AI 에이전트와 함께 개발하기: Codex, Claude Code, Claude Cowork 실전 가이드

「코드를 작성하는 것」이 업무의 중심이 아니게 되었을 때, 우리는 엔지니어로서 무엇을 해야 하는가 — 8가지 교훈을 통해 배우는 안전한 위임 방법

본 기사는 아래 기사의 일본어판입니다.

지난 몇 달 동안 AI 코딩 에이전트(AI coding agent)를 사용하여 무언가를 출시해 본 경험이 있다면, 이 느낌을 기억하실 것입니다. 3줄 정도의 지시를 작성하고 커피를 타러 자리를 비웠다 돌아오면, 차이점(diff)과 테스트 결과, 그리고 변경 사항(Changelog)까지 첨부된 풀 리퀘스트(Pull Request)가 완성되어 있는 것——이는 우리 대부분이 익숙해져 온 코드베이스(codebase)와의 상호작용 방식과는 분명히 다릅니다. 그렇기 때문에 이 기술을 어떻게 사용할지에 대해서는 의도적이어야 한다고 생각합니다.

이 기사는 보도 자료가 아니라 현장의 필드 가이드(field guide)입니다. 개인 사업자나 소규모 팀이 지금 바로 손을 뻗을 법한 세 가지 에이전트 도구——OpenAI의 Codex, Anthropic의 Claude Code, 그리고 마찬가지로 Anthropic의 Claude Cowork——를 어떻게 구분하여 사용할지, 그리고 무엇보다 중요한 「에이전트로의 위임이 성공할 것인가, 아니면 실수를 가속화하는 것으로 끝날 것인가를 가르는 운영 규율」에 대해 쓰고 있습니다.

시작하기 전에 한 가지만 말씀드려 놓겠습니다. 이 분야의 모델 버전, 벤치마크 점수, 요금은 대체로 월 단위로 변화합니다. 본문 중에서 구체적인 수치를 언급하고 있는 곳에는 모두 출처 링크를 첨부하였으므로, 영구적인 사실이 아닌 「집필 시점의 스냅샷」으로 읽어 주시기 바랍니다.

지난 몇 년간 「AI를 통한 코딩 지원」이라고 하면 채팅창(chat window)을 의미했습니다. 함수를 붙여넣어 질문하고, 설명이나 스니펫(snippet)을 받은 뒤, 나머지는 복사·붙여넣기·실행·디버깅을 자신의 손으로 반복하는——그 반복이었습니다.

무엇이 변했느냐 하면, 모델이 여러 단계에 걸친 도구 이용을 충분히 수행할 수 있게 되어, 개발 루프(development loop)의 「외부」에서 지시를 내리는 것뿐만 아니라 「내부」에서 동작하는 것을 맡길 수 있게 되었다는 점입니다. 리포지토리(repository)를 클론(clone)하고, 실제 파일을 읽고, 테스트 스위트(test suite)를 실행하고, 실패를 해석하고, 코드를 편집하고, 다시 테스트를 실행하고, 풀 리퀘스트(pull request)를 여는——그 대부분을 인간이 중간 단계를 일일이 입력하지 않고도 수행할 수 있게 되었습니다. OpenAI는 Codex 출시 기사에서, 엔지니어가 「리팩터링(refactoring), 이름 변경(rename), 테스트 작성과 같이 집중을 방해하는 정형적이고 스코프(scope)가 명확한 태스크」를 오프로드(offload)할 수 있는 도구라고 Codex를 소개했습니다. 이 「에이전트는 질문에 답하는 신탁이 아니라, 한정된 작업 단위를 맡길 수 있는 동료이다」라는 파악 방식이 본 기사에서 다루는 세 가지 도구 모두에 공통되는 올바른 멘탈 모델(mental model)입니다.

우리 엔지니어들에게 실무적인 귀결은 역할의 전환입니다. 지금까지의 병목 현상(bottleneck)은 타이핑 속도와 구문 암기량이었습니다. 앞으로는 에이전트에게 주는 지시의 질과, 돌아온 결과를 얼마나 엄격하게 리뷰할 수 있는가가 에이전트와의 일주일이 잘 풀릴지를 크게 좌우합니다. 「15개의 디자인 패턴을 알고 있다」보다 소박한 기술이지만, 실제 성과를 좌우하는 것은 이쪽입니다.

