AI와 소통하는 방법의 변화
AI를 잘 활용하기 위한 접근법이 점점 넓어지고 있다. 처음에는 프롬프트를 잘 쓰는 것이 핵심이었고, 최근에는 컨텍스트를 잘 구성하는 것으로 관심이 옮겨가고 있다. 이 글에서는 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 그리고 움벨트라는 개념까지 간단히 정리해본다.
Prompt Engineering — 질문을 잘 던지기
프롬프트 엔지니어링은 AI에게 입력하는 텍스트를 잘 구성하는 기술이다. 2023년부터 널리 알려졌고, 지금도 유효한 기본기다.
대표적인 기법들:
| 기법 | 설명 | 예시 |
|---|---|---|
| Zero-shot | 예시 없이 바로 지시 | “이 코드를 리팩토링해줘” |
| Few-shot | 예시를 몇 개 보여주고 지시 | “이런 형식으로 변환해줘: A→B, C→D” |
| Chain-of-Thought | 단계별 사고를 유도 | “단계별로 생각해서 풀어줘” |
| Role-playing | 역할 부여 | “시니어 개발자로서 리뷰해줘” |
프롬프트 엔지니어링은 한 번의 대화에서 더 좋은 답을 얻는 데 효과적이다. 챗봇에게 질문하거나, 단일 작업을 요청할 때 여전히 중요한 스킬이다.
Context Engineering — 작업 환경을 설계하기
에이전트 시대로 넘어오면서, AI와의 상호작용이 달라졌다. 한 번 질문하고 끝나는 게 아니라, 수십~수백 턴에 걸쳐 파일을 읽고, 코드를 쓰고, 도구를 사용하는 장기 작업이 일상이 되었다.
이 맥락에서 등장한 개념이 Context Engineering이다. Andrej Karpathy를 비롯한 여러 사람들이 언급하면서 주목받기 시작했다.
프롬프트 엔지니어링이 “무엇을 물어볼까”라면, 컨텍스트 엔지니어링은 “어떤 환경에서 일하게 할까”다.
프롬프트 vs 컨텍스트
| 구분 | Prompt Engineering | Context Engineering |
|---|---|---|
| 대상 | 입력 메시지 | 시스템 전체 환경 |
| 범위 | 한 번의 질문 | rules, tools, memory 등 |
| 지속성 | 해당 턴 | 세션 전체 또는 프로젝트 전체 |
| 비유 | 좋은 질문 던지기 | 좋은 작업 환경 세팅하기 |
실전에서의 컨텍스트
Claude Code를 예로 들면, 컨텍스트를 구성하는 요소는 이런 것들이 있다:
- Rules — 코딩 스타일, 보안 기준, 테스트 정책 등을 파일로 정의
- Tools — 에이전트가 사용할 수 있는 도구 (파일 읽기/쓰기, 검색, 외부 API 등)
- Memory — 세션 간 유지되는 사용자 선호, 프로젝트 맥락
- Hooks — 파일 수정 시 자동 포맷팅 같은 자동화된 반응
- Agents — 코드 리뷰어, 보안 검토자 등 전문 역할 분담
같은 모델이라도 이런 컨텍스트가 잘 구성되어 있으면 결과물이 확연히 달라진다. 프롬프트 한 줄에 “코드를 깔끔하게 써줘”라고 말하는 것과, rules 파일에 구체적인 코딩 컨벤션을 정의해두는 것은 정밀도 면에서 차이가 크다.
움벨트 엔지니어링(Umwelt Engineering) — 이런 개념도 있다
최근 한 가지 더 흥미로운 개념이 등장했다. 움벨트 엔지니어링(Umwelt Engineering)이다.
움벨트(Umwelt)는 원래 독일의 생물학자 야콥 폰 윅스퀼이 1909년에 제안한 생물학 개념으로, 각 생명체가 자신의 감각 기관에 따라 경험하는 주관적 세계를 말한다. 진드기는 시각도 청각도 없이 체온, 냄새, 촉각 세 가지만으로 세상을 인식한다. 인간이 보는 세계와 진드기가 보는 세계는 완전히 다르다.
2025년 발표된 논문 “Umwelt Engineering”에서는 이 개념을 AI에 적용해서, 프롬프트 엔지니어링·컨텍스트 엔지니어링 위에 놓이는 세 번째 계층으로 정의했다.
세 계층의 차이
| 계층 | 설계 대상 | 핵심 질문 |
|---|---|---|
| Prompt Engineering | 지시와 형식 | 무엇을 시킬까? |
| Context Engineering | 외부 정보와 도구 | 무엇을 알게 할까? |
| Umwelt Engineering | 어휘, 문법, 개념적 원시 요소 | 어떻게 생각하게 할까? |
핵심 아이디어는 이렇다. LLM은 텍스트를 생성하는 과정이 곧 추론 과정이다. 인간은 언어 외에도 공간 직관이나 감정 같은 비언어적 사고가 가능하지만, LLM에게는 언어가 곧 사고 그 자체다. 그래서 에이전트가 사용하는 언어 구조 자체를 바꾸면 추론 방식이 달라진다는 것이다.
실험 결과
논문에서는 두 가지 언어 제약을 실험했다:
- “have” 사용 금지 — 소유 개념을 배제하면 윤리적 추론이 19.1pp 개선
- “to be” 사용 금지 (E-Prime) — 본질주의적 사고를 억제, 인과 추론에서 이점
또한 서로 다른 언어 제약을 가진 3개 에이전트를 앙상블로 묶었을 때, 소프트웨어 디버깅에서 100% 정답 커버리지를 달성했다고 한다. 다양한 “인지 관점”이 서로를 보완한 결과다.
아직 초기 연구 단계이고 실무에 바로 적용하기엔 이른 감이 있지만, “AI에게 무엇을 시키느냐”를 넘어 “AI가 어떻게 생각하느냐”까지 설계할 수 있다는 관점은 꽤 신선하다.
정리
| Prompt Engineering | Context Engineering | Umwelt Engineering | |
|---|---|---|---|
| 핵심 | 질문을 잘 쓰기 | 환경을 잘 설계하기 | 사고 방식을 설계하기 |
| 유효한 상황 | 단일 대화, 단발 작업 | 에이전트 기반 장기 작업 | 추론 품질이 중요한 작업 |
| 투자 방식 | 매번 프롬프트 작성 | 한 번 설계하면 계속 적용 | 연구/실험 단계 |
셋은 대체 관계가 아니라 계층 관계다. 프롬프트를 잘 쓰는 것이 기본이고, 컨텍스트 설계가 그 위에 올라가며, 움벨트 엔지니어링은 더 근본적인 층을 다룬다. 지금 당장 실무에서 가장 효과가 큰 것은 컨텍스트 엔지니어링이고, 움벨트 엔지니어링은 앞으로 지켜볼 만한 방향이다.