이런 상황이라면
AI 코딩 도구를 이미 매일 쓰는데 "결국 내가 다 고친다"는 느낌이 드는 사람에게 맞는다. 혼자 또는 소수로 제품을 만들면서 사람 손을 늘리는 대신 구조를 늘려야 하는 상황이라면 더 그렇다. 반대로 AI 코딩 자체가 처음이라면 기초 입문서를 먼저 보는 게 낫다.
한눈에 보기
AI 코딩 도구를 쓰는데도 생산성이 체감되지 않는 사람이 많다. 질문 하나에 답 하나를 받는 방식으로 쓰기 때문이다. 이 책은 그 지점을 문제로 잡는다. 개별 프롬프트를 잘 쓰는 기술이 아니라, 요청·실행·검증·수정이 스스로 돌아가는 "루프"를 어떻게 짜는지를 다룬다. 클로드 코드를 축으로 스킬, MCP, 훅, 컨텍스트 관리, 하네스, 코드 리뷰, 오케스트레이션을 하나의 작업 체계로 엮는다. 뒤쪽에서는 LLMOps와 Langfuse로 그 루프를 관측하고 평가하는 방법까지 이어진다. 도구 설명서가 아니라 일하는 구조에 대한 책이다.
기존의 AI 활용서는 "이렇게 물어보면 좋은 답이 나온다"는 프롬프트 기술에 머물렀다. 이 책은 좋은 답을 한 번 받는 것보다, 틀린 답을 시스템이 먼저 걸러내게 만드는 쪽이 중요하다고 본다. 사람이 매번 검토하는 구조는 결국 사람이 병목이 된다. 그래서 훅으로 자동 검증을 걸고, 스킬로 반복 작업을 재사용 가능한 단위로 묶고, 컨텍스트를 의도적으로 설계한다. 관측과 평가를 넣는 것도 같은 맥락이다. AI를 쓰는 사람에서 AI가 일하는 환경을 만드는 사람으로 역할이 바뀐다.
핵심 인사이트
- 01
프롬프트가 아니라 루프가 성과를 만든다
AI 활용 수준의 차이는 질문 솜씨가 아니라 반복 구조에서 갈린다. 한 번의 요청은 결과가 좋든 나쁘든 거기서 끝난다. 반면 실행 결과가 다시 입력으로 돌아오는 구조를 만들면, 틀린 출력이 다음 시도의 재료가 된다. 테스트를 돌려 실패 메시지를 그대로 다시 넘기는 것만으로도 품질이 올라가는 이유가 여기 있다. 사람이 중간에서 복사하고 붙여넣는 역할을 하고 있다면 루프가 아직 닫히지 않은 것이다. 루프를 닫는 순간 작업량이 선형으로 늘지 않는다.
- 02
컨텍스트는 많이 넣는 게 아니라 깎는 것이다
컨텍스트 창이 커지면 문제가 사라질 것 같지만 반대다. 관련 없는 정보가 섞이면 모델은 엉뚱한 파일을 고치고 이미 정한 규칙을 잊는다. 사람에게 설명할 때 배경을 다 읊지 않고 필요한 것만 추리는 것과 같다. 코드베이스 전체를 던지는 것보다 해당 모듈과 규약 문서만 주는 쪽이 정확하다. 그래서 컨텍스트 설계는 "무엇을 넣을까"보다 "무엇을 빼야 하나"의 문제다. 입력을 줄이면 비용도 줄고 결과도 좁혀진다.
- 03
검증은 사람이 아니라 하네스가 한다
AI가 만든 코드를 사람이 눈으로 읽어 승인하는 방식은 금방 한계에 부딪힌다. 양이 늘어나면 리뷰가 형식적으로 변하고, 통과시킨 다음 사고가 난다. 하네스는 그 판단을 자동화된 관문으로 바꾼다. 린트, 타입 체크, 테스트, 훅이 먼저 걸러내고 사람은 통과한 것만 본다. 신뢰의 근거가 "잘 썼겠지"에서 "통과했다"로 옮겨간다. 결과적으로 AI에게 맡길 수 있는 작업 범위가 넓어진다.
- 04
스킬과 MCP는 능력이 아니라 경계를 정하는 장치다
도구를 붙이는 일은 기능 추가로만 보이기 쉽다. 하지만 실제 효과는 모델이 할 수 있는 일의 범위를 명확히 하는 데서 나온다. 무엇을 쓸 수 있고 어떤 절차를 따라야 하는지가 정의되면 모델의 선택지가 좁아지고 결과가 안정된다. 자유도가 높을수록 똑똑하게 쓸 것 같지만, 실무에서는 자유도가 높을 때 예측 불가능성이 커진다. 반복되는 작업을 스킬로 묶는 이유도 같다. 매번 설명하지 않고 같은 절차를 같은 방식으로 돌리기 위해서다.
- 05
여러 에이전트를 돌리는 건 속도가 아니라 분리의 문제다
오케스트레이션을 병렬 처리로 속도를 올리는 기법으로 이해하면 절반만 맞다. 더 큰 이득은 역할을 쪼개 서로의 컨텍스트를 오염시키지 않는 데 있다. 코드를 쓰는 쪽과 그것을 의심하는 쪽을 같은 대화에 두면, 방금 자기가 쓴 코드를 변호하게 된다. 작성과 리뷰를 분리하면 리뷰어는 결과만 보고 판단한다. 탐색과 구현을 나누는 것도 같은 논리다. 사람 조직에서 역할을 나누는 이유와 다르지 않다.
- 06
관측이 없으면 개선도 없다
AI 기능을 붙인 뒤 "잘 되는 것 같다"는 감으로 운영하는 경우가 흔하다. 하지만 어떤 요청이 실패했고 토큰이 어디서 새는지 모르면 고칠 지점을 특정할 수 없다. Langfuse 같은 도구로 호출을 추적하고 평가 기준을 붙이는 작업이 그래서 필요하다. 프롬프트를 바꿨을 때 좋아졌는지 나빠졌는지를 숫자로 비교할 수 있어야 한다. 이 과정이 없으면 개선은 취향 논쟁이 된다. LLMOps는 거창한 인프라가 아니라 이 비교 가능성을 만드는 일이다.
이렇게 적용한다
상황AI에게 기능 구현을 맡겼는데 받은 코드를 매번 직접 고치고 있을 때
고치는 행위를 멈추고, 내가 매번 지적하는 항목을 목록으로 적는다. 그중 기계가 판단할 수 있는 것은 테스트나 훅으로 옮긴다. 사람이 반복해서 하는 지적은 거의 다 자동화 대상이다. 지적 목록이 줄어들 때까지 이 작업을 먼저 한다.
상황같은 종류의 작업을 매번 처음부터 설명하고 있을 때
그 작업의 절차를 순서대로 적어 스킬이나 지침 파일로 저장한다. 다음부터는 설명 대신 그것을 호출한다. 핵심은 문서화가 아니라 호출 가능한 형태로 만드는 것이다. 설명이 길어질 때마다 저장할 신호로 본다.
상황AI 기능을 서비스에 붙였는데 품질이 좋아졌는지 확신이 없을 때
먼저 호출 로그를 남기는 것부터 한다. 입력, 출력, 실패 여부, 토큰 사용량을 쌓아 둔다. 그다음 실패 사례 열 개를 골라 평가 기준을 만든다. 기준이 생기기 전에는 프롬프트를 더 손대지 않는다.
ACTION ITEMS
오늘 바로 할 수 있는 것.
- ✓지금 쓰는 AI 도구에 테스트 실행 결과가 자동으로 돌아오는 경로를 하나 만든다.
- ✓AI가 쓴 코드에서 내가 반복해 고치는 항목 다섯 개를 적고, 그중 하나를 훅이나 린트 규칙으로 옮긴다.
- ✓이번 주 가장 자주 반복한 작업 하나를 절차로 적어 스킬 파일로 저장한다.
- ✓프로젝트 지침 문서를 열어 지금 쓰지 않는 내용을 지우고 절반 분량으로 줄인다.
- ✓코드 작성과 코드 리뷰를 같은 세션에서 하지 않고 나눠서 한 번 돌려 본다.
- ✓AI 호출 로그를 남기는 설정을 켜고 하루치 입출력과 토큰 사용량을 확인한다.
밑줄 그은 문장
“AI에게 답을 잘 묻는 능력보다, 틀린 답이 걸러지는 구조를 만드는 능력이 성과를 가른다.”
“컨텍스트를 늘리는 것은 설명을 늘리는 것이고, 설명이 길어질수록 초점은 흐려진다.”
이 책이 답하지 않는 것
도구와 플랫폼의 변화 속도가 빨라 구체적인 설정이나 명령은 금방 낡는다. 바뀌지 않는 설계 원리를 중심으로 읽어야 한다. 또 개발 작업 흐름에 초점이 맞춰져 있어, 모델 자체를 학습시키거나 대규모 서비스 인프라를 운영하는 문제는 다루는 범위 밖이다.
이 통찰의 근거가 궁금하다면?
원서·번역서 정보와 가격은 판매처에서 확인하세요.
※ 구매 링크는 제휴 활동의 일환이며, 이를 통해 일정액의 수수료를 제공받습니다. 구매자에게 추가 비용은 발생하지 않습니다.
비슷한 주제의 책
NEWSLETTER
매일 아침, 새로운 인사이트
하루의 시작을 도와줄 책 한 권의 핵심과 실천 과제를 보내드립니다.