AI가 코드를 써도, 소프트웨어는 퇴고가 필요하다

바이브 코딩의 시대입니다.

아이디어를 말하면 코드가 나오고, 에러 로그를 붙이면 원인을 추적해주고, 낯선 프레임워크도 예제부터 만들어 줍니다. 예전에는 반나절 걸리던 보일러플레이트가 몇 분 만에 생기고, 혼자 막혀 있던 버그도 대화하듯 풀립니다. 코딩은 분명히 쉬워졌습니다.

하지만 코딩이 쉬워졌다는 말과, 실제로 사용할 수 있는 애플리케이션을 만들기 쉬워졌다는 말은 같지 않습니다.

처음 실행되는 화면을 만드는 일은 훨씬 빨라졌습니다. 그런데 그 화면이 사용자 데이터와 만나고, 권한 모델과 연결되고, 장애 상황을 견디고, 배포 환경에서 설정을 읽고, 로그와 메트릭으로 관찰 가능해지고, 운영자가 문제를 이해할 수 있는 상태까지 가는 일은 여전히 어렵습니다.

AI는 코드를 빨리 씁니다. 그러나 소프트웨어는 코드만으로 완성되지 않습니다.

좋은 결과물은 여전히 이해에서 나온다

Anthropic이 2026년 6월에 공개한 Agentic coding and persistent returns to expertise 리포트는 이 지점을 꽤 흥미롭게 보여줍니다. 이 리포트는 2025년 10월부터 2026년 4월까지의 Claude Code 세션 약 40만 건을 분석했습니다.

핵심은 단순합니다. AI 코딩 도구를 사용하더라도, 사용자가 작업 도메인을 더 잘 이해할수록 성공률이 높았습니다. 특히 초급자와 중급자의 결과 차이는 크게 나타났고, 중급자와 고급자의 차이는 상대적으로 더 작았습니다.

다만 이 분석은 배포 후 제품 품질을 장기간 추적한 연구는 아닙니다. 세션 안에서 관찰 가능한 테스트 통과, 커밋이나 PR, 사용자 확인 같은 신호를 바탕으로 성공 여부를 추정한 분석에 가깝습니다. 그래서 이 결과를 “중급자는 항상 더 좋은 제품을 만든다”는 식으로 읽기보다는, 도메인 이해가 AI 도구를 더 효과적으로 쓰게 만든다는 근거로 보는 편이 자연스럽습니다.

이 결과를 “초급자는 AI를 쓰면 안 된다”는 뜻으로 읽을 필요는 없습니다. 오히려 반대에 가깝습니다. AI는 초급자에게도 엄청난 가속 장치입니다. 다만 좋은 결과물을 얻으려면 최소한 다음을 판단할 수 있어야 합니다.

• 지금 만든 코드가 문제를 실제로 해결하는가
• 빠진 요구사항은 없는가
• 실패했을 때 어떻게 보이는가
• 테스트가 의미 있는 경로를 확인하는가
• 코드가 커졌을 때 계속 고칠 수 있는 구조인가
• 운영 환경에서 설정, 로그, 권한, 데이터가 자연스럽게 이어지는가

이것은 천재적인 아키텍트의 감각이 아니라 중급자의 눈에 가깝습니다. 문제를 어느 정도 겪어본 사람, 첫 결과물의 빈틈을 알아보는 사람, “돌아간다”와 “쓸 수 있다”를 구분하는 사람의 눈입니다.

첫 결과물은 완성본이 아니라 초고다

AI 코딩 도구가 만들어주는 결과물은 종종 인상적입니다. 화면도 있고, API도 있고, 테스트도 있는 것처럼 보입니다. 그래서 위험한 착각이 생깁니다.

실행된다
  -> 거의 완성됐다

실제로는 더 자주 이런 상태입니다.

실행된다
  -> 검토할 수 있는 초고가 생겼다

초고가 생겼다는 것은 굉장히 큰 진전입니다. 빈 화면이나 빈 파일을 바라보는 시간은 줄어듭니다. 하지만 초고는 어디까지나 고칠 수 있는 재료입니다.

