창업 후 4년, 기획자가 실무에서 에이전트를 조종하는 9가지 코딩 원칙

저는 수년간 수많은 디자이너, 개발자들과 치열하게 협업해 온 '서비스 기획자'입니다. 기획자로서 늘 마주쳐야 했던 딜레마는 '내 머릿속의 아이디어와 해결책을 구현하려면 항상 개발자의 손을 빌려야 한다'는 점이었습니다.

하지만 AI 에이전트 코딩(Vibe Coding)의 시대가 열리면서 모든 것이 변했습니다. 이제는 개발자가 아닌 '기획자'인 제가 직접 에이전트와 코딩하며, 교육회사를 운영하는 동시에 고객사의 홈페이지를 구축하고 내부 자동화 시스템까지 세팅해 주는 비즈니스(셀렉트웨이)를 만들어가고 있기 때문입니다.

개발 지식이 완벽하지 않은 제가, 어떻게 프론트엔드부터 백엔드, DB까지 다루며 무너지지 않는 대규모 프로젝트를 운영할 수 있었을까요? 그 비밀은 고도의 코딩 스킬이 아니라, 다년간의 서비스 기획 경험을 바탕으로 AI 에이전트(안티그래비티)를 조종하는 저만의 확고한 '원칙과 셋팅 로직'에 있습니다.

기획자는 AI 에이전트와 페어 프로그래밍을 할 때 절대 무작정 "이거 만들어줘"로 시작해서는 안 됩니다. 기술 도입을 주저하는 수많은 기획자와 논테크(Non-tech) 직군을 위해, 현업에서 제가 '개발자가 아닌 기획자의 관점'으로 철저하게 지키는 9가지 문제해결 방식을 공유합니다.

1. 작은 실험에서 시작한다. 되는지 보고 개선한다.

기획자들은 상상력이 뛰어납니다. 처음부터 너무 거대한 청사진을 그리는 일들이 흔합니다. 놀랍게도 사내에서 아이디어를 처음 기획할 때 그리고 마지막에 개발자에게 실제 전달되는 문서의 범위는 큰 차이가 있습니다. 어떤 기획도 결국에 쪼개면 수백장의 기획서로 탈바꿈 되는데요. AI와 개발을 할 때는 아주 작은 단위의 '성공 경험'부터 만들어야 합니다. 개발자가 기능 하나 하나를 만들어본다고 생각해 보면서 아주 작지만 핵심 기능에서 출발을 합니다.

1. 실제 프로젝트 적용: 마케팅을 위한 랜딩 페이지 자동화 시스템을 만들어 보겠습니다. 저는 처음부터 거대한 DB 연동을 지시하지 않았습니다. 가장 단순한 디자인을 하나 만들고, 일단 하드코딩으로 내용을 채웁니다. 눈에 보이는 구성과 내용이 만들어지고, 간단하게 Netlify 나 로컬에서 배포를 해봅니다. 이 과정은 몇 분만에 진행되는 '작은 실험'입니다. 일단 화면이 원하는 대로 그려진 후에야 어떤 데이터를 입력하고 수정할 수 있게 할지, 또는 데이터베이스를 연결해서 자동화할지 그 다음에 개선을 해나갑니다. 또는 다른 사례로 이메일 자동화를 생각해봅니다. 일단은 어떤 방식이든 가장 빠르고 비용이 저렴하게 해결할 수 있는 방법을 선택합니다. SMTP로 '단 한 통의 메일이 발송되는가?'를 테스트(작은 실험)해보고 성공하면, 그 다음에 확장을 해나갑니다.

2. 기술 중심이 아닌 '문제 해결' 중심으로 접근한다

'이 기술로 무엇을 만들지?'가 아니라 기획자가 AI를 활용하는 과정에서는 '이 문제를 해결하려면 어떤 기술과 방법이 있지?'에서 더 많이 생각하게 됩니다. 매일 아침에 눈을 뜰 때마다 새로운 기술이 빗발칩니다. 그렇지만 어떤 기술을 선택하는 것이 아니라, 무엇을 해결하고 싶은지를 생각해보며 해결 방안을 찾아나갑니다.

1. 실제 프로젝트 적용: 랭체인, 오픈클로, 자연어 처리.. 무수히 많은 키워드를 먼저 공부하려고 접근하지 않았습니다. 공부에 매몰되다보면 어느 순간 목표나 목적은 사라지고, '어려워'라며 포기하게 됩니다. 이 부분에서는 어떤 팀이나 커뮤니티, 조직에 속해 있는 것이 좋습니다. 그러면 우리는 무수히 많은 문제들을 마주치게 되거든요. "홍보용 사이트를 만들다보니 똑같은 작업을 여러번 반복하네. 이걸 자동화하고 싶은데 어떻게 해야 하지?' 라고 먼저 생각하고, 가장 효율적이고 빠른 방법부터 시도해 봅니다. 모델부터 새로 만드냐고요? 아니요. 그것보다는 "구글 제미나이(Gemini) 모델부터 붙여서 테스트해볼까?"라는 생각으로 접근을 먼저 했던 점이지요. 이것이 가장 중요한 팁이자 문제해결 중심의 코딩입니다.

