제작 발표회
일정
| 시간 | 일정 |
|---|---|
| 9:30 | 발제 |
| 10:00 | 발표 (A조 - 첫 번째 순서) |
| 12:30 | 외부인 대상 부스 방문 |
| 14:00 | 외부 심사위원 부스 방문 |
| 16:00 | 커리어 세션 - 취업 지원 |
| 17:00 | 수료식 |
발표
발표 자료
발표 피드백
- 기술 선택과 문제 해결 과정이 논리적이고 체계적이었다.
- 동시성 문제를 고려하고 AOP 기반의 락을 구현한 점이 인상적이었다.
- 포트폴리오의 시나리오(대기열, 락 동작, 예외 처리 등)가 구체적으로 설명되지 않아 외부 평가자가 이해하기 어려웠다.
- 카프카 2대와 클러스터 3대 구성이 일반적일 것 같은데, 아키텍처 선택의 이유가 명확하지 않았다.
- 구조도와 도식을 잘 작성해 이해를 돕는 데 도움이 되었다.
마치며
비슷한 기술 스택을 가진 개발자들과 직접 의견을 나누고 토론할 수 있는 경험이 값졌다. 팀원 모두가 적극적으로 문제 해결에 나서며 협업한 덕분에 의미 있는 팀 프로젝트를 할 수 있었다.
외부 질문
MSA를 채택한 이유?
서비스 주제 특성상 정말 많은 사용자의 요청이 동시에 몰리기 쉬운데 MSA는 확장성이 뛰어나기 때문에 트래픽을 관리하기 용이하다.
웨이팅 미루기 기능 테스트 방법?
순서와 순번은 따로 존재하고, 다음 10명 사이에 순서를 정하면 교체되는 방식이다.
피드백
특정 순번을 조정하는 기능을 테스트할 때, 다른 사용자에게 미치는 영향을 최소화할 방안을 고려해야 한다.
분산락, 락 획득 실패 시 동작 방식?
현재는 구현되지 않았으며, 락 획득 실패 시 3회 재시도 후 데드 큐에 넣는 방식으로 처리하고 있다.
재촉 알림의 10분 기준?
피드백
정책 수립 시 논리적인 근거가 필요하며, 보다 명확한 기준을 마련해야 한다.
어떤 메트릭을 모니터링하면 좋을까?
피드백
안정적인 서비스 제공을 위해 어떤 지표를 사전에 모니터링하면 장애를 예방할 수 있을지 고민해야 한다.
작업 분배 기준?
프로젝트 설계 후 업무량을 균등하게 나누었으며, 논의를 통해 각자의 역할을 정했다.
의견 충돌 해결 방식?
다수결을 우선하되, 담당자의 의견을 존중하는 방향으로 조율했다.
QueryDSL을 선택한 이유?
다른 대안을 고려하지 않았으며, Java 기반으로 타입 안정성이 있기 때문이다. 단, 빌드 시 Q파일이 생성되어야 하는 점에서 러닝 커브가 존재했다.
ECS가 아닌 EC2를 사용한 이유?
MSA 배포를 위해 GitHub Actions 스크립트 작성이 어려워, EC2 내에서 Docker Compose를 활용하는 방식을 선택했다.
알람과 알림의 차이?
- 알람: 모니터링과 관련된 경고
- 알림: 예약 및 웨이팅의 최종 경험과 관련된 사용자 안내
알림 채널로 슬랙을 선택한 이유?
카카오 알림톡을 고려했으나, 비즈니스 인증이 필요해 배제됐다. 디스코드, 텔레그램 등도 검토했지만, 캠프에서 이미 사용 중인 슬랙이 접근성이 높아 선택했다.
레디스 스트림 - 네트워크 문제 복구 전략?
센티널 구조를 적용하여 Failover를 구현 중이다.
PostgreSQL을 선택한 이유?
MySQL을 고려했으나, AWS 배포 시 비용적인 문제로 PostgreSQL을 선택했다.