프롬프트 잘 쓰는 사람보다, 연결을 설계하는 사람이 강해진다
프롬프트 잘 쓰는 사람보다, 연결을 설계하는 사람이 강해진다
프롬프트 엔지니어링이 전부인 줄 알던 시절이 있었다.
AI에게 역할을 주고, 예시를 넣고, 출력 형식을 지정하고, “단계적으로 생각해줘” 같은 문장을 붙이면 결과가 좋아졌다. 실제로 그랬다. 프롬프트는 AI 활용의 첫 번째 문법이었다.
그런데 요즘은 조금 이상하다.
프롬프트를 아무리 잘 써도 일이 잘 안 끝나는 순간이 늘었다. 이유는 간단하다. 우리가 AI에게 맡기는 일이 “답변”에서 “작업”으로 바뀌었기 때문이다.
답변은 문장으로 끝난다.
작업은 구조가 필요하다.
그래서 이제 AI를 잘 쓰는 능력은 이런 순서로 이동하고 있다.
프롬프트 엔지니어링
→ 컨텍스트 엔지니어링
→ 루프 엔지니어링
→ 하네스 엔지니어링
→ 그래프 엔지니어링
처음에는 AI에게 말을 잘 걸면 됐다. 이제는 AI가 무엇을 보고, 어떤 도구를 쓰고, 어떤 반복을 돌고, 어디서 멈추고, 무엇과 무엇을 연결해야 하는지 설계해야 한다.
나는 이 흐름의 끝에 그래프 엔지니어링이 있다고 본다.
아직 널리 합의된 표준 용어는 아니다. 하지만 방향은 꽤 분명하다. AI 시대의 리터러시는 문장을 잘 쓰는 능력에서 연결 구조를 설계하는 능력으로 이동하고 있다.
1. 프롬프트 엔지니어링: AI에게 말을 잘 거는 기술
프롬프트 엔지니어링은 여전히 중요하다.
OpenAI의 prompt engineering 문서도 기본 출발점을 명확히 보여준다. 모델은 prompt를 받아 텍스트, 코드, 수학 풀이, 구조화된 응답 같은 결과를 만든다.1 Anthropic도 프롬프트를 고치기 전에 먼저 성공 기준과 평가 방법을 정하라고 말한다.2
이 말은 꽤 중요하다.
좋은 프롬프트는 “예쁜 주문”이 아니다. 내가 원하는 결과가 무엇인지, 성공 기준이 무엇인지, 어떤 형식으로 판단할지 분명히 하는 일이다.
예를 들어 이렇게 묻는 것과,
AI 트렌드 정리해줘.
이렇게 묻는 것은 다르다.
최근 AI 에이전트 이슈를 업무 설계 관점에서 정리해줘. 단순 뉴스 요약이 아니라, 권한·로그·검수·책임 구조가 어떻게 바뀌는지 중심으로 써줘.
프롬프트는 AI에게 방향을 준다. 하지만 여기서 멈추면 문제가 생긴다.
프롬프트는 순간적이다. 대화창이 바뀌면 다시 설명해야 한다. 자료가 부족하면 AI는 평균적인 말을 만든다. 기준이 없으면 그럴듯한 글을 내놓고도 맞는지 틀린지 모른다.
그래서 프롬프트 엔지니어링은 입구다.
입구를 잘 만드는 일은 중요하지만, 입구만으로 건물이 완성되지는 않는다.
2. 컨텍스트 엔지니어링: AI에게 작업장을 만들어주는 기술
컨텍스트 엔지니어링은 질문을 잘 쓰는 기술이 아니다. AI가 일할 작업장을 설계하는 기술에 가깝다.
LangChain은 context engineering을 “에이전트의 다음 단계에 필요한 정보를 context window에 적절히 채우는 기술”로 설명한다.3 여기서 중요한 단어는 “많이”가 아니라 “적절히”다.
AI에게 자료를 많이 넣으면 더 똑똑해질 것 같지만 꼭 그렇지 않다.
자료가 없으면 AI는 지어낸다.
자료가 너무 많으면 AI는 중요한 것과 덜 중요한 것을 섞는다.
낡은 자료가 들어가면 낡은 판단을 최신 판단처럼 말한다.
틀린 정보가 context에 들어가면, 그 틀린 정보가 이후 판단의 출발점이 된다.
그래서 컨텍스트 엔지니어링은 정보 투입이 아니라 정보 배치다.
블로그 글 하나를 써도 그렇다.
AI에게 단순히 “글 써줘”라고 하는 것과, 기존 글 톤, 카테고리 구조, 위키링크 관례, 공식 출처, SEO 규칙, 이미지 규격, 독자 맥락을 함께 주는 것은 완전히 다르다.
좋은 컨텍스트는 AI를 천재로 만들지 않는다. 대신 AI가 덜 헛소리하게 만든다.
3. 루프 엔지니어링: 한 번에 맞히는 대신 고치는 구조
프롬프트와 컨텍스트를 잘 줘도 한 번에 끝나지 않는다.
글은 초안이 필요하고, 코드는 테스트가 필요하고, 리서치는 출처 확인이 필요하다. AI가 만든 결과물은 대부분 “완성품”이라기보다 “검토해야 할 후보”다.
그래서 루프가 필요하다.
Anthropic은 agentic system을 설명하면서 workflows와 agents를 구분한다. workflows는 미리 정의된 코드 경로를 따라 LLM과 도구를 오케스트레이션하는 시스템이고, agents는 LLM이 도구 사용과 작업 과정을 더 동적으로 지휘하는 시스템이다.4
이 구분은 루프를 이해하는 데 좋다.
AI가 한 번 답하고 끝나는 구조는 약하다. 실제 업무에서는 이런 흐름이 필요하다.
수집한다
→ 분류한다
→ 초안을 만든다
→ 검증한다
→ 수정한다
→ 다시 검증한다
→ 배포한다
→ 반응을 다음 입력으로 남긴다
루프 엔지니어링은 AI에게 “정답을 한 번에 맞혀라”라고 요구하지 않는다. 대신 틀릴 수 있다는 전제에서 출발한다.
틀렸을 때 발견할 수 있는가.
발견했을 때 고칠 수 있는가.
고친 결과가 다음 작업에 반영되는가.
이게 루프다.
한 번의 좋은 답변보다, 나쁜 답변을 발견하고 고치는 구조가 더 중요해진다.
4. 하네스 엔지니어링: AI가 도구를 잡는 손잡이
여기서 한 층 더 내려가면 하네스 엔지니어링이 나온다.
말은 조금 낯설지만, 의미는 단순하다.
하네스 엔지니어링은 AI가 실제 도구를 안전하게 호출하고, 실행하고, 멈추고, 기록하도록 만드는 실행 환경 설계다.
OpenAI Agents SDK 문서는 agent를 instructions와 tools를 가진 LLM으로 설명하고, handoffs, guardrails, tracing, built-in loop 같은 primitives를 제공한다고 설명한다.5
여기서 중요한 건 “AI가 똑똑하다”가 아니다.
AI가 도구를 쓸 수 있게 되면, 도구 사용의 규칙이 필요해진다.
- 어떤 도구를 쓸 수 있는가
- 어떤 입력은 막아야 하는가
- 어떤 출력은 검증해야 하는가
- 어떤 작업은 사람 승인 전에는 실행하면 안 되는가
- 실행 흔적은 어디에 남는가
- 실패하면 어떻게 멈추고 되돌리는가
프롬프트 엔지니어링이 말의 문제라면, 하네스 엔지니어링은 손잡이의 문제다.
AI에게 칼을 쥐여줄 것인가, 가위를 쥐여줄 것인가.
쥐여준 도구를 어디까지 쓰게 할 것인가.
손이 미끄러졌을 때 누가 멈출 수 있는가.
에이전트 시대에는 이 층이 정말 중요해진다. AI가 파일, 브라우저, 터미널, 데이터베이스, 결제, 이메일에 접근하는 순간, 프롬프트만으로는 부족하다.
도구를 안전하게 잡는 손잡이가 필요하다.
5. 그래프 엔지니어링: 이제 연결을 설계해야 한다
그리고 마지막에 그래프 엔지니어링이 온다.
내가 말하는 그래프 엔지니어링은 단순히 지식그래프 DB를 붙이자는 뜻이 아니다. 물론 GraphRAG 같은 흐름도 중요하다. Neo4j는 공식 GraphRAG 패키지를 통해 knowledge graph builder, RAG pipeline, graph 기반 검색을 제공한다.6
하지만 내가 여기서 말하는 그래프는 더 넓다.
AI가 일하려면 여러 노드가 연결되어야 한다.
- 개념과 개념
- 문서와 근거
- 작업과 도구
- 프롬프트와 평가 기준
- 에이전트와 사람 승인
- 결과물과 책임자
- 실패와 복구 루프
- 오늘의 글과 다음 글감
이 연결을 설계하는 일이 그래프 엔지니어링이다.
LangGraph 문서도 이 방향을 보여준다. LangGraph는 long-running, stateful agents를 만들고 관리하는 orchestration framework이며, deterministic step과 agentic step을 하나의 graph 안에서 섞을 수 있다고 설명한다. persistence, human-in-the-loop, memory, debugging도 핵심 기능으로 제시된다.7
이건 단순한 기술 문서 이상의 힌트를 준다.
AI 작업이 길어질수록 중요한 것은 개별 답변이 아니라 상태, 경로, 분기, 기억, 사람 개입 지점이다.
즉 AI 작업은 점점 그래프가 된다.
6. 비교하면 차이가 선명해진다
다섯 가지를 한 번에 놓고 보면 이렇게 정리할 수 있다.
| 구분 | 중심 질문 | 사람이 설계하는 것 | 실패하면 생기는 문제 |
|---|---|---|---|
| 프롬프트 엔지니어링 | AI에게 어떻게 말할까 | 질문, 역할, 출력 형식 | 답변이 흐리거나 엉뚱해짐 |
| 컨텍스트 엔지니어링 | AI가 무엇을 보고 일할까 | 자료, 기억, 파일, 규칙 | 그럴듯하지만 맥락 없는 결과가 나옴 |
| 루프 엔지니어링 | AI가 어떻게 반복하며 개선할까 | 생성, 검증, 수정, 배포 흐름 | 한 번 만든 결과에서 멈춤 |
| 하네스 엔지니어링 | AI가 어떤 도구를 어떻게 쓸까 | 도구, 권한, guardrail, tracing | 행동은 했는데 통제와 기록이 없음 |
| 그래프 엔지니어링 | 무엇과 무엇이 연결되어야 할까 | 개념, 근거, 작업, 도구, 책임의 관계 | 결과물은 많아지지만 지식과 책임이 흩어짐 |
여기서 중요한 것은 유행어 순위가 아니다.
프롬프트가 낡았고 그래프가 새롭다는 말도 아니다.
층위가 다르다.
프롬프트는 입구다.
컨텍스트는 작업장이다.
루프는 작업 리듬이다.
하네스는 실행 손잡이다.
그래프는 축적 구조다.
AI를 취미로 쓸 때는 프롬프트만으로도 충분할 수 있다.
하지만 AI를 업무 시스템 안으로 들이면 이야기가 달라진다. 그때부터는 프롬프트보다 구조가 중요해진다.
7. 그래프 엔지니어링이 중요한 이유
AI는 결과물을 너무 쉽게 만든다.
글도 만들고, 코드도 만들고, 표도 만들고, 보고서도 만든다. 문제는 많아진 결과물이 서로 연결되지 않을 때다.
글은 쌓이는데 지식은 쌓이지 않는다.
자료는 많아지는데 판단 기준은 흐려진다.
자동화는 늘어나는데 책임은 불분명해진다.
이게 AI 시대의 새로운 쓰레기다.
예전의 쓰레기는 빈 문서였다. 아무것도 안 만들어진 상태.
이제의 쓰레기는 연결되지 않은 산출물이다. 많이 만들었는데 어디에도 붙지 않는 상태.
그래프 엔지니어링은 이 문제를 다룬다.
블로그를 예로 들면 더 쉽다.
좋은 AI 글 하나는 단독 글로 끝나지 않는다.
- 기존 글과 연결된다.
- 새 개념 노드를 만든다.
- 공식 출처와 연결된다.
- LinkedIn 반응과 연결된다.
- 다음 글감으로 이어진다.
- 나중에 검색과 그래프 뷰에서 다시 발견된다.
이 구조가 없으면 AI는 계속 새 글을 만들지만, 블로그는 지식 정원이 아니라 콘텐츠 창고가 된다.
업무도 마찬가지다.
AI가 보고서를 만들었다면, 그 보고서는 어떤 원자료와 연결되어야 한다. 어떤 판단 기준을 썼는지 남아야 한다. 누가 승인했는지 기록되어야 한다. 다음 의사결정에서 다시 호출될 수 있어야 한다.
그게 안 되면 AI는 일을 많이 한 것처럼 보이지만, 조직은 더 혼란스러워진다.
8. 사람에게 남는 일은 연결의 기준을 정하는 것이다
AI가 문장을 잘 쓰기 시작하자 사람은 프롬프트를 배웠다.
AI가 긴 맥락을 다루기 시작하자 사람은 컨텍스트를 설계해야 했다.
AI가 도구를 호출하고 반복 작업을 수행하자 사람은 루프와 하네스를 설계해야 했다.
그리고 AI가 여러 지식과 작업을 넘나들기 시작하면, 사람은 그래프를 설계해야 한다.
이 흐름에서 사람의 역할은 사라지지 않는다. 다만 위치가 바뀐다.
사람은 모든 문장을 직접 쓰는 사람이 아니다.
모든 자료를 직접 찾는 사람도 아니다.
모든 반복 작업을 직접 수행하는 사람도 아니다.
대신 사람은 연결의 기준을 정한다.
무엇이 중요한 개념인가.
어떤 근거를 신뢰할 것인가.
어떤 작업은 자동화하고 어떤 작업은 사람에게 물어봐야 하는가.
어떤 결과를 다음 지식으로 남길 것인가.
어떤 실패를 복구 루프로 연결할 것인가.
이건 프롬프트보다 어렵다.
하지만 더 오래 간다.
프롬프트는 복사된다. 컨텍스트 주입은 도구가 대신한다. 루프와 하네스도 점점 제품화된다. 그런데 어떤 연결이 의미 있는지 판단하는 일은 쉽게 자동화되지 않는다.
사람의 전문성은 그쪽으로 이동한다.
결론: 이제 질문은 문장이 아니라 구조다
AI를 잘 쓰는 사람은 더 이상 “프롬프트 문장”만 잘 쓰는 사람이 아니다.
AI가 볼 맥락을 고르고, 반복 구조를 만들고, 도구 사용의 손잡이를 설계하고, 결과물이 지식과 책임으로 이어지게 만드는 사람이다.
프롬프트 엔지니어링은 AI 활용의 시작이었다.
하지만 에이전트 시대의 질문은 더 크다.
이 AI가 무엇을 보고, 무엇을 실행하고, 무엇을 남기고, 무엇과 연결되는가?
그래서 나는 앞으로 그래프 엔지니어링이라는 말이 더 중요해질 거라고 본다.
AI가 많이 만들수록, 사람은 더 잘 연결해야 한다.
문장을 잘 쓰는 능력에서 구조를 잘 남기는 능력으로.
그게 AI 리터러시의 다음 층위다.
출처
-
OpenAI, “Prompt engineering,” OpenAI API docs. https://platform.openai.com/docs/guides/prompt-engineering ↩
-
Anthropic, “Prompt engineering overview,” Claude docs. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview ↩
-
LangChain, “Context Engineering,” LangChain Blog. https://blog.langchain.com/context-engineering-for-agents/ ↩
-
Anthropic, “Building Effective AI Agents,” Anthropic Engineering. https://www.anthropic.com/engineering/building-effective-agents ↩
-
OpenAI, “OpenAI Agents SDK,” documentation. https://openai.github.io/openai-agents-python/ ↩
-
Neo4j, “GraphRAG for Python,” official documentation. https://neo4j.com/docs/neo4j-graphrag-python/current/ ↩
-
LangChain, “LangGraph overview,” docs. https://docs.langchain.com/oss/python/langgraph/overview ↩