암묵지 보관 - 일상의 소소함

회의실에서 벌어진 일

얼마 전, 한 프로젝트의 요구사항 검토 회의에서 있었던 일이다. 시스템 이관 프로젝트였다. 현업 담당자가 요구사항 문서를 화면에 띄우고 설명을 시작했다. “기존 시스템의 모든 기능을 동일하게 구현해 주세요.” 문서는 깔끔했다. 기능 목록이 표로 정리돼 있었고, 각 항목에 우선순위까지 매겨져 있었다.

AI에게 이 문서를 던져주면 어떻게 될까. 아마 기능 목록을 읽고, 우선순위에 따라 개발 일정을 산출하고, 필요한 기술 스택을 추천하고, 심지어 코드 스켈레톤까지 만들어줄 것이다. 문서에 적힌 내용만 놓고 보면 완벽한 분석이다.

그런데 회의실에 있던 사람들은 다른 것을 읽고 있었다.

현업 담당자가 “모든 기능을 동일하게”라고 말할 때, 그의 목소리가 살짝 떨렸다. 옆에 앉은 팀장은 노트북 화면을 보며 미세하게 고개를 저었다. 기획팀에서 온 과장은 특정 기능 항목이 나올 때마다 펜을 만지작거렸다. 나는 20년간 이런 회의를 수백 번 해왔기 때문에 그 순간 직감했다. 이 프로젝트에는 문서에 적히지 않은 이야기가 있다.

회의가 끝나고 복도에서 현업 담당자를 만났다. 커피 한 잔을 건네며 물었다. “혹시 기존 시스템에서 안 쓰는 기능이 있지 않으세요?” 그가 한숨을 쉬었다. “사실 기능의 절반은 아무도 안 써요. 그런데 그걸 문서에 쓸 수가 없어요. 그 기능들을 만든 분이 아직 계시거든요.”

이것이 맥락이다. 문서 어디에도 적히지 않았지만, 프로젝트의 성패를 가르는 결정적 정보. AI는 문서에 적힌 “모든 기능을 동일하게”를 충실하게 이행하려 했을 것이다. 하지만 사람은 행간을 읽었다. 그 행간에는 조직의 역학, 개인의 체면, 암묵적 합의, 그리고 말하지 못하는 진실이 담겨 있었다.

7화에서 이어지는 이야기

지난 7화에서 신뢰 자산을 다뤘다. AI 시대에 인간관계가 왜 더 비싸지는지, 사람 사이의 신뢰가 어떻게 조직의 경쟁력이 되는지 이야기했다. 오늘은 그 연장선에서 한 걸음 더 들어간다. 신뢰가 축적되면 무엇이 가능해지는가? 바로 맥락을 읽는 능력이 작동하기 시작한다. 신뢰 관계가 없으면 행간은 그냥 빈 줄이다. 신뢰가 있을 때 비로소 그 빈 줄에서 의미가 피어난다.

이번 8화에서는 AI가 구조적으로 접근할 수 없는 영역, ‘맥락’이라는 것의 정체를 파헤쳐보려 한다. 단순히 “AI는 맥락을 못 읽어”라는 뻔한 이야기가 아니다. 20년간 금융IT 현장에서, 그리고 8년간 챗봇을 운영하면서 내가 목격한 맥락의 실체가 무엇인지, 그것이 왜 데이터로 환원될 수 없는지, 그리고 그것을 읽는 능력을 어떻게 키울 수 있는지를 이야기하겠다.

맥락이란 무엇인가 — 정의부터 다시 하자

맥락(Context)이라는 단어는 기술 업계에서 너무 흔하게 쓰인다. AI 모델의 ‘컨텍스트 윈도우’, 프로그래밍의 ‘실행 컨텍스트’, 대화의 ‘문맥’. 기술적 정의로서의 맥락은 명확하다. 주어진 정보를 해석하기 위해 필요한 주변 정보의 집합. 하지만 내가 오늘 말하고자 하는 맥락은 이것과 결정적으로 다르다.

내가 말하는 맥락은 “명시적으로 전달되지 않았지만, 상황을 올바르게 이해하기 위해 반드시 필요한, 그러면서도 데이터화할 수 없는 정보의 총체”이다.

이 정의에서 핵심은 세 가지다.

명시적으로 전달되지 않았다 — 누군가 의도적으로 숨긴 것일 수도 있고, 너무 당연해서 굳이 말하지 않는 것일 수도 있고, 말로 표현할 수 없는 것일 수도 있다.
올바른 이해에 반드시 필요하다 — 이것 없이는 같은 문장, 같은 데이터, 같은 상황을 완전히 다르게 해석하게 된다.
데이터화할 수 없다 — 설령 알고 있더라도 구조화된 형태로 기록하기가 극히 어렵거나 불가능하다.

금융IT에서 일하다 보면 이 세 조건을 동시에 충족하는 상황을 매일 만난다. 감독기관의 검사가 예고된 시점에 올라오는 시스템 개선 요청. 그 요청서의 문면은 “사용자 편의성 향상”이지만, 진짜 의도는 검사 대비 증적 확보다. 이걸 모르고 UX 관점에서만 접근하면 현업이 원하는 것과 완전히 다른 결과물이 나온다.

AI의 컨텍스트 vs 인간의 맥락

오해를 방지하기 위해 짚고 넘어가자. 2026년 현재의 AI, 특히 대형 언어 모델은 분명 ‘컨텍스트’를 처리한다. 대화 이력을 기억하고, 문서의 앞뒤를 참조하며, 심지어 수십만 토큰의 긴 문맥도 유지한다. 나는 AI가 문맥을 ‘전혀’ 모른다고 말하려는 게 아니다.

내가 말하는 것은 AI가 처리하는 컨텍스트와 인간이 읽는 맥락은 본질적으로 다른 종류의 것이라는 점이다.