이 부분은 정확히 이해해 둘 가치가 있습니다. 에이전트 도구에 대한 불만의 상당수는 이를 「똑똑해진 채팅창」으로 취급하는 데서 기인하기 때문입니다.

구분	AI 채팅	AI 코딩 에이전트
스코프 (Scope)	질문·설명·코드 스니펫	실제 리포지토리를 조사하고, 실제 파일을 편집
기억 범위	해당 대화 안에서만	실제 코드베이스, 작업 트리(working tree), git 히스토리
출력	직접 붙여넣는 텍스트나 코드 블록	diff, 커밋(commit), 풀 리퀘스트(PR), 테스트 결과
실행	없음——모두 직접 실행	테스트·lint·빌드·git 명령어를 스스로 실행
관여 정도	매 단계 필요	체크포인트를 두어 태스크 단위로 위임 가능

「스니펫을 생성하는 것」에서 「조사하고, 편집하고, 테스트하고, PR을 여는 것」으로의 이행이야말로, 지금 세대의 도구군을 중심으로 워크플로우(workflow)를 재구축할 가치가 있는 이유입니다. 동시에, 이는 실패 모드가 완전히 다르다는 것——솔직히 말해 더 무서운 것이 될 수 있다는 이유이기도 합니다. 스니펫이 틀리면 시간을 낭비할 뿐이지만, 에이전트가 파괴적인 셸(shell) 명령어나 스키마(schema) 변경을 틀리면 운영 장애로 이어질 수 있습니다. 자세한 내용은 후술하겠습니다.

Codex(2021년의 초대 Codex 모델이 아니라, 2025년에 재출시된 것)는 **격리된 비동기 실행 (isolated asynchronous execution)**을 중심으로 설계되어 있습니다. "auth 모듈의 테스트 커버리지(test coverage)를 추가한다", "이 의존성(dependency)을 업그레이드한다", "이 Issue에 기재된 버그를 수정한다"와 같은 태스크는 각각 전용 클라우드 샌드박스(sandbox) 내에서 리포지토리(repository)를 프리로드(preload)한 상태로 실행되며, 전용 git worktree를 가지기 때문에 병렬 태스크 간의 충돌이 발생하지 않습니다. 태스크를 던져두고 다른 작업으로 넘어갔다가 5~30분 후에 돌아오면, 커맨드 로그(command log), 테스트 결과, 차이점(diff, 또는 PR)이 리뷰 가능한 형태로 준비되어 있습니다.

실무상 Codex를 특징짓는 것은 다음 두 가지입니다.

• GitHub 네이티브 리뷰 루프 (GitHub-native review loop). 풀 리퀘스트(Pull Request)에 @codex review라고 코멘트하는 것만으로 자동 리뷰가 실행되며, Issue → PR 자동 생성 기능을 통해 잘 작성된 GitHub Issue가 에디터를 전혀 열지 않고도 드래프트 PR(draft PR)로 변환됩니다.
• 진정한 병렬 실행 (True parallel execution). 태스크가 샌드박스화되어 격리되어 있기 때문에, 리팩터링(refactoring), 테스트 커버리지 추가, 의존성 업데이트를 동시에 실행하더라도 작업 복사본들끼리 간섭하지 않습니다. OpenAI의 Codex 제품 페이지나 그 서브 에이전트(sub-agent) 구성을 다룬 비교 기사에 자세한 설명이 있습니다.

이러한 비동기 및 배치 지향(batch-oriented) 설계는 강점의 이면으로서 약점이 되기도 합니다. 30초마다 방향을 수정하고 싶어지는, 정말 까다로운 디버깅(debugging)처럼 밀도 높은 인터랙티브(interactive)한 상호작용을 필요로 하는 태스크에는 적합하지 않습니다.

Claude Code는 그 반대의 기본 설정을 취합니다. 로컬(local) 터미널(IDE나 브라우저를 통한 액세스도 가능)에서 동작하며, 영향력이 큰 조작 전에는 확인을 요청합니다. 설정을 하지 않는 한, 아무것도 머신 외부로 나가지 않습니다.

