원본 데이터 보호 원칙 (수정중)
dev 데이터 사본을 만들어 그 위에서만 작업·동기화할 수 있다.1. 아찔했던 사고 · 시트 10개 분량이 사라졌다
2026-07-07 데일리에서 정요천 총괄이 트랜스링크 인베스트먼트 분기 영업보고서 자동화 시스템을 직접 시연하며 꺼낸 이야기다.
Claude Code 에 이것저것 수정을 시키던 중, 영업보고 총괄 시트에서 회사 작성 시트 약 10개 분량의 데이터가 사라졌다. 원인은 끝내 정확히 못 짚었고, 그 순간 "이제 끝났다" 싶을 만큼 등줄에 땀이 났다고 한다. 다행히 구글 스프레드시트의 버전 관리로 복구했다 · 만약 엑셀 파일이었으면 복구 자체가 불가능했다.
핵심은 이거다. 고객 데이터는 회사의 가장 큰 자산이다. A16Z(안드레센 호로위츠)가 말하는 AI 서비스의 두 해자(moat) · ① 고객 워크플로우에 깊숙이 박히는 것, ② 고객의 독점 데이터에 접근하는 것 · 을 FDE 는 동시에 쥔다. 그만큼, 그 데이터를 훼손하면 코드 에러와는 차원이 다른, 돌이킬 수 없는 사고가 된다.
"한번 그 경험을 하고 나면 다시 예전으로는 절대 못 돌아가요. 그래서 무조건 이게 업데이트가 되어야 되고, 자기들은 무조건 이걸 써야 되는 거지." · 정요천 (락인 효과에 대해)
2. 우리가 실제로 만지는 데이터가 어떤 것인지 보자
말로 "고객 데이터"라고 하면 와닿지 않는다. 사고가 난 그 시트를 직접 보자. 아래는 시연에 쓰인 트랜스링크 영업보고 총괄 시트다 (회사명·심사역·링크·재무수치는 마스킹했다 · 이 강의의 원칙을 이 강의부터 지킨다).
포트폴리오사(피투자기업)별로 어떤 서류를 받았는지 추적하는 화면이다. 재무상태표·손익계산서·주주명부·등기부등본·4대보험 가입자증명 · 82개사에서 분기마다 받아야 하는 제출 서류가 열로 늘어서 있고, 기업별로 ○/×/△ 로 수취 현황이 관리된다.
같은 시트를 오른쪽으로 스크롤하면 재무 데이터 본체가 나온다. 매출액·영업손익·당기순손익(연도별), 4대보험 가입자 수, 총발행주식수, 유상증자 여부 · 전부 포트폴리오사의 독점 재무 데이터다.
이게 "회사의 가장 큰 자산"의 실체다. 82개사 × 수십 개 재무 항목이 한 시트에 모여 있고, Claude Code 는 이 시트에 쓰기 권한을 가진 채 작업한다. 시트 하나가 날아가면 그냥 날아간다.
3. 왜 실수가 나는가 · 구조적인 함정
이건 "조심성이 부족해서" 나는 사고가 아니다. 개발 흐름 자체에 함정이 있다.
- 개발 초기엔 더미 데이터로 자유롭게 작업한다. 여기선 뭘 지워도 괜찮다.
- 첫 프로덕션 릴리즈 이후부터가 문제다. 신규 기능 개발에 필요한 데이터가 프로덕션(=고객 실데이터)에만 존재하는 상황이 반드시 생긴다.
- 이때 "옮기기 귀찮다"는 이유로 프로덕션에서 직접 작업하게 되는 것이 사고의 근원이다.
정요천 총괄은 과거 경기콘텐츠진흥원 프로젝트에서도 같은 일이 있었다고 했다. 지금은 Claude 에게 DB 복사를 시킬 수 있지만, 예전엔 SCP 로 접속해 프로덕션 설정을 풀고 특정 IP 제한을 해제한 뒤 데이터를 옮겨야 했다. 그 과정에서 프로덕션 DB 를 날릴까 두려워, 결국 프로덕션에서 직접 작업하는 악순환이 반복됐다.
트랜스링크 사고도 같은 뿌리다 · Claude Code 가 고객의 구글 드라이브(원본)에 연결된 채로 수정을 하다가, 원본 시트가 날아간 것이다.
4. 원칙 · 원본은 건드리지 않고, dev 데이터 사본 위에서 개발한다
해결책은 단순하고, 철칙이다.
- 원본 데이터를 직접 조작하지 않는다. Claude Code 를 고객 원본에 연결한 채 개발하지 않는다.
- 프로젝트 드라이브에
dev 데이터폴더를 만들고, 원본의 사본을 그대로 복사해 넣는다. - 개발이 진행될 때마다 사본을 원본과 동기화한다. 데이터가 82개로 많더라도 반드시 사본을 만든다.
트랜스링크 실사례. 사본을 만들 때 함정이 하나 있다.
사본 시트 안의 링크들(§2 스크린샷의 투자기업 시트 링크·드라이브 링크 열)이 여전히 원본 드라이브를 가리키고 있었다.
사본을 만들어도 링크가 원본을 가리키면, 그 링크를 타고 들어가 결국 원본을 건드리게 된다.
그래서 회의 전날, Claude Code 로 사본 안의 링크들을 전부 사본 링크로 일괄 교체하는 작업을 테스트했다 (§4 도식의 "링크도 사본으로 교체").
실제로 시연 폴더는 이렇게 나뉘어 있었다 · 원본과 사본을 폴더 단위로 분리해 둔 것이다.
테스트 폴더/·…영업보고회 총괄 원본.xlsx,…영업보고회 총괄 사본.xlsxdev data/·…영업보고회 총괄.xlsx(개발용 사본)
"무조건 사본 만들어가지고 데브 데이터 반드시 관리하시고, 반드시 업데이트를 계속 하셔야 돼요. 이거는 무조건 철칙이에요." · 정요천
5. 안전망은 원칙을 대신하지 못한다
이번엔 스프레드시트 버전 관리로 살았다. 하지만 그건 운이었지 대비책이 아니다.
- 구글 스프레드시트는 버전 관리가 있어 복구 여지가 있다. 엑셀 파일은 그마저 없어 날리면 끝이다.
- 신스타프레젠트 사례처럼 메일로 파일이 오가는 구조라면 원본이 고객사에 남아 상대적으로 안전하다. 하지만 우리가 드라이브·DB 에 직접 연결해 작업하는 시스템은 그 안전망이 없다.
그래서 순서가 중요하다. 버전 관리·백업은 마지막 그물이고, 1차 방어선은 "원본을 안 건드리고 dev 사본에서 개발한다"는 원칙이다. 그물을 믿고 외줄을 타지 않는다.
오늘 정리 + 다음
- 정리: 고객 실데이터 = 회사의 가장 큰 자산. Claude Code 는 그 데이터에 쓰기 권한을 가진 채 작업하므로, 원본을 직접 건드리지 말고 프로젝트 드라이브의
dev 데이터사본 위에서 개발하고, 개발 내내 동기화한다. 사본 안의 링크가 원본을 가리키지 않게 링크까지 사본으로 교체한다. - 흔한 함정: 첫 프로덕션 릴리즈 직후, "이 데이터는 프로덕션에만 있는데 옮기기 귀찮으니 그냥 여기서…" 하는 순간이 사고의 문턱이다. 그 유혹이 오면 그때가 바로 dev 사본을 만들 때다.
- 다음 시간: 에이전트가 위험한 작업(원본 조작·삭제·외부 발송)을 하기 전에 사람이 확인하도록 강제하는 장치 · L13(hooks)·L28(실행-직전 가드)과 이어진다.
- 자습 권장: 내가 지금 맡은 프로젝트에서 Claude Code 가 쓰기 권한으로 닿는 원본 데이터가 무엇인지, 그 사본이 프로젝트 드라이브에 있는지 각자 점검해 보자.