컨텍스트 엔지니어링: 프롬프트 이전의 작업

spinny:~/writing $ less context-engineering-agents.md

1 
2AI 에이전트의 작은 세계에서 현재의 단어는 컨텍스트 엔지니어링입니다.
3 
4우리가 이미 했던 것을 판매하기 위해 또 다른 라벨이 발명된 것 같습니다. 부분적으로 그렇습니다. 그러나 종종 발생하는 것처럼, 라벨은 실제 고통에 이름을 부여하기 때문에 인기를 얻습니다.
5 
6문제는 모델이 "생각하지 않는다"는 이유만으로 실패하지 않는다는 것입니다. 우리가 그들을 잘못된 방에 작업하도록 보내기 때문에 그들은 종종 실패합니다.
7 
8우리는 그들에게 오래된 지시를 내립니다. 우리는 그에게서 중요한 파일을 숨깁니다. 우리는 너무 긴 문서를 전달하고 무엇이 중요한지 말하지 않습니다. 우선순위 없이 로그를 표시합니다. 우리는 언제 사용하는지 설명하지 않고 10가지 도구를 제공합니다. 그러다가 마치 낯선 아파트에서 깨어난 사람처럼 에이전트가 움직이면 우리는 깜짝 놀란다.
9 
10프롬프트는 당신이 말하는 문구입니다. 맥락은 당신이 그 주위에 준비하는 세상이다.
11 
12## 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로
13 
14신속한 엔지니어링은 종종 글쓰기로 간주되었습니다. 올바른 단어를 선택하고, 올바른 방식으로 질문하고, 예를 추가하고, 형식을 지정하세요.
15 
16컨텍스트 엔지니어링은 아키텍처에 더 가깝습니다.
17 
18단순히 "요청을 어떻게 작성하나요?"라고 묻지 않습니다. 그것은 묻습니다:
19 
20- 정말 필요한 정보는 무엇인가?
21- 소음이란 무엇입니까?
22- 즉석에서 무엇을 복구해야 합니까?
23- 무엇을 기억해야 할까요?
24- 어떤 도구가 노출되어야 합니까?
25- 어떤 지침이 안정적이고 어떤 지침이 작업에 따라 달라지나요?
26- 무엇이 권위 있는 것인지 에이전트가 이해하게 하려면 어떻게 해야 합니까?
27 
28미묘하지만 엄청난 변화다. 에이전트와 작업할 때 컨텍스트는 정적 블록이 아니기 때문입니다. 모든 단계에서 변경됩니다.
29 
30에이전트는 파일을 열고, 무언가를 학습하고, 테스트를 실행하고, 오류를 수신하고, 계획을 업데이트하고, 도구를 호출하고, 종속성을 검색합니다. 각 랩마다 그는 무엇을 가지고 갈지, 무엇을 버릴지 결정해야 합니다.
31 
32이것은 엔지니어링입니다.
33 
34## 맥락은 매립지가 아니다
35 
36큰 컨텍스트 창이 있는 템플릿은 우리에게 유혹을 주었습니다. 모든 것을 던져 보겠습니다.
37 
38이해할 수 있습니다. 백만 개의 토큰이 있다면 왜 선택해야 합니까?
39 
40모든 것을 넣을 수 있다고 해서 모든 것이 도움이 되는 것은 아니기 때문입니다. 실제로 소음에는 비용이 발생합니다. 토큰 비용, 주의 비용, 대기 시간 비용, 품질 비용이 듭니다. 우리가 탭 20개를 열었는데 더 이상 이유를 기억하지 못하는 것처럼 모델도 관련 없는 세부 사항에 빠져 있을 수 있습니다.
41 
42좋은 컨텍스트에는 계층 구조가 있습니다.
43 
441. 시스템 지침 및 정책
452. 구체적인 목적
463. 현황
474. 관련 데이터
485. 제약사항
496. 사용 가능한 도구
507. 이미 내린 결정을 추적하십시오.
51 
52모든 것을 동일한 수준에서 다룰 필요는 없습니다. 사용자 명령은 이전 메모보다 더 가치가 있습니다. 실패한 테스트는 이제 3개월 전의 미학적 선호보다 더 가치가 있습니다. 보안 정책은 생산 지름길보다 더 가치가 있습니다.
53 
54컨텍스트 엔지니어링은 데이터뿐만 아니라 가중치를 부여하는 것을 의미하기도 합니다.
55 
56## 기억력: 적게 기억하고 더 잘 기억하세요
57 
58에이전트의 기억은 가장 미끄러운 주제 중 하나입니다.
59 
60사용자로서 귀하는 상담원이 귀하를 알기를 원합니다. 당신은 그가 어조, 계획, 관습, 이미 결정된 사항을 기억하기를 원합니다. 엔지니어로서 여러분은 모든 영구 메모리도 위험하다는 것을 알고 있습니다. 이는 틀릴 수도 있고, 오래되고, 너무 개인적일 수도 있고, 너무 일반적일 수도 있고, 검증할 수 없을 수도 있습니다.
61 
62유용한 기억에는 최소한 세 가지 특성이 있어야 합니다.
63 
64- 출처: 이 정보는 어디에서 오는가?
65- 날짜: 언제 사실이었나요?
66- 목적: 어떤 유형의 작업에 사용해야 합니까?
67 
68이 세 가지가 없으면 기억은 미신이 됩니다.
69 
70나는 행위자 기억을 마법의 마음이 아닌 통합 문서로 생각하고 싶습니다. 임시 메모, 확정된 결정, 스타일 선호도, 기술적 제약, 소스 링크가 있습니다. 어떤 것들은 만료됩니다. 일부는 다시 작성해야 합니다. 일부는 에이전트가 잘못 추론했기 때문에 제거되어야 합니다.
71 
72좋은 시스템은 이러한 유지 관리를 정상적으로 수행해야 합니다. 영웅적이지 않습니다.
73 
74## 검색과 도구는 같은 것이 아닙니다
75 
76맥락에 대해 이야기할 때 우리는 종종 즉시 RAG에 도달하게 됩니다. 임베딩, 벡터 데이터베이스, 청킹, 순위 재지정.
77 
78모두 유용합니다. 그러나 검색은 모델에 정보를 가져오는 한 가지 방법일 뿐입니다. 그는 유일한 사람이 아닙니다.
79 
80에이전트는 파일 읽기, API 쿼리, MCP 서버 호출, 브라우저 열기, 테스트 실행, Slack 검색, 대시보드 보기, 사람에게 질문하여 컨텍스트를 얻을 수 있습니다.
81 
82흥미로운 부분은 어떤 경로를 언제 사용할지 결정하는 것입니다.
83 
84에이전트가 과거 질문에 답해야 하는 경우 검색만으로도 충분할 수 있습니다. 버그를 수정하려면 실제 코드를 읽어야 합니다. 배포가 실패한 이유를 이해하려면 최신 로그를 살펴봐야 합니다. 고객에게 편지를 보내야 하는 경우 티켓의 톤, 내역 및 상태를 검색해야 합니다. 생산에 관해 조치를 취해야 한다면 허가를 받아야 합니다.
85 
86컨텍스트는 데이터베이스가 아닙니다. 워크플로입니다.
87 
88## 좋은 상담원은 무시할 줄도 안다
89 
90상담원의 성숙함의 표시는 다음과 같이 말할 수 있는 능력입니다. 이 정보는 필요하지 않습니다.
91 
92사소한 것 같지만 매우 어렵습니다. 많은 에이전트 시스템이 축적됩니다. 각 도구 호출은 텍스트를 추가합니다. 모든 오류는 버퍼에 남아 있습니다. 읽은 각 파일이 스택에 추가됩니다. 결국 모델은 매우 오랜 역사를 갖고 있고 지도가 없습니다.
93 
94압축이 필요합니다. 중간 합성이 필요합니다. 구조화되어야합니다.
95 
96"그게 다 일어난 일"이 아니라 다음과 같습니다.
97 
98- 목표는 여전히 유효합니다.
99- 현재 가설;
100- 이미 검사된 파일;
101- 결정이 내려졌습니다.
102- 공개 위험;
103- 다음 행동.
104 
105이렇게 하면 에이전트가 덜 연극적이고 더 유용해집니다. 그가 더 똑똑해 보여서가 아니라 깔끔한 책상에서 일하기 때문이다.
106 
107## 프롬프트 아티스트가 아닌 팀을 위한 컨텍스트 엔지니어링
108 
109이 주제가 제가 관심을 갖는 이유는 책임이 개인에서 시스템으로 옮겨지기 때문입니다.
110 
111신속한 엔지니어링에서는 모델과 가장 잘 대화할 수 있는 사람이 승리하는 경우가 많습니다. 컨텍스트 엔지니어링에서는 문서화, 규칙, 문제, 로그, 테스트, 소유권, 이름 지정, 소스 등 작업을 가장 잘 구성하는 팀이 승리합니다.
112 
113깨끗한 저장소가 더 나은 컨텍스트가 됩니다. 잘 작성된 이슈는 더 나은 연료가 됩니다. 업데이트된 Runbook은 토큰과 불안을 줄여줍니다. 명확한 변경 로그는 환각을 줄여줍니다.
114 
115좋은 소식이면서 다소 불편한 소식입니다. 좋은 관행에 대한 보상을 주기 때문에 아름답습니다. 영리한 프롬프트로 모든 것을 해결할 수 없기 때문에 불편합니다.
116 
117에이전트는 자신이 찾은 시스템의 위생 상태를 증폭시킵니다.
118 
119## 내일 어떻게 적용할까
120 
121실제 프로젝트에 컨텍스트 엔지니어링을 도입한다면 작은 것부터 시작하겠습니다.
122 
123- 짧고 유지 관리되는 프로젝트 지침 파일
124- 예상되는 결과의 좋은 예
125- 사용 가능한 도구 및 이를 사용할 수 있는 사례 목록
126- 인용 가능한 방식으로 작성된 아키텍처 결정;
127- 최소한의 필수 컨텍스트가 있는 문제
128- 로그 및 테스트를 쉽게 검색할 수 있습니다.
129- 인간이 수정할 수 있는 영구 메모리.
130 
131그런 다음 간단한 것을 측정합니다. 상담원이 몇 번이나 설명을 요청해야 하는지 아니면 잘못된 방향으로 가는지 측정합니다.
132 
133자주 발생한다면 더 큰 모델을 즉시 추가하지 않을 것입니다. 맥락을 살펴보겠습니다.
134 
135## 내가 읽은 책
136 
137컨텍스트 엔지니어링은 약간 과장된 단어입니다. 그러나 개념은 건전합니다.
138 
139이는 에이전트의 지능이 모델에만 있는 것이 아니라는 점을 상기시켜 줍니다. 우리가 그를 위해 준비하는 것은 환경에 있습니다. 그가 보는 것, 기억하는 것, 할 수 있는 것, 금지된 것, 그가 진실이라고 인식하는 출처.
140 
141인간적인 부분은 이것이다: 상황을 잘 준비하는 것은 배려의 한 형태이다. 이는 에이전트뿐만 아니라 팀에도 "당신이 추측하기를 원하지 않습니다. 당신이 필요한 것을 갖기를 바랍니다."라고 말하는 것입니다.
142 
143마법이 덜합니다. 청정실. 상담원도 우리만큼 필요합니다.
144 
145## 소스
146 
147- [LangChain 블로그: 컨텍스트 엔지니어링의 부상](https://blog.langchain.com/the-rise-of-context-engineering/)
148- [사이먼 윌리슨: 컨텍스트 엔지니어링](https://simonwillison.net/2025/Jun/27/context-engineering/)
149- [모델 컨텍스트 프로토콜: 소개](https://modelcontextprotocol.io/introduction)
150- [Anthropic: 효과적인 에이전트 구축](https://www.anthropic.com/engineering/building- Effective-agents)
151- [OpenAI: 에이전트 구축을 위한 새로운 도구](https://openai.com/index/new-tools-for-building-agents/)
152

:컨텍스트 엔지니어링: 프롬프트 이전의 작업lines 1-152 (END) — press q to close

2AI 에이전트의 작은 세계에서 현재의 단어는 컨텍스트 엔지니어링입니다.

4우리가 이미 했던 것을 판매하기 위해 또 다른 라벨이 발명된 것 같습니다. 부분적으로 그렇습니다. 그러나 종종 발생하는 것처럼, 라벨은 실제 고통에 이름을 부여하기 때문에 인기를 얻습니다.

6문제는 모델이 "생각하지 않는다"는 이유만으로 실패하지 않는다는 것입니다. 우리가 그들을 잘못된 방에 작업하도록 보내기 때문에 그들은 종종 실패합니다.

8우리는 그들에게 오래된 지시를 내립니다. 우리는 그에게서 중요한 파일을 숨깁니다. 우리는 너무 긴 문서를 전달하고 무엇이 중요한지 말하지 않습니다. 우선순위 없이 로그를 표시합니다. 우리는 언제 사용하는지 설명하지 않고 10가지 도구를 제공합니다. 그러다가 마치 낯선 아파트에서 깨어난 사람처럼 에이전트가 움직이면 우리는 깜짝 놀란다.

10프롬프트는 당신이 말하는 문구입니다. 맥락은 당신이 그 주위에 준비하는 세상이다.

12## 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

14신속한 엔지니어링은 종종 글쓰기로 간주되었습니다. 올바른 단어를 선택하고, 올바른 방식으로 질문하고, 예를 추가하고, 형식을 지정하세요.

16컨텍스트 엔지니어링은 아키텍처에 더 가깝습니다.

18단순히 "요청을 어떻게 작성하나요?"라고 묻지 않습니다. 그것은 묻습니다:

20- 정말 필요한 정보는 무엇인가?

21- 소음이란 무엇입니까?

22- 즉석에서 무엇을 복구해야 합니까?

23- 무엇을 기억해야 할까요?

24- 어떤 도구가 노출되어야 합니까?

25- 어떤 지침이 안정적이고 어떤 지침이 작업에 따라 달라지나요?

26- 무엇이 권위 있는 것인지 에이전트가 이해하게 하려면 어떻게 해야 합니까?

28미묘하지만 엄청난 변화다. 에이전트와 작업할 때 컨텍스트는 정적 블록이 아니기 때문입니다. 모든 단계에서 변경됩니다.

30에이전트는 파일을 열고, 무언가를 학습하고, 테스트를 실행하고, 오류를 수신하고, 계획을 업데이트하고, 도구를 호출하고, 종속성을 검색합니다. 각 랩마다 그는 무엇을 가지고 갈지, 무엇을 버릴지 결정해야 합니다.

32이것은 엔지니어링입니다.

34## 맥락은 매립지가 아니다

36큰 컨텍스트 창이 있는 템플릿은 우리에게 유혹을 주었습니다. 모든 것을 던져 보겠습니다.

38이해할 수 있습니다. 백만 개의 토큰이 있다면 왜 선택해야 합니까?

40모든 것을 넣을 수 있다고 해서 모든 것이 도움이 되는 것은 아니기 때문입니다. 실제로 소음에는 비용이 발생합니다. 토큰 비용, 주의 비용, 대기 시간 비용, 품질 비용이 듭니다. 우리가 탭 20개를 열었는데 더 이상 이유를 기억하지 못하는 것처럼 모델도 관련 없는 세부 사항에 빠져 있을 수 있습니다.

42좋은 컨텍스트에는 계층 구조가 있습니다.

441. 시스템 지침 및 정책

452. 구체적인 목적

463. 현황

474. 관련 데이터

485. 제약사항

496. 사용 가능한 도구

507. 이미 내린 결정을 추적하십시오.

52모든 것을 동일한 수준에서 다룰 필요는 없습니다. 사용자 명령은 이전 메모보다 더 가치가 있습니다. 실패한 테스트는 이제 3개월 전의 미학적 선호보다 더 가치가 있습니다. 보안 정책은 생산 지름길보다 더 가치가 있습니다.

54컨텍스트 엔지니어링은 데이터뿐만 아니라 가중치를 부여하는 것을 의미하기도 합니다.

56## 기억력: 적게 기억하고 더 잘 기억하세요

58에이전트의 기억은 가장 미끄러운 주제 중 하나입니다.

60사용자로서 귀하는 상담원이 귀하를 알기를 원합니다. 당신은 그가 어조, 계획, 관습, 이미 결정된 사항을 기억하기를 원합니다. 엔지니어로서 여러분은 모든 영구 메모리도 위험하다는 것을 알고 있습니다. 이는 틀릴 수도 있고, 오래되고, 너무 개인적일 수도 있고, 너무 일반적일 수도 있고, 검증할 수 없을 수도 있습니다.

62유용한 기억에는 최소한 세 가지 특성이 있어야 합니다.

64- 출처: 이 정보는 어디에서 오는가?

65- 날짜: 언제 사실이었나요?

66- 목적: 어떤 유형의 작업에 사용해야 합니까?

68이 세 가지가 없으면 기억은 미신이 됩니다.

70나는 행위자 기억을 마법의 마음이 아닌 통합 문서로 생각하고 싶습니다. 임시 메모, 확정된 결정, 스타일 선호도, 기술적 제약, 소스 링크가 있습니다. 어떤 것들은 만료됩니다. 일부는 다시 작성해야 합니다. 일부는 에이전트가 잘못 추론했기 때문에 제거되어야 합니다.

72좋은 시스템은 이러한 유지 관리를 정상적으로 수행해야 합니다. 영웅적이지 않습니다.

74## 검색과 도구는 같은 것이 아닙니다

76맥락에 대해 이야기할 때 우리는 종종 즉시 RAG에 도달하게 됩니다. 임베딩, 벡터 데이터베이스, 청킹, 순위 재지정.

78모두 유용합니다. 그러나 검색은 모델에 정보를 가져오는 한 가지 방법일 뿐입니다. 그는 유일한 사람이 아닙니다.

80에이전트는 파일 읽기, API 쿼리, MCP 서버 호출, 브라우저 열기, 테스트 실행, Slack 검색, 대시보드 보기, 사람에게 질문하여 컨텍스트를 얻을 수 있습니다.

82흥미로운 부분은 어떤 경로를 언제 사용할지 결정하는 것입니다.

84에이전트가 과거 질문에 답해야 하는 경우 검색만으로도 충분할 수 있습니다. 버그를 수정하려면 실제 코드를 읽어야 합니다. 배포가 실패한 이유를 이해하려면 최신 로그를 살펴봐야 합니다. 고객에게 편지를 보내야 하는 경우 티켓의 톤, 내역 및 상태를 검색해야 합니다. 생산에 관해 조치를 취해야 한다면 허가를 받아야 합니다.

86컨텍스트는 데이터베이스가 아닙니다. 워크플로입니다.

88## 좋은 상담원은 무시할 줄도 안다

90상담원의 성숙함의 표시는 다음과 같이 말할 수 있는 능력입니다. 이 정보는 필요하지 않습니다.

92사소한 것 같지만 매우 어렵습니다. 많은 에이전트 시스템이 축적됩니다. 각 도구 호출은 텍스트를 추가합니다. 모든 오류는 버퍼에 남아 있습니다. 읽은 각 파일이 스택에 추가됩니다. 결국 모델은 매우 오랜 역사를 갖고 있고 지도가 없습니다.

94압축이 필요합니다. 중간 합성이 필요합니다. 구조화되어야합니다.

96"그게 다 일어난 일"이 아니라 다음과 같습니다.

98- 목표는 여전히 유효합니다.

99- 현재 가설;

100- 이미 검사된 파일;

101- 결정이 내려졌습니다.

102- 공개 위험;

103- 다음 행동.

104

105이렇게 하면 에이전트가 덜 연극적이고 더 유용해집니다. 그가 더 똑똑해 보여서가 아니라 깔끔한 책상에서 일하기 때문이다.

106

107## 프롬프트 아티스트가 아닌 팀을 위한 컨텍스트 엔지니어링

108

109이 주제가 제가 관심을 갖는 이유는 책임이 개인에서 시스템으로 옮겨지기 때문입니다.

110

111신속한 엔지니어링에서는 모델과 가장 잘 대화할 수 있는 사람이 승리하는 경우가 많습니다. 컨텍스트 엔지니어링에서는 문서화, 규칙, 문제, 로그, 테스트, 소유권, 이름 지정, 소스 등 작업을 가장 잘 구성하는 팀이 승리합니다.

112

113깨끗한 저장소가 더 나은 컨텍스트가 됩니다. 잘 작성된 이슈는 더 나은 연료가 됩니다. 업데이트된 Runbook은 토큰과 불안을 줄여줍니다. 명확한 변경 로그는 환각을 줄여줍니다.

114

115좋은 소식이면서 다소 불편한 소식입니다. 좋은 관행에 대한 보상을 주기 때문에 아름답습니다. 영리한 프롬프트로 모든 것을 해결할 수 없기 때문에 불편합니다.

116

117에이전트는 자신이 찾은 시스템의 위생 상태를 증폭시킵니다.

118

119## 내일 어떻게 적용할까

120

121실제 프로젝트에 컨텍스트 엔지니어링을 도입한다면 작은 것부터 시작하겠습니다.

122

123- 짧고 유지 관리되는 프로젝트 지침 파일

124- 예상되는 결과의 좋은 예

125- 사용 가능한 도구 및 이를 사용할 수 있는 사례 목록

126- 인용 가능한 방식으로 작성된 아키텍처 결정;

127- 최소한의 필수 컨텍스트가 있는 문제

128- 로그 및 테스트를 쉽게 검색할 수 있습니다.

129- 인간이 수정할 수 있는 영구 메모리.

130

131그런 다음 간단한 것을 측정합니다. 상담원이 몇 번이나 설명을 요청해야 하는지 아니면 잘못된 방향으로 가는지 측정합니다.

132

133자주 발생한다면 더 큰 모델을 즉시 추가하지 않을 것입니다. 맥락을 살펴보겠습니다.

134

135## 내가 읽은 책

136

137컨텍스트 엔지니어링은 약간 과장된 단어입니다. 그러나 개념은 건전합니다.

138

139이는 에이전트의 지능이 모델에만 있는 것이 아니라는 점을 상기시켜 줍니다. 우리가 그를 위해 준비하는 것은 환경에 있습니다. 그가 보는 것, 기억하는 것, 할 수 있는 것, 금지된 것, 그가 진실이라고 인식하는 출처.

140

141인간적인 부분은 이것이다: 상황을 잘 준비하는 것은 배려의 한 형태이다. 이는 에이전트뿐만 아니라 팀에도 "당신이 추측하기를 원하지 않습니다. 당신이 필요한 것을 갖기를 바랍니다."라고 말하는 것입니다.

142

143마법이 덜합니다. 청정실. 상담원도 우리만큼 필요합니다.

144

145## 소스

146

147- [LangChain 블로그: 컨텍스트 엔지니어링의 부상](https://blog.langchain.com/the-rise-of-context-engineering/)

148- [사이먼 윌리슨: 컨텍스트 엔지니어링](https://simonwillison.net/2025/Jun/27/context-engineering/)

149- [모델 컨텍스트 프로토콜: 소개](https://modelcontextprotocol.io/introduction)

150- [Anthropic: 효과적인 에이전트 구축](https://www.anthropic.com/engineering/building- Effective-agents)

151- [OpenAI: 에이전트 구축을 위한 새로운 도구](https://openai.com/index/new-tools-for-building-agents/)

152