Code Agents를 효과적으로 사용하기

Source: Dev.to

Overview

LLM이 “업그레이드”될 때마다 마법과 같은 느낌이 듭니다 – 첫 인상은 언제나 강렬하죠.
코드 에이전트를 사용했을 때도 마찬가지였습니다: 모델이 내 시스템에 완벽히 맞춰서 하이퍼 컨텍스트 인식을 하고, 문제를 반복해서 작업해 결국 작동하는 솔루션을 만들어냈습니다.

가장 놀라운 점은? 에이전트가 이미 구현해 놓았기 때문에 솔루션을 이해할 필요조차 없었다는 것입니다.

하지만 언제나 그렇듯, 이 새로운 기능을 가지고 놀다 보면 곧 한계가 드러납니다. 장난 프로젝트를 넘어가면 에이전트가 큰 틈을 메우기 시작하고, 큰 레포지토리를 편집하려 할 때는 완전히 실패하는 경우가 많습니다.

최신 모델들(GPT‑5‑Codex, Sonnet 4.5)은 이제 새로운 엔지니어만큼의 역량을 갖추고 있습니다. 하지만 극히 섬세한 지시가 필요하고, 열정적인 신입 개발자처럼 자유롭게 두어서는 안 됩니다. 모델은 거의 모든 일을 해낼 만큼 똑똑하지만, 많은 협업 없이는 어렵습니다.

아래에서는 현재 최첨단 LLM과 도구들을 활용해 좋은 결과를 얻기 위해 제가 사용하고 있는 전략들을 자세히 설명합니다.

1. 컨텍스트는 금보다 더 가치 있다

큰 토큰 윈도우를 사용하더라도 모든 토큰은 결과를 망칠 수 있는 독이다. 문제는 세 가지 주요 측면에서 비롯됩니다:

가격

• 현재 Anthropic 가격 기준으로 단일 프롬프트 비용이 30달러 이상일 수 있습니다.

작업 과부하

• 모델은 시스템 프롬프트, 찾은 모든 # TODO, 모든 지시사항 등을 생각하고 있습니다.
• 이 모든 것이 복합적으로 작용해 모델을 혼란스럽게 합니다.

검색

• 각 모델은 토큰 제한을 다르게 처리합니다; 실제로는 어느 모델도 수십만 토큰을 “머리”에 진짜로 보유하고 있지 않습니다.
• 현재 검색은 LLM 발전에서 가장 중요한 영역 중 하나이며 아직 해결되지 않은 문제입니다.

2. Agent‑of‑Agents: 작동하는 “미친 해킹”

주요 에이전트가 다른 에이전트를 호출하도록 하면 세 가지 큰 이점이 있습니다:

1. 높은 품질의 답변 – 새로운 에이전트가 깨끗한 컨텍스트로 하위 작업을 처리합니다.
2. 주 에이전트 컨텍스트 축소 – 주요 에이전트의 토큰 윈도우를 가볍게 유지합니다.
3. 비용 절감 – 프롬프트가 작을수록 호출 비용이 저렴해집니다.

코드 페어링의 일반적인 워크플로우

에이전트를 사용해 업무에서 코드 페어링을 할 때 자주 발생하는 두 가지 작업이 있습니다:

• 빌드 시스템 실행
• MCP를 통한 독점 문서 읽기

두 작업 모두 적은 양의 정보만 필요하지만, 도구들은 방대한 토큰 페이로드를 내보냅니다:

• 평균 문서 페이지 ≈ 10 k 토큰
• 작은 make 빌드도 수천 개 토큰이 될 수 있습니다.

해결책: 새로운 에이전트를 생성하고 예를 들어 다음과 같이 지시합니다:

“Run make build. I edited xxx.hpp. Let me know if there are any errors.”

에이전트는 **“Your change worked”**와 같은 간결한 바이너리 피드백이나 상세한 오류 메시지를 반환합니다.

3. 모델별 강점

• Claude Code v2.0은(는) 이 패턴에 특히 뛰어납니다.
• 나는 예전에는 사이클을 직접 관리하고 새 모델을 자주 시작했지만, 이제는 같은 채팅을 유지할 수 있습니다.

“엄격한 규칙보다는 분위기와 가깝지만, 새로운 기능이 구현되고 테스트가 통과되면 저는 보통 코드를 커밋할 때와 같은 마일스톤을 따라 압축합니다.”

4. Working in Large, Proprietary Repos

• You must be extremely explicit with tasking, yet you can’t overload the model with too much info.
• Dumping all docs and folders into context lobotomizes the model.

