2026년 2월, Mitchell Hashimoto(HashiCorp 공동창업자)는 자신의 블로그에서 이렇게 썼습니다.

“에이전트가 실수를 할 때마다, 그 실수를 다시는 반복할 수 없도록 환경을 엔지니어링한다. 나는 이걸 ‘하네스 엔지니어링(harness engineering)‘이라고 부른다.”

이 짧은 문장에서 시작된 용어가, 몇 주 만에 OpenAI와 Anthropic의 공식 엔지니어링 블로그를 타고 업계의 새로운 키워드가 되었습니다.

그런데 — 왜 하필 지금 이 개념이 필요해졌을까요? 그 답을 이해하려면, 우리는 70년을 거슬러 올라가야 합니다.

📖 글의 흐름

1. 1부. 추상화의 70년 역사 — 0과 1에서 Markdown까지
2. 2부. AI 시대의 3단계 진화 — Prompt → Context → Harness Engineering
3. 3부. 왜 지금 “하네스"인가 — Mitchell Hashimoto의 통찰
4. 4부. 우리 팀에게 주는 의미

1부. 추상화의 70년 역사

🎯 한 문장으로 요약하면

“프로그래밍의 역사는, 사람이 기계에게 덜 말하고 더 적게 쓰도록 만들어온 역사다.”

아래 다이어그램은 70년간 코딩 추상화의 흐름을 한눈에 보여줍니다.

timeline
    title 코딩 추상화의 진화 (1940s ~ 2020s)
    1940s : 기계어 (Machine Code)
          : 0과 1의 이진 코드
          : 천공카드로 입력
    1949  : 어셈블리어 (Assembly)
          : MOV, ADD 같은 니모닉
          : EDSAC에서 첫 사용
    1972  : C 언어
          : Dennis Ritchie (Bell Labs)
          : CPU 독립적 고급 언어
    2000s : 프레임워크 시대
          : React, Spring, Django
          : 비즈니스 로직에만 집중
    2020s : Markdown·자연어
          : AGENTS.md, CLAUDE.md
          : AI가 코드를 작성

각 단계마다 공통 패턴이 있습니다:

flowchart LR
    A[사람이 쓰는 것] --> B[기계에게 위임하는 것]
    B --> C[새로운 추상화 계층이 생김]
    C --> D[사람은 더 높은 수준의 의도만 표현]
    D --> A
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#e8f5e9

그럼 각 단계가 무엇을 추상화했고, 무엇을 남겼는지 살펴보겠습니다.

🕰️ Stage 1: 기계어 — “0과 1의 시대” (1940년대)

당시 실제로 작성하던 코드는 이랬습니다:

1
2

10110000 01100001
10000111 11000011

컴퓨터가 직접 이해하는 이진 코드. 이 비트 패턴을 종이 카드에 구멍을 뚫어 입력해야 했습니다. CPU 명령어 하나하나를 비트 단위로 직접 계산하고, 메모리 주소도 머릿속으로 따져가며 썼습니다. 구멍 하나만 잘못 뚫어도 전체 프로그램이 망가졌고, 기종이 다르면 처음부터 다시 시작해야 했습니다.

💡 이 시대는 사람이 기계의 언어를 배워야 했습니다. 기계가 사람에게 맞추는 게 아니라, 사람이 기계에 맞춰야 했던 시절이었습니다.

🕰️ Stage 2: 어셈블리어 — “숫자에 이름 붙이기” (1949년)

1949년, 영국 케임브리지의 EDSAC 컴퓨터에서 어셈블리어가 처음 본격적으로 사용되었습니다.

1
2

MOV AX, 5      ; 5를 AX 레지스터에 저장
ADD AX, 3      ; AX에 3을 더함 (결과: 8)

비트 패턴에서 이름으로 — 단순해 보이지만 이게 큰 전환이었습니다. 어셈블러라는 프로그램이 텍스트를 기계어로 자동 번역해줬고, 이제 코드를 눈으로 읽고 고칠 수 있게 됐습니다.