3. 체크리스트와 플레이북(Playbook) 작성: "모든 과정은 문서로 룰을 정해"

AI를 활용해서 하루종일 코딩하는데 점점 만드는 페이지도 많아지고 코드도 복잡해집니다. 사람도 내가 어제 작성했던 기획서를 다시보면 헷갈리는 것처럼, AI도 약점이 있습니다. 바로 컨텍스트(맥락)가 휘발되는 경우입니다. 다양한 대안책들이 나오고 있지만, 여전히 종종 AI는 내가 실수했던 것을 여러번 번복하기도 합니다. 프로젝트가 커질수록 나조차도 내가 어디까지 만들었는지 알기 어려워집니다. "우리가 지금까지 뭘 합의했지?"라는 규칙을 AI에게도, 스스로에게도 각인시키기 위해 룰을 문서로 통합합니다.

1. 실제 프로젝트 적용: 기업 홈페이지를 만드는 과정에서 마음에 드는 디자인이 나올 때까지 시행착오를 수십번 겪습니다. 수십 장의 컨셉과 디자인 시스템, 디자인 에셋을 만들기 위한 프롬프트를 Design_playbook.md로 문서화 해달라고 요청합니다. 그리고 추후에 이 문서를 활용해서 다음 번 홈페이지 작업은 더 높은 퀄리티로 작업할 수 있게 기준이 되는 룰을 정해 놓습니다.

4. 실패한 것을 다시 반복하지 않도록: 성공/실패 케이스 정리

AI를 활용해도 수백번의 오류와 실패를 경험합니다. 이때 일희일비하지 않습니다. 또 오류가 났다고 "고쳐줘" 한마디로 끝내선 안 됩니다. 왜냐하면 내일 지나면 이 삽질 과정은 내 머릿 속에서도 점점 희미해 지거든요. 나도 배우고 성장해야하고 AI도 기록한 내용을 봐야합니다.

1. 실제 프로젝트 적용: 구글 Gmail 플랫폼과 SMTP로 이메일 자동화(더밀크 자동화 로직)를 세팅할 때 겪었던 오류들(Google OAuth 토큰 이슈, 앱 비밀번호의 불필요함 등)을 전부 모아 문서로 요청했습니다. 구글 안티그래비티에서는 '아티팩트'라고 하는 형태로 (마치 클로드의 아티팩트처럼) 문서를 체크리스트도 만들어주고, 도식 이미지도 만들어서 문서에 정리해 줍니다. 문서 가이드를 만들고 정리하다보면, 그 중에 하나의 블로그 글이 나오기도 합니다. 내가 헤맸던 리스크가 회사와 팀의 자산이 되게끔 즉시 문서로 갈무리합니다.

5. 기능 개선이 주는 영향 확인: 프론트, 백엔드, DB 등 임팩트 분석을 제안받기

점점 복잡해지는 프로젝트, 새로운 기능을 붙이다가 기존 서비스가 망가지는 것만큼 두려운 일은 없습니다. 무작정 코드를 고치기 전, 항상 AI에게 이 변화가 기존 시스템에 어떤 영향을 끼칠지 물어보고 확인 후 승인합니다. 이 변화가 시스템 전체에 어떤 '연쇄 작용'을 일으킬지 AI에게 분석 보고서를 써달라고 요청합니다.

1. 실제 프로젝트 적용: 기존 교육 서비스에서 교육 수강생 DB를 관리하는 파이어베이스(Firebase) 프로젝트를 다른 곳으로 마이그레이션(이동)할 때, "그냥 옮겨줘"라고 하지 않았습니다. "이 과정에서 어떤 임팩트(위험성)를 미치는지 분석해서 가장 안전한 아키텍처를 추천해줘"고 요구한 뒤 코딩을 시작했습니다.

6. 빠르게 테스트 주소로 배포하고 테스트 후 합친다.

본 서버에서 이것저것 만지다 종종 잘 되던 서비스가 오류가납니다. 만약 고객이 사용 중에 접속이 끊기는 건 최악의 장애입니다. 대규모 서비스라면 더 철저하게 관리하겠지만 작다고해서 무시할 수는 없습니다. 처음부터 배포는 어떻게 하는지, Github은 어떻게 사용하는지 다 알고 시작했다면 좋겠지만, AI코딩을 하는 기획자 중에 개발지식을 모두 갖추고 시작하는 사람은 흔치 않습니다. 대신 기획자가 더 잘할 수 있는 부분도 있습니다. 원래 현업에서 하던 것처럼 테스트를 꼼꼼히 하고 합치는 거죠.

