스타트업이라는 말이 붙은 이유가 무엇이냐?

규모가 작은 회사라면 다양한 솔루션을 적용해놨을 것이다.
그런데 스타트업에선? 사업을 시작하는 단계에서는?

바위에 계란치기를 시도하는 입장에서 정말 조악한 수준으로 시작을 하게 된다.

물론 내가 시도했던 방식이 정답은 아닌 것 같다.
(더 빠르게 출력이 된 업체에서 일을 해봤다는 센터의 담당자의 대답으로 보아서는)

그렇지만 정답이 아니라고 오답은 아니다.
정답으로 가는 길목 중 하나라고 생각했기에, 나의 경험담을 풀어본다.

운송장은 어떻게 뽑나요?

모두 같은 방식으로 쓰고 있는지 확언은 할 수 없다만, 얼추 맞는 듯 하다.

출처 : 물류신문

택배를 사용해봤다면 한번 쯤은 보게 되는 운송장이다.
일상에서 운송장을 자세하게 볼 일이 생길 줄 몰랐는데

내가 경험했던 운송장의 출력 방식은
양식만 정의되어있는 택배사의 라벨지를 택배사로부터 받아온 후
라벨프린터로 해당 라벨지에 정보를 출력하는 식으로 진행이 됐다.

그리고 해당 라벨 프린터를 사용하려면 ZPL( Zebra 프로그래밍 언어) 라는 것을 별도로 다룰 수 있어야한다.

해당 언어의 모양은 아래와 같다.

ZPL 코드 예시 : ZPL viewer

지금 보면 별 생각 없는데, 처음 봤을 땐 이게 도대체 뭔가 싶었다 ㅋㅋ

대충 특정 좌표에 특정 글꼴로 무언가를 입력하겠다.
어떤 모양을 그리겠다.(바코드 포함) 이런식으로 코드를 작성하면 위의 사진처럼 보여준다.

자, 그럼 어떤 것으로 어떻게 입력해서 출력했는지 알았으니
어떻게 풀어나갔는지 서술해보겠다.

입사 당시의 상황

입사를 했을 무렵에는 하루 총 출고량이 200건이 안됐던 것으로 기억한다.

그리고 요청 한번에 최대 20장까지만 출력이 가능했다.
사업의 초기였기에 어떻게든 굴러갔다, 200장을 뽑아야하면 10번을 누르면 됐으니까.

그렇게 굴러가다가 큰 문제에 돌입을 하게 된다.
이벤트 출고가 발생을 하게 된 것, 2000장에 가까운 수량을 발송해야 하는 일이 벌어졌다.
이때 운송장 출력만 거의 한두시간 정도를 한 것으로 알고 있다..

---

이 일이 발생되고 나서 소통을 더 많이 하게 됐다.

왜냐하면 대량 처리에 대한 준비가 하나도 안되어있는 상황에서
영업팀에서 가능하다고 하여 해당 물량을 받아온 상황은 별개로

적어도 이러한 이야기를 개발팀에 전달만 했어도 선제조치를 해봤을텐데
갑작스럽게 발생한 일이기에 아무런 대처도 없이 인력으로 해결했다.

---

이 당시에 사용하던 프린터 프로그램은 외주를 통해 받아놓은 것이였고
ZPL에 대한 이해도 또한 떨어졌기에 운송장 출력 로직을 고쳐보기로 다짐을 했다.

해당 로직을 살펴보니,
운송장 생성 - 출력을 원터치에 진행이 되고 있었으며
불필요하게 운송장을 생성과 출력 할 때 마다 총 두 번의 주소 검증이 이뤄지고 있었다.

그래서 아래와 같은 방법으로 변경을 진행한다.

여기서 핵심은 결국 주소 검증은 1회만 진행하는 것이다.

왜냐하면, 택배사의 API를 통해서 주소 검증이 있었기 때문에
외부변수는 제어를 할 수 없고 두 번이나 검증을 할 필요가 없었기에 변경을 했다.

운송장 테이블을 새롭게 설계하는 것으로 다양한 이점을 얻을 수 있었는데
대량의 출고가 발생을 하는 경우 업무시간 전 미리 운송장을 발행하는 것으로

조금 더 많은 운송장을 한번에 출력할 수 있게 되었고 대기하는 시간 또한 대폭 감소하였다.
수치상으로는 대략 300%에 가까운 업무 효율이 올라간 것으로 기억되고 있다. (과거 문서에 있음)

그렇게 끝이 날 줄 알았....
진 않았다

N개의 택배사를 사용한다.

4개의 택배사를 운용할 수 있도록 프린터를 개선해달라

