4주차 팀회고

✋ 피어세션 내용 공유

🏃‍♂️ J103_박무성

• 오늘 배워 온 건 별로 없는 것 같은데, 일단 배팅덕이나 부퀴즈, 녹타 보면서 웹소켓 같은 거 참고는 할 수 있지 않을까 싶어요.
• • 다른 분들은 다 단일서버더라고요. 우리가 겪었던 채팅 웹소켓 문제나 이런걸 공유하니까 오히려 예방 주사 맞았다고 좋아하시던데… (외화 유출만 하고 수출을 못함)
• 부퀴즈 팀은 신기하게 Cent나 Rocky도 쓰시더라고요. 기왕 해보는 거 OS 다 경험해보자는 마인드로 하셨다고… 대신 인스턴스가 3개라 돈도 삭제되고 있다고 합니다.

☄️ J152_안성윤

• 이번주는 대부분 기능 위주로 서로 공유를 했어서 따로 기술적인 부분을 건져온 곳은 없습니다.
• 그나마 주식, 코인 관리하는 서비스들 참고해보니 SSE가 은근 부하가 별로 안크다?? 라는것 정도는 알 수 있더라구요.

🐟 J222_정명기✅

• https://lottiefiles.com/kr/ 이런걸 알아왔어요 무료 애니메이션 해주는건데 나름 이쁜게 많더라고요

🍎 J235_조민석 ✅

• 내도메인.한국 에서 도메인 발급한 거로 HTTPS 하시는 분이 계셨는데 NGINX에서 SSL 걸어서 사용중이시래요 코드 한 줄 딸각이면 HTTPS 적용된다는 걸 들었습니다. 외부 서비스에 의존적이지 않아서 좋을듯하네요 도메인 비용도 아끼고

→ 나중에 Nginx 도입할 때 한번쯤 참고해볼만 하겠네요

• Redis 이전해야 할 것 같네요… 다른 팀들 다 Public Server에 Redis 두셨더라고요. 사실 인터넷 타고 들어오는거라 이게 일반 DB랑 큰 차이는 없지 않나 싶네요

→ Redis 이전 다음주에 태스크 발행합시다.

• SSE HTTP 버전별로 접속할 수 있는 클라이언트 접속 제한 수를 언급해주셔서 이거 까먹고 있었네요…ㅎ Nest HTTP 1.1인데 괜찮으려나 싶네요. 아마 1.1이 6명, 2.0이 100,200명? 인거로 알아요.

→ 내일 저희 인당 4개씩 띄워놓고 부하테스트 하시죠

• 아직 테스트 코드 적으면서 테스트 들어간 조가 거진 없더라고요. 테스트 DB 구축도 안 한 조가 많아서 공유하고 왔습니다. 테스트 열심히 적어보죠…!!!

🌱 J249_채준혁

• 인프라 이야기를 많이 하셔서 이해하는데 조금 어려웠어요. 저희 팀에 적용을 할 수 있는 부분인지 모호해서 일단 들고와봤습니다

네, 이 팀은 주식 거래 같은 금융 서비스를 만드는 것 같네요. 주요 내용을 쉽게 설명해드릴게요.

전체 시스템 구조


서비스를 여러 개로 나눠서 운영 (마이크로서비스 구조)

auth-service: 로그인, 인증 담당
balance-service: 사용자 잔액 관리
transaction-service: 거래 처리
static-server: 웹 페이지 파일 제공





마주친 문제들


MongoDB 트랜잭션 이슈

여러 거래가 동시에 들어올 때 안전하게 처리하려면 트랜잭션이 필요
그런데 MongoDB는 단독으로는 트랜잭션 기능을 못 씀
여러 서버를 묶어서(replica set) 구성해야 하는 번거로움



해결책으로 메시지 큐 도입

Bull MQ (Redis 기반) 선택
거래 요청을 바로 처리하지 않고 큐에 넣어서 순서대로 처리
Redis는 데이터가 날아갈 수 있지만(휘발성) 속도가 빠름





배운 점

처음에 MongoDB를 선택한 이유: "성능이 좋다"
하지만 금융 거래에는 부적합했음

트랜잭션 지원이 부족
데이터 안정성이 덜 중요한 곳에 더 적합


결과적으로 추가 인프라(메시지 큐 등)가 필요해짐



운영 관리

쿠버네티스로 서버 자동 확장/축소
CPU 사용량 80% 넘으면 서버 자동 증설
한 번에 너무 급격히 늘리거나 줄이지 않도록 설정



이 팀의 주요 고민은 "동시에 여러 거래가 들어올 때 어떻게 안전하게 처리할까?"였던 것 같네요. MongoDB 선택이 이런 요구사항과 잘 맞지 않아서 추가 작업이 필요했던 케이스입니다.

