[3주차] 활동 기록 & 데일리 회고 - kyupid/issue-tracker GitHub Wiki

0621회고

eamon:

어텀이 나의 코드를 보고 궁금했던 점에 대한 피드백을 issue 에 남겨놓았는데 이제야 확인해서 다시 답을 주었다. 협업하는 동안에는 issue 를 자세히 들여다 보는 습관을 들여야겠다.
그것과 동시에 이슈를 자세히 적는 습관을 들어야겠다. 부실한 이슈 코멘트는 있으나 마나한것같다.

Kyu:

API 구현하는게 너무 밀린거 같아 일요일에 불타올라 빠르게 다 구현하고 오늘 아침까지 열심히 했던게 진행상황에 도움이 된것 같아 좋았다.

autumn:

오전 - 테스트코드에 대해서 수업 들음. Head가 루카스 개발할 때 테스트코드를 어떻게 작성했는지 보여주셨다. API가 나오기 전에 이왕 목데이터를 사용할 거라면 테스트코드를 작성하는 게 좋을 것 같다는 생각이 들었다. 헤드도 그렇다고 하셨는데, 어렵긴 할 거라고 덧붙여 말씀하셨다. 오후 - 크롱이 채용 공고를 보고 괜찮은 회사인지 판단할 수 있는 팁들을 알려주셨다. 오후 늦게 - 네이버 스마트에디터에 재직 중이신 우상훈님의 세미나?를 들었다.
로그인 부분 API를 MJ가 배포해주신 걸로 같이 쓰기로 바꿨는데, 그에 맞춰서 코드를 약간 수정해야 됐던 점이 살짝 귀찮기도 하고 어려웠다. callback url이 살짝 다른 사소한 문제가 있었다.
서버 쪽에서는 클라이언트에서 모든 요청 시에 header에 jwt 토큰을 담아서 보내야 정상적으로 응답을 주도록 되어 있다. 이것도 며칠 전에 바뀐 부분이라서, 이어몬이랑 나는 헤더에 담지 않고 계속 해왔는데 갑자기 이렇게 바뀌어서 당연히 계속 에러가 났다. 매 요청 때마다 똑같이 헤더에 담아 보내야 해서 공통 부분을 정의해둘 수 있지 않을까 싶어 찾아보니 axios 공식문서 에 config 설정에 대한 설명이 있었다. 저렇게 해보려다가 뭔가 잘 안 돼서 일단은 돌아가게 하자! 라고 이야기했고, 너무 중복이 많은 게 눈에 보이긴 하지만 모든 요청에 일단 header: ~~~ 를 써줘서 해결했다.
정말 오늘의 하이라이트였던 에러처리!! API 배포가 안 된 것들이 있어서 응답으로 에러가 왔는데, try ~ catch 를 사용해서 에러를 잡아주니까 화면이 터지지 않고 잘 나왔다. recoil이나 react에서 제공하는 에러 처리 방법이 있는 것 같긴 한데 아무리 읽어봐도 아직은 잘 모르겠고 try ~ catch 로 일단 썼다. 금요일부터 서버 쪽에 계속 알 수 없는 에러가 있었고 프론트 쪽에는 아무런 에러 처리를 안해놨고, 에러 처리 방법 구글링 해봐도 잘 모르겠어서 며칠동안 아무것도 안 나오는 흰 화면만 봤는데 오늘 드디어 화면이 나와서 너무 기뻤다. 🥺 에러처리의 소중함을 알게 되었다.
- 금요일부터 계속 봤던 에러는 500 에러였다.
- 첫 번째 문제는 로그인 API를 우리팀 꺼에서 MJ팀네 걸로 바꾸는 과정에서 콜백 url이 달랐다던지 등의 미묘한 차이점 때문이었던 것 같다. 프론트 쪽 Route path를 살짝 수정해서 해결했다.
- 두 번째 문제는 에러처리를 안 한 게 그냥 문제였다. 이 부분은 원인을 몰랐던 건 아니고 에러처리를 좀 멋지고 우아하게 해보고 싶어서 찾아보기만 하다가 시간만 질질 끌고 정작 잘 모르겠는 상태가 돼서 try ~ catch를 사용해서 급한 불만 꺼놨다. 나중에 에러에 대한 UI 만들기 등등 좀 더 친절한 에러처리를 하고 싶다.
- 500 에러에 관해서 궁금한 게 생겨서 Kyu에게 질문했다.
  
  요청할때 아직 토큰 담아서 보내는거 안했는데 500 에러가 나오거든요 검색해보면 500 내부 서버 오류는 일반적인 HTTP 상태 코드로 서버에서 문제가 발생하였으나 문제의 구체적인 내용을 표시할 수 없음을 의미합니다. 라고 나오는데
  
  궁금1: 500 이라는 에러코드는 규가 500으로 에러를 발생시킬 거야! 해서 짜놓은건가여?? 궁금2: 응답으로 에러 메시지 같은걸 같이 응답해줄 수도 있는건가여?? 유저 토큰이 없습니다 라던지 ..
  
  궁금1 답변: 아니요 ㅎㅎ 그냥 코드가 실행이 안될때 500이 나와요 특정 url로 들어갈때 그 url에 대해서 매핑하는 API가 있겠죠? 매핑하는 과정에서 여러가지 문제가 있을수있겠죠. 당장은 실행이 되는데 어텀이 접속하려면 에러가 나는거죠. 예를 들면 JWT 안담아서 보내는 것도 그 일종이죠, 왜냐면 코드에서는 JWT 가 없으면 접근이 안되도록 되어있으니까요
  
  궁금2 답변: 해보진 않았는데 찾아보면 하는 방법이 있을거예요, 예를들면 404 페이지를 찾을수없습니다도 보면 서비스하는 웹페이지마다 이쁘게 꾸며놨잖아요? 그런 개념이죠
  
  계속해서 500 에러를 받았을 때 대체 에러가 왜 나는 건지 알 수가 없었기 때문에, 서버 쪽에서 에러의 이유를 같이 보내줄 수 있다면 보내줬으면 좋겠다 라는 생각이 들었다.

