14장. 말로 지시하고 맥락을 넘기는 법

3장에서 위키를 세우고 나면 그 위키에 무엇을 시킬 것인가가 남는다. 여기서 결과를 가르는 것은 도구의 성능보다 그 요청에 얼마나 많은 맥락이 실려 있는가다. 새로 온 학생에게 줄 자료를 정리해 달라는 요청을 예로 들면, 어느 분야에서 역사적으로 중요한 논문을 찾아 달라는 문장만으로는 전달되지 않는 것이 대부분이다. 어떤 순서로 읽히고 싶은지, 왜 그 순서인지, 그 학생이 지금 무엇을 못 하는지, 이 자료로 무엇을 깨우치게 하려는지가 그 요청에 없다. 에이전트가 그것을 채워 넣으면 그럴듯한 목록이 나오고 그 목록에는 사람이 실으려던 판단이 빠져 있다. 손으로는 적지 않았을 맥락을 말로 넣고 그렇게 들어온 요청은 산출물을 소유할 작업 공간으로 보낸다.

타이핑하지 않게 되는 맥락

요청이 짧아지는 이유는 적는 데 시간이 들기 때문이다. 머릿속에 있는 배경을 문장으로 옮기면 여러 문단이 되고 그 문단을 치는 동안 정작 하려던 일이 미뤄진다. 그래서 대부분의 요청이 한두 문장으로 줄어든다. 줄어든 요청과 원래 하려던 일 사이의 거리가 결과의 품질을 정한다. 이 거리는 도구를 바꾼다고 줄지 않는다. 모델이 좋아지면 짧은 요청에서 더 그럴듯한 결과가 나오는데 그럴듯하다는 것과 내가 원하던 것이라는 것은 다르다. 오히려 결과가 그럴듯할수록 무엇이 빠졌는지 알아채기 어려워진다. 빠진 것을 알아채려면 자기가 무엇을 말하려 했는지가 어딘가에 적혀 있어야 하고 짧은 요청에는 그것이 없다.

빠지는 맥락에는 몇 가지 종류가 있다. 목적이 첫째다. 이 산출물이 누구에게 가고 그 사람이 이것으로 무엇을 하는지가 빠지면 형식은 맞고 쓸모는 없는 결과가 나온다. 배경이 둘째다. 지금까지 무엇을 해 왔고 어디까지 정해졌는지가 없으면 이미 결정된 것을 다시 제안한다. 제약이 셋째다. 언제까지인지, 무엇은 건드리면 안 되는지, 누구와 관련된 일인지가 빠지면 실행할 수 없는 결과가 온다. 판단의 근거가 넷째다. 왜 그렇게 하려는지를 적어 두면 에이전트가 그 근거에 맞지 않는 제안을 스스로 걸러 낸다. 네 가지를 매번 타이핑하려면 요청 하나에 몇 분이 걸리고 그래서 대부분 적지 않는다.

긴 수다 세션

Karpathy가 이 문제를 두고 쓴 짧은 글이 있다. 그는 LLM과 일할 때 쓸 만한 방식으로 “a nice long ramble session”을 든다. LLM이 무엇을 하려는지 이해하려면 더 많은 정보가 필요한데 타이핑하기는 귀찮은 상황이 있고 그럴 때는 의자에 기대앉아 음성 입력으로 바꾼 뒤 10분쯤 떠든다는 것이다. 정리하지 않아도 되고 뒤죽박죽이어도 되고 의식의 흐름 그대로여도 된다. 그는 맨 앞에 음성 인식으로 바꾸니 오타는 양해해 달라는 말을 붙이기도 하고 때로는 몇 번 주고받는 짧은 인터뷰 형태로 만들기도 한다고 적었다. 이어지는 관찰이 이 방식의 핵심이다. LLM은 길고 두서없는 수다를 재구성하는 데 상당히 능하고 되돌아온 정리가 처음 말한 것보다 오히려 깔끔한 경우가 많다는 것이다. 그 결과로 서로가 이해한 바가 맞춰지고 그 뒤로는 고칠 일이 줄어든다.

이 방식이 앞 절의 문제를 정확히 겨냥한다. 목적과 배경과 제약과 근거를 타이핑으로 적으려면 오래 걸리지만 말로 하면 몇 분이면 된다. 말은 정리되지 않아도 되므로 정리하는 데 드는 시간이 아예 빠진다. 그리고 정리하는 일 자체가 LLM이 잘하는 일이다. 흩어진 발화에서 무엇이 목적이고 무엇이 제약이고 무엇이 곁가지인지를 가려내 구조로 만드는 작업은 사람이 하면 지치고 기계가 하면 빠르다. 순서는 사람이 원재료를 쏟아 놓고 기계가 정리한 것을 사람이 확인하는 쪽으로 바뀐다. 확인하는 단계가 빠지면 이 방식은 성립하지 않는다.

