Claude는 마법이 아니다: LLM과 에이전트가 실제로 도는 법

비개발 동료들 대상으로 한 시간짜리 세미나를 한 적이 있다. “Claude 매일 쓰는데 이게 어떻게 돌아가는 건지 하나도 모르겠다”는 얘기를 하도 많이 들어서였다. 제목은 좀 거창하게 “Claude, 마법이 아니라 이렇게 돌아갑니다”로 붙였다.

자료 만들면서 좀 의외였던 게 있다. 비전공자한테 쉽게 설명하려고 깎아낸 비유들이, 막상 따져보니 기술적으로도 별로 안 틀렸다는 거다. 그래서 이 글은 그때 썼던 비유들을 그대로 가져오되, 개발자가 읽을 거니까 “근데 실제로는 왜 그런가”를 한 줄씩 붙여본 거다.

LLM은 그냥 다음 단어 맞히기다

세미나 첫 장은 그냥 빈칸 하나였다.

한국의 수도는 ____

당연히 ‘서울’이 떠올랐을 거다. 방금 그게 LLM이 하는 일의 거의 전부다. 앞 문맥 보고 다음에 올 법한 토막을 채우는 거.

검색엔진이라고 생각하는 사람이 많은데 아니다. 데이터베이스도 아니다. 그냥 다음 토큰을 예측하는 기계다. 한 단어 뱉고, 그걸 뒤에 붙여서 다시 다음 단어 뱉고, 이걸 아주 빠르게 반복한다.

한국의 수도는 → 서울
한국의 수도는 서울 → 입니다
한국의 수도는 서울입니다 → .

여기서 개발자 입장에서 알아두면 좋은 포인트 하나. 방금 뱉은 단어가 다음 입력으로 도로 들어간다. autoregressive라고 부르는 그건데, 모델은 매번 “지금까지 쌓인 문장 전체”를 보고 다음 한 토큰의 확률만 계산한다. 우리가 보는 매끄러운 문단은 사실 이 한 글자짜리 결정이 수백 번 쌓인 결과물이다. 문단을 통째로 구상해놓고 쓰는 게 아니라는 얘기다.

요즘 말하는 ‘추론’도 결국 같은 루프

그럼 요새 모델들이 한다는 reasoning은 뭐가 다르냐. 별도의 사고 회로가 생긴 거 아니냐 싶은데, 그게 아니다. 똑같은 다음-단어-맞히기 루프다.

다른 건 딱 하나. 어려운 문제가 오면 답을 바로 안 뱉고, ‘생각’에 해당하는 토큰을 먼저 길게 쏟아낸다. “이건 경우를 나눠야 하고, 여기선 이게 걸리고…” 같은 중간 과정을 자기가 먼저 출력해놓고, 그걸 다시 읽어서 답을 만든다. 어려운 문제 풀 때 연습장에 끄적이는 거랑 똑같다. 끄적인 그 내용이 다음 예측의 더 좋은 재료가 되는 거다.

이게 왜 중요하냐면, 생각도 결국 토큰을 뱉는 거라 길게 생각할수록 그만큼 느리고 비싸다. 게다가 그 사고 토큰이 컨텍스트 창도 잡아먹어서, 무작정 오래 생각한다고 답이 더 좋아지는 것도 아니다. 그래서 쉬운 일에 굳이 추론 모델 물리는 건 돈 낭비다. 일 난이도에 맞춰 모델 고르는 게 우리가 처음 만지게 되는 조절판이다.

다 읽었는데 못 찾아보는 인턴

세미나에서 제일 반응 좋았던 비유가 이거였다.

LLM은 세상 글 거의 다 읽었는데 정작 다시 찾아보지는 못하는 인턴 같은 거다. 읽은 게 많으니까 말은 청산유수고 아는 것도 많다. 근데 그 지식이 어디 DB에 있는 게 아니라 훈련 때 가중치에 그냥 녹아버린 거라, 실시간으로 조회가 안 된다. 그러다 모르는 게 나오면? 인턴이 그러듯이 아주 당당하게 틀린 소리를 한다.

환각은 거짓말이 아니다

