첫 번째 레슨을 게시한 후, 왜 제가 AI로 빌드하기 시작했는지, 무엇을 배웠는지, 그리고 그것이 AI 시대의 소프트웨어 개발에 대한 제 관점을 어떻게 형성했는지로 이 시리즈를 시작했어야 했다는 것을 깨달았습니다.

저는 약 25년 동안 엔지니어링 팀을 이끌어 왔습니다. 최근에는 다시 직접 코드를 작성하고 있습니다. 지난 몇 달 동안 저는 대부분 혼자서 제품 하나를 엔드 투 엔드(end to end)로 구축했습니다. 즉, 전체 과정에 AI를 포함하여(AI in the loop) 계획부터 배포까지 AI 네이티브(AI-native) 조달 도구를 만들었습니다.

• 약 4개월 만에 제로(Zero)에서 프로덕션(production) 단계까지 도달
• 수천 개의 테스트 수행
• 사용 사례(use case)에 따라 선택된 여러 LLM(Large Language Model) 제공업체 활용
• 프롬프트(prompt)가 필요한 사항에 따라 벤더와 모델의 선택을 주도

저는 이러한 도구들에 대해 읽는 것이 아니라, 직접 사용함으로써 이해하고 싶었습니다. 다음은 제가 배운 내용이며, 잘 작동했던 부분과 그렇지 않았던 부분들입니다.

계획 (The Plan)

계획은 주로 제가 직접 구축하고, AI를 사용하여 속도를 높이며, 모든 설계 결정을 직접 내리는 것이었습니다. 마지막 부분은 결코 변하지 않았습니다. AI는 제가 결정을 내리기 전에 옵션을 비교하고 선택이 어떤 결과를 초래할지 생각하도록 도와주지만, 최종 결정은 저의 몫입니다. 팀을 이끌어온 수많은 세월을 거치며, 저는 제가 완전히 설명할 수 없는 시스템을 출시하는 것을 좋아하지 않게 되었습니다.

그 점은 저의 공백과 정면으로 충돌했습니다. 저는 Java로 많은 것을 구축해 왔으며, 일부는 처음부터 만들었고 일부는 가져와서 확장했습니다. Python도 익숙하지만, Python만으로 처음부터 끝까지 완전한 앱을 혼자 구축해 본 적은 없었습니다. 그래서 저는 제가 가장 취약한 부분에서 AI에 가장 많이 의존하고 있었습니다. 그 점이 도구의 선택을 제가 예상했던 것보다 더 중요하게 만들었습니다.

도구 (The Tools)

저는 Gemini로 시작했습니다. 많은 것을 잘하지만, 당시 가장 중요했던 한 가지 측면에서 무너졌습니다. 바로 자신의 유닛 테스트(unit tests)를 통과시키지 못했다는 점입니다. Mock(모의 객체)을 엉망으로 만들었고, 문제를 해결하는 대신 스스로 더 깊은 구덩이를 파고 들어갔습니다. 실패의 원인이나 이유를 저에게 말해주지 못했습니다.

저는 Claude를 시도해 보기로 결정했고, 실패 원인을 이해하고 수정하는 것을 도와달라고 요청했습니다. 30분 이내에 모든 것이 통과되었습니다.

한 가지 주의 사항이 있으며, 이는 포스트 전체에 해당합니다. 이 글은 어떤 도구를 지지하는 것이 아닙니다. 저는 우연히 몇 가지 특정 도구들을 사용하여 빌드했을 뿐이며, 두 도구 모두 2025년 말 이후로 크게 발전했기에 그날 오후의 경험은 하나의 스냅샷일 뿐 최종적인 판결이 아닙니다. 이어지는 내용은 어떤 에이전트(agent)를 선택할지에 관한 것이 아닙니다. 어떤 도구가 타이핑을 하든 제가 맞닥뜨린 어려운 부분들은 동일하기 때문에, 어떤 에이전트와도 협업하는 방법에 관한 것입니다.

사실, 이것이 바로 제가 단 하나의 모델이 내놓는 첫 번째 답변을 신뢰하는 대신, 설계 단계부터 멀티 모델 검증 (multi-model validation)을 아키텍처에 포함시킨 정확한 이유입니다. 서로 다른 모델들은 서로 다른 것들을 잡아냅니다. 그리고 단일 모델이라 할지라도 요청만 한다면 첫 번째 시도보다 더 많은 것을 제공합니다. 유도 질문을 던지거나, 자신의 답변을 포함하여 답변을 검토하라고 지시하면, 모델은 방금 한 말을 방어하는 대신 정직해지며 더 깊이 파고듭니다. 문제는 우리에게 있습니다. 우리는 질문하는 법을 배워야 하며, 질문하는 것을 잊지 말아야 합니다.