AI의 컨텍스트는 입력된 것이다. 프롬프트에 적힌 텍스트, 업로드된 문서, API로 전달된 데이터. 아무리 정교해도 결국 누군가가 명시적으로 넣어준 정보의 범위 안에서 작동한다.

인간의 맥락은 입력되지 않은 것에서 읽어낸 것이다. 말하지 않은 것, 표정, 분위기, 타이밍, 역사, 관계, 문화, 상식, 직관. 이것들은 프롬프트에 적을 수 없다. 적을 수 있다 해도 완전하지 않다. 완전하다 해도 그것을 해석하는 또 다른 맥락이 필요하다.

이것은 단순한 기술적 한계가 아니다. 구조적 불가능이다. 그 이유를 지금부터 층위별로 풀어보겠다.

맥락의 다섯 가지 층위

20년간 현장에서 경험한 맥락을 분류해 보면 크게 다섯 가지 층위로 나눌 수 있다. 각 층위는 독립적이기도 하지만, 대부분의 경우 여러 층위가 동시에 작동하며 복합적인 의미를 만들어낸다.

1층: 조직의 맥락 — “누가 말했느냐가 무엇을 말했느냐보다 중요하다”

같은 제안서라도 누가 들고 왔느냐에 따라 의미가 완전히 달라진다. 이것은 편향이 아니다. 합리적인 정보 처리다.

예를 들어보자. “이 시스템의 장애 대응 프로세스를 자동화하면 좋겠습니다”라는 제안이 올라왔다. 이 한 문장을 AI에게 주면, AI는 장애 대응 자동화의 기술적 방안을 제시할 것이다. 모니터링 도구, 자동 복구 스크립트, 알림 파이프라인. 기술적으로 훌륭한 답변이다.

그런데 사람이라면 먼저 이렇게 물을 것이다. “이 제안을 누가 했지?”

운영팀 신입이 했다면 — 야간 장애 대응에 지쳐서 업무 부담을 줄이고 싶은 것일 수 있다. 진짜 필요한 건 자동화가 아니라 당직 로테이션 개선일 수 있다.
기획팀 임원이 했다면 — 비용 절감 보고서를 쓰기 위한 근거가 필요한 것일 수 있다. 진짜 원하는 건 “자동화로 인력을 N명 줄일 수 있다”는 숫자다.
감사팀에서 했다면 — 최근 장애 사고의 재발 방지 대책을 요구받고 있는 것이다. 진짜 필요한 건 기술적 자동화가 아니라 감사 보고서에 쓸 수 있는 ‘대책 문서’다.
현업 부서장이 했다면 — 개발팀에 빚을 만들어두고 나중에 다른 요청을 관철시키려는 포석일 수 있다. 이 제안의 채택 여부보다 “제안을 했다”는 사실 자체가 목적이다.

같은 한 문장, 네 가지 전혀 다른 의미. 이 차이를 만드는 것은 제안자의 직급, 소속, 최근 상황, 조직 내 역학관계, 그리고 과거 행동 패턴이다. 이 정보들은 어떤 데이터베이스에도 기록되어 있지 않다. 사람들의 머릿속에, 복도에서 나눈 잡담 속에, 회식 자리의 넋두리 속에 흩어져 있다.

금융IT에서 이런 조직 맥락을 못 읽으면 프로젝트가 산으로 간다. 나는 경력 초반에 이것을 몰랐다가 큰 낭패를 본 적이 있다. 현업이 요청한 대로 정확하게 만들었는데, 결과물을 보여주니 “이게 아닌데”라는 반응이 돌아왔다. 요구사항 문서를 펼쳐보며 “여기 적힌 대로 만들었는데요”라고 항변했지만 소용없었다. 문서에 적힌 것과 현업이 진짜 원한 것은 달랐다. 그리고 진짜 원하는 것은 문서에 적을 수 없는 종류의 것이었다.

2층: 시간의 맥락 — “같은 말도 언제 하느냐가 다르다”

타이밍은 맥락의 가장 미묘한 층위 중 하나다. AI에게 시간은 타임스탬프다. 언제 입력이 들어왔는지, 얼마나 시간이 지났는지를 밀리초 단위로 기록한다. 하지만 인간에게 시간은 의미다.

“이 건은 천천히 진행해도 됩니다.” 이 말의 뜻은 말한 시점에 따라 정반대가 될 수 있다.

분기 초에 들으면 — 진짜로 급하지 않다는 뜻이다. 다른 우선순위 높은 일을 먼저 하라는 배려.
분기 말에 들으면 — 이번 분기 실적에 반영할 생각이 없다는 뜻이다. 이 프로젝트의 중요도가 떨어졌다는 시그널.
인사 시즌 직전에 들으면 — 이 프로젝트의 주도권을 다른 사람에게 넘기려는 준비일 수 있다.
감사 직후에 들으면 — 감사에서 지적을 받았고, 서둘러 진행하면 또 다른 문제가 생길까 봐 신중해진 것이다.

챗봇을 운영하면서 가장 많이 느꼈던 것이 이 시간의 맥락이다. 금요일 오후 5시에 들어오는 “계좌 해지 방법 알려주세요”와 월요일 아침 9시에 들어오는 같은 질문은 전혀 다른 상황에서 비롯된 것일 가능성이 높다. 금요일 오후의 질문은 충동적 결정일 수 있고, 월요일 아침의 질문은 주말 내내 고민한 결과일 수 있다. 챗봇은 두 경우 모두 동일한 해지 절차를 안내한다. 하지만 사람 상담사라면 접근 방식이 달랐을 것이다.