들었을 땐 그저 의문만 가득했다.

말만하면 만들 수 있는 줄 아나? (진심으로)

왜냐하면 외주업체를 통해 받은 프로그램으로 작업을 하고 있었고
해당 프로그램은 단 한개의 프린터만 지원을 하고 있었기 때문이다.

외주업체에 추가 개발을 요청했으나,
현재 밀린 업무가 있기에 긴 시간이 걸릴 수 있다. 라는 답변을 받게 된다.
시간이...없는디...?

그래서 직접 만들어보기로 한다.

처음에는 아는게 너무 없었기에 기존의 프로그램을 참고해보았지만
크게 도움이 되는 정보가 없었기에 아예 1부터 새로 만들기로 작정을 하는데...

이때부터 사무실에 운송장 뽑는 소리가 매일같이 들렸다.

하드웨어는 다루기엔 너무나도 많이 가는 것 같고
우리는 웹개발자니 그럼 http 통신을 해보는 것은 어떨까?

기존에 사용하던 프린터에는 내장된 랜카드가 없어서 프로그램으로 만들어줬기에
랜카드가 내장된 프린터를 주문하여 테스트를 했다.

프린터에 랜선을 꽂은 후 게이트웨이 동일하게 맞춰놓고
프린터 IP로 POST 요청을 했더니 너무나도 잘나오는 운송장에 아 ㅋㅋ 드디어 해결 완료 ㅋㅋ

인 줄 알았으나 운송장의 출력 순서가 지멋대로 뒤섞이는 일이 발생했다.

프린터의 메모리에 운송장 정보를 넣어놓고 출력을 하는데
정상적으로 출력이 완료되기 전에 새로운 정보를 꾸겨넣으니 문제가 발생하는 것이였다.
(정확한 원인은 다음 챕터에 나온다.)

그래서 딜레이를 주지 않고 한개의 문자열로 던지는 것으로 정리하고 창고를 가려고 했는...데?

랜선을 따줄 수 없다는 답변을 들었다.

...랜선을 프린터에 못 꽂으면 암것도 못하는디?
패킹하러 담당자가 이동하면서 운송장 출력 요청까지 하는 예쁜 그림도 그리고 있었는데?

보안 문제부터 시작해서 어른들의 사정으로 인해 안된다는 답변을 받는다.

그렇게 다시 고민을 하던 중....
같이 삽질을 하는 팀원이 멀티 브릿지를 이용하면 가능할 것 같다고 하여
쿠팡으로 바로 주문을 해버린 다음 날 테스트를 해봤다.

정 상
동 작

그렇게 씬나게 센터를 가서 설치를 하러 갔는데?

안돼

이때 진짜 머리가 많이 아팠다, 그렇게 맨손으로 퇴근하고
네트워크 담당자한테 문의를 넣어놓고
퀵으로 보냈던 프린터는 다시 사무실로 보내고
아, 퀵으로 사람을 배달 못한단다, 그.. 다마스면 태워주면 되지않나?

여러가지 궁리를 하던 차에, 공유기의 스위치 기능을 활용하여 테스트에 성공
그렇게 센터에 도착해서 설치를 완료하게 된다..

N개의 프린터를 이용하여 N개의 택배사 운송장을 출력하고 출력 수량 또한 40매에서 200매까지 늘리며 큰 성과를 거두고 온다.

---

사실 이때 별 짓을 다 했던 것으로 기억한다.
해외 운송장도 출력을 했는데 엄청 빠르게 출력이 되는 것을 보고
국내 운송장도 빠르게 출력을 할 수 없을까.. 하면서 ZPL 커뮤니티를 다 뒤져봤는데

템플릿 캐시를 적용해도 별 차이를 못느끼고 아쉽게 마무리를 한 기억이 있다.

운송장 정보 수정이 가능할까요?

최초 발행되던 운송장에는 거대한 문제가 있었다.

운송장에 상품이름이 안들어가고 물품의 고유번호(SKU)가 들어가고 있던 것.

정말 맘에 안들어서 이거 고쳐드릴깝쇼? 하는데 클레임이 안걸린다고 그냥 뒀다.
(이것이 스타트업?)

그러던 와중 드디어 클레임이 들어와 수정을 해보려고 했더니
익숙치 않았던 ZPL이 난항을 겪게 만들었다.

ZPL로 할 수 있는 모든 것을 다 해야만 정보를 변경할 수 있었는데,
이 작업을 하면서 숙련도(?)가 올랐다고 해야할까..

1. 글씨가 쓰여질 좌표를 잡고
2. 레이아웃의 한계선을 잡은 후
3. 글꼴이 반영된 문자를 그려낸다.

