[개별 멘토링] 2024.11.10.

💯 이번 주 문제 해결 경험

1. 🔩 BE 회의 진행

   우선 팀 전체 회의가 많았던 1주차와 달리, 어느 정도 틀이 잡힌 2주차에는 분야별로 나누어 회의를 진행하기로 했다. 프로젝트 기본 세팅을 마치고, NCloud 서버를 생성했다.

   사실 부끄러운 이야기이지만 AWS를 쓸 때에도 IAM 계정을 생성하지 않고 루트 계정으로만 관리했었다. 마스터 클래스 때 서브 계정에 대한 이야기를 듣고 처음 적용을 해보았다. 그래서인지 서브 계정을 생성해 접속하고 관리하는 과정이 새로웠고 신기했다.

   NCloud 서버 생성이 마냥 잘 되었던 것은 아니다. 늦은 밤까지 BE 분들과 함께 작업을 하고 있었는데 port를 사용하여 통신하는 curl 같은 명령어들이 하나도 동작하지 않았던 문제이다. 거의 2시간 가량 끙끙거리면서 다양한 방식을 시도해보았지만 고치지 못했고, 다음 날 서버를 완전 삭제하고 다시 만들어서 해보자는 의견이 나왔었다. 다음 날 서버를 완전히 삭제하고, 동일한 ACG, Subnet을 구성해 다시 시도해봤는데.. 허탈할 정도로 너무 잘됐었다. 그룹원분들과 무슨 문제가 있는지 찾아서 트러블 슈팅 페이지까지 작성할 준비를 다 했었는데.. 그냥 삭제했다가 다시 서버를 여니까 그냥 동작했다. (…)

2. 🖥️ 개발 시작

   스프린트 회의를 통해 이번 주에 작업하고자 하는 태스크를 정했다. 스프린트 태스크에서 담당할 분야를 정해 개발을 시작해보려고 했는데 다들 먼저 고르라고 양보해서 사다리 타기로 태스크를 골랐던 것이 기억난다.😊

   이번 프로젝트에서의 핵심은 실시간 데이터 관리다. 그러기 위해서는 한국투자 Open API에서 원하는 정보를 보내주는 API를 찾고, 값을 얻어와야 한다. 나는 외부 API에 값을 요청해서 받아오는 게 처음이라 이것저것 시행착오를 많이 겪었었다.

   생각나는 문제는 다음과 같다.

   1. Access Token을 얻어오지 못하는 문제

      한국 투자 API의 경우 실제 주식 계좌를 만들어야지만 주식 API에 접근할 수 있어서 그룹원이 하나의 계정을 만들어서 그 계정을 다 같이 쓰기로 이야기를 나눴었다. 이 문제는 우리가 계정은 하나인데 다 따로따로 작업하려고 해서 발생했다.

      한국투자 사이트에서 API나 소켓을 요청할 때에는 Access Token을 발급받고, 해당 토큰을 이용해 API/소켓을 요청해 응답받아야 한다. 그런데 다 따로따로 작업하다보니 같은 계정으로 Access Token을 여러 번 발급받으려고 해서 발생했다. 사이트 자체에서 너무 잦게 Access Token을 요청하는 상황을 막기 위해서 시간을 걸어놨는데 각자 로컬에서 테스트해본다고 여기저기서 Access Token을 요청해 403 에러가 발생하면서 얻어오지 못했었다.

      이후에 개발이 끝나고 합치는 과정에서 공통 함수로 분리해 싱글톤으로 관리하게 바꾸었다.

      다음부터 이런 공통 사항이 발생할 경우 어떤 식으로 진행할 지 따로 이야기가 더 필요할 것 같다고 느꼈다.

   2. API 요청에 대한 제대로 된 응답값을 받지 못한 문제

      이거는 내가 바보같았던 일화이다. Request Header 같은 경우에는 Required를 꼼꼼히 확인하고 필요한 걸 다 넣었는데.. 쿼리 파라미터는 내가 필요하다고 생각했던 것만 넣었다. 모든게 다 필요했던 필드였는데.. 내 마음대로 문서를 제대로 읽지 않고 넣었던 것이다.

      왜 로직대로 동작하지 않는지 console.log() 를 찍어가며 확인했는데 아예 응답값이 없었다. 이 때 눈치채고 API 문서를 다시 확인하니 쿼리 파라미터의 값을 다 넣어야 했다.

      이때 문서를 꼼꼼히 읽고 처리해야 한다는 것을 느꼈다.