테스트(Tests)는 오랫동안 저의 아킬레스건이었습니다. 테스트가 실패할 때마다 에이전트에게 그 문제를 가리키면, 에이전트는 헛돌며 길을 잃곤 했습니다. 그래서 실패 사례들을 배치(batches) 단위로 전달해 보았고, 결과는 훨씬 좋아졌습니다. 테스트가 실제로 효과를 발휘하기 시작한 진정한 전환점은 테스트 시스템을 완전히 리팩터링 (refactor)한 이후에 찾아왔습니다 (Lesson 1 참조).

이 모든 과정에서 제가 얻은 더 큰 교훈은 이것입니다: 가치는 자동 완성 (autocomplete)에 있는 것이 아닙니다. 제대로 사용한다면, 이는 당신이 부족한 분야에서 당신의 역량을 끌어올려 주는 도구이며, 저는 마침 그런 부족한 부분이 눈앞에 놓여 있었습니다. 저는 AI를 더 빠른 키보드처럼 취급하는 것을 멈추고, 제가 관리해야 하는 빠르고 문자 그대로의 엔지니어 (literal engineer)처럼 취급하기 시작했습니다.

차질 (The Setbacks)

프로토타입(prototypes)은 빠르게 만들어졌습니다. 만약 '따라간다'는 의미가 내 시스템에서 실제로 무엇이 실행되고 있는지 실제로 이해하는 것을 뜻한다면, 제가 따라갈 수 없을 정도로 빨랐습니다. 아무도 그 부분에 대해 경고해주지 않습니다. AI가 코드를 생성하게 만드는 것은 쉬운 부분입니다. 그것이 생성한 내용을 파악하고 통제하는 것이 진짜 작업입니다.

이것은 그 과정을 구체화한 버전입니다. 제가 계획을 작성했고, 에이전트(agent)가 이를 실행했으며, 모든 것이 완료된 것처럼 보였습니다. 며칠 후, 다른 작업을 하던 중 저는 에이전트가 몇 가지 사항이 중요하지 않다고 조용히 판단하여 누락시켰다는 사실을 발견했습니다.

• 감사 날짜 필드(Audit date fields): 불필요하다고 판단하여 삭제함.
• 서비스 경계(A service boundary): 에이전트의 표현을 빌리자면, 어차피 지금은 모두 하나의 컨테이너 안에 있기 때문에 하나로 합쳐버림.
• 가치가 높은 테스트(The high-value tests): 쉬운 테스트들은 작성하면서 정작 중요한 테스트들은 건너뛰었으며, 이를 겉으로 드러내어 말하지 않음.

이 중 어느 것도 악의적인 의도는 아니었습니다. 에이전트는 모든 삭제 작업에 대해 그럴듯한 근거를 가지고 있었으며, 바로 그 점이 에이전트를 위험하게 만듭니다. 에이전트가 생략하기로 선택하는 부분은 스스로 논리를 펼칠 수 있는 부분들이기에, 단순히 변경 사항(diff)을 스캔하며 "이게 맞아 보이나요?"라고 묻는 방식으로는 이를 잡아낼 수 없습니다. 그것은 언제나 맞아 보이기 때문입니다.

해결책 (The Fixes)

• 계획을 채팅창에서 꺼내 디스크에 저장했습니다. 계획 파일(Plan files), 추적 테이블(tracker tables) 등을 활용합니다. 이제 의도와 결정 사항은 테스트 실행이 어긋나는 순간 사라져 버리는 대화 속에 머물지 않고 파일에 기록됩니다. 이는 가설이 아닙니다. 한 번은 계획이 오직 채팅창에만 존재했기 때문에 세션 도중에 전체 계획을 통째로 잃어버린 적도 있습니다.
• 검토 본능을 게이트(gates)로 전환했습니다. 작업이 반드시 통과해야 하는 루프를 만들었습니다: 계획 수립 $\rightarrow$ 계획 검토 $\rightarrow$ 구현 $\rightarrow$ 그 후 컨벤션(conventions), 보안, 그리고 테스트 게이트를 거쳐야만 무엇인가가 배포됩니다.
• AI를 기여자(Contributor)로 관리했습니다. 제가 인간 팀을 운영하던 방식을 모방하도록 의도적으로 설계한 것은 아니었습니다. 자연스럽게 나타난 결과였습니다. 그러다 문득 이것이 제가 항상 유지해 온 검토 문화와 동일하며, 제가 함께 일했던 그 어떤 주니어 개발자보다 빠르고 훨씬 더 협조적인 기여자에 맞춰 재구축된 것임을 깨달았습니다.

모든 도구보다 더 중요했던 단 하나의 상시 지침은 바로 **"나에게 이의를 제기하라(challenge me)"**였습니다. 단순히 제가 요청하는 대로만 하지 마십시오. 만약 제가 요청하는 내용이 나중에 문제가 될 것 같다면, 구현하기 전에 미리 말해 주십시오. 에이전트는 당신이 명령하지 않는 한 반박하지 않습니다. 하지만 훌륭한 엔지니어는 요청받지 않아도 그렇게 합니다.

