LLM 기반 ‘바이브 코딩’이 사고와 검증, 몰입을 어떻게 방해하는지, 그리고 손으로 코드를 쓰는 즐거움과 통제된 방식으로 LLM을 활용하는 타협점을 이야기한다.
2026년 2월 7일 · 4분 · Abhinav Omprakash
클로드-코드(claude-code)가 일하는 모습을 보다가 휴대폰으로 시선이 튀는 사이, 익숙한 우울감과 무기력이 스멀스멀 올라오는 걸 느꼈다. “이게 다 무슨 의미가 있지?”라는 생각이 들었다. LLM은 그럴듯하고(대충) 맞는 것처럼 보이는(대충) 코드를 뚝딱 생성해 주는데, 그럼 나는 남는 시간으로 뭘 하게 되지? 둠스크롤? 이번이 클로드-코드를 세 번째로 다시 써본 거였다. 매번 똑같은 기분을 느꼈고, 결국 2~3주 지나면 클로드-코드를 삭제하게 됐다. 그런데 어쩐지 아는가? 매번. 그때마다. 나는 코딩의 즐거움을 다시 발견했다.
그래. 코딩은 소프트웨어 엔지니어링 그 자체는 아니다. 하지만 내게 코딩은 그 일의 재미있고도 필수적인 한 부분이다. 소프트웨어 엔지니어링을 효과적으로 하려면 문제 영역(problem space)에 익숙해야 하고, 그러려면 문제를 붙잡고 씨름하며 생각해야 한다. API의 문서나 구현을 읽기만 해서 그 API를 쓰는 고통을 정말로 알 수는 없다. 직접 써봐야 느낀다. 코드를 쓰는 행위는—비록 더 느리더라도—내가 문제 영역과 씨름하는 방식이었고, 처음 떠올린 아이디어가 통하지 않는다는 걸 알아내는 방식이었고, 생각하는 방식이었다. 바이브 코딩은 그걸 방해했다.
글을 쓰지 않고 생각한다면, 당신은 생각하고 있다고 착각할 뿐이다.
— Leslie Lamport
이 일의 또 다른 큰 부분은 정확성(correctness)을 보장하는 것이다. 내게는 내가 직접 쓰지 않은 코드의 정확성을 검증하는 게, 내가 쓴 코드보다 훨씬 어렵다. 코드를 쓰는 과정은 맥락을 내 안에 내재화하도록 돕고, 내 뇌가 그 맥락을 깊게 다루기 더 쉽게 만든다. 이걸 LLM에 외주 주면 문제 도메인을 내재화하는 과정을 건너뛰게 되고, 생성된 코드가 정확한지 확신할 수 없게 된다.
설계상, 바이브 코딩은 중독성이 있다. 지시 몇 줄을 쓰면, 맞아 보이는 코드가 생성된다. 쾅! 도파민 한 방! 코드가 맞지 않다면… 프롬프트 한 번만 더 치면 맞게 될 거지? 그렇지?
바이브 코딩은 또, 내 뇌를 꺼버리고 변경 사항을 수동적으로 받아들이게 만드는 강력한 효과가 있다. 정작 뇌를 써야 할 때가 되면, 그 관성을 극복하기가 훨씬 더 어렵고, 손쉬운(게으른) 길을 택하기가 너무 쉽다. 내가 가장 바닥이었을 때는, 파일에서 찾기/바꾸기(find-and-replace)조차 LLM에게 시켰다. 몇 초면 끝날 일을, 이제는 몇 분과 네트워크 호출이 필요하게 만든 셈이다.
30분 만에 1,000줄짜리 PR을 생성하더라도, 나는 결국 그걸 이해하고 리뷰해야 한다. 내가 배포하는 코드에 대한 책임은 내게 있으니, 결국 내가 병목이 된다.
바이브 코딩에 대한 흔한 관점은 “좋지도 나쁘지도 않다, 그저 도구일 뿐”이라는 것이다. 하지만 도구는 워크플로와 사고 과정을 형성한다. 어떤 도구가 깊게 생각하는 걸 막는다면, 나는 그게 좋은 도구라고 생각하지 않는다. 지식 노동자라면 핵심 역량은 생각하는 능력인데, 어떤 도구가 그걸 방해한다면 두려워해야 한다. 정말로 두려워해야 한다.
그렇다고 내가 LLM으로 코드를 생성하지 않는다고 말하면 거짓말이다. 나는 여전히 Claude를 쓰지만, 더 통제된 방식으로 쓴다. 필요한 맥락을 제공하는 데 중요하다고 생각되는 파일은 내가 직접 복사해 붙여 넣고, 그다음 코드도 복사해 붙여 넣은 뒤 그 코드의 변경을 요청하거나 테스트를 작성해 달라고 한다. 이런 ‘마찰’은 여러 이점이 있다. 여러 파일에 걸친 변경을 한 번에 만들 수 없으니 생성되는 diff가 너무 커지지 않는다. 또 다른 파일들을 내가 수동으로 바꿔야 한다면, 코드가 전체에서 어떻게 맞물리는지 내가 알고 있게 된다. 클로드에게 맥락을 수동으로 제공하는 것은, 그냥 “요리해(cook)”라고 맡기기보다 내가 코드베이스에 스스로 익숙해지도록 강제한다. 코드를 생성하는 일을 수동적인 행동에서, 의도적이고 사려 깊은 행동으로 바꿔 준다. 그리고 내 뇌가 계속 관여하고 활성화된 상태를 유지하게 해 주므로, 나는 여전히 몰입 상태(flow state)에 들어갈 수 있다. 내게는 이것이 두 세계의 장점을 모두 취하는 최선의 방식이었고, 일하면서의 행복을 지키는 방법이었다.
결국, 행복을 최적화하지 않기엔 인생은 너무 짧다. 어쩌면(정말 큰 어쩌면) 기능 전체를 통째로 생성하는 것이 내 생산성을 더 높여줄 수도 있다. 하지만 그게 실존적 공포를 불러오고 나를 우울하게 만든다면, 장기적으로 생산적이라고 보기는 어렵다. 당신도 이런 감정들 중 일부에 공감할지도 모른다. 아닐 수도 있다. 하지만 다르게 선택하는 것을 두려워하지 말라.
