프롬프트에서 루프까지

지난주에 루프 엔지니어링 글을 올렸었습니다. 바로 적용하기에 너무 어렵다. 가장 많이 들었던 반응입니다. 그래서 여러 매체들에서 루프 엔지니어링보다 먼저 언급되었던 프롬프트 엔지니어링부터 알아보려고 합니다.

작년에는 프롬프트 엔지니어링 이야기가 많이 들렸고, 올해 초에는 하네스 엔지니어링을 들었고, 지금은 루프 엔지니어링입니다. 그 사이에 컨텍스트 엔지니어링이라는 말도 있었던 것 같은데 확실하지 않았습니다. 무엇이 무엇을 대체한 것인지, 아니면 유행어가 그냥 돌아가는 것인지 모르는 채로 마지막 것만 붙잡고 글을 쓴 셈이었습니다.

업무에 AI를 어떻게 써야 잘 쓰는 건지가 원래 궁금했던 것인데, 그 답이 저 네 이름 어딘가에 있을 것 같아서 처음부터 훑었습니다. 1차 출처를 찾아서요.

말이 네 번 바뀌었습니다

[Fig. 1 — 이름이 붙은 네 순간]닫기 ✕Fig. 1 — 이름이 붙은 네 순간

찾아보고 놀란 건 뒤의 셋이 열두 달 안에 다 나왔다는 것이었습니다. 앞의 다섯 해에 하나였는데요.

AI가 그만큼 빨라진 건지, 쓰는 사람이 그만큼 늘어난 건지는 저도 모르겠습니다. 다만 이름이란 부를 일이 많아져야 붙는 것이니, 뒤쪽 아니면 둘 다일 것 같습니다.

그리고 하나 더. 검색하면 「프롬프트 엔지니어링은 죽었다」는 제목이 쏟아지는데, 1차 출처는 하나같이 반대로 말합니다. 그건 뒤에서 보겠습니다.

프롬프트 — 말이 전부이던 때

[Fig. 2 — 쪽지 한 장을 건넨다]닫기 ✕Fig. 2 — 쪽지 한 장을 건넨다

말의 뿌리

prompt는 원래 「튀어나오게 하다, 부추기다」입니다. 여기서 연극의 프롬프터(무대 옆에서 대사를 일러주는 사람), 명령 프롬프트(터미널의 $), 작문 과제의 writing prompt가 갈라져 나왔습니다.

이 셋 중 무엇이 LLM 용어의 직계 조상인지는 못 밝혔습니다. 그걸 따진 1차 출처를 못 찾았습니다. 정황만 보면 작문 프롬프트 쪽이 가까워 보입니다 — 「이 뒤를 이어 써라」가 언어모델이 실제로 하는 일이니까요. 다만 이건 제 짐작이고, 근거를 대라면 못 댑니다.

「프롬프트 엔지니어링」은 누가 썼나

아무도 창시자를 확정하지 못합니다. 확인되는 흔적을 시간 순으로 놓으면 이렇습니다.

2020년 6월 Gwern은 본인 글에서 prompt programming이라고 썼습니다.

a new kind of programming, prompt programming, where the prompt is now a coding language which programs GPT-3 to do new things.

새로운 종류의 프로그래밍, 프롬프트 프로그래밍. 이제 프롬프트가 GPT-3에게 새로운 일을 시키는 코딩 언어다.

한 달 반 뒤 해커뉴스에 제3자가 prompt engineering이라는 말을 그대로 쓴 기록이 남아 있습니다.

Gwern points out that "prompt engineering" is very important in GPT-3

Gwern은 GPT-3에서 **「프롬프트 엔지니어링」**이 아주 중요하다고 짚는다.

논문보다 커뮤니티가 먼저였습니다. 이듬해 2월 CLIP 논문이 한 절의 제목을 Prompt Engineering and Ensembling으로 달면서, 본문에서 스스로 출처를 밝힙니다.

Similar to the "prompt engineering" discussion around GPT-3, we have also observed that zero-shot performance can be significantly improved by customizing the prompt text to each task.

