Agents · ARTICLE · 2026

더 이상 Claude를 프롬프팅하지 않습니다 >> 하지만 프롬프트는 여전히 중요합니다

Sujin Kang (강수진) · linkedin.com ↗ · ↳ 12 links

요약

Sujin Kang이 LinkedIn에 올린 게시물로, AI 코딩 에이전트를 다룰 때 무엇을 최적화하는지가 약 4년 동안 네 단계를 거쳐 이동해왔다는 진단을 하나의 타임라인으로 배열한다. 순서는 prompt에서 context로, 다시 harness로, 마지막으로 loop다.

이 자료의 값은 새 기법을 제안하는 데 있지 않고 이미 흩어져 있던 네 개념에 순서와 좌표를 부여하는 데 있다. 각 단계에 제안자와 시점과 소속이 붙어 있어, 개념의 계보를 따라가려는 독자가 어느 자료부터 읽어야 하는지 판단할 수 있다. 이 wiki에서는 Prompt → Context → Harness → Loop Engineering: 4단계 진화 개괄가 그 배열을 그대로 채택해 4단계 진화 지도의 골격으로 삼는다.

게시물은 타임라인만 제시하고 끝나지 않는다. 루프를 이루는 구성 요소 여섯 가지에 역할을 하나씩 달고, 루프가 만드는 리스크 세 가지에 정의를 붙이며, 마지막으로 프롬프트 엔지니어링이 소멸했는지에 답한다. 저자의 답은 소멸하지 않았다는 것이며, 바뀐 것은 프롬프트의 형태와 수명이라는 진단으로 마무리한다.

제목은 두 문장이 붙은 형태다. 앞 문장이 "더 이상 Claude를 프롬프팅하지 않습니다"이고 뒤 문장이 "하지만 프롬프트는 여전히 중요합니다"다. 뒤 문장이 앞 문장의 범위를 제한한다. 프롬프트가 없어진다는 뜻이 아니라 프롬프트를 공급하는 주체가 바뀐다는 뜻이다.

배경

이 게시물의 출발점은 Boris Cherny가 남긴 한 문장이다. 게시물은 Cherny를 Claude Code를 이끄는 Anthropic 소속으로 소개하고, 이제 자신의 일은 프롬프트를 쓰는 것이 아니라 Claude를 프롬프팅하는 루프를 설계하는 것이라는 그의 말을 인용한다. 설계 대상이 문장에서 그 문장을 만들어내는 구조로 한 칸 바깥으로 나갔다는 진술이다.

게시물은 이 발언에 이름이 붙은 시점도 함께 적는다. 2026년 6월에 이 발언이 "Loop Engineering"이라는 이름을 얻으며 하나의 담론이 되었다는 것이다. 개인의 작업 방식 변화가 명명을 거쳐 공통 어휘로 옮겨간 경위를 한 문장으로 요약한 셈이다.

이 진술을 받아 게시물은 같은 종류의 이동이 이번이 처음이 아니라고 본다. 최적화 대상이 바깥으로 밀려나는 일이 약 4년 동안 세 번 더 있었고, 그 궤적을 이으면 하나의 타임라인이 된다는 것이다. loop engineering은 그 타임라인의 마지막 칸이다.

타임라인의 형태를 취한 덕분에 이 게시물은 개별 개념 소개와 다른 기능을 한다. 어떤 기법이 좋은지를 논하는 대신, 각 기법이 어떤 문제를 이어받았는지를 위치로 보여준다. 앞 단계의 한계가 다음 단계를 부른 순서라서, 뒤 단계를 읽을 때 앞 단계를 전제로 삼을 수 있다.

핵심 개념

prompt engineering은 한 번의 지시문을 최적화하는 일이다. 게시물은 이 단계의 질문을 "무엇을 말할 것인가"로 적는다. 최적화 대상이 사람이 직접 타이핑하는 한 덩어리의 텍스트로 한정된다.

context engineering은 유한한 컨텍스트에 무엇을 넣을지를 설계하는 접근이다. 게시물의 표현으로는 프롬프트 밖의 모든 토큰 구성을 최적화하는 것이며, 2025년 Anthropic이 개념을 정리한 것으로 표기한다. 같은 지시를 주더라도 함께 들어가는 문서, 이전 대화, 도구 출력이 결과를 바꾸므로 무엇을 넣고 뺄지가 설계 문제가 된다.

