프로젝트 3주차 회고(2022. 6. 27. ~ 7. 1.) - ikjo93/issue-tracker GitHub Wiki

익조

• 전체 내용 : https://ikjo.tistory.com/270
• 3주 동안 진행되는 이슈 관리 서비스 구현 팀 프로젝트를 하면서 최초 1주차 때에는 "어떻게 풀어나가야할까?" 등 웹 앱 구조에 대한 설계 부분에 대해 고민이 많았었기에, 별다른 기능 구현 내용이 없었다. 2주차부터는 주요 기능부터 하나하나 구현해나가기 시작하면서 웹 앱의 모양새(API 등)를 갖추어 나갔었다.
• 3주차인 오늘부터는 본격적으로 각각의 도메인에 대한 CRUD 관련 API 구현 작업을 진행해나갔다. 1~2주차 때에는 기능 구현 속도가 더뎌 "이거 3주안에 다 할 수 있을까?" 하는 걱정이 많았었는데, 막상 3주차에 와서 보니 묵직한 몇개 기능을 제외하고 단순히 조회, 생성, 수정, 삭제만을 수행하는 API를 만드는 것은 큰 어려움이 없었다.
• 내가 이번에 이 웹 앱에 대해 설계한 내용이 올바른지, 그른지 판단은 힘들지만, 적어도 처음에 어떻게 설계하는지에 따라 나중에 기능 구현함에 있어 얼마나 많은 유연함을 제공하는지가 결정된다는 느낌을 받을 수 있었다. 스프링 웹 앱을 구현하면서 지난 자바 웹 프로그래밍 과정에서 자주 배웠던 역할과 책임 분리, 개방 페쇄 원칙 등 객체 지향적 설계의 중요성을 몸으로 체득할 수 있었던 것 같다.

파크

• 커스텀하게 만들어서 사용하고 있던 useAxios 에 더 필요한 로직이 생겨서 해당 부분을 추가하고 관련된 로직을 드러내느라 시간을 많이 쓴 하루였습니다. 한번 data 를 fetch 한 이후 다시 re-fetch 할 수있는 dependencyList 가 필요했는데, refetch 함수를 별도로 만들어서 필요로할 때 데이터를 다시 fetch 받을 수 있게 만들었습니다.
• 목표로한 페이지 구현은 많이 하지 못했지만 useAxios 의 로직이 필요해진 것을 추가해서 사용하니 더 간결해짐을 느껴서 기분이 좋았습니다.

앨런

• (작성대기)

익조

• 전체 내용 : https://ikjo.tistory.com/271
• D-4, 오늘은 수료하기까지 4일이 남은 날이다. 🤣 이번 팀 프로젝트 과제의 경우 마지막 미션 과제답게 애플리케이션 개발 부분에서 해야할 작업들이 굉장히 많았다. 마스터즈 코스를 하는 동안 여유로웠던 적은 많지 않았음에도 불구하고, 단언컨대 이번 미션 과제를 수행할 때가 가장 정신없이 하루하루를 보내고 있는 것 같다. 😂
• 이제 어느 정도 애플리케이션 개발을 마치고 부랴부랴 배포를 하면서 클라이언트와의 연동을 테스트 해봐야하는 단계이다. 이제부터는 추가 기능 구현 보다는 연동 과정에서 일어나는 오류들을 처리하는데 많은 시간을 할애하게 될 것 같다.
• 요즘 수면패턴도 붕괴(?)되어 밤낮이 바뀐채로 하루를 지내고 있는데, 이러한 상황을 이해해주시고 스크럼 시간을 탄력적으로 조정해주시는 프론트 엔드 팀원들께 감사한 마음이 든다.

파크

• 슬슬 목서버의 한계를 느끼는 것 같습니다. issue 와 milestone 간의 관계를 연결지어서 handler 를 어떻게 작성해야할지에 대한 고민이 생겼습니다.
• 목표로한 모든 페이지 구현은 하루가 더 걸렸지만 이정도면 나쁘지 않게 시간이 걸린게 아닐까 생각하고 있습니다. 이제부터 테스트코드와 성능개선에 초점을 둘 텐데 남은 3일(사실상 2일) 이 어떻게 될지..!

앨런

• 오늘은 많은 구현을 하진 않고 이슈 디테일 페이지 기능을 조금 추가했습니다. 파크가 많이 수고해주셔서 감사한 마음과 미안한 마음이 뒤섞인..ㅎ 저녁에는 배포작업을 했는데 redirect와 rewrite의 차이를 알게 되고, 별 생각없이 했던 webpack 설정이 뜬금없이 더 자세히 와닿게 되는 시간이었습니다..ㅎ 다행히 성공적으로 배포가 되어서 내일은 디버깅을 해야될 것 같습니다. react-router에서 context를 적용하는 문제나, 몇몇 API 스펙에 맞지 않는 사용들을 수정해야할 것 같습니다. 파이팅!

익조

