AI 개발, 코드부터 들이대지 마세요: 보리스 테인의 클로드 코드 활용법에서 배운 것

2026-02-25 · 시리즈: AI

요즘 AI 코딩 도구 이야기가 정말 뜨겁습니다. 클로드 코드(Claude Code) 같은 녀석들은 개발자의 생산성을 혁신할 거라고 기대를 한 몸에 받고 있죠. 그런데 막상 실제로 써보면, 기대만큼의 결과가 안 나오거나 오히려 더 많은 시간을 낭비하는 경우가 많다고들 하십니다. 저도 처음에는 그랬거든요.

저도 이 문제를 어떻게 해결해야 하나 고민이 많았는데, 마침 보리스 테인(Boris Tane)이라는 분이 자신의 블로그에 올린 글을 보고 무릎을 탁 쳤습니다. 그분은 클로드 코드를 무려 9개월 동안 주 개발 도구로 사용하면서 자신만의 독특한 워크플로우를 정립했다고 하는데요. 그 핵심은 바로 ‘AI에게 코드를 쓰게 하기 전에, 개발자가 직접 검토하고 승인한 계획을 먼저 만들어라’는 겁니다.

이게 무슨 말인가 싶으시죠? 저도 처음엔 그저 ‘계획을 잘 세워야 한다’는 뻔한 이야기로 들렸습니다. 그런데 글을 자세히 읽어보니, 이분은 우리가 흔히 아는 계획과는 차원이 다른, 훨씬 더 깊이 있는 접근 방식을 사용하고 계시더라고요. 오늘은 그분의 통찰을 빌려, 제가 생각하는 AI 시대의 효과적인 개발 방법론에 대해 이야기해보려고 합니다.

흔히 하는 실수: 코드부터 들이대는 개발

대부분의 개발자들은 AI 코딩 도구를 이렇게 사용합니다. “이거 만들어줘”라고 프롬프트를 입력하고, AI가 뱉어낸 코드를 받아서 에러를 수정하고, 마음에 안 들면 다시 프롬프트를 수정해서 반복하죠. 좀 더 적극적인 분들은 복잡한 프롬프트 패턴을 짜서 대화 모드로 들어가기도 하고요.

하지만 이런 방식은 간단한 스크립트나 코드 조각을 만들 때는 괜찮을지 몰라도, 조금만 복잡해져도 금방 한계에 부딪힙니다. 저도 수없이 경험했던 일인데요, AI가 내놓은 코드는 뭔가 동작은 하는데, 제가 의도했던 아키텍처나 세부 로직과는 거리가 멀 때가 많았습니다. 결국 제가 다시 다 뜯어고치거나 처음부터 짜는 게 더 빠를 때도 있었죠. AI가 내놓은 코드를 고치느라 더 많은 시간을 쓰는 악순환이 반복되는 겁니다.

도대체 왜 이런 일이 생기는 걸까요? 제 생각에는 AI가 전체 맥락을 온전히 이해하지 못해서 벌어지는 문제도 있지만, 더 근본적인 이유는 개발자가 AI에게 ‘충분히 구체적인 생각의 재료’를 제공하지 않기 때문이라고 봅니다. 우리 머릿속에만 있는 ‘추상적인 계획’으로는 AI가 우리의 의도를 완벽히 구현해 줄 수 없는 거죠. 마치 건축가 없이 “집 하나 지어줘”라고 말하는 것과 비슷하다고 할까요?

코드 생성 전, ‘계획’이 핵심인 이유

보리스 테인님은 이 문제를 해결하기 위해 ‘계획 수립’과 ‘실행’을 철저히 분리합니다. 이게 핵심이에요. AI에게 코드를 쓰게 하는 건 가장 마지막 단계라는 겁니다. 그전까지는 AI를 ‘생각하는 도구’이자 ‘연구 보조원’으로 활용하는 거죠.

저는 이 부분이 정말 중요하다고 생각하는데요. AI가 아무리 똑똑해도, 결국 소프트웨어의 아키텍처와 핵심 로직은 ‘사람’인 개발자가 주도해야 합니다. AI에게 주도권을 넘겨주는 순간, 우리는 통제력을 잃게 되고, 결국 AI가 만들어낸 혼란스러운 결과물을 수습하느라 에너지를 낭비하게 됩니다.

AI를 효과적으로 사용한다는 건, AI에게 ‘똑똑하게 지시하는 방법’을 아는 것과 같다고 봅니다. 그리고 그 지시의 가장 기본은 바로 탄탄한 계획이죠. 계획이 확실하면 AI는 훨씬 더 적은 토큰(비용)으로도 훨씬 더 좋은 결과물을 만들어낼 수 있습니다. 이 얼마나 효율적인가요?

보리스 테인에게 배운 워크플로우의 첫 단추: 깊이 있는 ‘연구’

그렇다면 보리스 테인님은 어떻게 계획을 세울까요? 그분의 워크플로우는 크게 세 단계로 나뉩니다. 연구(Research) → 계획(Planning) → 구현(Implementation). 이 중에서 첫 단계인 ‘연구’가 정말 인상 깊었습니다.

