AI 코딩 도구에게 “이 기능 만들어줘”라고 하면 바로 코드를 짜기 시작합니다. 하지만 시니어 엔지니어라면 코딩 전에 먼저 계획을 세우죠. AI에게도 똑같이 시킬 수 있을까요?
Every의 소프트웨어 엔지니어 Kieran Snyder는 자신의 이메일 앱 Cora를 개발하면서 AI에게 ‘코드 대신 계획’을 먼저 시키는 방법을 체계화했습니다. 그가 발견한 건 단순합니다. AI에게 리서치와 계획을 맡기면, 잘못된 방향으로 시간을 낭비하지 않고 더 빠르게 제품을 만들 수 있다는 것이죠.
출처: Teach Your AI to Think Like a Senior Engineer – Every
53,000개 이메일 정리, AI가 함정을 미리 발견하다
Kieran은 Cora의 ‘받은편지함 대청소(email bankruptcy)’ 기능을 개발할 때 이 방법을 썼습니다. 53,000개 이메일을 한 번에 보관처리하는 기능인데, 얼핏 보면 간단해 보였죠. 하지만 그는 코딩부터 시작하지 않았습니다. 대신 리서치 에이전트를 만들어서 계획을 세우게 했어요.
에이전트에게 시킨 일은 세 가지였습니다. 기존 대량 작업 패턴을 분석하고, API 제한을 확인하고, 세 가지 구현 방식과 각각의 장단점을 제안하는 것이죠. 20분 후 에이전트로부터 의외의 답변이 돌아왔습니다. Gmail API가 2,000개에서 속도 제한에 걸리고, 시스템이 긴 작업에서 타임아웃될 거라는 거였어요. 사용자는 너무 오래 기다려야 할 것이고요.
간단한 기능이라고 생각했던 게 3일짜리 아키텍처 난제로 바뀌었습니다. 계획 단계 덕분에 잘못된 걸 만드느라 시간을 낭비하지 않았죠.
8가지 계획 전략의 핵심
Kieran이 사용하는 방법은 ‘병렬 리서치 작전’입니다. 여러 AI 에이전트가 동시에 다른 종류의 지식을 모으고, 그 결과를 인간이 판단해서 하나의 일관된 계획으로 만드는 거죠. 다섯 개 에이전트가 동시에 리서치하는 게 사람이 하나씩 계획 세우는 것보다 훨씬 빠릅니다.
인간의 역할은 취향, 판단력, 그리고 제품과 사용자에 대한 맥락을 제공하는 것입니다.
전략 1: 버그를 재현하고 문서화하기
언제 쓰나: 버그 수정이나 간단한 개선 작업
에이전트의 역할: 단계별 재현 가이드 만들기
프롬프트: “이 버그를 고치지 말고, 재현만 해서 로그와 정보를 모두 모아줘.”
Cora의 받은편지함 대청소 기능을 런칭한 직후 19명의 사용자가 멈춰버렸습니다. ‘모두 보관처리’ 버튼을 눌렀는데 작업이 실패한 거죠. Kieran은 추측 대신 Claude Code에게 말했습니다. “AppSignal 로그를 돌면서 진단해줘.”
5분 후 답이 왔습니다. 속도 제한 에러가 프로덕션에서 조용히 무시되고 있었던 거예요. Gmail 제한에 걸리면 작업이 조용히 실패하고, 재개되지도 않았죠. 사용자는 버튼을 누르고 로딩 스피너만 보다가 영원히 기다리게 되는 겁니다. 한 배치가 실패하면 전체 작업이 멈추는데, 사용자에게는 아무 알림도 가지 않았으니까요.
이 재현 과정 덕분에 단순한 재시도가 아니라 배치 처리와 작업 재개 기능이 필요하다는 걸 알았습니다.
반복 방지와 개선: Kieran은 이 문제가 다시 발생하지 않도록 자신의 @kieran-rails-reviewer 에이전트를 업데이트했습니다. 체크리스트에 항목을 추가한 거죠. “외부 API를 호출하는 백그라운드 작업이 있다면 속도 제한을 처리하는가? 재시도하는가? 사용자를 중간 상태로 남겨두지 않는가?” 한 번 잊어버렸지만, 시스템이 다시는 잊지 않게 만든 겁니다.
전략 2: 베스트 프랙티스로 기반 다지기
언제 쓰나: 낯선 패턴을 다룰 때, 모든 난이도에서
에이전트의 역할: 웹에서 다른 사람들이 비슷한 문제를 어떻게 해결했는지 찾아서 요약
이 전략은 누군가 이미 당신의 문제를 해결한 모든 경우에 작동합니다. 기술 아키텍처, 카피라이팅 패턴, 가격 책정 리서치, 업그레이드 경로 같은 것들이죠.
Kieran이 두 버전 뒤처진 라이브러리를 업그레이드해야 했을 때, 에이전트에게 검색을 시켰습니다. “X 버전에서 Y 버전으로 업그레이드 경로”, “버전 간 주요 변경사항”, “일반적인 마이그레이션 문제들” 같은 걸 찾게 했죠. 에이전트는 공식 업그레이드 가이드와 함께, 같은 업그레이드를 하다가 예외 상황을 겪은 엔지니어들이 쓴 블로그 포스트 세 개를 찾았습니다. 3분짜리 리서치가 몇 시간의 시행착오 디버깅을 막아준 셈이죠.
기술적이지 않은 결정에도 썼습니다. “SaaS 가격 책정 티어 베스트 프랙티스”를 검색하니 가격 플랜 구조화 프레임워크가 나왔고, “이메일 드립 캠페인 전환 카피”를 찾으니 검증된 이메일 템플릿이 나왔습니다. “백그라운드 작업 재시도 전략”을 검색하니 다른 회사들이 규모에 맞춰 문제를 해결한 패턴들이 나왔어요.
반복 방지와 개선: Kieran이 특히 유용한 패턴을 찾으면, 핵심 발견사항을 docs/*.md 파일로 자동 저장하게 했습니다. 예를 들어 “docs/pay-gem-upgrades.md”에는 마이그레이션 패턴을, “docs/pricing-research.md”에는 가격 책정 인사이트를 저장했죠. 다음에 비슷한 질문이 나오면 에이전트가 웹 검색 전에 먼저 이 문서들을 확인합니다. 지식 베이스가 계속 성장하고 개선되는 거예요.
전략 3 이후: 코드베이스 분석과 그 너머
원문에서는 총 8가지 전략을 소개하는데, 나머지는 유료 구독자 전용입니다. 하지만 핵심은 명확합니다. 기존 코드베이스를 분석해서 이미 해결된 패턴을 재발명하지 않기, git 히스토리를 제도적 기억으로 활용해서 반복된 실수 방지하기 같은 전략들이죠.
계획이 먼저, 코드는 나중에
이 접근법의 핵심은 ‘병렬 처리’입니다. 다섯 개의 전문화된 에이전트가 동시에 다른 각도에서 리서치하고, 인간은 그 결과를 판단해서 하나의 계획으로 통합합니다. 코드를 짜기 전에 방향이 잡히니, 잘못된 길로 가서 시간을 낭비할 일이 없죠.
Kieran의 사례가 보여주는 건 단순합니다. AI 도구를 쓰면서도 ‘어떻게 쓰느냐’가 결과를 크게 바꾼다는 것. 코드를 작성하게 하기 전에 생각하게 만드는 것. 그게 시니어 엔지니어처럼 일하는 AI를 만드는 첫걸음입니다.
참고자료:
답글 남기기