더 미묘한 시간 맥락도 있다. 금융 시스템에서 연말 결산 시즌에 올라오는 “사소한 UI 변경 요청”은 사소하지 않다. 십중팔구 결산 과정에서 발견된 데이터 정합성 문제를 UI 변경으로 포장한 것이다. 왜 직접 말하지 않느냐고? 데이터 정합성 문제를 공식적으로 제기하면 감사 이슈가 되기 때문이다. 연말에 감사 이슈를 만들고 싶은 사람은 아무도 없다. 이런 맥락은 금융업의 계절 리듬을 체화한 사람만 읽을 수 있다.

3층: 감정의 맥락 — “논리적으로 맞는 말이 왜 틀린가”

AI는 감정 분석(Sentiment Analysis)을 할 수 있다. 텍스트에서 긍정·부정·중립을 판별하고, 기쁨·슬픔·분노 같은 감정 레이블을 붙인다. 2026년의 모델들은 꽤 정교해졌다. 풍자를 잡아내기도 하고, 문맥에 따른 감정 변화를 추적하기도 한다.

하지만 감정의 맥락은 감정 분석과 다르다. 감정의 맥락이란, 상대방의 감정 상태가 그 사람의 말과 행동의 의미를 어떻게 바꾸는지를 이해하는 것이다.

내가 챗봇 운영 8년 동안 가장 많이 본 유형의 민원이 있다. 고객이 격앙된 어조로 시스템 오류를 신고한다. 기술적으로 조사해 보면 오류가 아니라 고객의 조작 실수인 경우가 대부분이다. AI라면 — 그리고 경험 없는 신입 상담사라면 — 정중하게 “확인 결과 시스템 오류가 아니며, 다음과 같이 조작하시면 됩니다”라고 안내할 것이다.

논리적으로 완벽하게 맞는 답변이다. 그리고 실무적으로 완벽하게 틀린 답변이다.

격앙된 고객이 원하는 것은 문제 해결이 아니다. 자신의 감정이 인정받는 것이다. “불편을 드려 죄송합니다. 저도 그런 상황이면 화가 났을 것 같습니다.” 이 한마디가 먼저 나와야 한다. 그 다음에 “제가 확인해 보니…”로 이어져야 한다. 순서가 바뀌면 고객의 분노는 배가된다. “내 잘못이라고요? 당신네 시스템이 헷갈리게 만들어놓고?”

이것은 ‘공감 표현을 먼저 하라’는 단순한 CS 매뉴얼의 문제가 아니다. 그런 매뉴얼이라면 AI에게도 가르칠 수 있다. 문제는 언제 공감이 필요하고 언제 필요하지 않은지를 판단하는 것이다. 같은 격앙된 어조라도, 시스템 장애로 실제 손해를 본 고객은 공감보다 빠른 해결을 원한다. 감정적으로 지쳐있는 고객은 해결 자체보다 “당신이 나를 이해한다”는 느낌을 원한다. 그리고 일부 고객은 의도적으로 감정을 높여서 보상을 끌어내려 한다. 이 세 가지 상황에 대한 대응은 모두 달라야 한다.

그 판단을 가능하게 하는 것이 감정의 맥락이다. 고객의 말뿐만 아니라, 그 고객의 과거 상담 이력, 현재 시스템 상태, 최근 서비스 장애 이력, 그리고 — 가장 중요한 — 대화의 흐름 속에서 감지되는 미세한 뉘앙스의 변화. 이것들을 종합적으로 읽어내는 것은 데이터 처리가 아니라 인간적 감수성의 영역이다.

4층: 문화의 맥락 — “같은 단어가 다른 세계를 가리킨다”

한국 금융IT에서 일하면 한국 특유의 문화적 맥락이 기술적 의사결정에 깊이 개입하는 것을 목격하게 된다.

“검토해 보겠습니다.” 이 말을 AI에게 분석시키면 ‘긍정적 검토 의향’으로 분류할 것이다. 하지만 한국 직장인이라면 안다. 이 말은 대개 ‘정중한 거절’이다. “검토해 보겠습니다”와 “좋습니다, 진행하시죠”는 아주 다른 말이다. 전자에는 실행 의지가 빠져 있다.

이런 문화적 맥락은 단순한 화법의 문제가 아니다. 조직 문화, 산업 문화, 세대 문화가 겹겹이 쌓여서 만들어진 의미의 생태계다.

금융권에는 특히 독특한 문화적 맥락이 있다.

“리스크가 있습니다” — 기술적 리스크가 아니라 감독기관 리스크를 말하는 경우가 많다.
“원칙적으로 안 됩니다” — ‘원칙적으로’가 붙으면 예외가 있다는 뜻이다. 그 예외를 찾아달라는 암묵적 요청.
“시스템에서 막고 있습니다” — 기술적으로 불가능한 게 아니라 정책적으로 차단한 것이다. 정책을 바꾸면 되는 문제.
“전례가 없습니다” — 하고 싶지 않다는 뜻이다. 전례를 만들어야 할 만큼 중요한 건인지 다시 생각해 보라는 뜻이기도 하다.
“위에서 내려왔습니다” — 더 이상 토론의 여지가 없다는 뜻. 이 시점에서 기술적 반론을 제기하면 정치적 자살이다.

이런 표현들을 AI는 액면 그대로 처리한다. “리스크가 있다”면 리스크 분석 매트릭스를 만들어줄 것이고, “전례가 없다”면 유사 사례를 검색해줄 것이다. 기술적으로 정확하지만 상황적으로 완전히 빗나간 대응이다.

문화적 맥락이 특히 까다로운 이유는 명시적으로 가르칠 수 없기 때문이다. “검토해 보겠습니다 = 거절”이라고 규칙을 만들 수 있을까? 물론 그렇게 만들 수는 있다. 하지만 진짜로 검토하겠다는 의미로 쓰일 때도 있다. 그 차이를 만드는 것은 말한 사람의 표정, 말투, 그리고 그 사람과의 관계에서 축적된 경험이다. 규칙으로 환원하는 순간 예외가 생기고, 예외를 처리하는 규칙을 만들면 또 다른 예외가 생긴다. 끝없는 재귀다.

5층: 암묵지의 맥락 — “설명할 수 없지만 알고 있는 것”

다섯 번째이자 가장 깊은 층위는 암묵지(暗默知, Tacit Knowledge)의 맥락이다. 마이클 폴라니가 말한 “우리는 말할 수 있는 것보다 더 많이 알고 있다(We know more than we can tell)”가 정확히 이 층위를 가리킨다.

금융 시스템 개발에서 암묵지의 맥락은 생명줄이다. 예를 들어, 레거시 시스템의 특정 모듈을 수정할 때가 있다. 문서화는 형편없고, 원래 개발자는 퇴직했고, 코드 주석도 거의 없다. AI에게 코드를 분석시키면 로직을 읽어내고 리팩토링 방안까지 제안해줄 것이다. 기술적으로 합리적인 제안이다.

하지만 10년 넘게 그 시스템을 만져온 선배는 고개를 젓는다. “그 모듈은 건드리지 마.” 왜냐고 물으면 명확하게 설명하지 못한다. “그냥… 건드리면 이상한 데서 터져.” 이것은 미신이 아니다. 수년간의 장애 대응, 야근, 긴급 패치의 경험이 체화된 직관이다. 그 선배의 머릿속에는 코드로 표현되지 않은 의존성 맵이 있고, 문서화되지 않은 부작용의 연쇄가 있고, “절대 동시에 실행하면 안 되는 배치 목록”이 있다.

이 암묵지는 전수하기가 극히 어렵다. 매뉴얼로 쓸 수 없다. 왜냐하면 당사자도 자신이 정확히 무엇을 알고 있는지 모르기 때문이다. 특정 상황이 닥쳤을 때 비로소 “아, 이건 이렇게 해야 해”라고 떠오르는 종류의 앎이다. 상황이 앎을 촉발하는 것이지, 앎이 선제적으로 존재하는 것이 아니다.

AI 시대에 이 암묵지의 가치는 역설적으로 더 커진다. 명시적 지식은 AI가 더 잘 처리한다. 문서화된 절차, 정형화된 규칙, 코드화된 로직 — 이런 것들은 AI에게 맡기는 게 효율적이다. 하지만 문서화되지 않은 것, 코드에 담기지 않은 것, 말로 전달할 수 없는 것을 아는 사람은 대체 불가능한 존재가 된다.

챗봇 8년이 가르쳐준 것 — 맥락 부재의 비용

이론적인 이야기만 하면 와닿지 않을 수 있다. 8년간 챗봇을 운영하면서 내가 직접 목격한, 맥락 부재가 만들어낸 실제 비용을 이야기해 보겠다.

사례 1: “정상 작동”이 만든 민원 폭주

어느 해 연초, 세금 관련 조회 기능에 문의가 폭주했다. 챗봇은 완벽하게 작동하고 있었다. 질문을 정확히 이해하고, 정확한 답변을 제공했다. 기술적으로 어떤 오류도 없었다.

문제는 따로 있었다. 그해 세법이 바뀌면서 조회 결과의 숫자가 전년도보다 크게 달라졌다. 고객들은 “작년에는 이 금액이 아니었는데?”라고 물었다. 챗봇은 “현재 조회 결과는 정상이며, 세법 개정에 따라 변경될 수 있습니다”라고 답했다. 기술적으로 100% 정확한 답변이다.

하지만 고객의 진짜 질문은 “내가 세금을 더 내야 하는 건가?”가 아니었다. “이게 맞는 건지 확인해 달라, 혹시 오류가 아닌지 불안하다”였다. 불안감에서 비롯된 질문에 시스템 정상 작동 안내는 오히려 불안을 키웠다. “정상이래, 그러면 진짜 이만큼 내야 한다는 거네?” → 상담사 연결 요청 폭주 → 상담 대기 시간 증가 → 추가 민원 발생.

사람 상담사라면 어땠을까. “올해 세법이 바뀌어서 많은 분들이 같은 질문을 하고 계십니다. 변경 사항을 간단히 설명드릴까요?” 이렇게 시작했을 것이다. 고객의 불안을 먼저 인식하고, 맥락(세법 개정)을 공유하고, 개인적 상황에 맞는 안내로 이어갔을 것이다.

이 사건 이후 우리 팀은 ‘시기별 맥락 프리셋’이라는 것을 만들었다. 연말정산 시즌, 금리 변동 시기, 세법 개정 시기 등에 맞춰 챗봇의 응답 톤과 내용을 미리 조정해 두는 것이다. 하지만 이것은 근본적 해결이 아니라 사람이 맥락을 읽어서 AI에게 주입해주는 것이다. 인간이 루프 안에 있어야 하는 이유의 전형적인 사례다.

사례 2: 고객의 침묵이 말하는 것

챗봇 데이터를 분석하다 보면 흥미로운 패턴이 보인다. 특정 시나리오에서 고객이 대화를 중간에 포기하는 비율이 유독 높은 경우가 있다. 기술적 지표로는 ‘이탈률’이라고 부른다.

AI에게 이탈률 데이터를 분석시키면, 이탈이 많은 시점의 공통점을 찾아줄 것이다. “3번째 턴에서 이탈률이 42%이며, 해당 턴에서 계좌 번호 입력을 요구하는 것이 원인으로 보입니다. 계좌 번호 입력 단계를 간소화하면 이탈률이 개선될 것으로 예상됩니다.” 데이터 기반의 합리적 분석이다.

그런데 실제로 그 시나리오를 직접 테스트해 보면 다른 이유가 보인다. 고객이 이탈하는 것은 계좌 번호 입력이 번거로워서가 아니다. 계좌 번호를 입력하면 자신의 잔고가 노출될까 봐 불안해서이다. 특히 가족 공용 기기에서 접속한 고객, 또는 재정 상황이 좋지 않은 고객이 이 시점에서 이탈한다.

이것을 어떻게 알았느냐고? 상담사 연결 후 실제 고객과 대화한 기록을 읽었기 때문이다. “챗봇에서 계좌 번호 넣으라길래 그냥 끊었어요. 혹시 정보가 어디 남는 건 아닌지…” 이런 류의 피드백이 쌓여 있었다. 데이터 분석만으로는 절대 도달할 수 없는 인사이트다.

고객의 침묵 — 대화를 중단하는 행위 — 에도 맥락이 있다. 그리고 그 맥락은 숫자가 아니라 인간에 대한 이해에서 비롯된다. 사람들은 왜 불안해하는가, 무엇을 숨기고 싶어하는가, 어떤 상황에서 방어적이 되는가. 이런 질문에 답할 수 있는 것은 데이터가 아니라 공감이다.

사례 3: “안 되는 건 알지만 물어보는 겁니다”

금융 챗봇에 자주 들어오는 질문 유형이 있다. 규정상 불가능한 것을 알면서도 물어보는 고객이다. “해외 송금 한도를 올릴 수 있나요?”(규정상 불가), “대출 금리를 좀 깎아주실 수 없나요?”(챗봇에겐 권한 없음), “이미 처리된 거래를 취소할 수 있나요?”(원칙적 불가).

AI는 이런 질문에 규정을 안내한다. “현재 해외 송금 한도는 1일 XX만 원이며, 한도 변경은 영업점 방문이 필요합니다.” 정확한 답변이다. 하지만 고객의 80%는 이미 그걸 알고 있다.

그렇다면 왜 묻는가? 여러 이유가 있다.

혹시 예외가 있지 않을까 하는 마지막 희망.
“내가 노력했다”는 것을 스스로에게 증명하기 위해.
불만을 표현하는 우회적 방법. “안 되는 걸 왜 이렇게 만들었냐”는 의미.
진짜 원하는 건 다른 것인데, 어떻게 말해야 할지 몰라서 가장 가까운 질문을 던진 것.

사람 상담사라면 이 뉘앙스를 읽는다. “아, 송금을 급하게 하셔야 하는 상황이신가 봐요. 한도 변경은 어렵지만, 다른 방법이 있을 수 있는데 상황을 좀 더 말씀해 주시겠어요?” 이렇게 응대하면 고객의 진짜 니즈에 도달할 수 있다. 규정 안내는 정답이지만, 고객이 원하는 답은 아니었다.

왜 맥락은 데이터로 환원될 수 없는가

여기까지 읽으면 이런 반론이 나올 수 있다. “그 맥락들도 결국 데이터로 만들 수 있지 않나? 조직도, 인사 정보, 과거 이력, 감정 분석, 문화 코드… 다 수집해서 AI에게 넣어주면 되지 않나?”

이론적으로는 그렇다. 실무적으로는 불가능하다. 그 이유를 세 가지로 설명하겠다.

이유 1: 프레임 문제(Frame Problem)

AI 철학에서 오래된 문제 중 하나인 프레임 문제는 이렇다. 어떤 상황을 올바르게 이해하려면 관련 있는 정보와 관련 없는 정보를 구분해야 한다. 그런데 무엇이 관련 있는지를 판단하려면 이미 상황을 이해하고 있어야 한다.

앞에서 든 회의실 예시로 돌아가보자. 현업 담당자의 목소리가 떨린다는 사실이 프로젝트 요구사항 이해에 관련이 있는가? 보통은 아니다. 하지만 그 떨림이 “이 요구사항에 적지 못한 것이 있다”는 신호일 때는 결정적으로 관련이 있다. 그리고 그 판단은 떨림의 원인을 이미 짐작하고 있을 때만 가능하다.

맥락 정보를 데이터화하려면 “무엇이 맥락인가”를 먼저 정의해야 한다. 하지만 무엇이 맥락인지는 상황마다 달라진다. 어떤 상황에서는 발언자의 직급이 핵심 맥락이고, 다른 상황에서는 날씨가 핵심 맥락일 수 있다(날씨가 나빠서 고객 방문이 줄어 매출 보고서의 맥락이 바뀌는 식으로). 가능한 모든 맥락 요소를 미리 수집하는 것은 사실상 세상의 모든 정보를 수집하는 것과 같다.

이유 2: 관찰자 효과

맥락의 상당 부분은 관찰하려 하면 사라진다. 복도에서의 잡담, 회의 후 엘리베이터에서의 한마디, 점심 식사 중의 넋두리 — 이런 비공식 커뮤니케이션이 조직 맥락의 핵심인 경우가 많다. 그런데 이것을 기록하기 시작하면 사람들은 더 이상 솔직하게 말하지 않는다.

“모든 커뮤니케이션을 기록해서 AI에게 맥락으로 제공하겠다”는 발상은 원리적으로 자기 모순이다. 기록된다는 사실이 커뮤니케이션의 성격을 바꾸기 때문에, 기록된 것은 이미 원래의 맥락이 아니다.

이유 3: 무한 회귀

맥락을 데이터화해서 AI에게 주었다고 치자. AI가 그 맥락 데이터를 올바르게 해석하려면, 맥락 데이터의 맥락이 또 필요하다. “현업 담당자 A는 과거에 세 번 같은 패턴의 요청을 했고, 모두 실제 의도와 달랐다”는 정보를 주었다고 하자. AI는 이번에도 실제 의도와 다를 것이라고 추론할 수 있다. 하지만 이번에는 진짜 의도대로일 수도 있다. 그 판단은 A의 최근 태도 변화, 조직 내 역할 변화, 이번 프로젝트의 특수성 등 또 다른 맥락에 의존한다. 그리고 그 맥락도 또 다른 맥락이 필요하다.

이것이 무한 회귀다. 맥락은 언제나 더 넓은 맥락 안에 있고, 그 끝은 결국 “이 상황을 살아가는 인간으로서의 총체적 경험”에 도달한다. 그것을 데이터화한다는 것은 한 인간의 전 생애를 디지털화한다는 것이며, 그것은 기술적 도전이 아니라 존재론적 불가능이다.

그렇다면 AI는 맥락에 대해 정말 무력한가?

여기서 균형을 잡아야 한다. 나는 AI의 한계를 이야기하고 있지만, AI 무용론을 주장하는 것이 아니다. 5화에서 경고했듯 “AI가 시킨 대로 했어요”도 위험하지만, “AI는 맥락을 못 읽으니까 쓸모없어”도 똑같이 위험한 함정이다.

2026년의 AI는 맥락 처리에서 분명한 강점이 있다.

명시적 맥락의 체계적 관리: 수천 페이지의 문서, 과거 회의록, 이메일 아카이브를 정리하고 관련 정보를 뽑아내는 것은 AI가 사람보다 낫다. 명시적으로 기록된 맥락에 한해서는.
패턴 발견: 사람이 놓치는 통계적 패턴을 찾아낸다. “이 고객은 분기 말마다 같은 유형의 문의를 한다”는 패턴은 AI가 더 잘 잡는다.
일관성 유지: 사람은 피곤하면 맥락을 놓친다. 금요일 오후의 상담 품질은 월요일 아침보다 떨어진다. AI는 그렇지 않다.
맥락 프롬프팅: 사람이 읽어낸 맥락을 AI에게 명시적으로 알려주면, AI는 그 맥락 안에서 훌륭하게 작동한다. 3화에서 다뤘던 피드백 루프가 바로 이것이다.

핵심은 이것이다. AI는 맥락을 ‘읽지’ 못하지만, 사람이 읽어준 맥락을 ‘활용’하는 데는 탁월하다.

이것이 바로 휴먼 인 더 루프의 본질 중 하나다. 사람은 행간을 읽고, AI는 읽어낸 행간을 시스템에 적용한다. 6화에서 판단의 문제를 다뤘는데, 맥락을 읽는 것은 판단의 전제 조건이다. 올바른 판단은 올바른 맥락 파악 위에서만 가능하다.

맥락을 읽는 능력을 어떻게 키울 것인가

맥락 읽기가 AI에게 구조적으로 불가능한 인간 고유의 능력이라면, 그 능력을 키우는 것은 AI 시대의 핵심 경쟁력이 된다. 20년간의 경험에서 몇 가지를 정리해 본다.

첫째, 의도적으로 ‘왜’를 물어라

요구사항을 받으면 ‘무엇을’보다 ‘왜’를 먼저 물어라. “이 기능이 필요합니다” → “왜 이 기능이 필요하세요?” → “그 문제가 발생하는 상황이 구체적으로 어떤 건가요?” → “그 상황이 최근에 특히 자주 생기는 이유가 있나요?”

‘왜’를 세 번 연속으로 물으면 대개 진짜 맥락에 도달한다. 하지만 주의할 점이 있다. 심문하듯 물으면 안 된다. 상대방이 편하게 이야기할 수 있는 분위기를 만드는 것이 전제다. 7화에서 다뤘던 신뢰 자산이 여기서 작동한다. 신뢰가 없으면 ‘왜’라는 질문은 방어 본능을 자극할 뿐이다.

둘째, 비공식 채널을 소중히 하라

회의실에서 나오는 정보는 공식적이다. 즉, 걸러져 있다. 진짜 맥락은 비공식 공간에서 흐른다. 복도 대화, 점심 식사, 커피 타임, 퇴근길 동행. AI가 절대 접근할 수 없는 이 채널들을 의식적으로 유지하라.

재택근무가 늘면서 이 비공식 채널이 크게 약화됐다. 이것은 단순히 ‘소통이 줄었다’는 문제가 아니다. 맥락 정보의 유통 경로가 막힌 것이다. 원격 환경에서 일하더라도 의도적으로 비공식 대화의 기회를 만들어야 한다. 업무 외 잡담 채널, 가벼운 화상 커피챗, 주간 점심 모임. 이런 것들이 단순한 복지가 아니라 조직의 맥락 인프라라는 인식이 필요하다.

셋째, 다양한 직군과 교류하라

같은 직군끼리만 어울리면 맥락 읽기 근육이 퇴화한다. 개발자끼리는 이미 공유된 맥락이 많기 때문에 행간을 읽을 필요가 적다. 현업, 기획, 디자인, 법무, 컴플라이언스, 영업 등 다른 직군과 교류할 때 맥락 읽기 능력이 훈련된다.

그들의 언어, 우선순위, 걱정거리, 성공의 기준이 개발자와 다르다는 것을 체감하는 것이 중요하다. “아, 이 사람이 ‘빠르게’라고 할 때 내가 생각하는 ‘빠르게’와 다르구나”를 깨닫는 순간, 맥락 읽기의 첫 단추가 채워진다.

넷째, 실패 사례를 기록하라

맥락을 못 읽어서 실패한 경험을 기록해두면 강력한 학습 자료가 된다. “이때 내가 놓친 맥락은 무엇이었나?” “어떤 신호를 무시했나?” “사전에 알 수 있었던 맥락인가, 아니면 원천적으로 알 수 없었던 것인가?”