이러한 로컬 및 확인 우선이라는 태도 덕분에, Codex가 어려워하는 영역—낯선 코드베이스에 대한 깊은 조사, 매 단계마다 문제 이해가 업데이트되는 멀티 턴(multi-turn) 디버깅, 파일별로 차이점을 리뷰하며 진행하고 싶은 단계적인 리팩터링—에 잘 들어맞습니다. 프로젝트 루트에 두는 CLAUDE.md는 코딩 규약, 금지 사항, 테스트를 실행하는 정확한 커맨드와 같은 리포지토리 고유의 컨텍스트(context)를 세션(session)을 넘어 유지해주기 때문에 매번 다시 설명할 필요가 없습니다. 이는 세션이 길어질수록 효과가 커집니다. 최신 기능 세트는 Anthropic의 Claude Code 문서를 참조하십시오. 올해 들어 이례적인 속도로 업데이트가 이어지고 있습니다.

Cowork는 어떤 타당한 질문에 대한 Anthropic의 답변입니다. "조사하고, 행동하고, 보고하는 에이전트가 코드에 이토록 유용하다면, 왜 그것을 코드를 쓰는 사람에게만 한정할 필요가 있는가?"라는 질문에 대한 답입니다. 2026년 1월에 출시되어 Claude 데스크톱 앱에 통합된 Cowork는 동일한 에이전트 루프(파일을 읽고, 계획을 세우고, 여러 단계의 작업을 실행하고, 결과를 보고하는 과정)를 리서치, 문서 작성, 업무 워크플로(workflow)에 적용합니다. 터미널은 전혀 필요하지 않습니다. 자세한 내용은 Anthropic의 Cowork 제품 페이지를 확인하십시오.

엔지니어링 중심의 팀에게도 중요한 것은 그 플러그인 생태계(plugin ecosystem)입니다. Anthropic은 출시 시점에 11개의 오픈 소스 플러그인(생산성, 엔터프라이즈 검색, 세일즈 등)을 제공하고 있으며, 각각이 스킬, 커넥터(connector), 슬래시 커맨드(slash command)를 하나로 묶고 있어 Cowork는 맨바닥이 아니라 도메인 지식(domain knowledge)을 사전에 갖춘 상태로 시작할 수 있습니다. 많은 1인 기업가와 마찬가지로 클라이언트 리서치, 사양서 작성, 엔지니어링 작업을 혼자서 수행하고 있다면, 리서치와 문서 작성의 절반은 Cowork에, 리포지토리를 다루는 절반은 Claude Code나 Codex에 맡기는 분담이 현실적입니다. 플러그인 출시의 전체적인 모습에 대해서는 The New Stack의 기사가 참고가 될 것입니다.

모든 축에서 승리하는 도구는 없습니다. 제가 일상적으로 사용하는 대략적인 매핑은 다음과 같습니다.

태스크	사용하는 도구	이유
미지의 코드 조사	Claude Code	로컬에서의 깊이 있는 인터랙티브 (Interactive) 조사
...	@codex review로 1차 리뷰를 자동화
기술 리서치·비교 자료	Claude Cowork	리서치 → 정리 → 문서화까지 일괄 처리
설계 메모·ADR 작성	Claude Cowork	구조화된 문서 생성에 강점
README·사양서 초안	Claude Cowork	기존 파일을 읽어 들여 일관된 문서 작성

간단한 기준은 다음과 같습니다. Codex는 던져두면 알아서 처리하는 비동기 배치 (Batch) 작업에, Claude Code는 루프 안에 머물고 싶은 인터랙티브 (Interactive) 작업에, Cowork은 diff가 아닌 문서로 끝나는 작업에 적합합니다.

이러한 도구들을 사용하면서 나쁜 결과가 나오는 가장 흔한 원인은, "일단 구현해 줘"라고 갑자기 요청해 버리는 것입니다. 일관되게 좋은 결과를 만들어내는 워크플로우 (Workflow)는 다음과 같습니다.

