[회고] SSAFY 공통 프로젝트 - Street Coding Fighter

🥈 SSAFY 2학기 첫 프로젝트 (공통 프로젝트) 우수상 수상

첫 프로젝트를 마치고 회고하는 글로 경험한 것과 느낀점을 자유롭게 정리하였습니다 :)

해당 프로젝트는 2024년 7월 8일 - 2024년 8월 16일 총 6주동안 진행되었습니다.

프로젝트 설명

프로그래밍을 게임처럼 즐기는, 실시간 참여형 학습 플랫폼 'Street Coding Fighter(스코파)'

아래는 프로젝트 개요입니다.

2017년 교육 과정 개정으로 인해 현재 고등학생들은 프로그래밍 교육을 의무적으로 받고 있습니다. 또한, 2025년부터는 초등학생과 중학생도 프로그래밍을 의무적으로 배우게 됩니다.

저희는 경남 양산의 한 고등학교 학생들을 만나 이야기를 들어보았습니다.

인터뷰 결과 학생들은 코딩이 중요하다는 것을 알지만, 학교 수업이 이론 중심으로 진행되어 지루하고 재미가 없다고 말했습니다. 특히 학생들은 코딩의 중요성을 인지하고 있지만, 이론 중심의 수업과 배운 내용을 단순 학습지에 답안을 채우는 방식의 수업에 흥미를 잃고 있었습니다.

이러한 문제를 해결하기 위해, 저희는 어떻게 하면 학생들이 코딩을 재미있게 배우고 더 효과적으로 학습할 수 있을지 고민하여 코딩을 게임처럼 즐길 수 있는 실시간 참여형 학습 플랫폼, '스트릿 코딩 파이터'를 제작하게 되었습니다.

 

서비스의 기능과 기술 스택 등은 아래 깃허브 레포지토리 리드미를 참고해주세요 :)

 

https://github.com/SunYerim/Street-Coding-Fighter

 

---

프로젝트 진행하며

1. 팀 빌딩

저희는 본인 포함 전공자 3명과 비전공자 3명으로 팀이 구성되었습니다. 전공자 분들과는 1학기때 같은 반이었기에 친했었고, 비전공자분 중 한 분과 오며가며 인사는 하고 지냈었습니다. 반이 배정된 후 빠르게 팀 빌딩을 해야 좋다는 이야기를 들어왔기에, 제가 나서서 팀을 꾸렸습니다. 비전공자분들과 함께 첫 협업이다보니 기대가 많이 되었고, 어떤 분들인지 잘 몰랐기에 설렘 반, 걱정 반 .. 이었습니다!

그렇지만, 팀원들의 자기소개를 보며 '다들 열정이 넘치시는 분들이신 것 같다'라는 생각이 들어 프로젝트가 기대되었습니다 😄

 

2. 가화만사성팀의 '그라운드 룰'

마인드셋

• 학무지경
• 모르는 것 인정하기
• 상대가 모를 것이라고 전제하지 않기
• 눈치보지 않기

그라운드룰

• 매일 마치기 30분 전 개인 회고 진행
• 영어이름 부르기
• 회의시 인형을 들고 이야기하기
• 아침 인사는 무조건 영어이름으로 하기

등이 있었습니다. 저는 여기서 '모르는 것 인정하기', '상대가 모를 것이라고 전제하지 않기' 이 두 부분이 특히 좋았습니다.

이전에 프로젝트 경험은 어느정도 있었으나, 백엔드 개발 파트를 맡아 제대로 해보는 프로젝트는 처음이었기에, 헷갈리는 부분이나 처음 접하는 기술도 있었습니다. 이 부분에 대한 느낀점은 후에 언급해보겠습니다 ㅎㅎ

 

3. 프로젝트 설계

우선, 저희팀은 흐름도, 화면설계, ERD 설계 등 모든 설계를 6명 다 함께 진행하였습니다. 사실 이전에 학교에서 했던 프로젝트들 모두 웬만하면 프론트엔드, 백엔드 모두 다 함께 설계하기도 했어서 낯설지는 않았습니다. 그렇지만, 이정도로 모든 것을 다같이 해본 건 처음이라 '개발 시간이 부족해지지 않을까?'라는 생각이 들긴했는데, 결과적으론 그렇지 않았습니다!!