Andrej Karpathy, X 게시물, 2026년 7월 22일. 저자가 보관한 화면.

번역

LLM과 일할 때 유용하다고 느끼는 방식 가운데 하나는 길게 수다를 떠는 세션이다. 가끔은 LLM이 내가 무엇을 하려는지 이해하려면 더 많은 정보가 필요한데, 그 내용을 모두 타이핑하기는 귀찮다. 그럴 때 나는 의자에 기대앉아 /voice로 바꾼 뒤 10분쯤 그냥 떠든다. 완전히 뒤죽박죽이어도 되고 무슨 말이든 해도 되며 의식의 흐름 그대로 말한다. 때로는 맨 앞에서 “지금부터 음성 인식으로 바꿉니다. 오타가 있어도 양해해 주세요…”라고 밝히고 몇 번 주고받는 짧은 인터뷰로 만들기도 한다. LLM은 길고 두서없는 수다를 놀라울 만큼 잘 재구성하며 엉킨 생각을 되비춘 결과가 처음 말한 것보다 제법 또렷하게 나오는 경우가 많다. 이렇게 서로의 생각을 더 잘 맞추고 나면 그 뒤로 고쳐야 할 것도 줄어든다.

음성으로 넣는 실제 방식

음성 입력의 편의는 도구마다 다르다. 휴대폰 앱에서 마이크를 눌러 그대로 넣을 수 있는 도구가 있고 그렇지 않은 도구가 있다. 이 차이가 실제 사용량을 가른다. 책상에 앉아 있지 않은 시간에 떠올린 것을 그때 넣을 수 있으면 이 방식이 일상이 되고 컴퓨터 앞에 앉아야만 되면 결국 타이핑하게 된다. 그래서 도구를 고를 때 음성 입력이 편한 쪽을 하나는 확보해 두는 편이 낫다.

내가 Codex를 권하는 또 하나의 이유

나는 이 장의 방식을 실제로 쓸 때 ChatGPT와 Codex의 음성 입력을 먼저 고른다. 컴퓨터와 iPhone 어느 쪽에서든 몇 분 동안 쉬지 않고 말해도 발화를 거의 끝까지 받아 적었다. 생각나는 대로 말하다가 문장을 고쳐 말하거나 다른 이야기로 샜다가 돌아와도 입력이 중간에 끊기지 않았다. 긴 수다에 목적과 배경과 제약을 한꺼번에 담는 이 장의 방식과 잘 맞는다.

Claude 앱에서는 같은 경험을 얻지 못했다. 긴 음성이 중간에 잘리거나 받아 적힌 분량이 적었고 Claude가 긴 발화를 끝까지 처리하지 못한 이유는 확인하지 못했다. iPhone의 기본 음성 인식을 거쳐 Claude에 넣는 방식도 누락이 많았으며 Claude 앱의 전사 결과도 내가 말한 내용을 충분히 남기지 못했다. 고유명사와 숫자는 어느 도구를 쓰든 다시 확인해야 하지만 긴 맥락이 얼마나 온전히 남는지를 보면 ChatGPT와 Codex 쪽이 훨씬 좋았다.

이 평가는 실제 연구와 행정 업무를 말로 지시하며 반복해서 얻은 경험에서 나왔다. 같은 녹음을 여러 도구에 넣어 수치로 비교하지는 않았다. 음성 지시를 매일 쓰려면 몇 분 동안 말한 내용이 끝까지 남아야 한다. 이 조건 때문에 나는 Claude보다 Codex를 추천한다.

실제로 무엇을 떠드는지가 감이 잡히지 않을 수 있다. 메일 한 통을 받았고 그에 대해 무언가 정해야 하는 상황을 예로 들면, 5분에서 10분 동안 다음과 같은 것들이 섞여 나온다. 어떤 메일이 왔고 무엇을 요구하는지, 그 메일이 가리키는 논문이 무엇이고 지금 어떤 목적으로 쓰고 있는지, 그 주제에 대해 위키에 무엇을 정리해 두었는지, 이 연구가 어떤 의미를 갖는다고 보는지, 함께 일하는 사람들이 어떤 방식으로 일하고 언제까지를 원하는지, 누가 참여하고 싶어 하고 어떤 부분에 강점이 있는지가 이어진다. 문장이 끊기고 중간에 다른 이야기로 샜다가 돌아오기도 한다. 그대로 두면 된다. 이 입력에는 많은 정보가 필요하다.