이 3개의 작업을 하는데 상당히 많은 시간이 들었다.

https://www.servopack.de/support/zebra/ZPLII-Prog.pdf

그러면서 이런저런 문서도 읽다보니 이후에는 그냥 대충 끄적끄적 건드려서
창고에서 원하는 레이아웃을 구현 할 수 있게 됐다.

사실 직접 다룰 수 없었다면 이것도 외주업체에 요청해서 만들었어야했는데....
정말 많은 시간을 아낀 결과라고 볼 수 있겠다.

더, 많이, 뽑으면, 좋겠어요.

영업팀이 몸집이 큰 화주를 대려오면서 출고량이 급증하기 시작했다.

근데 운송장은 한번에 최대 200장까지 밖에 뽑질 못했다.

그래서 결국 요청사항이 들어왔다.

그래서 정말 완전 바닥까지 내려가보기로 결정한다.

프린터란 도대체 어떻게 동작을 하는 것인가?

와이어샤크로 통신이 되는 것을 확인을 해보니 응답을 프린터가 주질 않았다.
응답만 주면 이게 어떤 상태인지 알 수 있는데 말이다..

그러다가 서치를 하다보니~hs 라는 커맨드를 사용하면 프린터의 상태를 확인할 수 있어서
출력의 끝점을 알 수 있는 것 까지 확인이 됐다.

그래서 똑같이 http로 해당 커맨드를 호출했는데

안돼, 또

그래서 열심히 서치를 해보니 아래 글을 보게 됐다.

누르면 넘어갑니다 > 스택오버플로

양방향 통신에서만 해당 커맨드가 먹힌다.
그래서 양방향 통신 중 한개인 TCP/IP를 활용하려고 했는데..

또또또 안돼
이유를 찾아보니 보안 문제가 있기 때문에 브라우저에선 TCP 통신은 불가능하다고 하더라..

그렇게 결국 go 언어를 사용해서 프로그램을 만들고, 테스트를 해본 결과!
1000장을 한번에 출력할 수 있는 결과를 얻게 된다.

씬나서 센터로 출장을 가서 설치를 하러 간다.

(짐도 댕많이 들고 갔다왔음)

어 뭐야 왜 출력이 안돼???

세팅을 잘 해놓고 집에 가려고 하는데, 갑자기 출력이 안된다는 말을 들었다.

에러로그를 찍어보니 rune 문자 어쩌구 하는 에러가 떠있었다.

지금까지 출력을 할 땐 문제가 없었는데 이게 도대체 뭘까 하고
세명이서 두시간을 찾아봤는데, 결론은 아래와 같다.

.... 저러고 룬문자 몇개가 더 있길래, 예외처리를 해놓는 것으로 문제를 해결하게 되었다.

---

이후 풀필먼트 조직 개편이 이뤄지면서 이후의 개발은 홀드가 되었다.

되돌아보며

해당 업무를 하면서 참 많은 우여곡절이 있었고 주변의 걱정도 있었다.

웹개발자인데 너무 하드웨어쪽을 깊게 보게 되는 상황이 좋아보이진 않는다고

근데 선택지가 딱히 없었다, 외주는 오래걸린다 하고 누군가는 잡고 해야하는데
내가 출고를 담당하고 있기도 했기에 일단 돌진을 해본 것 같다.

성과는 점진적 개선을 통하여 1회에 20장 출력에서 1000장으로, N개의 프린터를 조작 가능하게 되었으니 결과만 놓고 보면 대성공이지 않을까 싶다.

일단 이게 피드백이 즉각적으로 오니까 도파민이 좀 많이 돈 것 같기도 하고(??)

맨바닥부터 해보는 챌린징같은 과제(업무)가 몇개 있었는데 나름 재밌게 한 것 같다.
결과가 나오지 않으면 어쩌나 하면서 고민도 많이 했지만
그 시간에 서치를 계속 돌리면서 정답들을 찾아내는 과정이 썩 재밌었던 것 같다.

갑자기 자다가 생각나서 찾아본게 내가 가야할 길로 알려줬던 것도 있었고..ㅋㅋ

삽질 참 열심히 잘 했던 것 같다.

---

아, 블로그 쓴다고 했더니 샤라웃좀 해달라길래 ㅋㅋ

위의 사진을 보면 농담곰과 다람쥐(?)가 나오는데
농담곰은 나고, 다람쥐는 나와 프린터 작업을 함께 해준 동갑내기 팀원이다.

둘이 있었기에 더욱 시너지가 나서 진행을 할 수 있었고 재밌게 했던 것 같다.

끝!