설계에 시간을 많이 들인만큼, 6명 모두의 생각이 같은 방향으로 정립되었고, 개발 속도도 빨랐습니다. 무엇보다 소통이 원활했기에 모든 과정이 크게 막힘없이 진행되었던 것 같습니다.

팀원들과 프로젝트에 대해 같은 생각을 가지고 있다는 것 자체가 든든했고, '중간에 어떠한 어려움이 생기더라도 이 사람들과 함께라면 무조건 헤쳐나갈 수 있겠다!'라는 확신이 생겼었습니다.

 

4. 프로젝트 개발

저는 이번 프로젝트에서 "회원관리, 프로필 관리, 튜토리얼 모드" 개발을 도맡아 했습니다. 위에서도 언급했지만, 저는 백엔드 개발경험이 풍부하지 않았기에, Spring security 사용이 처음이었습니다. 그렇지만, 프론트엔드 개발을 했었기에 흐름은 알고있었습니다.

저희는 백엔드 팀원끼리 mr마다 코드리뷰를 진행했었는데, 첫 mr을 날렸을때 정말 많은 질문이 들어왔었습니다 ......ㅎ 지금 생각해보면 설계에 조금 더 시간을 많이 들이고 코드를 작성해도 됐었을 것 같은데 빨리 해줘야될 것 같다는 생각때문에 로직을 꼼꼼히 확인하지도 않았던 것 같습니다. 예를 들어, 로그인할 때 token발급 로직을 2번 작성해뒀다던가 .... (진짜 바보멍청이였네 나자신아)

당시에 다른 백엔드 팀원분끼리 처음부터 코드리뷰를 너무 쎄게(?) 하는 것이 아니냐 라는 이야기가 오갔다고 하는데 저는 오히려 좋았습니다. 저도 security를 처음 사용해봤기에 코드에 대한 확신이 없었고, 마음에 들지 않았기 때문에 리뷰 해주신 것들을 하나하나 읽어보며 '이런 부분은 고쳐야겠다, 앞으로 설계 시간을 조금 더 많이 가져가야겠다' 라는 생각을 정말 많이 했습니다.

이후 mr날릴때부터는 생각하는 시간을 이전보다 조금 길게 가져가고 꼼꼼하게 코드를 작성하려 노력했습니다. 확실히 처음보다 코드 가독성 부분에서도 그렇고 좋아지는 게 눈에 보였습니다. 헷갈리는 부분이 있다면 무조건 팀원에게 질문 또 질문, 내가 이해한 로직이 맞는지 논의했던 것 같습니다!

 

입에 발린 좋은 말들 듣는 것도 좋지만, 따끔하게 조언을 듣고 부족한 부분을 채워가며 스스로 성장하고 싶은 욕심이 더 컸기에 코드리뷰 부분이 정말 좋았습니다. 다른 mr때 남겨주신 코멘트들을 기록해두고, 스스로도 다시 코드를 읽어보았습니다. 이러한 부분들을 이번 특화프로젝트때 신경써서 개발해 볼 예정입니다.

 

4-1. 적용할 새로운 기술들이 쏟아진다!

우선, 이번 프로젝트 진행하며 처음 써 본 기술들이 많았습니다!

MSA아키텍처나 Docker와 같은 인프라쪽 기술들은 이전에 친구와 개인 프로젝트를 하면서 사용을 해봤었는데, Kafka, Redis, Spring security ... 는 처음 시도해본 기술이었습니다.

처음 시도해본 기술들이라 걱정이 많이 되었는데, 팀원들과 함께여서 기간 내에 모두 적용할 수 있었던 것 같습니다. 그 과정에서 또 많이 배울 수 있었습니다.

 

4-2. RequestHeader에는 userId가 아니라 memberId !

이건 별 문제는 아니었지만 약간의 웃픈 이슈 ...? 정도겠네요.

이전에 MSA 아키텍처로 프로젝트를 설계했을때, 인증서버(Gateway Server)를 따로 뒀었는데요. 이때 클라이언트 입장에서는 header에 accessToken만 포함하여 인증서버(Gateway Server)로 요청을 보내면 해당 서버에서 토큰 검증 후 token에 포함된 memberId를 추출해 헤더에 추가한 뒤 실 요청 서버로 요청을 전달했는데요.

 

