업무용 화면을 만들다 보면 “기능은 들어갔는데 현장에서 보는 값이 다르다”는 순간이 있습니다. 이번에는 상담 화면에서 거래처를 선택했을 때 적용되는 등급이 문제였습니다. 현장에서는 특정 거래처를 4등급으로 보고 있었지만, 새 상담 화면에서는 1등급으로 잡혔습니다. 가격이 등급에 따라 달라지는 화면이라 단순한 표시 오류로 넘길 수 없었습니다.
DB값이 맞는데도 현장과 달랐다
거래처를 검색해 선택하면 등급 배지가 표시되고, 그 등급에 맞춰 상품 가격이 자동으로 선택됩니다. 그런데 거래처명에는 분명 등급을 뜻하는 표시가 붙어 있는데도 화면은 데이터베이스의 tier 값만 보고 1등급이라고 판단하고 있었습니다.
비개발자인 제 입장에서는 “DB에 있는 값이면 맞는 것 아닌가?” 싶었습니다. 하지만 실제 업무 데이터는 그렇게 단순하지 않았습니다. 오래된 시스템일수록 공식 칼럼과 현장에서 오랫동안 써 온 규칙이 서로 다를 수 있었습니다.
표시와 계산, 전달값을 함께 따라갔다
확인해야 할 지점은 세 가지였습니다. 상담 화면이 어떤 값을 기준으로 등급을 정하는지, 등급을 어떤 가격 필드로 바꾸는지, 선택한 거래처를 새 전표로 넘길 때 어떤 값을 쓰는지였습니다. 이 경로들이 각각 따로 움직인다면 한 군데만 고쳐서는 문제가 해결되지 않습니다.
사실 이 부분은 전에 [비개발자 자동화 노트] 오늘 카드에서 어제 매출을 보려다 DB 함수까지 만진 날에서도 비슷하게 헤맸던 지점이라, 그때 기록을 다시 들여다보면서 확인했다.
현장에서 쓰는 거래처명 끝의 숫자나 짧은 표기가 실제 등급 역할을 하고 있었습니다. DB의 공식 칼럼과 현장 표기가 충돌한 셈입니다. 특히 화면의 배지만 4등급으로 바뀌고 실제 가격은 계속 1등급으로 적용된다면 더 위험했습니다.
AI와 함께 먼저 거래처 검색 응답에서 DB 등급값이 실제로 무엇인지 확인했습니다. 그다음 상담 화면 코드에서 등급 배지, 상품 적용가, 전표 전달값이 어떤 함수를 거치는지 차례로 따라갔습니다. 원인은 명확했습니다. 화면이 DB의 tier만 믿고 있었고, 거래처명 끝에 붙은 등급 표기는 해석하지 않았습니다.
등급을 정하는 기준을 한곳으로 모았다
해결은 “더 그럴듯한 값 하나를 고르는 것”이 아니라 “기준을 한곳으로 모으는 것”이었습니다. 거래처명 끝의 1~5 등급 표기를 우선 해석하고, 특수한 짧은 표기도 같은 규칙 안에서 처리하도록 했습니다.
이렇게 보정한 등급을 화면 배지, 상품 가격 선택, 새 전표로 넘기는 값에 모두 똑같이 적용했습니다. 마지막에는 ESLint와 빌드를 통과시킨 뒤 커밋과 배포까지 확인했습니다.
어느 값이 진짜인지 먼저 물어야 했다
이번에 배운 점은 비개발자가 AI와 일할 때 “어느 값이 진짜인가?”를 꼭 물어야 한다는 것입니다. 데이터베이스 칼럼은 중요하지만, 오래된 업무 시스템에서는 현장 규칙이 이름이나 메모, 별도 표기 안에 숨어 있는 경우가 있습니다.
AI에게 “DB값이 왜 틀렸지?”라고만 묻기보다 “화면에 보이는 값, 저장된 값, 실제 업무 기준이 각각 어디서 오는지 따라가자”고 요청해야 했습니다. 가격처럼 돈과 연결되는 화면이라면 표시와 계산도 따로 보면 안 됩니다. 배지만 고쳐도 사용자는 안심할 수 있지만, 실제 적용가가 다르면 더 큰 사고로 이어질 수 있습니다.
이번 작업의 핵심은 보정 로직을 하나로 만들고 모든 경로가 그 로직을 쓰게 한 것이었습니다. 새 화면을 만드는 일은 새 코드를 쓰는 일보다 기존 업무 기준을 빠뜨리지 않는 일이 더 어렵다는 것을 다시 느꼈습니다.