WIL(Weekly I Learned) 택배 운송장 서비스를 구현하면서 느낀점

lets-do-the-odessey.tistory.com/9

택배 운송장 등록&관리 서비스

일주일만에 돌아왔다. 개발을 마친 건 4일이었는데 바로 다음공부를 진행해야했기도 하고 여러 일들이 많아 바로 글을 쓸 여력이 안됐다. 위 링크는 월요일에 어떻게든 구현을 하겠다고 짜놓은 기획안이다. 이걸 구현하기 위해 4일동안 밤새며 전전긍긍했던 후기를 풀어보고자한다.

 

시작에 앞서 팀원은 나 포함 총 3명이었는데 셋다 백엔드에 관심이 있어서 홈페이지 도메인을 유려하게 꾸미지 못한 점이 아쉽다.. 나름 우리는 기능에 치중한 것이 포인트라고 애써 위로했지만 다음번에 이러한 프로젝트를 또 진행한다면 꼭 디자인설계까지 마치고 시작하고 싶은 심정이다.(개인적인 아쉬움일 뿐 그것과는 별개로 같이 힘내준 팀원들한테 너무 고맙다.)

 

보자보자 운송장 서비스! 

kellykang.site/

보자보자 운송장 서비스

 

위 링크는 AWS서버에 올려서 가비아에서 산 도메인 링크를 연결한 최종시안이다.

 

WIL답게 간단하게 배운 점과 느낀점을 풀고가려 한다.

이번 프로젝트 개발에서 크게 중요하게 깨달았던 점은(지식적인 면에서) 세가지였다.

 

1. 인코딩과 디코딩

인코딩이란 간단하게 설명하자면 코드화, 암호화라고 보면 된다. 인코딩/유니코드/아스키코드등의 의미를 이해하려면 컴퓨터가 처음 등장한 시점으로 올라가야한다. 초기 컴퓨터는 복잡한 숫자연산을 위해 사용될 용도로 등장했다. 그러나 계산 후에도 사람이 볼 수 있는 형태로 모니터,프린터 등 다른 컴퓨터에 나타내야 했는데 이를 위해 문자를 숫자로 치환하는 방법이 등장했다. 그러나 각각의 컴퓨터마다 이를 나타내는 법이 달랐는데, 이를 통일하기 위한 국제표준이 등장했으며, 이것이 아스키코드의 발단이다. 그러나 이건 영미권만을 위한 표준이었기에 다른 나라간의 교류에서 애로사항이 생겼고 이를 다시 통일하기 위해 생긴것이 유니코드이다. 그러나 또 다시 문제가 생기게 되는데 즉, 글자마다 바이트 사용 기준이 달라서 숫자앞에 특수문자로 바이트를 몇개를 읽어야할지 모르는 상황이 오게되는데 이후 생기게 된 것이 인코딩이다. 그리고 알다시피 인코딩 방법에는 UTF-8이나 EUC-kr같이 여러 방법이 존재하는데 이 방법이 다르게 되면 오류가 생긴다. 이건 일상에서 흔히 겪어봤을 것이다. 한글이 가나다를 궳뚫쉛등으로 읽어들이는 것이 그 예이다.

 

이러한 서론이 등장한 이유가 있는데 나는 파이참으로 로그인 기능을 구현하던도중(jwt토큰 방식을 사용중이었음)

token = jwt.encode(payload, SECRET_KEY, algorithm='HS256').decode('utf-8') 라고 토큰을 인코딩 후 디코딩을 해주었는데 계속해서 로그인창 이후로 넘어가지 않았다. 구글링 끝에 파이썬이 이미 디코딩기능이 내장되어있어서 두번 쓸 필요가 없다는 답변을 얻었다..

그리고나서 DB작업 및 호환문제등을 해결하기 위해서는 인코딩/디코딩 개념을 확실하게 잡을 필요가 있다싶어 정리하게 되었고 

www.youtube.com/watch?v=ABPOjjre0C8

이분의 영상이 굉장히 도움이 되었다

 

그리고나선 문제없이 프론트엔드를 개발하고 팀원들에게 택배 API제작을 맡기고 모든 것이 순조롭게 흘러가 프로젝트 마감 하루전날에 미리 끝낼 수 있는거 아니야? 했던 찰나에 깨달은 점이 있었으니..

 

2. DB설계의 어려움, 추후 업데이트를 위해 공부해야할 것은 무엇일까

우리가 제공하려는 기능을 다시한번 짧게 설명하자면 사용자가 택배 운송장을 등록하면 그걸 한 군데에 모아 보여주고 배송완료된 것은 삭제해주고 택배가 어디쯤 왔는지 자동으로 업데이트 해주는 것이었다. 문제는 그놈의 자동 업데이트 였다. 우리는 사용자가 택배 송장번호를 입력하면 그걸 사용자ID값,송장번호,택배사 이 세가지 정보를 택배DB에 넣어줌과 동시에 DB에서 정보등을 빼내와 택배api주소에 http://송장번호/택배사 이런 형식으로 사용자 인터페이스에 찍어줬다.

 

이런식의 API 코드로.. 말이다

 

