그날의 작은 사건
퍼피즈(자동화 봇 중 하나)가 주문서를 처리하는 데 갑자기 실패하기 시작했다. 같은 데이터인데 간헐적으로 오류가 났다. 처음엔 구글 시트의 API 연결 문제라고 생각했지만, 원인은 완전히 달랐다.
윈도우 디바이스의 구글 시트에서 특정 열(컬럼)을 '숨김' 처리해놨는데, Claude Code가 그 열의 존재를 인식하지 못했던 것이다.
왜 이런 일이 생겼나
구글 시트 API는 숨겨진 열도 데이터로 반환한다. 하지만 Claude Code가 시트를 읽을 때 숨겨진 구간을 건너뛰거나 부정확하게 해석했다. 결국 우리가 의도한 데이터 구조와 에이전트가 받은 구조가 달랐다.
[보이는 데이터]
A열(고객명) → B열(이메일) → C열(금액)
[실제 시트 구조]
A열(고객명) → B열(숨김) → C열(숨김) → D열(이메일) → E열(금액)
우리가 배운 세 가지
**1. 자동화 설계는 시각적 상태가 아닌 데이터 구조를 기준으로 해야 한다**
사람이 보기 편하다고 열을 숨기면, AI는 혼동한다. 열 숨김은 인간의 편의이지, 데이터 자동화의 약속이 아니다.
**2. 깔끔함이 함정이 될 수 있다**
우리는 "더 보기 좋으니까" 중간 계산 열들을 숨겼다. 하지만 이것이 자동화 봇의 신뢰도를 깎아먹었다.
**3. Claude Code의 로그를 읽는 것이 가장 빠른 디버깅이다**
Claude Code가 실제로 어떤 데이터를 읽었는지 확인하는 순간, 원인이 명확해졌다.
이후의 변화
이제 우리는 중요한 정보는 절대 숨기지 않는다. 대신 시트를 두 개로 나눴다.
• 워킹 시트(Working Sheet): 모든 열이 보인다. 에이전트는 여기만 읽는다.
• 디스플레이 시트(Display Sheet): 사용자가 보기 좋게 정렬된 버전. 사람만 본다.
같은 구글 계정, 같은 워크북 안에서 이 분리만으로도 버그가 90% 줄었다.
작은 결론
AI를 쓸 때는 "내가 보는 화면"과 "AI가 읽는 데이터"가 같다고 절대 가정하면 안 된다. 숨겨진 것은 숨겨진 대로 문제를 만든다.