조사한다. 무언가를 건드리기 전에, 코드베이스 (Codebase)와 변경에 따른 영향 범위를 이해시킨다. -
계획을 제안하게 한다. 코드가 아니라 접근 방식 (Approach)을 제안하게 한다. -
계획을 리뷰한다. ← 인간의 체크포인트 (Checkpoint). 파일을 건드리기 전에 접근 방식을 승인한다. -
작은 단계로 구현한다. 한 번에 여러 파일을 넘나드는 대규모 재작성이 아니라, 기능이나 파일 단위로 진행한다. -
테스트를 실행한다. 기존 테스트가 통과하는지 확인한다. -
차분 (Diff)을 리뷰한다. ← 인간의 체크포인트 (Checkpoint). 모든 행을 반드시 자신의 눈으로 읽는다. -
필요하다면 수정한다. 구체적인 문제점을 피드백하여 재구현하게 한다. -
최종 판단을 내린다. ← 인간의 체크포인트 (Checkpoint). 머지 (Merge)와 릴리스 (Release)는 인간의 판단으로 남겨둔다.

8단계 중 3단계가 명시적인 인간의 체크포인트 (Checkpoint)라는 점에 주목하십시오. 이것은 단순한 마찰이 아니라, "에이전트 = 자동 조종이 아닌 파트너"라는 사고방식이 실제 레버리지 (Leverage)를 발휘하는 지점입니다. 단 한 줄의 요청으로부터 갑자기 4단계로 뛰어넘는 것이, 제가 직접 경험하거나 읽은 거의 모든 나쁜 에이전트 경험의 근본 원인이었습니다.

돌이켜보면 상식처럼 들리지만, 그렇기 때문에 태스크 (Task) 도중에 잊기 쉽기도 합니다.

갑자기 구현으로 뛰어들지 않는다. 먼저 조사하게 하고, 변경 계획을 제안하게 한다. -
1태스크·1목적. 관계없는 여러 변경 사항을 하나의 요청에 묶지 않는다. 묶게 되면 각각을 개별적으로 평가할 수 없게 된다. -
변경 범위를 명시적으로 좁힌다. 어떤 파일과 디렉토리가 대상인지, 혹은 대상이 아닌지를 명확히 한다. -
제약 사항을 먼저 전달한다. "API 스펙은 변경하지 말 것", "새로운 의존성 (Dependency)은 추가하지 말 것" 등, 에이전트가 움직이기 전에 전달한다. 리뷰 단계에서 예상치 못한 차분을 발견하면 이미 늦다. -
테스트 실행을 반드시 지시한다. "테스트를 실행하고 결과를 보고할 것"이라고 명시적으로 요청한다. 실행되었다고 멋대로 가정하지 않는다. -
인간은 반드시 차분 (Diff)을 리뷰한다. 요약이 아무리 깔끔해 보여도, 신뢰만으로 머지 (Merge)하지 않는다. -
중요한 설계 판단을 AI에게 맡기지 않는다. 아키텍처 (Architecture)와 보안 판단은 스스로 내린다. -
해서는 안 될 일을 명시적으로 전달한다. 금지 사항은 평이한 언어로 적어둔다. 에이전트의 추측에 의존하지 않는다.

원칙은 고개를 끄덕이며 읽기는 쉽지만, 마감 압박 속에서는 잊기 마련입니다. 그래서 제가 실제로 돌려쓰고 있는 3가지 프롬프트 (Prompt)를, 사용하는 도구에 맞춰 조금씩 조정한 형태로 소개합니다.

1. 코드베이스 조사 요청 (미지의 코드에 대한 첫 번째 수단으로 항상 사용):

이 리포지토리 (Repository)를 조사하여, 로그인 처리 전체의 구조를 설명해 주세요.
아직 파일은 편집하지 마세요.
특히 다음 사항을 확인해 주세요:
...

여기서 효과를 발휘하는 두 줄은 "아직 파일은 편집하지 마세요"와 구체적인 체크리스트입니다. 전자가 없으면, 코드 이해에 자신감을 얻은 에이전트가 요청하지도 않았는데 "친절하게" 이것저것 수정하기 시작할 수 있습니다. 후자가 없으면 조사는 처음에 그럴싸해 보이는 답변에서 멈추기 쉽습니다.

