%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8 2%EC%A3%BC%EC%B0%A8 %ED%9A%8C%EA%B3%A0%282022. 6. 20. ~ 6. 24.%29 - ikjo93/issue-tracker GitHub Wiki

익조

• 오늘은 저번 숙소 예약 서비스 팀 프로젝트 때 구현했었던 JWT를 통한 로그인 검증 부분을 리팩토링해보았다. 저번 구현 시에는 토큰을 단순히 문자열로만 관리하고 있었는데, 지난 리뷰어 토큰을 Dan이 객체를 통해 관리하는 것을 권장해주었다. 예상치도 못한 내용이었는데, 지난 번 팀 프로젝트 때 당시 남은 시간이 얼마 있지 않았기에 다음 프로젝트 때 리팩토링하는 것을 목표로 했었다.
• 마침 이번 팀 프로젝트에서도 미션 요구사항 중 JWT를 통한 로그인 검증하기가 있었기에, 도전해보기로 했다. 리팩토링 시에는 지난번 Dan이 공유해주었던 자료를 참고하였다. 처음에는 굳이 이렇게까지 해야되나 싶었지만 한번 해보기로 했다.
• 결론적으로 문자열로 돌아다니던 토큰을 access 및 refresh 각각의 토큰 객체를 만들어 관리하도록 구현했다. 리팩토링을 통해 이전 보다 더 개선되었던 점은 기존에는 토큰을 문자열로 관리했었기에 토큰이 가는 곳마다 검증 로직과 jwt 관련 상수들이 따라다녀야만 했었다. 하지만 객체로 관리한 덕분에 객체 내에서 검증 로직을 처리할 수 있고 관련 상수들도 상태값으로 둘 수 있었다. 즉, 유지보수의 용이성이 증가했다고 볼 수 있었다.
• 또한 각각의 토큰 객체는 비슷한 메서드와 상태를 지니고 있으므로 이를 인터페이스화하여 호출 메서드에 대한 표준화 할 수 있었다. 이는 아직 당장은 와닿진 않았지만 혹시라도 추후에 access나 refresh 토큰 외에 다른 토큰이 추가되었을 때 신규 생성에 유리하고 사용자(개발자) 입장에서도 일관된 형식의 메서드를 호출함으로써 개발의 편익을 제고시킬 수 있을 것이라고 생각됐다.

파크

• 오늘은 앨런과 한 주의 계획을 대략적으로 짜보았습니다. 일단 이번주 내에 요구사항에 있는 모든 기능들을 구현하고 마지막 3주차에서는 해당 기능들의 테스트 코드를 작성한 이후 리팩터링을 진행하는 방향으로 이야기를 나누었습니다. 생각보다 페이지의 수가 많아서 가능할지는 모르겠지만 최대한 실현해보고자 이야기를 나누었습니다.

앨런

• 오늘은 디폴트 페이지의 기능을 전부 완성했습니다. table header에 있는 체크박스를 클릭했을 때 cell에 있는 체크박스들과의 연결 로직을 구현했는데, 아주 간단하지만 은근히 코드가 지저분해지는 느낌을 받았습니다. 이래서 상태관리 라이브러리를 쓰나 싶은...
• 그리고 오늘 개인적으로 기쁜 소식이 있었어서 그래도 자축하는 의미로 맛있는 저녁과 함께 맥주 한잔을 하고 게더에서 담소를 나누는데 시간을 썼습니다. 😃

익조

• 오늘은 그동안 도메인 설계와 애플리케이션 개발에 정신이 팔려 하지 못하고 있었던 배포 작업을 진행했다. 스프링 부트 웹 앱을 우선적으로 배포 진행했는데, 이번 배포 시에는 별도로 도커 네트워크를 지정하고 고정 IP 주소를 사용하도록 했다. 그런데 예상치 못한 부분에서 삽질을 하게 되었는데, 바로 Git과 관련된 내용이었다.
• 배포 이전에 애플리케이션 개발을 하던 중 자바 소스코드 파일명(클래스명) 중 MileStone이라는 단어를 Milestone으로 변경한 적이 있었다. 이렇게 파일명을 바꾼 것은 운영체제가 관리하는 파일시스템에 의한 것인데, 문제는 Git이 이를 추적을 하지 못한다는 점이었다.
• 이는 Git의 경우 최초 ignorecase 속성이 true로 설정되어 있어 대소문자를 구분하지 않기 때문이었는데, 나의 로컬 환경에서는 분명 S를 s로 바꾸었지만 git에서는 앞서 저장소에 저장되어있던 S를 그대로 인식하게 되었다. 결론적으로 이로 인해 깃허브 액션을 통해 배포하는 과정에서 빌드 시 오류가 발생하게 되었다.
• 이러한 문제는 git의 ignorecase 속성을 false로 변경(git config core.ignorecase false)하거나 또는 일일이 파일명을 변경(git mv MileStone Milestone)하여 해결할 수도 있었다.