이번에도 역시 동일한 로직으로 처리하였습니다. 물론 이번에는 Nginx가 gateway역할을 담당했습니다.

 

제가 유저측 서비스를 담당했기에 ERD에서 member 테이블의 PK인 memberId로 token에 각 회원의 고유 id를 넣어뒀었습니다. 하지만 Nginx(API Gateway)에서 token을 decoding할 때 userId를 찾으려 했기 때문에 회원 고유 id 값을 찾을 수 없었습니다.

그래서 통신이 제대로 되지 않았었는데요. 이때, 사소한 부분이라고 생각되더라도 소통을 하자 ! 라는 교훈을 얻었습니다.

 

4-3. 게임 결과가 손실되지 않도록 Kafka 메시지 큐를 도입하자.

저희 서비스의 주요 기능인 '멀티 모드'의 경우 한 게임 방에 최대 100명의 유저가 게임을 플레이할 수 있습니다. 이 때, 여러 개의 방에서 플레이 중인 최대 100명의 유저들의 문제 풀이와 게임 결과 기록을 유실시키지않고 안전하게 저장시켜야 되지 않을까? 라는 팀원의 고민을 듣게 되었습니다. 이 게임 결과는 동시에 랭킹을 업데이트 하는 요청과도 직결되어있기 때문에, 게임 결과를 업데이트 하는 요청이 한꺼번에 쏟아지게 되면 게임 결과가 손실되는 문제가 발생할 수 있겠다고 생각했습니다.

이때문에 저희는 Kafka 메시지 큐를 도입하기로 했습니다.

 

4-4. Kafka 에서 100만번의 로그 발생으로 서버가 다운되버렸다.

게임이 끝난 후, GameResult의 리스트를 publish했습니다. 이 때, 리스트 자체를 직렬화하면서 문제가 발생했습니다. 리스트가 직렬화되면서 문자열(String)로 변환되었고, 이를 다시 역직렬화하려고 시도했을 때 문제가 생겼습니다. 이로 인해 100만 번의 로그..가 발생했고, 로그 용량이 어마어마해서 결국 서버가 다운되는 현상까지 발생되었습니다😂

 

이 경우는 Kafka 기술 자체를 처음 썼다보니 생겼던 문제라고 생각합니다 .. !

List를 publish하지말고 개별 객체를 for문을 통해 publish하자! 라는 깨달음을 얻을 수 있었습니다.

 

---

5. 프로젝트 후반

후반부에는 제가 맡은 기능 개발을 마치고, 프로젝트의 완성도를 높이기 위해 디테일한 디자인 부분 수정 작업을 하고 프론트엔드 분들과 소통하며 더 필요한 api가 있으면 설계를 하며 시간을 보냈습니다. 

 

나 혼자 하는 프로젝트가 아니라, 우리 모두가 하는 프로젝트라고 생각했기에 프론트엔드 부분 개발을 하면서도 즐겁게 프로젝트를 할 수 있었던 것 같습니다 !!

 

그리고 제 동생이 고등학생인데, 저희 프로젝트 사용 대상이 고등학생 친구들이어서 동생의 도움을 정말 많이 받았습니다.

실제 고등학생 친구들(5명) 인터뷰도 하고 직접 피드백을 받아 서비스를 더욱 개선할 수 있었습니다.

 

6. 내가 500명 앞에서 발표를 하게되다니 ?! 그런데 발표 준비할 시간이 이틀밖에 안 남았다..

저희팀은 원래 다른 팀원분이 발표를 진행하셨습니다. 발표를 잘 해주셨는데, 저희 프로젝트의 컨셉과 발표자 분의 목소리 톤이 안 맞다는 피드백을 계속 받게되었습니다. 

그렇지만, 발표 처음부터 끝까지 전반적으로 잘 해주셔서 팀원 모두 으쌰으쌰하며 조금만 더 파이팅하자는 분위기였는데, 본선 진출후에도 해당 피드백이 계속 들어와서 결국엔 제가 하게 되었습니다.

 

이전 대학교 다닐때 전공수업, 동아리, 졸업작품 등에서 발표 경험도 어느정도 있었고, 1학기 관통프로젝트 최종 발표에서도 제가 발표자였어서 '발표 자체'에는 크게 부담이 되지 않았습니다. 그렇지만, 이번에 새로 적용한 기술들도 워낙많고 전 발표자분에 비해서 정말 완벽하게 숙지된 상태가 아니였기때문에 질문 부분에 있어서 약간의 부담감이 있었습니다. (바늘로 쿡 찌르면 바로 완벽하게 술술 나올 정도는 아니었습니다 ..)

