처음부터 AI에게 코드를 만들게 하지 마라

2026년 1월 나는 여전히 이전의 방식으로 C++을 이용하여 상용 소프트웨어를 개발하고 있었다. Visual Studio 2022와 2026을 이용하여 코드를 작성하고 빌드하고 테스트하면서 윈도우 응용프로그램에서 사용할 모듈을 만드는 개발 업무를 수행하고 있었다. 하지만 한순간에 모든 것이 바뀌었다. anthropic의 claude code가 소프트웨어를 개발할 수 있고 소프트웨어 개발의 결과물이 놀라울 정도로 완성도를 갖추고 있다는 것을 확인했다. 물론 이전에도 ai가 코딩을 할 수 있다는 것은 알고 있었지만 2025년까지만 해도 수준이 낮았고 코드의 품질이 좋지 못했기 때문에 상용 소프트웨어 개발에는 아직 사용할 수 없다고 생각하고 있었다.

뉴스에서 AI에 관련된 내용이 많아지고 온라인의 컨텐츠들은 AI가 가장 먼저 대체할 직업이 프로그래머라고 했다. 이러한 인식은 단순히 뉴스에 머물지 않았다. 실제로 IT 기업들이 개발자에 대한 신규 채용을 줄이거나 없애고 기존의 인력 또한 감축하기 시작했다. AI로 달라질 미래에 대해 현실 세계가 대응하기 시작한 것이다. AI와 가장 가까운 IT 기업이 가장 빠르게 인지하고 실행에 옮기기 시작한 것이다. 나도 이 때 많은 생각과 고민을 했다. 20년 이상 같은 분야에서 쌓아 왔던 노력과 경험이 AI라는 것에 의해 송두리째 흔들리는 느낌을 강하게 받았다. 커리어 차원에서의 허탈함마저 들었다.

부딪쳐 보기로 했다. claude, gemini, codex 등을 이용하여 AI를 이용한 개발을 실험해보기 시작했다. 모두 어느 정도의 POC 수준의 코드를 만들어내는 것은 확인했다. 그중에서 claude의 opus 모델이 눈에 띄게 좋은 성능을 보여주었다. opus를 이용하여 개발 작업을 시작했다. 모든 모델을 두루 잘 다루는 것보다 한 가지를 깊이 있게 다뤄보고 싶었다.

opus는 agentic coding에 특화된 모델이었다. 현존하는 AI들이 다양한 분야에서 인공지능으로서의 역할을 수행하고 있었지만 개발자의 개발 영역에서는 opus가 가장 강력했다. opus를 실험하고 공부했다. 초기에는 내 의도와 다른 많은 실패작들이 탄생했다. AI에 대한 연구가 더 필요하다고 생각했다.

프롬프트를 연구했고, 스킬을 이용하고 만들어보고, 훅을 이용해보고, 하네스에 대해서도 실험해보았다. 프롬프트, 스킬, 훅, 하네스가 모두 효과가 있었다. AI agent가 내가 의도하는 것에 가까운 결과물을 만들어 내기 시작했다. 하지만 90%였다. 90%에서 나머지 5%를 더 올리는 일은 무척 어려운 작업이었다. 심지어는 90%에서 5%를 더 올리기 위한 작업 중에 90%까지 쌓은 결과물이 망가져서 작업률이 후퇴하는 경험도 있었다. 단순히 기술적인 방법으로 AI agent를 상용 수준의 코드를 만드는 도구로 만드는 것에는 한계가 있다고 느꼈다.

근본적인 문제에 대해 더 고민하기 시작했다. 왜 AI는 내가 원하는 동작을 수행하지 못할까? AI가 아직 성능이 좋지 않아서일까? 아니다 AI는 이미 훌륭했다. 단지 내 의지와 AI가 이해하는 바가 달랐기 때문이다. 나는 나의 의도와 AI가 인지하는 바를 일치시키기 위해 노력했다. 여기서 내가 얻은 결론은 PRD를 정교하게 만드는 것이 가장 중요하다는 것이었다. 이전에는 프롬프트에 의존하여 내가 원하는 기능이나 설계를 단편적으로 쏟아내면서 프로그램을 구성하고 있었다. 시작부터 잘못된 것이다.

