
솔직히 고백하겠습니다.
저도 창업 초기에는 '배포' 버튼을 누르는 게 공포였습니다.
금요일 오후 5시에 핫픽스를 내보냈다가 주말 내내 서버실(사실은 제 방)에서 밤샌 기억, 다들 한 번쯤 있으시죠?
그런데 최근 미국에서 '국가 차원의 배포 실수'라고 부를 만한 사건이 터졌습니다.
소프트웨어 버그가 아닙니다.
무려 법률(Law)에 버그가 심어진 채로 통과된 겁니다.
미국 노스다코타 주에서 벌어진 일인데요.
내용을 들여다보면 개발자인 우리에게 너무나 익숙한 '더미 데이터(Dummy Data)' 사고와 판박이입니다.
사건의 전말은 이렇습니다.
노스다코타 주 의회가 핵심 광물 개발을 지원하는 법안을 통과시켰습니다.
법안에는 지원 대상이 되는 광물 목록이 쭉 나열되어 있었죠.
리튬, 코발트, 니켈 같은 진짜 희토류들 사이에 이상한 이름 두 개가 섞여 있었습니다.
바로 '프리지엄(Friezium)'과 '스트랠리엄(Stralium)'입니다.
화학 주기율표를 아무리 뒤져봐도 이런 원소는 없습니다.
완벽한 가짜입니다.
알고 보니 이 이름들의 정체가 더 황당합니다.
해당 법안과 관련된 석탄 회사 변호사들의 이름에서 따온 겁니다.
변호사 이름이 'Al Friez'와 'David Straley'였거든요.
마치 개발자가 테스트 코드 짤 때 변수명에 자기 이름이나 test_123을 넣은 것과 똑같습니다.
문제는 이 장난(혹은 실수)이 실제 법적 효력을 가진 문서로 확정될 때까지 아무도 몰랐다는 겁니다.
staging 환경에만 있어야 할 데이터가 production까지 라이브로 나간 셈입니다.
변호사들은 "우리가 넣은 게 아니다"라고 부인했습니다.
하지만 누군가는 법안 초안을 작성하면서 이 가짜 단어들을 '플레이스홀더(Placeholder)'처럼 넣어뒀을 겁니다.
그리고 수많은 검토 과정, 위원회 심사, 본회의 투표를 거치는 동안...
그 누구도 이 단어들을 검증하지 않았습니다.
B2B SaaS를 운영하는 제 입장에서 이 뉴스는 남 일 같지 않았습니다.
우리 조직에서도 매일 벌어질 수 있는 일이기 때문입니다.
우리는 흔히 '전문가'나 '시스템'을 맹신하는 경향이 있습니다.
"법안 작성자가 알아서 잘 썼겠지."
"시니어 개발자가 짠 코드니까 문제없겠지."
"기획팀에서 확인했으니 스펙대로 구현만 하면 되겠지."
이런 안일한 믿음이 '프리지엄' 사태를 만듭니다.
노스다코타 의원들도 수백 페이지짜리 법안을 꼼꼼히 읽지 않았을 겁니다.
그냥 '스캔(Scan)'만 했을 가능성이 큽니다.
우리가 PR(Pull Request) 리뷰할 때 코드 로직을 깊게 안 보고 변수명 스타일만 지적하는 것과 비슷합니다.
저는 이 사건을 보며 팀원들에게 이렇게 강조했습니다.
"사람은 누구나 실수를 한다. 하지만 프로세스는 그 실수를 걸러내야 한다."
법안에 가짜 광물이 들어간 건 개인의 실수일 수 있습니다.
하지만 그게 법으로 공포될 때까지 걸러지지 않은 건 시스템의 실패입니다.
저희 회사에서는 이런 일을 방지하기 위해 몇 가지 원칙을 세웠습니다.
첫째, 크로스 체크(Cross-Check)의 의무화입니다.
기획자가 쓴 문서는 개발자가, 개발자가 짠 코드는 QA가, 마케터가 쓴 카피는 디자이너가 봅니다.
서로 다른 관점을 가진 사람이 봐야 '당연하다고 착각하는 오류'가 보입니다.
둘째, '더미 데이터'의 엄격한 관리입니다.
테스트용이라도 'asdf'나 욕설, 장난스러운 텍스트는 절대 금지합니다.
언제든 실수로 노출될 수 있다는 가정 하에, 테스트 데이터도 실제 데이터처럼 그럴싸하게(Realistic) 만듭니다.
만약 노스다코타 법안 초안에 'Stralium' 대신 'Unobtanium(영화 아바타에 나오는 가상의 광물)'이라고 적혀 있었다면?
누군가는 눈치챘을지도 모릅니다.
너무 그럴싸한 변호사 이름을 섞어놓으니 '전문 용어겠거니' 하고 넘어간 것이죠.

비즈니스 현장에서는 사소한 '오타' 하나가 치명적인 신뢰 하락으로 이어집니다.
고객은 우리의 화려한 기술 스택보다, 눈에 보이는 텍스트 한 줄, UI 디테일 하나로 우리를 평가합니다.
법률조차 이렇게 허술하게 통과되는 세상입니다.
하지만 우리는 고객의 데이터를 다루는 SaaS 기업입니다.
법을 만드는 의회보다 더 꼼꼼하고 엄격해야 합니다.
오늘 배포 예정인 기능이 있다면, 다시 한번 살펴보세요.
혹시 여러분의 코드 속에, 기획서 속에 '프리지엄'이 숨어 있지는 않은가요?
단순한 실수가 아니라, 우리의 프로페셔널리즘을 증명하는 문제입니다.