많은 분들이 AI에게 “이 코드 문제점 찾아줘”, “이 기능 구현해 줘”라고 바로 지시하곤 하죠. 하지만 보리스 테인님은 AI에게 **‘가장 먼저 해당 코드베이스를 깊이 있게 이해하라’**고 지시합니다. 그것도 그냥 대화창에 요약해 달라는 게 아니라, 지속적으로 참조할 수 있는 마크다운 파일로 결과물을 작성하게 합니다.

read this folder in depth, understand how it works deeply, what it does and all its specificities. when that’s done, write a detailed report of your learnings and findings in research.md

위 프롬프트 예시처럼, ‘깊이 있게’, ‘자세히’, ‘모든 세부 사항을’ 같은 단어를 적극적으로 사용합니다. 이걸 그냥 ‘수박 겉핥기’ 식으로 읽지 말고, 정말 심층적으로 파고들도록 유도하는 거죠. 저도 이 부분을 보면서, “아, 내가 너무 대충 지시했었구나” 하고 깨달았습니다.

AI가 research.md 같은 보고서를 쓰는 건 단순히 AI에게 ‘숙제’를 시키는 게 아닙니다. 저는 이걸 개발자가 **‘AI의 이해도를 검증하는 표면’**이라고 이해했습니다. AI가 해당 시스템을 얼마나 정확하게 이해했는지, 혹시 오해하고 있는 부분은 없는지 제가 직접 읽어보고 검토하는 거죠. 만약 여기서 AI의 이해가 잘못됐다면, 아무리 좋은 계획을 세워도, 아무리 멋진 코드를 짜도 결과물은 엉망이 될 수밖에 없으니까요.

개인적으로 이 ‘연구’ 단계가 너무 중요하다고 생각합니다. 개발자가 직접 코드베이스를 꼼꼼히 뜯어보는 시간을 아끼면서도, AI를 통해 시스템의 핵심 흐름과 복잡한 부분을 빠르게 파악할 수 있는 강력한 도구가 되는 거죠. AI가 정리해준 내용을 제가 빠르게 훑어보고 수정하면서, 제 머릿속에 시스템의 전체 그림을 효율적으로 그릴 수 있게 되는 겁니다.

계획을 탄탄하게, ‘주석’으로 설계도 그리기

연구 단계에서 시스템에 대한 충분한 이해가 끝났다면, 다음은 ‘계획’ 단계입니다. 보리스 테인님은 이 단계에서 ‘어노테이션 사이클(Annotation Cycle)‘이라는 것을 활용합니다. 이게 뭐냐면요, 그냥 글로 대충 계획을 쓰는 게 아니라, 코드에 달릴 주석 형태로 구체적인 로직과 구현 방식을 미리 작성하는 겁니다.

예를 들어, “이 함수는 사용자 정보를 받아와서 DB에 저장한다”가 아니라,

# 사용자 정보를 받아와 유효성 검사를 수행합니다.
# 1. request body에서 name, email, password를 추출
# 2. email 형식 유효성 검사 (정규식 사용)
# 3. password 길이 검사 (최소 8자 이상)
# 4. 기존 DB에 동일한 email이 있는지 확인 (중복 체크)

# 유효성 검사를 통과하면 password를 해싱합니다.
# 1. bcrypt 라이브러리 사용하여 비밀번호 해싱
# 2. 솔트(salt)는 환경 변수에서 가져오거나 안전하게 생성

# 최종 사용자 객체를 구성하고 DB에 저장합니다.
# 1. User 모델 인스턴스 생성
# 2. DB 트랜잭션 시작
# 3. 사용자 정보 저장
# 4. 성공 시 트랜잭션 커밋, 실패 시 롤백

# 저장 후 성공/실패 응답을 반환합니다.
# 1. 성공 시 HTTP 201 Created와 함께 사용자 ID 반환
# 2. 실패 시 HTTP 400 Bad Request와 함께 에러 메시지 반환

이런 식으로, 마치 실제 코드가 될 것처럼 구체적으로 주석을 달아나가는 겁니다. 그리고 이 주석을 AI에게 보여주면서 “이 주석을 기반으로 코드를 작성해 줘”라고 하는 거죠. 중요한 건, 이 주석을 AI가 처음부터 다 작성하는 게 아니라, 개발자가 초안을 만들고 AI와 함께 여러 번 반복하며 더 정교하게 다듬어 나간다는 겁니다.

저는 이 방식이 정말 효과적이라고 생각합니다. 첫째, 제가 직접 코드를 짜는 것처럼 한 줄 한 줄 로직을 설계해야 하니, 자연스럽게 ‘아키텍처’와 ‘설계’에 대한 고민을 하게 됩니다. 둘째, AI는 이 구체적인 주석을 보고 마치 설계도면을 받아든 건축가처럼 훨씬 정확하고 의도에 맞는 코드를 만들어낼 수 있습니다. 중간에 이상한 결과물이 나올 확률이 현저히 줄어드는 거죠. 셋째, 토큰 사용량도 효율적입니다. “알아서 잘 해줘”라는 추상적인 프롬프트보다, 구체적인 주석이 있는 프롬프트가 훨씬 적은 시행착오로 원하는 코드를 얻을 수 있으니까요.

