고급 컨텍스트 엔지니어링 for Coding Agents

발행: (2025년 12월 28일 오후 03:13 GMT+9)
10 분 소요
원문: Dev.to

Source: Dev.to

번역할 전체 텍스트를 제공해 주시면, 원본 형식과 마크다운을 유지하면서 한국어로 번역해 드리겠습니다.

문제: 생산성 ≠ 진전

대규모 개발자 설문 조사에서 일관된 패턴이 나타났습니다:

  • AI가 배포된 코드 양을 증가시킵니다
  • 코드 churn이 더 크게 증가합니다
  • 팀이 AI가 생성한 결과물을 반복적으로 재작업합니다
  • Brownfield 코드베이스가 가장 나쁜 결과를 겪습니다

AI는 그린필드 프로젝트, 프로토타입, 대시보드에서 잘 작동합니다. 그러나 레거시 제약이 있는 복잡한 시스템에서는 순진한 에이전트 사용이 기술 부채 공장이 됩니다.

이는 많은 시니어 엔지니어와 창업자들의 실제 경험과 일치합니다.


왜 이런 일이 발생하는가: 컨텍스트는 유일한 제어면

대형 언어 모델은:

  • Stateless (세션 간 메모리 없음)
  • Non‑deterministic (비결정론적)

이들은 전적으로 현재 컨텍스트 윈도우에 의해 제어됩니다. 도구 사용, 파일 편집, 환각 등 모든 결정은 현재 컨텍스트에 있는 토큰에 의해 결정됩니다.

더 나은 토큰이 들어가면 → 더 나은 토큰이 나옵니다.
더 많은 토큰이 반드시 더 나은 결과를 의미하는 것은 아닙니다.


더미 영역

컨텍스트 사용량이 증가함에 따라 모델 품질이 저하됩니다. 경험적으로 이는 작업 복잡도에 따라 ≈ 40 %의 컨텍스트 윈도우 정도에서 시작되는 경우가 많습니다. 이 구역을 더미 영역이라고 부릅니다.

일반적인 원인

  • 대용량 도구 출력(JSON, UUID, 로그)
  • 필터링되지 않은 파일 덤프
  • 반복적인 교정 루프
  • MCP가 관련 없는 데이터 덤프
  • 잡음이 많은 긴 채팅 기록

더미 영역에 들어가면 모델 품질과 관계없이 에이전트의 신뢰성이 떨어집니다.


궤적이 중요합니다

LLM은 대화 내에서 패턴을 학습합니다. 대화가 다음과 같이 전개된다면:

  1. 모델이 실수를 한다
  2. 인간이 모델을 꾸짖는다
  3. 모델이 또 다른 실수를 한다
  4. 인간이 다시 꾸짖는다

가장 가능성이 높은 다음 전개는… 다시 실수.

잘못된 궤적은 실패 모드를 강화합니다.

이것이 세션을 재시작하거나 컨텍스트를 압축하는 것이 지속적인 교정보다 더 효과적인 경우가 많은 이유입니다.


Intentional Compaction

Intentional compaction은 컨텍스트를 최소한의 고신호 표현으로 의도적으로 압축하는 것을 의미합니다. 대화가 계속해서 커지는 대신에, 여러분은:

  1. 현재 상태를 마크다운 아티팩트로 요약합니다
  2. 인간으로서 검토하고 검증합니다
  3. 그 아티팩트를 씨드로 하여 새로운 컨텍스트를 시작합니다

압축할 내용

  • 관련 파일 및 라인 범위
  • 검증된 아키텍처 동작
  • 이미 내린 결정들
  • 명시적인 제약 조건 및 비목표

압축하지 말아야 할 내용

  • 원시 로그
  • 도구 추적
  • 전체 파일 내용
  • 반복적인 오류 설명

압축은 탐색을 반복적인 비용이 아닌 일회성 비용으로 전환합니다.


Source:

서브‑에이전트는 역할이 아니라 컨텍스트에 관한 것입니다

서브‑에이전트는 자주 오해됩니다. 이들은 프론트엔드 에이전트QA 에이전트와 같은 인간 역할을 그대로 반영하는 것이 아닙니다.