• 전체 내용 : https://ikjo.tistory.com/273
• 마지막 팀 프로젝트인 이번 이슈 관리 서비스 미션의 경우는 앞서 구현했었던 JWT 로그인 검증 기능을 활용하여 구현 자체에는 많은 시간을 절약할 수 있었고 지난 리뷰어 단이 피드백 사항으로 주셨던 토큰을 객체 형태로 관리하는 방향으로 리팩토링을 진행하여 기존 코드를 개선시킬 수 있었다.
• 그리고 마침내 프론트 엔드와 직접적으로 연동해볼 수 있었는데, 그 과정에서 프론트 엔드에서 로컬 환경에서 API 서버에 있는 API를 호출할 때 발생하는 CORS와 관련하여 여러 이슈들을 만나볼 수 있었다. 예전부터 클라이언트 단에서 쿠키 값에 접근하지 못하는 이슈를 종종 목격했었는데 이는 SameSite와 관련된 이슈였고 충분히 학습해볼만한 내용들이었다.
• 액세스 토큰의 경우 세션과 달리 서버와 클라이언트간 헤더에 값을 실어 주고받았는데, 클라이언트 입장에서는 (새로고침 등의 상황에서) 사용자 상태 유지를 위해 별도의 로직을 통해 토큰 값을 관리할 필요가 있었다. 이를 위해 클라이언트에서 많이 애써주셨다.
• 또한 서버에서의 별다른 리다이렉트 없이 클라이언트에서 라우터라는 기술을 활용하여 화면 전환이 가능하게끔 했다. 다만, 서버 단에서는 이를 위해 웹 서버인 Nginx에서 별도의 path 설정이 필요했다. 처음에는 return, rewrite을 사용했다가 같은 프론트 엔드 팀원께서 try_files라는 키워드를 제시해주신 덕에 문제를 해결할 수 있었다. 이를 해결하는 과정에서 그동안 내가 알고있었던 Nginx 사용법은 정말 새발의 피라는 사실을 깨달을 수 있었다. Nginx 자체만 해도 굉장히 깊이가 있는 분야였다.

파크

• 오늘부터 꼭 테스트코드를 짜봐야지! 생각을 하고 간단히 데모페이지를 QA 해보는 과정에서 이미지업로드 기능과 실제 issue detail 화면에서 보여질 텍스트 뷰어 부분을 손보고 싶다는 욕심이 생겨서 이미지 전송과 markdown parser 에 대해서 구현을 하게 되었습니다.
• 프로젝트 셋업을 할 때, style reset 하는 것을 선호하는 편인데, markdown parser 로 parsing 된 태그들을 보니 css가 reset 되어 적용되어지지 않는 문제가 있었고 관련 현상을 해결하기위해 github-markdown-css 라는 라이브러리를 사용해 덮어씌우는 것을 선택했습니다. 이미지 전송은 formData 라는 객체를 사용해보았는데, 실제로 어떻게 data 가 주고 받아지는지를 개발자도구의 network tab 에서 확인하며 신기함을 느꼈습니다. 실제 마크다운으로 텍스트가 보여지는 모습을 보았을 때는 너무 짜릿했습니다.

앨런

• (작성대기)

익조

• 전체 내용 : https://ikjo.tistory.com/274
• 6월 한 달 동안 잠을 줄이면서 팀 프로젝트 등 학습을 진행해서 그런지, 몸살 기운이 있어 오늘은 학습을 많이 하지 못했다. 생각해보니 지난 3월말 웹 서버 구현 미션을 진행할 때도 이런 비슷한 몸살 기운이 있었는데 뭔가 3개월을 주기로 오는듯 하다. 😂
• 다행인건 며칠 전 이번 기획서에서 요구하는 기능들에 대한 API는 모두 구현해놓아 추가적으로 구현할 작업이 있진 않았다. 대신, 프론트 엔드와의 연동 과정에서 발생하는 일부 오류들에 대해서 보완 작업들을 진행했으며, 수요일 리뷰어가 남겨주신 피드백을 일부 보완하는 시간을 가졌다.

파크

• 크롱이 간단히 리뷰를 해주었던 부분에서 디렉터리 구조에 대한 부분이 있었습니다. 실제로 프로젝트의 디렉터리 구조는 depth 가 너무 깊기도 하고, 재사용이 되어지는 컴포넌트임에도 불구하고 특정 컴포넌트 디렉터리에 존재한다는 점이 이상하다고 느끼고 있었을 때 였습니다. 그래서 앨런과 이야기한 후 페어로 디렉터리구조를 갈아엎었고, 아토믹구조와 pages, templates 등 어떻게 나누는게 좋을 지 고민이 많이 되었지만 이미 컴포넌트들이 많이 만들어져있는 상태여서 page 별로 사용되는 것을 크게 나누고, 공통적으로 사용되는 것을 작게 나누면서 왜 아토믹 구조에 대한 고민이 생겨났는지를 느낀 작업이었습니다.
• 이외에 같은 디자인이라고 해서 재사용하고 있었던 컴포넌트가 필요없는 데이터를 요청하는 로직을 담고있어서 컴포넌트의 역할에 대해서 다시 나누고 디자인만 가져와서 사용할 수 있도록 컴포넌트를 분리하는 과정을 가졌습니다. 컴포넌트를 어떻게 나누어야 할지 (디자인이 같으면? 혹은 그 컴포넌트가 갖고있어야 하는 상태?) 를 좀 더 고민해봐야겠다는 생각이 들었습니다.

앨런

• (작성대기)

익조

• (작성대기)

파크

• 원했던 테스트코드작성과 리팩터링 과정을 거치지는 못했지만 데모를 위한 테스트를 이번주 내내 진행하면서 실제 배포를 위한 테스트의 기간을 충분히 잡아야겠다는 생각을 했습니다. 실제 배포환경에서만 생길 수 있는 예기치못한 버그가 생길 수도 있고, 늘 데모페이지를 보여줄 때에만 보이는 버그가 있었기 때문입니다. 데모를 위한 테스트 기간을 길게 잡으니 실제 데모를 할 때에 버그가 존재하지 않았고, 공유시간에 당당히 url 을 공유하여 사용해볼 수 있도록 한 경험이 좋았습니다.

앨런

• (작성대기)