이 주석을 만드는 과정에서 AI와 여러 번 대화하고 피드백을 주고받는 ‘어노테이션 사이클’을 1~6번 반복한다고 하셨는데, 이는 마치 TDD(Test Driven Development)에서 테스트를 먼저 작성하듯이, PDD(Plan Driven Development)와 비슷하게 느껴지더라고요. 코드를 짜기 전에 설계도를 완벽하게 만드는 것에 집중하는 거죠.

실전 코딩: 이제야 AI에게 코드를 맡길 시간

연구와 계획(주석)이 완벽하게 준비되면, 드디어 AI에게 코드를 생성하라고 지시할 때입니다. 이쯤 되면 AI는 해당 시스템의 맥락을 깊이 이해하고 있고, 제가 원하는 코드의 설계도까지 구체적으로 받아든 상태입니다.

이때 AI가 생성하는 코드는 이전에 무작정 “이거 만들어줘”라고 했을 때와는 차원이 다릅니다. 제가 의도했던 로직과 아키텍처에 훨씬 가깝고, 불필요한 오류도 훨씬 적습니다. 사실상 제가 직접 코드를 짠 것과 거의 같은 수준의 결과물을 AI의 속도로 얻어낼 수 있는 거죠.

저는 이 경험을 ‘AI는 나의 손발이 되어줄 뿐, 머리는 내가 쓴다’고 표현하고 싶습니다. AI는 제가 생각한 대로 움직이는 훌륭한 조수가 되는 겁니다. 저는 전체적인 방향과 설계에 집중하고, AI는 그 설계를 기반으로 빠르게 결과물을 만들어내는 역할을 하는 거죠.

물론 AI가 내놓은 코드를 100% 그대로 쓰는 건 아닙니다. 마지막 검토와 디버깅은 여전히 개발자의 몫이죠. 하지만 잘 만들어진 계획 덕분에 이 과정이 훨씬 수월해집니다. 사소한 오류를 수정하거나, 제 스타일에 맞게 다듬는 정도의 작업만 남게 되는 경우가 많았습니다.

운전대를 놓지 않는 개발자의 자세

보리스 테인님의 글에서 제가 가장 크게 공감한 부분은 ‘Staying in the Driver’s Seat’, 즉 **‘운전석에 계속 앉아있어라’**는 메시지입니다. AI 코딩 도구는 개발자의 생산성을 폭발적으로 끌어올릴 수 있는 강력한 도구이지만, 이 도구를 맹신하고 개발의 주도권을 AI에게 넘겨주는 순간, 우리는 방향을 잃게 됩니다.

이 워크플로우는 AI를 맹목적으로 믿는 대신, AI를 ‘생각을 확장하고, 정보에 빠르게 접근하며, 반복적인 작업을 자동화하는’ 도구로 활용하는 방법을 제시합니다. 결국 소프트웨어 개발은 문제 해결의 과정이고, 이 문제 해결의 중심에는 여전히 개발자의 ‘사고’가 있어야 한다는 것을 강조하는 거죠.

저는 이 접근 방식이 단순히 ‘클로드 코드를 잘 쓰는 법’을 넘어, AI 시대에 개발자가 어떤 태도를 가져야 하는지에 대한 중요한 통찰을 준다고 생각합니다. AI가 아무리 발전해도, 시스템 전체를 이해하고, 아키텍처를 설계하며, 복잡한 문제를 해결하는 능력은 여전히 개발자의 고유한 영역으로 남을 겁니다. AI는 이 과정을 더 빠르고 효율적으로 만들어주는 조력자일 뿐이고요.

마무리하며: AI 개발의 새로운 패러다임을 향해

보리스 테인님의 ‘연구-계획-구현’ 워크플로우를 보면서, 저는 AI 코딩 도구의 활용에 대한 새로운 시야를 얻었습니다. 단순히 프롬프트 엔지니어링 스킬을 늘리는 것을 넘어, 개발 프로세스 자체를 AI와 협력하도록 재설계하는 관점 말이죠.

만약 여러분도 AI 코딩 도구를 사용하면서 ‘이게 맞나?’ 싶은 회의감을 느껴보셨다면, 오늘 제가 이야기한 이 워크플로우를 한번 시도해 보시길 강력히 추천합니다. 처음에는 조금 번거롭다고 느껴질 수도 있습니다. AI에게 깊이 있는 연구를 시키고, 그걸 검증하고, 주석으로 구체적인 계획을 세우는 과정이 익숙하지 않을 수 있죠.

하지만 이 과정을 통해 여러분은 훨씬 더 높은 품질의 코드를 더 효율적으로 얻을 수 있을 겁니다. 그리고 무엇보다, AI에게 휘둘리지 않고 개발의 주도권을 굳건히 지키는 ‘진정한 AI 시대의 개발자’가 될 수 있을 거라고 저는 확신합니다. 우리 모두 AI와 함께 더 똑똑하게, 더 효율적으로 개발하는 방법을 찾아나갔으면 좋겠습니다.