2주차 개인 회고

J016 김동민

😎 Keep

이번 주의 개인적인 목표는 팀원들의 코딩 스타일 이해와 실제 개발을 진행해보는 것으로 앞으로의 협업 방향을 설정하는 것이었습니다. 나름 잘 수행한 것 같아 고무적입니다.

• 페어프로그래밍을 진행하면서 팀원들의 코드스타일, 사고의 흐름등을 잘 살펴볼 수 있어서 앞으로의 개발에도 많은 참고가 될 것같습니다.
• 함께 오프라인으로 있으면서도 파트를 나누어 개발을 진행, PR과 머지하는 것 까지 진행해봄으로써 차주부터 분업을 어떤 식으로 진행하면 좋을지 감을 잡을 수 있었습니다.
• 금주에 진행한 내역을 블로그에 잘 정리해둔 것 같아 뿌듯합니다.
• 수요일에 SDC 컨퍼런스와 타입스크립트 실전 경험 올리기 특강을 듣는것으로 많은 학습이 되었습니다. 듣고 느꼈던 점이나 배웠던 것을 잘 정리해두었고, 차후에 잘 적용할 수 있기를 바랍니다.

🦇 Problem

• 개발, 학습정리, 컨퍼런스와 특강 수강등 많은 일들을 처리하면서 시간관리가 잘 되지 않는다는 느낌을 받았습니다.
• 학습정리는 잘 되고 있는듯 하지만 개발하면서 만난 문제나 사고흐름등을 기록해야할 개발기록은 잘 정리되지 않고 있습니다.

🧼 Try

• 차주부터는 주별, 일별 해야할 일들을 잘 관리하고 그에 따라 수면시간도 잘 조절하면서 체력또한 잘 관리해야겠습니다.
• 개발을 진행할 때 구현에만 집중하지 않고 만난 문제에 대한 정의, 해결한 과정과 방법, 배운점과 느낀점 등을 노션과 위키에 잘 정리해야겠습니다.

🫂 피어세션 피드백

• 수학적인 내용이 많아보이는데, 개발이나 기술이 아닌 수학적인 이론에 너무 많은 시간투자를 하는 것은 위험할 수도 있다는 피드백을 받았습니다. 어느정도 동감하는 부분이라 수학적인 지식에 대해서는 어떤 부분이 무슨 역할을 수행하는지 정도에 대한 대략적인 이해만 하고, 왜 그렇게 해야만 하는지에 대한 깊은 이해까지는 크게 생각하지 않으려고 합니다.
  • 프로젝트의 진행상황과 학습정리 등을 미루어 보아 금주에 많은 시간투자를 한 것으로 보이는데 프로젝트 초반부터 너무 무리하면 위험할 수도 있다는 피드백을 받았습니다. 마찬가지로 동감하는 부분이라 시간과 체력관리에 주의해야겠습니다.

J053 박재하

한마디

이번 주는 TDD 때문에 울고 웃었던 한 주였습니다. 페어 프로그래밍 시간이 화/목밖에 없어 시간 압박이 좀 있었는데, 화요일에 이렇다할 성과가 없으니 제가 조바심이 나서 돌이켜보니 좀 예민했던것 같기도 하네요.. 반성

그럼에도 정말 미친 체력으로 목요일 엄청난 양의 페어프로그래밍도 함께 마치고 추가로 Swagger까지 적용해주신 준섭님 정말 존경하고, 저도 운동 열심히해서 체력도 멘탈도 강인한 개발자가 되어야겠다는 생각을 했습니다. 흑 그리고 발표 빠뜨려서 죄송해요,, 하트❤️

Keep

• 기록하며 개발하기
  • 따로 시간을 내는 것보다 훨씬 효율적이고
  • 이런 기록은 비슷한 문제의 해결에 실질적인 도움이 많이 되는 것을 절실히 느꼈습니다. Keep going!
• 페어 프로그래밍할 내용 미리 학습 정리하기
  • 막연히 만나기보다, 미리 어떻게 개발할 지를 손만 움직이면 될 수준으로 미리 알아봐두니 개발 시간을 현저히 단축시킬 수 있었습니다.
  • 앞으로도 가능한 이렇게 미리 학습하고, 개발하는 습관을 들이면 좋겠습니다!

Problem

