인간은 더 이상 개발자가 아니다

저는 더 이상 코드를 많이 작성하지 않습니다. 아니, 거의 작성하지 않습니다.

저는 25년 동안 소프트웨어를 구축해 왔습니다. 결제 시스템, 문서 파이프라인, 은행 소프트웨어, 고부하 트랜잭션 시스템(high-load transactional systems) 등, 잘못되었을 때 심각한 오류를 일으키는 종류의 코드들을 다뤄왔습니다. 그래서 제가 인간은 더 이상 코드를 작성하는 존재가 아니라고 말할 때, 그것은 추측이 아닙니다. 저는 업무를 수행하는 동안 제 직업이 변하는 것을 직접 목격했습니다.

이제는 AI 에이전트(AI agents)가 그 일을 합니다. 저에게 남은 것은 다른 종류의 업무입니다. 저는 무엇을 만들지 결정하고, 규칙을 설정하며, 결과를 확인하고, 출시되는 결과물에 대한 책임을 집니다. 타이핑은 줄어들고, 판단은 늘어났습니다. 더 창의적이고 생산적이 되었습니다.

많은 이들이 여전히 AI가 나쁜 코드를 작성하고 실수를 한다고 주장합니다. 물론 그렇습니다. 인간도 마찬가지입니다. 바로 그렇기 때문에 저는 단 하나의 에이전트도 신뢰하지 않습니다. 저는 두 개의 에이전트가 서로 논쟁하게 만듭니다.

저는 합의 환경(consensus environment)을 운영합니다: Claude Code가 구축하고, Codex가 검토하며, 제가 판단합니다.

의도적으로 서로 다른 두 모델을 사용합니다. 각 모델은 저마다의 방식으로 결함이 있으며, 동일한 방향으로 실패하는 경우는 드뭅니다. Claude는 코드베이스(codebase)를 탐색하고 계획을 코드로 전환하는 데 강점이 있습니다. Codex는 냉철하게 개입하여 계획을 읽고, 차이점(diff)을 살펴보고, Claude가 생성한 결과물에 이의를 제기합니다. 핵심은 어느 한 에이전트가 항상 옳다는 것이 아닙니다. 핵심은 그들이 틀리는 방식이 서로 다르다는 점입니다.

그리고 현재 이 조합은 매우 잘 작동하고 있습니다. 숙련된 개발자가 작성한 것만큼, 때로는 그보다 더 훌륭하고, 당연히 인간보다 훨씬 빠른, 작동 가능하며 깨끗하고 신뢰할 수 있는 코드를 생성합니다.

AI 에이전트를 사용하는 것은 '바이브 코딩(vibe coding)'이 아닙니다. 그것은 하나의 기술(skill)입니다.

당신은 그것을 구축하고, 연마하며, 도구들이 계속 변화함에 따라 최신 상태를 유지해야 합니다. 그런 의미에서 이것은 이 직업의 다른 기술들, 즉 언어를 배우고, 패턴을 배우고, 아키텍처(architecture)를 배우는 것과 다르지 않습니다. 누구도 우연히 이 기술에 능숙해지지 않으며, 연습 없이는 누구도 숙련된 상태를 유지할 수 없습니다.

AI 에이전트(AI agents)는 이미 어떤 작업을 건네주며 "가서 만들어봐"라고 말해도 될 만큼 충분히 똑똑합니다. 하지만 복잡한 작업에 이를 시도해 본다면 그 결과는 실망스러울 것입니다. 소프트웨어 개발은 분기(branching)가 발생하는 문제입니다. 동일한 목표에 도달하는 방법은 매우 많으며, 초기에 잘못된 방향으로 한 번만 틀어져도 그 이후의 모든 과정이 잘못된 방향으로 흐르게 됩니다. 설령 그 분기(branch)가 아무리 깔끔하게 작성되었다 하더라도 말입니다.

명세(Spec)를 먼저 작성하고, 코드는 나중에 작성하십시오. 업계에서는 이를 명세 주도 개발 (spec-driven development)이라고 부릅니다.

따라서 복잡한 작업이나 운영 코드(production code)에 대한 어떠한 변경 사항에 대해서도, 저는 결코 코드부터 시작하지 않습니다. 저는 계획, 즉 명세(spec)부터 시작합니다. 작업의 성격에 따라 그 계획을 올바르게 세우는 데 수십 번의 반복(iteration)이 필요할 수도 있으며, 이 모든 과정은 에이전트(agents)와 함께 수행됩니다. 계획이 확정되었을 때 비로소 Claude와 Codex가 그 계획에 따라 코드를 작성하고 검토하도록 합니다.