1. 실제 프로젝트 적용: 새로운 기능이나 테스트용 서비스가 나온다면, 기존 페이지에 바로 덮어쓰지 않고 안전하게 테스트할 수 있는 환경을 먼저 구축해달라고 합니다. Github을 이해하고 있다면 브랜치를 아예 새로 파거나, 또는 배포할 때도 본체 서비스에 배포하지 않고, 다른 주소나 프로젝트 환경에서 분리해 배포합니다. 테스트를 충분히 한 후 그 다음에 병합합니다.

7. 비즈니스 가드레일 셋팅: "수익화 안 될 것 같으면 날 말려줘"

코딩과 관련된 부분만 이야기 하지 않습니다. AI로 뭘이든 뚝딱 만들 수 있게 되면 처음에 즐겁습니다. 잔뜩 신 기술에 취해 '돈 안 되는 것'을 개발하는 데 시간을 쏟기 십상입니다. 저는 창업 후 스타트업을 운영하고 있기 때문에, 쓰고 싶은 만큼 AI를 쓸 수 있지만 그것은 곧 회사 입장에서는 손해이기도 합니다. 종종 정신 차리고 보면, 원래 하려던 일이 아닌 일을 몇 시간씩 붙잡고 있기도 합니다. 그래서 에이전트를 하나 만들어 둡니다.

1. 실제 프로젝트 적용: 안티그래비티 초기 셋팅 프롬프트에 "우리의 비즈니스 모델(교육, B2B 웹사이트 구축 솔루션)을 인지해. 내가 비효율적이거나 본질적인 수익 창출과 무관한 기능을 개발하려 하면 네가 적극적으로 제동을 걸고 말려야 해"라고 선언합니다. 또는 에이전트를 하나 만들어두고 중간 중간에 내가 해야할 업무를 신랄하게 지적해주도록 해두었습니다. 무조건 "Yes"만 외치는 코더가 아니라 객관적인 시각으로 피드백하는 비즈니스 파트너로 만든 것입니다.

8.하고 있는 것과 완료 된 것들을 체크리스트로 관리

구글 안티그래비티를 사용하는 환경에서는 동시에 여러 에이전트를 돌릴 수 있습니다. 그러면 내 머릿 속에서 해결해야할 문제들도 문어발처럼 늘어납니다. 여러 프로젝트가 동시에 돌아갈 때는 어느 로직까지 구현되었는지 파악하는 메타 인지가 중요합니다. 기획자가 어떻게 모든 개발 환경과 상황을 이해하겠어요. 내가 부족할 수 있다는 것을 겸허하게 받아들이고, 정확하게 진도를 체크해나가는 문서를 요청합니다.

1. 실제 프로젝트 적용: 자동화 프로세스나 배포 과정을 혼자 기억하지 않고, automation_checklist.md 문서를 만들어 모든 Task를 나열해달라고 합니다. 하다보면 프로젝트마다 여러 기능별, 상황별 문서들이 점점 늘어나기 시작합니다. 체크리스트를 요청하면 체크리스트를 만들어 에이전트가 알아서 진행된 것과 진행 중인 것을 표시해 줍니다.

9. 궁금한 것은 무조건 물어보고 인사이트로 정리

기획자로써 얕은 지식(주먹구구식 개발)으로 AI에게 코딩을 시키면 스파게티 코드가 됩니다.

1. 실제 프로젝트 적용: 데이터 분석 자동화 시스템을 열심히 개선해나가고 있었습니다. 중간에 질문해봅니다. "이 방식 말고, 대기업들이 적용하는 시스템이나 방식은 뭐야? 공식적인 용어나 아키텍쳐는 어떻게 사용해? 무엇이 표준이야?" 대부분의 기술은 선도기업들의 사례와 표준들이 있습니다. 내가 사용하는 나만의 언어나 용어가 아니라, 시장에서 정말 통하는 표준 용어와 기술을 비교해봅니다.

마치며: AI 시대의 기획자는 '도시 계획가'다

AI 에이전트를 다룰 때 기획자의 진짜 무기는 '코드를 잘 아는 것'이 아닙니다. 그럴려면 엔지니어가 되는 것이 맞겠지요.

기획자가 AI를 활용하게 되면 엄청난 무기를 갖게 되는 것은 사실입니다. 하지만 만들고 개발하다보면 어느 순간 비즈니스 목표나 가치가 멀어지기 십상입니다. 비즈니스를 잃지 않도록 선을 긋고(7번), 문서로 룰을 정비하며(3번, 8번), 전문가의 워크플로우를 배우고(9번), 안전하게 테스트하여 사고를 예방하면서(5번, 6번) 프로덕트를 만드는 것이 좋습니다. 어떻게 요즘 같은 시대에서 AI를 활용해 내 회사와 고객의 문제를 해결할 수 있는지 고민하는 기획자분들에게 제 방법론이 작은 플레이북이 되기를 바랍니다.