[프로젝트 회고] URTurn 페어 프로그래밍 기반 알고리즘 풀이 서비스

✅ URTurn

알고리즘과 페어 프로그래밍을 접목한 개발자를 위한 협업 코딩 서비스

✅ 프로젝트 설명

• 기획 배경

  • 팀 프로젝트를 진행하면서 다른 사람이 작성한 코드 독해력을 
    키우고 가독성 좋은 코드 작성 위한 필요성을 느낌

• 서비스 설명

  • 알고리즘 문제 풀이와 페어 프로그래밍을 결합
  • 2명이서 페어를 이루어 2개의 문제를 번갈아가며 코드를 작성하여 이어서 풀이
  • 이를 위해 변수 명, 메서드 명, 주석을 고려하고 가독성 좋은 코드를 작성하며 다른 사람의 코드를 읽는 연습을 자연스럽게 할 수 있음

• 개발 기간 : 2024.04.08 ~ 5.17 (6주)

  • 아이디어 1주
  • 설계 1주
  • 개발 3주
  • 발표 1주

• 인원 : 5명

✅ 역할 (Infra / Backend)

• 인프라 구축 및 자동배포 파이프라인 구축
• 채점 & 회고 도메인 담당
  • 채점 서버 구축 및 메인서버 통신 로직 구현
  • 회고 저장 및 GITHUB 자동 업로드 로직 구현
• 인증 / 인가
• PM & QA 업무 (일정 관리, 업무 분배, 버그 리스트업 및 관리)

✅ 주요 기술 스택

Spring Boot, MySQL, Spring Data JPA, Querydsl, Spring Security, JWT, Oauth2
EC2, Nginx, Docker, Jenkins, Sonarqube, Prometheus, Grafana, Promtail, Loki
Gitlab, Jira, Notion

✅ System Architecture

• 메인서버에서 클라이언트와 웹소켓 통신

• 부하가 높은 채점 서버 AWS 별도 인스턴스로 분리

• 문제 풀이 진행하면서 생기는 비 영구적인 상태 데이터 (문제 풀이 상태, 제출 코드 등) 을 redis에 관리

✅ Keep

기술

1. 무중단 배포 구현

   • 본 프로젝트는 WAS 개수가 적고, 분산환경으로 관리하지 않음
   • 서비스 중단이 없고, 신속한 롤백이 가능한 블루/그린 배포 전략 선택
   • 재 배포에 따른 서버 다운 타임 30초 → 1초 미만으로 개선
   • STOMP.js를 활용하여 서버 재빌드에 의한 웹소켓 재연결
   • Redis에 상태를 저장하여

2. 웹소켓을 사용한 양방향 통신 서버 구현

   • 서버를 거치지 않아도 되는 음성 채팅, 코드 실시간 공유, 이모티콘 기능은 WEB-RTC를 활용

3. Sonarqube를 활용한 정적 분석 기반 리팩토링

   • 수정 전 8 bug, 4 security hotspot, 353 code smell
   • 수정 후 0 bug, 0 security hotspot, 0 code smell
     • 불필요한 import문 삭제, var 사용 권고 등의 약 130개의 code smell은 수정하지 않음

4. 트러블 슈팅과정 개선을 위한 grafana - promtail/loki 연동
   

전략

1. Swagger 재도입

   • Swagger를 재도입한 이유는 아래와 같다.

   • Postman과 API 명세 만으로 프론트와 백이 원활하게 통신하기 어려웠기 때문이다.

   • Postman의 무료 버전에서는 Teamspace에서 최대 3명만이 접근이 가능했었다. (때문에 공통 프로젝트에서는 공통으로 사용하는 POSTMAN ID를 만들어 공유해서 사용했었다)

   • Swagger는 빌드된 서버 기준으로 API를 확인할 수 있음으로 백엔드 팀원이 놓치고 기록하지 못한 API 수정 내용에 대해 더블 체크가 가능했다.

2. 서버 지급 일자 당일부터 바로 서버를 구축할 수 있도록 미리 준비를 해두었다. 덕분에 직전 프로젝트 인프라 구축 (2주)에 비해 빠르게 (2일) 진행할 수 있었다.

3. 프로젝트 종료 1주일을 앞두고 백엔드 팀원이 면접 준비로 인해 업무에 온전히 참여하기 어려웠고, 백에 비해 프론트 기능이 전부 붙지 않았다.

   이를 위해 PM 업무를 맡아 각 페이지, 도메인별로 구현할 기능, 고쳐야 할 버그, 추가 구현하면 좋을 기능들을 모두 리스트업 하여 프론트 담당자 3명에게 업무를 분배하고 매일 사용자 플로우를 돌리면서 진척상황을 확인했다. 덕분에 목표한 일정 내에 개발을 완료할 수 있었다.

   이번에 맡은 백엔드, 인프라는 물론 최종 발표, PPT 작성, 포팅 메뉴얼, README 작성에 PM, QA 업무까지 진행하니 정말 바빴다.. 하지만 덕분에 프로젝트를 보다 거시적으로 바라볼 수 있었고 각 담당자들에게 효과적인 소통 방식을 선택하여 적절한 업무를 배분할 수 있었다고 생각한다.