파크

• Create Issue Page 를 만들다보니, 로그인된 사용자에 대한 정보가 필요하다는 것을 어떻게 적용해야할지 고민해보았습니다. 이 과정에서 나에대한 정보를 가져올 수 있는 커스텀 훅을 만들어보면 어떻겠냐고 이야기를 나누어보기도 했고, 거기에서 쓰일 API 등을 익조에게 요청하기도 했습니다.
• default page 에서 쓰이고있던 상태들의 depth 를 높일 필요가 있다고 판단하여 앨런과 이야기한 이후 lables, milestone 등 상태가 어느곳에 존재해야할 지에 대해서 이야기를 나누었습니다.

앨런

• (작성대기)

익조

• 오늘로 벌써 마지막 팀 프로젝트 기간도 절반에 달했다. 그래도 그동안 3번의 팀 프로젝트를 진행하면서 나름대로 열심히 하면서도 그래도 약간의 여유를 느끼곤 했었는데, 이번 미션 과제의 경우는 왠지 첫 날부터 마지막 날까지 굉장히 정신이 없을 것 같다. 개인적으로는 지난 팀 프로젝트들 대비 이번 팀 프로젝트 미션 과제가 좀 더 헤비(?)한 느낌이다.
• 기능을 구현하고나면 해당 기능에 대해 프론트 엔드 팀원들께서 (프론트 엔드 작업 관련) 피드백을 주시는데, 이를 통해 다시 기존 기능들을 보완 및 개선하는데 드는 시간도 만만치 않았다. 하지만 그 요청사항들을 적용하는 과정에서 오히려 내 서비스 로직이 이전 보다 개선되는 것을 확인할 수 있었다.
• 사실 이번 팀 프로젝트 뿐만 아니라 지난 팀 프로젝트를 하면서도 느낀 것이 백엔드 입장에서 개발을 하다보면 "사용자 입장에서" 생각을 하지 못할 때가 많은 것 같았다. 프론트 엔드 팀원들과 같은 기획서를 봐도 백엔드는 어떻게 하면 API를 클라이언트에 제공할지에 초점을 둔다면, 프론트 엔드에서는 어떻게 하면 사용자 입장에서 편익을 느끼는지에 대해 초점을 맞추는 것 같다. (개인적인 느낌과 경험이다.)
• 이로 인해 어떤 API를 구현하더라도 이에 대해 프론트 엔드 팀원들의 피드백 사항들에 대해 적극적으로 반영하고자 하는 마인드를 가질 필요성을 느끼고 있다.

파크

• 익조가 작성해주신 API 의 구조를 프론트엔드에서 최대한 사용자의 경험이 좋을 쪽으로 수정해보려했습니다. 가령 레이블 탭을 눌렀을 때 맨 처음 불러온 데이터를 기반으로 보여주기보다 맨 처음 페이지가 로딩되고 그 이후 레이블이 추가되거나 수정되었다면 해당 데이터가 보여져야 하기 때문에 해당 API 를 별도로 분리한다는 등의 개선을 요청드렸고, 흔쾌히 동의해주셔서 너무 감사했습니다.
• 이외에 default page 에서 쓰이는 컴포넌트의 디자인적 구조가 비슷하다고 느껴지는 부분을 재사용하기 위해서 컴포넌트가 가지고 있는 역할에 대해서 고민을 좀 더 해보고 역할을 분리하여 재사용할 수 있도록 개선해보았습니다.

앨런

• (작성대기)

익조

• 마지막 팀 프로젝트의 절반이 넘어가는 시점 이제 슬슬(?) 데드라인의 압박(?)이 느껴지고 있다. 🤣 마스터즈 코스 과정의 장점(?)은 각 미션마다 다소 짧은(?) 제한 시간이 주어지는데, 나태해질 겨를 없이 미션 과제 수행을 위해 정신 없이 프로그래밍을 하게 된다는 점이다. 이는 물론 나중에 현업에 들어가서도 마찬가지일거라는 생각이 든다. 💦
• 아무쪼록 마지막 미션 과제인 만큼 난이도도 어려운데, 진도가 빨리 빨리 나가지 못해 조급한 마음도 든다. 이번주는 기능 구현보다는 프론트 엔드와의 연동 과정에서 발생하는 오류들에 대응하고 팀원들의 추가적으로 수정이 필요한 사항들을 처리하느라 상당한 시간을 소모하게 되었다.
• 특히, 연동 과정에서 발생하는 오류들을 처리하느라 시간을 가장 많이 썼는데, 백엔드인 나의 실수로 인한 부분이 굉장히 많았다. 개발할 때는 나름대로 철저하게(?) 코드를 작성했다고 생각했었지만, 실제 연동 과정에서 곳곳에 빈틈들이 굉장히 많았다. 하나를 처리하면 다음 문제가 발생하고 이런 식으로 많은 시간들이 지나만 갔다.
• 이번 미션 과제를 하면서 약간의 벽(?)을 조금씩 느끼고 있지만 일단 내가 할 수 있는 것에만 집중하고자 한다. 차근차근 하다보면 또 좋은 결과가 있을 것이라고 기대해본다.

