제조 실행 시스템(MES/POP)을 유지보수하다 보면, 버그 리포트의 절반은 코드 문제가 아닙니다. 이번 건이 딱 그랬습니다. 코드를 한 줄도 고치지 않고 버그를 고친 이야기, 그리고 그 과정에서 발견한 “같은 이름의 컬럼이 전혀 다른 값을 담고 있는” 레거시의 함정을 기록합니다.
증상: 하나를 클릭했는데 여러 개가 선택된다
설비이력 화면에서 목록의 설비 하나를 클릭하면, 아래쪽의 다른 설비들까지 같이 선택된 것처럼 하이라이트되는 버그가 보고됐습니다. 화면 코드부터 의심하게 되는 증상입니다 — 선택 상태 관리가 꼬였거나, 키가 중복되거나.
추적: 선택 키를 따라가니 데이터가 나왔다
선택 로직을 따라가 보니 행 식별을 설비코드(equipment_code) 기준으로 하고 있었습니다. 그리고 데이터를 조회해 보니 — 설비코드가 빈 값인 설비가 13대 있었습니다. 빈 문자열끼리는 서로 같으니, 코드가 빈 설비 하나를 클릭하면 코드가 빈 나머지 12대가 전부 “같은 키”로 매칭되어 함께 하이라이트된 겁니다. 코드는 설계대로 동작했고, 데이터가 설계의 전제(“설비코드는 유일하다”)를 깨고 있었습니다.
선택지: 코드를 고칠 것인가, 데이터를 고칠 것인가
수정 방법은 두 가지였습니다.
- 코드 수정 — 선택 키를 설비코드에서 내부 id(UUID)로 변경. 근본적이지만, 이 화면 말고도 설비코드를 키로 쓰는 곳이 있는지 전수 확인이 필요하고, 배포도 타야 함
- 데이터 수정 — 빈 코드 13대에 설비코드를 부여. 배포 없이 해결되지만, “왜 빈 코드가 생겼나”의 재발 방지가 같이 필요
2번을 택했습니다. 애초에 설비코드는 비어 있으면 안 되는 값이었고(데이터가 잘못된 것), 채번 규칙(V-###)을 정해 13대에 V-001~V-013을 부여했습니다. 다음 신규 등록은 V-014부터 자동으로 이어집니다. 배포 없이 운영 반영으로 버그가 사라졌고, 규칙이 생겼으니 같은 문제가 재발하지도 않습니다.
함정: 같은 이름, 다른 값
다만 데이터를 건드리기 전에 반드시 확인할 게 있었습니다. 이 설비코드를 다른 데서 누가 참조하는가. 특히 PLC 연동 테이블에 equipment_code라는 같은 이름의 컬럼이 있어서, 코드를 부여하면 PLC 매핑이 깨지는 게 아닌지 확인이 필요했습니다.
확인해 보니 반전 — 그 컬럼은 이름만 equipment_code일 뿐, 실제로는 설비의 내부 id(UUID)를 담고 있었습니다. 즉 PLC 연동은 설비코드와 무관하게 동작하고 있었고, 코드 부여는 안전했습니다. 안심되는 결론이지만 동시에 무서운 발견이기도 합니다. 레거시에서 컬럼 이름은 그 컬럼이 담는 값을 보증하지 않습니다. 이름만 믿고 데이터 작업을 했다면 진단 자체가 틀렸을 겁니다.
교훈
- 버그의 최소 수정은 코드가 아닐 수 있다. 데이터가 설계의 전제를 깨고 있다면, 데이터를 전제에 맞게 되돌리는 것이 가장 작은 수정이다. 단, 반드시 재발 방지 규칙(채번룰)까지 세트로.
- 같은 이름의 컬럼이 같은 의미라는 보장은 없다. 데이터 작업 전 참조처 전수 확인은 생략하면 안 되고, 확인 결과가 “이름과 실제가 다르다”일 수 있음을 항상 열어둬야 한다.
- “코드는 설계대로, 데이터가 전제를 위반” 패턴은 레거시 유지보수 버그의 단골이다. 화면 증상에서 바로 코드로 들어가지 말고, 키가 되는 데이터의 유일성부터 확인하면 빠르다.
덧붙여
이 추적도 AI 코딩 에이전트(Claude Code)와 페어로 진행했습니다. 참조처 전수 검색과 데이터 집계는 에이전트가 빠르게 돌려줬고, “코드가 아니라 데이터를 고친다”는 선택과 채번 규칙의 결정은 사람이 했습니다. 유지보수 실전에서 겪는 이런 사례들을 계속 기록합니다.