harness는 모델을 감싸 도구와 검증과 상태를 제공하는 실행 환경이다. 게시물은 harness engineering을 도구, 제약, 검증 게이트 등 모델 바깥의 실행 환경을 설계하는 일로 정의하고, 2026년 2월 HashiCorp 공동창업자 Mitchell Hashimoto의 제안으로 표기한다. 이 단계에는 "Agent = Model + Harness"라는 등식이 함께 붙어 있다. 에이전트를 모델 하나로 보지 않고 모델과 실행 환경의 합으로 본다는 뜻이다.

loop engineering은 에이전트를 반복 구동하는 루프 자체를 설계 대상으로 삼는 관점이다. 게시물은 이를 harness를 타이머 위에 올리고, 서브에이전트를 생성하고, 스스로에게 일을 공급하는 오케스트레이션 계층이라고 풀이한다. 2026년 6월 7일 Google Chrome의 Addy Osmani가 명명한 것으로 표기한다.

네 단계 진화

단계별 최적화 대상

게시물이 각 단계에 붙인 라벨은 다음과 같다. 최적화 대상 열은 게시물 본문의 서술을 그대로 옮긴 것이다.

단계	시점과 제안자	게시물이 적은 최적화 대상
Prompt Engineering	표기 없음	한 번의 지시문을 최적화. "무엇을 말할 것인가"
Context Engineering	2025년, Anthropic이 개념 정리	프롬프트 밖의 모든 토큰 구성을 최적화
Harness Engineering	2026년 2월, HashiCorp 공동창업자 Mitchell Hashimoto	도구, 제약, 검증 게이트 등 모델 바깥의 실행 환경을 설계
Loop Engineering	2026년 6월 7일, Google Chrome의 Addy Osmani	harness를 타이머 위에 올리고, 서브에이전트를 생성하고, 스스로에게 일을 공급하는 오케스트레이션 계층

게시물은 이 네 칸 전체를 약 4년에 걸쳐 최적화 단위가 이동해온 흐름이라고 부른다. 네 단계가 서로 대체 관계가 아니라 시간 순서로 놓였다는 뜻이다.

단계가 바뀔 때 달라지는 것

게시물은 이동의 방향을 괄호 안에 한 줄로 압축해 적는다. 단어에서 맥락으로, 맥락에서 환경으로, 환경에서 시스템으로 옮겨간다는 것이다. 그 결과가 두 가지로 서술된다. 사람이 설계하는 단위는 커지고 건별 개입은 줄어든다.

단계	게시물이 적은 설계 층위	설계자가 직접 쓰는 것	사람의 건별 개입
Prompt Engineering	단어	지시 문장	매 요청마다 필요하다
Context Engineering	맥락	지시 문장과 함께 들어갈 토큰	매 요청마다 필요하다
Harness Engineering	환경	모델이 일할 실행 환경	환경을 갖춘 뒤로 줄어든다
Loop Engineering	시스템	요청 자체를 만들어내는 루프	루프가 도는 동안 필요하지 않다

마지막 칸에서 성격이 한 번 더 바뀐다. 앞의 세 단계는 요청 한 번을 어떻게 잘 만들지를 다루지만, loop 단계는 요청이 여러 번 반복되는 구조를 다룬다. 사람이 매번 요청을 공급하지 않아도 순환이 이어지는 지점이 여기다.

제안자 표기의 근거

게시물은 네 단계 중 세 단계에 인물과 소속과 시점을 붙인다. 이 표기가 이 wiki 안에서 교차 확인되는지는 항목마다 다르다. 아래 표의 마지막 열은 게시물의 주장이 아니라 이 wiki의 다른 페이지를 대조한 결과다.

단계	게시물의 제안자 표기	소속 표기	시점	이 wiki에서의 교차 확인
Prompt Engineering	없음	없음	없음	해당 없음
Context Engineering	Anthropic	기관	2025년	저자가 댓글에 단 참고 자료가 Anthropic의 "Effective context engineering for AI agents"다
Harness Engineering	Mitchell Hashimoto	HashiCorp 공동창업자	2026년 2월	같은 attribution을 담은 다른 자료가 이 wiki에 없다
Loop Engineering	Addy Osmani	Google Chrome	2026년 6월 7일	Loop Engineering (Addy Osmani, 2026-06-07)이 같은 날짜의 원문이고 저자 소속 표기도 일치한다

Prompt Engineering 칸만 비어 있는 것은 표기 누락이라기보다 이 단계에 단일 제안자가 없기 때문으로 보인다. 다만 나머지 세 단계와 표기 수준이 고르지 않다는 점은 그대로 남는다.

제목의 구성