여기에 크나큰 문제가 있었으니.. 등록할 때는 실시간이겠지만 등록하고 나서 업데이트 하는 기능을 어떻게 구현해야할지 생각을 안해뒀던 것이다. 사용자가 아무런 액션도 취하지 않는데 업데이트 되는 기능? 어떻게 하는지 도저히 떠오르지 않았고.. 더군다나 이걸 프로젝트 마감전날 새벽에 셋이서 깨달아버렸다. 마감이 하루남은 시점에서 로그인한 사용자마다 다른 페이지를 어떻게 보여줘야하는지도 모르겠는데 DB를 자동으로 업그레이드하고 그걸 다시 사용자 인터페이스에 붙여주는 기능이라니, 불가능이었다. 이건 아직도 해결하지 못했는데 추후 해결할지도 모르니까 페이지에 업데이트 버튼을 달아뒀다. 다른 팀들에게 홈페이지 시연을 보여줬더니 업데이트 버튼의 존재에 의구심을 품는 사람이 있을까봐 땀을 삐질거렸던 기억이 난다..

 

3. 토큰을 str으로 만들고 > Jsonify(str)로 줘야했던거구나!

결국 우리는 기능적인 부분들을 적당히 타협하며 최종시안에 작업하기에 이르렀다. 마감당일 오후 10시쯤에 아슬아슬하게 local에서 모든 기능이 돌아가는 것을 확인하고 아 이제 끝났다... 하고 생각하는 찰나에.. AWS가 문제를 일으켰다.

AWS에서 리눅스 컴퓨터를 구매하고 이걸 서버용 컴퓨터로 사용하려고 모든 계획을 짜놨다. 그리고 이전에 해왔던 것 처럼 서버용 컴퓨터에 파일질라로 투고 후 확인해봤더니 어라? 로그인이 안되는 것 아닌가.. 정말이지 멘붕이었다. 왜냐면 24시가 마감이었는데 로그인이 안된다는 걸 깨달은게 23시 40분이었으니까... 투고를 담당하는 팀원에게 빨리 해결하라고 재촉했지만 결국 마감시간을 지나서도.., 새벽 2시가 돼서도 해결을 못했다. 로그인이 안되는 걸 어쩌라는 말인가. 생각해보면 프로젝트를 시작하고나서 멘토가 직접적으로 도움을 준 적이 없었다. 모든 애로사항은 팀 자체 내부에서 해결해야 했고. 우리는 투고 단계에서 일이 터질 줄 몰랐다. 마감날 두뇌를 풀가동하느라 지친 팀원과 함께 아침 일찍 일어나서 멘토분들께 도움을 청하기로 했다. 아침에 일어나 확인해보니 기적적으로..! 팀원분께서 해결해놨었다.

 

짧게 로그인이 안됐던 이유를 설명하자면 토큰을 html파일에 전달하는 과정에서

return jsonify({'result': 'success', 'token': token, 'msg': '로그인 성공!'})

이러한 함수를 사용하는데 이전에 토큰으로 만들어두고서는 우리가 제공하는 토큰이 어떤 타입의 데이터인지도 확인하지 않았던 것이다.. jsonify의 경우 문자형(str)만 전달이 가능한데 우리는 토큰을 문자형로 바꿔주는 작업을 하지 않아 로그인에 착오가 생겼던 것이다. 여러분은 이런 실수를 하지 않도록 자신이 페이지에서 페이지로 데이터를 넘겨줄 때 무슨 타입의 데이터인지 확인해보는 습관을 기르도록 하자.

 

마지막으로 아쉬웠던 점과 느낀 점 또한 짧게 얘기해볼까 한다.

평소 적당히 노력해 적당한 결과를 뽑아내는 걸 좋아하는 성격이기에 자신의 한계를 넘는 경험을 해본 적이 많이 없는데, 이번 팀 프로젝트를하며 그런 경험을 수도없이 한 것 같다. 왜냐면 개인의 일은 자신이 그 모든 책임을 감내하고 안좋은 결과가 나와도 이정도 노력해서 이런 결과면 괜찮은거지~ 하고 자기합리화가 가능한데 팀 프로젝트는 그게 아니었다. 내가 내 한계 그 이상으로 노력하지 않으면 우리 팀은 어떠한 결과물도 만들어낼 수 없다. 그건 팀원이 팀에게 보여주는 진심을 무시하는 행동이기도 하니까. 그리고 다시 한번 깨달았다. 나는 타인과 협업하는게 너무 즐겁다. 체력적으로 힘든지도 몰랐을정도로 프로젝트를 하며 내가 이만큼의 생산성도 낼 수 있구나 싶어서 즐겁다고 느꼈었다.

그럼에도 아쉬운 점이 있었는데 웹 기획이 처음이라 기능적인 부분을 계획할때 대충 만들면 되겠지의 생각으로 큰그림만 잡고 시작해서 결국 구현하지 못하게된 기능이 많았다. 조촐한 계획이어도 되니 세부적으로 짰다면 시간을 낭비하는 일은 없었겠지하고 아쉬움이 많이 남았다. 자신의 역량을 잘 고려해 기능적인 부분을 어떻게 구현할건지도 다음부터는 섬세하게 계획해서 일을 진행하고자 한다.