GPT-3 주변의 그 「프롬프트 엔지니어링」 논의처럼, 우리도 과제마다 프롬프트 문구를 맞춰주면 제로샷 성능이 크게 올라가는 것을 보았다.

따옴표를 붙여 썼다는 게 요점입니다. 바깥에서 쓰던 말을 논문이 빌려온 것이죠. 효과도 적어뒀습니다. 문구를 과제에 맞추는 것만으로 ImageNet(이미지 분류 성능을 재는 표준 시험) 정확도가 1.3% 오르고, 여러 문구를 만들어 합치는 것까지 하면 5% 가까이 오른다고요.

정의는 처음부터 두 개였습니다

[Fig. 3 — 좁은 정의와 넓은 정의]닫기 ✕Fig. 3 — 좁은 정의와 넓은 정의

같은 해 7월에 나온 서베이가 학술 정의를 굳혔는데, 읽어보면 우리가 쓰는 말과 꽤 다릅니다.

A text where [X] is instantiated by input x but answer slot [Z] is not.

[X] 자리에는 입력 x가 채워지고, 답 슬롯 [Z]는 비어 있는 텍스트.

빈칸 채우기 문제지입니다. 「이 리뷰의 감정은 [Z]이다」를 넣고 [Z]를 채우게 하는 것. 그런데 이건 시대가 달라서가 아닙니다. 한 해 전 Gwern은 이미 프롬프트를 「코딩 언어」라고 불렀고, 같은 해 CLIP은 「과제마다 문구를 맞춘다」고 썼습니다.

즉 좁은 정의와 넓은 정의가 나란히 있었던 것입니다. 논문은 성능을 재기 위해 형식을 좁게 잡아야 했고, 쓰는 사람들은 처음부터 넓게 썼습니다. 세 해 뒤에 나온 The Prompt Report는 넓은 쪽을 표준으로 올립니다.

An input to a Generative AI model, that is used to guide its output.

생성 AI 모델에 넣는 입력으로, 그 출력을 이끄는 데 쓰이는 것.

이 층에서는 모델 탓인지 내 탓인지 가릴 수가 없습니다

Gwern이 같은 글에 소제목으로 달아둔 경고가 있습니다.

Sampling Can Prove The Presence Of Knowledge But Not The Absence

뽑아보는 것으로 지식이 있다는 건 증명해도, 없다는 건 증명하지 못한다.

무슨 말이냐면 이렇습니다. 프롬프트를 잘못 썼거나 예시가 모자라도 모델은 「못 한다」처럼 보입니다. 그래서 결과가 나빴을 때 「모델이 못 하는 것」이라고 결론 내릴 수가 없습니다. 그가 붙인 문장이 이겁니다.

The question is not whether a given prompt works, but whether any prompt works.

문제는 「그 프롬프트가 되느냐」가 아니라 **「되는 프롬프트가 있기는 하냐」**다.

우리 일로 치면 선행기술 조사와 같습니다. 검색해서 안 나왔다고 없는 게 아니죠. 검색식이 나빴을 수도 있으니까요. 찾았으면 있는 것이 확실하지만, 못 찾은 것으로는 아무것도 확정할 수 없습니다.

프롬프트 층에는 이걸 가려낼 장치가 없습니다. 모델은 못 고치고, 고칠 수 있는 건 내가 넣은 덩어리 하나뿐이니까요. 뒤에 나온 셋은 이걸 나눠서 볼 수 있게 만든 것들입니다 — 컨텍스트는 「필요한 걸 보여주기는 했나」를, 하네스는 「틀린 걸 걸렀나」를, 루프는 「몇 번 다시 시켜봤나」를 따로 따질 수 있게 해줍니다.

그런데 왜 이 말이 버려졌나

사이먼 윌리슨의 진단이 가장 정확합니다.

most people developed an inferred definition that reduced it to "a laughably pretentious term for typing things into a chatbot." … inferred definitions — not intended ones — are what ultimately stick.

사람들이 제멋대로 유추한 정의는 **「챗봇에 뭘 쳐 넣는 걸 우습게 거창하게 부른 말」**로 쪼그라들었다. … 결국 굳는 건 의도한 정의가 아니라 유추된 정의다.

기술이 죽은 게 아니라 말의 뜻이 오염돼서 버려진 것입니다.

컨텍스트 — 책상이 유한하다는 걸 알게 된 때

[Fig. 4 — 책상에 사건기록을 올려준다]닫기 ✕Fig. 4 — 책상에 사건기록을 올려준다

앞의 말은 커뮤니티에서 나와 결국 논문이 정의를 굳혔습니다. 이 말은 정본이 아직 트윗 두 개입니다.

2025년 6월 18일, 쇼피파이 CEO 토비 뤼트케.

I really like the term "context engineering" over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.

「컨텍스트 엔지니어링」이 「프롬프트 엔지니어링」보다 마음에 든다. 핵심 기술을 더 잘 설명한다 — LLM이 그 과제를 풀 수 있을 법하게 만드는 데 필요한 모든 맥락을 대주는 기술.

일주일 뒤 안드레이 카파시가 붙였습니다.

People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.

사람들은 프롬프트를 「일상적으로 LLM에 주는 짧은 과제 설명」과 결부시킨다. 그런데 제대로 된 LLM 앱에서 컨텍스트 엔지니어링이란 다음 한 걸음에 딱 맞는 정보로 컨텍스트 창을 채우는, 섬세한 기예이자 과학이다.

석 달 뒤 앤트로픽이 공식 정의를 냈습니다.

Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.

컨텍스트 엔지니어링이란 추론 중에 최적의 토큰(정보) 묶음을 골라내고 유지하는 전략들이며, 프롬프트 바깥에 들어앉게 되는 다른 정보까지 포함한다.

[Fig. 5 — 내 프롬프트는 창 안의 한 칸이다]닫기 ✕Fig. 5 — 내 프롬프트는 창 안의 한 칸이다

같은 글에 나오는 세 문장이 실무에 바로 걸립니다.

Context, therefore, must be treated as a finite resource with diminishing marginal returns.

컨텍스트는 한계 효용이 떨어지는 유한 자원으로 다뤄야 한다.

context rot: as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.

컨텍스트 부패 — 창에 든 토큰이 늘수록, 모델이 그 안에서 정확히 기억해내는 능력은 떨어진다.

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.

좋은 컨텍스트 엔지니어링이란 원하는 결과가 나올 확률을 최대로 만드는, 가능한 한 가장 작은 고신호 토큰 집합을 찾는 일이다.

더 넣는 게 좋은 게 아니라는 뜻입니다. 필요할 것 같으면 일단 다 넣고 보게 되는데, 정확히 그 반대로 하라는 얘기입니다.

이건 대체로 도구가 해줍니다

앤트로픽이 긴 작업을 위해 든 기법이 넷인데, 읽다 보니 클로드나 챗지피티가 이미 알아서 해주는 것들이었습니다.

기법	도구가 해주는 것	내가 하는 것
압축	창이 차면 알아서 요약해 이어간다	요약에서 빠지면 안 될 것을 미리 파일로 빼두기
기록	메모리 파일을 알아서 읽고 쓴다	무엇을 남길지, LLM Wiki
서브 에이전트	깨끗한 창을 열어 부를 수 있게 돼 있다	누구를 몇 명, 어떤 지시로 부를지
적시 검색	경로만 주면 필요할 때 읽어간다	경로를 찾을 수 있게 정리해두기

그러니까 컨텍스트 엔지니어링은 상당 부분이 이미 기능으로 들어와 있습니다. 몇 해 전이라면 직접 짜야 했을 것들입니다. 그렇다고 할 일이 없어진 건 아닙니다. 무엇을 이 일에 끌어올지 정하는 것은 여전히 사람이 합니다.

「기록」이 특히 그렇습니다. 얼마 전에 카파시의 LLM 위키를 읽고 OA 대응 업무에 그대로 얹어봤습니다. 사건마다 원문을 처음부터 다시 읽히는 대신, 논거 하나를 문서 하나로 만들어 쌓습니다. 지금 백 개가 조금 넘고, 새 사건을 볼 때 원문보다 그 위키를 먼저 봅니다.

제가 구조를 짠 건 아닙니다. 에이전트에게 그 글의 링크를 주고 「우리 일에 적용해 달라」고 시켜서 첫 구조를 받았고, 그 뒤로 여러 차례 같이 고쳤습니다.

하네스 — 방을 고치기 시작한 때

[Fig. 6 — 사무실을 만든다]닫기 ✕Fig. 6 — 사무실을 만든다

말 자체는 새것이 아닙니다

harness는 원래 말에 채우는 마구이고, 소프트웨어 공학에서는 시험 대상을 붙들어 매고 돌리는 테스트 하네스로 오래 쓰였습니다. 언어모델 쪽에서도 EleutherAI의 lm-evaluation-harness가 2020년 무렵부터 있었고 — 어떤 모델이든 똑같은 입력·똑같은 코드로 재보려는 틀입니다 — 에이전트 안전성을 재는 METR은 2023년에 같은 것을 스캐폴딩이라 부르며 「스캐폴딩 + 모델 = 에이전트」로 셈했습니다.

2026년에 새로 생긴 건 기술이 아니라 「직업으로 부르는 이름」입니다.

2026년 2월, 엿새 사이에

2월 5일, 미첼 해시모토가 자기 AI 도입 6단계를 적으면서 5단계에 이렇게 썼습니다.

the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

에이전트가 실수하는 걸 볼 때마다, 그 실수를 다시는 못 하게 만드는 해법을 공들여 짜 넣는 것.

그리고 에이전트에게 주는 자기 지침 파일을 두고 이렇게 덧붙입니다.

Each line in that file is based on a bad agent behavior, and it almost completely resolved them all.

그 파일의 각 줄은 전부 에이전트의 나쁜 행동 하나에서 나왔고, 그것으로 거의 다 해결됐다.

엿새 뒤 OpenAI가 「Harness engineering」을 냈습니다. 다섯 달 동안 적은 인원이 사람이 손으로 쓴 소스코드 0줄로 약 100만 줄짜리 제품을 냈다는 이야기입니다.

Agents aren't hard; the Harness is hard.

에이전트는 어렵지 않다. 하네스가 어렵다.

(이 글은 원문이 열리지 않아 InfoQ 보도와 저자 본인 저장소로 확인했습니다. 숫자는 매체마다 조금씩 다릅니다.)

4월, 체계가 됐습니다

가장 잘 정리된 글은 쏘트웍스의 비르기타 뵈켈러가 마틴 파울러 사이트에 쓴 것입니다.

정의는 한 줄입니다. 하네스 = AI 에이전트에서 모델을 뺀 나머지 전부. 그리고 그걸 두 종류로 가르는데, 이 구분이 알맹이입니다.

[Fig. 7 — 가이드와 센서, 계산적인 것과 추론적인 것]닫기 ✕Fig. 7 — 가이드와 센서, 계산적인 것과 추론적인 것

• 가이드는 하기 전에 방향을 잡아주는 것 — 지침 파일, 서식, 잘 쓴 예시
• 센서는 하고 난 뒤에 틀렸다고 알려주는 것 — 검사 스크립트, 반박하고 검토하는 쪽

그리고 각각을 다시 계산적(검사기처럼 확정적이고 빠른 것)과 추론적(AI가 의미를 보고 판단하는, 느리고 확률적인 것)으로 나눕니다. (위 그림은 뵈켈러의 분류를 그대로 옮겨 그린 것입니다.)

이 글에서 제일 오래 남은 문장은 이거였습니다.

A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important.

좋은 하네스의 목표는 사람의 개입을 없애는 게 아니라, 개입이 가장 중요한 자리로 몰아주는 것이다.

애디 오스마니는 같은 것을 더 짧게 말합니다.

Agent = Model + Harness. If you're not the model, you're the harness.

에이전트 = 모델 + 하네스. 당신이 모델이 아니라면, 당신이 하네스다.

Every line in a good AGENTS.md should be traceable back to a specific thing that went wrong.

좋은 지침 파일의 모든 줄은 실제로 잘못됐던 무언가로 거슬러 올라갈 수 있어야 한다.

엔비디아 CEO가 키노트에서 이 말을 씁니다

이 말이 어디까지 갔는지는 이걸로 알 수 있습니다. 젠슨 황이 2026년 6월 GTC 타이베이 키노트에서 에이전트를 이렇게 설명했다고 합니다.

it is an agent, which consists of a large language model or many sitting inside a harness, and that harness orchestrates it to do productive work … You can think of the model as the brain, the harness as the body, and the tools it uses working in a runtime.

에이전트란 하네스 안에 들어앉은 하나 또는 여럿의 대규모 언어모델이고, 그 하네스가 그것을 지휘해 쓸모 있는 일을 하게 만든다. … 모델은 뇌, 하네스는 몸, 그리고 런타임에서 도구가 돌아간다고 보면 된다.

(이것도 보도로 확인했고 공식 트랜스크립트는 못 봤습니다.)

루프 — 내가 없어도 도는 때

[Fig. 8 — 내가 출근 안 해도 돈다]닫기 ✕Fig. 8 — 내가 출근 안 해도 돈다

여기는 지난 글에서 이미 다뤘으니 아우터 루프의 네 자리는 다시 적지 않겠습니다.

이번에 새로 확인한 건 하나입니다. 앤트로픽이 루프를 네 종류로 나눈 글에는 무엇을 기준으로 나눈 것인지가 적혀 있었습니다.

[Fig. 9 — 무엇을 넘겼느냐로 갈린다]닫기 ✕Fig. 9 — 무엇을 넘겼느냐로 갈린다

칸이 넷이라는 게 아니라, 내가 어디까지 넘겼느냐가 넷입니다. 도구 호출 승인 → 됐는지 판정 → 언제 시작할지 → 프롬프트 전체. 이 순서로 하나씩 더 넘기면 그때마다 루프의 종류가 바뀝니다.

정지 조건에 대한 한 줄도 가져갈 만합니다.

The more quantitative the checks are, the easier it is for Claude to self-verify.

검사가 양적일수록 클로드가 스스로 검증하기 쉽다.

그리고 같은 글이 이렇게 끝납니다.

Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.

모든 일에 복잡한 루프가 필요한 건 아니다. 가장 단순한 것부터 시작하고 골라서 쓰라.

뒤에 나온 것이 앞의 것을 대체하지 않았습니다

[Fig. 10 — 네 층]닫기 ✕Fig. 10 — 네 층

이번 조사에서 가장 값어치 있었던 건 이겁니다. 개념을 세운 사람들이 하나같이 「앞의 것을 껴안는다」고 직접 썼습니다.

앤트로픽은 컨텍스트 엔지니어링을 소개하는 글에서 이렇게 못 박습니다.

At Anthropic, we view context engineering as the natural progression of prompt engineering.

앤트로픽에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 다음 단계로 본다.

프롬프트를 안 쓴다는 게 아니라, 프롬프트가 들어앉는 창 전체로 눈을 넓히자는 것입니다.

뵈켈러도 하네스를 컨텍스트 위에 얹습니다.

Engineering a user harness for a coding agent is a specific form of context engineering.

코딩 에이전트를 위해 사용자 하네스를 만드는 일은 컨텍스트 엔지니어링의 한 구체적 형태다.

오스마니도 같은 방향입니다.

Context is scarce, and harnesses are largely delivery mechanisms for good context engineering.

컨텍스트는 귀하고, 하네스란 대체로 좋은 컨텍스트 엔지니어링을 실어 나르는 장치다.

그리고 루프에 대해서는, 루프 설계가 프롬프트 엔지니어링보다 쉬운 게 아니라 어렵다고 못 박습니다.

즉 넷 중 어느 것도 앞의 것을 버리자고 하지 않습니다. 하네스를 만든다는 것은 결국 에이전트가 보는 자리에 무엇을 얹느냐의 문제이고, 그건 컨텍스트의 문제이며, 그 안에 프롬프트가 들어앉아 있습니다. 루프는 그 전체를 몇 번, 언제 돌릴 것인가를 얹은 것이고요.

정리하면 넷은 순서대로 갈아탄 것이 아니라 층으로 쌓인 것입니다. 안쪽이 틀리면 바깥을 아무리 잘 만들어도 소용없고, 바깥이 비면 안쪽은 한 번밖에 못 씁니다.

층으로 놓으면 증상만 보고 어디가 고장인지 짚을 수 있습니다. 이 글에서 가져갈 게 하나뿐이라면 이 표라고 생각합니다.

증상	어느 층
시킨 걸 잘못 알아들었다	프롬프트
알아는 들었는데 필요한 자료를 안 봤다 / 앞 얘기를 잊었다	컨텍스트
알고도 틀린 걸 냈는데 아무도 안 걸렀다	하네스
결과는 맞는데 내가 매번 「해」라고 쳐야 한다	루프
계속 돌긴 하는데 언제 끝인지 모르겠다	루프

우리 일로 옮겨보면

이름을 몰랐을 뿐, 이미 하고 있었습니다

에이전트가 OA 대응 검토 보고서 초안을 저에게 줄 때 검사 스크립트를 통과하지 못하면 넘기지 못하도록 해뒀습니다. 에이전트가 반복해서 어겼던 것들을 검사 항목에 넣어뒀습니다 — 채워 넣기로 한 자리가 비어 있는지, 쓰지 않기로 한 표현이 들어갔는지, 종속항 검토를 한 문장으로 뭉개는 상투구가 있는지 같은 것들입니다. (이 사이트에도 같은 게 있습니다. 글을 올리기 전 규약을 검사하고, 어기면 빌드가 멈춥니다.)

해시모토와 오스마니의 두 문장이 정확히 이걸 가리킵니다. 말만 다르고 같은 것이었습니다.

이름을 몰라서 손해 본 건 자랑거리가 아니라 빈 칸을 못 봤다는 것입니다. Fig. 7의 네 칸에 OA 대응 검토 업무를 얹어보면 이렇게 됩니다.

	계산적 (확정적·빠름)	추론적 (AI·느리고 확률적)
가이드 (사전)	보고서 양식 · 사건 폴더와 파일 이름 규약 · 원문 추출 절차	업무 지침 문서 · 잘 쓴 과거 보고서(골드 샘플) · 대응안을 어떤 순서로 만들지 정한 규칙
센서 (사후)	넘기기 전 검사 스크립트	심사관 역 반박 에이전트 · 판정 3인

오른쪽 아래가 제일 공들인 칸인데, 동시에 제일 못 미더운 칸입니다. 지난 글에 적은 그 일이 여기서 벌어집니다. 어떤 사건에서 판정 3인이 만장일치로 「등록 가능」을 준 안이 있었는데, 제가 구글 이미지로 1분 검색해 보니 그 안의 근거가 통째로 무너졌습니다. 인용문헌에 우연히 없었을 뿐, 시중에 흔한 물건이었거든요.

뵈켈러가 「동작 영역이 지금 가장 어렵다」고 한 게 정확히 이 자리입니다. 맞는 형식은 기계가 잡지만, 맞는 판단인지는 아직 기계가 못 잡습니다.

지난 글에서 「잘못 채웠다」고 쓴 칸들

지난 글에서 저는 OA 대응 검토를 서브 에이전트로 나눠 돌렸다가 두 건 다 실패했고, 네 자리 중 셋을 잘못 채웠다고 썼습니다. 거기까지만 적었습니다. 사실 그 셋은 그 작업 직후에 지침을 고쳐 막아둔 것들이었습니다. 이제 와서 이름을 붙이면 이렇게 됩니다.