내부 동작을 단계별로 설명드리면:

1. **사용자 입력 처리**
   - 사용자가 `docker pull learndocker.com/python` 입력
   - Docker CLI는 이게 docker.io가 아닌 커스텀 레지스트리라고 인식
   (왜? 도메인에 점(.)이 있어서!)

2. **도메인 확인**
   - learndocker.com이라는 주소를 찾음
   - /etc/hosts 파일에서 이 주소가 로컬호스트(127.0.0.1)로 연결된걸 확인

3. **Nginx 프록시**
   - 80번 포트로 Nginx에 요청이 감
   - Nginx는 "아, 이건 우리 프라이빗 레지스트리(5000번 포트)로 보내야겠다"
   - 요청을 프라이빗 레지스트리로 전달

4. **이미지 다운로드**
   - 프라이빗 레지스트리가 python 이미지 정보 반환
   - Docker CLI가 필요한 레이어들을 순차적으로 다운로드
   - 로컬에 이미지 저장

특별히 재미있는 부분은:
1. Docker는 도메인에 점(.)이 있는지 없는지로 docker.io인지 아닌지 판단해요
   - `docker pull python` → docker.io 사용
   - `docker pull learndocker/python` → docker.io 사용
   - `docker pull learndocker.com/python` → 커스텀 레지스트리 사용

2. 컨테이너 안에서는 살짝 다르게 동작해요
   - 호스트의 IP(172.17.0.1)를 사용
   - 보안 설정(insecure-registries)이 추가로 필요

이렇게 해서 사용자는 간단한 명령어로 안전한 이미지만 받을 수 있게 되는 거죠!

아, 죄송합니다. 제가 글을 다시 자세히 보니 맞네요. 글쓴이가 Nginx를 사용한 방법을 테스트해봤지만, 최종적으로는 다른 방법(컨테이너 이름으로 프록시)을 사용할 예정이라고 했네요.

주요 포인트를 정리하면:

도커 이미지 주소 제한의 목적
- Docker Hub의 검증되지 않은 이미지 사용 방지
- 승인된 이미지만 있는 프라이빗 레지스트리 사용 강제

작동 방식
- 호스트에서 프라이빗 레지스트리를 5000번 포트로 실행
- /etc/hosts에서 learndocker.io를 172.17.0.1로 매핑
- /etc/docker/daemon.json에서 HTTP 통신 허용 설정

사용자 경험
- 사용자는 learndocker.io/이미지이름 형식으로 간단히 사용
- 내부적으로는 프라이빗 레지스트리에서만 이미지 다운로드

공유 결과

---

🫂 KPT 회고

<aside> ✍🏻

• Keep

  • 이런거 좋음

• Problem

  • 이거 아쉽네요

• Try

  • 이런거 해보죠 </aside>

• 🏃‍♂️ J103_박무성✅

  Keep

  • FE 분들 피드백도 빠르고 잘 주셔서 좋습니다. 준X님, X기님 항상 감사합니다. :)
  • 이번 주는 정신없을 정도로 좀 바빴던 것 같은데 그런 와중에도 민석님의 문서화… 감탄이 나옵니다. (제가 도와드릴게 뭐 없을까요. 시켜만 주세요.)

  Problem

  • 새벽 3시까지 있는거는 좀 문제가 있다고 생각합니다. 오랜만에 챌린지 찍먹시절로 돌아간 듯해요. (근데 재미랑 감동, 낭만은 있어서 큰 문제는 아니라 생각합니다.)
  • 명기님꺼 보다가 저도 생각났는데, API 명세 관련해서 준혁님이 좀 힘들었을 거에요. 다음에는 좀 자세하게 픽스를 하고 진행하겠습니다.

  Try

• ☄️ J152_안성윤 ✅

  Keep

  • 코드 리뷰 문화가 저희 팀만의 입맛대로 잘 정착한것 같아 좋야요!
  • 다들 작업량도 상당해서 이번주차는 거의 스프린트 목표를 달성한 것 같아 기분이 아주 뿌듯합니다 🙂

  Problem

  • 정책적인 부분들에 대해서 각자 이해도가 조금 다른 상황이 꽤나 자주 발생했습니다.
    • 여기에는 blogName이 들어가는가? userName이 들어가는가?
    • 특정 기능이 이번 버전에 포함이 되었는가? (FE ↔ BE간 이해의 차이)

  Try

  • 이번주 스프린트 리뷰회의때 태스크 잔뜩 만들어서 마스터분들이 말씀하시던 완성도있는 프로젝트 부시러 갑시다 ㅋ.

