F1 레이스에서 이런 상황을 상상해보자. 피트월에서 엔지니어가 드라이버에게 무전을 넣는다. “타이어 어때?” 드라이버가 답한다. “그냥 좀 이상해.” 엔지니어는 멍하니 모니터만 바라본다. 정보가 없다. 판단할 수 없다. 다음 랩, 엔지니어가 다시 묻는다. “3랩 전 대비 그립감이 줄었어? 앞 쪽이야 뒤 쪽이야?” 드라이버가 즉시 답한다. “앞 왼쪽, 진입 구간에서만.” 이제 엔지니어는 움직일 수 있다.
LLM 엔지니어링도 정확히 같은 구조다. LLM은 질문 하나를 받아 답변 하나를 돌려주는 함수다. 그 함수에 무엇을 넣느냐가 전부다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링 — 이름이 계속 바뀌어왔지만 본질은 단 하나다. 매 질문에 맥락과 의도를 얼마나 잘 담느냐.
LLM 엔지니어링이란 무엇인가 — 깡통에 뭘 넣느냐의 문제
LLM을 처음 접하면 뭔가 대단한 지식 덩어리가 안에 들어 있을 것 같다. 하지만 실제 구조는 다르다.
현재의 모든 LLM은 기본적으로 인풋이 들어오면 아웃풋을 반환하는 함수 덩어리다. 기억이 없다. 대화창에서 아무리 긴 이야기를 나눠도, 다음 문장에 앞선 내용을 넣어주지 않으면 LLM은 그 대화를 모른다. 매 질문이 새 출발이다.
LLM 엔지니어링이란 이 구조를 이해하고, 그 위에서 원하는 답을 끌어내는 모든 행위를 말한다. 어떤 말을 어떻게 던질지, 어떤 맥락을 얼마나 넣을지, 어떤 환경을 갖춰줄지 — 이 모든 시도가 LLM 엔지니어링의 범위 안에 있다.
3단계 진화 — 프롬프트에서 하네스까지
LLM 엔지니어링은 지난 몇 년 사이 세 번의 이름 변화를 겪었다. 이름이 바뀐 게 아니라, 문제를 보는 범위가 넓어진 것이다.
| 단계 | 키워드 | 핵심 질문 | 범위 |
|---|---|---|---|
| 1단계 | 프롬프트 엔지니어링 | 말을 어떻게 던져야 잘 알아듣는가? | 질문 문장 설계 |
| 2단계 | 컨텍스트 엔지니어링 | 어떤 맥락을 얼마나 떠먹여야 하는가? | 입력 정보 구성 |
| 3단계 | 하네스 엔지니어링 | 틀과 환경 자체를 어떻게 갖춰줄 것인가? | 시스템 전체 설계 |
프롬프트 엔지니어링은 가장 먼저 주목받았다. 같은 질문도 어떻게 표현하느냐에 따라 답이 달라진다는 걸 사람들이 경험하면서다. 역할을 부여하고, 예시를 제시하고, 출력 형식을 지정하는 기법들이 여기서 나왔다.
컨텍스트 엔지니어링은 한 발 더 나아갔다. 질문 문장만이 아니라, 질문에 딸려 들어가는 배경 정보 전체를 설계하는 개념이다. 관련 문서를 넣고, 이전 대화를 붙이고, 도메인 지식을 함께 제공하면 LLM이 훨씬 정확하게 반응한다. RAG가 대표적인 컨텍스트 엔지니어링 구현체다.
하네스 엔지니어링은 현재 가장 뜨거운 키워드다. 하네스(Harness)는 말(馬)에 끼우는 마구(馬具)를 뜻한다. 길들이지 않은 야생마가 모델이라면, 마구를 씌워 원하는 방향으로 달리게 하는 것이 하네스 엔지니어링이다. 시스템 프롬프트 설계, MCP 연결, 샌드박스, 스킬 파일 — 이 모든 것이 하네스의 범주에 들어간다.
하네스도 결국 과도기다 — 모델이 강해지면 사라지는 것들
하네스 엔지니어링이 뜨겁다고 해서 영원히 뜨겁지는 않다. 이미 비슷한 일이 반복됐다.
프롬프트 엔지니어링이 처음 나왔을 때, 사람들은 이걸 직업으로 만들었다. 지금은 어떤가. 모델이 좋아지면서 굳이 공들여 프롬프트를 설계하지 않아도 어지간한 답이 나온다. 컨텍스트 엔지니어링도 비슷한 수순을 밟고 있다.
하네스도 같은 길을 걸을 가능성이 크다. 모델이 충분히 강해지면 정교한 마구 없이도 잘 달린다. 오히려 이전 버전에서 쓰던 하네스를 그대로 입혀두면 성능이 떨어지는 경우도 생긴다. 똑똑한 말에 불필요한 장치를 달아두는 꼴이다.
이 흐름을 보면 LLM 엔지니어링의 이름은 계속 바뀌겠지만, 결국 남는 것은 하나다.
LLM 엔지니어링의 본질 — 매 질문에 맥락과 의도를 담는 기술
LLM은 질문 하나에 답변 하나를 돌려준다. 이 구조는 바뀌지 않는다.
프롬프트, 컨텍스트, 하네스 — 이름이 무엇이든 이 모든 행위는 결국 한 가지 질문으로 귀결된다. 이 질문에 내 의도와 맥락이 충분히 담겼는가?
피트월 엔지니어가 “타이어 어때?”라고 물으면 드라이버도 대답할 수 없다. “3랩 전 대비 앞 왼쪽 그립감 변화가 있냐”고 물어야 의미 있는 답이 나온다. LLM도 마찬가지다. 질문이 명확하지 않으면 아무리 좋은 모델도 엉뚱한 방향으로 달린다.
메타 프롬프팅을 공부할 때도 느꼈지만, AI에게 좋은 답을 받으려면 내가 먼저 무엇을 원하는지 명확히 알아야 한다. 좋은 질문은 좋은 사고에서 나온다. LLM 엔지니어링을 배운다는 건, 결국 스스로 더 잘 생각하는 훈련이기도 하다.
스킬, 플러그인, 에이전트 — 화려한 도구들이 계속 나온다. 하지만 도구가 아무리 좋아도 질문이 흐릿하면 답도 흐릿하다. 좋은 LLM 엔지니어링의 시작점은 항상 같다. 내가 지금 무엇을 원하는지를 먼저 명확히 하는 것.
핵심 요약
- LLM은 인풋이 들어오면 아웃풋을 반환하는 함수다. 기억이 없고, 매 질문이 새 출발이다.
- LLM 엔지니어링은 프롬프트 → 컨텍스트 → 하네스 순으로 범위가 넓어졌지만 본질은 같다.
- 하네스 엔지니어링도 모델이 강해질수록 필요성이 줄어드는 과도기적 개념이다.
- 이름이 무엇이든 결국 남는 것은 하나 — 매 질문에 맥락과 의도를 잘 담는 기술이다.
- 좋은 질문은 좋은 사고에서 나온다. LLM 엔지니어링을 배우는 건 생각하는 훈련이기도 하다.
[링크 제안]
LLM에게 맥락을 잘 넣는다는 게 구체적으로 어떤 구조인지 궁금하다면 RAG부터 보면 된다.
AI가 현장에서 살아남는 엔지니어의 무기가 되는 이유가 궁금하다면 이 글을 이어서 읽어라.
LLM 공식 문서나 Anthropic 프롬프트 가이드를 참고하고 싶다면 Anthropic 공식 문서에서 직접 확인할 수 있다.
