[비개발자 자동화 노트]
ERP 화면을 만들다 보면 “그냥 표시만 하나 추가하면 되는 일”처럼 보이는 요청이 있습니다. 이번에는 배송코스 화면에서 직배송 건마다 주문한 시각, 그러니까 몇 시 몇 분에 들어온 주문인지 보고 싶다는 요구였습니다. 김부장 눈에는 처음에 단순했습니다. 날짜가 있고 전표번호가 있으니, 어딘가에 시간도 있겠지 싶었습니다.
그런데 AI와 같이 로그와 코드를 따라가 보니, 이 작업은 버튼 하나 붙이는 문제가 아니었습니다. “화면에 안 보인다”와 “데이터가 없다”는 완전히 다른 문제라는 걸 다시 배웠습니다.
첫 번째 막힘: created_at을 쓰면 되는 줄 알았다
처음 떠오른 후보는 Supabase 테이블의 created_at이었습니다. 이름만 보면 생성 시각이니 주문 시각처럼 보입니다. 하지만 조사해 보니 이 값은 주문이 들어온 시각이 아니라, 웹 쪽 데이터베이스에 행이 만들어진 시각에 가까웠습니다. 더 곤란한 점은 동기화 과정에서 기존 행을 지우고 다시 넣는 방식이 섞여 있어, 재동기화가 일어나면 created_at이 흔들릴 수 있다는 점이었습니다.
비개발자인 제 입장에서는 컬럼 이름이 제일 위험했습니다. 그럴듯한 이름이라고 진짜 업무 의미까지 맞는 것은 아니었습니다. AI에게 “추측하지 말고 실제 소스와 컬럼을 확인해 달라”고 한 이유가 여기서 나왔습니다.
두 번째 막힘: 배송 화면이 읽는 데이터에는 시간이 없었다
배송코스 화면이 실제로 읽는 값도 확인했습니다. 전표번호, 날짜, 거래처명, 비고, 수량, 품명, 금액, 창고코드 같은 필드는 있었지만 “시:분”을 담는 필드는 없었습니다. 수동으로 입력하는 시간지정 값은 있었지만, 그것은 “10시까지 배송” 같은 사용자가 적는 메모 성격이지 주문이 접수된 시각은 아니었습니다.
여기서 한 번 더 배웠습니다. 화면에 비슷해 보이는 값이 있다고 해서 같은 의미는 아닙니다. 배송 희망시간, 주문 입력시각, 동기화 시각은 모두 시간처럼 보이지만 업무적으로는 완전히 다른 값입니다.
세 번째 막힘: 원본 ERP에는 시간이 있었지만 길이 끊겨 있었다
AI가 계속 원본 쪽을 추적했습니다. 레거시 ERP의 전표 헤더 쪽에는 날짜와 시각을 함께 담는 필드가 있었습니다. 형식도 날짜와 시:분:초가 들어가는 타임스탬프였습니다. 즉 “진짜 주문 또는 입력 시각에 가장 가까운 데이터”는 원본에는 있었습니다.
문제는 그 다음이었습니다. 원본 ERP에서 Supabase로 넘어오는 동기화 SELECT 목록에는 그 시각 필드가 빠져 있었습니다. 그래서 프론트 화면이 읽는 테이블까지 시간이 도착하지 못했습니다. 데이터는 원본 창고 안에 있는데, 배송 화면으로 오는 트럭에는 실리지 않은 셈입니다.
AI와 같이 확인한 방식
이번에는 코드를 바로 고치지 않고 조사만 했습니다. 먼저 배송 화면의 타입과 조회 컬럼을 확인했고, 그다음 Supabase 테이블 정의와 마이그레이션을 봤습니다. 마지막으로 레거시 ERP와 연결되는 동기화 코드에서 어떤 컬럼을 가져오고 어떤 컬럼을 버리는지 대조했습니다.
AI가 잘한 부분은 “쓸 수 있다/없다”를 감으로 말하지 않고 후보를 표처럼 나눠 준 점이었습니다. created_at은 동기화 시각이라 탈락, 날짜 필드는 시각이 없어서 탈락, 비고 텍스트는 관행이 없어서 탈락, 원본 ERP의 타임스탬프는 유일한 실제 후보지만 현재 동기화되지 않아 보류. 이렇게 정리되니 비개발자인 저도 다음 작업의 범위를 이해할 수 있었습니다.
비개발자 김부장이 배운 점
첫째, 화면 수정 전에 데이터의 출처를 먼저 봐야 합니다. 둘째, 이름이 비슷한 시간값을 함부로 대체하면 나중에 업무 신뢰도가 깨집니다. 셋째, 레거시 시스템과 새 웹 시스템 사이에서는 “원본에는 있는데 동기화에서 빠진 값”이 생각보다 중요합니다.
결국 오늘의 결론은 “주문 시각을 표시하려면 원본 ERP의 시각 필드를 동기화 파이프라인에 새로 태워야 한다”였습니다. 단순 UI 작업이 아니라, 원본 SELECT 추가, 웹 DB 컬럼 추가, 동기화 매핑, 화면 타입과 표시까지 이어지는 작은 데이터 파이프라인 작업이었습니다.
다음 편에서는 이런 조사 결과를 실제 수정 작업으로 옮길 때, 비개발자가 어디까지 검증하고 어디서 멈춰야 하는지 정리해 보려고 합니다. 바이브코딩은 AI가 대신 코드를 써 주는 것보다, 제가 모르는 위험한 지점을 같이 찾아내는 쪽에 더 큰 가치가 있었습니다.