따라해보기

아래 블록은 AI 도구의 채팅창에 넣는 프롬프트이고 가운데 부분은 타이핑 대신 마이크로 말한다. 수다를 시작할 때 앞에 붙일 말은 짧으면 된다. 음성으로 넣는다는 사실과 무엇을 해 달라는지만 말하고 나머지는 흘러가는 대로 둔다.

지금부터 음성으로 넣는다. 정리되지 않은 말이니 오타와 끊긴 문장은
그대로 넘겨 달라.

<5분에서 10분 동안 떠오르는 대로 말한다>

여기까지다. 다음 순서로 답해 달라.
1. 내가 하려는 일을 한 문장으로 정리
2. 목적, 배경, 제약, 판단 근거를 각각 항목으로 분리
3. 내 말에서 서로 어긋나는 대목
4. 결정이 필요한데 내가 말하지 않은 것

아직 아무것도 실행하지 말고 위 네 가지만 보여 달라.

세 번째와 네 번째 항목이 이 요청의 값이다. 말로 하면 앞에서 한 말과 뒤에서 한 말이 어긋나는 일이 흔하고 그 어긋남은 말하는 사람 눈에는 잘 보이지 않는다. 어긋난 대목을 짚어 주면 아직 정하지 않은 것이 드러난다. 네 번째도 같은 성격이다. 한참 떠들고 나면 다 말한 것 같은데 실제로는 가장 중요한 결정 하나를 말하지 않은 경우가 있다. 아무것도 실행하지 말라는 마지막 줄을 넣는 이유는 정리를 확인하기 전에 작업이 시작되면 잘못 알아들은 내용 위에 결과가 쌓이기 때문이다.

인터뷰로 바꾸기

한 번에 다 떠들지 않아도 된다. Karpathy가 함께 적어 둔 방식이 몇 번 주고받는 짧은 인터뷰로 만드는 것이다. 3분쯤 말한 뒤 무엇이 더 필요한지 물어보게 하고 물어온 것에 답하는 식으로 두어 번 오간다. 이 방식이 잘 맞는 경우가 있다. 자기가 무엇을 말해야 하는지 모르는 상태에서 시작할 때다. 한참 떠들다 보면 정작 중요한 제약을 빠뜨리는데 무엇이 빠졌는지는 정리를 받아 봐야 안다. 인터뷰로 바꾸면 그 확인이 앞당겨진다. 질문의 방향도 정해 줄 수 있다. 목적과 제약과 판단 근거 가운데 무엇이 비어 있는지를 묻게 하면 곁가지로 새는 질문이 줄어든다.

반대로 인터뷰가 방해가 되는 경우도 있다. 이미 무엇을 원하는지 알고 있고 그것을 옮기기만 하면 되는 상황에서는 중간에 끊기는 것이 흐름을 깬다. 그럴 때는 끝까지 말하고 한 번에 정리를 받는 편이 빠르다. 두 방식을 가르는 기준은 자기 머릿속이 얼마나 정리되어 있는가다. 정리되어 있으면 한 번에 쏟고 정리되지 않았으면 주고받는다. 어느 쪽이든 마지막에 하는 일은 같다. 정리된 결과를 읽고 고치는 것이다.

되돌아온 정리 확인

정리를 받으면 읽는다. 이 방식에서 사람이 하는 일이 여기에 몰려 있다. 확인할 것이 두 종류다. 하나는 잘못 알아들은 곳이고 다른 하나는 잘못 말한 곳이다. 앞의 것은 음성 인식이 만든 오류다. 사람 이름, 기관 이름, 유전자나 방법의 이름 같은 고유명사와 숫자가 특히 자주 틀린다. 정리된 문장은 문법적으로 완전하므로 틀린 이름도 자연스럽게 읽히고 그래서 원문을 아는 사람이 눈으로 확인해야 한다. 숫자는 더 위험하다. 마감일이나 표본 수가 틀리면 그 뒤의 모든 계획이 어긋나는데 정리된 문장만 보면 틀렸다는 표시가 없다.

뒤의 것은 자기가 잘못 말한 곳이다. 이쪽이 더 유용하다. 떠드는 동안에는 앞뒤가 맞는다고 느꼈는데 정리해 놓고 보면 두 대목이 서로 부딪히는 경우가 있다. 아직 내리지 못한 결정이 그 충돌에서 드러나고 정리를 받기 전에는 결정을 미뤘다는 사실조차 모르고 있었던 것이다. 이 발견이 이 방식의 실질적인 이익 가운데 하나다. 확인이 끝나면 고친 정리를 다시 받는다. 여기까지가 한 번의 왕복이고 대개 두 번이면 실행에 들어갈 만한 상태가 된다. 확인 없이 곧바로 실행으로 넘어가면 잘못 알아들은 이름이 파일 이름과 문서 제목에 박히고 그 시점에 되돌리는 값이 커진다.

수다가 이미 있는 문서를 만날 때

말로 넣는 방식이 위키와 만나면 이익이 한 번 더 생긴다. 떠드는 동안 말한 것 가운데 상당수가 이미 위키에 적혀 있기 때문이다. 그 논문에 대해 무엇을 정리해 두었는지, 그 주제에 대해 어떤 판단을 내려 두었는지, 지난번에 무엇을 하기로 했는지가 문서에 있다. 정리를 시킬 때 그 문서들을 함께 읽게 하면 두 가지가 갈린다. 내가 말한 것 가운데 이미 적혀 있는 것과 새로 나온 것이다. 앞의 것은 다시 적을 필요가 없고 뒤의 것이 이번에 남길 것이다. 이 구분이 없으면 같은 판단이 문서에 두 번 세 번 쌓이고 쌓인 것들이 조금씩 달라진다. 말한 것과 적혀 있는 것이 어긋날 때는 몇 달 사이에 생각이 바뀌었는데 문서를 고치지 않았거나 문서가 맞고 지금 잘못 기억하고 있는지를 확인한다.

어느 쪽인지는 사람이 정한다. 판정을 시키면 문서 쪽이 맞다고 답하는 경향이 있는데 문서에 적힌 것이 항상 최신은 아니기 때문에 그 답을 그대로 받으면 안 된다. 어긋난 대목을 짚어 달라고만 하고 어느 쪽이 맞는지는 묻지 않는 편이 낫다. 짚어 준 대목을 열어 보고 언제 적힌 것인지 확인한 뒤에 고칠지 정한다. 이 확인이 끝나면 문서 쪽을 고치는 일이 그날의 산출물 가운데 하나가 된다.

어느 작업 공간으로 갈지 정하기

말로 들어온 요청에는 한 가지 문제가 더 있다. 어느 폴더에서 처리할 일인지가 요청에 적혀 있지 않다는 것이다. 3장에서 본 대로 위키 하나로 모든 일이 처리되지는 않는다. 논문을 다루는 위키 옆으로 분석 코드를 두는 작업 공간, 원고를 쓰는 작업 공간, 회의와 강연을 기록하는 작업 공간이 갈라져 나오고 각각이 자기 지침 파일과 자기 위키를 갖는다. 말로 쏟아 놓은 내용에는 이 공간들에 걸친 이야기가 섞여 있다. 논문 이야기를 하다가 그 논문에 들어갈 그림 이야기로 넘어가고 다시 그 그림을 만드는 분석 이야기로 넘어간다. 세 공간에 걸친 요청이 하나의 발화로 들어온 것이다.

그래서 정리 단계에서 판정을 함께 시킨다. 이 요청의 각 부분이 어느 공간으로 가야 하는지를 정하고 그 공간의 지침 파일을 읽은 뒤에 무엇을 할지 정하게 한다. 판정 기준은 산출물의 소유다. 그 작업이 만들어 내는 결과물을 어느 공간이 소유하는지로 정하고 소유한 쪽이 파일명과 폴더 배치와 완료 기준을 정한다. 나머지는 근거와 원자료만 공급한다. 이 기준이 없으면 지금 열려 있는 폴더나 요청에 들어 있는 단어 하나로 정해지고 같은 종류의 작업이 매번 다른 곳에서 벌어진다.

작업 공간마다 다른 위키

각 작업 폴더 안에 위키 폴더를 하나 두고 해당 공간의 규칙과 상태를 거기에 둔다. 분석 폴더의 경우 프로젝트마다 폴더를 만들고 그 아래에 자료, 코드, 결과, 참고자료 같은 하위 폴더를 둔다. 프로젝트들 사이의 관계와 어느 문서가 무엇의 정본인지는 위키 폴더의 문서 하나가 소유한다. 프로젝트마다 그 관계를 따로 적으면 프로젝트가 늘어날 때 서로 어긋나기 시작한다. 작업 로그도 그 위키 폴더에 함께 둔다. 각 프로젝트 폴더 안에 로그를 만들면 폴더 루트가 지저분해지고 여러 프로젝트에 걸친 작업은 어느 로그에 적을지가 매번 결정 사항이 된다.

