AI 코딩 도구를 사용할 때 가장 흔하게 겪는 문제가 무엇일까요? 바로 AI가 코드를 작성하기 전에 충분한 계획을 세우지 않아 잘못된 방향으로 구현을 진행하거나, 이미 존재하는 더 나은 해결책을 무시하고 처음부터 새로 만들려는 경향입니다. 개발자라면 누구나 AI가 생성한 코드를 수정하느라 오히려 더 많은 시간을 낭비한 경험이 있을 것입니다.
AI의 성급함이 만드는 문제들
대부분의 AI 코딩 도구는 질문을 받으면 즉시 코드를 작성하기 시작합니다. 하지만 시니어 엔지니어는 키보드에 손을 대기 전에 먼저 생각합니다. 기존 코드베이스를 살펴보고, 비슷한 문제를 어떻게 해결했는지 찾아보며, 여러 접근 방식의 장단점을 비교합니다.
이메일 관리 앱 Cora의 개발 사례를 보면 이 차이가 명확하게 드러납니다. 개발팀이 53,000개의 이메일을 안전하게 정리하는 ‘이메일 정리’ 기능을 구현할 때, 만약 AI에게 바로 코드 작성을 요청했다면 어땠을까요? Gmail의 2,000건 배치 처리 제한, 시스템 타임아웃 문제, 사용자 대기 시간 이슈를 놓쳤을 가능성이 높습니다. 하지만 AI 연구 에이전트가 먼저 사전 분석을 수행했기 때문에 이러한 치명적인 문제들을 구현 전에 발견할 수 있었습니다.
계획 중심 개발의 핵심 인사이트
AI가 시니어 엔지니어처럼 사고하도록 만드는 핵심은 간단합니다. 코드 작성을 요청하기 전에 먼저 ‘계획 수립’을 요구하는 것입니다. 이 접근법은 단순해 보이지만 개발 속도를 높이고 오류를 극적으로 줄이는 효과를 냅니다.
Every.to에서 공개한 방법론은 8가지 계획 전략을 난이도별로 적용하며, 각 전략은 특정 에이전트가 병렬로 연구를 수행한 뒤 개발자가 최종 판단과 의사결정을 내리는 구조로 설계되었습니다. 더 흥미로운 점은 에이전트가 학습한 개발자의 선호도와 패턴이 자동으로 축적되어, 시간이 지날수록 개발자의 사고방식을 깊이 이해하게 된다는 것입니다.
실전에서 검증된 8가지 전략
전략 1: 버그 재현 및 문서화
수정에 들어가기 전에 버그를 체계적으로 재현하고 단계별 가이드를 생성합니다. 이메일 파산 기능 출시 직후 19명의 사용자가 작업 실패 상태에 갇힌 사건이 발생했습니다. AppSignal 로그를 순회하며 진단한 결과, Gmail 속도 제한 에러가 프로덕션 환경에서 무시되고 있었고, 배치 하나가 실패하면 전체 작업이 중단되었지만 사용자에게는 무한 로딩 스피너만 표시되는 상황이었습니다.
재현 과정에서 단순 재시도만으로는 부족하고 배치 처리와 작업 재개 기능이 필요함을 발견했습니다. 이 경험은 복리 효과를 만들어냈습니다. @kieran-rails-reviewer 에이전트의 체크리스트에 “외부 API를 호출하는 백그라운드 작업 시 속도 제한 처리, 재시도, 부분 상태 방치 여부”라는 항목이 자동으로 추가되었기 때문입니다.
전략 2: 베스트 프랙티스 조사
모든 난이도의 작업에서 유용하며, 특히 생소한 패턴을 다룰 때 효과적입니다. 2버전 뒤처진 gem을 업그레이드할 때 에이전트가 “버전 X에서 Y로 업그레이드 경로”, “버전 간 중단 변경사항”, “일반적 마이그레이션 이슈”를 자동으로 검색합니다.
단 3분의 연구로 공식 업그레이드 가이드와 함께 동일한 업그레이드를 수행한 다른 엔지니어들의 블로그 포스트 3개를 발견했고, 이는 수 시간의 시행착오 디버깅을 방지했습니다. 흥미롭게도 이 전략은 기술적 결정뿐 아니라 “SaaS 가격 티어 베스트 프랙티스”, “이메일 드립 캠페인 전환 카피”, “백그라운드 작업 재시도 전략” 같은 비기술적 영역에도 활용됩니다. 유용한 패턴을 발견하면 자동으로 docs/*.md 파일에 저장되어, 다음번 유사한 질문이 나올 때 웹 검색 전에 먼저 확인됩니다.
전략 3: 코드베이스 조사
기존 기능이 중복될 가능성이 있는 모든 작업에서 필수적입니다. 새 기능에 이벤트 트래킹을 추가하기 전 에이전트가 코드베이스를 검색했습니다. “현재 이벤트 트래킹은 어떻게 처리되고 있는가?”, “분석 호출 패턴은?”, “이벤트는 어디서 전송되는가?” 같은 질문들이죠.
결과는 놀라웠습니다. 헬퍼 메서드까지 갖춘 기존 트래킹 시스템을 발견했는데, 개발자 본인조차 잊고 있던 것이었습니다. AI가 코드베이스를 참조하지 않으면 처음부터 새로 만들려고 시도하기 때문에, 새 트래킹 시스템을 만드는 대신 기존 패턴을 확장하는 것으로 해결하여 호환되지 않는 두 번째 시스템 구축을 방지했습니다. 이후 “@event-tracking-expert” 에이전트가 생성되어 트래킹이 필요한 모든 기능 계획 시 자동으로 실행됩니다.
전략 4: 라이브러리 소스코드 조사
빠르게 변화하거나 문서화가 부족한 라이브러리를 사용할 때 특히 유용합니다. RubyLLM gem은 새 모델, 파라미터, 기능이 지속적으로 추가되지만 문서가 뒤처지는 상황이었습니다.
에이전트가 RubyLLM 소스코드를 직접 분석하여 “사용 가능한 모델 옵션”, “전달 가능한 파라미터”, “최신 버전의 미문서화 기능”을 찾아냈습니다. “버전 1.9에 스트리밍 지원이 추가되었으나 문서화되지 않았음. 테스트 스위트에서 파라미터명과 사용 예시를 확인”이라는 구체적인 정보를 제공했습니다. 의존성을 업데이트할 때마다 지식도 자동으로 업데이트되어 낡은 정보로 작업하는 일이 없어졌습니다.
전략 5: Git 히스토리 연구
리팩토링이나 작업을 이어갈 때, 특히 “왜”에 대한 이해가 필요할 때 필수적입니다. 구버전 EmailClassifier를 사용 중인 것을 발견하고 업그레이드를 시도하기 전 git 히스토리를 검색했습니다. “왜 v1을 사용하고 있는가?”, “v2로 업그레이드를 시도한 적이 있나?”
3개월 전 다른 팀원의 PR을 발견했는데, v2로 업그레이드했다가 받은편지함 이메일이 아카이브로 가고 아카이브 이메일이 받은편지함으로 가는 심각한 문제가 발생했고, PR 토론에 상세한 이유와 함께 의도적으로 롤백한 기록이 있었습니다. 이를 통해 제도적 기억이 보존되고 검색 가능해져, 신입 팀원도 과거 결정의 논리를 물려받을 수 있게 되었습니다.
전략 6: 프로토타이핑으로 요구사항 명확화
UX가 불확실하거나 탐색적 작업을 할 때 효과적입니다. 이메일 Brief 인터페이스를 재설계할 때 5가지 다른 레이아웃 프로토타입을 Claude에서 각 5분씩 제작했습니다. 직접 클릭해보고 불편한 점을 파악한 뒤 일부 사용자에게 최적 버전을 제시했습니다.
한 사용자의 피드백은 결정적이었습니다. “레이아웃이 압도적이고 이메일 아카이브 방법을 모르겠습니다.” 이 인사이트가 실제 계획의 요구사항으로 반영되었습니다. “아카이브 버튼은 좌측 상단 모서리에 배치 필수—사용자의 근육 기억이 Gmail에서 그 위치를 기대합니다.” 프로토타이핑이 불확실성을 구체적 명세로 전환하고 사용자 반응을 문서화하는 도구가 된 것입니다.
전략 7: 옵션과 함께 종합
모든 연구 단계를 마치고 구현에 들어가기 전, 전략 1~6의 결과를 트레이드오프가 포함된 하나의 계획으로 통합합니다. 에이전트는 이 연구를 바탕으로 문제 해결 방법 3가지를 제시합니다. 각 접근법의 구현 복잡도, 성능 영향, 유지보수 부담, 매칭되는 “기존 패턴”을 분석합니다.
Gmail 인박스 동기화 예시를 보면, 옵션 A는 기존 동기화 시스템을 사용하는 것으로 빠르게 구현 가능하지만 코드 중복과 관심사 분리 저해 문제가 있습니다. 옵션 B는 실시간 동기화로 깔끔한 아키텍처를 제공하지만 느리고 신뢰성 문제가 발생할 수 있습니다. 옵션 C는 미러 캐싱 시스템 구축으로 장기적으로 최고의 솔루션이며 가장 깔끔한 분리를 제공하지만 초기 작업량이 가장 큽니다.
비교를 확인한 후 30초 만에 정보에 입각한 선택을 할 수 있습니다. 선택은 선호도를 드러내므로, “호환성 우선” 선호를 표시하면 다음번 유사한 결정 때 시스템이 호환성에 높은 가중치를 부여합니다.
전략 8: 스타일 에이전트 리뷰
최종 계획 단계에서 구현 전에 자동 실행되는 3개의 리뷰 에이전트가 있습니다. 단순화 에이전트는 과도한 엔지니어링에 플래그를 답니다.
이 기능에 정말 3개의 데이터베이스 테이블이 필요한가? 타입 필드가 있는 1개 테이블로 가능하지 않나?
보안 에이전트는 일반적 취약점을 체크합니다.
이 계획은 사용자 입력을 데이터베이스 쿼리에 직접 허용합니다 — 입력 새니타이제이션 추가가 필요합니다.
Kieran 스타일 에이전트는 개인 선호도를 강제합니다.
복잡한 조인을 사용 중입니다. Kieran은 단순 쿼리를 선호하므로 비정규화를 고려하세요.
에이전트가 시간이 지남에 따라 개발자의 취향을 축적하여, “이거 싫어함” 또는 “잘 잡았어”라고 표시할 때마다 시스템이 학습합니다.
오늘부터 시작하는 실천 가이드
복잡한 시스템을 구축할 필요는 없습니다. Every의 Github 마켓플레이스에 계획 시스템이 오픈소스로 공개되어 있어, Claude Code에 설치하면 /plan 슬래시 커맨드와 연구 에이전트를 즉시 사용할 수 있습니다.
더 간단하게 시작하고 싶다면 이번 주 빌드 중인 Fidelity 2 기능 하나를 선택하세요. 여러 파일에 걸쳐 있고 명확한 범위를 가진 작업이 좋습니다. 새 뷰 추가, 피드백 시스템 구현, 컴포넌트 리팩토링 같은 것이죠.
Claude Code나 Cursor에 빌드를 요청하기 전 15~20분 동안 연구를 진행합니다. 베스트 프랙티스는 웹에서 블로그 포스트, Stack Overflow, 문서를 검색하여 다른 사람들이 어떻게 해결했는지 찾아봅니다. 본인의 패턴은 기존 코드베이스에서 유사 기능을 검색하여 어떻게 해결했는지 확인합니다. 라이브러리 기능은 AI로 문서나 소스코드를 읽어 사용 중인 도구가 실제로 무엇을 지원하는지 파악합니다.
AI가 연구를 계획으로 종합하도록 합니다. 해결할 문제를 명확한 한 문장으로, 2~3가지 솔루션 접근법을 각각의 정직한 장단점과 함께, 매칭되어야 할 기존 코드 패턴, 엣지 케이스나 보안 고려사항을 포함해야 합니다.
계획을 검토하고 반응을 관찰하세요. “너무 복잡하다” 또는 “이미 더 나은 방법이 있다”고 생각되면, 계획만 수정하지 말고 왜 그렇게 생각하는지 포착해 기록합니다. 계획을 기반으로 기능을 출시하고, 최종 구현과 원래 계획을 비교합니다. 어디서 벗어났고, 왜 그랬으며, 무엇이 계획을 더 낫게 만들었을까요?
10분을 투자해 학습을 문서화하세요. CLAUDE.md 파일에 “X 타입 작업 시 Y를 체크할 것을 기억” 또는 “이유 C 때문에 접근법 B보다 A를 선호”같은 규칙 하나를 작성합니다. 학습이 축적되면 특화 연구 에이전트나 커맨드를 생성합니다. “Event Tracking Expert”는 본인의 패턴을 숙지하고, “Security Checker”는 일반적 실수에 플래그를 답니다.
다음 주에 반복하고 노트를 참조하여 두 번째 계획이 첫 번째보다 나아졌는지 확인하세요. 몇 달 후면 개발자의 사고방식을 아는 시스템을 구축하게 됩니다.
핵심은 복리 효과
이 전략들의 진짜 힘은 복리 효과에 있습니다. 매번 계획을 세우고, 결정을 내리고, 피드백을 기록할 때마다 AI는 개발자의 사고방식을 더 깊이 이해하게 됩니다. 시간이 지날수록 AI는 단순히 코드를 작성하는 도구에서 개발자의 선호도와 패턴을 이해하는 진정한 협업 파트너로 진화합니다. 코드를 작성하기 전에 먼저 생각하는 습관, 이것이 시니어 엔지니어와 주니어 엔지니어를 구분하는 핵심이며, 이제 AI에게도 같은 습관을 가르칠 수 있습니다.
참고 자료: Every.to, “Teach Your AI to Think Like a Senior Engineer”