
테스트는 모두 통과했지만, 실제로는 조립되지 않는다 — 제조업 설계자가 Claude Code 개발에 도입한 검사 패턴
요약
제조업 설계의 '공차 누적' 개념을 AI 개발에 접목하여, 단위 테스트가 통과하더라도 실제 환경에서 작동하지 않는 문제를 방지하는 검사 패턴을 제안합니다.
핵심 포인트
- 단위 테스트 통과가 전체 시스템의 정상 작동을 보장하지 않음
- 일본어 정규표현식 기반 로컬라이제이션 사례를 통한 테스트 사각지대 경고
- 제조업의 공차 누적(Tolerance Stack-up) 개념을 소프트웨어 검증에 적용
- 검사 범위 밖의 결함을 찾기 위한 통합적 관점의 검증 필요성
서론
전직은 제조업에서 장치 설계를 담당했습니다. 지금은 Claude Code를 파트너로 삼아, Wizardry 스타일의 3D 던전 RPG 「Abyssgate」(가제)를 개인 개발하고 있습니다.
이 계정에서는 지금까지 개발을 5단계로 나누어 세션을 일회성으로 사용하는 이야기나, 1개 태스크에 1개의 AI를 할당하여 구현하게 하고 보고를 검수하는 이야기를 써왔습니다. 둘 다 「AI와 어떻게 일할 것인가」라는 운영에 관한 이야기입니다.
이번에는 그 토대가 되는 이야기를 하겠습니다. 그 운영 방식은 AI 개발 지식에서 탄생한 것이 아닙니다. 전직 시절 제가 냈던 한 건의 결함에서 비롯되었습니다.
도면은 옳았다. 하지만 장치는 조립되지 않았다
전직 시절, 어떤 장치의 설계를 담당했을 때의 이야기입니다.
도면상으로는 설계 미스가 없었습니다. 검도(検図)도 통과했습니다. 치수도 계산도 틀리지 않았습니다.
그럼에도 불구하고, 현장에서 그 장치는 조립되지 않았습니다.
원인은 공차(公差)였습니다. 개별 부품은 도면대로 제작되었고, 모두 사양 범위 내에 있었습니다. 하지만 공차를 잡는 방식이 안일하여, 부품을 쌓아 올리다 보니 치수가 예상 범위를 벗어난 것입니다. 하나하나에는 문제가 없는데, 조합하는 순간 파탄이 납니다. 공차 누적(Tolerance Stack-up)이라는 현상입니다.
이를 발견한 것은 고객사에 나가 있던 자사의 필드 엔지니어였습니다. 현지에서 조정하여 어떻게든 조립해 주었습니다. 제가 도면 앞에서 깨닫지 못했던 것을, 실물 앞에 있던 사람이 찾아낸 것입니다.
원인을 나누자면 두 가지가 있습니다. 공정 측의 품질 관리 소홀과 저 자신의 선입견입니다. "이 정도면 들어가겠지". 그 한마디가 검도라는 공정을 빠져나갔습니다.
지금 돌이켜보면 요점은 이것뿐입니다.
검도에서 보고 있었던 것은 "도면이 올바른가"였지, "조립되는가"가 아니었습니다.
같은 일이 AI와의 개발에서 일어나고 있었다
Abyssgate의 코드는 거의 전부 Claude Code가 작성합니다. 인간인 제가 하는 일은 사양을 결정하는 것, 리뷰하는 것, 실기(実機)에서 만져보는 것입니다. 품질은 자동 테스트(Automated Test)가 책임지고 있으며, 테스트는 현재 2,113건으로 모두 통과(Green) 상태입니다.
얼마 전, 영어 로컬라이제이션(Localization) 설계를 하던 중 이런 것을 발견했습니다.
전투 로그의 색상 지정(데미지는 빨간색, 회복은 초록색, 상태 이상은 보라색...)이 일본어 정규 표현식(Regular Expression)으로 구현되어 있었던 것입니다. "\d+ のダメージ"
와 같은 패턴으로 본문을 검색하여, 일치하는 부분에 BBCode로 색을 입히는 방식이었습니다. 즉, 영어로 바꾸는 순간 색상이 모두 사라지게 됩니다.
문제는 여기서부터입니다.
이러한 고장 방식은 기존의 테스트로는 검출할 수 없습니다. 테스트는 일본어 로그를 입력값으로 사용하고 있기 때문입니다. 영어로 바꾼 후에도 테스트는 계속해서 통과(Green) 상태를 유지할 것입니다.
도면 이야기와 같은 형태를 띠고 있습니다.
- 검도는 통과했다. 하지만 조립되지 않는다.
- 테스트는 통과한다. 하지만 영어로 하면 고장 난다.
둘 다 "검사한 범위 내에서는 올바르다". 그리고 검사 범위의 바깥쪽에서 고장 나 있습니다.

