누군가에게 알려주기 보다는 나 스스로 정리 하며 언젠가 다시 사용할 때를 대비하는 글을 작성할것이다.
지난 포스팅에서 도커(Docker)를 활용해 인프라라는 무대를 다 지어놨으니, 이제 바로 코딩이라는 연기를 시작할 줄 알았다. 하지만 막상 키보드에 손을 올리니 망설여졌다.
솔직히 말하면, 나는 이 프로젝트에 들어가는 모든 기술과 언어에 통달한 전문가가 아니다. 세상에 공부할 건 너무 많고, 내 리소스는 한정적이다. 그런데도 내가 대용량 B2B 푸시 솔루션이라는 거창한 목표에 도전할 수 있는 이유는 명확하다. 나에게는 Claude Code라는 아주 유능한 '팀원'이 있기 때문이다.
이번 4편에서는 그 유능한 팀원을 제대로 부리기 위해, 내가 그 어느 때보다 문서 작성과 설계에 집착했던 과정을 적어보려 한다.
언어는 도구일 뿐, 핵심은 설계(Design)다
많은 사람이 "어떤 언어로 짤까?"를 고민할 때, 나는 "어떻게 가치를 설계할까?"를 더 고민했다. AI와 협업해 본 사람이라면 알 것이다. 내 의도가 흐리멍덩하면 AI가 뱉어내는 코드도 결국 쓰레기가 된다는 것을.
1인 개발자로서 AI에게 코드를 맡긴다는 것은, 내가 '타이피스트'가 아닌 '아키텍트'가 되어야 함을 의미한다. AI가 내 의도를 100% 이해하고 버그 없는 코드를 내놓게 하려면, 코드를 한 줄도 치기 전에 이미 문서 위에서 시스템이 완벽하게 돌아가고 있어야 한다.
AI 수석 설계자들과의 티키타카
이번 설계 과정에서는 Gemini와 Claude를 내 팀원으로 고용했다.
- Gemini와는 거시적인 비즈니스 로직을 논의했다. "B2B 푸시 서비스라면 어떤 기능이 필수적이지?"라는 질문을 던져 PRD(제품 요구사항 문서)의 뼈대를 잡았다.
- Claude는 그 뼈대에 살을 붙이는 역할을 맡겼다. "이 기능이 저 요구사항이랑 충돌하지 않아??"라고 끈질기게 물으며 74개의 요구사항을 하나하나 검증하고 다듬었다.
이렇게 탄탄하게 다져진 요구사항 정의서와 기능 명세서는 이제 Claude Code가 한 치의 오차도 없이 코드를 구현해낼 수 있는 '완벽한 지도'가 되었다.
미래의 나, 그리고 AI를 위한 배려
내가 설계 문서와 씨름하며 유난을 떤 이유는 결국 두 가지다.
- 미래의 나를 위해: 나중에 내가 이 코드를 고칠 때 과거의 나를 원망하지 않도록. (내가 나를 보좌하는 셈이다.)
- AI를 위해: AI가 맥락을 정확히 짚어 수준 높은 결과물을 내놓을 수 있도록 '정답지'를 미리 만들어두는 과정이다.
결국 언어는 도구일 뿐이다. 진정한 개발의 가치는 그 도구를 어떻게 휘두를지 결정하는 설계(Design)와 흐름(Flow)에 있다는 것을 이번 기회에 다시 한번 느꼈다.
마치며
설계도는 이제 완벽하게 준비되었다. 이제 이 지도를 들고 본격적으로 '구현'이라는 실전에 들어갈 차례다. 과연 이 치밀한 설계도가 실제 코드에서는 어떻게 꽃을 피울지, 다음 화부터 하나씩 풀어보겠다.
참고자료
기타
당연 틀린 부분 지적은 감사하나 비난은 정중하게 사양하겠다.