"그래픽이 좋은 테트리스 게임 만들어줘." 로 시작했던 게 가장 큰 실수였다. 이렇게 만들어진 프로그램을 실행하고 실행 후 "이 부분 바꿔줘.", "저 부분 바꿔줘"와 같은 프롬프트를 통해 소프트웨어를 제작하려고 했던 것이다. AI가 많은 부분을 대신 해줄 것이라는 믿음이 위와 같은 실수를 낳는다. 한 가지 꼭 명심해야 할 부분이 있다. AI는 사람의 의중을 이해하고 만족할 만한 결과물을 스스로 만들어내지 않는다. AI가 나의 동료나 친구처럼 나와의 몇 마디 대화에서 나의 뜻을 알아차릴 것이라고 착각해서는 안 된다. AI는 모호하지 않고 명확하게 주어지는 사실만을 근거로 동작한다. 자율적 판단은 단지 스텝을 진행하기 위해 내리는 결정이지 사람이 만족하는 결과를 위해 판단을 내리지 않는다. 따라서 나의 의도를 최대한 팩트에 근거해서 기술해야 한다. PRD가 가장 기초적이고 근본적으로 이 문제를 해결할 수 있는 단계가 된다.

처음부터 AI에게 코드를 만들게 하지 마라. 설계와 개발의 방향을 코드 작성 단계 이전에 최대한 문서화하고 문서를 매개체로 사람과 AI가 반복적으로 오해를 줄여나가는 작업을 반드시 선행해야 한다. 소프트웨어가 복잡해질수록 코드 작성 이전의 과정이 복잡해진다. PRD를 비롯한 수많은 설계문서를 먼저 작성해야 한다.

AI가 많은 작업을 자동화하고 빠르게 처리해 주는 것은 확실히 맞다. 하지만 요청자가 원하는 것을 자동으로 처리해 주지는 않는다. AI를 이용한 개발작업을 진행하면 할수록 이전의 소프트웨어 개발 방식의 차이와 달라진 점이 제한적이라는 것을 느끼게 된다.

이전의 개발 작업을 요구사항->설계/기획/디자인->WBS->개발->테스트->배포 라고 해보자. 이전에는 이 작업을 모두 사람이 수행했다. AI를 이용한 개발에서는 위의 모든 단계에 AI의 도움을 받을 수 있다. AI를 이용해서 위의 단계를 빠르게 진행할 수 있다. 하지만 여기서 조심해야 할 것은 위의 과정을 PRD 한 장으로 한 번에 끝까지 진행할 수 없다는 것이다. AI가 알아서 해준다는 생각으로 위의 각 단계를 AI에게 모두 위임할 수 있다는 생각이 마지막 단계에서 나의 의도와 다른 소프트웨어를 만들어내는 가장 큰 실수가 될 수 있는 것이다.

시니어 개발자의 경우 전통적인 방식의 소프트웨어 개발 방식에 익숙하고 경험이 많다. 도메인 지식이 풍부한 오랜 경험을 가진 시니어 개발자가 AI가 소프트웨어를 개발하는 방식을 잘 이해하고 이용한다면 최고의 효율과 속도의 개발을 진행할 수 있다. AI가 없던 시절에도 요구사항 분석과 설계 과정에서 이후의 개발에서 발생할 수많은 문제와 결정 사항을 고려하고 이러한 사항을 설계와 기획에 반영하게 했다. AI를 이용한 개발 시대에 이 부분이 이전보다 더 중요해졌다. 설계상의 문제는 실제 개발 단계에서 개발만으로 해결하기 힘든 경우가 많다. 설계를 수정해야 된다. AI 개발도 마찬가지다. 설계가 중요하다. 설계 단계의 문제를 사람과 마찬가지로 AI도 완벽하게 해결할 수 없다. 오히려 사람보다 더 망가뜨릴 수 있다.

위와 같은 생각으로 AI를 이용하여 개발을 구상하게 되면 자연스럽게 AI에게 보여주기 위해 만들어야 할 문서와 단계별로 어떤 사항을 체크해야 하는지 떠오르게 된다. 이 부분을 프롬프트, 스킬, 훅, 하네스로 연결하면 AI를 이용한 상용 소프트웨어 개발이 가능해진다. AI 이전 시대에 아키텍트 한 명이 솔루션을 끝까지 개발하기 위해서는 물리적으로 어려웠지만 이제는 가능해졌다. 이전에 10명이 필요했던 개발팀이 이제는 한두 명이면 가능할 수도 있다. 조금 더 많으면 나을 수도 있다. AI를 감시하는 역할이 필요해졌기 때문이다.

AI의 탄생으로 개발자가 필요 없는 세상이 될 것 같다는 걱정을 이제는 하지 않는다. AI를 잘 다루는 개발자가 오히려 더 많이 필요해질 것이다. AI는 개발을 해야 하는 이유를 갖고 있지 않다. 개발자가 개발을 지시하기 때문에 개발을 수행할 뿐이다. 미래에도 여전히 많은 수의 소프트웨어가 필요하다. 이러한 소프트웨어를 AI가 스스로 만들어내지 않는다. AI에게 개발 작업을 지시하고 감시하고 높은 품질의 소프트웨어를 배포하는 결정을 내리는 개발자가 더 많이 필요해질 것이다.