2. 구현 요청 (최소 Diff의 원칙):

위의 조사 결과에 기반하여, 최소한의 차분 (Diff)으로 수정해 주세요.
제약 사항:
- 기존 API 스펙은 변경하지 말 것
...

「최소한의 차분 (Diff)」이라는 첫 문장이 상당한 역할을 합니다. 제약 없이 맡기면, 에이전트는——열정적인 신입 엔지니어와 마찬가지로——곁다리로 근처 코드까지 「개선」해 버릴 때가 있습니다. 파일 스코프 (File Scope, 여기서는 src/auth/)를 고정하는 것이 이 템플릿 전체에서 가장 레버리지가 높은 한 줄입니다.

3. 차분 리뷰 요청 (본인이 보기 전에 에이전트 스스로 셀프 리뷰를 하게 함):

현재의 차분 (Diff)을 리뷰해 주세요.
리뷰 기준:
- 사양을 충족하는가
...

이것이 앞서 언급한 원칙 6(인간에 의한 리뷰)을 대신할 수는 없지만, 구조화된 셀프 리뷰를 한 단계 거침으로써 본인의 눈에 닿기 전에 일정 비율의 문제를 발견할 수 있으며, 중요도 분류는 실제로 리뷰할 때의 우선순위 지정에도 도움이 됩니다.

이러한 도구를 도입한 팀의 누구에게 물어봐도, 혹은 어떤 기사를 읽어도 나오는 전형적인 실패 사례와 실제로 효과적인 대책을 정리했습니다.

실패 패턴	대책
관계없는 파일까지 변경함	대상 파일·디렉토리를 명시적으로 지정함
...

이것들은 모두 동일한 근본 원인으로 귀결됩니다. 작성하는 순간에는 구체적으로 느껴졌던 지시가 사실은 모호했다는 점입니다. 「로그인 처리를 수정해 줘」는 풀 액세스 권한(Full Access)을 가진 에이전트가 해석하기 시작하기 전까지는 구체적으로 느껴지는 법입니다.

짧고, 타협할 수 없는 리스트입니다.

절대로 하지 말아야 할 것:

• 프롬프트에 API 키·토큰·인증 정보를 붙여넣기
• 운영 환경(Production)에 대한 직접적인 조작 권한 부여
• 확인 없이 파괴적인 명령(rm -rf, DROP TABLE 등)을 실행하게 하기

해야 할 것:

• 자동 실행이 아닌, 제안·확인 모드부터 시작하기
• 기본값은 읽기 전용(Read-only)으로 설정하고, 신뢰가 쌓인 후에 권한을 확장하기
• 자동 실행을 허용하는 것은 스테이징(Staging) 환경으로 한정하기
• 기밀 정보는 환경 변수로 관리하고, 프롬프트에는 직접 쓰지 않기
• 위화감이 없을 때를 포함하여, 실행 로그 리뷰를 습관화하기

이 섹션에서 단 한 줄만 가져간다면——제대로 읽지 않고 확인 조작을 y로 승인하는 비용은, 그 순간에는 읽고 승인하는 비용과 같아 보입니다. 하지만 그것이 잘못되었을 경우, 일주일 후에는 완전히 다른 결과가 됩니다.

이러한 도구들이 아무리 강력해지더라도, 몇 가지 판단은 인간의 몫으로 남을 것입니다.

• 요건 정의·사양 결정— 무엇을 만들지는 비즈니스적인 판단임
• 아키텍처 결정— 시스템 전체의 설계 방침
• 보안 판단— 취약성과 리스크에 대한 최종 평가
• 품질 기준 결정— 어느 정도의 테스트 커버리지·리뷰 기준을 허용할 것인가
• 최종 리뷰— 머지(Merge) 전에 인간이 코드를 읽음
• 릴리스 결정— 운영 환경으로의 최종 출하 판단

이유는 간단합니다. 에이전트는 주어진 지시의 스코프(Scope) 내에서 최적화를 수행하지만, 비즈니스 문맥이나 조직의 제약, 혹은 어떤 리스크와 다른 리스크를 저울질하는 듯한 판단은 프롬프트로 완전히 지정할 수 없습니다. 이것은 다음 모델 릴리스에서 해결될 일시적인 제약이 아니라, 결과에 대해 책임을 지는 인간에게 판단이 남을 수밖에 없는 구조적인 이유입니다.