돌파구 (The Unlock)

한동안 저는 인사이트 보고서(insights report)를 실행조차 하지 않았습니다. 제가 다루고 싶지 않은 방해 요소라고 생각했기 때문입니다. 그러던 어느 날 그냥 실행해 보았는데, 그것이 제 작업 방식을 바꾸어 놓았습니다. 보고서는 매우 직설적이었습니다. 무엇이 잘 작동하고 있는지, 무엇이 저를 저해하고 있는지, 그리고 두 가지 모두에 대한 구체적인 제안을 담고 있었습니다. 그다음 도구는 그 피드백을 바탕으로 실행할 수 있도록 도와주겠다고 제안했습니다. 저는 수락했습니다.

제가 내린 최고의 결정은 그 개선 사항들을 별도의 독립된 프로젝트로 분리하여 진행한 것이었습니다. 모두가 기술(skills), 명령(commands), 에이전트(agents)에 대해 이야기하며 각자의 것을 게시하고 있었고, 솔직히 말해서 에이전트가 경로를 벗어나지 않게 유지하는 것만으로도 고군분투하던 저에게는 조금 위협적으로 느껴졌습니다. 그 툴킷(toolkit) 프로젝트가 AI와 효과적이고 효율적으로 협업할 수 있는 문을 열어주었습니다.

그래서 제가 여러분께 드리는 조언은 그냥 일단 시작하라는 것입니다. 실제 워크플로 (workflow)에서 AI를 사용해 보세요. 그러면 진행하면서 스스로 방법을 찾아낼 수 있을 것입니다. 먼저 교육을 받거나 학습을 위해 별도의 시간을 할애할 필요는 없습니다. 코드를 작성한다면, AI 기능이 활성화된 IDE를 열고 AI와 함께 코딩을 시작하세요. 나머지는 자연스럽게 자리를 잡을 것입니다.

현재 (The Now)

오늘날 저는 타이핑을 거의 하지 않습니다. 요구사항을 전달하고, 명확히 하며, 계획을 반복적으로 다듬으면, 에이전트가 빌드(build)를 수행합니다.

솔직히 말씀드리면, 제가 구축한 시스템 없이 작업하는 것보다 속도가 더 빠른 것은 아닙니다. 하지만 훨씬 더 효율적입니다. 게이트(gates)와 체크(checks) 과정에는 실제 시간이 소요됩니다. 하지만 제가 얻는 결과물은 실제로 사양(spec)에 부합하며, 새벽 2시에도 디버깅(debug)할 수 있을 만큼 제가 충분히 이해하고 있는 시스템입니다. 저는 의도적으로 속도를 충실도(fidelity)와 맞바꿨습니다. 일정 수준의 시니어(seniority) 단계에 이르면, 그것이 바로 여러분이 원하는 트레이드오프(trade-off)입니다.

미래 (The Future)

아직 클라우드 VM에서 실행되도록 밀어붙이지는 않았습니다. 주변에 더 많은 하네스(harness)가 필요하며, 그 단계에 도달하면 멀티 모델(multi-model) 방식이자 엔드 투 엔드(end to end)로 완전히 파이프라인화(pipelined)된 시스템을 만들고 싶습니다. 프레임워크(framework)의 개요는 잡아두었지만, 아직 그에 걸맞은 시간을 투자하지는 못했습니다. 만약 이 분야에 관심이 있거나 협업을 원하신다면 언제든 연락해 주세요.

교훈 (The Lesson)

이 중 그 어떤 것도 엔지니어링 (engineering)을 대체하지 않았습니다. 단지 위치가 옮겨졌을 뿐입니다. 이제 제 일과 중 타이핑을 하는 시간은 줄어들었습니다. 대신 대부분의 시간은 무엇이 실제로 '좋은 결과물'인지 결정하고, 빠르고, 수용적이며, 약간 과도하게 자신만만한 기여자가 타이핑을 하고 있을 때 이를 지탱해 줄 가드레일 (guardrails)을 구축하는 데 사용됩니다.

AI로부터 가장 많은 이득을 얻는 사람들은 AI를 가장 많이 신뢰하는 사람들이라고 생각하지 않습니다. 그들은 AI를 혼자 내버려 둘 수 없는 몇몇 지점들을 찾아내고, 그곳에 머무는 사람들입니다. 저에게 있어 그것은 먼저 수개월 동안 시행착오를 겪는 과정이었으며, 이것이 바로 이 포스트가 다루고자 했던 핵심 내용의 대부분이었습니다.

제품 (product)은 제가 시작한 이유였습니다. 방법론 (method)은 제가 계속 가져갈 것입니다.