제목의 앞뒤 문장이 서로 다른 것을 말한다는 점이 이 게시물의 논지를 압축한다. "더 이상 프롬프팅하지 않는다"가 부정하는 것은 프롬프트의 가치가 아니라 사람이 매번 프롬프트를 직접 공급하는 방식이다. Cherny의 표현을 그대로 따르면 루프가 Claude를 프롬프팅하므로, 프롬프트는 여전히 시스템 안에서 만들어지고 쓰인다.

그래서 뒤 문장 "하지만 프롬프트는 여전히 중요합니다"가 부제로 따라붙는다. 최적화 대상이 바깥으로 나갔다고 해서 안쪽 칸이 사라지지 않는다는 것이 타임라인 전체에 걸친 전제이기도 하다. 게시물은 두 문장을 모두 Cherny가 한 말로 소개한다.

루프의 구성 요소

게시물이 든 목록

게시물은 루프를 이루는 요소를 여섯 가지로 들고 각각에 짧은 역할 설명을 단다. 목록 바로 위에 "Osmani가 정리한 요소를 요약했습니다"라는 주석이 붙어 있어, 이 목록이 저자의 독자적 분류가 아니라 원출처의 요약임을 게시물 스스로 밝힌다. 바로 아래에는 Claude Code와 Codex 모두 이미 갖춘 요소들이라는 문장이 이어진다.

구성 요소	게시물이 적은 역할	게시물이 든 구현 예
Automations	스케줄과 이벤트 트리거	`/loop`, cron, 훅, GitHub Actions
Worktrees	병렬 에이전트의 작업 격리	표기 없음
Skills	재사용 가능한 능력 패키징	표기 없음
Sub-agents	큰 목표의 분해와 위임	표기 없음
Connectors	외부 시스템 연결	MCP
+External State	실행 간 기억을 유지하는 외부 상태	표기 없음

소제목은 "루프의 5가지 구성 요소 (+n)"인데 실제 목록은 여섯 항목이다. 여섯 번째 항목만 이름 앞에 더하기 기호가 붙어 있어, 나머지 다섯과 성격이 다른 보조 항목으로 취급된 것으로 읽힌다. 모델이 세션 사이에 메모리를 갖지 않는다는 제약을 메우는 항목이라서 필수 구성 요소와 구분한 것으로 보인다.

원출처 자료와의 대조

두 자료의 목록을 나란히 놓으면 항목이 거의 그대로 대응한다. 아래 표의 오른쪽 두 열은 게시물이 아니라 Loop Engineering (Addy Osmani, 2026-06-07)이 서술하는 내용이다.

게시물의 항목	Osmani 페이지의 대응 항목	역할 (Osmani 페이지 기준)
Automations	Automations	예약된 발견과 분류를 사람 개입 없이 수행
Worktrees	Worktrees	병렬 실행 에이전트 사이의 파일 충돌 차단
Skills	Skills	프로젝트 지식을 문서로 고정해 재유도 반복 제거
Sub-agents	Sub-agents	구현 기능과 평가 기능의 분리
Connectors	Plugins와 Connectors	파일시스템 바깥 시스템과의 통합
+External State	Persistent state	실행 사이의 컨텍스트 보존

차이는 두 군데다. 다섯 번째 항목을 Osmani 페이지는 플러그인과 커넥터를 묶어 부르고 게시물은 커넥터만 적었다. 여섯 번째 항목의 이름도 external state와 persistent state로 나뉜다. 두 이름이 강조하는 지점이 다른데, 앞은 저장 위치가 모델 바깥이라는 점을 가리키고 뒤는 실행과 실행 사이에 값이 남는다는 점을 가리킨다.

역할 설명의 밀도도 다르다. 게시물은 항목당 한 구절로 줄였고 Osmani 원문은 항목마다 절을 하나씩 배정한다. 따라서 구성 요소를 실제로 설계할 때는 이 페이지가 아니라 Osmani 페이지를 읽는 편이 맞다.

도입 사례

게시물은 루프가 이미 현장에서 가동 중이라는 근거로 OpenAI를 든다. OpenAI가 내부에서 루프를 상시 가동 중이라고 했다며 세 가지 용도를 나열한다.

이슈 트리아지
CI 실패 요약
버그 헌팅

이 문장에는 출처 표기가 붙어 있지 않다. 게시물이 구성 요소 목록에는 Osmani 출처 주석을 달았지만 이 문장에는 달지 않았다. 게시물이 원출처로 지목한 Osmani 페이지는 하루 1회 triage 스킬을 실행하는 가상 시나리오와 Codex 앱 사례를 들 뿐, OpenAI가 사내에서 루프를 상시 가동한다는 서술은 담고 있지 않다. 따라서 세 용도는 확인된 사실이 아니라 게시물의 전언으로 다루는 편이 안전하다.