flowchart LR
    A["10110000
01100001"] -->|어셈블러가 번역| B["MOV AL, 97"]
    B --> C["사람이 읽고 쓸 수 있음!"]
    style A fill:#ffebee
    style B fill:#fff9c4
    style C fill:#e8f5e9

다만 하드웨어의 사슬을 완전히 벗어난 건 아니었습니다. CPU 종류마다 어셈블리어가 달랐고 (x86, ARM, MIPS 전부 제각각), 메모리 주소나 레지스터는 여전히 개발자가 직접 신경 써야 했죠. 복잡한 프로그램 하나에 수백~수천 줄은 기본이었습니다.

💡 숫자 대신 이름으로 말할 수 있게 됐지만, 여전히 하드웨어를 신경 써야 했습니다.

🕰️ Stage 3: 고급 언어 C — “기계를 잊다” (1972년)

1957년 FORTRAN을 시작으로 고급 언어들이 등장했지만, 현대 프로그래밍의 진짜 출발점은 1972년 Bell Labs의 Dennis Ritchie가 만든 C 언어였습니다.

1
2
3
4
5

int sum = 0;
for (int i = 0; i < 10; i++) {
    sum += i;
}
printf("합계: %d\n", sum);

C가 가져온 변화의 핵심은 이식성이었습니다. 컴파일러가 각 기계에 맞는 기계어로 알아서 번역해줬으니, 한 번 짠 코드가 여러 기계에서 돌아갔습니다.

flowchart TB
    A[개발자: C 코드 작성] --> B[컴파일러]
    B --> C[x86 기계어]
    B --> D[ARM 기계어]
    B --> E[RISC-V 기계어]
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#ffebee

MOV, ADD 대신 if, for, while 같은 논리적 개념으로 코드를 쓸 수 있게 됐고, CPU 명령어 선택이나 레지스터 관리 같은 저수준 작업은 컴파일러가 대신 처리했습니다. C는 훗날 C++, Java, JavaScript, Python, Go 등 거의 모든 현대 언어의 조상이 됩니다.

💡 사람은 처음으로 “기계"를 잊고 “문제"에만 집중할 수 있게 됐습니다.

🕰️ Stage 4: 프레임워크 시대 — “뼈대를 빌리다” (2000년대~)

1
2
3
4

// React (2013) — UI를 DOM으로 직접 그릴 필요 없음
function WelcomeButton() {
  return <button onClick={sayHi}>안녕!</button>;
}

1
2
3
4
5

// Spring (2003) — 웹 서버, DB 연결을 선언만 하면 됨
@GetMapping("/users")
public List<User> getUsers() {
    return userService.findAll();
}

예전에 웹 서버 하나 만들려면 소켓 열기, HTTP 프로토콜 파싱, 라우팅 로직, DB 커넥션 풀, 세션 관리까지 전부 직접 짜야 했습니다. 프레임워크가 이 공통 뼈대를 미리 다 만들어두면서, 개발자는 비즈니스 로직에만 집중할 수 있게 됐습니다.

flowchart LR
    A[비즈니스 로직
사용자가 작성] --> B[프레임워크
React/Spring/Django]
    B --> C[저수준 작업
HTTP, DB, UI 렌더링]
    C --> D[운영체제 & 하드웨어]
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#ffebee

반복적이고 규약적인 “어떻게” 부분은 프레임워크에게 넘기고, 사람은 **“무엇을 만들 것인가”**만 작성하면 됐습니다.

💡 선언만 하면 됐습니다. “이 버튼을 여기에 두고, 이 데이터를 보여줘.”

🕰️ Stage 5: Markdown과 자연어의 시대 — “문서가 곧 코드” (2020년대~)

🌟 변곡점: 2020년 GPT-3

2020년 GPT-3가 공개되면서, AI가 자연어 설명만 보고 실제로 동작하는 코드를 쓸 수 있다는 것이 증명되었습니다. 2022년 ChatGPT, 2023년 GitHub Copilot, 그리고 2024~2026년 Claude Code / Codex / Cursor까지 — 불과 6년 만에 판도가 완전히 바뀌었습니다.

📝 오늘날 프로그래밍이 일어나는 모습

다음은 실제 Markdown 파일 하나입니다:

1
2
3
4
5
6
7
8
9

# 레트로 게임 메이커

레벨 에디터, 스프라이트 에디터, 엔티티 동작, 
플레이 가능한 테스트 모드를 갖춘 2D 레트로 게임 메이커를 만들어라.

## 요구사항
- React + Vite 사용
- AI 기능 통합
- 공유 가능한 링크로 게임 내보내기

이 1문장짜리 Markdown이 Claude 에이전트에게 전달되면, 실제로 3시간 50분 동안 자율적으로 동작하며 **동작하는 DAW(Digital Audio Workstation)**을 만들어냅니다.¹

¹ 이는 가정이 아닙니다. Anthropic이 2026년 3월 24일 공식 엔지니어링 블로그에서 실험 결과로 공개한 실제 사례입니다. (링크)

📂 “Markdown이 코드가 된” 사례들

🎯 GitHub의 공식 선언 (2025년 10월)

GitHub 공식 블로그는 2025년 10월, 다음과 같은 제목의 글을 올렸습니다:

“Spec-driven development: Using Markdown as a programming language when building with AI” (AI로 빌드할 때 Markdown을 프로그래밍 언어로 사용하는 스펙 기반 개발)

기사에서 한 개발자는 Go 프로젝트를 오직 Markdown으로만 작성하고, GitHub Copilot에게 Go 코드로 “컴파일"하도록 시켰습니다. 그는 “실제 Go 파일은 거의 보지도, 편집하지도 않는다“고 썼습니다.

🔄 무엇이 바뀌었나?

flowchart LR
    A[자연어 Markdown] --> B[AI 에이전트]
    B --> C[코드 작성]
    B --> D[테스트 실행]
    B --> E[버그 수정]
    B --> F[배포 준비]
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#e8f5e9
    style D fill:#e8f5e9
    style E fill:#e8f5e9
    style F fill:#e8f5e9

• 문법을 외울 필요 없음 — AI가 알아서 번역
• 프레임워크 API를 찾을 필요 없음 — AI가 알아서 선택
• 구현 디테일을 쓸 필요 없음 — AI가 알아서 채움
• 사람은 “무엇을 원하는가"를 한국어로 쓰기만 함

🎨 한 표로 보는 추상화의 진화

2부. AI 시대의 3단계 진화

⚡ Markdown으로 코딩하는 시대의 새로운 문제

Markdown으로 의도를 전달하는 것은 분명 쉬워졌습니다. 하지만 써본 사람들은 곧 깨달았습니다:

• “AI가 내 의도를 자꾸 잘못 이해한다.”
• “같은 질문에 매번 다르게 답한다.”
• “긴 작업을 시키면 중간에 엉뚱한 방향으로 간다.”

이 문제를 해결하려는 시도가 순차적으로 등장했습니다.

timeline
    title AI 엔지니어링의 3단계 진화
    2020-2023 : Prompt Engineering
              : "어떻게 질문할까?"
              : 단일 턴 출력 최적화
    2024-2025 : Context Engineering
              : "무엇을 보여줄까?"
              : 세션 내 맥락 관리
    2026~     : Harness Engineering
              : "어떤 환경에서 일하게 할까?"
              : 장시간 자율 실행 환경 설계

🧩 Phase 1: Prompt Engineering — “질문을 잘 하기” (2020~2023)

2020년 GPT-3가 공개되면서 이 분야가 열렸고, 2022년 ChatGPT 출시로 대중화됐습니다.

핵심 아이디어

“모델이 같아도, 프롬프트만 잘 쓰면 결과가 극적으로 달라진다.”

대표 기법들

mindmap
  root((Prompt
Engineering))
    Zero-shot
      그냥 물어보기
    Few-shot
      예시 몇 개 보여주기
    Chain-of-Thought
      단계별로 생각하게 하기
    Role Prompting
      역할 부여
    Tree-of-Thought
      여러 갈래 사고

예시 비교

❌ 나쁜 프롬프트:

1

코드 짜줘

✅ 좋은 프롬프트:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

당신은 Python 전문가입니다. 다음 요구사항을 만족하는 
REST API 엔드포인트를 작성해주세요. 
단계별로 생각하며 답하세요.

[요구사항]
- GET /users/:id 엔드포인트
- 존재하지 않으면 404 반환
- 입력 검증 포함

[예시 출력 형식]
1. 먼저 ...
2. 다음으로 ...

한계

실제로 써보면 곧 한계가 드러났습니다. 한 번의 대화에서는 잘 작동했지만, 긴 작업을 시키거나 대화가 길어지면 맥락을 잃기 시작했습니다. 프롬프트가 아무리 정교해도, 대화 중간에 맥락이 끊기면 소용이 없었죠.

💡 프롬프트 엔지니어링은 **“질문을 잘하는 기술”**이었습니다. 필요한 기술이었지만, 그것만으로는 충분하지 않았습니다.

🧩 Phase 2: Context Engineering — “시야를 설계하기” (2024~2025)

2024년부터 조금씩 등장하던 이 개념은, 2025년 6월 Shopify CEO Tobi Lütke가 X(구 Twitter)에서 “prompt engineering보다 context engineering이라는 표현이 더 적절하다"고 올리면서 빠르게 퍼졌습니다. **Andrej Karpathy(OpenAI 창립 멤버, Tesla AI 전 책임자)**도 이에 동의하면서 용어가 굳어졌습니다.

**Karpathy의 원문 (2025.06.25 X 게시물)**²:

“‘프롬프트 엔지니어링’보다 ‘컨텍스트 엔지니어링’이라는 용어에 +1. 사람들은 프롬프트를 일상에서 LLM에게 주는 짧은 작업 설명으로 연상하지만, 모든 산업용 LLM 앱에서 컨텍스트 엔지니어링은 다음 단계에 꼭 맞는 정보로 컨텍스트 창을 채우는 섬세한 기술이자 과학이다.”

² 출처: Andrej Karpathy X 게시물 (@karpathy), 2025년 6월 25일.

Gartner도 같은 말을 했습니다 (2025년 7월)

Gartner 선언: “Context engineering is in, prompt engineering is out.” (컨텍스트 엔지니어링이 대세이고, 프롬프트 엔지니어링은 한물갔다.)

Gartner는 2028년까지 AI 애플리케이션 구축 도구의 80%가 컨텍스트 엔지니어링 기능을 갖출 것으로 예측.³

³ 출처: Gartner 리서치 보고서, 2025년 7월. 여러 AI 업계 매체에서 인용됨.

핵심 아이디어

“모델은 병목이 아니다. 모델이 받는 컨텍스트가 병목이다.”

대표 기법들

flowchart TB
    A[사용자 질문] --> B{Context Engineering}
    B --> C[RAG
관련 문서 검색]
    B --> D[System Prompt
세션 지시사항]
    B --> E[Compaction
대화 요약]
    B --> F[Context Window
관리]
    C --> G[LLM]
    D --> G
    E --> G
    F --> G
    G --> H[더 나은 출력]
    style B fill:#fff3e0
    style G fill:#e3f2fd

• RAG (Retrieval-Augmented Generation): 회사 내부 문서, 최신 정보 등을 실시간으로 검색해 컨텍스트에 삽입
• Compaction: 긴 대화를 요약해서 컨텍스트 창 절약
• System Prompt 설계: 세션 전체에 걸친 지시사항 구조화

한계

컨텍스트 엔지니어링은 세션 안에서의 문제는 해결했습니다. 하지만 에이전트가 수 시간 동안 수백 가지 결정을 혼자 내려야 하는 상황, 그리고 세션이 바뀌면 모든 맥락이 다시 사라지는 문제는 여전히 남아 있었습니다.

💡 컨텍스트 엔지니어링은 **“AI의 시야를 설계하는 기술”**이었습니다. 하지만 AI가 일하는 시간 자체가 길어지면, 시야 설계만으로는 부족했습니다.

🧩 Phase 3: Harness Engineering — “환경을 설계하기” (2026~)

이 개념은 2026년 2월 5일, Mitchell Hashimoto의 블로그 포스팅 하나에서 출발했습니다.

타임라인

gantt
    title Harness Engineering 확산 타임라인 (2025.11 ~ 2026.03)
    dateFormat YYYY-MM-DD
    section 초기 논의
    Anthropic 첫 글 "effective harnesses"      :2025-11-26, 1d
    section 용어 확립
    Mitchell Hashimoto "Engineer the Harness"  :2026-02-05, 1d
    OpenAI "Harness Engineering" 블로그         :2026-02-11, 1d
    section 확산
    Anthropic "Harness Design" 후속편          :2026-03-24, 1d

핵심 아이디어

Mitchell Hashimoto의 원문을 직접 인용하면:

“에이전트가 실수하는 것을 발견할 때마다, 시간을 들여서 그 에이전트가 다시는 같은 실수를 할 수 없도록 해결책을 엔지니어링한다. 나는 이것을 ‘하네스 엔지니어링’이라고 부른다.”

— Mitchell Hashimoto, “My AI Adoption Journey” (2026.02.05)⁴

⁴ 출처: https://mitchellh.com/writing/my-ai-adoption-journey — Step 5 “Engineer the Harness” 섹션에서 직접 인용.

왜 필요해졌나?

flowchart TB
    A[2020~2023
Prompt Engineering] -->|여전히 풀리지 않는 문제| B[2024~2025
Context Engineering]
    B -->|여전히 풀리지 않는 문제| C[2026~
Harness Engineering]
    
    D[문제: 단일 출력 품질] -.->|해결| A
    E[문제: 세션 내 맥락 관리] -.->|해결| B
    F["문제: 
수 시간 자율 실행
수백 개 결정
감독 없음"] -.->|해결| C
    
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style F fill:#ffebee

2025년 말부터 AI 에이전트가 수 시간~수일간 자율 실행 가능해졌습니다. 그런데 이 시간 동안 에이전트는 수백 개의 결정을 감독 없이 내려야 합니다. 이때 병목은 **“모델 지능"이 아니라 “환경 설계”**임이 드러났습니다.

“하네스(Harness)“란?

원래 하네스는 **말에게 씌우는 마구(馬具)**입니다. 말의 힘을 없애는 것이 아니라, 올바른 방향으로 쓸 수 있게 통제하는 장치입니다.

AI 분야에서 하네스란:

flowchart TB
    subgraph HARNESS["🎯 하네스 (에이전트를 둘러싼 모든 것)"]
        direction TB
        subgraph AGENT["에이전트 런타임"]
            LLM[LLM
모델]
        end
        
        DOC[문서 구조
AGENTS.md]
        TOOL[도구
Linter, CI, DevTools]
        FB[피드백 루프
에러 메시지]
        CON[제약 조건
아키텍처 규칙]
        OBS[관찰성
Logs, Metrics]
        
        DOC -.-> LLM
        TOOL -.-> LLM
        FB -.-> LLM
        CON -.-> LLM
        OBS -.-> LLM
    end
    
    style HARNESS fill:#fff3e0
    style AGENT fill:#e3f2fd
    style LLM fill:#bbdefb

공식 = Agent = LLM + Harness

업계에서 흔히 쓰이는 단순한 정의:

Agent = LLM + Harness

• LLM이 “무엇을 할지” 결정
• Harness가 “무엇을 볼 수 있고, 어떤 도구를 쓸 수 있고, 잘못됐을 때 어떻게 되는지” 결정

대표 기법들

OpenAI와 Anthropic이 각자 공개한 실험 결과에서 공통적으로 나타나는 원칙들:

mindmap
  root((Harness
Engineering))
    Progressive Disclosure
      AGENTS.md 100줄 목차
      필요할 때 깊은 문서로
    Mechanical Enforcement
      커스텀 린터
      CI 자동 검증
    Session Handoff
      progress.txt
      git log + JSON feature list
    Generator vs Evaluator
      일하는 에이전트
      판단하는 에이전트
    Agent Legibility
      Chrome DevTools
      LogQL / PromQL
    Garbage Collection
      백그라운드 문서 청소
      주기적 리팩토링 PR

1. Progressive Disclosure (점진적 공개) — OpenAI 모든 규칙을 한꺼번에 주지 않고, 100줄짜리 AGENTS.md “목차"만 주고 필요할 때 깊은 문서로 유도

2. Mechanical Enforcement (기계적 강제) — OpenAI 규칙을 문서에만 적지 않고, 커스텀 린터와 CI로 자동 검증. 린터 에러 메시지에 수정 방법을 포함

3. Session Handoff (세션 핸드오프) — Anthropic #1 (2025.11) 긴 작업을 여러 세션으로 쪼개고, 파일로 상태 전달 (progress.txt, feature_list.json, git log)

4. Generator–Evaluator 분리 — Anthropic #2 (2026.03) 일하는 에이전트와 독립적으로 판단하는 에이전트를 분리 (GAN에서 영감)

5. Agent Legibility (에이전트 가독성) — OpenAI Chrome DevTools, LogQL, Playwright 등 에이전트가 직접 쿼리할 수 있는 도구 제공

6. Continuous Garbage Collection — OpenAI 백그라운드 에이전트가 문서·코드 드리프트를 주기적으로 청소

충격적인 결과

OpenAI의 실험 결과 (2026.02 공개): 소수의 엔지니어 팀(3명)이 5개월간 단 한 줄의 코드도 직접 쓰지 않고, 약 100만 줄의 프로덕션 코드와 약 1,500개의 PR을 만들어내 실제 베타 제품을 출시. 수동 코딩 대비 약 1/10의 시간이 걸림.⁵

⁵ 출처: OpenAI 공식 엔지니어링 블로그, “Harness Engineering: Leveraging Codex in an Agent-First World” (2026.02.11). 링크

🔄 세 가지 엔지니어링 한눈에 비교

세 가지는 배타적이 아니라 누적적입니다. 좋은 하네스는 좋은 컨텍스트를 포함하고, 좋은 컨텍스트는 좋은 프롬프트를 포함합니다.

flowchart TB
    subgraph H["🏗️ Harness Engineering (2026~)"]
        subgraph C["📦 Context Engineering (2024~2025)"]
            subgraph P["💬 Prompt Engineering (2020~2023)"]
                CORE[좋은 질문]
            end
        end
    end
    style H fill:#f3e5f5
    style C fill:#fff3e0
    style P fill:#e3f2fd

3부. 왜 지금 “하네스"인가 — Mitchell Hashimoto의 통찰

📖 한 사람의 진짜 경험에서 시작된 용어

Mitchell Hashimoto는 Terraform을 공동 창시하고 HashiCorp를 창업한 개발자입니다. 그는 2026년 2월 5일, “My AI Adoption Journey"라는 제목의 블로그 글에서 자신의 AI 도구 도입 여정을 6단계로 정리했습니다.

flowchart LR
    S1["Step 1
챗봇에서 탈출"] --> S2["Step 2
직접 작업 재현"]
    S2 --> S3["Step 3
End-of-Day 에이전트"]
    S3 --> S4["Step 4
잘하는 일은 위임"]
    S4 --> S5["Step 5
하네스를 엔지니어링"]
    S5 --> S6["Step 6
항상 에이전트 실행"]
    style S5 fill:#ffecb3

그가 “하네스 엔지니어링"을 Step 5에 배치한 것에는 의미가 있습니다. 그는 AI를 도입하는 과정에서 앞선 4단계를 다 거치고 나서야, 진짜 생산성 도약이 하네스 엔지니어링에서 왔다고 말합니다.

그의 정의 (원문 그대로)

“하네스 엔지니어링은 두 가지 형태로 나타난다.

1. 더 나은 암묵적 프롬프팅 (AGENTS.md). 에이전트가 반복해서 잘못된 명령을 실행하거나 잘못된 API를 찾는 같은 단순한 문제는, AGENTS.md를 업데이트한다.

2. 실제 프로그램된 도구들. 예를 들어 스크린샷을 찍는 스크립트, 필터링된 테스트를 실행하는 스크립트 등. 보통 이것들은 AGENTS.md 변경과 함께 쓰인다.”

핵심 철학

“매번 에이전트가 잘못하는 것을 볼 때마다, 그것이 다시는 일어날 수 없도록 진지한 노력을 한다.”

이것은 단순히 AI에게 더 명령을 잘하는 것이 아닙니다. 시스템의 구조를 바꿔서 그 실수가 구조적으로 불가능해지게 만드는 것입니다.

왜 이 접근법이 확산되었는가?

2020년 이후 AI 도구를 써본 사람이라면 누구나 이 경험을 합니다:

flowchart LR
    A[에이전트 실수 발생] --> B{"어떻게 대응?"}
    B -->|프롬프트만 더 잘 쓰기| C["같은 실수 반복 😤"]
    B -->|환경을 바꾸기
하네스 엔지니어링| D["구조적으로
불가능해짐 ✅"]
    style C fill:#ffebee
    style D fill:#e8f5e9

Mitchell은 이 블로그 직후 몇 주 만에 OpenAI와 Anthropic이 같은 통찰을 다른 각도에서 공식화한 글을 연달아 발표했다고 관찰했습니다. 이는 업계 전체가 동시에 같은 지점에 도달했다는 강력한 신호입니다.

4부. 우리 팀에게 주는 의미

🎯 1. 추상화의 역사는 반복된다

flowchart LR
    A[문제:
비트 배치] -->|추상화| B[해결:
어셈블러]
    B --> C[문제:
알고리즘 작성]
    C -->|추상화| D[해결:
컴파일러]
    D --> E[문제:
앱 조립]
    E -->|추상화| F[해결:
프레임워크]
    F --> G[문제:
AI에게 뭘 줄까?]
    G -->|추상화| H[해결:
하네스]
    style A fill:#ffebee
    style C fill:#ffebee
    style E fill:#ffebee
    style G fill:#ffebee
    style B fill:#e8f5e9
    style D fill:#e8f5e9
    style F fill:#e8f5e9
    style H fill:#e8f5e9

매번 같은 패턴이었습니다. 새 계층이 생기면 아래 계층을 잊어도 됐고, 사람은 **“무엇을”**에 집중하고 **“어떻게”**는 기계에게 위임했습니다. 하지만 새 계층에는 항상 새로운 도전이 따라왔습니다.

우리 시대의 도전은 **“AI에게 어떤 작업 환경을 줄 것인가”**입니다.

🎯 2. 우리는 “Markdown 프로그래밍의 초기"에 있다

C 언어가 나온 후 구조적 프로그래밍이 성숙하는 데 10년이 걸렸습니다. 웹 프레임워크가 나온 후 현대적 모범 사례가 정립되는 데도 10년이 걸렸습니다. AI 에이전트 개발은 지금 바로 그 초기 단계입니다. 2020년 프롬프트, 2025년 컨텍스트, 2026년 하네스 — 다음은 무엇일까요?

이 시점에 하네스 엔지니어링을 체득한 팀과 그렇지 못한 팀의 격차는, 향후 몇 년 사이에 C를 빨리 익힌 팀과 어셈블리어만 쓰던 팀의 격차만큼 벌어질 수 있습니다.

🎯 3. 역할의 전환 — “코더"에서 “환경 설계자"로

flowchart LR
    A[예전 개발자:
코드를 작성하는 사람] --> B[미래 개발자:
AI 작업 환경을
설계하는 사람]
    style A fill:#ffecb3
    style B fill:#c8e6c9

OpenAI의 실험에서 엔지니어는 단 한 줄도 코딩하지 않았습니다. 대신 그들은:

• 규칙을 설계하고
• 문서 구조를 짜고
• 린터와 피드백 루프를 만들고
• 에이전트가 쓸 도구를 준비했습니다.

이것이 바로 추상화의 다음 단계입니다. 우리가 항상 해온 것 — 기계어에서 어셈블리어로, 어셈블리어에서 C로, C에서 프레임워크로 — 그리고 이제 프레임워크에서 Markdown으로, 코더에서 하네스 설계자로.

🎬 마무리

70년의 흐름을 한 문장으로

“우리는 항상 기계에게 더 쉽게 말하는 법을 찾아왔습니다. 0과 1로 말하다가, 영어 약어로 말하다가, 문법으로 말하다가, 이제는 그냥 한국어로 말합니다.

하지만 ‘쉬워졌다’고 해서 ‘간단해졌다’는 뜻은 아닙니다. 복잡성은 사라지지 않고, 그저 다른 곳으로 옮겨 갔을 뿐입니다.

예전엔 컴파일러가 우리 대신 복잡성을 감당했다면, 이제는 ‘하네스’가 그 일을 합니다.

그리고 오늘, 이 하네스를 잘 설계하는 것이 — 새로운 프로그래밍 능력입니다.”

📚 참조 및 출처

프로그래밍 언어 역사

• Wikipedia — History of programming languages → 어셈블리 1949년 EDSAC 사용, C 1972년 Dennis Ritchie 개발 확인
• IEEE Computer Society — A Timeline of Programming Languages → FORTRAN 1957, 고급언어 연대 확인

Prompt → Context Engineering 전환

• arXiv — A Brief History of Prompt: Leveraging Language Models (2023) → Prompt Engineering 연대기
• Gartner 보고서 인용 (2025.07) — “Context engineering is in, prompt engineering is out” → Atlan.com 등 여러 AI 업계 매체에서 인용

Harness Engineering 용어의 출발

• Mitchell Hashimoto — My AI Adoption Journey (2026.02.05) → “Engineer the Harness” 섹션 직접 인용
• OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World (2026.02.11) → 100만 줄 코드, 1,500 PR, 1/10 시간 수치 출처
• Anthropic — Effective Harnesses for Long-Running Agents (2025.11.26) → Initializer Agent + Coding Agent 구조
• Anthropic — Harness Design for Long-Running Application Development (2026.03.24) → GAN 영감 Generator-Evaluator 구조, DAW 실험

Markdown as Programming Language

• GitHub Blog — Spec-driven development: Using Markdown as a programming language (2025.10) → GitHub 공식 선언

참조 블로그

• teo.log — 우리는 프로그래머다 → 추상화의 역사와 개발자 역할 변화에 대한 시각 참조

이 글을 작성하며 참고한 자료들입니다.