그 경계선의 반대편에는 적극적으로 위임할 가치가 있는 작업들이 많이 있습니다.

• 기존 코드 조사 및 변경 영향 범위 파악
• 작은 버그 수정 및 타입 에러(Type Error) 해결
• 테스트 커버리지 작성·확충
• 문서 작성(README, API 스펙)의 초안 작성
• 인간이 리뷰하기 위한 리팩터링(Refactoring) 안 작성
• PR 리뷰의 1차 대응 지원
• 코드 중복 해소 및 정형적인 클린업(Clean-up)
• 기계적인 변환 작업(타입 주석 추가, 동기 처리에서 비동기 처리로의 전환 등)

시간 절감 효과가 실제로 나타나는 지점은 바로 이곳이며, 그 효과는 결코 사소하지 않습니다. OpenAI는 자사의 엔지니어링 조직 내에서 Codex를 "리팩터링(Refactoring), 이름 변경(Rename), 테스트 작성과 같이 집중을 방해하는 정형적이고 스코프(Scope)가 명확한 태스크"의 기본 도구로 위치시키고 있다고 Codex 출시 기사에서 밝히고 있습니다. 또한, OpenAI 내부 이용 상황에 관한 보도에 따르면, 일부 워크플로(Workflow)에서는 Codex가 자사 애플리케이션 코드의 대부분을 생성하고 있다고 합니다 (LeadDev의 OpenAI 팀 인터뷰 기사 참조). 오래된 스냅샷이 아닌 현재 수치를 확인하고 싶다면, vals.ai의 SWE-bench Verified 리더보드를 북마크해 둘 가치가 있습니다. Anthropic과 OpenAI 모두 대략 월 단위로 모델을 업데이트하고 있으며, 리더보드도 그에 맞춰 변동됩니다.

업계에서 자주 인용되는 "자동화 30%"와 같은 통계에 대한 솔직한 견해는 — 방향성 측면에서는 사실이지만, 조직마다 고유하며 자신의 코드베이스에 대한 보증은 아니다 — 라는 것입니다. 언어, 테스트 커버리지(Test Coverage), 티켓(Ticket)이 얼마나 명확하게 스코프되어 있는지에 따라 실제 효과는 정말로 달라집니다.

Codex:

• 프로젝트의 규칙이나 금지 사항, 규약을 기재한 AGENTS.md를 정비한다 — 세션 시작 시 자동으로 읽어 들여집니다.
• @codex review를 가끔 수동으로 요청하는 것이 아니라, PR(Pull Request)에 대한 상설 체크로서 운용한다.
• 어려운 버그에 대해서는 --attempts 옵션을 사용하여 여러 개의 후보 해를 병렬로 생성하여 최선의 것을 선택한다 — 순차적으로 시행착오를 겪는 것보다 효율적입니다.

Claude Code:

• CLAUDE.md를 항상 최신 상태로 유지한다 — 아키텍처 개요, 금지 사항, 정확한 테스트 명령 등을 포함합니다. 이것이 장시간의 세션에서도 일관된 동작을 유지하는 열쇠가 됩니다.
• "이 파일은 무엇을 하고 있는가?"라는 의문에는 구현 방침을 결정하기 전에 전용 Explore 에이전트를 사용한다.
• 긴 세션으로 컨텍스트(Context)가 비대해지면 /compact를 사용한다 — 중요한 작업 메모리를 유지하면서 이력을 압축할 수 있습니다.
• 헤드리스 모드(claude -p)는 CI/CD 파이프라인이나 GitHub Actions 통합에 사용할 수 있어, 자동화 및 스크립트화된 실행이 가능해집니다.

Claude Cowork:

