AI 코딩, 어떻게 하면 더 잘할 수 있을까

같은 AI 코딩 도구를 쓰는데, 어떤 사람은 하루 만에 기능 하나를 뚝딱 만들고, 어떤 사람은 일주일째 헤매고 있어요. 왜 그럴까요? 도구가 달라서? 모델이 달라서? 아니에요. 방식이 달라서입니다.

저도 처음엔 후자였어요. AI한테 '이거 만들어줘'라고 하고, 에러 나면 또 물어보는 식이었죠. 그러다가 어느 날 꽤 긴 시간을 디버깅에 쓰고 있더라고요. AI가 만든 코드라 전체 구조 파악이 덜 돼서 원인 찾기가 쉽지 않았어요.

그때 방식을 바꿨어요. AI를 '만능 코드 생성기'가 아니라 '내 팀원'처럼 대하기로요. 요구사항을 명확히 정의하고, 체계적으로 업무를 나누고, 결과물을 꼼꼼히 검토하기 시작했어요. 그랬더니 확실히 달라지더라고요.

오늘은 제가 직접 시행착오를 겪으며 찾은 AI 코딩 방법론을 공유할게요. PRD 기반 워크플로우, Sub Agent 활용법, 그리고 개발자에서 설계자로의 마인드셋 전환까지.

구체적으로 뭐가 문제였나

좀 더 구체적으로 말해볼게요. 한번은 PG사 결제 연동을 하고 있었어요. 기본적인 요구사항은 전달했고, 코드도 잘 나왔어요. 그런데 나중에 테스트하다 보니 특정 상황에서 결제가 중복 처리되는 문제가 생기더라고요.

원인을 찾아보니, 결제 완료 알림이 여러 번 올 수 있는 상황에 대한 처리가 빠져 있었어요. 생각해보면 당연한 건데, 요구사항에 명시하지 않았으니 AI 입장에서는 알 수가 없었던 거죠. 이런 엣지 케이스들을 미리 정리해서 전달했으면 처음부터 잡을 수 있었을 거예요.

그때 알게 됐어요. AI는 내가 말한 것만 알아요. 당연한 것 같은 요구사항도 명시적으로 말해줘야 해요. 팀원한테 일 시킬 때 요구사항 문서 없이 '그냥 알아서 해줘'라고 하면 결과물이 이상하게 나오잖아요. AI도 마찬가지예요.

문서 기반 워크플로우: PRD - Checklist - Result

제가 찾은 첫 번째 해법은 문서 기반 워크플로우였어요. 핵심은 간단해요. 코드 작성 전에 PRD를 확실히 만들고, 그 이후는 AI에게 맡기는 거죠.

PRD가 전부예요. 이 워크플로우에서 사람이 진짜 해야 하는 건 PRD를 완성하는 것뿐이에요. 그것도 처음부터 완벽하게 쓰는 게 아니라, AI와 대화하면서 완성도를 올려가는 거죠.

아까 말한 결제 연동을 다시 해봤어요. 이번엔 다르게 시작했죠. 'PG사 결제 연동 PRD를 같이 만들자. 일단 뭘 결정해야 하는지 질문해줘.' 그랬더니 AI가 물어보기 시작해요. '단건결제인가요, 정기결제인가요?' '웹훅 실패 시 재시도 정책은요?' '결제 상태는 어떻게 관리할 건가요? 자체 DB인가요, PG사 API 조회인가요?' 이런 질문에 하나씩 답하면서 30분 만에 2페이지짜리 PRD가 완성됐어요.

PRD가 완성되면 나머지는 AI 몫이에요. PRD를 기반으로 Checklist를 만들게 하면, SDK 설치부터 API 엔드포인트 생성, 웹훅 핸들러 구현까지 작업 단위로 쪼개서 정리해줘요. 이 Checklist를 그대로 구현하게 하면 하나씩 체크해가며 코드를 만들고, 저는 중간중간 결과를 확인하면서 방향만 잡아주면 돼요.

Result 문서도 AI가 작성해요. 작업이 끝나면 'Result 문서 만들어줘'라고 하면 뭘 만들었는지, 어떤 기술적 결정을 내렸는지, 주의할 점은 뭔지를 정리해줘요. 이게 중요한 이유가 있어요. AI의 컨텍스트 윈도우는 언젠가 리셋되거든요. 대화가 길어지거나 새 세션을 시작하면 이전에 했던 얘기를 다 까먹어요.

Result 문서가 있으면 이 문제가 해결돼요. 다음에 같은 코드를 수정해야 할 때 '이 Result 문서 읽고 맥락 파악해'라고 하면, AI가 이전 작업의 의도와 결정 사항을 바로 이해해요. 팀원한테 공유할 때도 '저번에 뭐 했어?'가 아니라 문서 링크 하나 던지면 끝이고요. 프로젝트 문서화가 작업의 부산물로 자동으로 쌓이는 셈이에요.