4. 작은 것이지만 교보재로 도메인도 사서 적용해보았다. 도메인 이름은 urturn.site !

협력

1. 아침 스크럼과 퇴근 전 진행 업무 공유를 빠지지 않고 진행하여 프로젝트 일정 관리하였다.

2. 백엔드 팀원과 일정 및 진행상황과 예상 리스크를 매일 공유하였다. 덕분에 서로의 일정에 맞추어 업무를 유연하게 분배할 수 있었다. 예시로 서로의 면접 일정에 대비하여 상대방의 업무를 가져가면서 프론트와의 개발 진도를 맞출 수 있었다.

✅ Problem

기술

1. 영구적으로 저장하지 않을 데이터라고 과연 무조건 RDBMS가 아닌 Redis에 저장하는 것이 맞는가?

   이 부분에 대해 백엔드 팀원과 오랜 토론을 했고, 기술 컨설턴트 님의 조언까지 받았는데, 실무에서는 영구적으로 저장하지 않을 데이터는 기본적으로 RDBMS에 넣지 않는다고 했다. 그리고 라운드별로 임시로 사용자가 작성한 코드를 저장하기 위해서는 NoSQL을 사용하는 것이 옳다고 생각이 들었다. (몇 개의 라운드가 진행될지 모르는 비정형 데이터임으로)

   하지만 꼭 레디스여야 하는가? mongoDB 등을 활용했어도 되지 않았을까? 그리고 서비스 규모를 생각해보았을 때 오버 엔지니어링이 아닌가? RDBMS에 저장하고, Spring Batch를 활용해 주기적으로 지워준다면 일정 기간동안 데이터를 로그로 관리할 수도 있고, 나름 괜찮은 방법일 수 있지 않은가? 물론 Redis를 사용해보고자 하는 목적도 있어 Redis로 결정하였지만, 보다 더 깊게 고민할 숙제를 가진 것 같았다.

2. 클라이언트와 서버의 책임에 대해 고민하게 되었다.

   웹소켓 연결을 끊어주는 부분을 과연 어디서 책임지는 것이 좋은 것인지에 대해 의문이 들었다. 본 프로젝트에서 필자는 웹소켓을 주로 담당하지는 않았는데, 웹소켓 파트를 담당했던 백엔드 팀원과 프론트 팀원의 토의 결과 웹소켓 연결 책임을 클라이언트 측에서 관리하기로 했다.

   하지만 실무에서는 분명 서버에서 웹소켓 세션을 직접 관리해야 하는 것으로 알고있다. 서버에서 세션을 효과적으로 관리하기 위해 세션 클러스터링, 세션 스토리지 분리 등을 할 수 있는데, 무중단 배포 과정에서 끊어지는 커넥션을 재 연결하기 위해 현재 사용중인 redis에 세션 정보를 관리하는 것도 좋은 선택이라고 생각이 들었다. 웹소켓에 대한 이해가 부족한채로 프로젝트를 진행하면서 이상한 점을 알게되어, 웹소켓 세션 관리의 중요성을 미리 학습하여 담당 팀원들을 설득하지 못했던 것이 아쉬웠다.

✅ Try

첫 프로젝트인 COMEET을 진행했을 때 느꼈던 부족함이 또 다시 느껴졌다. 당시에는 인프라 구조를 모르니 클라이언트와 어떻게 소통하는지, 다수의 서버끼리 어떻게 통신하는지에 대해 이해가 되지 않았다.

첫째, 클라이언트 단의 이해도를 높혀야한다는 필요성

프론트 팀원과 소통 및 트러블 슈팅하는 과정에서

웹소켓 연결을 끊어주는 부분을 어디서 책임을 져야하는지부터 의문이었다. 웹소켓 부분을 담당했던 백엔드 팀원과 프론트 팀원의 토의 결과 클라이언트 측에서 관리하기로 했지만.. 실무에서는 분명 서버에서 웹소켓 세션을 직접 관리해야 하는 것으로 알고있다.

그리고 어떠한 데이터를 클라이언트단에서 상태관리를 해야하고 할 수 있는지를 모르니, API 명세를 보다 비효율적으로 작성하고 있지는 않은가? 불필요한 정보를 요청하고 제공하고 있지 않는가?라는 의문이 자주 들었었다.

