AI가 내린 답보다 ‘버린 답’을 봐야 하는 이유
ChatGPT와 한 시간 동안 만든 답이 질문 한 번 고치자 사라졌다. 편집하는 순간 대화가 갈라졌고, 이전 경로는 어딘가에 묻혔다. 이건 사소한 UI 불편이 아니다. 중요한 판단을 다시 검토하려면 최종 답보다 버려진 분기와 재실행 경로가 필요하다.
TL;DR
- AI 제품은 선형 채팅보다 분기 그래프에 가깝다.
- 세션 메모리는 검색이 아니라 상태 계층이다.
- replay, provenance, branch view는 고급 기능이 아니라 신뢰 기본값이다.
- 다만 모든 분기를 한 번에 보여주면 안 된다. 인지부하를 낮추는 단계적 공개가 같이 필요하다.
문제: AI는 답을 잘하는데, 우리는 왜 여전히 불안한가
모델은 이제 충분히 똑똑하다. GPT든 Claude든 Gemini든, 웬만한 질문엔 웬만한 답을 준다. 그런데 이상하게도 AI를 쓸수록 질문이 늘어난다.
- 방금 그 답은 어디서 나왔나?
- 아까 그 버전이 더 나았는데 돌아갈 수 있나?
- 다음 주에 다시 열면 이 맥락 기억하나?
이 질문들의 공통점은 하나다. 전부 답변의 품질이 아니라 작업의 구조를 묻고 있다. 답이 좋은 건 이제 당연하고, 문제는 그 답에 이르는 길이 보이지 않는다는 것이다.
내비게이션이 목적지만 띄워주고 경로를 안 보여준다면 아무도 믿고 따라가지 않을 것이다. 지금 많은 AI 제품이 딱 그렇다.
원인: 대화는 선(線)이 아니라 나무(木)인데, 화면은 선만 보여준다
개발자라면 Git 브랜치를 떠올리면 된다. 코드에 브랜치를 만들고, 실험하고, 아니다 싶으면 원래 가지로 돌아온다. 버린 브랜치도 남아 있어서 언제든 다시 볼 수 있다.
AI 대화도 실제로는 이미 이렇게 작동한다. 메시지를 편집할 때마다 새 가지가 생긴다. 다만 제품이 그걸 숨길 뿐이다. Branch of Thought라는 브라우저 확장이 이 숨은 가지들을 그래프로 그려주는데, 처음 보면 놀랍다. 한 시간짜리 대화가 사실은 다섯 갈래, 여섯 갈래의 나무였다는 걸 눈으로 확인하게 되기 때문이다.
가지가 보이면 세 가지가 달라진다.
- 어떤 답이 버려졌는지 알 수 있다.
- 지금 내가 어느 가지에 서 있는지 알 수 있다.
- 언제든 갈림길로 돌아갈 수 있다.
이건 히스토리 보기가 아니라 의사결정의 지도다.
메모리: 세션이 끊기면 에이전트는 다시 1페이지부터 읽는다
메모리도 마찬가지다. 세션이 끊기면 에이전트는 같은 파일을 다시 찾고, 같은 결정을 다시 내리고, 같은 실수를 다시 한다. 어제 읽던 책을 오늘 다시 1페이지부터 읽는 셈이다.
필요한 건 책 전체를 통째로 외우는 기억력이 아니다. 책갈피다. 무엇을 기억하고, 무엇을 버리고, 다음에 어디서부터 시작할지를 정해둔 얇은 상태 계층이 더 중요하다.
이제 중요한 건 “얼마나 많이 저장하느냐”가 아니다. “다음 세션에 필요한 만큼만 정확히 남기느냐”다.
즉, 메모리는 기능이 아니라 작업 시스템의 상태다.
방향: 챗봇이 아니라 작업대(워크벤치)
이 변화를 한 문장으로 줄이면 이렇다. AI 제품은 대화창이 아니라 작업대가 되어가고 있다.
목수의 작업대를 떠올려보자. 완성된 의자만 놓여 있는 게 아니다. 도면이 있고, 잘라낸 조각이 있고, 실패한 이음새가 있고, 쓰던 공구가 그대로 있다. 그래서 내일 와서도 이어서 일할 수 있고, 남이 봐도 “아, 이렇게 만들었구나”를 알 수 있다.
Claude Science 같은 최근 제품들이 이 방향을 보여준다. 답만 던지는 게 아니라 실행한 코드, 쓴 데이터, 중간 결과를 함께 보존한다. 나중에 다시 돌리고(replay), 출처를 확인하고(provenance), 수정할 수 있다.
요리로 치면, 완성된 요리 사진만 주는 게 아니라 레시피를 함께 주는 것이다. 레시피가 있어야 다시 만들 수 있고, 어디서 맛이 틀어졌는지 찾을 수 있다.
함정: 그렇다고 다 펼쳐놓으면 지옥이 된다
여기서 반론이 나온다. “좋아, 그럼 분기 그래프랑 로그를 전부 화면에 띄우면 되겠네?”
절대 아니다. 목수의 작업대가 유용한 건 정리되어 있기 때문이다. 톱밥까지 쌓아두면 그건 작업대가 아니라 쓰레기장이다.
사람은 긴 로그보다 알아볼 수 있는 경로를 따라간다. 히스토리는 많을수록 좋은 게 아니라 필요할 때 열리는 구조일 때 좋다. 그래서 답은 단계적 공개다. 평소엔 깨끗한 결과 화면, 궁금하면 한 번의 클릭으로 열리는 경로와 이력.
프라이버시 문제도 있다. 모든 걸 기억하는 AI는 모든 걸 유출할 수 있는 AI다. 간단한 계산기에 분기 그래프를 붙이는 건 과잉 설계다. 원칙은 하나다.
많이 저장하지 말고, 명시적으로 관리할 것만 저장하라.
실전 활용 팁: 분기와 메모리를 작업 표면으로 만드는 법
이 신호를 AI 제품, 도구, 글쓰기, 운영 전반으로 옮기면 꽤 단순하다.
- 결과만 보여주지 말고 branch / replay / provenance를 노출하라.
- 메모리는 길게 쌓지 말고 scoped state로 관리하라.
- 작업 결과에는 input / run / output / replay / provenance를 붙여라.
- 다음 세션으로 이어질 최소 기억만 남기고 나머지는 버려라.
- “AI가 뭘 했는지”보다 사람이 다시 돌아올 수 있는지를 기준으로 설계하라.
- 모든 걸 한 번에 보여주지 말고 progressive disclosure로 인지부하를 관리하라.
이렇게 해야 제품도, 문서도, 블로그도 단순한 결과물이 아니라 다시 쓰이고 다시 읽히는 작업 환경이 된다.
바로 해볼 실험
오늘 당장 할 수 있는 실험은 작지만 효과가 크다.
- 다음 유틸 하나를 고른다.
- 결과 화면에
input / branch / output / replay / provenance를 넣는다. - 최근 버전과 버려진 버전을 최소 1개씩 남긴다.
- 같은 작업을 한 번 더 실행해서 경로가 어떻게 달라지는지 본다.
- 필요할 때만 세부 로그가 열리도록 토글을 둔다.
중요한 건 속도가 아니라 되돌아갈 수 있느냐다.
리스크 / 반론
물론 모든 제품이 거대한 분기 그래프가 되어야 하는 건 아니다.
- 히스토리가 너무 많으면 UI가 지저분해질 수 있다.
- 세션 메모리는 프라이버시와 권한 문제를 만든다.
- 모든 분기를 저장하면 오히려 탐색 비용이 커진다.
- 간단한 계산기나 변환기에는 과한 설계일 수 있다.
그래서 핵심은 “많이 저장”이 아니라 명시적으로 관리할 것만 저장하는 것이다.
즉, 분기와 메모리를 숨기지 말되, 통제 가능하게 만들어야 한다.
결론
AI 제품의 경쟁은 이제 모델 이름 싸움만으로 끝나지 않는다. 모델은 점점 비슷해지고, 차이는 분기와 메모리, replay와 provenance, boundary와 인지부하 관리, 그리고 사용자가 다시 돌아올 수 있느냐에서 난다.
좋은 제품과 좋은 글은 정답을 보여주는 데서 끝나지 않는다. 사람이 다음 판단을 할 수 있게 길을 남긴다.