- Published on
컨텍스트 엔지니어링이란?
- Authors
- Name
- junyeol kim
최근 국내 기술 블로그들을 보면 토스와 우아한형제들이 비슷한 시기에 각자 독립적으로 같은 주제를 다뤘습니다. 바로 **컨텍스트 엔지니어링(Context Engineering)**입니다. 두 회사가 동시에 같은 키워드에 도달했다는 건, 그만큼 실무에서 부딪히는 문제라는 뜻이라 정리해봤습니다.
🤔 프롬프트 엔지니어링과 뭐가 다른가
"프롬프트를 잘 쓰면 되는 거 아닌가?" 싶었는데, 둘은 다루는 범위 자체가 다릅니다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 초점 | 문장을 얼마나 잘 쓰느냐 | 컨텍스트 창에 무엇을, 어떤 순서로 채우느냐 |
| 대상 | 지시문 한 줄 | 시스템 프롬프트, 대화 이력, 툴 결과, 검색된 지식 전체 |
| 목표 | 첫 번째 좋은 답 얻기 | 1000번째 답도 여전히 좋게 유지하기 |
| 실패 원인 진단 | "지시가 부족했나?" | "모델이 지금 뭘 보고 있는가?" |
즉 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 부분집합입니다. 지시문을 다듬는 것도 결국 "컨텍스트 창 안에서" 하는 일이니까요.
📐 왜 이게 문제가 되나
LLM은 컨텍스트가 길어질수록 중간에 있는 정보를 놓치는 경향이 있습니다. 그래서 정보를 무작정 많이 넣는다고 정확도가 올라가지 않고, 오히려 관련 없는 내용이 섞이면 주의(attention)가 분산돼 성능이 떨어집니다. 핵심 원칙은 단순합니다.
- 관련 있는 정보만 넣기: 넣는다고 다 도움되는 게 아니라, 과한 정보는 오히려 정확도를 깎아먹음
- 위치가 중요함: 중요한 지시는 앞이나 뒤에 — 중간에 묻히면 무시되기 쉬움
- 구조화하기: 규칙 6개가 뭉친 긴 문장 하나보다, 원자적으로 쪼갠 지시가 더 잘 지켜짐
- 절차보다 목표 정의: "이렇게 저렇게 해라"보다 "이런 결과가 좋은 결과다"를 정의하는 게 요즘 모델엔 더 잘 먹힘
🏦 토스 사례: Topic 시스템
토스가 겪은 문제는 이거였습니다. LLM은 일반 지식은 잘 답하는데, 회사 내부 정책이나 특정 기능의 구현 여부처럼 회사 고유의 정보는 잘 모릅니다. 문서, 코드, 메신저 여기저기 흩어져 있고, 뭐가 최신이고 뭐가 상충하는지조차 검색만으론 알기 어렵기 때문입니다.
그래서 검색 성능을 올리는 대신, 정보 소스를 연결하면서 불확실성과 충돌을 명시적으로 추적하는 레이어인 Topic을 만들었습니다. 문서는 마크다운 헤딩 구조로, 메신저는 개별 메시지가 아니라 스레드 단위로 요약하되 기술 식별자와 결정 상태는 보존, 코드는 심볼 단위로 파싱한 뒤 여러 함수에 걸친 실제 비즈니스 동작까지 설명을 붙이는 식입니다.
그리고 특이한 점은, 신뢰도를 하나의 점수로 뭉개지 않고 6가지 축으로 나눴다는 겁니다.
| 축 | 질문 |
|---|---|
| Granularity | 이게 하나의 일관된 단위인가? |
| Faithfulness | 원본이 실제로 이 주장을 뒷받침하는가? |
| Staleness | 이 정보가 아직 유효한가? |
| Canonicality | 같은 개념이 중복 관리되고 있진 않은가? |
| Consistency | 여러 소스가 공존할 수 있는가? |
| Coverage | 중요한 관점이 빠지진 않았는가? |
충돌하는 정보가 있을 때 자동으로 하나를 고르지 않고, 원본·시점·근거와 함께 충돌 상태 그대로 남겨서 사람이 판단하게 하는 것도 인상적이었습니다.
🎨 우아한형제들 사례: 디자인 시스템 코드 생성
우아한형제들은 디자인 시스템 기반 MCP 서버 코드 생성에서 비슷한 문제를 겪었습니다. 가이드라인을 아무리 자세히 써줘도 결과물이 들쭉날쭉했던 겁니다. 원인은 "지시가 부족해서"가 아니라 LLM이 텍스트를 처리하는 방식 자체였습니다.
- 간격 관련 규칙을 건너뛰고 디자인 토큰 대신
10.dp같은 값을 그냥 씀 - 컴포넌트 선택이 일관되지 않고, 시스템 타이포그래피 대신 커스텀 스타일을 생성
- 아이콘 처리·크기 계산 규칙을 너무 문자 그대로 해석해서 다른 맥락에 잘못 적용
해결은 위에서 정리한 원칙 그대로였습니다. 규칙 6개가 뭉친 60단어짜리 문장 하나를 원자적 지시로 쪼개고, 서브 에이전트에 필요한 정보만 정리해서 위임하는 방식으로요. 그 결과 규칙 위반이 "5번 시도 중 1~2번"에서 "10번 시도 중 1번 미만"으로 줄었다고 합니다.
📚 정리
- 컨텍스트 엔지니어링은 프롬프트 엔지니어링의 상위 개념 — 문장을 다듬는 게 아니라 컨텍스트 창 전체를 설계하는 일
- 많이 넣는다고 좋은 게 아님 — 관련 없는 정보는 주의를 분산시켜 오히려 정확도를 떨어뜨림
- 위치와 구조가 정확도를 좌우함 — 중요한 지시는 앞/뒤에, 규칙은 원자적으로 쪼개서
- 토스는 신뢰도를 6개 축으로 나눠 충돌을 사람이 판단하게 함
- 우아한형제들은 지시를 쪼개고 서브 에이전트로 분리해서 규칙 위반을 10배 줄임
두 회사 사례를 보면 결국 방향은 같습니다. "얼마나 많이, 잘 말해주는가"가 아니라 "모델이 지금 무엇을 보고 있는가"를 설계하는 문제라는 것.
참고: 토스 기술블로그 「LLM은 똑똑한데, 왜 우리 회사 일은 모를까」, 우아한형제들 기술블로그 「AI가 내 프롬프트를 흘려듣는 이유」