나는 개인적으로 ‘맥락 실패 일지’를 몇 년째 쓰고 있다. 거창한 것이 아니라, 프로젝트나 회의에서 “아, 이걸 미리 알았으면”이라고 느낀 순간을 간단히 메모하는 것이다. 돌아보면 패턴이 보인다. 내가 유독 못 읽는 맥락의 종류가 있고, 잘 읽는 종류가 있다. 그 자기 인식이 능력 향상의 출발점이다.

다섯째, AI를 맥락 탐색의 보조 도구로 활용하라

역설적으로, AI는 맥락을 읽는 데 간접적으로 도움이 된다. AI에게 명시적 정보 처리를 맡기면, 인간은 암묵적 맥락에 더 집중할 여유가 생긴다.

예를 들어, 회의 전에 AI에게 관련 문서를 요약시키고, 참석자들의 최근 이메일과 보고서에서 자주 등장하는 키워드를 뽑아달라고 하면, 회의에서 나는 문서 내용을 따라가느라 에너지를 쓰는 대신 참석자들의 반응과 분위기를 읽는 데 집중할 수 있다. AI가 ‘글자’를 담당하고, 사람이 ‘행간’을 담당하는 것이다.

또한 AI에게 “이 요구사항에서 빠져있을 수 있는 것은 무엇인가?”라고 물어볼 수 있다. AI는 진짜 맥락을 읽지는 못하지만, 논리적으로 빠져있는 부분을 지적하는 것은 잘한다. 그 빈 곳을 힌트로 삼아 사람이 맥락을 추적하면 효율적이다.

맥락과 책임 — 왜 행간을 읽는 것이 윤리적 의무인가

맥락 읽기를 단순한 업무 스킬로 치부하면 절반만 이해한 것이다. 나는 맥락을 읽는 것이 윤리적 책임이기도 하다고 생각한다.

5화에서 “AI가 시킨 대로 했어요”의 위험성을 이야기했다. AI의 출력을 검증 없이 수용하는 것이 왜 무책임한지를 다뤘다. 맥락은 그 검증의 핵심 도구다. AI의 답변이 기술적으로 정확한지를 검증하는 것은 비교적 쉽다. 하지만 그 답변이 이 상황에서 적절한지를 검증하려면 맥락이 필요하다.

금융 분야에서 맥락 실패는 단순한 불편이 아니라 실질적 피해로 이어진다. 규정상 가능하지만 고객의 상황을 고려하면 권하지 않아야 할 상품이 있다. 기술적으로 구현 가능하지만 지금 시점에 배포하면 감독기관의 우려를 살 기능이 있다. 데이터 분석 결과가 통계적으로 유의미하지만 표본의 특수한 사정을 고려하면 왜곡된 해석일 수 있는 보고서가 있다.

이 모든 상황에서 맥락 없이 기술적 정답만을 따르면, 결과적으로 누군가에게 해가 된다. 맥락을 읽지 않는 것은, 자신의 판단 책임을 기술적 정확성 뒤에 숨기는 것이다.

4화에서 AI가 끝맺지 못하는 일의 정체를 다뤘다. 그것은 결국 ‘상황의 총체적 이해 위에서 내리는 최종 판단’이었다. 맥락 읽기는 그 총체적 이해를 가능하게 하는 능력이다. AI가 끝맺지 못하는 일을 사람이 끝맺으려면, 행간을 읽을 수 있어야 한다.

현장의 맥락 패턴 — 20년 경험에서 뽑은 체크리스트

추상적인 이야기를 마무리하고, 실무에서 바로 써먹을 수 있는 맥락 읽기 체크리스트를 공유한다. 완벽한 목록은 아니지만, 나에게는 수없이 도움이 됐다.

요구사항을 받았을 때

발신자의 맥락: 이 요청을 보낸 사람의 현재 상황은 어떤가? 최근 승진/이동/평가가 있었나? 이 요청이 그 사람에게 어떤 의미인가?
타이밍의 맥락: 왜 하필 지금 이 요청이 왔는가? 분기 초인가, 말인가? 감사 시즌인가? 인사 시즌인가? 최근 장애가 있었나?
빠진 것의 맥락: 이 요구사항에 당연히 있어야 할 항목이 빠져 있다면 왜인가? 의도적 누락인가, 단순 실수인가?
우선순위의 맥락: “급합니다”는 얼마나 급한가? 이 사람이 평소에도 모든 것을 급하다고 하는 사람인가, 아니면 정말 급할 때만 그렇게 말하는 사람인가?
정치의 맥락: 이 요청의 배후에 다른 이해관계자가 있는가? 이 요청이 수용되면 누가 이익을 보고 누가 불이익을 받는가?

회의/대화 중에

말하지 않은 것: 이 자리에서 누가 한 번도 발언하지 않았는가? 특정 주제가 의도적으로 피해지고 있지는 않은가?
비언어적 신호: 표정, 자세, 시선, 호흡의 변화. 특히 특정 주제에서 갑자기 태도가 바뀌는 사람에 주목.
합의의 질: 모두가 “좋습니다”라고 했는가? 진짜 동의인가, 침묵의 동의인가? “반대 의견 없으시죠?”로 끝난 합의는 합의가 아니다.
에너지의 흐름: 특정 안건에서 참석자들의 에너지가 높아지는가, 떨어지는가? 에너지가 떨어지는 안건은 이미 결론이 나 있는 것이거나, 모두가 피하고 싶은 것이다.

AI 출력을 검토할 때

정확성 vs 적절성: 이 답변은 맞는가? (기술적 검증) → 이 답변은 지금 이 상황에서 적절한가? (맥락적 검증)
수신자의 맥락: 이 답변을 받을 사람은 어떤 상태인가? 이 답변이 그 사람에게 어떻게 읽힐 것인가?
타이밍의 맥락: 이 답변을 지금 전달하는 것이 적절한가? 같은 내용이라도 다른 시점에 전달하는 것이 나을 수 있다.
빠진 맥락 주입: AI가 모르는 맥락 중 이 답변의 질을 결정적으로 바꿀 수 있는 것이 있는가? 있다면 프롬프트에 추가해서 재요청하라.

