핵심 요약: AI 코딩은 새로운 패러다임처럼 보이지만, 실제로는 좋은 소프트웨어 엔지니어링 기본기를 AI 시대에 맞게 다시 짜는 문제에 가깝다. “스펙 넣으면 코드 나온다” 같은 vibe coding으로는 잘 안 된다. LLM의 컨텍스트 한계를 인정하고, 사람의 판단(설계·정렬)과 AI의 반복 실행(구현·테스트)을 분리하고, 작업을 vertical slice로 쪼개 빠른 피드백 루프 위에서 돌려야 한다는 메시지다. AI 코딩 워크숍 한 편을 보고 핀테크 백엔드 작업에 바로 끼워 넣을 만한 포인트만 정리해 둔다.
지난 AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다 글에서 “Agent의 다음 경쟁력은 더 좋은 프롬프트가 아니라 Harness 설계 능력”이라고 적었다. 비슷한 결의 이야기를 코딩 작업에 한정해 풀어낸 워크숍 영상을 한 편 보면서, 실제 코드 작업에 바로 가져다 쓸 만한 포인트가 많아 정리해 둔다.
1. LLM에는 Smart Zone과 Dumb Zone이 있다
발표자가 가장 먼저 짚는 건 LLM의 컨텍스트 길이 자체가 양날의 칼이라는 점이다. 컨텍스트가 길어질수록 더 똑똑해질 것 같지만, 실제로는 어느 순간부터 attention 관계가 복잡해지면서 판단력이 떨어진다. 초반엔 또렷하다가 뒤로 갈수록 잘못된 결정을 내릴 확률이 높아진다.
그래서 큰 작업을 그대로 AI에게 던지는 게 안 통한다. AI가 감당할 만한 작은 단위로 쪼개야 한다. 발표자는 LLM을 영화 메멘토의 주인공에 비유한다. 계속 리셋되는 존재라는 걸 받아들이고, 그 특성에 맞춰 워크플로우를 설계하자는 말이다.
실무적으로는 두 갈래로 갈린다.
- compact로 컨텍스트를 계속 이어 붙이기 → 길어진 만큼 점점 흐려진다.
- 깨끗하게 clear한 뒤 필요한 정보만 구조화해 다시 넣기 → 매번 또렷한 상태에서 시작한다.
발표자는 후자를 선호한다. 컨텍스트 압축 글에서 정리했던 “다음 판단에 필요한 작업 상태만 남기고 나머지는 버린다”는 원칙과 정확히 같은 방향이다. 코딩 도구로 옮기면, compact로 끌고 가지 말고 자주 비우면서 쓸 정보만 다시 깔아주는 식이 비용 측면에서도 자연스럽다.
2. 가장 먼저 해야 할 일은 코딩이 아니라 정렬이다
AI와 코딩할 때 가장 큰 문제 중 하나가 misalignment, 즉 사람과 AI가 같은 그림을 그리고 있지 않은 상태다. 발표자는 그래서 바로 plan mode나 specs-to-code로 넘어가지 않는다. 먼저 “grill me” 같은 스킬을 써서 AI가 사용자를 집요하게 질문으로 압박하게 만든다. 기능 요구사항, 예외 상황, 설계 판단, 테스트 기준이 하나씩 드러나도록 짜내는 작업이다.
여기서 발표자가 반대하는 흐름은 익숙하다.
스펙 작성 → AI가 코드 생성 → 코드가 이상하면 스펙만 수정 → 다시 생성
specs-to-code 또는 vibe coding이라 부르는 패턴이다. 발표자의 진단은 단순하다. 코드가 실제 전장인데, 코드를 외면하기 때문에 잘 안 된다. AI가 코드를 만들어도 개발자는 여전히 코드 구조와 설계 판단을 직접 들고 있어야 한다는 이야기다.
3. 사람은 판단에 남고, AI는 구현 루프를 돈다
발표자는 작업을 두 종류로 나눈다.
Human-in-the-loop task: 요구사항 정리, 제품 방향, 설계 판단, 도메인 결정처럼 사람이 반드시 관여해야 하는 일. grill me 세션, PRD 작성, 이슈 분해가 여기에 들어간다.
AFK task (Away From Keyboard): 사람이 자리를 비워도 AI가 굴릴 수 있는 일. 구현, 테스트 실행, 타입체크, 작은 리팩터링처럼 반복 가능한 작업이다.
planning과 alignment 단계는 사람이 있어야 하지만, implementation은 잘 쪼개두면 AI에게 맡길 수 있다. 전체 흐름은 대략 이런 모양이다.
아이디어
→ AI가 사람을 질문으로 압박하며 요구사항 정렬
→ PRD로 목적지 문서화
→ Kanban / issue로 작업 분해
→ AI agent가 AFK로 구현
→ 테스트 · 타입체크 · QA로 피드백
여기서 보이는 그림은 Harness Engineering 글의 결론과 같은 결이다. AI에게 자유를 더 주는 게 아니라, 더 정교한 구조를 그 주변에 깔아주는 일이다.
4. PRD는 목적지 문서, Kanban은 여정 문서다
grill me 세션으로 충분히 정렬한 다음에는 그 결과를 PRD(Product Requirements Document)로 정리한다. 발표자가 부르는 표현이 직관적이다. PRD는 destination document다. 우리가 어디로 가야 하는지를 문서로 박아둔다. 문제 정의, 해결책, user story, implementation decision, testing decision이 안에 들어간다.
다음 단계가 흥미롭다. 발표자는 PRD를 순차적인 multi-phase plan으로 바로 옮기지 않는다. 1단계 → 2단계 → 3단계 식 계획은 한 명의 agent가 순차로 처리하기엔 편하지만, 작업 간 의존성을 정확히 표현하지 못한다.
대신 Kanban board 형태의 독립 이슈들로 쪼갠다. blocking 관계를 명시해두면 여러 agent가 병렬로 처리할 수 있는 구조가 만들어진다. PRD는 어디로 가는지, Kanban은 어떻게 가는지에 대한 문서인 셈이다.
5. Horizontal slice가 아니라 vertical slice로 쪼갠다
가장 실무적으로 와닿는 부분이 vertical slice(또는 tracer bullet) 개념이다.
AI는 보통 작업을 horizontal하게 나누는 경향이 있다.
1단계: DB schema 전부
2단계: API 전부
3단계: frontend 전부
이렇게 가면 마지막 단계에 가서야 전체 기능이 실제로 도는지를 알 수 있다. 피드백이 너무 늦다. 잘못된 가정 위에 길게 빌드하고, 그걸 뒤늦게 안다.
발표자가 제안하는 건 얇지만 end-to-end로 동작하는 vertical slice다. 예를 들어 게이미피케이션 기능을 붙인다면, 첫 작업부터 schema 일부 + service 일부 + dashboard의 최소 UI까지 한 줄로 이어서 “눈에 보이는 동작”을 먼저 만든다. 그래야 AI가 빠르게 피드백을 받고, 잘못된 방향으로 오래 달리지 않는다.
큰 기능을 AI에게 맡길 때는 레이어별로 나누지 말고, 작더라도 처음부터 끝까지 동작하는 흐름으로 나누는 게 핵심이다.
6. 좋은 코드베이스와 테스트가 AI 코딩 품질의 상한선이다
마지막으로 발표자가 강하게 짚는 게 코드베이스 품질이다. “bad codebases make bad agents” 라는 취지다. 코드 구조가 엉망이면 AI도 엉망으로 코딩할 가능성이 높다. AI가 잘 코딩하게 하려면 코드 구조가 명확해야 하고, 테스트·타입체크·lint 같은 피드백 루프가 갖춰져 있어야 한다.
특히 TDD를 강하게 강조한다. AI가 코드를 작성하기 전에 테스트를 먼저 만들고, 그 테스트를 통과하도록 구현하게 만들면 AI가 “속이기” 어려워진다. 피드백 루프가 없으면 AI는 사실상 blind coding을 하게 되고, 테스트 품질이 AI 코딩 품질의 ceiling이 된다.
핀테크 백엔드를 다루는 입장에서 이 부분이 특히 와닿는다. 결제·정산·신용평가처럼 잘못된 출력이 곧 손실로 이어지는 영역은 테스트 인프라가 약하면 AI가 만든 코드를 검증할 길이 없어진다. AI 코딩을 본격적으로 도입하기 전에 도메인 모델, 더미 데이터, replay 가능한 픽스처, 통합 테스트 환경 같은 테스트 가능성을 먼저 갖추는 일이 와야 한다.
AI 코딩은 결국 기본기의 재구성이다
워크숍 한 편을 보고 가져갈 메시지는 명확하다. AI 코딩의 생산성은 더 좋은 프롬프트에서 나오지 않는다. 작업을 작게 쪼개고, 피드백 가능한 구조로 만들고, 사람이 판단해야 할 부분과 AI가 반복 실행할 부분을 분리하는 능력에서 나온다.
요구사항 정렬 → 목적지 문서화 → vertical slice 이슈화 → 테스트 기반 AFK 구현 루프. 흐름 자체는 새롭지 않다. 좋은 소프트웨어 엔지니어링이 늘 강조해 온 작은 작업 단위, 빠른 피드백, 명확한 인터페이스, 든든한 테스트. 그 기본기를 AI 시대에 맞춰 다시 짠 것에 가깝다.
다음 단계는 이걸 실제로 핀테크 백엔드 같은 내 환경에 맞춰 끼워 넣는 일이다. grill me 스킬에 도메인 질문을 미리 깔아두기, PRD 템플릿을 결제·정산·리스크 워크플로우에 맞게 다듬기, vertical slice의 첫 단위를 어떻게 잡을지. 다음 글로 자연스럽게 이어갈 주제들이다.
참고
- 원본 워크숍 영상: Mastering AI-First Coding (YouTube)
함께 보면 좋은 글: