AI와 함께 코딩하는 법: 계획·워크트리·리뷰까지 한 번에 정리
AI 코딩, 왜 잘 쓰는 사람만 빨라지는가
요즘 개발 커뮤니티를 보면 같은 도구를 쓰는데도 속도 차이가 극단적으로 벌어집니다. 누구는 AI 덕분에 하루 만에 사이드 프로젝트를 올리고, 누구는 채팅창에 프롬프트만 던지다 코드 정리도 못 끝냅니다. 차이는 모델의 성능보다, 인간이 설계를 얼마나 직접 쥐고 있는가에 가깝습니다.
이 개발자는 Cursor 같은 AI 에디터를 쓰면서도, 코드 자체보다 워크플로를 먼저 다듬습니다. 새 프로젝트를 시작할 때도 "뭐 만들까"보다 "어떻게 만들지"부터 AI와 상의합니다. 제 기준에서는 이 관점 전환이, 요즘 말하는 '에이전틱 코딩'의 핵심에 가깝습니다. 모델이 쓰는 토큰보다, 사람이 설계하는 루틴이 훨씬 큰 차이를 만듭니다.
재미있는 지점은, 이 방식이 비개발자용 '마법 지팡이' 같은 스타일과는 정반대라는 점입니다. 코드를 모르면 쓰기 더 어렵습니다. 이미 코드를 잘 아는 사람이, 반복 작업을 떼어내 AI에게 넘기기 위해 필요한 구조를 만들어 두는 방식입니다. 저라면 이 흐름을 "코드 작성을 외주 주는 것"이 아니라 "코드 작업 환경을 설계하는 것"에 가깝게 이해하겠습니다.
빠른 모델보다 중요한 것, 플로우의 구조
사람들이 주로 집착하는 부분은 어떤 모델이 더 똑똑한가, 어느 회사가 더 싸게 해 주는가입니다. 이 글의 주인공은 정반대로 움직입니다. 계획 단계에는 비싼 모델을 쓰더라도, 실제 구현은 빠르고 싼 모델에 맡깁니다. 대신 처음에 아주 구체적인 plan.md를 함께 작성합니다.
이 계획은 기능 목록이 아니라, 어떤 파일을 만들고, 어떤 명령을 돌려 확인하고, 어떤 형식으로 결과를 남길지까지 들어간 "작업 각본"에 가깝습니다. 사람이 여기에 동의하고 나면, 그때부터는 에이전트가 그대로 수행합니다. 한국 개발 환경에서도 이 패턴은 그대로 통합니다. 팀장이 설계를 세밀하게 잡고, 구현은 주니어에게 맡기는 구조와 크게 다르지 않습니다.
AI를 위한 환경 세팅, 인간이 직접 해야 하는 이유
이 개발자는 프로젝트 초기 세팅만큼은 직접 손으로 합니다. 패키지 매니저 선택, 기본 디렉터리 구성, .env와 git 설정까지 사람이 먼저 잡습니다. 에디터가 자동으로 명령을 대신 실행해 줄 수 있지만, 초기 환경이 꼬이면 이후 에이전트가 아무리 똑똑해도 계속 오작동하기 때문입니다.
또 하나 흥미로운 습관은 Git worktree를 적극 활용한다는 점입니다. 같은 리포지터리에서 여러 작업 브랜치를 실제 디렉터리로 띄워, 서로 다른 모델에게 같은 계획을 실행하게 합니다. 이렇게 하면 Composer, Claude, Gemini가 같은 목표를 어떻게 다르게 구현하는지 비교할 수 있습니다. 국내에서 여러 벤더의 모델을 섞어 쓰려는 팀이라면, 이런 물리적인 분리 전략이 꽤 쓸 만한 실험 도구가 됩니다.
계획과 워크트리, 에이전트 시대의 새로운 기본기
AI 코딩이라는 말을 들으면 보통 "프롬프트 잘 쓰는 법"이 먼저 떠오릅니다. 그러나 여기서 핵심은 프롬프트보다 계획 파일입니다. 계획은 읽히기 위해 존재하고, 프롬프트는 소모되기 위해 존재합니다. 이 차이를 이해하면, 에이전트를 다루는 태도가 달라집니다.
코드는 버리고, 계획만 유지하는 사고방식
사람이 코드를 직접 짤 때는 한번 만든 코드를 어떻게든 살려 보려는 심리가 작동합니다. 수정에 수정이 붙고, 결국 기묘한 레거시가 됩니다. 반면 AI에게 구현을 맡기는 경우, 그 코드는 토큰 몇만 개의 결과물일 뿐입니다. 마음먹으면 통째로 버리고 처음부터 다시 만들 수 있습니다.
이 개발자는 실제로 그렇게 합니다. 복잡한 리팩터링이나 라이브러리 마이그레이션을 시킬 때, 한 번 시도해서 꼬이면 애써 고치게 하지 않습니다. 대신 "어디서 어떻게 틀렸는지"를 메모해 두고, 그 정보를 계획에 반영합니다. 그리고 아예 새 브랜치, 새 worktree를 만든 뒤, 개선된 계획을 기준으로 전체 구현을 다시 생성합니다. 코드가 아니라 계획을 자산으로 보는 시선입니다.
워크트리와 에이전트, '원격 주니어' 관리하기
워크트리 전략은 에이전트를 여러 명의 원격 주니어 개발자처럼 다루는 것과 비슷합니다. 각자 다른 브랜치와 디렉터리에서 자기 몫의 구현을 끝내고, 사람은 최종 결과만 검토해 선택합니다. 마음에 드는 버전이 있으면 그 브랜치만 메인에 머지하고, 나머지는 그대로 버립니다.
국내 개발 문화에서 이런 방식은 두 부류에 특히 유리합니다. 사이드 프로젝트를 많이 돌리는 1인 개발자, 그리고 새로운 스택을 팀에 도입하려는 리드 개발자입니다. 전자는 시간 대비 실험 수를 극단적으로 늘릴 수 있고, 후자는 "어떤 설계가 우리 코드베이스와 잘 맞는가"를 코스트 적게 비교해 볼 수 있습니다. 반대로, 코드 한 줄 한 줄을 손으로 컨트롤해야 직성이 풀리는 스타일이라면 이런 접근은 오히려 스트레스로 다가올 수 있습니다.
테스트와 코드 리뷰, AI를 '주니어 동료'로 쓰는 법
많은 사람이 놓치는 부분이 바로 이 대목입니다. AI가 코드를 쓸 수 있으니 테스트를 덜 해도 될 것 같다는 착각입니다. 실제로는 정반대입니다. 테스트와 타입 체크, 리뷰 프로세스를 만들어 줄수록 AI가 더 똑똑해집니다. 인간이 아니라 도구가 똑똑해지는 것이 아니라, 도구를 다루는 방식이 학습되기 때문입니다.
"이게 통과하면 성공"이라는 기준을 먼저 만든다
복잡한 프로젝트에서 에이전트가 고전하는 가장 큰 이유는, 무엇이 성공인지 모르는 상태에서 코드를 짜기 때문입니다. 이 개발자는 그래서 항상 "간이 벤치마크"를 먼저 만듭니다. 예를 들어 대규모 LLM 벤치마크 프로젝트에서는, 전체를 돌리면 몇 시간이 걸리니, 아주 단순한 도구 호출 테스트를 따로 떼어냅니다. 그리고 bun run dry-run 같은 명령으로 빨리 확인할 수 있게 합니다.
여기에 타입 체크를 강제하는 스크립트도 붙입니다. bun run tsc가 통과하지 않으면 실패로 간주하는 식입니다. 그리고 이 기준을 계획과 프롬프트에 그대로 적습니다. AI에게 "이 명령을 돌려, 실패 메시지를 읽고, 다시 수정해라"라고 말하는 셈입니다. 국내 현업 팀에서도 비슷한 패턴을 적용할 수 있습니다. 예전에는 사람의 감으로 보던 "대충 되는 것 같은데?" 수준을, 이제는 명령 몇 개로 객관적인 합격선을 정의하는 방향으로 바꾸는 것입니다.
코드 리뷰를 또 다른 AI에게 맡기는 이유
여기서 한 걸음 더 나아가, 이 개발자는 PR 리뷰까지 전용 AI 서비스에 맡깁니다. Cursor가 만든 코드라도, Graphite나 CodeRabbit 같은 리뷰 봇이 다시 검사합니다. 도구 호출 결과를 잘못 파싱했다든지, 타입 정의는 맞는데 초기화 타이밍이 미묘하게 어긋났다든지, 사람이 잘 못 보는 패턴을 집요하게 짚어냅니다.
제 기준에서는 이 단계가 "AI 코딩이 진짜로 쓸 만해지는 지점"입니다. 에디터 안의 에이전트, 별도의 PR 리뷰 봇, 그리고 사람이 보는 최종 검토까지 세 겹으로 엮일 때 비로소 안심하고 머지를 눌러도 됩니다. 한국 조직 문화에서는 여전히 사람 리뷰를 중시하는 곳이 많지만, 리뷰어의 피로를 줄이고, 사람이 더 의미 있는 논의에 집중하게 만드는 보조 도구로 본다면 도입 장벽이 훨씬 낮아집니다.
이 전략이 맞는 사람, 그리고 피해야 할 사람
AI 코딩이라는 말에 기대를 거는 사람은 많지만, 모두에게 같은 방식이 통하는 것은 아닙니다. 어떤 사람에게는 생산성을 폭발적으로 올려 주는 도구가 되지만, 어떤 사람에게는 더 복잡한 장난감으로 끝납니다. 중요한 것은 자신의 작업 스타일과 이 에이전틱 워크플로 사이의 궁합을 냉정하게 보는 일입니다.
누구에게 유리한가, 누구에게 의미가 없는가
이 방식이 특히 잘 맞는 사람은 두 유형입니다. 하나는 이미 한두 개 언어를 실무에서 쓰고 있는 개발자입니다. 반복적인 세팅과 리팩터링에 지쳤고, 설계와 실험에 더 시간을 쓰고 싶은 사람입니다. 다른 하나는 사이드 프로젝트를 즐기는 IT 직장인입니다. 퇴근 이후 짧은 시간에 여러 아이디어를 검증해야 하는 상황이라면, 계획과 워크트리, 리뷰 봇을 조합한 흐름이 강력한 레버리지가 됩니다.
반대로, 아직 프로그래밍 개념 자체가 낯선 초보자에게는 독이 될 수 있습니다. 도구는 코드를 만들어 내지만, 무엇이 좋은 코드인지 판단할 수 없기 때문입니다. 또, 회사 차원에서 자동화와 실험을 장려하지 않고, 여전히 "사수가 옆에서 보고 가르치는" 방식에 머무른 팀이라면 이런 세팅에 공을 들여도 조직 내에서 제대로 쓰이지 않을 가능성이 큽니다.
시작 전에 확인해야 할 현실적 제약과 첫 행동
에이전트 기반 워크플로를 도입하기 전에, 세 가지 현실을 먼저 계산하는 편이 좋습니다. 첫째, 에디터와 모델 구독 비용입니다. 요즘 기준으로는 Cursor 같은 도구 하나와 LLM API 약간을 합쳐도, 한 달 점심값 몇 번 수준이면 충분합니다. 다만 팀 단위로 쓰려면 계정 관리, 보안, 로그 남기기 문제를 함께 설계해야 합니다.
둘째, 코드베이스의 정리 상태입니다. 테스트가 거의 없고, 타입 정의도 엉망인 레거시 프로젝트라면 에이전트를 바로 투입하기보다는, 먼저 타입과 간단한 스모크 테스트부터 정리하는 편이 낫습니다. 셋째, 팀의 실험 문화입니다. 실패한 브랜치를 가볍게 버리고, 계획을 고쳐 다시 돌리는 사이클을 용인하는 문화가 있어야 합니다.
첫 행동은 의외로 단순합니다. 거창한 서비스가 아니라, 이 개발자가 만든 것처럼 "하나의 입력을 받아 세 개의 마크다운 파일을 남기는 작은 도구"부터 시작하는 것입니다. 예를 들어, 사내 문서 요약용 CLI, 팀 코드 스타일을 점검하는 간단한 체크 스크립트 정도가 좋습니다. 이 작은 성공 경험이 쌓이면, 한국 개발자들도 "AI가 코딩을 대신해 준다"는 피상적인 기대에서 벗어나, "AI와 함께 일하는 방식을 설계한다"는 다음 단계로 자연스럽게 건너갈 수 있습니다.
출처 및 참고 :
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.