파크

• 이전 미션들을 하면서 개인적으로 OAuth 를 구현해보기도 했고, 로그인 관련한 로직을 직접 서버를 만들어서 시도해봤던 경험이 있어서 이걸 내가 주도적으로 진행하기보다는 앨런이 직접 삽질을 해보면서 해보는게 좋을 것 같다는 생각으로 앨런에게 로그인 기능구현을 권유했는데 흔쾌히 동의하셔서 앨런은 로그인 로직, 저는 기타 페이지들을 작성하는 것으로 진행했습니다. 로직이 조금씩 막힐때 마다 막히는 부분에 대해서 이야기해보는 식으로 프로젝트를 진행했습니다.
• 다만 이미 알고있다고 생각했던 로직들이 익조와 이야기 하면서 조금 다르다는 것을 느꼈고, httponly, refresh-token, access-token 을 기반으로 로그인 로직을 만드는 것에 대한 새로운 인사이트를 얻을 수 있었습니다.

앨런

• 오늘은 Oauth 기능을 구현하는데 시간을 썼다. Oauth 과정에 대해 익조와 파크가 여러 좋은 글들을 공유해주셔서 미리 어느 정도 이해를 할 수 있었고, 직접 구현하며 더 잘 이해하게 된 것 같다. 실제로 동작시키기 위해서 코드를 작성하는데, 오랜만에 코드를 잘 작성하기 위해 머리를 쓴게 아니라 에러 원인을 찾고 해결하는데 시간을 쓴 것 같다. 서버와의 통신과정에서 발생하는 문제나, 로직 문제 등이 있었는데, 상태 코드가 디버깅에 큰 힌트가 되기도 했다.
• 사실 이번 프로젝트는 처음부터 백엔드 요구량이 많다고 생각했다. 프론트의 경우 기능 자체는 어려운 것이 없고 페이지 수만 좀 많았는데, 파크가 워낙 잘하시기도 하고, 그동안 화면 구현은 많이 익숙해져서 크게 힘들지는 않은 것 같다. 그래서 백엔드의 부하를 줄이는 방법에 대해 고민이 더 된다.
• 개인적으로는 오늘 아주 재밌었다. 에러를 직접 해결할 일이 많지는 않았지만, 에러 원인을 찾으며 여러가지 부분에 대해 얕은 지식을 추가한 느낌이라 좋다.

익조

• 매주 금요일은 팀별로 전체 공유 시간을 가지고 백엔드 수강생들과 함께 기술 세션 시간을 가진다. 한 주 동안 작업했었던 것들을 다같이 공유하는 시간으로 "같은 미션 과제"를 수행하면서도 각 팀원들마다의 관심사가 다르고 추진하는 방향도 가지각색의 형태에 있었다.
• 나 같은 경우 미션 과제를 수행하다보면 다른 사람들의 코드를 보지 않고 나만의 코드를 작성하려고 하는 편인데 (생각이 고정되는 것을 막고자) 코드를 다 작성하고나서도 다른 사람들이 작성한 것들을 보지 않다보니 나만의 생각에 갇히게 되는 문제가 있었다.
• 그래도 이렇게 전체 공유 시간과 백엔드 수강생들간의 기술 세션을 통해 더 좋은 방법들과 나의 부족한 점들도 발견할 수 있었다. 아울러 마스터즈 코스 과정이 끝나면 그간의 학습 내용들을 정리하면서 다른 팀원들은 어떻게 문제를 해결했는지에 대해서도 알아보고 싶다는 생각이 들었다.

파크

• 결국 로그인 기능을 마무리하지 못했고, 모든 페이지 구현을 마무리하지도 못했지만, 모든 페이지 구현은 월요일 정도만 더 하면 될 것 같습니다. 솔직히 불가능한 일정이라고 생각했었는데 중간중간 이슈가 생겼던 것에 비하면 일정을 잘 세운 편이라고 생각이 들었습니다. 월요일에 남은 페이지 구현 마무리하고, 로그인 기능을 마무리한 이후 꼭 리팩터링을 진행했으면 좋겠습니다.

앨런

• (작성대기)