서브‑에이전트의 존재 목적은 다음과 같습니다:

  • 깨끗한 컨텍스트 윈도우를 포크하기 위해
  • 대규모 탐색적 읽기를 수행하기 위해
  • 부모 에이전트에 간결하고 사실적인 요약을 반환하기 위해

예시

  • 서브‑에이전트가 큰 레포지토리를 스캔함

  • 다음과 같이 반환함:

    “Relevant logic is in foo/bar.ts:120–340, entrypoint is BazHandler

부모 에이전트는 그 요약을 기반으로 필요한 부분만 읽습니다. 이렇게 하면 컨텍스트를 확장하면서도 무능한(dumb) 영역에 빠지지 않을 수 있습니다.

The Research–Plan–Implement Workflow

This workflow is not “spec‑driven development”. That term has become semantically diffused.

RPI is about systematic compaction at every stage.

Research: Compressing Truth

Goal

  • Understand how the system actually works
  • Identify authoritative files and flows
  • Eliminate assumptions

Characteristics

  • Read code, not docs
  • Produce a short research artifact
  • Validate findings manually

If agents are not onboarded with accurate context, they will fabricate. This mirrors Memento: without memory, agents invent narratives.

Plan: Compressing Intent

Planning is the highest‑leverage activity.

A good plan:

  • Lists exact steps
  • References concrete files and snippets
  • Specifies validation after each change
  • Makes failure modes obvious

A solid plan dramatically constrains agent behavior. Bad plans produce dozens of bad lines of code; bad research produces hundreds.

Implement: Mechanical Execution

Once the plan is correct:

  • Execution becomes mechanical
  • Context remains small
  • Reliability increases

This is where token spend actually pays off.


정신적 정렬 및 코드 리뷰

코드 리뷰는 주로 공유된 이해에 관한 것이며, 구문에 관한 것이 아닙니다.

AI 출력이 확대됨에 따라 수천 줄을 검토하는 것은 지속 가능하지 않게 됩니다.

고성능 팀

  • 연구 및 계획 검토
  • 에이전트 전사본이나 AMP 스레드를 PR에 첨부
  • 정확한 단계와 테스트 결과 표시

계획을 검토함으로써 처리량이 증가해도 아키텍처 일관성을 유지할 수 있습니다.


Limits: AI Does Not Replace Thinking

AI는 이미 수행된 사고의 품질을 증폭시킵니다. 깊은 아키텍처 리팩터링이나 숨겨진 불변성을 가진 레거시 시스템과 같은 경우에는, 팀이 먼저 인간 설계로 돌아가야 합니다.

  • 완벽한 프롬프트는 없습니다.
  • 만능 해결책은 없습니다.
  • 사고는 외주를 줄 수 없습니다.

올바른 컨텍스트 엔지니어링 수준 선택

작업 유형추천 접근법
UI 수정직접 지시
소규모 기능가벼운 계획
크로스‑repo 변경연구 + 계획
대규모 리팩터링전체 RPI + 인간 설계

문제 난이도의 상한선은 컨텍스트 규율이 높아짐에 따라 상승합니다.


다음은 무엇인가

코딩 에이전트는 상품화될 것이다.

실제 과제는 적응하는 것이다:

  • 팀 워크플로우
  • SDLC 프로세스
  • 문화적 규범

이것이 없으면, 팀은 위험에 처한다:

  • 주니어가 형편없는 코드를 배포
  • 시니어가 이를 정리
  • AI 사용과 함께 기술 부채가 확대

이는 워크플로우와 리더십 문제이며, 순수한 기술적 문제는 아니다.


주요 요점

  • 맥락은 유일하게 중요한 레버이다
  • 토큰이 많을수록 정확도가 떨어지는 경우가 많다
  • 의도적인 압축은 필수이다
  • 연구와 계획이 가장 높은 ROI 활동이다
  • AI는 사고를 증폭시킬 뿐, 대체하지는 않는다

Source & Attribution

이 문서는 해당 강연을 충실히 기술적으로 각색한 것입니다.

모든 아이디어, 용어 및 프레임워크는 해당 강연에서 유래되었습니다.

Back to Blog

관련 글

더 보기 »