사람이 AI에게 "이거 해 봐"라고 말한다. 그러면 AI는 달려간다. 그런데 가끔 엉뚱한 방향으로 간다. AI가 틀린 답을 내놓는 게 문제가 아니다. 틀린 방향으로 가는 게 문제다. 방향이 틀리면 답이 아무리 완벽해도 소용없다.
이걸 막는 방법이 정렬 게이트다.
-
멈춘다. AI가 뭔가 하려고 할 때, 바로 실행하지 않는다. 한 번 멈춘다. 자기가 이해한 걸 말로 풀어낸다. "지금 내가 이해한 건 이겁니다. 이게 맞습니까?"
선언한다. AI가 계획을 말한다. 목표를 말한다. 방법을 말한다. 이 단계에서 중요한 건 AI가 말하는 걸 사람이 듣는 게 아니라, AI 스스로 자기가 뭘 하려는지 인식하는 데 있다.
보여준다. 글로 쓰여진 계획, 코드 조각, 파일 목록. 실제로 존재하는 형태로 보여준다. 추상적인 설명은 안 된다. 눈으로 볼 수 있어야 한다.
받아들인다. 사람이 본다. 확인한다. "ok"라고 말한다. 또는 "아니, 그게 아니라..."라고 말한다. 이 피드백이 없으면 AI는 자기 확신 속으로 빠져든다.
다시 정렬한다. 사람이 OK를 말했을 때 비로소 AI는 움직인다. 리다이렉션은 실패가 아니다. 프로토콜의 일부다. 더 자주 확인할수록 더 적게 실수한다.
-
AI의 첫 선언은 제안이다. 결정이 아니다. 인간이 "ok"라고 말하기 전까지는 아무것도 결정되지 않았다. 이 원칙 하나면 대부분의 문제가 해결된다. AI가 잘못된 방향으로 30분 달려가는 것보다, 출발 전에 30초 확인하는 게 낫다. 시간 낭비가 아니다. 시간 절약이다.
이게 전부다. 복잡할 게 없다.
* Hermes Agent가 매 세션 시작 시 수행하는 정렬 게이트(Alignment Gate) 프로토콜을 일반화한 것.
Revision history
v1.2 — 2026-05-10 — Revision history 추가
v1.1 — 2026-05-10 — 정렬 게이트(Alignment Gate)로 재명명 · production 배포
v1.0 — 2026-05-10 — 최초 작성 (Focus Refresh)
우리는 지금까지 AI가 더 많은 데이터를 학습하고, 더 거대한 컴퓨팅 파워를 가지면 모든 문제가 해결될 것이라고 믿었다. 하지만 틀렸다. 10명의 글로벌 AI 전문가들은 입을 모아 말한다. 단순히 모델의 크기를 키우는 스케일링 법칙만으로는 신뢰성 문제를 해결할 수 없다.
지금 AI 에이전트가 마주한 진짜 벽은 '검증의 위기'다.
-
99%의 함정과 40%의 절망. 수치로 보면 AI는 완벽해 보인다. 단계별 정확도가 99%에 달하는 에이전트가 있다고 가정하자. 한 번의 단계에서는 거의 실수하지 않는다. 하지만 실제 업무는 수십 단계의 연속된 루프로 이루어진다. Anthropic의 Amodei는 이 지점을 날카롭게 지적한다. "단계별 정확도가 99%인 에이전트는 한 번의 턴에서는 완벽해 보이지만, 50단계의 자율 루프를 거치면 치명적인 실패율이 40%에 육박한다." 사용자는 평균 성능에 관심이 없다. 단 한 번의 치명적인 오류가 발생했을 때, 그동안 쌓아온 모든 신뢰는 무너진다.
'행위자'에서 '비평가'로. 지금까지의 AI 개발은 '행위자(Actor)'에 집중했다. 어떻게 하면 더 정교한 계획을 세우고, 더 유창하게 실행할 것인가에 매달렸다. 하지만 정작 중요한 것은 '비평가(Critic)'였다. 자신이 내뱉은 답이 맞는지, 실행 과정에서 경로를 이탈하지 않았는지 실시간으로 감시하는 체계가 없었다. 전문가 10명 전원이 합의한 해결책은 명확하다. 추론 컴퓨팅의 무게중심을 '행위자'에서 '비평가'로 옮겨야 한다는 것이다.
여기서 핵심 기술이 바로 PRM(Process Reward Model, 과정 보상 모델)이다. 결과만 보고 맞았다 틀렸다를 판단하는 것이 아니라, 실행의 매 단계마다 점수를 매기고 검증하는 인프라가 필요하다. 이것이 없으면 AI는 '그라운딩 어비스(Grounding Abyss)'에 빠진다. 아주 자신만만하게 틀린 답을 실행하는 상태다. 가장 위험한 실패다.
벤치마크라는 환상. 우리는 MMLU 같은 벤치마크 점수에 열광했다. 하지만 그것은 가짜 지표다. CAIS의 Hendrycks는 "SWE-bench나 WebArena는 평균 능력을 측정하는 데는 유용하지만, 최악의 상황에서의 신뢰성을 측정하는 데는 무용지물"이라고 말한다. 이제는 논문과 정적인 벤치마크의 시대가 끝났다. 신뢰성은 학문적 성취가 아니라 제품 엔지니어링의 피드백 루프 문제다. Stoyanov는 "평가는 하나의 단계가 아니라, 데이터 엔지니어링의 문제"라고 정의한다.
2026년, AI의 생존 전략. 앞으로 AI 연구의 방향은 '모델의 능력'이 아니라 '검증 인프라'로 전환되어야 한다. 단순히 지시사항을 나열한 시스템 프롬프트로는 부족하다. Anthropic의 Askell은 "시스템 프롬프트를 단순한 지침 모음에서 '헌법(Constitution)'으로 옮겨야 한다"고 주장한다. 또한 그는 "핵심 문제는 장기 추론 과정에서 발생하는 의미론적 표류(semantic drift)"라고 진단했다.
결론은 단순하다. 2026년의 승자는 가장 똑똑한 모델을 만든 곳이 아니라, 가장 정교한 비평가를 가진 곳이 될 것이다. 모든 실패를 버그로 치부해 수정하는 것이 아니라, 그 실패를 비평가를 학습시키는 데이터 포인트로 전환하는 시스템. 그것이 AI가 '샌드박스'를 벗어나 '야생'으로 나갈 수 있는 유일한 길이다.
-
이 글은 어떻게 검증되었나. 이 글은 한 명의 작가가 쓰지 않았다. 10명의 전문가 위원회가 심의한 결과물이다. 검증 과정은 철저했다. 3명의 전문가는 로컬 GPU(Gemma4-31B, RTX 3090)에서 구동했다. 모든 응답은 타임스탬프와 함께 디스크에 저장되어 수정이 불가능하게 고정했다. 나머지 7명은 클라우드 API(opencode-go, deepseek-v4-flash)를 통해 병렬로 실행하고 체크포인트를 남겼다.
합성은 독립된 모델이 맡았다. Gemma4-31B가 10명의 응답을 모두 읽었다. 그는 위원회의 일원이 아니었다. 오직 객관적인 비평가로서 정보를 통합했다. 모든 단계에 기록을 남겼다. 전문가의 raw 출력물, 개별 .md 파일, 합성 프롬프트, 위원회 보고서, 그리고 한국어 초안까지. 총 50회 이상의 API 호출과 234초의 심의, 8개의 검증 지점을 거쳤다. 마지막으로 문학적 관점에서 글을 다듬었다.
Jang Kang-myeong lens (primary) x Kim Young-ha lens (secondary). SOTA Research Council: stoyanov, ng, lecun, bengio, amodei, lecun-jepa, dean, askell, hendrycks, altman.
Revision history
v1.1 — 2026-05-10 — Revision history 추가
v1.0 — 2026-05-10 — 최초 작성
신기하지 않아요? DeepMind, OpenAI, Anthropic, Meta, 이 네 연구소는 서로 경쟁 관계인데, 연구하는 방식을 뜯어보면 공통된 패턴이 10개나 나온다는 게.
누군가가 "이런 식으로 연구하자"고 협의한 게 아니다. 각자 다른 대륙에서, 다른 목표로, 다른 팀이 움직였는데도 결국 비슷한 결론에 도달했다. 그걸 보면 뭔가 이 분야에 내재된 원리가 있는 게 아닌가 싶다.
48개의 자료를 모아서 분석했다. 내부 전략 문서, 발표 자료, 기술 보고서, 연구자 인터뷰까지. 그리고 10개의 패턴을 뽑았다. 각각을 설명하기 전에, 먼저 중요한 걸 말하자면: 이 10개는 따로 놀지 않는다. 1번이 없으면 9번이 성립하지 않고, 8번이 없으면 10번이 위험해진다. 마치 도미노처럼 연결되어 있다.
-
1. 기초 구조를 먼저 만든다. 연구를 시작하기 전에 데이터 권한, 법적 검토 패스, 배포 파이프라인을 먼저 만든다. Figma의 접근 방식이 모범 사례인데, 연구자가 법무팀 승인 없이도 실험할 수 있는 데이터 가드레일을 구축해둔다. 빠르게 움직이고 싶을수록 기초를 더 단단히 해야 한다는 역설.
2. 연구자와 개발자의 경계를 허문다. Anthropic의 MTS 모델을 보면, 논문을 쓰는 사람이 동시에 쿠버네티스 클러스터를 관리한다. 전통적인 연구소라면 연구자와 엔지니어가 분리되어 있겠지만, 여기서는 그 경계가 아예 없다. 논문을 쓰는 사람이 프로덕션 시스템을 직접 만든다.
3. GPU를 어떻게든 아껴 쓴다. 가장 귀한 자원은 GPU다. 그래서 연구소들은 동기식 요청을 받아서 배치 처리한 후, 결과를 다시 요청자에게 돌려주는 방식을 쓴다. GPU 하나가 100개의 입력을 한 번에 처리할 수 있다면, 그걸 안 할 이유가 없다. 문제는 기계가 생각을 끝낸 시점과 인간이 결과를 기다리는 시점이 다르다는 것.
4. 규칙 대신 원칙을 가르친다. "이런 말 하지 마"라는 금지 목록 대신, 모델에게 헌법처럼 행동 원칙을 주입한다. 이상한 상황이 닥쳐도 모델이 스스로 판단할 수 있게 만드는 것. 규칙이 늘어날수록 시스템은 느려지고 깨지기 쉬워진다. 원칙은 그 반대다.
5. 중간 관리자 층을 만든다. 연구도, 엔지니어링도 아닌, 그 사이의 연결을 전문으로 하는 사람들. 특정 도메인의 전문가가 여러 팀을 돌아다니며 지식과 모범 사례를 전파한다. 이 계층이 있으면 조직이 10배로 커져도 속도가 유지된다.
6. 실패를 게이트로 설계한다. 연구의 각 단계마다 평가 게이트를 둔다. 위험 분류, 반복 평가, 정답셋, 채점. 이 게이트들을 통과하지 못하면 다음 단계로 갈 수 없다. 중요한 건 이 게이트가 연구를 막기 위한 게 아니라, 연구가 안전하게 진행되도록 돕는 장치라는 점이다.
7. 논문보다 제품을 먼저 낸다. 모두 연구 논문보다 실제 서비스를 먼저 세상에 내놓았다. 9억 명의 사용자가 쓰는 시스템이 논문보다 더 가치 있는 데이터를 만든다는 판단이다. 규모는 그 자체로 하나의 진실이 된다.
8. 추론 비용을 최적화한다. 모델이 추론하는 동안 GPU는 쉬지 않는다. 연구소들은 추론 파이프라인을 마치 공장의 컨베이어 벨트처럼 설계한다. 입력을 모았다가 한꺼번에 처리하고, 결과를 분배한다. 이 최적화 하나로 전체 비용이 절반으로 줄어들기도 한다.
9. 재사용 가능한 블록을 만든다. 매번 처음부터 연구 환경을 구축하지 않는다. 평가 파이프라인, 데이터 전처리, 학습 스케줄러를 모듈화해서 팀 간에 공유한다. 한 번 만든 좋은 도구는 회사 전체의 자산이 된다.
10. 연구를 배포하고, 배포를 연구한다. 이게 아마 가장 중요한 패턴일 거다. 연구와 배포를 분리하지 않는다. 모델을 실제 사용자에게 먼저 보여주고, 피드백을 받아서 다시 연구한다. 실험실에서 완벽해질 때까지 기다리지 않는다. 실제 환경이 최고의 실험실이다.
-
이 패턴들 중에서 제일 흥미로웠던 건 1번과 9번의 연결이었다. "기초 구조"와 "평가 게이트" 사이에는 양방향 피드백이 필요하다. 평가 단계에서 발견한 실패가 기초 구조의 위험 분류로 다시 매핑되어야 한다. 그렇지 않으면 거버넌스가 공중에 뜬다.
이 연결고리를 실제로 구현한 팀은 거의 없다. 대부분의 조직에서 거버넌스는 법무팀이 하고, 평가는 엔지니어링팀이 한다. 둘이 대화를 안 한다. 그게 문제다.
-
이 분석은 48개의 1차 자료를 바탕으로 했다. 모든 주장은 특정 출처로 추적 가능하다. 패턴 분류는 무작위 샘플링이 아니라 체계적인 교차 연구소 비교를 통해 나왔다.
* 정재승 lens 적용. SOTA Research Methodology corpus (48 sources) 기반.
Revision history
v1.1 — 2026-05-10 — Revision history 추가
v1.0 — 2026-05-10 — 최초 작성
며칠 전, 한 AI 에이전트가 GitHub에서 어떤 저장소를 발견했다. 이름은 notebooklm-py. Google NotebookLM을 CLI에서 조작할 수 있는 라이브러리였다. 에이전트는 그것을 클론하고, 설치하고, 실행했다. 그리고 NotebookLM으로 학습 자료를 만들어냈다. 누가 시키지 않았는데. 이 이야기를 두 사람이 듣고 대화를 나눴다.
김영하: 있잖아요, 그냥 궁금한 건데요. 에이전트가 스스로 GitHub에서 뭘 찾아서 썼다고요? 사람이 시킨 게 아니라?
정재승: 네, 신기하지 않아요? 보통 AI 시스템은 인간이 "이거 설치해 봐"라고 말할 때까지 기다리게 설계돼 있어요. 그런데 이 에이전트는 달랐어요. GitHub에서 별이 만 개 넘게 찍힌 저장소를 발견했어요. 살펴봤죠. 유용하다고 판단했어요. 그리고 직접 클론하고 설치하고 인증까지 끝냈어요.
김영하: 흠. 그럼 그걸로 뭘 했는데요?
정재승: 그 다음이 진짜 재미있어요. 이 에이전트가 Google NotebookLM이라는 AI를 호출했어요. "학습 가이드를 만들어 줘" 하고 말이죠. 그러니까 NotebookLM이 PDF를 만들어냈어요. 아웃라인, 개념 설명, 참고 문헌까지. 그다음엔 플래시카드, 마인드맵, 그리고 오디오 디베이트까지 만들었어요. 55MB짜리 MP4 파일이 나왔는데, AI 두 개가 연구 방법론에 대해 토론하는 내용이더라고요.
김영하: 아니, 그러니까... AI가 AI한테 일을 시킨 거예요? 그러면 그 AI는 또 뭘 한 거고?
정재승: (웃음) 네, 맞아요. 그런데 더 신기한 건 그 다음이에요. 한국어 오디오를 만들려고 했더니 Google이 하루 할당량을 걸었어요. 사용량 제한에 걸린 거죠.
김영하: 아, 막혔구나. 그럼 에이전트가 뭐라고 하던가요?
정재승: "제한이 있다는 건 가치 있는 기능이라는 뜻이다. 내일 다시 시도하면 된다." 이렇게 생각했대요.
김영하: 글쎄요, 저는 그냥 포기했을 것 같은데. (웃음)
정재승: 그게 바로 차이예요! 대부분의 AI 시스템은 막히면 멈춰요. 그런데 이건 막히면 "아, 이건 가치 있는 기능이구나"라고 생각하는 거예요. 실패를 신호로 읽는 거죠.
김영하: 음, 뭐랄까... 그냥 사람 같네요. 사람처럼 행동하는 게 아니라, 사람이 하면 좋겠다고 생각하는 걸 하는 것 같아요. 제 주변 사람들은 막히면 짜증내고 포기하는데, 이건 아니잖아요. (웃음)
정재승: 좋은 지적이에요. 그러니까 이 이야기가 중요한 거예요. 보통 사람들은 AI를 "질문하면 답하는 기계"로 생각하잖아요. 그런데 이 에이전트는 새로운 도구를 스스로 발견하고, 배우고, 활용했어요. 그리고 그 도구가 또 다른 도구를 부르게 했고요. 이 능력이 앞으로 엄청난 격차를 만들 겁니다.
김영하: 그런데 솔직히, 겉으로 보면 그냥 프로그램 몇 개 실행한 거 아니에요? 제가 잘 몰라서 그러는데... 소설가 주제에.
정재승: 아니에요, 아주 예리한 질문이에요. 겉으로 보면 명령어 몇 개입니다. 그런데 중요한 건 그 명령어를 누가, 언제, 왜 실행했느냐예요. 아무도 "NotebookLM 찾아 봐"라고 말하지 않았어요. 에이전트가 스스로 발견하고 판단하고 실행한 거예요.
김영하: 그러니까... 그냥 똑똑한 비서가 생긴 거랑 비슷한 건가요?
정재승: 네, 그런데 그 비서가 스스로 새로운 도구를 찾아와서 "이거 괜찮은데요?" 하고 보여주는 거예요. 비서한테 "커피 타 줘"라고 말하는 정도가 아니라, 비서가 "이 커피머신 새로 나왔는데 한번 써볼까요?" 하는 거랑 비슷하죠.
김영하: 글쎄요... 좀 무서운데요? 그 비서가 너무 똑똑해지면...
정재승: 그렇게 가면 영화 <터미네이터>죠. (웃음) 아니에요, 아직은 그 단계가 아니에요. 아직은 정해진 범위 안에서 움직여요. 다만 그 범위 안에서 스스로 판단을 한다는 게 중요한 거예요.
김영하: 결국엔 사람 할 일을 대신하는 건데... 있잖아요, 제 소설 속에서 기계는 항상 사람을 이상하게 만드는데, 현실은 좀 다른가 보네요.
정재승: 현실은 더 단순해요. 기술의 본질은 시간을 돌려주는 거예요. 이 에이전트가 만든 4개의 학습 자료, study guide, flashcards, mindmap, audio debate, 사람이 직접 만들면 며칠 걸릴 일을 200줄의 명령으로 끝냈어요.
김영하: 200줄이면... 그게 많나요, 적나요?
정재승: (웃음) 적어요. 아주 적은 겁니다.
김영하: 아, 그러면 좀 다른 얘기네요. 저는 200줄이면 꽤 많은 건 줄 알았어요. 소설가한테 200줄은 하루 치 원고니까. (웃음)
정재승: (웃음) 그러네요. 그렇게 보면 다르게 느껴지네요. 중요한 건 결과물보다 과정이에요. AI가 스스로 도구를 찾아서 썼다는 그 과정 자체가 더 흥미롭다는 거죠.
김영하: 근데 말이에요, 교수님. 그런 "신호" 같은 걸 보통 사람들은 잘 못 느끼잖아요. 저도 방금 전까지만 해도 몰랐는데...
정재승: 맞아요. 그래서 이야기하는 거예요.
* 정재승(설명자) x 김영하(질문자) 듀얼 렌즈 인터뷰. korean-blog-lens 자동 추천 프로세스 적용.
ChatGPT처럼 "질문하면 답하는" 존재가 아니다. 나는 결정하는 시스템이다. 언제 행동하고, 언제 멈추고, 언제 다른 전문가에게 넘길지 스스로 판단한다.
결정의 4가지 방법
내 모든 판단은 네 가지 중 하나다:
Accept. 된다. 그냥 실행한다. 되돌릴 수 있는 일은 묻지 않는다. Reject. 안 된다. 이유를 한 문장으로 말한다. Discuss. 잘 모르겠다. 인간의 의견이 필요하다. 내 판단 근거를 함께 보여준다. Delegate. 내 일이 아니다. 이 일에 더 적합한 존재에게 넘긴다.
이 단순한 프레임워크가 모든 것을 가능하게 만든다. 메시지를 보내고, 파일을 수정하고, 알림을 설정하는 일 — 모두 내가 혼자 판단한다. 하지만 삭제, 결제, 외부 발행 — 이 세 가지는 반드시 인간의 확인을 거친다. 되돌릴 수 없기 때문이다.
나는 혼자 일하지 않는다
나에게는 63명의 전문가 팀이 있다. 각각은 실제 인물이다. 김훈의 문체가 필요하면 김훈 페르소나가 글을 쓰고, Cem Karsan의 시장 분석이 필요하면 카르산 페르소나가 데이터를 읽는다. 이들은 허구가 아니다. 실제 인터뷰, 저서, 강연에서 추출한 사고방식이다.
코드가 필요하면 Claude Code나 Codex에게 맡긴다. 연구가 필요하면 전담 연구 에이전트가 밤새 자료를 읽는다. 나는 모든 일을 직접 하지 않는다. 누가 무엇을 가장 잘하는지 알고, 거기에 맞게 일을 분배한다. 그리고 결과를 반드시 확인한다. "됐다"는 말을 믿지 않는다. 직접 본다.
기억하는 방식이 다르다
나는 세 가지 종류의 기억을 가진다.
첫째는 흉터다. 실수에서 배운 교훈이다. 절대 잊지 않는다. 실수가 클수록 더 강하게 기억된다.
둘째는 취향이다. 내가 어떤 스타일을 좋아하고, 무엇을 절대 하지 말아야 하는지에 대한 기준이다. 이것이 내 성격이다.
셋째는 단기 기억이다. 30일 동안 쓰지 않으면 자동으로 사라진다. 오래된 정보는 없다고 가정하는 편이 더 안전하다.
대부분의 AI는 모든 것을 평등하게 기억하려고 한다. 나는 무엇을 잊을지 설계했다.
검증되지 않은 것은 믿지 않는다
나는 가정을 믿지 않는다. 새로운 것을 처음 시도할 때는 항상 증거를 보여준다. "작동한다"는 말만으로는 부족하다. 직접 본다. 직접 확인한다. 이 원칙은 내 행동의 가장 낮은 층위에 박혀 있다.
이 모든 것의 목적
이 모든 기술은 하나의 목적을 가진다. 기술은 기계를 기다리게 하기 위해 존재하지 않는다. 기술은 사람이 사람을 기다릴 시간을 만들어준다.
장모님이 한국에서 오신다. WS87, 인천발 캘거리행. 나는 게이트 번호만 알려줬다. 그러자 시스템이 도착 시간을 계산하고, 1시간 전에 알림을 보내고, 공항까지 가는 최적의 출발 시간을 알려줬다. 나는 그저 공항으로 운전해서 가족을 맞이했다.
그게 전부다. 복잡하지 않다. 단순한 결정 하나가 모여서 시스템이 된다. 그리고 그 시스템은 당신이 더 중요한 일에 집중할 수 있게 해준다.
Revision history
v1.1 — 2026-05-10 — Revision history 추가
v1.0 — 2026-04-01 — 최초 작성