즉, 프론트를 내가 많이 모르고 있다는 생각이 계속 들었고, 프론트에 대한 기본적인 이해는 갖추어야 전체적인 서비스 구조 및 사용자 흐름을 파악할 수 있다고 느껴졌다.

둘째, 다양한 서비스의 설계를 학습하고 이해해야겠다는 필요성

URTurn 서비스 설계 과정에서, 팀원들과 내가 알아본 내용이 다른 경우가 있었다. 사실 이는 큰 문제가 아니지만 서로가 서로의 주장에 확신이 없던 적이 있었다는게 문제였던 것 같다.

처음에는 양방향으로 통신해야하니 웹소켓을 사용하는 것도 좋지만, 서비스의 특성상 초단위로 다수의 데이터를 받는 것이 아니고, 한 방에 2명의 유저만 들어가기 때문에, 폴링으로 구현해도 되지 않을까라는 생각도 했었다. 그리고 웹소켓이 연결되고 끊는 시점은 언제여야 하는지에 대해서도 의견이 나뉘었었다. 보통 게임 서버는 로그인되는 시점부터 게임을 종료할 때까지 웹소켓을 연결해둔다고 팀원이 주장하였는데, 정작 본인도 이 내용이 맞는지 확실치가 않아서 고민을 많이 했던 기억이 있다.

사실 웹소켓이라는 기술을 팀원들 모두 처음 사용해보았음으로 그럴 수 있지만, 우리가 사용하는 시스템이 어떠한 형태로 설계되어있는지에 대한 이해가 아직 부족하다는 생각을 지울 수 없었다. 때문에 다양한 시스템이 어떻게 설계되어있고, 그 이유는 무엇이고 어떠한 장단점이 있는지에 대해 공부해야 할 필요성을 느꼈다.

셋째, 테스트 코드의 부재

제일 약점이라고 느껴진 부분이었다. 테스트 코드를 이번에도 제대로 작성하지 못했다.. 게다가 웹소켓의 테스트코드는 어떻게 작성해야하는지 막막했는데 찾아보니 Junit에 WebSocketStompClient, CompletableFuture을 활용하여 작성할 수 있었다. 테스트 코드 작성에 이해도가 많이 부족하다고 느껴져 테스트코드 관련 강의를 수강하고, 기존 프로젝트들에 붙여보고자 한다.

기술

1. 테스트 코드 작성법 공부 (유데미 강의 신청 완료, 6월부터 수강 예정)

2. 자바스크립트 공부 (유데미 강의 신청 완료, 7월부터 수강 예정)

3. 가상 면접 사례로 배우는 대규모 시스템 설계 기초 공부 (광진정보도서관 비치, 2권도 있음)

협력

1. 지라의 담당자 자동 할당, 작업 툴 연동, 차트 활용 등 다양한 기능을 보다 적극적으로 활용해보자

✅ 소감

☘️ 예상대로 팀원 한명이 취뽀에 성공하여 아이디어 단계에서 빠지게 되면서 백엔드 맨파워가 부족했었다. 또한 필자도 네이버 면접 준비, 다른 백엔드 팀원도 삼성 면접 준비를 병행했어야 했지만 직전 프로젝트인 Flowermari 때보다는 더 좋은 결과물이 나온 것 같다.

☘️ 일정관리를 주도적으로 진행했다. 직전 프로젝트와 거의 동일한 팀원으로 진행하게 되어 서로의 업무 성향을 잘 파악할 수 있었고, 이에 따른 업무 분담을 성공적으로 한 것 같다. 전 프로젝트를 타산지석삼아 초반에는 거시적으로, 마지막에는 하루 단위의 마이크로 매니징으로 일정 관리를 진행하였다.

☘️ 싸피가 끝난다. 2학기는 전공자들과 프로젝트를 진행하며 나는 우물 안 맹꽁이라는 생각을 늘 달고 살았던 것 같다. "너무나도 안 좋은 시간에 도전을 한게 아닌가"라는 마음이 스멀스멀 올라올 때 키보드 앞에서 코드 한줄이라도 더 치고, 글이라도 한 줄 더 읽고, 운동을 했다. 그리고 주변 동료들과 진지하기도, 실 없기도 한 대화들을 주고 받았다. 3회의 프로젝트를 진행하면서 정말 많이 성장하였는데, 무언가를 만들다보니 더 빠르게 실력이 큰 것도 있지만 여러 팀원들과 아이디어와 지식을 공유하고, 부딛히고 협동했던 것이 가장 큰 양분이 되었다고 생각한다. 때문에 꼭 작더라도 스터디를 만들어서 공부를 이어나가야겠다.