처음에는 단순한 인쇄 옵션 문제라고 생각했습니다. 모바일 거래내역 화면에서도 PC처럼 현장용과 거래처용을 고른 뒤 거래명세서를 출력하면 될 것 같았습니다. 그런데 막상 고쳐 보니 프린터는 움직이는데, 정작 나와야 할 거래명세서 대신 모바일 거래목록 화면 자체가 인쇄됐습니다.
비개발자인 김부장 입장에서는 이런 상황이 가장 헷갈립니다. “인쇄가 안 된다”도 아니고, “인쇄는 되는데 다른 화면이 나온다”는 문제는 코드의 어느 부분이 잘못됐는지 감을 잡기 어렵습니다. 그래서 이번에도 AI에게 기존 PC 인쇄 방식과 모바일 인쇄 방식을 먼저 나눠 보게 했습니다.
막힌 지점 1: A5라고 생각했는데 프린터에는 A5가 없었다
처음에는 거래명세서가 반절 크기 용지처럼 보이니 CSS를 A5 가로로 맞추면 된다고 판단했습니다. 하지만 실제 안드로이드 인쇄창에서 확인해 보니 용지 크기 목록에 A5가 없었습니다. PC에서는 대충 넘어가던 용지 설정이 모바일에서는 더 엄격하게 적용될 수 있다는 것도 알게 됐습니다.
그래서 한 번은 A5로 바꿨다가 다시 A4 기준으로 되돌렸습니다. 이 과정에서 배운 건 “내가 생각한 용지 크기”와 “프린터 드라이버가 실제로 지원하는 용지 크기”는 다를 수 있다는 점입니다.
막힌 지점 2: 버튼은 눌렀는데 브라우저가 현재 화면을 인쇄했다
더 큰 문제는 그다음이었습니다. 인쇄는 되는데 거래명세서가 아니라 거래목록 화면이 찍힌 겁니다. AI와 함께 코드를 살펴보니 PC 쪽은 별도의 거래명세서 HTML을 만들어 인쇄 엔진에 넘기는 구조였습니다. 반면 모바일에서는 데이터를 불러오는 비동기 과정과 인쇄창을 여는 타이밍 사이에 간격이 생겼습니다.
모바일 브라우저는 사용자의 클릭 동작으로 바로 열린 창이 아니면 팝업이나 인쇄창을 막는 경우가 있습니다. 그러면 개발자가 의도한 거래명세서 HTML이 아니라 현재 보이는 화면이 그대로 인쇄 대상으로 잡힐 수 있었습니다.
AI와 같이 확인한 해결 방향
이번에 고친 핵심은 “인쇄할 내용”과 “인쇄창을 여는 타이밍”이 따로 움직이지 않게 하는 것이었습니다. 사용자가 모바일에서 인쇄 버튼을 누르는 순간 먼저 인쇄용 창을 확보하고, 거래명세서 데이터를 불러온 뒤 그 창 안에 현장용 또는 거래처용 HTML을 넣도록 흐름을 바꿨습니다.
또 기존 PC에서 쓰던 거래명세서 인쇄 엔진을 모바일에서도 함께 쓰도록 맞췄습니다. 그래야 PC와 모바일의 양식이 서로 다르게 어긋나지 않습니다. 다만 공용 인쇄 엔진을 손대면 매출전표 작성, 거래내역, 배송코스 출력처럼 여러 화면에 영향을 줄 수 있어서 빌드 확인과 영향 범위 정리가 꼭 필요했습니다.
비개발자 관점에서 배운 점
이번 작업의 교훈은 “프린터 문제처럼 보여도 브라우저 문제일 수 있다”는 것입니다. 용지 크기, 팝업 차단, 비동기 데이터 로딩, 공용 인쇄 엔진이 한꺼번에 얽혀 있었습니다. 예전 같으면 프린터 설정만 계속 만졌을 텐데, 이번에는 AI와 함께 어디까지가 기기 설정이고 어디부터가 코드 흐름인지 나눠 볼 수 있었습니다.
그리고 또 하나 배웠습니다. 화면에서 버튼 하나를 누르는 일도 개발 안에서는 꽤 긴 여행입니다. 버튼 클릭, 데이터 조회, HTML 생성, 새 창 열기, 인쇄 명령까지 이어집니다. 중간에 타이밍이 하나만 어긋나도 사용자는 “왜 목록이 인쇄되지?”라는 결과만 보게 됩니다.
다음 편에서는 비슷하게 “겉으로는 숫자 표시 문제인데 실제로는 계산 기준이 달랐던” 창고이전 인쇄의 현재 수량과 잔량 수정 기록도 정리해 보려고 합니다.