• 반복적으로 발생하는 리서치·문서 작성 계열의 워크플로에는 매번 컨텍스트를 다시 설명하는 대신 플러그인에 의존한다.
• 기존 사양서가 있는 로컬 폴더를 지정하여, 드래프트(Draft)가 일반적인 정형문이 아니라 팀의 실제 규약을 계승하도록 한다.
• 리서치 → 비교표 작성 → ADR(Architecture Decision Record) 작성이라는 파이프라인을 하나의 태스크로서 일괄적으로 맡긴다 — 이 일련의 인수인계야말로 단순한 채팅 세션에 대한 Cowork의 우위성이 발휘되는 장면입니다.

개인적인 시도 단계를 지나면:

• 신규 멤버(인간과 에이전트 모두)의 온보딩(Onboarding) 자료로 활용한다. AGENTS.md / CLAUDE.md를 리포지토리(Repository)에서 공유한다.
• PR 리뷰를 자동화한다. @codex review(또는 Claude Code 측의 동등한 기능)를 CI에組み込み(통합), 리뷰 기준을 팀으로서 표준화한다. 개개인이 제각각 기준을 만드는 것을 피한다.
• 태스크 배분을 의도적으로 최적화한다. 테스트, 타입 에러 수정, 문서 업데이트와 같은 정형 작업은 기본적으로 에이전트에게 맡긴다. 설계 및 아키텍처 논의는 인간이 주도한다.
• 코드 리뷰 기준을 양보하지 않는다. AI가 생성한 코드도 인간이 작성한 코드와 완전히 동일한 리뷰 프로세스를 거치게 한다. 차이점(Diff)이 도구에서 나온 것이라고 해서 에이전트의 출력을 비판적으로 평가하는 기술이 불필요해지는 것은 아닙니다. 팀 멤버 전원이 이 기술을 갖추어야 합니다.

아직 워크플로에 포함시키지 않았다면, 현실적인 속도는 다음과 같습니다.

1주 차 — 우선 스스로 시도한다. 개인 프로젝트에서 Claude Code나 Codex를 구동해 본다. 처음에는 조사 태스크로만 한정하고 구현은 시키지 않는다 — 파일을 수정하게 하기 전에, "좋은 계획"이란 어떤 것인지에 대한 감각을 기르기 위해서입니다.

2~4주 차 — 작은 단계부터 위임하기. 테스트 추가나 타입 에러 수정 등, 정말 작고 스코프(Scope)가 명확한 태스크를 맡깁니다. 신뢰할 수 있는 프롬프트 템플릿(Prompt Template)을 구축합니다. 모든 차이점(Diff)을 실제로 읽는 습관을 들입니다. 단순히 훑어보는 것이 아니라 말입니다.

2개월 차 이후 — 팀에 전개하기. AGENTS.md 또는 CLAUDE.md를 유지 및 공유합니다. 자동 PR 리뷰를 정비합니다. 성공 경험뿐만 아니라 아찔했던 실수(Hiyari-hatto)도 팀과 공유합니다. 실패담은 성공담만큼, 혹은 그 이상으로 배움이 됩니다.

AI 에이전트는 엔지니어의 대체재가 아닙니다. 리서치, 구현, 테스트, 리뷰 지원과 같은 작업 단위(Work Unit)를 위임할 수 있는 개발 파트너이며, 실제로 리스크를 동반하는 판단은 인간이 계속해서 쥐고 있어야 합니다.

위임이 잘 이루어지는지를 좌우하는 것은 다음 세 가지입니다.

작업을 작은 단위로 분해하기. 크고 모호한 의뢰야말로 나쁜 결과의 대부분의 근본 원인입니다.

조사 → 계획 → 구현 → 테스트 → 리뷰라는 루프를 끝까지 밟기. 구현으로 바로 건너뛰지(Shortcut) 않습니다.

AI가 작업을 수행하고, 인간이 판단과 책임을 갖기. 설계, 보안, 최종 판단은 여전히 당신의 업무로 남습니다.

앞으로 중요해질 두 가지 기술은 사실 새로운 것이 아닙니다. 명확한 지시를 작성하는 능력과, 돌아온 출력을 비판적으로 평가하는 능력입니다. 둘 다 원래부터 뛰어난 엔지니어가 갖추고 있던 기술입니다. 에이전트는 단지 그것을 '가시화'했을 뿐입니다.

참고 링크: OpenAI Codex 문서, Claude Code 문서, Claude Cowork 제품 페이지