THE HATEFUL GAP: 왜 당신의 AI 경험은 다른 사람과 완전히 다른가

본 글은 10월 쯔음에 AI의 비결정적 행동으로 스트레스의 이유를 찾아 본문의 내용을 드래프트로 썼다가 12월말에 여러 거장들의 트위터 글을 보고 생각나서 다시 편집했다.

서론: 전문가들의 고백#

안드레이 카퍼시는 현대 AI 담론에서 가장 영향력 있는 목소리 중 하나다. 스탠퍼드에서 페이-페이 리 교수 밑에서 컴퓨터 비전을 연구했고, OpenAI 창립 멤버로 합류했다. 이후 테슬라로 이직해 AI 디렉터로서 오토파일럿 시스템을 이끌었다. 2025년 초에는 “바이브 코딩(Vibe Coding)“이라는 용어를 만들어 AI 주도 개발의 새로운 패러다임을 포착했다.¹

그런 그가 2025년 12월 X에 올린 글은 업계에 충격을 줬다.

“프로그래머로서 이만큼 뒤처졌다고 느낀 적이 한 번도 없었다. 이 직업은 극적으로 리팩터링되고 있으며, 프로그래머가 기여하는 비트들은 점점 더 성기게, 드문드문 배치되고 있다.”²

AI 분야의 선구자가 스스로 “뒤처졌다"고 고백한 것이다. 그는 에이전트, 서브에이전트, MCP, LSP, 워크플로우 등 새로운 추상화 레이어를 마스터해야 한다며, 이를 “사용 설명서 없이 나눠진 강력한 외계 도구"에 비유했다.

보리스 체르니는 Anthropic에서 클로드 코드(Claude Code)를 만든 엔지니어다. 클로드 코드는 터미널에서 직접 Claude를 사용해 코딩 작업을 위임할 수 있는 에이전틱 코딩 도구다. 카퍼시의 글에 답글로 그는 더 충격적인 사실을 공개했다.

“지난 한 달은 엔지니어로서 IDE를 전혀 열지 않은 첫 달이었습니다. Opus 4.5가 약 200개의 PR을 작성했고, 모든 줄이 그에 의해 쓰였습니다.”³

후속 게시물에서 그는 259개의 PR, 497개의 커밋, 4만 줄 추가, 3만 8천 줄 삭제라는 구체적 수치를 제시했다.⁴ 그가 관찰한 흥미로운 현상이 있다. 레거시 기억이 없는 신입들이 모델을 가장 효과적으로 활용한다는 것이다. 과거 모델의 한계에 대한 선입견이 없기 때문에, 현재 모델의 가능성을 더 열린 마음으로 탐색한다.

두 사람 모두 AI 분야 최전선에 있다. 그런데 “뒤처졌다"고 느낀다. 동시에 많은 개발자들은 “AI는 쓸모없다"고 말한다. 같은 도구인데 왜 경험이 이렇게 다른가?

---

I. 세 개의 세계#

AI를 사용하는 사람들은 대략 세 그룹으로 나뉜다.

그룹	시키는 문맥	AI 경험	대표적 반응
A	1-5	마법	“AI가 모든 걸 대체한다”
B	50-100	쓰레기	“AI는 쓸모없다”
C	5-15 (경계)	불안정	“되다 안되다 미치겠다”

첫 번째 그룹은 “AI가 모든 걸 대체한다"고 믿는다. 이들은 주로 단순한 작업을 시킨다. 이메일 초안, 간단한 함수, 정형화된 문서. AI가 마법처럼 느껴진다.

두 번째 그룹은 “AI는 쓸모없다"고 단언한다. 이들은 복잡한 시스템 전체를 AI에게 맡긴다. 결과물은 엉망이다.

세 번째 그룹은 “되다 안되다 미치겠다"고 좌절한다. 이들은 AI 능력의 경계에서 작업한다. 어떨 때는 놀라운 결과가 나오고, 어떨 때는 완전히 실패한다. 비일관성에 지친다.

세 그룹 모두 같은 AI를 쓰고 있다. 틀린 사람은 없다. 차이는 AI에게 시키는 작업의 문맥 복잡도에 있다.

---

II. 문맥 복잡도 모델#

2.1 스케일의 정의#

사람이 시키는 태스크의 실제 복잡도를 1에서 100까지의 스케일로 놓자. 현재 AI의 처리 능력은 대략 5에서 10 수준이다.⁵

여기서 중요한 구분이 있다. 프롬프트 길이와 문맥 복잡도는 다르다. 한 줄 명령이 100짜리 일일 수 있다. “윈도우즈 11 OS 만들어줘"는 짧은 프롬프트지만 문맥 복잡도는 수천에 달한다. 반대로 긴 프롬프트가 문맥 5짜리 단순 작업을 설명할 수도 있다.

문맥 복잡도를 높이는 것은 텍스트의 양이 아니라 의존성의 깊이다. 코드베이스 전체에 흩어진 암묵적 규칙, 숨겨진 비즈니스 로직, 외부 API와의 미묘한 상호작용—이런 ‘보이지 않는 맥락’이 많을수록 복잡도는 치솟는다.

2.2 트리 구조로 보는 AI의 한계#

100짜리 태스크 A를 시켰다고 가정하자. 이 태스크는 트리 구조로 분해될 수 있다.

                    A (100짜리 태스크)
             B              C
         D      E       F      G
       H I J  K L M   N O P  Q R S
      .........(실제 작업 90%)..........

AI는 상위 4~5단계(A에서 G)까지만 실제로 수행한다. 나머지 90%(H 이하)는 할루시네이션으로 채운다. “그럴싸하게” 만든다. AI는 “다 했어요!“라고 답한다. 열어보면 엉망이다.

하지만 H 레벨 태스크만 시키면? 완벽하게 해낸다.

이것이 경험 차이의 근본 원인이다. 문맥 5짜리를 시키는 사람은 AI의 처리 능력 안에서 작업한다. 문맥 100짜리를 시키는 사람은 AI의 능력을 한참 벗어난 요청을 한다. 문맥 10-15를 시키는 사람은 경계에서 불안정한 결과를 경험한다.

2.3 해상도와 압축 메타포#

AI는 본질적으로 손실 압축 시스템이다. 현실 데이터를 압축(학습)하고, 압축 해제(추론)할 때 손실이 발생한다. 손실난 부분을 노이즈나 상상력으로 채운다. 이것이 할루시네이션이다.

JPEG 압축 해제나 이미지 업스케일링과 같은 원리다. 원본에 없는 디테일을 “그럴듯하게” 생성한다. 인간의 기억 회상도 정확히 같은 메커니즘으로 작동한다는 연구들이 있다.⁶ 우리는 과거를 정확히 재생하는 게 아니라 재구성한다. 빈 부분은 “그럴 것 같은” 내용으로 채운다.

---

III. 결정론의 종말#

전통 소프트웨어 스택의 기본 전제는 결정론이었다. 같은 입력은 같은 출력을 보장했다. 버그는 재현 가능했고, 재현 가능하면 수정 가능했다.

AI 시스템은 다르다. 확률적이고, 같은 프롬프트에 다른 결과가 나온다. 왜 실패했는지 정확히 알기 어렵다. 내부 작동을 설명할 수 없다.

이 특성은 엔지니어링의 기본 전제를 바꾼다.

• 완전한 이해 → 충분한 예측
• 완벽한 통제 → 실패 모드 관리
• 디버깅 → 확률적 신뢰 관리

이것은 단순한 도구 변화가 아니다. 물이 100도에서 증기가 되듯, 프로그래밍이라는 직업 자체가 위상 전이를 겪고 있다. 같은 이름이지만 완전히 다른 상태로 변하고 있다.

---

IV. 세 가지 역설#

4.1 레거시 프롬프트 역설#

능력 10짜리 모델에 최적화한 프롬프트가 있다. 세심하게 조율했고, 잘 작동한다. 능력 20짜리 새 모델이 나왔다. 같은 프롬프트를 쓴다.

결과: 성능이 오히려 떨어진다.

이유는 간단하다. CTO에게 신입 개발자 다루듯 명령하는 격이다. “이 변수의 타입을 명시적으로 선언하고, null 체크를 반드시 하고, 예외 처리를 이렇게 해라”—능력이 낮은 모델에게 필요했던 상세 지시가, 능력 높은 모델에게는 오히려 제약이 된다.

오늘의 최적화가 내일의 성능 저하 원인이 된다.

4.2 경험이 부채가 되는 순간#

20년 경력 개발자는 “이건 AI가 못 해"라고 단정한다. 과거 모델로 시도해봤고, 실패했다. 시도조차 안 한다.

신입 개발자는 그냥 시켜본다. 되면 좋고, 안 되면 다시 시킨다. 과거의 실패 기억이 없다.

보리스 체르니의 관찰이다:

“레거시 기억이 없는 신입이 모델을 가장 효과적으로 활용한다. 옛 모델을 쓰며 형성된 온갖 가정이 없기 때문이다.”⁷

과거 경험이 현재 가능성을 막는다. 로켓 착륙이 “불가능하다"고 했던 업계 베테랑들과 같다. SpaceX는 그 “불가능"을 무시하고 수십 개의 프로토타입을 폭발시키며 학습했다. 이 접근법이 AI 시대에도 필요하다.

4.3 하네스의 딜레마#

해결책으로 에이전트, 워크플로우, 하네스를 정교하게 구축한다. 비결정적 답변에 대한 최적화는 고된 작업이다. 어디까지 잘 되는지 테스트하고, 프롬프트를 조율하고, 실패 케이스를 처리한다.

문제는 다음 모델이 나오면 이 모든 노력이 쓰레기통으로 간다는 것이다.

새 모델의 능력이 다르다. 이전 모델의 약점을 보완하려 만든 우회로(이른바 ‘프롬프트 해킹’)가 새 모델에서는 오히려 방해가 된다. 최적화할수록 폐기 비용이 커진다.

물론 변하지 않는 가치도 있다. 좋은 문서화, 깔끔한 인터페이스 정의, 명확한 RAG 파이프라인 같은 **‘양질의 맥락’**을 공급하는 구조는 유효하다. 하지만 모델의 결함을 때우기 위한 임시방편적 하네스는 부채가 된다. 영구적인 것을 만들려는 본능이 발목을 잡는다.

---

V. 에이전트 군단: 해결책과 새로운 문제#

5.1 계층적 위임의 등장#

앞서 언급한 ‘그룹 B(지옥의 경험)‘가 겪는 좌절은, 본질적으로 혼자서 이 거대한 트리 전체를 감당하려 했기 때문이다.

문제 인식은 명확하다. 단일 모델은 상위 레벨만 제대로 하고 하단은 할루시네이션이다. 해결책: 할루시네이션이 발생하는 하단부를 부하 모델에게 외주 준다.

트리 구조로 작업을 분배한다.

        인간
          ↓
      루트 에이전트 (Opus)
       ↙     ↘
   에이전트A   에이전트B (Sonnet)
    ↙   ↘      ↙   ↘
  a1  a2    b1   b2 (Haiku)

각 레벨이 자기 처리 능력 범위 내의 작업만 담당한다. 루트는 전체 설계, 중간은 모듈 구현, 잎사귀는 세부 함수. 이론적으로 완벽해 보인다.

5.2 정렬 드리프트 문제#

새로운 문제가 발생한다. 인간은 꼭대기 모델하고만 대화한다. 인간이 머릿속에 가진 전체 문맥이 루트 에이전트에게 100% 전달되지 않는다. 루트가 중간에게, 중간이 잎사귀에게 전달할 때마다 조금씩 벡터 방향이 틀어진다.

잎사귀에 도달하면 원래 의도에서 상당히 먼 곳에 있다.

구체적 예시:

인간 의도: "소셜 로그인 구현해줘" (OAuth 기대)
    ↓
루트 해석: "인증 시스템을 설계해야겠군"
    ↓
중간 해석: "JWT 토큰 기반으로 구현하라는 거네"
    ↓
잎사귀 실행: 토큰 만료 처리 로직 열심히 작성
    ↓
결과: OAuth는 없고 자체 JWT 시스템만 있음

전언 게임과 같다. CEO 지시가 말단에 도달하면 왜곡되는 것과 같다. 각 레이어가 자기 해석을 추가하고, 최종 실행은 원래 의도와 괴리된다.

5.3 미해결 과제#

어떻게 정렬을 끝까지 유지할 것인가?

• 잎사귀 에이전트에게 원본 컨텍스트를 직접 전달해야 하나?
• 중간 레이어의 해석을 검증하는 메커니즘이 필요하다
• 각 레벨에서 “내가 이해한 게 맞나요?” 확인 단계?

이 문제를 해결해야 에이전트 스케일링이 실용화된다. 현재로서는 열린 문제다.

---

VI. 새로운 추상화 레이어#

기존 프로그래밍 스택 위에 새로운 레이어가 쌓였다. 카퍼시가 나열한 목록이다:⁸

• 에이전트, 서브에이전트
• 프롬프트, 컨텍스트, 메모리
• 모드, 권한, 도구, 플러그인
• 스킬, 훅, MCP, LSP
• 슬래시 커맨드, 워크플로우, IDE 통합

이 레이어는 전통적 추상화와 질적으로 다르다. TCP/IP 위에 HTTP를 올리는 것과, 확률적 언어 모델 위에 에이전트 시스템을 구축하는 것은 같은 종류의 작업이 아니다. 전자는 결정론적이다. 후자는 확률적이고, 설명 불가능하고, 버전마다 행동이 달라진다.

마스터해야 한다. 하지만 마스터한 순간 다음 버전이 나온다. 고정된 지식 축적이 아니라, 탐색 프로세스 자체를 내재화해야 한다.

---

VII. 새로운 역할의 부상#

7.1 타이핑에서 지휘로#

사라진 것: 대부분의 직접 코드 입력.

남은 것: 설계, 검증, 조율.

10줄 쓰던 자리에 1줄 쓴다. 하지만 그 1줄이 수백 줄의 방향을 결정한다. 지휘자가 악기를 직접 연주하지 않지만 오케스트라 전체를 컨트롤하는 것과 같다. 개입은 “성기게” 배치되지만, 레버리지는 커졌다.

보리스 체르니가 한 달간 IDE를 열지 않았다는 건 코딩을 안 했다는 뜻이 아니다. 무엇을 만들지 결정하고, 만들어진 것을 검증하고, 방향을 조정하는 일은 계속했다. 코드를 직접 입력하는 작업이 빠졌을 뿐, 엔지니어링의 핵심적인 인지 작업은 그대로 남아 있었다.

7.2 검증 능력의 가치 폭등#

AI가 생성한 코드에는 특유의 실패 패턴이 있다.

• 겉보기에 작동하지만 에지 케이스에서 무너진다
• 표면적으로 요구사항을 충족하지만 암묵적 가정에 의존한다
• 구문 오류는 없지만 설계 의도에서 벗어난다
• Happy path는 완벽하지만 에러 처리가 허술하다

이런 문제를 잡아내려면 코드를 작성하는 능력과는 다른 종류의 전문성이 필요하다. 코드를 읽고 의도와 비교하는 능력. 빠진 부분을 인식하는 능력. AI가 볼 수 없는 더 넓은 맥락을 파악하는 능력.

코드 리터러시가 코드 라이팅보다 중요해졌다. 읽고 판단하는 능력이 핵심이다.

---

VIII. 처방: 어떻게 적응할 것인가#

8.1 프로토타입 마인드셋#

프롬프트와 워크플로우를 영구적인 것처럼 만들지 마라. 다음 모델에 버릴 각오로 가볍게 만들어라. 폐기 비용을 최소화하는 방향으로 설계하라.

SpaceX 방식이다. 스타십 프로토타입을 수십 개 폭발시켰다. 각각을 “완벽하게” 만들려고 하지 않았다. 빠르게 만들고, 테스트하고, 폭발하면 배우고, 다음 버전을 만든다. AI 워크플로우도 같아야 한다.