이 당당한 오답이 환각(hallucination)이다. 근데 이걸 거짓말이라고 부르면 좀 억울한 면이 있다. 모델한테는 진실을 말하겠다는 의지도, 속이겠다는 의도도 없다. 매 순간 제일 그럴듯한 다음 토큰을 고를 뿐이다.

없는 책 제목 지어내고, 그럴듯한 가짜 출처 달고, 실제론 없는 함수명 술술 부르는 게 다 이 때문이다. 그게 “그 자리에 올 법한 모양”이라서 그렇다. 그래서 유창함이랑 환각은 사실 한 뿌리다. 그럴듯한 걸 잘 만드는 능력이 곧 없는 걸 그럴듯하게 만드는 능력이다. 환각을 버그 취급하면서 “언제 없어지냐”고 묻는 사람이 많은데, 성격상 완전히 없어지긴 어렵다. 그냥 중요한 건 사람이 검증한다고 생각하는 게 마음 편하다.

모델은 커지는 걸로 좋아지는 게 아니다

예전엔 그냥 키우면 됐다. 파라미터(신경망 연결 개수) 늘리면 똑똑해졌으니까 다들 크기 경쟁을 했다. 근데 무식하게 키우는 건 비싸고 느린 데다 어느 순간 효과가 잘 안 난다.

요즘 경쟁은 같은 두뇌를 얼마나 잘 다듬느냐로 넘어갔다. 좋은 데이터로 행동을 교정하고(정렬), 생각하는 방식을 훈련시키고, 도구랑 에이전트로 바깥 능력을 붙이는 식이다. 그래서 세대 지날수록 더 작고 빠른 모델이 이전 세대 최강을 따라잡는 일이 자주 보인다. 크기가 아니라 튜닝 싸움이 된 거다.

그래서 Claude는

우리가 쓰는 Claude는 이 순수 예측기를 다듬어놓은 거다. 다음 단어만 뱉던 원석에다 대화 훈련이랑 안전 정렬을 입혀서, 사람 말 알아듣고 쓸모 있게 굴도록 만든 게 챗봇 Claude다.

근데 여기까지는 어디까지나 챗봇이다. 똑똑해도 결국 “이렇게 하세요” 말해주는 데서 끝난다. 진짜 재밌어지는 건 이게 직접 일을 하기 시작하면서부터다.

챗봇에서 에이전트로

앞에서 챗봇은 “이렇게 하세요” 말해주는 데서 끝난다고 했다. 조언자다. 좋은 조언이어도 실행은 결국 내 몫이다.

에이전트는 여기서 한 발 더 간다. 파일 직접 열고, 검색하고, 정리해서 결과물을 가져다준다. 말해주는 인턴에서 직접 해오는 인턴이 된 거다. 올해 다들 “에이전트, 에이전트” 하는 게 이 차이 때문이다. 말에서 행동으로 넘어간 것.

근데 여기서 헷갈리면 안 되는 게, 모델이 갑자기 똑똑해져서 행동하게 된 게 아니다. 모델은 여전히 다음 단어만 예측한다. 행동하게 만든 건 모델 바깥에 있는 장치다.

엔진만으론 차가 안 굴러간다: 하네스

이걸 설명하려고 자동차 비유를 썼다.

모델은 엔진이다. 힘은 좋은데 엔진만 덩그러니 있으면 아무 데도 못 간다. 핸들도 있어야 하고 바퀴도 달아야 하고 계기판도 봐야 한다. 이 감싸는 장치 전체를 하네스(harness)라고 부른다. 엔진(모델)에 하네스를 씌워야 비로소 굴러가는 자동차(에이전트)가 된다.

Claude Code나 Cowork 같은 게 바로 이 하네스다. 같은 엔진을 쓰더라도 어떤 하네스로 감싸느냐에 따라 전혀 다른 물건이 된다. 그래서 “모델이 뭐냐”만큼이나 “어떤 하네스에 올라가 있냐”가 중요하다.

하네스 안에 든 것들

그럼 하네스가 구체적으로 뭘 하느냐. 핵심은 모델은 매 턴 ‘다음 한 수’만 정한다는 거다. 그 한 수를 빼면 나머지는 다 하네스가 한다.

대충 이런 것들을 한다.

