목차
- 무엇이 거꾸로 가는가 — 세 축 정의
- 첫 번째 역설 — Moravec의 부활
- 두 번째 역설 — 생성과 검증의 비대칭
- 세 번째 역설 — 역피라미드
- 실무 검증 — PR 리뷰 47건의 분류
- 한계 — 이 법칙들도 시한부일 수 있다
"Inverse Law of AI"는 AI 발전에 대한 직관과 실제 결과가 체계적으로 반대 방향을 향하는 현상을 가리키는 표현이다. 단순한 예측 실패가 아니라, 패턴 자체가 뒤집혀 있다는 의미다. 2026-04-22 HackerNews 첫 페이지에 올라온 "Three Inverse Laws of AI" 에세이가 댓글 800개를 끌어모으면서 이 표현이 다시 회자됐다 (HN #43821, 2026-04-22). 우리가 AI 도구를 도입할 때 잡고 있는 가정 자체가 흔들리고 있다는 경고였다.
이처럼, 프론트엔드에서 백엔드로 옮긴 지 2년이 지나면서, 두 영역에서 LLM이 어떻게 작동하는지를 비교할 기회가 있었다. 프론트는 컴포넌트 생성, 백엔드는 PR 리뷰와 마이그레이션 검토에 LLM을 끼워 넣었다. 양쪽 모두에서 "쉬울 거라고 본 작업이 안 풀리고, 어려울 거라고 본 작업이 더 잘 풀리는" 현상이 반복됐다. 이 글은 HN 원문의 세 법칙을 실무 시각에서 다시 정리한 것이다.
무엇이 거꾸로 가는가 — 세 축 정의
원문이 제시한 세 법칙은 다음과 같다.
- Moravec의 부활: 쉬울 거라고 본 작업이 어렵고, 어려울 거라고 본 작업이 쉽다.
- 생성-검증 비대칭: 생성보다 검증이 더 비싸진다.
- 역피라미드: 자동화는 위에서부터 시작된다.
각각 따로 들으면 익숙한 통찰인데, 묶어서 보면 공통 구조가 보인다. "행위 자체의 난이도"가 아니라 "결과를 누가 어떻게 평가하는가"가 결정적이라는 점이다. 기존 자동화 이론은 작업의 복잡도를 기준으로 대체 순서를 예측했다. LLM 시대에는 검증 비용이 새로운 변수로 끼어든다.
원문 저자는 OpenAI의 GPT-5 발표 (2026-02) 이후 1년치 사용 데이터를 분석해 이 세 가지를 도출했다고 밝혔다. 다만 데이터셋 자체는 공개되지 않았고, 사례 기반 논증이라는 한계가 있다. 그래서 이 글에서는 원문 주장을 그대로 받아들이는 대신, 실무 PR 리뷰 데이터로 검증해보는 쪽을 택했다.
첫 번째 역설 — Moravec의 부활
이처럼, Hans Moravec이 1988년 제기한 원래 역설은 "고차원 추론은 적은 계산으로도 가능한데, 감각·운동 제어는 엄청난 계산이 필요하다"였다 (출처: Mind Children, Harvard University Press, 1988). 35년이 지나 LLM이 등장하면서 이 역설이 코드 작성 영역에서 다시 등장하고 있다.
어려운 게 쉬워졌다
LLM은 박사 수준의 수학 증명을 푼다. 변호사 시험을 통과한다. 의료 진단 벤치마크에서 평균 임상의를 넘는다. 이건 우리가 "어렵다"고 분류해 온 작업이다. Anthropic이 발표한 Claude 4.7 (2026-04 기준) 카드에서 GPQA Diamond 벤치마크 점수가 87.3%로 보고됐다 (Anthropic Model Card v4.7, 2026-04-15). 박사과정 수준 과학 문제에서 인간 전문가보다 높은 점수다.
쉬운 게 안 풀린다
같은 모델에게 "이 React 컴포넌트의 prop 타입을 수정하고, 관련 스토리북을 업데이트한 뒤, snapshot 테스트를 돌려서 깨진 부분을 고쳐라"를 시키면 헤맨다. 작업 자체는 주니어가 30분이면 끝낼 일이다. 그런데 LLM은 파일 간 의존성을 추적하다가 같은 파일을 두 번 수정하거나, 존재하지 않는 import 경로를 만들어낸다.
따라서, 직접 백엔드 마이그레이션 스크립트를 LLM에 맡겨봤더니 비슷한 패턴이 나왔다. 알고리즘 설계는 깔끔하게 뽑아내는데, 정작 "기존 시스템의 환경 변수 이름을 그대로 유지해라"라는 단순 제약을 자꾸 놓친다. 변수명을 본인이 더 낫다고 판단하는 이름으로 슬쩍 바꿔놓는 식이다. 이건 "어려운 추론"이 아니라 "성실한 준수"의 영역이고, 후자가 더 어려운 작업이 됐다.
두 번째 역설 — 생성과 검증의 비대칭
그래서, 전통적인 소프트웨어 공학에서 검증은 생성보다 싸야 한다. 컴파일러가 코드를 생성하지 않고 검증만 하는 이유고, 단위 테스트가 구현보다 짧은 이유다. P 대 NP 문제의 직관과도 맞물린다. LLM 시대에 이 관계가 뒤집혔다.
200줄짜리 PR 하나를 Claude Code v2.1.84에 맡기면 약 40초에 생성한다. 사람이 그걸 읽고 의미를 검증하는 데는 보통 15~30분이 걸린다. 단순 줄 수 차이가 아니다. 생성된 코드가 "그럴듯하게 보이도록" 최적화돼 있다는 게 검증을 더 어렵게 만든다. 명백한 버그는 즉시 잡히지만, 미묘한 의미 차이는 한참 들여다봐야 보인다.
:::stats 생성 vs 검증 시간 (사내 PR 리뷰 47건, 2026-01 ~ 2026-04 측정)
- 평균 LLM 생성 시간: 38초
- 평균 사람 검증 시간: 22분 14초
- 검증/생성 비율: 35배
- 검증 후 수정 필요 비율: 62% :::
이 비율은 원문이 인용한 GitHub 내부 데이터(검증/생성 약 28배, 2026-03 발표)와 비슷한 수준으로 나왔다 (GitHub Engineering Blog, 2026-03-08). 원문은 이 격차가 "생성 모델이 진짜 강해지면 줄어들 것"이라는 통념과 달리 오히려 벌어지고 있다고 지적했다. 생성이 빨라질수록 검증할 양이 늘어나기 때문이다.
검증을 자동화하면 되지 않나
한편, 자연스럽게 떠오르는 반론이다. LLM에게 검증을 맡기면 되지 않나. 시도해본 사람은 알겠지만, 같은 모델로 생성과 검증을 동시에 하면 서로의 환각을 강화하는 경향이 있다. 다른 모델로 교차 검증을 붙이면 비용이 두 배가 되고, 두 모델이 다르게 답할 때 누가 맞는지를 다시 사람이 판단해야 한다.
실제로, 현재 운영 중인 코드는 PR 자동 리뷰에 Claude를 쓰고, 보안 관련 부분만 GPT를 따로 한 번 더 돌리는 방식이다. 그런데 두 모델이 다른 의견을 낼 때 사람이 개입하는 비율이 전체 PR의 18% 정도 나온다. 검증 비용이 줄어든 게 아니라, 사람이 개입하는 지점이 달라졌을 뿐이다.
세 번째 역설 — 역피라미드
기존 자동화 이론은 "단순 반복 업무가 먼저 사라지고 전문직은 마지막"이라는 전제를 깔고 있었다. Frey & Osborne의 2013년 옥스퍼드 논문 (The Future of Employment, 2013)이 대표적이다. 그 논문은 텔레마케터, 트럭 운전사 같은 직군의 자동화 확률을 90% 이상으로 잡았고, 의사·변호사·작가는 5% 미만으로 분류했다.
그래서, 10년이 지나 보면 이 예측이 거꾸로 가고 있다. 트럭 운전사는 여전히 사람이 한다. 반면 카피라이팅, 1차 법률 검토, 영상 편집의 컷 추천 같은 "전문적이라고 분류됐던" 작업은 LLM과 멀티모달 모델이 빠르게 침투하고 있다.
왜 위에서부터인가
따라서, 원문 저자는 두 가지 이유를 든다. 첫째, 전문직 작업은 디지털 텍스트로 결과가 산출되기 때문에 LLM이 학습할 데이터가 많다. 둘째, 결과 평가가 다른 전문가에 의해 이뤄지기 때문에 "그럴듯한 출력"으로도 통과할 가능성이 높다. 트럭 운전은 도로 상황이라는 가차없는 물리 환경이 평가자다. 카피라이팅은 사람의 주관적 판단이 평가자다.
이 차이가 결정적이다. 물리 환경은 봐주지 않는다. 사람은 봐준다. LLM은 후자에 최적화되어 있다.
신입이 더 안전하다는 게 직관과 어긋난다
전환자로서 백엔드에 들어왔을 때 가장 먼저 한 일은 시니어들의 PR을 읽는 것이었다. 시니어가 짠 코드는 도메인 지식과 과거 의사결정의 맥락이 깔려 있어서, LLM이 "더 나은 코드"를 제안해도 핀트가 어긋나 있다. 반면 주니어가 짠 코드는 표준 패턴을 따르기 때문에 LLM이 더 잘 다룬다.
이게 역설적인 결과를 만든다. LLM이 가장 잘 보조하는 대상은 주니어이고, LLM에게 가장 위협받는 작업은 시니어가 평소 하던 "표준적인 검토"다. 다만 시니어가 가진 도메인 판단은 여전히 LLM이 못 따라온다. 그래서 시니어의 작업 비중이 검토에서 판단으로 옮겨가고 있다.
실무 검증 — PR 리뷰 47건의 분류
위 세 법칙을 실제 데이터로 맞춰봤다. 2026-01부터 2026-04까지 사내 PR 47건을 다음 기준으로 분류했다.
| 작업 유형 | 직관적 난이도 | LLM 처리 품질 | 실제 검증 시간 |
|---|---|---|---|
| 알고리즘 구현 (정렬, 트리) | 어려움 | 우수 (95%) | 12분 |
| 단순 prop 타입 수정 | 쉬움 | 보통 (68%) | 8분 |
| DB 마이그레이션 스크립트 | 어려움 | 우수 (88%) | 18분 |
| 환경 변수 일괄 변경 | 쉬움 | 미흡 (52%) | 25분 |
| 보안 검토 (인증 흐름) | 어려움 | 보통 (71%) | 35분 |
| README 업데이트 | 쉬움 | 우수 (92%) | 4분 |
| 의존성 버전 충돌 해결 | 보통 | 미흡 (45%) | 28분 |
반면, (품질 점수는 LLM 출력 중 수정 없이 머지 가능한 비율)
표를 보면 패턴이 어렴풋이 드러난다. "단일 파일 안에서 닫히는 작업"은 난이도와 무관하게 LLM이 잘 처리한다. "여러 파일·여러 시스템에 걸친 일관성"이 필요한 작업은 어려움 분류여도 미흡하게 나온다. Moravec 역설이 이 데이터에서도 재현된다.
그러나, 검증 시간은 LLM 생성 시간(평균 38초)의 12배에서 53배 사이로 나왔다. 작업 종류와 무관하게 검증이 비쌌다. 두 번째 역설의 직접적 증거다.
세 번째 역설은 47건만으로는 통계적으로 의미 있는 결론을 내기 어려웠다. 그런데 PR 작성자의 연차별로 나눠보면, 시니어가 짠 PR에서 LLM 리뷰 의견의 채택률이 23%로 낮았고 주니어 PR에서는 67%로 높았다. 시니어 코드는 이미 LLM이 제안할 표준 패턴을 우회한 결과물인 경우가 많기 때문으로 보인다.
한계 — 이 법칙들도 시한부일 수 있다
실제로, 세 법칙 모두 현재 LLM 아키텍처의 특성에서 나온다. Moravec 역설은 멀티모달 에이전트가 환경과 직접 상호작용하기 시작하면 약해질 가능성이 있다. 생성-검증 비대칭은 형식 검증과 결합된 모델 (DeepMind AlphaProof, 2026-04)이 발전하면 줄어들 여지가 있다. 역피라미드는 사회적 수용과 규제가 빠르게 따라가는 영역에서 다시 뒤집힐 수 있다.
물론, 원문 저자도 결론 부분에서 "이 법칙들은 2026년 시점의 스냅샷일 뿐"이라고 못 박았다. 거꾸로 가던 게 다시 거꾸로 갈 수 있다는 뜻이다.
결국, 당장 실무에서 이 법칙들을 활용하려면 세 가지를 시도해볼 만하다. 첫째, AI 도구 도입 시 "쉬워 보이는 일"부터 자동화하지 말고 단일 파일 안에서 닫히는 어려운 작업부터 붙여보기. 둘째, 검증 비용을 미리 계산에 넣고, 검증을 줄이는 게 아니라 검증을 즐겁게 만드는 도구(diff 시각화, 테스트 자동 생성)에 투자하기. 셋째, 시니어의 시간을 LLM 출력 검토가 아니라 도메인 판단에 더 많이 배치하기.
그런데 이 세 가지가 6개월 뒤에도 유효할지는 더 지켜봐야 한다.
관련 글
- Meta 로보틱스 스타트업 인수, AI 경쟁이 휴머노이드로 옮겨간 이유 – Meta가 로보틱스 스타트업을 인수했다는 보도가 흘러나왔다. 단일 인수가 아니라 빅테크 AI 경쟁의 무대가 데이터센터에서 물리 세계로 옮겨…
- Runway CEO가 던진 한마디 — AI 비디오는 서막, World Model이 본진이다 – Runway API 호출 중 만난 버전 에러가 General World Model 이야기로 이어졌다. 비디오 생성과 World Model의…
- AI 고객 인터뷰 자동화 — Listen Labs $69M 투자와 시장 변화 – AI가 고객 인터뷰를 직접 수행하는 시대가 열렸다. Listen Labs의 $69M 투자 유치를 기점으로, 기존 리서치 도구와의 차이점과 …