3. 💼 문서화

   우선 이번 주차 담당한 분야는 소켓은 없고, 단순 API만 개발하는 거라 Swagger UI를 통해 문서화하는 것이 쉬웠다.

   우리 노션 페이지에서는 내 코드를 이해하기 쉽도록 작성해보았다.

   API 요청에 필수적인 값, API 요청하면 도착하는 값으로 나눠서 어떤 것이 내가 진짜로 필요한지 한번 더 정리하면서 외부 API 요청에 대한 난이도를 낮춰보려고 했다.

💬 피어세션 때 나눠보고 싶은 이야기

1. 다들 DB는 어떤 식으로 관리하고 있나요?

   1. 백엔드 마스터 클래스에서 진행했던 것처럼 private 서버 인스턴스를 생성해 해당 서버에서 하고 계신지, 그렇다면 서버 비용 등 어떤 식으로 관리하고 계신지 궁금합니다.

      ⇒ 저희 팀은 멘토님의 조언에 따라 알파 서버(BE에서 작업한 API를 배포하는 서버, 프론트 분들의 로컬 테스트 환경을 구축해주기 위함)를 배포 중인데 알파 서버 + 데이터 베이스 서버 벌써 인스턴스를 두 개나 사용 중이어서 배포 서버를 따로 두기엔 금액적으로 부담이 간다고 느꼈습니다.

      https://www.ncloud.com/product/compute/cloudFunctions#pricing

2. 다들 로그 관리는 어떤 식으로 하시나요?

   1. 이번 주에 배포하면서 문제가 좀 많이 터졌었는데 따로 로그 관리를 하지 않아서 문제 원인을 쉽게 파악하지 못했습니다. 다들 어떤 거로 많이 하시나요?

👨🏻‍🏫 멘토링 - 질문 사항

1. 현재 Task별로 작업을 나눠서 진행 중입니다!

   한국투자 Open API에서 access token을 발급 받은 후에 API를 요청하는 시스템이었는데, Task 별로 나눠서 작업하다보니 코드를 두개로 나눠서 작성하고, 이후에 합치는 과정으로 진행했습니다.

   이번에 했던 것처럼 겹치는 내용에 대해서는 따로 작업한 이후에 하나로 합치는 수정 과정을 거치는게 나은지, 주간 회의를 통해 필요한 공통 함수를 먼저 작성한 후 개별 작업하는 것이 좋은지 궁금합니다.

2. conflict 가 났을 때 어떻게 하면 효율적으로 해결할 수 있을까요?

   1. 이번 주는 Pull Request 페이지 하단에 Resolve conflicts 버튼을 눌러서 수정해서 해결했는데 이런 식으로 해결해도 되는건지 궁금합니다. 또 Resolve conflicts 버튼이 활성화되지 않는 상황에서의 conflict는 어떤 식으로 해결하시는지 궁금합니다!

3. NCloud 서버 관리

   1. SSH 접속 IP 제한이 된 상태이긴 하나… 깃허브에 저희 공인 IP 주소가 노출된 채로 올라가있는데 보안적으로 문제가 되진 않을까 고민이 됩니다. 공인 IP가 드러나는 부분을 .env 파일에 넣어서 관리하는 방식으로 빠른 시일 내에 바꿔야 할까요? 공인 IP를 아예 반납하고 새로 발급까지 받는 것이 좋을까요?