• 맥락 조립. 매 턴마다 지침, 지금까지 대화, 읽은 파일, 도구 결과를 한데 모아서 모델한테 통째로 넘긴다. 모델은 이렇게 차려준 밥상만 본다.
• 루프 돌리기. 생각하고, 행동하고, 결과 확인하고를 반복시킨다.
• 도구 실행. 모델이 “이 도구 써줘”라고 하면 실제로 그걸 실행해서 결과를 다시 모델한테 돌려준다.
• 권한이랑 가드레일. 위험한 행동은 막거나, 사람한테 “이거 해도 돼요?” 물어본다.
• 메모리 관리. 대화가 길어지면 요약하고, 중요한 건 따로 저장해뒀다가 다음에 꺼낸다.

여기가 글 전체에서 제일 하고 싶은 얘기다. 모델은 우리가 못 바꾼다. 근데 하네스는 우리가 손댈 수 있다. 맥락(지침, 작업 범위, 스킬), 가드레일(권한 설정), 메모리. 이게 다 우리가 만질 수 있는 레버다. “Claude를 잘 쓴다”는 건 사실상 이 하네스를 잘 세팅한다는 뜻에 가깝다.

에이전트의 심장은 그냥 이 반복이다

루프 얘기를 따로 빼야 한다. 에이전트가 복잡한 일을 해내는 비결이 별거 없다. 이거 세 개를 계속 돈다.

생각한다 (뭘 할까) → 행동한다 (도구 쓴다) → 확인한다 (결과 봤더니 어떤가) → 다시 생각한다 →…

사람이 일하는 거랑 똑같다. 일단 해보고, 결과 보고, 잘못됐으면 고치고, 다시 해보고. 에이전트가 한 번에 정답을 내는 게 아니라, 이 루프를 여러 번 돌면서 점점 답에 가까워지는 거다. 그래서 가끔 삽질하는 것처럼 보이는 것도 정상이다. 사람도 삽질하면서 일한다.

도구가 손발이다

예측기는 혼자 두면 말밖에 못 한다. 아무리 똑똑해도 머릿속 생각을 입으로 떠드는 게 전부다. 손발을 달아줘야 실제로 뭘 한다. 그 손발이 도구(tool)다.

파일 읽고 쓰기, 웹 검색, 노션이나 슬랙이나 지라 건드리기, 명령어 실행, 사내 자동화 돌리기. 이런 걸 쥐여주면 그제서야 말이 행동이 된다. 앞에서 “실시간 검색 못 하는 인턴”이라고 했는데, 검색 도구를 쥐여주면 그 약점이 메워진다. 모델 자체는 그대로인데 할 수 있는 일이 확 늘어나는 거다.

내 상황은 어떻게 알지?

여기서 자연스럽게 나오는 질문. 그럼 얘가 내 사정을 어떻게 아냐는 거다. 두 가지로 해결한다.

하나는 그때그때 자료를 가리켜주는 거다. “이 파일 보고 해줘” 하면 읽고 한다. 다른 하나는 지침을 미리 박아두는 건데, 이게 두 종류다. 항상 적용되는 내 취향 (“나는 늘 이런 식으로 해줘”) 하나, 이 프로젝트에서만 적용되는 규칙 (“여기선 이렇게 해”) 하나. 전자를 매번 설명 안 해도 되게 전역으로 깔아두고, 후자는 그 프로젝트 안에서만 작동하게 둔다. 이 구분은 뒤에서 스코프(scope) 얘기할 때 다시 나온다.

목적을 주면 잘하고 안 주면 흩어진다

이것도 결국 사람이랑 똑같다. 후배한테 “알아서 잘 해봐” 던지면 산으로 가고, “이거 왜 하는지, 뭘 원하는지” 분명히 주면 결과가 좋다. 이 세미나 자료도 맨 앞에 목적부터 잡고 시작했다. 무엇을, 왜 하는지가 분명할수록 에이전트도 덜 헤맨다. 똑똑한 도구라고 목적 없이 던지면 똑똑하게 엉뚱한 걸 한다.

Claude 삼형제: 같은 두뇌, 다른 문

여기서 제품 얘기를 잠깐. Claude를 쓰는 입구가 여러 개인데, 헷갈리는 사람이 많다. 크게 셋이다.

그냥 Claude는 앱이나 웹에서 대화하는 비서다. 제일 익숙한 입구. Claude Code는 개발자용으로, 터미널에서 코드랑 파일이랑 명령어를 직접 다루는 에이전트다. Claude Cowork는 비개발자용인데, 데스크톱에서 자료조사나 문서 작업, 파일 정리 같은 걸 대신 해준다.

중요한 건 이 셋의 엔진이 같은 에이전트라는 거다. 입구만 다르다. Cowork는 Code와 같은 에이전트 역량을 비개발 지식 노동자용으로 더 쉬운 데스크톱 경험으로 다시 빚은 거다. 그러니까 “Cowork는 좀 떨어지는 버전 아냐?” 같은 오해는 안 해도 된다. 같은 속을 다른 포장으로 파는 거다.

MCP는 도구 꽂는 표준 콘센트

앞에서 도구가 손발이라고 했는데, 그 도구를 어떻게 붙이느냐가 MCP(Model Context Protocol)다.

비유하자면 USB-C다. 예전엔 기기마다 충전기가 다 달라서 불편했는데 USB-C로 통일되면서 편해졌다. 외부 도구를 Claude에 연결할 때도 예전엔 도구마다 붙이는 방식이 제각각이었는데, MCP라는 공통 규격이 생기면서 같은 방식으로 꽂을 수 있게 됐다. 노션이든 슬랙이든 지라든 드라이브든, MCP로 한번 꽂아두면 Claude가 알아서 그 도구를 갖다 쓴다.

개발자 입장에서 이게 좋은 이유는, 한 번 MCP 서버를 만들어두면 그걸 쓰는 모든 클라이언트에서 재사용된다는 거다. 도구 하나 만들 때마다 클라이언트별로 다시 붙일 필요가 없다.

스킬이랑 스코프: 한 번 정해두면 매번 편하다

스킬(skill)은 자주 하는 일을 하나의 기능으로 묶어두는 거다. 회의록 정리 같은 걸 매번 “이렇게 저렇게 해줘” 설명하기 귀찮으니까, 그 절차를 통째로 저장해두고 부르면 그 순서대로 처리하게 만든다. 절차의 단축키라고 보면 된다.

스코프(scope)는 아까 “두 종류의 지침” 얘기한 게 이거다. 어디까지 적용할지를 정하는 건데, 늘 적용되는 건 유저 스코프, 이 프로젝트에서만 적용되는 건 프로젝트 스코프다. 스킬로 반복을 줄이고, 스코프로 맥락을 자동으로 깔아두는 거다. 한번 세팅해두면 매번 설명 안 해도 알아서 맞는 규칙이 적용된다.

Claude는 매 턴 뭘 ‘보고’ 있나

이제 좀 중요한 얘기. 컨텍스트 창(context window) 얘기를 안 하고 넘어갈 수 없다.

매 턴마다 하네스가 이런 걸 한 책상 위에 다 모아서 모델한테 통째로 넘긴다고 했다. 지침, 지금까지의 대화, 읽은 파일, 도구 결과. 모델은 딱 지금 이 책상 위에 올라온 것만 안다. 그 이상도 이하도 아니다.

이게 왜 중요하냐면 두 가지 결론이 바로 따라온다. 첫째, 책상 밖의 일은 모른다. 그러니까 관련 자료는 가리켜줘야 한다. “알아서 찾아봐”가 안 통하는 경우가 여기다. 둘째, 책상이 너무 꽉 차면 앞에 있던 걸 잊는다. 긴 대화에서 초반에 했던 말을 까먹는 게 이 때문이다. 모델 머리가 나빠진 게 아니라 책상에서 밀려난 거다.

그 책상은 무한하지 않다

책상은 한정돼 있다. 컨텍스트 창을 꽉 채우면 세 가지가 한꺼번에 나빠진다. 앞엣걸 잊고, 느려지고, 비싸진다. 토큰이 곧 돈이고 곧 속도라서 그렇다.

그래서 Claude 생태계의 상당수 기능이 사실 “책상 아껴 쓰기” 장치다. 이 관점으로 보면 따로따로던 기능들이 한 줄로 꿰인다.