• 정지 조건을 「등록 판정이 날 때까지」에서 **「두 라운드 연속으로 더 나은 안이 안 나오면 종료, 최대 세 라운드」**로 바꿨습니다. 앤트로픽이 「양적일수록 스스로 검증하기 쉽다」고 한 그대로입니다
• 지시의 세기가 한쪽으로 기울었던 것은, 보정하지 않는 안을 등록가능성과 무관하게 항상 제1안으로 남기는 규칙을 넣어 막았습니다
• 검사자가 문헌 안에서만 보던 것은 — 이게 제일 큰 것인데 — 어떤 안이 「인용문헌에 없다」는 이유만으로 살아남으려 할 때 걸리는 사전 필터를 새로 만들고, 거기에 「구글 이미지나 카탈로그로 1분간 실물을 확인할 것」을 지켜야 할 항목으로 넣었습니다

셋 다 프롬프트를 고친 게 아니라 규칙과 환경을 고친 것입니다. 이름을 붙이자면 하네스 엔지니어링이고, 그때는 그냥 「지침을 고쳤다」고 생각했습니다.

아직 고치는 중입니다. 지난 글을 쓴 뒤에 손본 것 중에는 아직 지침에 안 올라간 것도 있습니다.

다만, 그 필터 옆에 이렇게 적어뒀습니다

그 사전 필터를 만들면서 같은 문서에 이런 메모를 남겨뒀습니다.

이건 루프가 스스로 못 고치는 맹점이다. 이 필터는 변리사의 실물 감각을 게이트로 명문화한 것이지 해법이 아니다.

써놓고 잊고 있었는데, 이번에 뵈켈러의 문장 옆에 놓고 보니 같은 말이었습니다. 개입을 없앤 게 아니라, 개입이 가장 중요한 자리로 몰아둔 것입니다.

남는 생각

지난 글에서 ① 언제 시작하느냐가 비어 있다고 썼는데, 지금도 그대로입니다. 설계 문서에는 「퇴근할 때 자동으로 도는 자리에 둔다」고 써뒀는데, 실제 운영 지침은 「저녁 배치 준비 없음, 초안 생성은 수시」로 굳었습니다. 제가 「해」라고 쳐야 도는 건 아직 변한 게 없습니다.

한 가지 더. 이 루프를 만들고 나서도 기본값으로 삼지 않고 선택제로 뒀습니다. 사건에 따라 예전 방식이 나을 때가 있어서요. 앤트로픽 글의 마지막 줄과 같은 이야기입니다.

그리고 실제 사건으로 두 방식을 나란히 돌려본 적이 있는데, 두 방식 다 진짜 쟁점을 못 찾았습니다. 제가 던진 질문 두 개가 각각 하나씩 찾아냈습니다. 이 발명의 핵심 동작이 인용문헌에 정말 있는지, 심사관은 거기에 뭐라고 했는지를 물은 것이었습니다. 명세서를 읽은 사람이면 떠올릴 만한, 그런데 루프 안에는 없던 질문이었습니다.

오스마니의 경고가 정확히 그 자리를 가리킵니다.

A loop running unattended is also a loop making mistakes unattended.

지켜보지 않는 채 도는 루프는, 지켜보지 않는 채 실수하는 루프이기도 하다.

그 글의 마지막 절 제목은 이겁니다.

Build the Loop. Stay the Engineer.

루프를 만들되, 엔지니어로 남아라.

오스마니가 「엔지니어로 남아라」라고 쓴 자리에 저는 변리사를 넣으면 되겠다 싶었습니다. 앞자리의 「루프」는 에이전트로 넓혀도 되겠고요 — 그의 말대로 「에이전트 = 모델 + 하네스」라면, 여기까지 본 넷이 다 그 안에 들어갑니다.

AI는 수단이고, 변리업의 주체는 변리사입니다. 에이전트를 만들되, 변리사로 남아야 하지 않을까요?