예를 들어 고객 목록을 검색하고 상태를 바꾸는 내부 운영 화면을 만든다고 해봅시다. AI는 검색 폼, 테이블, 상세 화면, 수정 API, 간단한 테스트까지 꽤 빠르게 만들 수 있습니다. 데모 데이터에서는 자연스럽게 동작하고, 화면도 그럴듯해 보일 수 있습니다.

하지만 실제로 쓰려면 곧 다른 질문들이 따라옵니다. 어떤 역할의 사용자가 어떤 고객 정보를 볼 수 있는지, 삭제되거나 병합된 고객은 어떻게 표시할지, 검색 결과가 수십만 건일 때 pagination과 index는 충분한지, 중복 submit은 막히는지, 개인정보는 로그에 남지 않는지, 상태 변경 이력은 감사 가능한지, 느린 API와 실패한 API는 화면에서 어떻게 보이는지 확인해야 합니다.

이런 것들은 마지막에 붙이는 장식이 아닙니다. “실제로 쓸 수 있는 애플리케이션”을 만드는 본문에 가깝습니다.

소프트웨어의 초고에는 대개 이런 빈틈이 남습니다.

• 정상 흐름은 있지만 예외 흐름이 약합니다.
• 데모 데이터에서는 맞지만 실제 데이터의 모양을 충분히 반영하지 못합니다.
• 타입은 맞지만 도메인 규칙은 빠져 있습니다.
• 테스트가 존재하지만 중요한 실패 조건을 검증하지 않습니다.
• 사용자 경험은 그럴듯하지만 반복 사용 시 불편합니다.
• 로컬에서는 동작하지만 배포, 설정, 관찰 가능성은 덜 다뤄졌습니다.

이 빈틈은 AI가 부족해서만 생기는 것이 아닙니다. 사람이 직접 코딩해도 똑같이 생깁니다. 차이는 속도입니다. AI는 초고를 더 빨리 만들고, 그만큼 더 빨리 수정할 기회를 줍니다.

그래서 좋은 바이브 코딩은 “느낌대로 맡기는 코딩”이라기보다 “빠른 초고를 만들고, 정확하게 고쳐나가는 코딩”에 가깝습니다.

중급자의 눈은 무엇을 보는가

좋은 결과물을 만드는 사람은 AI에게 더 긴 프롬프트를 쓰기만 하는 사람이 아닙니다. 결과물을 보고 다음 질문을 던질 수 있는 사람입니다.

이 상태는 어떤 입력에서 깨질까?
사용자가 같은 작업을 매일 반복하면 어디가 불편할까?
데이터가 10배가 되면 어떤 코드가 먼저 느려질까?
권한이 달라지면 어떤 API가 위험해질까?
운영자가 장애를 볼 때 필요한 로그는 남는가?
이 코드는 다음 기능을 붙일 때 어디를 다시 고치게 만들까?

이 질문들은 화려하지 않습니다. 하지만 실제 애플리케이션의 품질은 이런 질문에서 올라갑니다.

AI는 답을 제안할 수 있습니다. 테스트를 추가하고, 리팩터링하고, 문서를 보강하고, 대안을 비교할 수 있습니다. 그러나 무엇을 다시 물어볼지, 어떤 결과를 받아들일지, 어디까지 고쳐야 쓸 수 있는지 판단하는 일은 여전히 사람의 몫입니다.

여기서 필요한 것은 모든 것을 직접 구현하는 능력이 아닙니다. 오히려 다음에 가깝습니다.

• 요구사항을 더 구체적인 제약으로 바꾸는 능력
• 생성된 코드의 의도를 읽는 능력
• 도메인 규칙과 코드 사이의 어긋남을 찾는 능력
• 테스트할 가치가 있는 경로를 고르는 능력
• 지금 고쳐야 할 문제와 나중에 다룰 문제를 나누는 능력

이 정도의 이해가 있으면 AI 도구는 훨씬 강력해집니다. AI가 대신 생각해주는 것이 아니라, 내가 가진 판단력을 더 빠른 실험과 수정으로 확장해주기 때문입니다.

소프트웨어에도 퇴고가 있다

좋은 글을 쓰는 방법을 말할 때 자주 언급되는 책 중 하나가 이태준의 문장강화입니다. 이 책에서 특히 오래 남는 태도는 글을 한 번에 완성하려 하지 않는다는 점입니다. 문장은 고치고, 덜어내고, 순서를 바꾸고, 더 정확한 표현을 찾는 과정에서 힘을 얻습니다.