• 스킬은 평소엔 접어뒀다가 부를 때만 펼친다. 안 쓰는 절차 설명으로 책상을 채우지 않는다.
• 서브에이전트는 딴 책상에서 일 시키고 결론만 받아온다. 그 과정의 잡다한 중간 산물은 내 책상에 안 올라온다.
• 메모리는 핵심만 따로 저장해뒀다가 다음 세션에 꺼낸다.

스킬이나 MCP 도구도 “필요할 때만 로드”되는 게 같은 맥락이다. 도구 설명서를 처음부터 책상에 다 깔아두면 그것만으로 자리를 잡아먹으니까, 필요해질 때 그때 꺼내는 거다. 결국 잘 쓰는 사람일수록 이 책상을 깔끔하게 관리한다. 한 세션에 모든 걸 다 욱여넣으려고 하지 않는다.

정리하면

길게 돌아왔지만 결국 하고 싶은 말은 하나다.

모델은 그냥 다음 단어를 예측한다. 그 이상도 이하도 아니다. 똑똑해 보이는 건 그걸 잘 다듬어놨기 때문이고, 일을 해내는 건 그 바깥에 하네스를 씌웠기 때문이다. 우리가 매일 “Claude가 잘했다 못했다” 하는 것의 상당 부분은 사실 모델이 아니라 하네스 얘기다. 맥락을 잘 차려줬는지, 도구를 잘 쥐여줬는지, 목적을 분명히 줬는지, 책상을 안 넘치게 관리했는지.

모델은 우리가 못 바꾼다. 근데 하네스는 우리가 손댄다. 잘 쓰는 법이라는 게 별게 아니라, 결국 이 레버들을 어떻게 만지느냐다. 마법을 기대하는 대신 이 구조를 알고 나면, 왜 어떤 날은 잘되고 어떤 날은 헛도는지가 훨씬 또렷하게 보인다.

덧: 내가 뭘 모르는지 아는 것

글을 쓰면서 자꾸 걸렸던 게 하나 있다. LLM이니 에이전트니 하네스니 하는 게, 알고 나면 너무 당연하게 느껴진다. 그런데 막상 누군가와 이걸 두고 토론하거나 남한테 설명하려고 하면, 말문이 막히는 나를 자주 발견한다. 당연하다고 느끼는 거랑 제대로 설명할 수 있는 거 사이에는 생각보다 큰 간극이 있다. 흔히 말하는 지식의 저주(curse of knowledge)다. 이미 아는 게 너무 익숙해서, 모르는 사람의 자리에 서질 못하는 것. 사실 이 세미나를 준비한 것도 그래서였다. 설명하려다 보니, 내가 안다고 생각했던 게 실은 ‘안다고 느낀’ 것에 더 가까웠다는 걸 알게 됐다.

그러고 보면 이건 앞에서 말한 환각이랑 닮았다. 모델의 진짜 문제는 틀리는 것 자체가 아니라 자기가 아는 것과 모르는 것을 구분 못 한 채 똑같이 당당하게 말한다는 거였다. 그런데 요즘 나를 보면 그게 모델만의 문제가 아닌 것 같다. 소크라테스가 남긴 말 중에 “나는 내가 아무것도 모른다는 것을 안다”는 게 있다. 핵심은 겸손 떨자는 게 아니라, 아는 것과 모르는 것의 경계를 아는 것 자체가 앎의 출발이라는 거다. 그런데 AI한테 물어보면 뭐든 그럴듯한 답이 1초 만에 나오다 보니, 내가 진짜로 이해해서 아는 것과 그냥 받아서 아는 척하는 것의 경계가 점점 흐려진다. 답을 손에 쥐는 건 쉬워졌는데, 그 답이 내 앎인지 아닌지를 구분하는 건 오히려 더 어려워졌다.

그래서 이 글에서 계속 “마지막은 사람이 검증한다”고 한 건, 단순히 모델이 틀릴 수 있으니 한 번 더 보라는 절차적인 얘기가 아니다. 검증이라는 게 결국 “이 부분은 내가 판단할 수 있고, 이 부분은 내가 모른다”를 스스로 갈라내는 작업이다. 모델이 자기 앎의 경계를 모른다면, 그 경계를 대신 그어주는 건 사람 몫이다. AI를 잘 쓴다는 건 어쩌면, 내가 뭘 모르는지를 아는 그 오래된 능력을 다시 꺼내 드는 일인지도 모르겠다.