바로 다음 문장에서 게시물은 방향을 바꾼다. 이 개념을 말한 Osmani 자신이 가장 회의적이라는 것이다. 도입 사례를 든 직후에 회의론을 배치한 구성이라, 세 가지 리스크가 이어질 자리를 만든다.

세 가지 리스크

게시물이 붙인 정의

게시물은 루프로 옮겨가면서 생기는 리스크 세 가지에 이름과 한 줄 정의를 함께 단다.

리스크	게시물이 붙인 정의	부담이 남는 자리
검증 부채	에이전트는 증거 없이 "완료"라고 주장한다	산출물을 확인하는 사람
comprehension debt	내가 쓰지 않은 코드가, 내 이해 속도보다 빠르게 쌓인다	코드베이스를 유지하는 사람
인지적 저항	루프가 주는 결과를 판단 없이 수용하게 되는 상태	결과를 판단하는 사람

세 항목의 공통점은 자동화가 걷어 가지 못하는 부담이라는 것이다. 실행 속도는 루프가 올려 주지만 확인과 이해와 판단은 사람에게 그대로 남는다. 세 이름이 모두 사람 쪽 상태를 가리키는 것도 그래서다.

세 항목 바로 뒤에 결과의 편차를 지적하는 문장이 붙는다. 같은 루프를 두 사람이 실행해도 정반대의 결과가 나온다는 것이다. 도구가 결과를 결정하지 않고 사용하는 사람의 판단이 결정한다는 뜻으로, 앞의 세 리스크가 왜 도구로 해결되지 않는지를 설명한다.

인접 자료의 대응 항목

게시물이 원출처로 지목한 Osmani 페이지도 한계를 세 가지로 정리한다. 두 목록이 같은 것을 가리키는지 확인하려면 정의를 대조해 볼 수 있다. 아래 표의 오른쪽 두 열은 게시물의 주장이 아니라 Loop Engineering (Addy Osmani, 2026-06-07)의 서술이다.

게시물의 이름	Osmani 페이지의 항목	대응 여부
검증 부채	verification 부담. 사람이 지켜보지 않는 루프는 사람이 지켜보지 않는 실수도 만든다	검증 책임이 사람에게 남는다는 점에서 같은 문제다
comprehension debt	comprehension debt. 배포된 시스템과 개발자의 이해 사이에 벌어지는 격차	이름과 정의가 모두 대응한다
인지적 저항	comfortable passivity. 실행의 편리함이 비판적 검토를 무디게 만드는 상태	정의는 대응하지만 이름의 방향이 반대다

세 항목 모두 정의 수준에서는 맞물린다. 세 번째만 이름에 문제가 남는다. 게시물이 붙인 정의는 판단 없이 수용하게 되는 상태이므로 Osmani의 comfortable passivity와 같은 것을 가리키는데, 인지적 저항이라는 이름은 문자 그대로 읽으면 받아들이지 않으려는 태도에 가깝다. 이름만 보고 뜻을 짐작하면 반대로 읽힌다.

프롬프트의 자리

결론부의 네 명제

게시물은 프롬프트 엔지니어링이 소멸했는지 묻고 전혀 그렇지 않다고 답한다. 이어지는 서술은 네 개의 명제로 정리된다.

명제	게시물의 서술
프롬프트 엔지니어링의 존속	소멸하지 않았다. 루프는 프롬프트로 만들어진다
품질의 전파	루프 안의 엉성한 프롬프트는 엉성한 결과물을 더 빠르게 찍어낼 뿐이다
계층 관계	하위 계층인 프롬프트와 컨텍스트는 사라지지 않고 루프가 그 위에 구조를 추가한다
실패의 대가	루프에서는 프롬프트를 잘못 쓰면 오류가 증폭되는 구조가 된다

두 번째와 네 번째 명제가 한 쌍을 이룬다. 루프는 프롬프트의 품질을 보정하지 않고 그대로 반복하므로, 프롬프트가 나쁘면 나쁜 결과가 더 많이 나온다는 것이다. 자동화가 품질 문제를 해소하는 것이 아니라 증폭한다는 진단이라서, 앞 절의 검증 부채와 같은 방향을 가리킨다.

형태와 수명의 변화

게시물이 최종적으로 내놓는 정의는 프롬프트가 없어진 것이 아니라 프롬프트의 형태와 수명이 바뀌었다는 것이다. 사람이 매 턴 타이핑하는 1회성 지시문이었다면, 이제는 시스템에 내장되는 프롬프트로 레버리지가 이동했다.