원고 폴더의 위키에는 다른 것이 들어간다. 지금 쓰고 있는 원고의 개요, 무엇을 왜 고쳤는지에 대한 작업 로그, 그림을 어떤 규칙으로 만드는지, 그리고 함께 쓰는 사람들에 대한 기록이 여기 놓인다. 마지막 항목은 다루는 방식을 정해 두어야 한다. 사람에 대한 기록에는 협업에 필요한 사실만 담고 그 사실이 문서에 적힐 때 밖으로 나갈 수 있다는 것을 전제로 쓴다. 회의와 강연 폴더의 위키에는 기록과 함께 서류 작성 요령이 들어간다. 어느 기관이 어떤 양식을 쓰는지, 출장 신청과 보고를 어떤 순서로 하는지 같은 것들이다. 매번 넣어야 하는 개인 정보와 소속 정보는 이 문서 본문에 적지 않고 바깥 파일에 두고 경로만 가리킨다. 규칙 문서는 세션마다 통째로 읽히므로 본문에 적어 두면 그 정보가 매번 함께 나간다. 16장에서 다루는 자료 경계가 여기서 미리 걸린다.

이 라우팅을 처음부터 완벽하게 만들 필요는 없다. 공간이 둘일 때는 어느 쪽인지가 대체로 분명해서 판정할 것이 없고 넷을 넘어가면서 흔들리기 시작한다. 흔들리는 경우가 나타나면 그때 판정 규칙을 한 줄 더 적는다. 실제로 자주 흔들리는 것은 두 공간에 걸친 작업이다. 원고에 들어갈 그림을 만드는 일은 분석이면서 원고이고 어느 쪽이 소유하는지를 정해 두지 않으면 그림 파일이 두 곳에 생긴다. 이런 경우에는 파일이 최종적으로 어디에 실리는지로 정한다. 그림은 원고에 실리므로 원고 폴더가 소유하고 그 그림을 만든 코드는 분석 폴더가 소유하며 두 폴더는 경로로 서로를 가리킨다. 복제하지 않고 가리킨다는 것이 이 구조에서 반복해서 나오는 원칙이다.

음성 입력에서 남길 것

음성으로 넣은 내용은 그 세션이 끝나면 사라진다. 정리된 결과도 대화 안에만 있으면 마찬가지다. 그래서 왕복이 끝난 뒤에 무엇을 어디에 남길지 정한다. 남길 것은 대체로 셋이다. 이 요청으로 무엇을 하기로 했는지, 그 판단의 근거가 무엇인지, 그리고 아직 정하지 못한 것이 무엇인지다. 세 가지 모두 그 작업을 소유한 공간의 위키에 들어간다. 수다 원문과 정리 전문은 남기지 않는다. 원문에는 곁가지가 대부분이고 정리 전문은 그날의 상태를 담고 있어 며칠이면 낡는다. 회의 전사를 다룰 때처럼 원자료와 판단은 서로 다른 문서에 남긴다.

이 방식을 반복하면 각 작업 공간의 위키가 실제로 자란다. 처음에는 지침 몇 줄뿐이던 문서에 판단과 근거가 쌓이고 몇 달이 지나면 새 요청을 넣었을 때 그 문서가 이미 절반을 답해 준다. 말로 넣는 방식이 특히 잘 맞는 이유가 여기 있다. 타이핑으로는 적지 않았을 근거가 말로는 나오고 그 근거가 문서에 남아 다음 판단의 재료가 된다. 그 결과 같은 종류의 요청을 두 번째로 넣을 때는 떠들 것이 줄어든다. 이미 적혀 있는 것을 다시 말할 필요가 없기 때문이다.

이 방식은 정확한 값을 그대로 넘겨야 하는 작업에는 잘 맞지 않는다. 파일 경로, 식별자, 명령의 옵션, 통계 수치처럼 한 글자만 틀려도 다른 것이 되는 입력은 말로 넣지 않는다. 음성 인식이 이런 종류를 특히 자주 틀리고 틀린 값은 정리된 문장 안에서 자연스럽게 읽힌다. 이런 값은 타이핑하거나 붙여 넣고 말로는 그 값을 무엇에 쓸 것인지만 설명한다. 배경과 판단은 말로 넣고 정확해야 하는 값은 손으로 넣으면 된다. 여러 사람이 함께 있는 곳에서도 쓰기 어렵다. 5분에서 10분을 소리 내어 말해야 하므로 혼자 말할 수 있는 환경이 필요하고 다른 사람에 대한 이야기가 들어가면 더 조심해야 한다.