네, 시작 단계에서는 더 느립니다. 하지만 초기에 투입하는 그 시간이 이후의 모든 과정을 더 빠르게 만듭니다. 나중에 두 배로 비용을 치르는 대신, 초기에 미리 지불하는 것입니다.

그리고 이것은 단지 저의 개인적인 습관이 아닙니다. 업계 전체가 같은 방향으로 움직이고 있습니다. GitHub의 Spec Kit, AWS의 Kiro 등, 명세(spec)를 신뢰할 수 있는 단일 원천 (source of truth)으로 취급하고 에이전트(agents)가 이를 바탕으로 빌드하도록 만드는 도구들이 등장하고 있습니다. 빠른 프로토타입(prototype) 제작이나 일회성 스크립트의 경우에는 이 모든 과정을 생략합니다. 계획을 세우는 비용은 잘못된 결정이 가져올 비용이 클 때에만 가치를 발휘합니다.

그 단계부터 명세(spec)와 코드는 Claude Code와 Codex 사이에서 동일한 피드백 루프를 거치며, 저는 마지막에 승인합니다. 전체 루프는 다음과 같습니다:

탐색 (Explore) → 명세 초안 작성 (Draft spec) → Claude + Codex 검토 (review) → 명세 수정 (Fix the spec) → 구현 (Implement) → Claude + Codex 검토 (review) → 테스트 (Tests) → 인간 검증 (Human validation) → 커밋 (Commit)

완벽한 프롬프트 (prompt)를 만드는 데 시간을 낭비하지 마세요. 당신의 명세 (spec)가 더 중요합니다.

프롬프트 자체는 특별히 영리할 것이 없습니다. 제가 실제로 사용하는 프롬프트들은 다음과 같습니다:

• 계획을 구현하세요 (Implement the plan).
• 명세(spec)에 따라 변경 사항을 검토하세요 (Review the changes against the spec).
• 독립적인 검토자로서 이 계획을 코드베이스(codebase)와 대조하여 검토하세요 (Review this plan against the codebase as an independent reviewer).
• 이 검토 내용을 비판적으로 검증하고, 타당한 지점들만 적용하세요 (Critically validate this review, and apply only the points that make sense).

사람들을 놀라게 하겠지만, 스타일, 문구, 심지어 오타조차 실제로는 큰 차이를 만들지 않습니다. 중요한 것은 프롬프트(Prompt) 뒤에 있는 명세(Spec)와 출력을 읽어내는 판단력입니다. 약한 명세 위에 올라간 영리한 프롬프트는 여전히 약한 코드를 만들어낼 뿐입니다.

유용한 발견은 거의 항상 구문(Syntax)에 관한 것이 아닙니다. 그것은 다음과 같은 것들입니다: 이것이 조용히 다른 입력 유형을 깨뜨린다, 이것이 재시도(Retry) 시 발생하는 일을 무시한다, 이것이 명세에서 설정 가능해야 한다고 명시한 값을 하드코딩(Hardcode)한다, 이것이 새로운 데이터는 처리하지만 오래된 데이터는 처리하지 못한다. 즉, 진짜 문제들입니다. 나중에 당신의 주말을 앗아갈 법한 그런 문제들 말입니다.

리뷰어의 피드백이 최종 결정은 아닙니다. Claude는 타당한 내용만을 적용하며, 결코 전체 목록을 다 적용하지 않습니다. 모든 제안을 수용하는 것은 단지 생각하지 않는 또 다른 방식일 뿐입니다.

업무는 사라지는 것이 아니라, 상위 단계로 이동합니다.

이 중 어느 것도 마법이 아니며, 대부분은 자동화될 수 있습니다. 분명히 그렇게 될 것입니다. 다음 단계는 명확합니다. 에이전트(Agent)들이 스스로 계획하고, 구축하고, 리뷰하며, 서로 논쟁하는 멀티 에이전트 개발 환경(Multi-agent development environments)입니다.

그리고 마지막 단계는 언제나 저입니다. 에이전트들이 구축하고, 논쟁하고, 수정합니다. 하지만 무엇이 진실인지 결정하고 그 결과에 내 이름을 거는 것은 바로 저입니다. 새벽 3시에 시스템이 망가진다면, 어떤 에이전트에게도 전화가 가지 않습니다. 저에게 전화가 옵니다.

만약 당신이 여전히 모든 코드를 직접 손으로 작성하고 있다면, 질문이 하나 있습니다. 왜인가요? 그리고 그것이 얼마나 오래 지속될 것이라고 생각합니까?