그렇지만 팀을 위해 제가 해당 역할을 맡았으니 남은 시간동안 최대한 노력을 해보자는 마음을 갖고 발표 연습도 새벽까지 하며 나올만한 질문이나 기술들을 다시 꼼꼼하게 정리하는 시간을 가졌던 것 같습니다. 발표 스크립트도 처음부터 끝까지 다시 짜고, 시연자가 어느 부분에서 페이지를 넘겨야되는지도 다 작성해서 시연자와 계속 합을 맞췄습니다. 이때 새벽까지 팀원들을 조금 괴롭혔는데 다들 열심히 들어주고 피드백주셔서 정~말정말 감사했습니다 😄

---

아쉬운 점

그리고 entity에 Setter 사용을 지양해야된다는 걸 알고 있었는데, 이번 프로젝트때 이 부분을 간과하고 코드를 작성했습니다. 저 부분은 익히 들어왔는데, '내가 왜 그랬지?'라는 생각이 정말 많이 들었습니다. 제일 기본적인 부분인데, 너무 급하게 개발한 게 후회가 되더라고요 .. 그래서 다음 프로젝트때는 꼭 신경써서 개발을 하려 합니다.

더욱 체계적으로 꼼꼼하게 개발하고싶었는데, 새로 적용해야되는 기술들도 쏟아졌고 기한이 그렇게 넉넉치 않았기에 조급함이 앞서 깊게 공부하지 못한 부분, 그리고 트러블 슈팅도 제대로 하지 못한 점이 아쉽습니다.

매일매일 느낀점에 대해 간단하게라도 1일 1블로그를 작성해야겠다 ... 다짐했었는데 못 지킨 부분도 아쉽습니다.

 

프로젝트 후기

백엔드로 전향 후 얼마되지않아 싸피 입과를 해서 controller, service, model(dto, entity) 어떤식으로 나누고 작성해야하는지, entity to dto를 왜해야되는지 등 기본적인것도 많이 헷갈려해서 어려워했던 게 엊그제 같은데, 몇개월만에 많이 성장했음을 느꼈습니다.  1월 초에 졸업 전 동아리에서 했던 프로젝트 마무리가 안되서, 팀원분 중 한 분한테 집중 과외를 요청한 것도 엊그제 같네요.

한편으로, 기본적인 부분들을 다시 한 번 더 꼼꼼히 정리해야겠다는 생각을 했습니다.

이전 대학교 동아리 WAP에서 진행했던 Bejuryu 프로젝트도 팀원간 합이 정말 잘 맞았어서 '이것보다 잘 맞는 사람들을 만날 수 있을까'했었는데, 해당 프로젝트로부터 정확히 1년 뒤 정말 합이 좋은 팀원들을 또 만났네요 😁 정말 저는 운이 좋은 것 같습니다 ㅎㅎ 

 

제가 이렇게까지 만족하면서 프로젝트를 할 수 있었던 이유는 팀 분위기가 정~말 좋았기 때문이라고 생각합니다.

• 서로의 의견을 존중하고 다른 의견이 나오더라도 기분 나빠하지 않고 경청하며 본인의 의견을 말하는 점이 좋았습니다.
• 저희 팀은 모든 설계를 6명 다같이 했는데, 비록 설계하는 데 다른 팀보다 시간이 오래 걸렸지만 프로젝트 끝까지 초기 설계가 거의 변하지 않았던 점이 대단하다 ! 생각합니다.
• 각자의 업무가 나눠져있다 생각하지않고, 모두가 함께 고민해주고 도왔기에 본선 진출하여 '우수상'도 받을 수 있었다고 생각합니다. 힘들어도 티내지않고 함께 끝까지 열심히 달려온 우리 가화만사성 팀원들에게 고맙다는 말을 전하고 싶습니다 😊

---

우리팀 고생했습니다~ 가화만사성팀 최고

다음 특화프로젝트 팀원들과도 분위기가 너무 좋아 기대가 됩니다. 부족한 부분은 제가 더 노력해서 채워가며 열심히 달려보겠습니다. 파이팅 :)