• 백로그의 중요성
  • 백로그가 Story 기반으로 모호하게 작성되다보니 여기에 맞추어 개발하기가 상당히 힘들고, 커밋을 할 때도 PR을 날릴 때도 여러 차례 딜레이가 있었습니다.
  • 빠뜨린 백로그도 많았습니다. 추가해주는 데 또 한세월..
  • 현재까진 이슈를 수정하며 유도리있게 잘 해결해나가고 있습니다만, 월요일에 백로그 단계부터 상세히 Task를 작성해두면 참 편하겠습니다!
• 페어 프로그래밍의 장단점
  • 개인의 성장에는 깨닫는 점이 정말 많았지만, 분업이 아니다보니 프로젝트 전체의 생산속도는 확실히 감소한다는 것을 느꼈습니다.
  • 시간 분배할 때 이 부분을 고려하여 넉넉히 잡고, 개발시간 전후로 미리 학습하고 마무리 기록을 잘 하는 습관을 들여 효율을 올려봅시다!

Try

• 백로그 이슈 개선하기
  • 빠뜨린 백로그 추가하고 이슈 open하기
  • 월요일에 Task 가능한 상세히 정리하고 계획하기
• 페어 프로그래밍
  • 사전 학습 : 페어 프로그래밍 전 개발할 내용 사전에 계획해두기
  • 기록 남기며 개발 : 과정이 느려지더라도 캡쳐와 로깅을 철저히 하며 진행
• 정리 부채 해결하기
  • 학습해둔 내용들 주말에 정리해서 블로그 올리기! 제때제때 해라!

J073 송준섭

📈 향후 개인의 성장 목표

• 근거있는 선택 하고 기록하기
  • 왜 이 기술을 사용하려고 하는지, 다른 기술은 없는지 학습하고 기록하기
  • 코드 한 줄을 짜더라도 생각하고 더 나은 방향은 없는지 고민하기
• 학습할 때 글 하나만 보고 대충 정리하지 말고 여러 자료를 참고해서 깊이 학습하기
• 기초 다지기
  • NestJS 깊이 파보기
  • 데이터베이스 정규화, 트랜잭션, 쿼리 최적화 등 학습 및 정리, 구현
• 서버 구조 고민하기
  • NGINX 학습 및 적용 계획 세우기
  • NCP 서비스들 학습 및 전략 세우기
  • docker, GitHub Action 학습 및 적용 계획 세우기

🤔 기술적 고민거리

1. TDD

TDD를 어떤 방식으로 진행해야 하지? 라는 막연함이 있었습니다.

Nest에서는 유닛 테스트를 짤 때 확인하고자 하는 계층 외에 그 계층의 로직에 필요한 다른 계층은 Mocking을 하여 완벽히 동작한다고 가정하고 테스트 코드를 짭니다.

예를 들어 BoardService의 유닛 테스트를 짠다고 한다면 해당 클래스에 필요한 BoardRepository는 잘 작동을 한다고 가정하여 Mocking을 하고 딱 BoardService의 로직만 테스트를 짭니다.

처음 테스트 코드를 짜면서 느낀 점이 있습니다.

결국 실제 중요한 것은 데이터베이스와 통신을 해서 결과물을 만드는게 중요하지 않나?

이렇게 유닛 테스트를 짜는 것이 무슨 의미가 있지?

이렇게 생각한 이유는 아직 애플리케이션의 로직이 너무 단순했기 때문이었습니다.

예를 들어 글 조회 기능을 구현을 한다고 하면 필요한 코드가 BoardRepository.find() 한 줄로도 해결을 할 수 있었기에 너무 억지로 테스트 코드를 짜는 느낌을 받았던 것이었습니다.

그래서 내린 결론은 일단 애플리케이션을 가상화해서 실제 HTTP 통신을 보내고, 그 결과를 테스트하는 e2e 테스트만 작성을 하고, 나중에 복잡한 Service 로직이 생기면 그런 것만 유닛 테스트를 짜보자! 라는 것이었습니다.

이렇게 하고 TDD 방식을 진행하니 어느 정도 감도 잡히고 잘 진행을 했던 것 같습니다.

1. Set-Cookie? Authorization Bearer?

JWT를 이용해 로그인을 구현하면서 이 JWT를 클라이언트에 어떻게 전달할 것이며 어디에 저장할 것인가에 대한 고민을 하였습니다.