4. nest.js에서 파일 이름

   1. 회사마다 다 다르다는 걸 알고는 있지만…! 카멜 케이스, 케밥 케이스 등등 다양한 규칙 중 멘토님은 어떤 걸 선호하시나요? 2주차동안 개별적으로 코딩하다보니 파일 이름이 정말 자유 분방하더라구요..ㅎㅎ 저희도 그걸 인지해서 코드 리뷰 때 나중에 따로 네이밍 어떤 식으로 할 지 이야기해보자고 말도 나왔고, 피어세션 때도 통일하는게 좋겠다는 피드백을 들었습니다. 그래서 멘토님이 선호하는 규칙이 어떤건지 궁금해져서 질문 남겨봅니다ㅎㅎ

피어세션 기록

동료와 공유하거나 의견을 묻고 싶은 부분을 정리해보세요.

피어세션에서 나눈 이야기 중 나의 문제 해결 경험과 관련한 피드백과 새롭게 깨달은 점이 있다면 기록으로 남겨주세요.

• Zustand
  • 편하다! 백엔드 개발자도 1시간 정도 공부하면 쓸 수 있을 것 같은 느낌
• J061_김주호님
  • 스켈레톤 코드만 작성, 프론트분들 테스트할 수 있게만 작업
  • [socket.io](http://socket.io) 에서 방 개념과 우리 프로젝트에서 생각한느 방 개념이 다름
    • socket은 pub/sub 패턴으로 방 개념 사용. 채팅방 느낌으로 자기 자신의 방, 여러 개의 방 동시에 진입 가능
    • 근데 우리는 방의 ‘호스트’라는 개념이 필요하고, 방에 입장하면 다른 방에는 입장하면 안되는.. 그런 상태
    • AI에게 질문하니 실제 온라인 게임에서도 소켓 쓰고, 로직으로 하나의 방만 들어갈 수 잇게 하는 과정을 한다고 함
    • 우선 코드만 작성하되, 나중에 뜯어고쳐서 할 수 있게 하려고 했다!
• J051_김영현님
  • TypeORM 연동
    • typeorm 트랜잭션 보장할 때 러너 이용해서 할 수 있는데, typeorm-transactional 설치해서 사용하면, 스프링 어노테이션인 @Transactional 처럼 똑같이 붙여서 쓸 수 있다!
    • 모듈 단위로 작업을 함
      • usecase가 하나의 비즈니스 로직, interface 구현체 사용해서 자바스럽게 코드 짜려고 노력했음
      • DI IOC 써서 추상화 진행해가지고 외부서비스에서는 인터페이스만 쓸 수 있게 했음
        • 와 대박이다, 진짜 꼼꼼하네요
    • 커스텀 예외처리
      • HTTP 상속받아서 만들었음
      • enum 말고 union 타입으로 관리 중
      • 클라이언트 측에서는 뭔 에러가 발생하던 500 에러가 터져서, 이거 확실하게 전달하게 하려고 필터 만들어서 하려고 함
• 나!
  • DB 등 서버 관리 어떻게 하고 있는지?
    • (영현님) public으로 nginx 서버, 미디어 서버 띄우고 private에 fe, was 두대, db까지 해서 3개 만들어서 한달에 20만원 정도 나감. DB서버 한대를 또 띄우는게 낫지 않나? 그럼 월 30이고, DEV환경인데 production 환경 바꾸고 하면 60만원식 드는데… 동일한 고민을 하고 있음
    • (주호님) [링크 확인](https://www.ncloud.com/product/compute/cloudFunctions#pricing)
  • 로그는 어떻게 관리?
    • 윈스턴 이용해서 로그 관리중
    • Loki stack 이용해서 지금은 콘솔보기 수준인데, 모니터링까지 진행하지 않을까 싶음
    • 요청하고 이런거 찍고, 에러 로그 발생하면 슬랙 알림도 할 수 있어서 추천
  • 네이밍 통일성
    • 카멜케이스, 케밥케이스 이런거! 하나로 맞추기
  • 타입스크립트 이넘 안티패턴
    • https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking
    • https://techblog.woowahan.com/9804/

개별 멘토링 기록

멘토에게 전달하고 싶은 이야기를 정리해보세요. 개별 멘토링 24시간 전에 멘토가 미리 내용을 보고 올 수 있도록 공유해야 합니다.

개별 멘토링 이후에는 멘토와 나눈 이야기가 휘발되지 않도록 기록해보세요.

1. 서브 계정 있는 거 좋은 거 같음. 회사에서도 다 함!
2. 안될 때는 아예 지우고 다시 하기보다는 새로운 서버 띄워서 비교하면서 해보는게 좋을듯하다.
3. db에 토큰 저장한다고 이슈가 될 만한 건 없음. 그거 저장하는 거 자체는 큰 이슈는 없다. 레디스 써보는 것도 좋을 듯. 토큰을 레디스에 올려놓고 필요할 때마다 꺼내 쓰고, 만료되면 갱신시켜주는 로직까지 넣어서 하면 서버 여러 개 떠도 문제 없을듯! DB보단 레디스가 편하니까 인메모리 db 같은거 한번 고려해보는 것이 좋다~
4. 스웨거 다양한 기능 활용해보는 것이 좋다.
   1. 현업에서는 be, fe 나눠서 개발하는게 일반적이니까 문서화 신경써서 해야 하니 미리 연습해보는 것이 좋다!
5. 현업에서는 알파서버-알파DB 따로 존재, 지금은 DB 한대 띄우고 알파, 리얼 둘 다 같이 써서 해라! BE, FE 배포는 따로 띄워도 DB는 하나 써도 괜찮을 것 같다. 금액이 부담되면 그렇게 해도 된다! 넘진 않을 것 같은데 혹시 모르니까~
6. 에러 발생했을 때 에러 캐치해서 슬랙에 쏘는 방법도 존재, 활용해도 좋을 것 같다!

---

질문사항 답변

1. 하나의 영역에서 두 명이 작업해서 생기는 문제, 현업에서는 그런 경우가 거의 없음. 각자 하나를 맡아서 하는 거기 때문에 그런 경우가 잘 없기 ㄴ하나.. 프로젝트 범위가 살짝 겹쳐서 다른 사람 영역이랑 겹칠 수도 있으니.. 이럴 땐 잘 보고 머지하고(conflict 대비) 그거 아니고 혼자서 감당하기 어려워 보인다. 이런거면 같이 모여서 이야기 하면서 해도 될 것 같다.

2. 주기적으로 백엔드 메인에다가 pr 날리고 있는데, back-end 메인을 작업하고 있는 브랜치에 주기적으로 머지해주면서 해야 함. 내가 conflict를 여기서 해결하고 PR을 올리면 된다! 주기적으로 하지 않으면 .. (멘토님 신입일 때) 3주짜리 프로젝트였는데 conflict 난 곳을 수정하고 수정하고 하다보니까… 누가 작업했는지 매번 찾고 해야 해서 좀 어려웠따. 주기적으로 머지하면서 충돌을 해결하는게 그나마 괜찮은 방법일 것이다! 충돌을 두려워할 필요는 없고, 다같이 보면서 해결하면 되니까! 사실 충돌났는데 pr 올리면은 안되지 ㅎㅎ

3. .pem 키값만 노출안되면 상관 없음. 개발자 도구에서 확인하면 api 주소 다 보임, 별 문제 없을듯!

   1. .env 쓰는 이유?

      알파랑 리얼 서버 나누게 되면, 리얼에는 real api 주소 넣고, alpha에는 alpha 주소를 넣는것. 페이지 구분을 위해서도 쓸 수 있다.

      .env로 분기치는걸 편하게 할 수 있다! 오 좋아요!

4. 도메인.controller.ts 이런 식으로 하긴 햇당

   1. 도메인 부분 하이픈 쓰면서 그런 식으로 많이 했다.

5. 화이팅~ 속도 내서 잘 해보기!