들어가면서 — AI를 쓰는 사람이 많아졌지만
회사에서는 Cursor.ai, 사내에서 만든 Cline, Codex를 쓰고, 집에서는 Claude Code, Antigravity 같은 도구들을 사용한다. 모델도 다르고, UI도 다르고, 자동화 수준도 제각각이다.
AI를 쓰는 사람은 확실히 많아졌고, 개인적으로도 퍼포먼스가 올라갔다는 느낌은 분명하다.
그런데 어느 순간 이런 생각이 들었다.
왜 같은 코드베이스, 같은 문서를 두고
결과의 느낌이 이렇게 다를까?
어떤 날은 굉장히 매끄럽게 일이 풀리고, 어떤 날은 결과는 나왔지만 찜찜함이 남는다. 이걸 단순히 “모델 차이”나 “도구 숙련도”로만 설명하기는 어려웠다.
그러다 문득 질문이 바뀌었다.
이건 AI를 어떻게 쓰느냐의 문제가 아니라,
AI와 함께 _어떤 순서로 생각하고 있느냐_의 문제 아닐까?
내가 정리해본 AI와 일하는 기본 흐름
이 질문을 계기로, 내가 AI와 일할 때 암묵적으로 거치고 있던 단계를 한 번 정리해봤다.
표준도 아니고, 규칙도 아니다. 그냥 내 개인적인 경험을 구조로 적어본 것에 가깝다.
0. Context Setting
1. Problem Space Definition
2. Option / Proposal Generation
3. Human Adjustment (HITL zone)
4. Execution
5. Review & Learning (optional but recommended)
0. Context Setting
AI에게 일을 시키기 전에,
이 대화에서 무엇을 기준으로 삼을지를 먼저 맞춘다.
- 코드베이스
- docs/specs
- 개인적으로 정리해둔 notes
- 툴에 따라 미리 설정하는 문서 (e.g. CLAUDE.md)
이 단계는 결과를 만들기 위한 준비라기보다, 대화의 전제를 맞추는 과정에 가깝다.
지금 생각해보면, 이건 거의 System Prompt에 해당한다.
1. Problem Space Definition
그다음은 문제 정의다. 여기에는 두 가지가 섞여 있다.
- 무엇을 구현하려는가
- 무엇을 고치려는가
PRD나 Feature Requirement Doc이 있는 경우도 있고, 단순한 개선이나 리팩토링일 때도 있다. 중요한 건 이번 작업에서 하지 않을 것(out of scope)까지 함께 정리하는 것이다.
2. Option / Proposal Generation
이 단계에서 일부러 바로 실행하지 않는다.
- 가능한 선택지를 몇 개 만들어보고
- 각 선택이 전제하고 있는 가정을 살펴본다
이건 속도를 늦추기 위한 단계라기보다는, 사고 공간을 넓히기 위한 단계에 가깝다.
3. Human Adjustment (HITL zone)
여기가 사람이 가장 적극적으로 개입하는 구간이다.
- 조건을 바꿔보거나
- 관점을 바꿔보거나
- 중요도를 재정렬해본다
여기서의 인간은 승인자가 아니라, 사고를 조정하는 존재에 가깝다.
4. Execution
조건과 방향이 어느 정도 정리된 뒤에 실행한다. 이때는 오히려 속도가 빨라진다. 무엇을 왜 하는지가 비교적 명확해져 있기 때문이다.
5. Review & Learning
항상 하지는 않지만, 가끔은 이렇게 돌아본다.
- 이 단계는 다음에 기계에게 넘겨도 될까?
- 어디까지는 자동화해도 괜찮을까?
이건 결과 평가라기보다, 다음 루프를 위한 정리에 가깝다.
HITL을 돌아보며 — 우리는 어디에 서 있는가
이 흐름을 정리하다 보니, Human-in-the-loop(HITL)를 이분법으로 보는 시선이 조금 불편해졌다. 현실은 훨씬 연속적이다.
Human-out-of-the-loop
↓
Machine-in-the-loop
↓
Human-on-the-loop
↓
Human-in-the-loop
중요한 건 우리가 이 중 하나를 선택해야 한다는 게 아니라, 지금 어떤 위치에서 일하고 있는지를 자각하는 것이었다. 그리고 그 위치는, 작업마다 달라질 수 있다. 즉, 같은 사람도 같은 날 안에서도 이 스펙트럼을 계속 오간다.
- 반복적이고 되돌릴 수 있는 작업은 MITL이 더 건강할 때도 있고
- 불확실성이 큰 순간에는 HITL이 필요하다
HITL이 늘어날수록, 사람은 더 많이 생각하게 된다. 이건 분명 비용이다.
하지만 동시에, 그 비용이 성장으로 이어질 수 있는 지점이기도 하다.
어떻게 팀과 공유할까 — 규칙이 아니라 참여로
이 생각을 팀과 나눌 때, 가장 조심했던 건 규칙을 만들지 않는 것이었다.
사실 이건 진짜다. 나는 규칙을 만들지 않았다. 그저 내 개인적인 경험을 정리해서 제안했을 뿐이다.
이 걸 공유하려고 정리하는 지점에서 애자일 도입 경험이 떠올랐다.
- 프랙티스를 그대로 따라 하는 건 어렵지 않았다
- 하지만 진짜 어려웠던 건,
팀이 직접 해석하고, 조정하고, 참여하게 만드는 과정이었다 - 이렇게 해야 유지가 된다.
팀은 결국 직접 참여하고, 반복적으로 되짚을 때 변화가 남는다.
AI 협업도 비슷하다고 느꼈다. 그래서 이렇게 접근했다.
- “이렇게 써야 한다”가 아니라
- “나는 이렇게 쓰고 있다”를 공유했다
- 그리고 같이 해볼 동료를 찾기로 했다
작게, 하지만 임팩트가 있는 실험을 하려는 것이다. 그 실험이 어떻게 자랄지는 아직 모른다. 다만 씨앗을 심어보는 건 의미가 있다고 생각했다.
마무리 — 속도가 아니라 질문의 밀도
AI는 일을 빠르게 만들어준다. 이건 부정하기 어렵다.
하지만 내가 느끼기에, 더 큰 변화는 다른 곳에 있었다.
AI와 함께 일하면서,
사람은 다시 질문하게 된다.
무엇을 기준으로 삼고 있는지, 어디에서 개입하고 있는지, 무엇을 기계에게 맡기고 있는지.
어쩌면 AI가 늘린 것은 속도가 아니라, 질문의 밀도였는지도 모른다.
그리고 그 질문은, 여전히 사람 쪽에 남아 있다.
'Agentic Coding' 카테고리의 다른 글
| 같은 요구사항, 같은 기술 스택, 완전히 다른 결과물 (0) | 2025.12.17 |
|---|---|
| Claude Code 자동화 실행 환경 & 설정 가이드 (0) | 2025.11.24 |
| Firebase Auth 완전 가이드 - 정적 페이지부터 앱 연동까지 (0) | 2025.11.19 |
| Claude Code Hooks로 Windows 데스크톱 알림 자동화하기 (0) | 2025.11.17 |
| AI로 내 문제 풀기-비개발자와 개발자가 함께 문제를 탐구한 실험 (0) | 2025.11.16 |