• Set-Cookie를 사용한 JWT 전송:
  • 방식: 서버는 클라이언트에게 JWT를 "Set-Cookie" 헤더를 통해 전송
  • 저장 위치: JWT는 클라이언트의 브라우저에 쿠키로 자동 저장
  • 자동 전송: 브라우저는 해당 도메인에 대해 자동으로 쿠키를 요청하는 모든 요청에 JWT를 함께 보냄
  • 보안 고려 사항: CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있으며, 쿠키를 안전하게 저장하고 전송해야 함
• Authorization 헤더를 사용한 Bearer Token 전송:
  • 방식: 클라이언트는 HTTP 요청의 "Authorization" 헤더에 "Bearer" 토큰으로 JWT를 직접 포함시켜 보냄
  • 저장 위치: 토큰은 클라이언트의 메모리나 저장소(로컬 스토리지, 세션 스토리지 등)에 저장될 수 있음. 클라이언트에서 직접 저장 설정이 필요함
  • 수동 전송: 모든 요청에 수동으로 "Authorization" 헤더에 토큰을 추가해야 함
  • 보안 고려 사항: XSS(Cross-Site Scripting) 공격에 노출될 수 있으며, 토큰을 안전하게 저장하고 전송해야 함

위와 같이 조금 조사를 한 결과 그냥 쿠키에 담는 것이 브라우저에서 자동으로 해주는 일도 많고, 프론트 분들에게 부담도 될 것 같아서 Set-Cookie로 쿠키에 담아 사용하기로 하였습니다.

피어세션 피드백

• NoSQL을 사용하는 이유에 대해서 확실하게 정리하지 않으면 나중에 혹시 면접 같은 곳에서 공격을 받을 수도 있을 것 같다는 말씀을 해주셨음
• PostgreSQL에서도 좌표 관련해서 지원을 해주는 타입이 있다고 어디서 들은 것 같으시다고 알아보시는것을 추천을 해주셨음
• TDD를 할 계획을 세우신 것이 좋다는 말씀을 해주셨음

J010 김가은

Keep

• Three.js 부분에서 많은 학습을 했다.

  • 특히 이번주에는 내가 모르는 수학적 개념이나 지구과학 지식들이 필요했다.
  • 문과돌이인 나는.. 벡터부터 정말 생소한 개념이었다 🥹
  • 그런 수학적 개념이 많이 필요한 부분은 코드를 혼자서 작성하지는 못했지만, 팀원들의 도움을 받아 원리와 개념을 이해할 수 있었다.
  • 수학 개념들을 이해하고, 그것을 적용한 three.js 코드를 함께 작성했다는 것만으로도 꽤나 도전적이었던 일주일이었다.
  • 그리고 Space Warp같은 것들은 인터넷상의 다른 레퍼런스들을 참고하지 않고, 스스로 고민하며 코드를 작성했다.
  • three.js에 익숙하지 않은 나로서는 이러한 것들에도 뿌듯함을 느꼈다.

• 페어프로그래밍을 많이 해볼 수 있었다.

  • 팀원들 모두 three.js를 써보고싶어했기에, three.js를 많이 사용하는 이번주에는 대부분의 시간을 페어프로그래밍하며 보냈다.
  • 이렇게 셋이서 페어프로그래밍한 적은 처음이었다.
  • 페어프로그래밍 상황에서 서로 부족한 점을 보완해줄 수도 있었고, 의견 충돌이 생기기도 했다.
  • 이런 경험을 해본 것이 큰 도움이 되었다.

• Three.js와 R3F에 관련한 기술블로그를 작성했다.

  • 기술블로그를 작성하며 그냥 넘어갔던 개념들도 더 자세히 찾아볼 수 있었다.
  • 그리고 팀원들에게 피드백받으면서 잘못 알고있던 것들을 바로잡을 수도 있었다.
  • 결과적으로 코드에 대한 이해도를 높이고 지식을 채우는 데 많은 도움이 되었다.

Problem

• three.js에 대한 지식이 다른 팀원들에 비해 부족하다.
  • three.js에 관한 것도 그렇지만, 수학적인 개념이 많이 부족하다고 느꼈다.

Try

• three.js 관련해서는 팀원들에게 많이 배우고, 다른 쪽에서 더 잘하도록 노력해보자.
  • 문과인 나로서는 수학적인 부분에서 지식이 부족한 것은 어쩔 수 없는 것 같다.
  • 이런 점을 받아들이고, 수학적인 개념이 들어간 부분은 코드와 개념을 이해하는 데 더 집중하자.
  • 대신 수학적 지식이 필요없는 곳에서는 더 많이 기여하도록 해보자.