아는 선배가 과제 제안서를 만드는 에이전트를 만들었습니다. 프롬프트, 작업 순서 모두 에이전트 안에 들어 있는데, 여전히 사용하는 직원에 따라 생성되는 제안서 품질이 천차만별이라고 합니다. 도구만 잘 만들어 두면 편차가 줄어들 줄 알았는데 그렇지 않았습니다.
비슷한 장면을 가까이서도 봤습니다. 얼마 전 가까운 친척과 지인이 각각 자기소개서를 쓰려고 AI를 이용했습니다. 넣은 자료도 비슷했고 물어본 방식도 크게 다르지 않았는데 결과물의 수준은 확연히 달랐습니다. 차이라면 친척은 그 작업을 이미 여러 번 해본 상태였고 지인은 처음이었다는 것 정도였습니다.
흔히 이럴 때 쓸수록 AI가 나를 알아가는 모양이라고 생각합니다. 저도 처음에는 막연하게 그렇게 생각했습니다. 그런데 따져 보면 모델이 사용자를 학습한 것이 아니라, 사용자가 AI에 줄 맥락과 다루는 습관을 쌓아 둔 걸로 보는 것이 합리적입니다. 이 글에서는 그러한 맥락 쌓기의 방법을 제 경험을 바탕으로 AI 활용법 다섯 가지를 정리해 보겠습니다.
1. 개인화의 주체
엄밀히 말해서 개인화를 하는 주체는 AI가 아니라 사용자입니다. 대화를 아무리 많이 해도 모델 자체는 변하지 않습니다.
그러면 자기소개서 사례의 차이는 어디서 왔을까요. 세 가지가 섞여 있다고 봅니다. 첫째는 이미 저장된 맥락입니다. 메모리나 프로젝트 기능은 학습이 아니라, 과거 대화 중 저장해 둔 문장을 다음 요청에서 활용하는 방식입니다. 제 친척은 그동안의 작업으로 경력과 지원 분야, 원하는 문체가 이미 쌓여 있었을 가능성이 큽니다.
둘째는 사용자의 숙련도이고, 이것이 가장 큰 변수라고 생각합니다. 같은 질문처럼 보여도 경험자는 제약 조건과 예시, 판단 기준을 함께 넣습니다. 결과가 마음에 들지 않으면 두세 번 만에 원하는 방향으로 끌고 갑니다. 처음 쓰는 사람은 첫 출력을 그대로 받습니다. 나쁜 결과를 알아보는 안목 자체가 결과의 차이입니다.
셋째는 AI 특성상 같은 입력이라도 매번 조금씩 다른 출력이 나온다는 점입니다. 두 사람을 비교할 때는 이 부분도 섞여 들어갑니다.
여기서 구분해 둘 것은 쌓이는 것과 굳어지는 것입니다. 자기소개서 주제를 뽑으려면 경력 사실과 지원 직무, 회사의 요구사항을 먼저 고려해야 한다는 점은 도구와 상관없는 문제입니다. 반면 이 모델은 이렇게 말해야 알아듣더라 수준의 요령은 도구나 버전이 바뀌면 달라집니다. 동시에 도구를 오래 쓰면 쓸수록 잘 되던 방식만 반복하는 관성도 생깁니다. 모델은 좋아졌는데 나는 예전 방식을 계속 쓰고 있는 경우가 의외로 흔합니다.
2. 인지 위임
인지 위임이란 기억하고 챙기는 일을 대화에 넘기는 것입니다. 이때 AI는 단순 메모장이라기보다 비서에 가깝습니다.
메모장은 내가 쓰고 내가 찾아야 하지만 비서는 일을 맡겨 두면 정리해 두었다가 필요할 때 꺼내 줍니다. 비서에게는 아까 내가 말한 다섯 가지 사례 중에서 두 번째만 자세하게 다시 정리해 달라는 식의 요청이 가능합니다. 검색이 아니라 위임입니다.
문제는 기억해 두라고 말했을 때 실제로 어디에 저장되느냐입니다. 저장되는 자리는 크게 세 군데입니다. 지금 이 대화 안, 프로젝트 안, 그리고 계정 전체에 남는 기억 기능입니다. 대화 안에 있는 것은 대화가 길어지면 영향력이 흐려지고 새 대화를 열면 사라집니다. 이 셋을 구분하지 못하면 기억하라고 요청했는데 왜 잊었느냐는 오해가 생깁니다.
제품마다 이름은 다르지만 구조는 비슷합니다. Claude는 프로젝트마다 별도의 메모리 공간과 프로젝트 요약을 두어 업무별 맥락이 섞이지 않게 합니다. ChatGPT도 프로젝트 메모리와 일반 대화 메모리가 서로 넘나들지 않도록 분리해 두었습니다. 기능 이름은 계속 바뀔 수 있으므로 지금 쓰는 도구에서 이 세 군데가 어디인지 한 번 확인해 두면 오래 갑니다.
일상 쪽 사례로는 장보기 목록 같은 것을 생각할 수 있습니다. 목록만 놓고 보면 메모장 앱이 더 편리합니다. 마트에서 한 손으로 체크하며 봐야 하는데 대화창은 스크롤해야 하기 때문입니다. 하지만 가령 이번 저녁 메뉴를 생각하고 그 재료로 목록을 만들어 달라고 하거나, 인터넷에서 본 레시피를 보고 인원수를 바꿔서 다시 계산해 달라고 하는 등 대화를 통해 기억을 바꿔 나갈 때 제값을 합니다.
최근에는 예약 실행 기능이 붙으면서 시점까지 넘길 수 있게 됐습니다. 이제 AI가 먼저 말을 걸 수 있습니다. 반응형에서 능동형으로 넘어가는 지점입니다. 다만 아직은 알림이 잘 안 되는 경우가 있을 수 있으니, 중요한 일정은 여전히 캘린더에 이중으로 걸어 두는 편이 안전합니다.
3. 다중 대화와 분업
하나의 작업도 대화를 여러 개로 나눠서 진행하는 것이 좋을 때도 있습니다. 이때 대화를 나누는 기준은 주제가 아니라 산출물의 성격입니다. 같은 주제라도 판단을 얻으려는 대화와 결과물을 얻으려는 대화는 따로 두는 편이 낫다고 느꼈습니다.
저는 크게 세 가지 역할로 씁니다. 설계자는 판단을 하기 위한 대화입니다. 발상을 나열하고, 검토받고, 의견을 듣습니다. 실행자는 최종 결과물을 얻기 위한 대화입니다. 코드나 블로그 초안처럼 확정된 규칙 위에서 기대한 결과가 나와야 하는 것들입니다. 조력자는 앞의 둘을 잘 쓰기 위한 역할입니다. 필요한 프롬프트를 짜 주고, 어떤 내용을 프로젝트로 올릴지 정리해 줍니다.
나눠야 하는 이유는 ‘맥락’이 섞이기 때문입니다. 설계자 대화에는 검토하다 버린 안이 잔뜩 쌓입니다. 그 상태에서 실행을 시키면 폐기한 판단이 결과물에 끼어듭니다. 반대로 규칙이 빽빽하게 쌓인 대화에서는 자유로운 발상이 그 틀에 갇힙니다. 두 대화가 필요로 하는 맥락의 성격이 서로 반대입니다.
사실 이 구분은 제 취향만은 아닙니다. 앞서 말한 프로젝트별 기억 분리가 같은 발상이고, 업무별 맥락이 섞이지 않게 하려는 의도가 제품 설명에 그대로 나와 있습니다. 다만 너무 잘게 쪼개면 매번 맥락을 다시 설명해야 합니다. 주제마다 새 대화를 열기보다, 무엇을 얻으려는 대화인지로 나누는 편이 관리하기 쉬웠습니다.
4. 축적과 재사용
한 번 푼 문제는 다시 풀지 않는 편이 좋습니다. AI와 같이 해결한 과정을 남겨 두면, 같은 문제가 다시 왔을 때 그 대화나 프로젝트를 여는 것만으로 절반은 끝납니다.
앞서 언급한 것들이 맥락을 미리 넣어 두는 이야기였다면 이것은 방향이 반대입니다. 작업하면서 생긴 결과가 다음 작업의 맥락이 됩니다. 처음에 말한 쓸수록 똑똑해지는 느낌의 실체가 여기에 있다고 생각합니다. 모델이 나를 학습한 것이 아니라, 내가 만든 해결 기록이 다시 쓸 수 있는 자산으로 남은 것입니다.
방법은 크게 두 가지로 나뉩니다. 먼저 같은 대화를 다시 여는 쪽은 맥락이 통째로 살아 있어 편하지만, 그 대화의 시행착오와 폐기된 판단까지 따라옵니다. 길어질수록 무거워지고 앞부분은 흐려집니다. 두 번째로 해결책만 뽑아 프로젝트로 올리는 쪽은 한 번 정리하는 수고가 들기는 하지만 다시 쓰기에는 훨씬 낫습니다. 경우에 따라 적합한 방법을 사용하면 됩니다. 대화에서 얻은 규칙을 위로 올리는 습관이 있느냐 없느냐가 생산성 차이를 만듭니다. 물론 정리도 공짜가 아니어서, 매번 하면 배보다 배꼽이 커집니다.
추가로 남기지 말아야 할 것도 짚어야겠습니다. 이 글의 사례만 봐도 자기소개서와 제안서, 회사 업무가 들어 있습니다. 개인 이력과 사내 정보가 그대로 올라갈 수 있습니다. 개인 대화와 업무 대화는 계정이나 도구 자체를 분리하는 편이 안전하고, 회사 정책과 승인된 도구가 있는지부터 확인하는 것이 먼저입니다. 특히 프로젝트나 기억 기능처럼 오래 남는 자리일수록 신중해야 합니다. 대화는 흘러가면 그만이지만 저장한 데이터는 계속 남습니다.
5. 검색어 없는 검색
이건 약간 예외적인 활용인데요, 명확한 검색어를 모를 때 저는 AI를 씁니다. 답을 얻는 도구가 아니라 검색어를 얻는 도구로 보면 정확합니다.
얼마 전 어떤 배우의 이름이 떠오르지 않아 한참 헤맸습니다. 얼굴과 분위기는 선명한데 이름만 기억이 안 나는 상태였습니다. 검색으로는 실패했고, 대화로 묘사를 좁혀 가며 찾았습니다. 검색엔진의 단점인데요, 이름을 알면 검색이 되는데, 이름을 몰라서 찾는 상황이기 때문입니다. 검색은 정확한 문자열을 요구하지만, AI는 흐릿한 서술도 받아들입니다. 그 사람 말고 다른 후보를 달라고 쳐낼 수 있다는 점도 다릅니다.
비슷한 경우가 몇 가지 더 있습니다. 가사 일부만 기억나는 노래를 찾을 때, 뜻은 아는데 정식 명칭이 떠오르지 않는 기술 용어를 확인할 때, 내용만 기억나는 책 제목을 되짚을 때입니다. 이 중 가장 자주 경험하는 분야가 기술 용어 쪽입니다. 정식 명칭을 알아야 문서를 찾을 수 있는데 그 명칭을 모르는 것이 병목이기 때문입니다. 자기 분야 밖을 찾을 때 특히 그렇습니다.
다만 검증의 강도는 경우마다 다릅니다. 용어는 후보를 받아 정의만 확인하면 끝나서 위험이 적습니다. 반면 사람 이름이나 책 제목, 가사는 그럴듯하게 지어내거나 다른 것과 섞을 여지가 큽니다. 후보를 받은 뒤 원래 출처에서 확정하는 순서를 지키는 편이 좋습니다.
남는 변수
도구화로 해결되지 않는 영역이 있습니다. 처음에 꺼낸 제안서 에이전트 이야기로 돌아가 보겠습니다.
자기소개서 쪽은 프롬프트가 비슷했다는 전제여서 숙련도 차이로 설명할 여지가 있습니다. 그런데 에이전트는 프롬프트와 작업 순서가 이미 설계돼 있는데도 결과가 달라집니다. 도구가 프롬프트 설계는 대신해 주지만 그 앞뒤에 필요한 맥락은 대신 채워주지 못한다는 뜻입니다.
남는 변수는 결국 사용자가 들고 오는 것들입니다. 사업 배경과 고객 상황, 제약 조건을 얼마나 구체적으로 넣는가, 나온 결과가 쓸 만한지 알아보는가, 아니다 싶을 때 다시 시도하는가. 저는 이 중 나온 결과물이 쓸 만한지 알아보는 부분이 가장 중요하다고 생각합니다. 잘 만든 도구일수록 격차가 줄어들 것 같지만, 실제로는 결과물의 수준이 올라가면서 알아보는 사람만 그 이득을 가져가는 쪽에 가까워 보입니다.
할루시네이션도 같은 문제입니다. 모델이 좋아져도 틀린 답은 나옵니다. 그럴듯하게 틀리기 때문에 오히려 알아보기 어려워지는 면도 있습니다. 앞에서 사람 이름과 책 제목은 원래 출처에서 확인하라고 했는데, 제안서의 품질을 가르는 능력도 결국 같은 것입니다. 검증할 수 없는 영역은 위임의 대상이 아니라고 보는 편이 안전합니다.
맺음말
잘 만든 에이전트에서도, 자기소개서 한 장에서도 결과를 가른 것은 재능이나 모델이 아니었습니다. 그 사람이 그동안 쌓아 둔 맥락과 다루는 습관이었습니다. 앞의 다섯 가지는 그 쌓기의 방법을 정리한 것입니다.
기능의 이름은 계속 바뀝니다. 그래도 어떤 맥락을 어디에 두고, 어떤 대화를 따로 열고, 무엇을 남길지 판단하는 능력은 그대로 남습니다.
도구는 계속 바뀝니다. 남는 것은 맥락을 정리하는 능력입니다.
ChulJoo Kim (김철주)
※ 참고문헌
- Anthropic, 「Use Claude’s chat search and memory to build on previous context」, Claude Help Center, 2026.
ckarch.kr
© 2026
is licensed under
CC BY-NC-SA 4.0