왼쪽: 합격을 쌓아 올리면 허용 범위를 벗어남 / 오른쪽: 합격을 쌓아 올려도 영어는 한 번도 통과하지 못함
공차 누적 그 자체에 해당하는 현상도 있습니다. 단체 테스트(Unit Test)는 부품을 하나씩 "사양대로인가" 확인하는 공정입니다. 개별 요소가 모두 통과하더라도, 조합된 전체가 작동한다는 보장은 어디에도 없습니다. 그래서 저희는 UI나 입력과 관련된 변경 사항에는 결합 테스트(Integration Test)를 최소 1개 이상 작성하는 것을 규칙으로 하고 있습니다. 이는 단체 테스트를 신뢰할 수 없어서가 아니라, 단체 테스트는 공차를 보고 있지 않기 때문입니다.
AI 특유의 사정도 하나 있습니다. AI는 테스트를 통과시키는 능력이 정말 뛰어납니다. 실패한 테스트를 주면 통과할 때까지 고쳐줍니다. 하지만 "그 테스트가 올바른 범위를 보고 있는가"는 AI가 최적화하는 대상의 바깥에 있습니다. 통과해야 할 테스트 자체를 의심하는 것은, 현재로서는 인간의 몫입니다.
왜 깨닫지 못하는가 —— 선입견의 위치
전직 시절의 저는 "이 정도면 들어가겠지"라고 생각했습니다.
이번의 저는 "tr()은 철저히 지켜지고 있을 것이다"라고 생각했습니다.
tr()은 Godot의 번역 함수입니다. 표시할 문자열은 이것으로 감싼다는 규칙을 저희는 꽤 오래전부터 정해두었습니다. 그래서 영어화는 사전을 추가하는 것만으로 끝날 줄 알았습니다. 그런데 실제로 조사해 보니, 아이템·몬스터·주문·직업 등의 이름 86건과 전투 로그 54개가 애초에 tr()을 거치지 않고 있었습니다. 규칙이 있다는 것과 규칙이 지켜지고 있다는 것은 별개의 문제였습니다.
여기서 중요한 것은, 두 가지 선입견 모두 체크의 전 단계에 위치한다는 점입니다.
검도(検図, Design Review)도 테스트도 「무엇을 볼 것인가」가 결정된 이후의 공정입니다. 선입견은 그 전 단계인 「볼 대상을 결정하는」 곳에 자리 잡고 있습니다. 그렇기 때문에 체크를 아무리 정성스럽게 해도 걸러내지 못합니다. 오히려 정성스럽게 할수록, 잘못된 범위를 정성스럽게 확인하게 됩니다.
필요한 것은 「더 제대로 보는 것」이 아닙니다. 「볼 범위를 도출하는 공정」입니다.
전직에서 했던 대책과 지금 하고 있는 것
그 결함이 발생한 후, 제가 했던 일은 세 가지였습니다.
- 자기 체크의 철저화 (품질 관리 부서에 넘기기 전에 자신의 공정에서 해결)
- 검도 시 주의 사항을 도출하여 이를 인수인계 사항으로 남김
- 결과적으로 기계적으로 검사할 수 있는 체제를 구축하여 품질 관리 부서의 공수를 줄임
세 번째가 핵심이었습니다. 검사를 엄격하게 만든 것이 아닙니다. 사람이 눈으로 보고 판단하던 것을 기계가 판정할 수 있는 형태로 구현했습니다. 덕분에 인간은 기계가 볼 수 없는 부분에 전념할 수 있게 되었습니다.
현재의 개발 운영은 이 세 가지와 거의 일대일로 대응하고 있습니다.
| 전직 (장치 설계) | 현재 (AI와의 게임 개발) |
|---|---|
| 자기 체크의 철저화 | AI 스스로가 스크린샷 하네스(Harness)를 통해 화면을 확인하는 공정을 삽입 |
| ... |
왼쪽 열은 장치 도면을 그리던 시절의 이야기이고, 오른쪽 열은 게임 코드를 작성하고 있는 지금의 이야기입니다. 그럼에도 하고 있는 일은 같았습니다.
1인 + AI 체제에서는 이것이 생명선이 된다
개인 개발에서는 리뷰할 인간이 한 명뿐입니다. 게다가 AI는 인간의 리뷰 속도를 전혀 신경 쓰지 않고 코드를 내놓습니다. 그대로 두면, 검사가 병목 현상(Bottleneck)이 되어 개발이 멈추거나, 검사를 포기하여 품질이 떨어지는 양자택일의 상황에 놓이게 됩니다.
전직에서의 해답은 「검사를 기계로 옮기는 것」이었습니다. 지금도 똑같은 일을 하고 있습니다. 사양대로인지 여부는 테스트로, 외관이 변하지 않았는지 여부는 스크린샷의 차분(Diff)으로. 그렇게 기계로 넘긴 만큼, 인간인 저는 기계가 볼 수 없는 것들——손맛, 패드 조작감, 어두운 던전을 걸을 때의 공포감——에 시간을 쓸 수 있습니다.
역으로 말하면, 기계로 옮기지 못한 것만이 인간의 업무로 남는다. 이 경계선을 긋는 것이 AI와 혼자 개발할 때의 설계 그 자체라고 생각합니다.
마치며
제조업의 고전적인 규율——기록과 현물을 대조하기, 검사는 자신의 공정에서 완결하기, 인수인계 사항 남기기——는 AI와 개발하게 되면서 낡아지기는커녕, 오히려 효과가 더 좋아졌다고 느낍니다.
AI는 코드를 쓰는 속도를 높였습니다. 하지만 무엇을 검사해야 할지를 결정하는 일은 여전히 우리에게 남아 있습니다. 생산 속도가 올라갈수록 검사 공정의 설계가 품질을 결정한다는 사실은, 생산 라인이든 코드든 변하지 않는 것 같습니다.
다음에는 현재 설계 중인 이 영어 로컬라이제이션(Localization)에 관한 이야기를 쓸지도 모르겠습니다. 363개의 문자열을 영어로 바꾸는 계획을 세우는 중인데, AI에게 맡겨도 되는 부분과 인간이 결정하지 않으면 사고가 나는 부분이 생각보다 명확하게 나뉘고 있기 때문입니다.
개발 자체의 전체적인 모습은 2개월 분량을 정리한 총집편에 적어 두었습니다.
개발 중인 게임 「Abyssgate」(가제)의 진행 상황은 X에서 주 1회 발신하고 있습니다. 관심 있으신 분은 팔로우해 주세요.
그럼, 지하 미궁에서 기다리고 있겠습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기