AI가 코드를 작성하는 시대가 되었다.
하지만 흥미로운 점은 코드 생성 속도 자체는 누구에게나 거의 동일하게 제공된다는 것이다.
차이를 만드는 것은 다른 곳에 있다.
- 무엇을 만들어야 하는지 정의하는 능력
- 문제를 잘게 나누는 능력
- 에이전트가 잘 작동하는 환경을 설계하는 능력
- 결과의 품질을 판단하는 능력
결국 AI 이전에도 중요했던 능력들이 AI 시대에 더 중요해졌다.
특히 Claude Code와 같은 Agentic Engineering 환경에서는 다음과 같은 능력이 핵심 역량이 된다.
1. 분해 능력 (Decomposition)
에이전트를 잘 활용하는 사람들의 공통점은 하나다.
작업을 매우 잘 쪼갠다.
핵심은 다음과 같다.
잘 작동하는 부분은 에이전트에게 위임하고,
나머지 부분에서 인간이 개입한다.
이를 위해서는 모호한 요구사항을 구체적인 작업 단위로 분해하는 능력이 필요하다.
예를 들어 하나의 큰 기능을 다음처럼 나눌 수 있다.
- 요구사항 분석
- 데이터 모델 수정
- API 구현
- UI 연결
- 테스트 작성
그리고 각 작업을 에이전트가 한 번의 작업 턴에서 처리할 수 있는 크기로 줄인다.
실무적으로 경험상 다음 정도가 적절하다.
- 파일 3~5개 수정
- 15~30분 내 완료 가능
이 정도 크기의 작업 단위로 분해하면
에이전트의 성공률이 눈에 띄게 높아진다.
2. 컨텍스트 설계 (Context Architecture)
AI가 실패하는 가장 흔한 이유는 모델이 부족해서가 아니라 컨텍스트가 부족해서다.
에이전트에게 전달되는 정보는 다음과 같은 구조를 가져야 한다.
- 현재 목표
- 관련 코드
- 아키텍처 규칙
- 완료 기준
- 제약 조건
즉 에이전트가 올바른 결정을 내릴 수 있는 환경을 설계하는 것이 중요하다.
이 과정은 일종의 컨텍스트 아키텍처 설계라고 볼 수 있다.
3. 완료 정의 (Definition of Done)
에이전트의 “완료”와
개발자의 “완료”는 다르다.
그리고 그 간극을 메우는 것은 더 좋은 모델이 아니라 더 명확한 완료 정의다.
많은 실패는 다음과 같은 착각에서 시작된다.
“문서가 있으니까 에이전트가 알아서 읽고 구현하겠지.”
하지만 실제로는 완료 기준을 명확하게 정의해야 한다.
가장 간단한 방법은 DoD 체크리스트를 지시에 포함하는 것이다.
예시:
Definition of Done
- PR이 생성되었는가
- main 브랜치와 동기화되었는가 (merge conflict 없음)
- CI가 통과했는가
- lint
- type check
- unit test
- E2E test
- Codex 코드 리뷰 통과
- Claude Code 코드 리뷰 통과
- Gemini 코드 리뷰 통과
- UI 변경이 있다면 스크린샷 포함
또한 작업이 끝나면 에이전트에게 다음 내용을 리포트로 작성하게 한다.
- 무엇을 수행했는지
- 완료 기준 중 무엇을 충족했는지
- 아직 남은 작업은 무엇인지
4. 실패 복구 루프 (Failure Recovery Loop)
에이전트 워크플로우에서 중요한 것은 실패를 줄이는 것이 아니라 실패에서 학습하는 것이다.
대표적인 방법은 다음과 같다.
문제 격리
문제가 되는 함수만 분리하여 테스트한다.
통합 테스트에서는 보이지 않던 문제가
단독 테스트에서는 즉시 드러나는 경우가 많다.
실패 기록
프로젝트에 다음 문서를 두는 것도 매우 효과적이다.
이 문서에는 다음을 기록한다.
- 에이전트가 자주 하는 실수
- 해결 방법
- 주의해야 할 패턴
실패 기록이 쌓이면 그것이 프로젝트의 메모리가 된다.
실패 기록이 메모리가 되고,
메모리가 시스템이 된다.
5. 관찰 가능성 (Observability)
에이전트가 작업하는 동안
중간 체크포인트를 명시적으로 설계하는 것도 중요하다.
예를 들어 이런 한 문장이 큰 차이를 만든다.
“여기까지 구현되면 한 번 보여줘.”
이 한 문장은 1시간짜리 잘못된 작업을 막을 수 있다.
또한 자동 모니터링도 가능하다.
예를 들어 다음 상태를 주기적으로 검사할 수 있다.
- tmux 세션 상태
- PR 생성 여부
- CI 결과
이를 기대 상태(blueprint) 와 비교하고
이탈하면 알림을 보내는 방식이다.
6. 메모리 설계 (Memory Architecture)
에이전트 작업에서 중요한 것은 작업 결과를 기록으로 남기는 것이다.
예를 들어 다음 구조가 많이 사용된다.
MEMORY.md
작동 방식은 단순하다.
- Claude가 작업 수행
- hooks가 세션 종료 시 작업 내용을 요약
- 문서에 자동으로 기록
다음 세션이 시작되면 Claude는 이 문서를 읽고 이전 작업의 맥락을 즉시 이해한다.
기록 내용은 복잡할 필요 없다.
다음 세 가지만 있어도 충분하다.
- 오늘 무엇을 했는가
- 어떤 결정을 내렸는가
- 다음에 무엇을 할 것인가
이 문서를 git에 커밋하면
개인의 기억이 아니라 팀의 기억이 된다.
7. 병렬 관리 (Parallel Orchestration)
에이전트를 여러 개 동시에 운영하는 것도 가능하다.
예를 들어
- Agent A → 인증 시스템
- Agent B → 결제 시스템
하지만 같은 파일을 수정하면 충돌이 발생한다.
이 문제를 해결하는 방법이 git worktree다.
예시:
worktree-payment
각 에이전트가 물리적으로 다른 작업 디렉토리에서 작업하게 하면
충돌 가능성이 크게 줄어든다.
숙련된 개발자는 다음과 같은 방식으로 운영하기도 한다.
- 로컬 Claude Code 5개
- 클라우드 Claude Code 5~10개
총 10~15개의 병렬 세션을 운영하는 것이다.
이때 중요한 능력은 모든 작업의 상태를 파악하고 방향을 맞추는 오케스트레이션 능력이다.
8. 추상화 계층 설계 (Abstraction Layering)
AI 시대의 개발자는 점점 더 높은 추상화 계층에서 일하게 된다.
대략 다음과 같은 단계로 나눌 수 있다.
Level 0
직접 코딩
에디터에서 한 줄씩 작성
Level 1
에이전트 지시
Claude Code / Codex 활용
Level 2
에이전트 오케스트레이션
여러 에이전트 관리
Level 3
메타 설계
오케스트레이터 자체를 만드는 도구 구축
즉 인간의 역할은 점점 다음으로 이동한다.
- 코드를 직접 작성하는 것
→ 시스템을 설계하는 것
에이전트에게 지시하는 것
→ 에이전트가 잘 작동하는 환경을 만드는 것
이 질문을 습관화하면 좋다.
“이 작업을 에이전트에게 맡기려면 무엇이 필요할까?”
9. 감각 (Taste)
마지막으로 가장 중요한 것은 감각(Taste) 이다.
처음부터 10개의 에이전트를 운영하려고 할 필요는 없다.
다음 순서를 추천한다.
- 하나의 에이전트 워크플로우를 완벽히 만든다
- 그 다음 두 번째 에이전트를 추가한다
- 점진적으로 확장한다
AI 네이티브 개발자가 되는 가장 빠른 방법은 실험이다.
실패하고 수정하는 과정 속에서
자신만의 워크플로우가 만들어진다.
결론
서비스의 비즈니스 로직이 복잡해질수록
AI는 쉽게 맥락을 잃고 헤매기 시작한다.
그래서 인간의 역할은 사라지지 않는다.
오히려 더 중요해진다.
- 문제를 좁히는 능력
- 오류 범위를 줄이는 능력
- 작업을 분해하는 능력
- 방향을 판단하는 능력
AI가 코드를 대신 작성하게 되면서
남은 것은 결국 코드 바깥에 있던 능력들이다.
- 도메인 이해
- 요구사항 검증
- 엣지 케이스 판단
- 아키텍처 설계
결국 결론은 단순하다.
AI 시대 이전에도 중요했던 능력들이
AI 시대에 더 중요해졌다.
'AI' 카테고리의 다른 글
| AI 기반 E2E 테스트의 진화: Playwright MCP에서 CLI로 (0) | 2026.03.25 |
|---|---|
| 에이전틱 엔지니어링 시대, 인간은 어디에서 개입해야 하는가 (0) | 2026.03.16 |
| AI 에이전트를 활용한 개발 (0) | 2026.03.16 |
| Agentic Development Workflow (0) | 2026.03.16 |
| 토큰 관리 (0) | 2026.03.16 |