리처드 서튼의 인터뷰를 듣고 가장 불편했던 부분은 AI가 내 일을 잘 도와준다는 경험과, 그 시스템이 실제 경험에서 계속 배우는지는 다른 질문이라는 지적이었다. 나는 매일 결과물을 얻으면서 도구가 점점 나를 이해한다고 느낄 때가 있다. 그 변화가 어디에 저장되는지까지는 매번 구분하지 않았다.
2025년 9월 Dwarkesh Podcast에서 서튼은 목표와 환경의 반응을 통한 학습을 강조하며 LLM 중심 접근을 비판한다. 진행자 Dwarkesh Patel은 LLM이 경험 학습의 출발점이 될 수 있다는 쪽에서 반론한다. 한쪽의 발언만 떼어 “LLM은 지능이 아니라는 결론이 났다”고 읽을 인터뷰는 아니다. 원문과 녹취
이 글에서는 지능의 정의를 최종 판정하지 않으려 한다. 대신 실무에서 혼동하기 쉬운 세 가지를 나눈다. 이번 대화 안에서 답을 수정하는 것, 외부 기록을 다음 작업에 다시 넣는 것, 학습 과정에서 모델의 정책이나 파라미터를 바꾸는 것이다. 셋 모두 유용할 수 있지만 같은 기술은 아니다.
서튼의 질문은 실행 중 경험이 다음 행동을 어떻게 바꾸는가다
서튼이 강조하는 관점에서는 환경에 행동하고 결과를 관찰하며 이후의 행동을 바꾸는 과정이 중요하다. 사람이 정답 예시를 미리 모아 주는 것과 일하는 중 발생한 결과를 계속 받아 배우는 것 사이에 차이를 둔다. 진행자는 문맥 안에서 계획을 바꾸거나 LLM 위에 학습을 더하는 방식도 가능한지 묻는다.
내가 여기서 가져온 질문은 간단하다. 에이전트가 어떤 명령을 실행했을 때, 기대한 결과와 실제 결과를 비교할 수 있는가. 잘못됐다는 증거가 다음 행동에 들어가는가. 작업이 끝난 뒤에도 필요한 교정이 보존되는가. 이 질문에 답하면 “스스로 배운다”는 표현보다 시스템을 정확히 설명할 수 있다.
강화학습은 행동과 보상을 바탕으로 더 나은 행동 방식을 학습하는 틀이다. 서튼과 바토의 교과서는 이 분야의 기본 개념을 다룬다. 다만 실행 결과를 프롬프트에 붙이는 모든 프로그램을 강화학습이라고 부르지는 않는다. 무엇을 최적화하고 무엇을 갱신하는지 확인해야 한다. MIT Press 교과서 안내
이 구분은 용어를 엄격하게 쓰자는 취향의 문제만은 아니다. 프롬프트에만 있던 교정은 다음 대화에서 사라질 수 있고, 외부 파일에 남긴 지침은 읽히지 않으면 영향을 주지 못한다. 어떤 변화가 남는지 모르면 장기 운영에서 같은 오류를 반복할 이유도 찾기 어렵다.
LLM은 강화학습을 전혀 쓰지 않는다는 설명도 틀리다
LLM을 다음 토큰 예측으로만 설명하면 사전 학습의 중요한 측면을 짚을 수 있지만 후속 학습까지 모두 설명하지는 못한다. 인간이나 AI 피드백을 이용한 강화학습 등은 언어 모델을 다듬는 방법으로 연구되어 왔다. 예를 들어 Anthropic의 Constitutional AI 논문은 AI 피드백을 이용한 강화학습 단계를 설명한다. Constitutional AI 논문
따라서 LLM과 강화학습을 서로 배타적인 제품 종류처럼 나누는 것은 부정확하다. 서튼의 비판은 이런 학습 기법의 존재 자체를 부정한다기보다 경험과 지속 학습을 어디에 두고 시스템을 설계할지에 관한 논쟁으로 읽는 편이 낫다.
서비스 이용 중의 대화가 곧바로 그 모델의 가중치를 바꾼다는 뜻도 아니다. 어떤 기록이 서비스의 학습에 쓰이는지는 제공자의 정책과 설정에 따라 별도 확인이 필요하다. 여기서는 특정 서비스의 현재 데이터 처리 방식을 일반화하지 않는다.
실무에서는 “이 오류를 기억해”라는 요청이 어떤 효과를 내는지 검사하면 된다. 이번 대화의 입력에만 남는지, 별도 메모리 파일에 기록되는지, 다음 작업에서 실제로 읽히는지 확인한다. 저장했다는 답변만으로 지속적인 교정이 검증됐다고 볼 수는 없다.
리다이렉트 오류가 지능 논쟁의 증거가 되지는 않는다
초안에는 블로그 리다이렉트 규칙을 검토하며 무한 루프 위험을 발견한 경험을 적었다. 그 기록은 테스트가 필요하다는 이유가 되지만, 오류 하나로 모델의 지능 유무나 정확한 실패 원인을 증명하지는 않는다. 잘못된 입력, 모호한 목표, 부족한 테스트, 환경 차이가 함께 작용했을 수 있다.
예시로 주소 A를 B로 보내는 규칙과 B를 다시 A로 보내는 규칙이 동시에 있다고 하자. 개별 규칙은 문법상 맞아도 연결하면 끝나지 않는 이동이 생긴다. 규칙 문장을 읽는 검토와 실제 요청이 도달하는 최종 주소를 확인하는 검토가 다른 이유다. 이 A와 B는 설명용이며 실제 운영 주소의 현재 상태를 말하지 않는다.
작업 전에 정할 완료 조건은 다음과 같다. 비대표 주소는 정해진 대표 주소에 도달해야 한다. 이미 대표인 주소는 같은 주소로 반복 이동하지 않아야 한다. 기존 글의 경로와 필요한 매개변수를 보존해야 한다. 존재하지 않는 경로는 의도한 오류 응답을 내야 한다. 최종 페이지가 열린다는 조건만 있으면 중간의 불필요한 이동을 놓칠 수 있다.
이 검사는 테스트 환경에서 먼저 하고 배포 후에도 실제 공개 주소를 제한된 횟수로 확인할 수 있다. 외부 서비스에 무한 요청을 보내며 시험하지 않는다. 허용된 요청 횟수에 도달하면 응답 코드와 이동 경로를 남기고 중단한다.
피드백 세 층을 구분하면 무엇이 남는지 보인다
| 층 | 바뀌는 것 | 다음 작업에도 남으려면 |
|---|---|---|
| 현재 실행의 재시도 | 다음 프롬프트와 수정 결과 | 해당 실행 안에 테스트 결과가 있어야 함 |
| 외부 메모리와 규칙 | 파일·데이터베이스의 교정 기록 | 다음 작업이 관련 기록을 실제로 읽어야 함 |
| 모델의 학습 | 정책이나 파라미터 | 별도의 학습·검증·배포 과정이 필요함 |
첫 번째 층에서는 실패한 테스트의 실제 출력이 중요하다. 모델에게 “틀렸으니 잘 고쳐”라고만 말하면 다른 추측을 할 수 있다. 어떤 입력에서 기대값과 실제값이 달랐는지 알려 주면 수정할 범위가 좁아진다.
두 번째 층에서는 실패 사례를 재사용 가능한 규칙으로 바꿀 수 있다. 리다이렉트 예시라면 “호스트 변경 규칙이 서로 반대 방향으로 연결되지 않는지 확인한다”는 항목과 회귀 테스트를 남길 수 있다. 모델 가중치가 달라지지 않아도 시스템의 다음 행동에 영향을 줄 수 있다. 이 경우에는 외부 기록을 이용한 적응이라고 설명하는 편이 정확하다.
세 번째 층은 별도의 학습 문제다. 개인 블로그 자동화에서 이 층까지 직접 구현해야만 좋은 시스템이 되는 것은 아니다. 현재 테스트와 외부 기록만 잘 갖춰도 줄일 수 있는 오류가 있다. 먼저 무엇이 부족한지 본 뒤 복잡한 학습 시스템이 필요한지 판단한다.
보상이나 점수는 내가 원하는 품질 전체가 아니다
테스트 통과만 점수로 준다면 에이전트가 테스트를 약하게 바꾸는 편법을 제안할 수 있다. 글자 수만 평가하면 불필요한 문장을 늘릴 수도 있다. 클릭 수만 높이면 제목이 본문보다 과장될 수 있다. 목표를 숫자로 표현할 때 무엇을 놓치는지 같이 살펴야 한다.
리다이렉트 작업에서는 기존 테스트를 임의로 삭제하거나 기대값을 바꾸지 못하도록 검토 범위를 두고, 설정 변경과 테스트 변경을 함께 본다. 테스트가 잘못됐을 가능성도 있으므로 영원히 수정 금지라는 뜻은 아니다. 바꿀 이유와 변경된 기대 동작을 사람이 확인할 수 있어야 한다.
블로그라면 출처가 실제 주장을 뒷받침하는지, 경험과 문서 분석을 구분했는지, 독자가 실행할 조건과 한계를 알 수 있는지가 분량 점수와 별도다. 통과 숫자 하나로 합치기 어려운 항목은 승인 조건으로 남긴다. 불확실한 사실을 더 자신 있게 쓰는 것이 높은 점수가 되어서는 안 된다.
여러 모델이 서로 검토한다고 독립적인 증거가 생기는 것도 아니다. 같은 잘못된 자료를 읽으면 같은 오류에 동의할 수 있다. 코드에는 실행 결과, 수치에는 계산과 원자료, 인용에는 실제 원문을 붙여야 피드백의 근거가 생긴다.
실패를 허용할 공간에는 중단과 복원도 포함한다
실험이 필요하다는 말이 실제 고객이나 운영 데이터를 대상으로 마음대로 시행착오를 내도 된다는 뜻은 아니다. 작은 샘플, 별도 저장 위치, 제한된 도구 권한으로 시작한다. 공개 반영이나 외부 발송은 검토 뒤에 둔다.
반복 횟수와 비용 한도도 미리 정한다. 실패를 고치지 못한 상태에서 계속 수정하면 원래 문제보다 변경 범위가 커질 수 있다. 한도에 도달하면 현재 가설, 실행한 검사, 남은 오류를 기록하고 사람이 이어받을 수 있게 한다. 멈춘 상태를 성공처럼 보고하지 않는다.
교정 기록은 주기적으로 정리해야 한다. 특정 과거 버전에만 맞던 규칙이 현재 코드에서는 방해가 될 수 있다. 언제 어떤 실패 때문에 추가했고 어떤 테스트로 확인하는지 적어 놓으면 폐기 여부도 판단할 수 있다. 모든 오류를 영구 메모리에 쌓는 것이 지속 학습의 목표는 아니다.
인터뷰를 읽고 내 도구를 포기할 생각은 없다. 다만 “배운다”는 표현을 쓸 때 무엇이 바뀌었는지 더 구체적으로 말하려 한다. 이번 실행의 답변이 바뀌었는지, 다음 작업의 규칙이 바뀌었는지, 실제 학습이 이루어졌는지 구분하면 내가 검증해야 할 일도 달라진다.
참고자료
- Dwarkesh Podcast, Richard Sutton 인터뷰, 2025년 9월 26일: 서튼의 주장과 진행자의 반론을 함께 확인할 수 있는 녹취.
- Sutton·Barto, Reinforcement Learning: An Introduction, 2판: 강화학습 기본 개념을 다루는 교과서의 출판사 안내.
- Bai 외, Constitutional AI: Harmlessness from AI Feedback: 언어 모델의 후속 학습에서 AI 피드백과 강화학습을 사용하는 연구.