본문으로 건너뛰기

4부: 작업 실행하기

규칙 파일, 엔지니어링된 컨텍스트, 그리고 검증 체계까지 갖추었습니다. 이제 실제로 작업을 수행합니다. 얼마나 잘 진행될지를 결정하는 두 가지 질문이 있습니다. 어느 모드에 있는지, 그리고 해당 작업에 어떤 종류의 에이전트가 적합한지입니다.

두 가지 모드: 지휘자와 오케스트레이터​

대부분의 개발자는 하루 내내 두 가지 모드를 오갑니다. 각각 다른 역량을 요구하며, 작업에 맞지 않는 모드를 사용하면 흔히 불만의 원인이 됩니다.

지휘자 모드는 실시간이고 직접적입니다. 에디터에서 코드가 생성되는 것을 보며, 프롬프트와 수정으로 방향을 잡고, 세밀한 제어를 유지합니다. 변경 사항이 만들어질 때마다 모든 내용을 이해합니다.

  • 적합한 경우: 복잡한 로직, 까다로운 디버깅, 낯선 코드베이스 — 각 단계를 이해해야 하는 모든 상황.
  • 위험 요소: 모든 키 입력을 직접 지시하면 여러분 자신이 병목이 되어 속도 향상 효과가 사라집니다.

오케스트레이터 모드는 비동기적이고 상위 수준입니다. 목표를 정의하고 에이전트에게 넘긴 뒤 키 입력이 아닌 결과를 검토합니다. 에이전트는 백그라운드에서, 병렬로, 코드베이스의 서로 다른 부분에서 실행될 수 있습니다.

  • 적합한 경우: 명확하게 명세된 작업 — 버그 수정, 마이그레이션, 테스트 생성, 확립된 패턴을 따르는 기능.
  • 주의 사항: 사전에 더 많은 규율이 필요합니다. 적은 것이 아닙니다. 위임하기 전에 정확한 명세를 작성해야 합니다. 보상은 첫 번째 작업이 아니라 두 번째 작업에서 옵니다.

오케스트레이터 모드는 문법 유창성과는 다른 역량을 요구합니다.

  • 명세 작성 — 에이전트가 추측 없이 실행할 수 있을 만큼 정확하게 작업을 정의합니다.
  • 분해 — 큰 작업을 에이전트 단위의 크기로 나눕니다.
  • 평가 — 출력 품질을 신속하게 판단합니다.
  • 시스템 설계 — 에이전트를 생산적으로 유지하는 제약 조건과 피드백 루프를 구축합니다.

하루 중 에이전트가 맞는 세 가지 위치​

같은 그림을 다른 방식으로 나누면, 에이전트는 세 가지 위치에서 등장합니다. 대부분의 사람들은 세 가지 모두를 사용합니다.

  • 에디터 안에서 — 전체 코드베이스 인식을 갖춘 인라인 자동완성과 인플레이스 채팅. 흐름을 유지하는 곳입니다. (Copilot, Cursor, Windsurf, JetBrains AI.)
  • 터미널 안에서 — 에이전트를 실행하고 평문으로 목표를 건넨 뒤, 파일을 넘나들며 도구와 테스트를 실행하고 결과에 반응하도록 맡깁니다. 본격적인 실무 작업이 이루어지는 곳입니다. (Claude Code, Codex CLI 등.)
  • 백그라운드에서 — 에이전트가 샌드박스에서 자율적으로, 때로는 몇 시간 동안 실행되고 나중에 검토할 풀 리퀘스트를 반환합니다. (Jules, Copilot 에이전트 모드, Cursor 백그라운드 에이전트.)

이 매핑은 한 번 이해하면 직관적입니다. 에디터 에이전트는 코드를 작성하는 동안, 터미널 에이전트는 다중 파일 탐색과 실행-반응, 백그라운드 에이전트는 한 문단으로 설명하고 자리를 떠날 수 있는 모든 작업에 적합합니다. 올바른 출발점은 가장 높은 자율성을 주장하는 도구가 아니라 작업 자체입니다.

샌드박스 안에서 실행하기​

에이전트가 코드를 실행할 때 — 테스트를 실행하거나, 수정을 시도하거나, 파일을 읽을 때 — 정의된 제한적인 도구와 접근 권한을 가진 격리된 샌드박스 안에서 실행해야 합니다. 이것이 자율적인 "생각 → 행동 → 관찰" 루프를 안전하게 만드는 것입니다. 에이전트가 시도하고 실패하더라도 건드려서는 안 될 것에 영향을 미치지 않습니다.

80% 문제 (어디서 잘못되는가)​

에이전트는 기능의 약 80%를 빠르게 생성합니다. 나머지 20% — 엣지 케이스, 오류 처리, 통합 지점, 미묘한 정확성 — 는 모델이 대체로 부족한 깊은 컨텍스트를 필요로 합니다. 그리고 이것이 정확히 프로덕션 장애가 발생하는 곳입니다.

위험의 양상이 바뀌었습니다. 초기 AI 오류는 명백한 문법 실수였습니다. 오늘날의 오류는 개념적입니다. 비즈니스 로직에 대한 잘못된 가정, 놓친 엣지 케이스, 조용히 유지보수 부채를 쌓아가는 아키텍처 선택. 코드가 올바르게 보이고 기본 테스트조차 통과할 수 있기 때문에 정확히 잡아내기 어렵습니다.

구체적으로 살펴보면:

# The agent's 80%: looks correct, passes the happy-path test
def apply_discount(price, percent):
    return price * (1 - percent / 100)

누락된 20%는 에이전트가 물어볼 줄 몰랐던 모든 것입니다. percent가 100을 초과할 수 있습니까? price는 정수 센트 값입니까 아니면 부동소수점입니까? 어떤 통화 반올림이 적용됩니까? 100% 할인이 허용됩니까, 아니면 업스트림의 버그를 나타내는 것입니까? 이 중 어느 것도 코드에서는 보이지 않습니다. 여러분이 보유하고 있지만 모델은 갖지 못한 비즈니스 규칙입니다.

잘하는 개발자들은 모든 것을 수락하여 더 빠르게 가려 하지 않습니다. 명확하게 명세된 80%에는 에이전트를 사용하고, 판단이 필요한 20%에는 자신의 주의를 집중합니다.

자신만의 워크플로우 구성하기​

  • 작업 전, 지휘자 모드와 오케스트레이터 모드 중 하나를 의식적으로 선택하십시오. 그리고 위임했어야 할 작업을 직접 지휘하고 있는 순간을 알아차리십시오.
  • 에이전트 위치를 작업에 맞게 선택하십시오. 흐름 중에는 에디터, 다중 파일 작업에는 터미널, 자리를 떠날 수 있는 작업에는 백그라운드.
  • 코드 실행이 범위가 제한된 접근 권한을 가진 샌드박스에서 이루어지는지 확인하십시오.
  • 모든 기능에 대해 20% — 엣지 케이스와 비즈니스 규칙 — 를 직접 작성하고, 테스트가 통과되더라도 해당 부분은 직접 검토하십시오.