구분	이전	이후
작성 시점	사람이 매 턴 타이핑한다	시스템에 미리 내장한다
수명	1회성 지시문	루프가 도는 동안 반복 사용된다
작업의 질문	"어떻게 말할 것인가"	"내가 없는 동안 에이전트가 무엇이 말하게 할 것인가"
잘못 썼을 때	그 요청 하나가 실패한다	오류가 증폭되는 구조가 된다

작업의 질문이 바뀌는 대목에 게시물은 괄호로 부연을 단다. "내가 없는 동안"이 "내가 작업을 보지 않는 동안"이라는 뜻이라는 것이다. 사람이 자리를 비운 시간에도 에이전트가 쓸 문장을 미리 준비해 두는 일이 새 작업의 내용이 된다.

마지막 문장이 저자의 최종 입장이다. 루프를 자동으로 구축하되 직접 프롬프트는 여전히 유효하며, 결국 시스템을 설계하는 균형의 문제라는 것이다. 어느 한쪽을 버리는 선택이 아니라 두 층을 함께 두는 설계라는 뜻이다.

한계

이 자료를 인용할 때 유의할 제약은 다섯 가지다.

본문에 링크와 각주가 없다. Cherny, Hashimoto, Osmani의 발언이 이름과 시점과 소속으로만 표기되고 개별 발언의 원문 인용이 붙어 있지 않다. 참고 자료 두 건은 본문이 아니라 저자 본인이 단 첫 댓글에 있고, 이 wiki에는 게시물 스크린샷으로만 아카이브되어 있다.
OpenAI 사례에 출처가 없다. 이슈 트리아지, CI 실패 요약, 버그 헌팅에 루프를 상시 가동 중이라는 서술의 근거가 본문에 없다. 게시물이 원출처로 지목한 Osmani 페이지에도 같은 서술이 없어 어디서 온 정보인지 확인되지 않는다.
리스크 세 가지의 화자가 명확하지 않다. 구성 요소 목록에는 Osmani가 정리한 것을 요약했다는 주석이 붙어 있지만 리스크 목록에는 같은 주석이 없다. 앞 문장이 Osmani의 회의적 태도를 언급하므로 Osmani의 정리로 읽을 여지가 있으나 게시물이 명시하지는 않는다.
세 번째 리스크의 이름과 정의가 어긋난다. 이름은 인지적 저항인데 정의는 판단 없이 수용하게 되는 상태를 서술한다. 저항과 수용은 반대 방향이므로 이름만 인용하면 뜻이 뒤집힌다.
harness 단계의 attribution이 단일 근거다. harness engineering을 Mitchell Hashimoto의 2026년 2월 제안으로 보는 배열은 이 wiki 안에서 이 자료가 유일한 근거다. 같은 주제를 다루는 Harness Engineering (Team Attention, 2026)은 이 attribution을 담고 있지 않고, Prompt → Context → Harness → Loop Engineering: 4단계 진화 개괄의 표기도 이 게시물에서 가져온 것이다. 따라서 이 항목은 교차 검증되지 않은 상태다.

표기 수준의 문제도 두 가지 남는다. 소제목은 "5가지 구성 요소 (+n)"인데 나열은 여섯 항목이고, 네 단계 중 Prompt Engineering에만 시점과 제안자 표기가 없다.

이 제약을 감안하면 이 자료는 개념을 깊이 배우는 곳이 아니라 순서를 잡는 곳으로 쓰는 편이 맞다. 네 단계의 이름과 위치, 구성 요소와 리스크의 목록을 확인한 뒤, 각 항목의 세부는 아래 관련 페이지에서 읽는 방식이다.

핵심 용어

용어	뜻
prompt engineering	한 번의 지시문을 최적화하는 일. 게시물은 이 단계의 질문을 "무엇을 말할 것인가"로 적는다
context engineering	프롬프트 밖의 모든 토큰 구성을 최적화하는 접근. 게시물은 2025년 Anthropic이 개념을 정리한 것으로 표기한다
harness engineering	도구, 제약, 검증 게이트 등 모델 바깥의 실행 환경을 설계하자는 제안. 게시물은 2026년 2월 Mitchell Hashimoto의 제안으로 표기한다
loop engineering	harness를 타이머 위에 올리고 서브에이전트를 생성하며 스스로에게 일을 공급하는 오케스트레이션 계층. 게시물은 2026년 6월 7일 Addy Osmani가 명명한 것으로 표기한다
Agent = Model + Harness	harness 단계에 함께 적힌 등식. 에이전트를 모델과 실행 환경의 합으로 본다는 뜻이다
External State	실행 간 기억을 유지하는 외부 상태. 구성 요소 목록에서 유일하게 이름 앞에 더하기 기호가 붙은 항목이다