Issac :

0622 화요일 회고

eamon: 수정 UI 를 가지고 만 하루가 넘게 진행이 안되고 있다. 문제의 원인은 두가지 내의 절대적인 코딩시간이 적은 것이랑 내가 하다가 다른 것 작업을 하는 것이다.

첫번째문제는 그렇다 치고 두번째는 나쁜 문제라고생각하지 않는다. 공부하는 입장 + 협업하는 입장에서 오톰과 현재 해결할수있는 혹은 급한 일부터 같이 이야기하면서 먼저 해결하는 과정이 에자일하다고 생각하기 때문에 내가 원래하려고 했던 일이 뒤로 밀린다고 조급해하진 말자 하지만 원래 하려던일이 급한일이 되기전까진 마무리해야하니까 조절을 하자.

이번 미션은 특히 api 요청이 많은 것같다. 그것과 더불어 백엔드와 긴밀하게 소통이 필요했던 것 같다. 평소보다 더 소통을 유의하게 했었어야했는데 처음의 부실한 설계가 지금에 영향을 끼치는 것 같다.

백엔드의 상황을 프론트가 조금더 자세하게 알고있어야 백엔드에게 요청할때 마음이편해진다는 것을 느꼈다. 배포가 다른 서버인지 코드가 같은 코드인지 누가 이걸 했는지 모르다보니 누구한테 상담(?)을 받아야할지 모르겠다. 사실 그래서 깃헙에 담당자가 있는 것인데 깃헙을 제대로 협업도구로 활용못하고있다고 느꼈다.

협업에 대한 반성으로 오늘 하루는 마친다 ㅠㅠ

Kyu:

MJ와 같이 협업하면서 각각 다른 팀원분들에게 변경사항들을 잘 전달하지않아 나중에 여러 이슈가 발생함. 변경사항을 전달하는 것과 의논할/한 것들을 관리하는 것도 능력이라고 생각.

autumn: 오늘은 좀 지친 하루였다. 호기롭게 이슈 상세 페이지를 시작했는데 백엔드 분들과 소통의 부재로 많은 어려움이 있었다. 🥺

문제1

Kyu와 MJ의 협업이 어떻게 이루어지고 있는지 잘 파악하고 있지 못했다.

어느 정도까지를 같이 개발하고 두 팀이 어떤 API를 공유하고 있는지를 잘 몰랐다. 아무래도 나랑 이어몬이 백엔드 쪽 작업을 잘 모르다보니까 Kyu도 설명해주시기 애매했던 부분도 분명 있었을 거라는 생각이 든다. 백엔드 공부도 해야겠다는 생각을 요즘 많이 한다.

문제2

백엔드 쪽에서의 변경 사항을 알려주시지 않아서 프론트가 잘 몰랐다.

두 팀이 같은 API를 사용하는 과정에서 Kyu, MJ가 각각 다르게 개발을 하다가 언제부턴가 합치신 것 같다. 그래서 원래 알고 있던 API에서 갑자기 바뀌어 있는 것을 오늘 발견하고 두 팀이 모두 모여 함께 회의해서 합의점을 찾아나갔다.

문제3

문제2와 비슷한데 API 문서 업데이트가 잘 안 되었다.

문서와 실제 API가 다른 부분도 있었고, 배포된 버전의 포스트맨 API 문서 url을 우리팀 프론트에게 알려주시지 않아서 이어몬과 나는 옛날 문서를 보고 있었다.

이번 프로젝트에서는 화면에 표시해야 하는 거의 모든 요소를 서버에서 받아야 하다 보니까 서버와의 통신이 많아지게 되었고, 그만큼 서로 잘 소통하는 것이 더 중요해진 것 같다. 백엔드도 개발하느라 바쁠 텐데 변경 사항을 다시 프론트에게 알려주고, 문서 업데이트도 부지런히 & 알아보기 쉽게 해야 한다는 점에서 백엔드 개발 또한 엄청 꼼꼼함이 필요하겠다는 생각이 들었다.

프론트의 입장에서는 개발하다 보면 어쩔 수 없이 API 수정 요청을 많이 하게 되는데 말씀드릴 때마다 너무 죄송스럽다.. 하지만 미안한 마음에 요청을 미루게 되면 더 큰 산사태가 날 거라는 걸 알기 때문에 꿋꿋이 요청을 하고 있다. 하하 🤓

오늘 힘든 점도 많았지만 좋은 점도 있었다. 새벽에 Kyu의 서버가 터졌는데 MJ의 서버로 바꿔서 사용할 수 있었다. 👍 도커를 사용하면 로컬 환경에서 서버를 돌릴 수 있기 때문에 aws에서 서버가 꺼지더라도 문제 없이 사용할 수 있다고 한다. 이걸 이제 알다니! 다음엔 도커를 사용해봐야겠다.

Issac :

0623 수요일 회고

eamon:

Kyu: https://velog.io/@kyukim/20210623

autumn:

오전에는 사람들이랑 잡담하고 놀다가 시간을 다 보냈고, 오후에는 화면 그래픽이 깨져보이는 것 때문에 애플지원에 연락하다 보니 금방 또 수업 시간이 되었다. 오후 늦게에는 우테캠 발표가 있었는데 내가 괜히 들뜨고, 속상하기도 해서 코딩이 손에 안잡혔다.
타입스크립트를 쓰면서, 그리고 이번 프로젝트 특성상인지 모르겠는데 비슷한 속성 값이 너무 많아서 헷갈린다. 따로 타입 설계는 하지 않고 그때그때 타입을 만들었는데, 그러다보니 나도 모르는 사이에 중복되는 타입을 계속 만들어내기도 하고 정리가 잘 안 되는 느낌을 받았다. 다음부터는 타입 설계도 좀 해봐야겠다는 생각이 들었다.
협업을 하다 보니 내 맘대로 파일을 건드리거나 이름을 바꾼다거나 할 수가 없어서 코드가 많이 지저분해졌다. 그렇다고 너무 모든 설계를 함께 하는 것도 피곤하고 어려운 일이다. 항상 균형을 잡는 일이 제일 어려운 듯..

Issac:

0624 목요일 회고

eamon:

Kyu:

autumn:

이슈 상세 페이지의 ui 요소들을 살짝 손봤고 (코멘트에 아바타 표시 등 자잘한 것), 코멘트 생성 기능을 중점적으로 구현했다. 로직 자체는 어렵지 않았는데 네트워크 쪽에서 자꾸 에러가 나서 에러 해결하느라 몇시간을 보냈다. 과정은 다음과 같다.
- 이번 프로젝트에서는 axios를 이용하고 있다.
- 코멘트를 작성하고 post 요청 시 500 에러가 났다.
- 이 과정에서 header에 Authorization 을 넣지 않았다는 걸 알았다. 넣지 않았던 이유는, 어제 이어몬이 토큰 안 넣었는데도 네트워크 탭에서 보니 토큰이 들어가있다고 해서 axios가 캐시를 해주는 건가 싶었다. 그런데 토큰을 안 넣어주면 안 들어가는 게 당연히 맞았다.
- 토큰을 넣어 보냈는데도 에러 발생. 발생했던 모든 에러코드가 다 기억이 나지는 않는데, 404, 415, 500 다양하게 났던 것 같다. url에 뭘 빼먹어서 그것도 고쳐보고 Content-type: application/json 도 넣어보고 (근데 axios는 알아서 json으로 변환해서 보내주기 때문에 이건 필요 없었다. 처음 안 사실!) 했는데도 해결이 안 됐다.
- 혹시나 싶어서 서버 url을 MJ네 걸로 바꿨는데 된다..?! 이 때는 Kyu가 코멘트 작성 부분을 깜빡하고 배포를 안 해놨나보다, 이렇게 생각했다.
- 이 로그를 사실 하루 지나서 쓰고 있는데 오늘 아침에 Kyu, Pyro까지 다 모여서 같이 디버깅하다가 원인을 찾아냈다. 로그인 요청을 MJ네 주소로 보낸 것이 문제였다. 문제해결 에 써두었다.
백엔드 쪽에서도 섬세한 에러처리가 정말 중요하다는 생각이 들었다. 그냥 500 에러라고만 뜨면 뭐가 문제인지 알 수가 없어서 삽질을 많이 하게 된다. ㅠㅠ (+ 프론트에서도 에러 처리가 중요한 건 마찬가지. 에러처리를 하지 않으면 화면이 아예 안 나와버린다.)
백엔드 개발을 해본 적은 없지만, 만약에 백엔드 개발을 하게 된다면 프론트와 어떻게 협업을 해야할지, 다음에 또 백엔드 개발자와 협업할 때 어떤 것들을 요청해야 할지 경험적으로 알게 되었다!
더불어서 백엔드 분야 공부와 네트워크 공부의 필요성이 너무너무 느껴진다. 아는 게 없으니 소통에 한계가 느껴진다.

Issac:

0625 프로젝트 마지막 날 회고

eamon:

Kyu:

autumn:

프로젝트의 마지막 날이자 코드스쿼드 마지막 날! 느즈막이 공간에 나가서 수료식도 하고, 오랜만에 동료들도 보고, 크롱도 뵙고, 맛있는 저녁도 먹었다. 😋
우리의 프로젝트는 끝나지 않았지! 한 주 더 한다~

Issac: