<div id="readability-page-1" class="page"><div>
  <h2>컨텍스트 엔지니어링 - 정적 컨텍스트와 동적 컨텍스트</h2>
  
  <p><span>2026년 03월 11일 작성</span></p><h2 id="tldr">TL;DR</h2>

<ul>
  <li>개발 컨텍스트를 정적 컨텍스트(PRD, ADR)와 동적 컨텍스트(Task, Code/Test)로 나누어 관리하는 것이 효과적이다.</li>
  <li>정적 컨텍스트는 오래 유지되어야 하는 기준과 제약이고, 동적 컨텍스트는 실행을 위해 일시적으로 생성되고 소모되는 정보다.</li>
  <li>모델과 도구가 좋아지면서, 동적 컨텍스트는 가볍게 유지하고 가능하면 휘발시키는 것이 좋다.</li>
  <li>사람이 해야 하는 일은 좋은 요구사항, 좋은 제약, 좋은 검증 기준을 관리하는 일에 점점 가까워지고 있다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

<p>에이전틱 코딩과 바이브 코딩을 하다 보면, 결국 개발의 본질로 돌아가고 있다는 생각이 든다.</p>

<p>비즈니스 요구사항을 코드로 바꾸는 일.</p>

<p>예전에는 나는 개발 컨텍스트를 [Requirement → Feature → Task → Code]<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup> 처럼 점점 구체화되는 계층으로 나누어 관리하는 프레임워크를 이야기하곤 했다.</p>

<p>당시에는 중간 단계를 더 잘게 나누고, 더 많이 문서화하고, 계속 최신 상태로 유지하는 것이 중요하다고 생각했다. 모델과 도구가 지금보다 약했기 때문에, 사람이 중간 컨텍스트를 더 많이 관리해야 했기 때문이다.</p>

<p>요즘은 생각이 많이 바뀌었다.</p>

<h2 id="1-모델과-도구가-달라졌다">1. 모델과 도구가 달라졌다</h2>

<p>모델은 훨씬 더 똑똑해졌고, 코딩 도구들도 크게 발전했다. 이제 에이전트는 필요한 정보를 스스로 찾고, 작업 순서를 스스로 만들고, 코드베이스를 바탕으로 다음 실행 경로를 스스로 구성할 수 있다.</p>

<p>그래서 지금은 개발 컨텍스트를 다음과 같이, <strong>정적인 컨텍스트와 동적인 컨텍스트</strong>로 나누어 보는 편이 좋다고 생각한다.</p>

<h2 id="2-정적인-컨텍스트">2. 정적인 컨텍스트</h2>

<p>정적인 컨텍스트는 오래 유지되어야 하는 기준과 제약이다.</p>

<ul>
  <li><strong>PRD</strong> 는 무엇을 만들어야 하는지를 정의한다.</li>
  <li><strong>ADR</strong> 은 왜 그렇게 구현하는지와 어떤 제약을 지켜야 하는지를 남긴다.</li>
</ul>

<p>이 두 가지는 프로젝트가 살아 있는 한 계속 참조되어야 하는 정보다. 에이전트가 아무리 똑똑해져도, <strong>무엇을 만들어야 하는지</strong>와 <strong>왜 이렇게 만들기로 했는지</strong>는 사람이 정의하고 관리해야 한다. 이것들이 흔들리면 에이전트는 매번 다른 방향으로 코드를 생성한다.</p>

<h2 id="3-동적인-컨텍스트">3. 동적인 컨텍스트</h2>

<p>반면 동적인 컨텍스트는 현재 작업을 앞으로 밀어가기 위해 일시적으로 생성되고 소모되는 실행 정보다.</p>

<ul>
  <li><strong>Task</strong> 는 현재 작업을 수행하기 위해 잠깐 만들어 쓰는 실행 단위에 가깝다.</li>
  <li><strong>Code / Test</strong> 는 요구사항과 제약이 실제로 만족되었는지를 보여주는 최종 결과물이다.</li>
</ul>

<p>예전에는 이 동적인 컨텍스트도 사람이 관리해야 했다. 하지만 지금은 그렇지 않다. 구현이 끝나고 나면 중요한 것은 중간 과정의 기록 자체가 아니라, <strong>요구사항과 제약이 코드와 테스트에 제대로 반영되어 있는가</strong>이기 때문이다.</p>

<h2 id="4-동적-컨텍스트는-휘발시켜야-한다">4. 동적 컨텍스트는 휘발시켜야 한다</h2>

<p>오히려 동적인 컨텍스트를 과하게 오래 남기면, 변경이 반복될수록 문서는 계속 쌓이고, 사람이든 에이전트든 읽어야 할 컨텍스트만 커진다. 그리고 그렇게 비대해진 컨텍스트는 때로는 더 똑똑해진 에이전트의 탐색과 실행을 방해한다.</p>

<p>따라서 동적인 컨텍스트는 특성상 <strong>가볍고 명확하게 유지</strong>해야하며, 가능하면 코드와 테스트만 남기고 휘발시키는 것이 좋다고 생각한다. 그리고 똑똑해진 에이전트와 툴 덕분에 점점 휘발시킬 수 있는 컨텍스트들이 늘어나고 있다.</p>

<h2 id="마치며">마치며</h2>

<p>결국 지금 시점의 컨텍스트 엔지니어링에서 핵심은 모든 중간 과정을 오래 보존하는 것이 아니다. <strong>정적인 컨텍스트는 선명하게 유지하고, 동적인 컨텍스트는 더 휘발적으로 다루는 것.</strong></p>

<p>모델이 더 좋아지고 도구가 더 발전할수록, 사람이 해야 하는 일은 좋은 요구사항, 좋은 제약, 좋은 검증 기준을 관리하는 일에 더 가까워지는 것 같다.</p>