Practical tips

1. Tell the agent exactly where to look and which path to take for implementation.
2. If you don’t know those answers, use a few different agents to gather the relevant info and help you craft a precise prompt for the execution agent.

5. “독성” 시스템‑레벨 프롬프트 피하기

나쁜 예시

“모든 Python 명령에 uv를 사용하세요.”

모델은 더 이상 Python 레포가 아니었음에도 매 단계마다 이 규칙을 기억했습니다.

권장 사항

• 광범위한 시스템‑레벨 프롬프트를 피하세요.
• 레포지토리 별로 프롬프트나 AGENTS.md를 세분화하세요.

실제 사례

오래된 레포에서 더 이상 사용되지 않는 도구가 매 빌드마다 업그레이드 경고를 출력했습니다. 모델은 그 경고가 근본 원인이라고 판단하고 최신 업데이트를 설치하려 했으며, 환경이 깨졌습니다. 저는 경고를 숨기도록 함수를 래핑해서 문제를 해결했습니다.

6. 계층형 에이전트 협업

이를 상위 수준의 하위 에이전트라고 생각하면 됩니다:

• 하나의 매니저 에이전트가 전체적인 그림을 함께 고민하고 워커 에이전트를 위한 프롬프트를 작성합니다.
• 매니저는 고수준 목표를 알고; 워커는 저수준 실행을 담당합니다.

일반적인 워크플로우

1. 두 개의 터미널을 엽니다:
   • 매니저 에이전트 – 지속적으로 실행되며 전체 목표를 파악합니다.
   • 워커 에이전트 – 컨텍스트 한도에 도달하거나 잘못된 경로로 갈 때마다 재설정됩니다.
2. 매니저와 협업하여 워커에게 전달할 프롬프트를 결정합니다.
3. 워커가 막히면 매니저가 누락된 컨텍스트나 더 높은 수준의 접근 방식을 찾아줍니다.

“이것은 매우 반복적인 과정입니다.”

현재 배치된 모델들만으로도 이를 완전히 자동화할 수 있을 정도로 충분하다고 생각합니다: 매니저 에이전트가 프로그래밍적으로 작업을 분해하고 배분할 수 있습니다. 최신 모델로 아직 테스트해 보지는 않았지만—Sonnet 4는 충분하지 않았고, Opus 4.1은 근접했습니다.

7. 자체 검증이 필수

에이전트와 챗봇의 주요 차이점은 에이전트가 자신의 작업을 스스로 검증할 수 있어야 한다는 점입니다.

• 에이전트가 코드를 빌드하고 테스트할 수 있는 명확한 경로를 제공하십시오.
• 구현 전에 테스트를 작성하십시오 (직접 혹은 다른 에이전트를 이용).
  • 테스트는 긴밀한 피드백 루프 역할을 합니다.
  • 또한 뛰어난 문서 역할을 하여, 코드가 영어 설명 블록보다 훨씬 간결해집니다.

8. TL;DR – 차이를 만드는 조합

컨텍스트를 고가의 자원으로 여기고, 전문화된 에이전트들 사이에 작업을 분할하며, 자체 검증을 강제함으로써 오늘날 최첨단 LLM으로부터 신뢰할 수 있고 비용 효율적인 결과를 얻을 수 있습니다.

답변의 품질

Anthropic은 최근 사후 보고서를 공개했으며, 인프라 버그 때문에 모델 성능이 저하되었다고 인정했습니다. 따라서 어느 날은 동작하고 다음 날은 동작하지 않는다면, 이는 아마도 당신의 잘못이 아닙니다.

누군가 새로운 업데이트를 출시하면, 직접 시도해 보면서 어떤 모드, 도구, 혹은 작업 조합이 가장 뛰어난지 확인하는 것이 좋습니다.

컨텍스트는 가깝게, 서브 에이전트는 더 가깝게 유지하세요. 가장 좋은 방법은 컨텍스트를 가능한 한 작게 유지하고, 현재 진행 경로가 좋지 않다면 완전히 재시작하는 것을 두려워하지 않는 것입니다.

다음 세대 모델에서는 이러한 것들이 중요하지 않을 것이라고 생각하지만, 모델이 출시될 때마다 나는 더 많은 것을 추적하게 됩니다. 나는 확실히 에이전트 때문에 일부 업무 라인에서 대체되었지만, 그들이 대규모로 멋진 것을 구축하는 단계까지는 아직 멀었습니다.