컨텍스트 엔지니어링 - 정적 컨텍스트와 동적 컨텍스트
TL;DR
- PRD와 ADR은 다음 작업에도 적용할 기준과 제약을 남긴다.
- 임시 계획과 탐색 기록은 필요가 끝나면 정리한다.
- 코드와 테스트는 검증 가능한 결과물로 보존한다.
시작하며
에이전틱 코딩과 바이브 코딩을 하다 보면, 결국 개발의 본질로 돌아가고 있다는 생각이 든다.
비즈니스 요구사항을 코드로 바꾸는 일.
예전에는 나는 개발 컨텍스트를 [Requirement → Feature → Task → Code]1 처럼 점점 구체화되는 계층으로 나누어 관리하는 프레임워크를 이야기하곤 했다.
당시에는 중간 단계를 더 잘게 나누고, 더 많이 문서화하고, 계속 최신 상태로 유지하는 것이 중요하다고 생각했다. 모델과 도구가 지금보다 약했기 때문에, 사람이 중간 컨텍스트를 더 많이 관리해야 했기 때문이다.
요즘은 생각이 많이 바뀌었다.
1. 모델과 도구가 달라졌다
모델은 훨씬 더 똑똑해졌고, 코딩 도구들도 크게 발전했다. 이제 에이전트는 필요한 정보를 스스로 찾고, 작업 순서를 스스로 만들고, 코드베이스를 바탕으로 다음 실행 경로를 스스로 구성할 수 있다.
그래서 지금은 개발 컨텍스트를 다음과 같이, 정적인 컨텍스트와 동적인 컨텍스트로 나누어 보는 편이 좋다고 생각한다.
2. 정적인 컨텍스트
정적인 컨텍스트는 오래 유지되어야 하는 기준과 제약이다.
- PRD 는 무엇을 만들어야 하는지를 정의한다.
- ADR 은 왜 그렇게 구현하는지와 어떤 제약을 지켜야 하는지를 남긴다.
이 두 가지는 프로젝트가 살아 있는 한 계속 참조되어야 하는 정보다. 에이전트가 아무리 똑똑해져도, 무엇을 만들어야 하는지와 왜 이렇게 만들기로 했는지는 사람이 정의하고 관리해야 한다. 이것들이 흔들리면 에이전트는 매번 다른 방향으로 코드를 생성한다.
3. 동적인 컨텍스트
동적인 컨텍스트는 현재 작업을 수행하며 읽고 만드는 정보다. 여기에는 임시 실행 기록과 오래 남겨야 할 결과물이 함께 들어간다.
- Task와 탐색 기록은 현재 작업의 순서와 진행을 돕는 정보다. 다음 작업에 필요하지 않은 임시 계획과 검색 결과는 정리할 수 있다.
- Code / Test는 요구사항과 제약을 실제로 구현하고 검증하는 결과물이다. 작업 중에는 바뀌지만 완료 후에도 저장소에 남겨야 한다.
작업 중 자주 바뀐다고 해서 모두 버려도 된다는 뜻은 아니다. 나는 다음 실행에 필요한 정보인지, 이미 코드와 테스트에서 다시 확인할 수 있는 정보인지에 따라 보존할 대상을 나누는 편이 낫다고 생각한다.
4. 임시 실행 기록은 가볍게 유지한다
끝난 작업의 계획과 탐색 기록까지 계속 읽게 하면, 변경이 반복될수록 컨텍스트가 커진다. 이미 바뀐 코드에 관한 요약이 남으면 현재 코드를 읽고 판단하는 데 혼선을 줄 수도 있다.
따라서 다음 작업에 필요 없는 임시 기록은 정리하고, 코드와 테스트를 결과물로 남긴다. 작업 중 새로 정한 요구사항이나 오래 유지할 결정은 PRD와 ADR에 반영해야 한다.
진행 중인 작업을 다음 세션에 넘길 때 필요한 상태나 미해결 문제까지 지울 필요는 없다. 그 정보의 용도가 끝났는지를 먼저 확인한다.
마치며
나는 다음 작업에도 필요한 요구사항과 결정, 코드와 테스트를 남기고, 임시 계획과 탐색 기록은 필요가 끝나면 정리하려 한다.
남겨둔 코드가 다음 에이전트에게도 유용하려면 그 코드가 어떤 업무를 처리하는지 드러나야 한다. 이 부분은 [다음 글]2에서 이어서 다룬다.