LLM(대규모 언어 모델)을 활용한 코딩의 유용한 점과 한계, 그리고 소프트웨어 개발에서의 현실적인 영향에 대한 생각.
홈 · 기능 · 문서 · 블로그 · 다운로드 · 법적 고지 · 문의
2026년 1월 18일
우리는 AI 열풍의 정점에 거의 다다른 것처럼 보입니다. 이제 이 기술의 유용함과 한계가 분명해졌습니다. 지금 보이는 것은 블록체인과 암호화폐가 몇 년 전 그랬던 것처럼, 결코 잘 작동하지 않을 영역에까지 아이디어를 무리하게 확장해 적용하려는 시도들입니다.
도처에 있는 AI 스타트업들은 실패할 것이고, 주가지수 하락과 함께 많은 회사에서 AI 전략을 재평가하는 일이 벌어질 겁니다. 저는 새로운 AI 에이전트에 들뜨지도 않고, 제가 쓸모없어질까 두렵지도 않습니다. 이제는 지루합니다. 사용자들도 맛없는 그림들, 과하게 친절한 AI 요약들, 토스터마다 튀어나오는 채팅 창에 질려 있습니다.
오해하지는 마세요. LLM이 정말로 유용한 분야도 많습니다. 지루한 단위 테스트를 더 이상 전부 손으로 쓰지 않아도 된다는 건 반가운 일입니다. 버리고 끝낼 스크립트를 빠르게 뚝딱 만들거나, 함수를 한 프로그래밍 언어에서 다른 언어로 번역하거나, 거의 모르는 언어로 코딩할 때 시작점으로 쓸 무언가를 생성할 수 있다는 것도 훌륭하죠. 문제는 그 “무언가”를 완성품으로 받아들이는 순간부터 생깁니다.
오래된 책(스티브 맥코널의 Code Complete)에는 코드 작성과 리뷰가 평균 개발자 시간의 약 30%를 차지한다고 나옵니다. 나머지 시간은 논의, 이메일 답장, 문서 읽기, 트러블슈팅, 학습, 혹은 개인적인 일에 쓰이죠. 이 데이터는 1964년 연구에서 온 것이고 비율은 사람과 회사에 따라 달라지겠지만, 어떤 개발자든 자신이 근무 시간의 100%를 소스 코드만 다루는 데 쓰지 않는다는 점은 인정할 겁니다. 30%라는 추정이 맞고 코딩을 20% 더 빠르게 할 수 있다고 해도, 프로젝트 기간 단축은 5% 정도만 기대할 수 있습니다(암달의 법칙을 보세요).
그러니 주말에 완제품을 만들 수 있다는 약속은 비현실적입니다. 프로그래밍은 어렵습니다. 저는 몇 시간씩 UI 이슈를 디버깅하거나 어셈블러 출력을 확인합니다. 이것은 제가 손으로 코딩한 제 프로젝트라서 꽤 잘 이해하고 있음에도 그렇습니다. 만약 제가 바이브코딩을 하고 있었다면, 근본 원인을 찾는 데 더 오래 걸렸을 겁니다.
제 경력에서, LLM으로 대량의 평범한 코드를 빠르게 생성해야 했던 프로젝트는 한 번도 없었습니다. 보통 이야기는 이렇게 흘러갑니다. 낮에는 본업이 있는 캘리포니아 남자 둘이 제품을 만들고, 갑자기 인기를 얻습니다. 코드는 엉망이고 확장성 한계에 부딪히죠. 그래서 그들은 저 같은 중부 유럽 개발자를 채용합니다. 베이 에어리어에서 같은 역량을 가진 개발자를 쓰면 비용이 더 들기 때문이죠. 동시에, 그 급여는 제가 제 지역에서 벌 수 있는 것보다 높습니다. 그래서 우리는 문화 차이, 강한 억양, 미친 시간대 차이를 서로 감내합니다.
저는 점차 문제를 디버깅하고, 코드를 더 잘 조직하고 더 빠르게 만듭니다. 어떤 회사에서는 6배 빠르게 만들었습니다. 그렇다고 창업자들이 나쁜 개발자였다는 뜻은 아닙니다. 단지 첫 버전을 만들 때 몇몇 부분을 타협했을 뿐이죠. 하지만 적어도 코드는 인간이 썼습니다.
요즘 새 창업자들 중 상당수는 바이브코딩을 하니, 저는 아마 죽거나 흥미를 잃을 때까지 그런 컨설팅 일을 할 수 있을 것 같습니다. 이상한 클래스 계층 구조, 특수 케이스 처리로 땜질된 논리 오류, 그리고 LLM이 GitHub나 StackOverflow에서 뜯어온 버그 있는 코드 조각들을 잔뜩 보게 되겠죠.
AI에 의존해 공부하는 사람들이 늘면, 기술적 문제를 해결할 수 있는 젊은이들은 줄어들 겁니다. 간단한 문제의 해답을 ChatGPT에 물어보는 데 익숙해지면, AI가 도와줄 수 없는 복잡하거나 새로운 이슈를 트러블슈팅하는 방법을 결코 배우지 못합니다. 인지 능력도 신체 능력처럼 훈련과 연습이 필요합니다.
게다가 프롬프팅은 그 자체로 하나의 기술입니다. 특히 영어가 모국어가 아니라면, 원하는 동작을 모든 세부까지 말로 설명하느니 차라리 코드를 직접 쓰는 편이 더 쉬운 경우가 많습니다.
제 생각에 바이브코딩은 고수준 프로그래밍 언어 위에 또 하나의 추상화 계층을 얹는 것에 불과합니다. 프로젝트에 반복적인 AI 생성 코드가 많다면, 라이브러리, 프레임워크, 또는 DSL(도메인 특화 언어)을 설계하는 편이 도움이 될 수 있다는 신호입니다. 경우에 따라서는 메타프로그래밍 기법도 도움이 됩니다.
노엄 촘스키가 거의 3년 전에 지적했듯이, LLM은 인간의 마음을 대체하는 것이 아닙니다. 유용하긴 하지만, 우리처럼 생각할 수는 없습니다. AI가 정신 건강에 미치는 영향은 현재 활발히 연구 중입니다. 제 생각(IMHO)에, 비디오 카드 칩과 대화하는 것은 인간에게 자연스러운 일이 아니며, 분명 정보 과부하를 만들어냅니다. 전반적으로 LLM은 소프트웨어 공학을 크게 단순하게 만들지 못합니다. 오히려 잘못 사용하면 복잡성을 더합니다.
앞으로 Aba Search and Replace에 몇 가지 AI 기능을 추가할 수도 있지만, 이것이 사생활을 침해하는 AI 에이전트가 되는 일은 없을 것이고, 여러분의 파일은 항상 여러분의 컴퓨터에 남아 있을 것입니다. 앱을 개발할 때 저는 텍스트 교정을 위해 로컬에서 실행되는 LLM만 사용합니다. 실험으로, 이 블로그 글은 AI의 도움 없이 작성했습니다.
브라우저 탭과 무작위 온라인 도구 사이를 오가며 시간을 낭비하지 마세요. Aba Search and Replace는 여러 파일에 걸친 빠르고 안전한 텍스트 업데이트와 데이터 변환을 위한 스위스 아미 나이프이며, 모든 데이터는 여러분의 컴퓨터에 그대로 남습니다. 개발자, 테스터, 분석가를 위해 만들었습니다.
이 블로그는 여러 파일에서 텍스트를 치환하는 도구인 Aba Search and Replace에 관한 블로그입니다.
구독