8.2 캘리브레이션 루틴#

새 모델이 나올 때마다 능력 경계를 테스트하라.

1. 표준 테스트 세트를 준비하라 (문맥 5, 10, 20, 50짜리 태스크)
2. 각각 시켜보고 어디서 깨지는지 확인하라
3. 그것이 그 모델의 처리 능력 경계다
4. 그 경계를 기준으로 작업을 분할하라

모델이 바뀔 때마다 이 과정을 반복한다. 능력 경계가 어디인지 알아야 효과적으로 활용할 수 있다.

8.3 적응적 분할#

처음부터 잘게 쪼개지 마라. 답답하다.

1. 일단 크게 시켜봐라 (문맥 20-30)
2. 깨지면 어디서 깨졌는지 확인하라
3. 그 부분만 더 잘게 쪼개서 다시 시켜라
4. 반복

하향식 분할이다. 필요한 만큼만 분해한다. 처음부터 모든 걸 잘게 나누면 오버헤드가 크고, 전체 맥락을 잃기 쉽다.

8.4 메타 스킬#

특정 도구 사용법을 암기하지 마라. 도구가 계속 변한다.

대신 탐색 프로세스 자체를 내재화하라:

• “지금 이 모델이 무엇을 할 수 있는가"를 반복적으로 테스트하는 습관
• 변화를 읽는 감각
• 도구가 변해도 적용 가능한 원칙

지식보다 감각이다. 고정된 답보다 질문하는 방법이다.

8.5 오늘 당장 할 수 있는 것#

지금 쓰는 모델에게 문맥 10, 20, 30짜리 태스크를 각각 시켜봐라. 어디서 깨지는지 확인하라. 그게 당신의 시작점이다.

---

결론: 위상 전이#

프로그래밍이라는 직업이 위상 전이를 겪고 있다. 물이 100도에서 증기가 되듯, 같은 이름이지만 완전히 다른 상태다. 과거의 “프로그래머"와 지금의 “프로그래머"는 하는 일의 본질이 다르다.

무언가를 만드는 장벽은 분명히 낮아졌다. AI에게 지시하면 코드가 나온다. 하지만 전문가 수준의 결과물을 만드는 장벽은 오히려 높아졌다. AI의 출력을 평가하고, 문제를 진단하고, 수정 방향을 제시하고, 최종 품질을 보장하려면 깊은 이해가 필요하다.

도구가 강력해질수록 도구를 제대로 쓰는 사람과 그렇지 못한 사람 사이의 격차가 벌어진다. “제대로 엮어 쓰면 10배 강력해질 수 있다"는 카퍼시의 감각은 정확하다.⁹ 하지만 그 부스트는 자동으로 주어지지 않는다.

새로운 추상화 레이어를 이해하고, 레거시 가정을 초기화하고, 검증과 조율의 역량을 키워야 한다. 직접 쓰지 않는 코드에 대한 책임을 지는 법을 배워야 한다. 그게 지금 시점에서 프로그래머에게 요구되는 것이다.

---

에필로그: 같은 지진 위에서#

카퍼시의 고백이 울림을 갖는 이유는 그가 AI의 최전선에 있기 때문이다. 그런 사람도 “뒤처졌다"고 느낀다면, 우리가 느끼는 불안은 정상이다.

하지만 “뒤처졌다"는 감각을 좌절의 신호로 읽을 필요는 없다. 그것은 변화의 속도에 대한 정직한 인정이다. 카퍼시 자신이 말했듯, 진도 9의 지진이 이 직업을 뒤흔들고 있다.¹⁰

중요한 것은 뒤처짐을 인정하고, 탐색을 멈추지 않는 것이다. 완벽한 이해를 추구하기보다 충분한 예측을 목표로 삼는 것이다. 영구적 지식 대신 적응적 감각을 기르는 것이다.

필요한 건 견고하게 버티는 능력이 아니라, 흔들림과 함께 움직이는 능력이다.

우리 모두 같은 지진 위에 서 있다.

---