<p>그리고 동적 컨텍스트를 휘발시킨 뒤 남는 코드가 정말 좋은 컨텍스트가 되려면, 코드 자체가 비즈니스를 잘 설명하고 있어야 한다. 이 부분에 대해서는 [다음 글]<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" rel="footnote">2</a></sup>에서 좀 더 이야기해보려 한다.</p>

<hr>



</div></div>

Haandol

TL;DR
개발 컨텍스트를 정적 컨텍스트(PRD, ADR)와 동적 컨텍스트(Task, Code/Test)로 나누어 관리하는 것이 효과적이다.
정적 컨텍스트는 오래 유지되어야 하는 기준과 제약이고, 동적 컨텍스트는 실행을 위해 일시적으로 생성되고 소모되는 정보다.
모델과 도구가 좋아지면서, 동적 컨텍스트는 가볍게 유지하고 가능하면 휘발시키는 것이 좋다.
사람이 해야 하는 일은 좋은 요구사항, 좋은 제약, 좋은 검증 기준을 관리하는 일에 점점 가까워지고 있다.
시작하며
에이전틱 코딩과 바이브 코딩을 하다 보면, 결국 개발의 본질로 돌아가고 있다는 생각이 든다.
비즈니스 요구사항을 코드로 바꾸는 일.
예전에는 나는 개발 컨텍스트를 [Requirement → Feature → Task → Code]1 처럼 점점 구체화되는 계층으로 나누어 관리하는 프레임워크를 이야기하곤 했다.
당시에는 중간 단계를 더 잘게 나누고, 더 많이 문서화하고, 계속 최신 상태로 유지하는 것이 중요하다고 생각했다. 모델과 도구가 지금보다 약했기 때문에, 사람이 중간 컨텍스트를 더 많이 관리해야 했기 때문이다.
요즘은 생각이 많이 바뀌었다.
1. 모델과 도구가 달라졌다
모델은 훨씬 더 똑똑해졌고, 코딩 도구들도 크게 발전했다. 이제 에이전트는 필요한 정보를 스스로 찾고, 작업 순서를 스스로 만들고, 코드베이스를 바탕으로 다음 실행 경로를 스스로 구성할 수 있다.
그래서 지금은 개발 컨텍스트를 다음과 같이, 정적인 컨텍스트와 동적인 컨텍스트로 나누어 보는 편이 좋다고 생각한다.
2. 정적인 컨텍스트
정적인 컨텍스트는 오래 유지되어야 하는 기준과 제약이다.
PRD 는 무엇을 만들어야 하는지를 정의한다.
ADR 은 왜 그렇게 구현하는지와 어떤 제약을 지켜야 하는지를 남긴다.
이 두 가지는 프로젝트가 살아 있는 한 계속 참조되어야 하는 정보다. 에이전트가 아무리 똑똑해져도, 무엇을 만들어야 하는지와 왜 이렇게 만들기로 했는지는 사람이 정의하고 관리해야 한다. 이것들이 흔들리면 에이전트는 매번 다른 방향으로 코드를 생성한다.
3. 동적인 컨텍스트
반면 동적인 컨텍스트는 현재 작업을 앞으로 밀어가기 위해 일시적으로 생성되고 소모되는 실행 정보다.
Task 는 현재 작업을 수행하기 위해 잠깐 만들어 쓰는 실행 단위에 가깝다.
Code / Test 는 요구사항과 제약이 실제로 만족되었는지를 보여주는 최종 결과물이다.
예전에는 이 동적인 컨텍스트도 사람이 관리해야 했다. 하지만 지금은 그렇지 않다. 구현이 끝나고 나면 중요한 것은 중간 과정의 기록 자체가 아니라, 요구사항과 제약이 코드와 테스트에 제대로 반영되어 있는가이기 때문이다.
4. 동적 컨텍스트는 휘발시켜야 한다
오히려 동적인 컨텍스트를 과하게 오래 남기면, 변경이 반복될수록 문서는 계속 쌓이고, 사람이든 에이전트든 읽어야 할 컨텍스트만 커진다. 그리고 그렇게 비대해진 컨텍스트는 때로는 더 똑똑해진 에이전트의 탐색과 실행을 방해한다.
따라서 동적인 컨텍스트는 특성상 가볍고 명확하게 유지해야하며, 가능하면 코드와 테스트만 남기고 휘발시키는 것이 좋다고 생각한다. 그리고 똑똑해진 에이전트와 툴 덕분에 점점 휘발시킬 수 있는 컨텍스트들이 늘어나고 있다.
마치며
결국 지금 시점의 컨텍스트 엔지니어링에서 핵심은 모든 중간 과정을 오래 보존하는 것이 아니다. 정적인 컨텍스트는 선명하게 유지하고, 동적인 컨텍스트는 더 휘발적으로 다루는 것.
모델이 더 좋아지고 도구가 더 발전할수록, 사람이 해야 하는 일은 좋은 요구사항, 좋은 제약, 좋은 검증 기준을 관리하는 일에 더 가까워지는 것 같다.
그리고 동적 컨텍스트를 휘발시킨 뒤 남는 코드가 정말 좋은 컨텍스트가 되려면, 코드 자체가 비즈니스를 잘 설명하고 있어야 한다. 이 부분에 대해서는 [다음 글]2에서 좀 더 이야기해보려 한다.
RFTCR - 에이전트 주도 소프트웨어 개발을 위한 새로운 SDLC 프레임워크 ↩
에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치 ↩

컨텍스트 엔지니어링 - 정적 컨텍스트와 동적 컨텍스트

댓글