정리하면 이래요. PRD는 AI와 함께 만들고, Checklist/코드/Result는 AI에게 맡긴다. 사람이 할 일은 PRD 대화할 때 방향 잡아주기, 중간 결과물 확인하기, 최종 코드 리뷰하기. 이 방식으로 바꾸고 나서 저는 '코드 짜는 시간'이 확 줄고 '설계하고 검토하는 시간'이 늘었어요. 그게 제 경험이 가장 잘 쓰이는 방식이더라고요.

Sub Agent: 전문가 팀 운영하기

두 번째로 효과가 컸던 건 Sub Agent 활용이에요. Claude Code에서는 마크다운 파일로 전문가 에이전트를 정의할 수 있어요. 저는 이걸 '나만의 전문가 팀을 꾸리는 것'처럼 생각해요. 프론트엔드 전문가, 백엔드 전문가, 블로그 작가 등 역할별로 에이전트를 만들어두고, 필요할 때 적합한 팀원을 불러서 일을 맡기는 거죠.

예를 들어볼게요. 새 기능을 만들 때 저는 이렇게 해요. 먼저 메인 에이전트와 PRD를 완성하고, '이제 프론트엔드 전문가 불러와서 UI 만들어'라고 하면 프론트엔드 에이전트가 작업을 시작해요. UI가 완성되면 '백엔드 전문가 불러서 API 연결해'라고 하고요. 각 에이전트는 자기 분야의 컨벤션과 맥락을 이미 알고 있어서, 매번 처음부터 설명할 필요가 없어요.

이렇게 나누면 또 다른 장점이 있어요. 각 에이전트끼리 결과물을 참조할 수 있어요. 프론트엔드 에이전트가 만든 컴포넌트 구조를 백엔드 에이전트가 보고 거기에 맞춰서 API 응답 형식을 설계하기도 해요. 마치 실제 팀에서 프론트엔드 개발자가 만든 화면을 보고 백엔드 개발자가 API를 맞추는 것처럼요.

처음엔 '굳이 나눠야 하나?' 싶었어요. 하나의 AI한테 다 시키면 안 되나? 그런데 써보니까 확실히 달라요. 하나의 AI에게 프론트엔드, 백엔드, 인프라를 다 시키면 대화가 길어지면서 앞에서 한 얘기를 까먹는 경우가 있어요. 에이전트를 분리하면 각자 자기 도메인의 맥락만 유지하니까 이런 문제가 줄어들어요. 그리고 에이전트마다 프로젝트 컨벤션을 미리 학습시켜 놓을 수 있어서, 매번 '우리 프로젝트는 이렇게 한다'고 설명하지 않아도 돼요.

처음 세팅하는 데 10~30분 정도 걸려요. 각 에이전트의 역할을 정의하고, 프로젝트 구조와 컨벤션을 시스템 프롬프트에 넣어야 하니까요. 하지만 한번 해두면 계속 쓸 수 있고, 프로젝트가 복잡해질수록 효과가 커져요. 혼자 다 하려고 하면 한계가 있는데, 팀을 꾸려두면 일이 훨씬 빨라지더라고요.

마인드셋 전환: 개발자에서 설계자로

도구나 워크플로우보다 더 중요한 게 있어요. 바로 마인드셋입니다. AI 코딩을 잘하려면, 자신을 '코드를 직접 짜는 개발자'가 아니라 '팀을 이끄는 설계자 또는 개발 팀장'으로 생각해야 해요.

팀장이 하는 일을 생각해보세요. 요구사항을 정의하고, 업무를 분배하고, 결과물을 검토하고, 방향을 조정하죠. 직접 코드를 짜는 시간보다 설계하고 검토하는 시간이 더 많아요. AI 코딩도 마찬가지예요. 제가 직접 for문을 짜는 게 아니라, AI한테 '이런 조건으로 데이터를 필터링하는 함수를 만들어'라고 지시하고, 나온 결과를 검토하는 거죠.

“Claude Code를 쓰면서 코딩 모드보다 리뷰 모드에 있는 시간이 더 많아졌는데, 이게 정확히 제 경험이 가장 잘 활용되는 방식인 것 같아요. Claude Code는 좋은 결과물이 어떻게 생겼는지 아는 숙련된 개발자에게 가장 효과적이에요.”

이 마인드셋이 잡히면 AI 코딩이 훨씬 편해져요. 예전에는 AI한테 어디까지 맡기고 뭘 직접 해야 할지 애매했는데, 지금은 '내가 관리하는 팀원이 여러 명 더 생긴 것'처럼 느껴져요. 단순 반복 작업은 AI한테 맡기고, 저는 더 중요한 설계와 의사결정에 집중할 수 있으니까요.