• 🐟 J222_정명기 ✅

  Keep

  • 다들 열심히 해주셔서 초기 계획한 버전1 결과물이 나왔네요 좋습니다!!

  Problem

  • 요즘 매일 새벽에 다 모여서 떠드는건 좋은데 힘드네요 이거 강제 수면시간이라도 정해야 할거같아요

  → 그냥 이건 자유롭게 다들 모여있던 말던 자리 비울수있는 분위기 형성

  • api설계가 항상 부족했던거 같아요 프론트엔드에서 따로 백엔드에서 따로 만드니까 서로 반환값 이름도 다르고 이거 반환해야하나 안해도 되나 이런거 자꾸 생기는거 같네요

  Try

  • 잠자기
  • 소통 늘리기

• 🍎 J235_조민석 ✅

  Keep

  • PN룰 다들 잘 지키는 것 같아서 다행입니다.
  • 일정 있을 때 미리 말씀해주셔서 좋습니다.
  • 저 이번에 API 만들때 프론트분들이랑 소통을 꽤 많이 하니까 크게 픽스할 게 없더라고요. 좋았습니다~ ex) 갑작스럽게 추가된 RSS승인/거절 기록 조회 API 만들때

  Problem

  • 코드 리뷰를 제 스스로 좀 대충 본 것 같아요. 무성님 코드도 그렇고, 성윤님 코드 볼때도 그렇고 다음 주는 더 꼼꼼하게 보겠습니다.
  • 노션에 API 명세서 업데이트가 안 돼서 어제 새벽에 준혁님이랑 거진 3시? 까지 토크하면서 API 명세서 업데이트 다 시켰습니다. 명세서 보고 만들고, 바뀐 부분은 꼭 즉시 반영 부탁드려요! (특히 상태 코드 빈 곳이 너무 많았습니다.)

  → 저희가 신경만쓰면 해결할 수 있는 부분. BE 에서 문서 업데이트 잘 해봅시다.

  작업이 끝남 → Github Project 관리 → API 문서 업데이트 관리

  • 아직도 Project에서 Issue가 Done이 되면 End Date를 안 넣는 분들이 계신 것 같아요…! 다 채워 넣었습니다

  → 이것도 똑같음. BE & FE에서 문서 업데이트 잘 해봅시다!!!

  본인만의 루틴을 만들어야해요!

  • 이번 주에 기분이 태도가 된 경우가 좀 있었습니다. 팀원분들께 죄송해용…ㅠ.ㅠ 말 둥글둥글…

  → 아무도 못느끼긴함. 근데 이야기해주셔서 감사합니다.

  Try

  • 다음 주부터 슬슬 기능 테스트를 해야 하는데, 각자 사용해보고 버그나 불편 사안 찾아오기?

• 🌱 J249_채준혁

  Keep

  • 작업을 많이 수행할 수 있어서 좋았습니다. 이번 주에 이슈 생성하고, PR merge 까지 일련의 과정들을 피하지 않으려고 노력했어요.
    • 기존에는 최대한 하나의 이슈에 넣어서 issue, pr 발행을 줄였는데, 나중에 GitHub Project로 볼 때 어떤 부분을 작업했는지 명시해놓는게 중요하다고 느껴 이렇게 했던 것 같아요.

  Problem

  • 문서화를 완벽하게 끝내지 못해 아쉬웠습니다..
  • 정책적인 부분을 미리 결정을 해놓고 이걸 자주 꺼내 보면서 이해가 완전히 된 상태에서 구현을 해야 함을 느꼈습니다.
    • 이렇게 해놓아야 나중에 구현할 때 시간 소모가 많이 안됨을 느꼈습니다..
  • 학습 정리 개인 페이지에만 작성하지 마시고 팀 노션에 공유해주세요 ㅠ

  → 구몬해야됨 ㅠㅠ

  Try

  • 운동을 줄이고 구현 내용을 늘리기
  • 애니메이션, 404 페이지, 구현 안 된 내용들 토스트로 보여주는 등 UX를 최대한 끌어올려서 완성도를 높이기

회고 결과

Keep
Problem	요즘 매일 새벽에 다 모여서 떠드는건 좋은데 힘드네요 이거 강제 수면시간이라도 정해야 할거같아요 노션에 API 명세서 업데이트가 안 돼서 어제 새벽에 준혁님이랑 거진 3시? 까지 토크하면서 API 명세서 업데이트 다 시켰습니다. 명세서 보고 만들고, 바뀐 부분은 꼭 즉시 반영 부탁드려요!
Try	자유롭게 다들 모여있던 말던 자리 비울수있는 분위기 형성 저희가 신경만쓰면 해결할 수 있는 부분. BE 에서 문서 업데이트 잘 해봅시다,작업이 끝남 → Github Project 관리 → API 문서 업데이트 관리

---

🗒️ 메모장