맥락과 기술의 진화 — 낙관도 비관도 아닌 현실

AI 기술은 계속 발전한다. 멀티모달 AI는 텍스트뿐 아니라 이미지, 음성, 영상까지 처리한다. 감정 인식 기술은 표정과 음성 톤에서 감정을 추론한다. 에이전트 AI는 여러 도구를 조합해 복잡한 작업을 수행한다. 이런 발전이 맥락 읽기 능력을 향상시킬 가능성은 있는가?

부분적으로는 그렇다. AI가 처리할 수 있는 맥락의 범위는 분명 넓어지고 있다. 회의 영상을 분석해 참석자의 감정 변화를 추적하고, 수년간의 조직 커뮤니케이션 데이터를 학습해 암묵적 의미 패턴을 발견하고, 실시간으로 관련 배경 정보를 제공하는 것은 기술적으로 가능해지고 있다.

하지만 앞에서 논의한 세 가지 근본적 한계 — 프레임 문제, 관찰자 효과, 무한 회귀 — 는 기술 발전으로 해소되는 종류가 아니다. 이것들은 “명시적으로 표현되지 않은 의미를 이해한다”는 과제의 본질적 특성이다. 처리 능력이 아무리 좋아져도, 입력되지 않은 것을 입력으로 바꾸는 문제는 그대로 남는다.

나의 현실적 전망은 이렇다. AI의 맥락 처리 능력은 계속 향상될 것이다. 인간이 읽어야 하는 맥락의 양은 줄어들 것이다. 하지만 남아있는 맥락의 중요도는 기하급수적으로 높아질 것이다. AI가 쉬운 맥락을 처리해줄수록, 사람에게 남는 것은 정말 어렵고 결정적인 맥락뿐이다.

이것은 1화에서 다뤘던 “AI 도입 1년 후 더 바빠진 이유”와 연결된다. AI가 단순 업무를 처리해주면서 사람의 업무 총량은 줄었지만, 남은 업무의 난이도와 밀도는 높아졌다. 맥락 읽기도 마찬가지다. AI가 명시적 맥락을 담당하면서 사람이 읽어야 할 암묵적 맥락의 비중과 중요도가 높아지는 것이다.

기계가 읽을 수 없는 것을 읽는 사람

글을 마무리하며, 하나의 장면을 이야기하고 싶다.

얼마 전 시스템 장애가 발생했다. 새벽 3시. 자동 알림이 왔고, AI 기반 모니터링 시스템은 즉시 원인을 분석했다. “디스크 I/O 병목. 특정 배치 작업의 쿼리 실행 시간이 임계치를 초과.” 기술적 분석은 정확했고, 자동 복구 스크립트가 실행되어 30분 만에 서비스가 정상화됐다.

하지만 나는 한 가지가 걸렸다. 그 배치 작업은 6개월째 아무 문제 없이 돌아가던 것이었다. 왜 갑자기? AI 분석은 “데이터 증가에 따른 점진적 성능 저하”라고 결론 내렸다. 합리적인 설명이다.

나는 다른 것을 떠올렸다. 지난주에 현업 부서에서 “소소한 데이터 정리”를 했다고 들은 게 있었다. 점심 시간에 지나가는 말로 들은 것이다. 문서 어디에도 기록되지 않았다. 조사해 보니 그 “소소한 정리”가 특정 테이블에 대량의 임시 데이터를 생성해놓고 삭제하지 않은 것이었다. 그게 배치 작업의 스캔 범위를 넓혀 I/O 병목을 유발한 진짜 원인이었다.

AI는 “디스크 I/O 병목”이라는 기술적 진단을 정확하게 했다. 하지만 “왜 지금 이 병목이 생겼는가”의 진짜 원인은 복도에서 주워들은 한마디에 있었다. 기계가 읽을 수 없는 곳에 답이 있었던 것이다.

이것이 맥락이다. 문서에 적히지 않고, 데이터로 수집되지 않고, 프롬프트에 입력할 수 없는 것. 하지만 상황의 진실을 가리키는 것. 행간에 있는 것을 읽는 능력. 그것은 AI가 영원히 대신할 수 없는, 인간만의 자산이다.

AI 시대에 “나는 어떤 가치를 가지고 있는가?”라는 질문을 스스로에게 던진다면, 이렇게 답해보라. “나는 기계가 읽을 수 없는 것을 읽을 수 있다.” 그리고 그 능력을 의식적으로, 끊임없이 키워라. 그것이 AI와 함께 일하는 시대에 사람으로서 살아남는 방법이다.

다음 9화에서는 ‘공감’을 다룬다. 맥락이 “상황을 이해하는 능력”이라면, 공감은 “사람을 이해하는 능력”이다. AI가 감정을 시뮬레이션하는 시대에, 진짜 공감이란 무엇이며, 그것이 왜 기술적으로 모방할 수 없는 것인지를 이야기하겠다.

이번 주 한 줄 노트: 오늘 누군가의 말에서 ‘적히지 않은 의미’를 하나만 읽어보세요. 그게 맥락 근육의 시작입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.

📚 시리즈: 휴먼 인 더 루프(Human-in-the-Loop): AI 시대, 사람만 할 수 있는 일 (총 12화 중 8화)
◀ 이전 7화 (다음 차수는 아직 게시되지 않았습니다)

[태그:] 암묵지

[휴먼 인 더 루프(Human-in-the-Loop): AI 시대, 사람만 할 수 있는 일] 8/12화: AI가 영원히 못 읽는 행간, 맥락이라는 인간의 무기