저는 코드를 꼭 읽어요

제가 지키려고 하는 습관 하나를 공유할게요. AI가 짠 코드를 읽고 이해하는 것이에요. 직접 안 짜도 괜찮은데, 뭐가 어떻게 돌아가는지는 파악하려고 해요. 앞에서 말한 결제 중복 버그도, 코드를 꼼꼼히 읽었으면 더 빨리 발견했을 것 같거든요.

코드를 읽다 보면 AI가 이상한 결정을 내린 부분이 보일 때가 있어요. '왜 여기서 이런 방식을 썼지?', '이건 우리 프로젝트 컨벤션이랑 안 맞는데?' 이런 것들이요. 이걸 그때그때 잡으면 나중에 기술 부채가 덜 쌓이더라고요. 모르는 부분이 있으면 AI에게 '이 부분 설명해줘'라고 물어보면 되고요.

코드 읽는 시간이 아까워 보일 수 있는데, 제 경험상 이 시간을 아끼면 나중에 더 많은 시간이 들더라고요. 그래서 저는 AI가 코드를 만들면 한 번은 처음부터 끝까지 읽으려고 해요. 이해가 될 때까지 넘어가지 않고요. 조금 번거롭지만, 저한테는 이게 결국 시간을 아끼는 방법이었어요.

툴 추천: 왜 Claude Code인가

여러 AI 코딩 도구를 써봤어요. Copilot, Cursor, Claude Code, Antigravity. 각각 장단점이 있는데, 2026년 1월 기준으로 제가 가장 많이 쓰는 건 Claude Code예요.

Claude Code가 좋은 첫 번째 이유는 컨텍스트 윈도우가 크다는 거예요. 20만 토큰까지 지원하는데, 덕분에 프로젝트 전체 맥락을 이해시킬 수 있어요. Copilot이나 기존 도구들은 현재 파일 위주로 보는데, Claude Code는 여러 파일에 걸친 구조를 파악해요. '이 함수 수정하면 저쪽에 영향 가는데'라는 걸 알아요.

두 번째는 터미널 네이티브라는 거예요. IDE에 플러그인으로 붙는 게 아니라 터미널에서 직접 돌아가요. 이게 왜 좋냐면, 터미널을 여러 개 열면 그만큼 에이전트를 동시에 실행할 수 있어요. 한쪽에서는 프론트엔드 작업하고, 다른 쪽에서는 백엔드 작업하고. 병렬로 돌리니까 작업 속도가 확 빨라져요.

세 번째는 앞서 말한 서브에이전트 기능이에요. 2025년 7월에 추가된 기능인데, 이게 있어서 전문가 팀 운영 방식이 가능해진 거예요. Cursor도 좋은 도구지만, 이런 수준의 에이전트 커스터마이징은 아직 안 돼요.

물론 Claude Code가 만능은 아니에요. 월 $20~$200 정도 드는데, 사용량이 많으면 비용이 꽤 나와요. 그리고 터미널 기반이라 처음 진입 장벽이 있고요. 간단한 자동완성만 원하면 Copilot이 더 나을 수 있고, GUI를 선호하면 Cursor가 더 편할 수도 있어요.

정리: 왜 어떤 사람은 잘하고 어떤 사람은 못할까

처음에 던진 질문으로 돌아가볼게요. 같은 AI 코딩 도구를 쓰는데 왜 결과가 천차만별일까요? 제가 느낀 건 AI를 도구로 보느냐, 팀원으로 보느냐의 차이예요.

도구로 보면 '이거 해줘' 하고 던지게 돼요. 결과물이 이상하면 도구 탓을 하고요. 팀원으로 보면 요구사항을 명확히 전달하고, 업무를 체계적으로 나누고, 결과물을 검토하게 돼요. 팀원이 실수하면 '왜 이렇게 됐지?'를 같이 고민하고요.

1. 문서 먼저: 코드 전에 PRD를 AI와 함께 작성하세요
2. 전문가 팀 구성: Sub Agent로 역할을 나누세요
3. 마인드셋 전환: 개발자가 아니라 설계자/팀장으로 생각하세요
4. 코드 읽기: AI가 짠 코드를 읽고 이해하는 습관을 권장해요
5. 도구 선택: 자기 스타일에 맞는 도구를 고르세요

새 도구가 나왔다고 무조건 뛰어들 필요 없어요. 도구보다 중요한 건 방식이에요. 좋은 방식을 찾으면 AI는 든든한 팀원이 돼요. 저도 아직 배워가는 중이에요. 더 좋은 방법을 찾으면 또 공유할게요.