소프트웨어도 비슷합니다.

처음 나온 코드는 생각의 초안입니다. 테스트는 그 초안을 소리 내어 읽어보는 일에 가깝습니다. 리팩터링은 문장의 군더더기를 덜어내는 일이고, 사용자 피드백은 독자가 어디에서 멈추는지 확인하는 일입니다. 장애 대응과 운영 로그는 글을 책상 위가 아니라 실제 현장에 놓았을 때 드러나는 문맥입니다.

한 번에 좋은 소프트웨어가 나오지 않는다는 사실은 실망스러운 일이 아닙니다. 오히려 그 반대입니다. 고칠 수 있기 때문에 좋아질 수 있습니다.

AI 코딩 도구는 이 과정을 더 빠르게 만듭니다. 초안을 빨리 만들고, 테스트를 빨리 늘리고, 대안을 빨리 비교하고, 지루한 수정을 덜 고통스럽게 합니다. 하지만 이 속도가 퇴고를 생략해도 된다는 뜻은 아닙니다.

오히려 속도가 빨라질수록 퇴고는 더 중요해집니다. 생성되는 코드의 양이 많아지고, 그럴듯한 결과물이 더 빨리 나오기 때문입니다. 그럴듯함은 검토를 대신하지 못합니다.

완성은 한 번의 상태가 아니라 계속되는 과정이다

소프트웨어는 “완성”이라는 단어와 잘 어울리지 않는 대상입니다.

처음 배포한 뒤에도 사용자는 새로운 방식으로 기능을 사용합니다. 데이터는 예상보다 커집니다. 보안 요구사항은 바뀝니다. 의존성은 업데이트됩니다. 운영 환경은 변하고, 장애는 문서에 없던 조합으로 발생합니다. 어제의 좋은 구조가 내일의 변경에는 조금 둔해질 수 있습니다.

그래서 소프트웨어 개발은 끝이 있는 작업이라기보다 완성을 해 나가는 과정에 가깝습니다.

이 관점에서 보면 AI 코딩 도구를 잘 쓰는 방법도 조금 달라집니다.

AI에게 완성본을 맡긴다

보다

AI와 함께 초고를 만들고
사람이 기준을 세우고
테스트와 피드백으로 고치고
다시 더 나은 형태로 정리한다

에 가깝습니다.

실무에서는 이 루프가 더 건강합니다.

빠르게 초고를 만든다
  -> 도메인 제약을 대입한다
  -> 실패 경로와 테스트를 추가한다
  -> 실제 사용과 운영 신호를 보고 다시 고친다

바이브 코딩은 소프트웨어 개발을 가볍게 만들었습니다. 그 가벼움은 좋은 일입니다. 더 많은 사람이 아이디어를 실행해볼 수 있고, 더 빠르게 실험할 수 있고, 혼자서는 엄두 내기 어려웠던 구현도 시작할 수 있습니다.

어쩌면 이제 코드를 직접 쓰는 일의 상당 부분은 사람만의 역할이 아닐지도 모릅니다. 하지만 소프트웨어 개발은 여전히 사람의 판단이 필요한 일입니다. 무엇을 만들지 정하고, 왜 그렇게 만들어야 하는지 이해하고, 결과물이 실제 문제를 해결하는지 확인하고, 부족한 부분을 계속 고치는 과정은 아직 사람에게 남아 있습니다.

다만 좋은 소프트웨어는 여전히 한 번에 나오지 않습니다. AI가 코드를 써도, 소프트웨어에는 퇴고가 필요합니다.

그리고 어쩌면 앞으로의 좋은 개발자는 코드를 가장 많이 치는 사람이 아니라, 가장 잘 고치는 사람이 될지도 모릅니다.

참고

• Anthropic, Agentic coding and persistent returns to expertise, 2026년 6월 16일

함께 읽기 좋은 글

• 컨테이너 설정 주입의 마지막 한 끗: env에서 config로 - 로컬에서 돌아가는 코드를 실제 배포 가능한 형태로 다듬을 때 필요한 설정 흐름을 다룹니다.
• 수정하지 않을 YAML 로그를 왜 전부 객체로 만들까 - 문제의 성격을 이해한 뒤 구현 방식을 다시 고르는 예입니다.