티스토리 뷰

기타

[Street Coding Fighter] 프로젝트 후기

신입 개발자 성장기 2024. 8. 27. 23:46

💡 SSAFY 첫 번째 프로젝트에서 우수상을 수상하고 남기는 후기(회고)

의식의 흐름대로 경험과 느낀점을 기반으로 작성하였습니다.

팀 구성

팀을 구성 할 때 비전공자분이 최소 2명 포함되어야 한다는 조건이 있었습니다. 비전공자분들에게 많은 인사이트를 배우고 협업 경험을 해볼 수 있는 좋은 기회라고 생각하였습니다.

저 포함 전공자 3명, 비전공자 3명으로 팀을 구성하였습니다. 전공자 친구들은 모두 1학기 때 같은 반이어서 친한 사람들이었지만 비전공자분들은 일면식도 없었습니다. 그래서 걱정 반, 기대 반.. 이었습니다

웹엑스로 자기소개를 했었는데, 우리 팀원들이 발표할 때 더 집중해서 봤습니다. 자기소개를 보고 기대가 되는 팀이었습니다. (성격이 다들 좋아보였고, 열심히 잘하는 사람들 같이 보였기 때문)

비전공자분들 중 가장 외향적으로 보이시는 분이 팀장을 한다고 하셔서 좋다고 생각했습니다.

첫 만남

저는 팀원들 모두 첫인상이 좋았습니다.

그라운드 룰을 정했는데, 가장 기억에 남는 룰은 <영어 이름으로 부르기><상대방이 모른다고 가정하고 말하지 말기>였습니다.

상대방이 모른다고 가정하지 말라는 것은 서로에 대한 존중을 하되, 모르는 부분은 바로 얘기하여 소통을 원할하고 효율적으로 하자는 의도 였습니다.

또 영어 이름으로 부르면서 아이스 브레이킹도 되고, 좀 더 의견을 자유롭게 낼 수 있는 분위기를 형성 했다고 생각합니다.

초반

프로젝트 주제 정하기

초기에 주제를 확정하고 설계하는데 많은 시간을 썼습니다. 주제 정하는데 한 주가 소요됐고 그 때 나온 두 개의 아이디어가 팽팽하게 경쟁했습니다.

  1. 짐캐리 (공유 캐리어 서비스)
  2. 스트릿 코딩 파이터 (고등학생 프로그래밍 교육을 위한 코딩 게임 서비스)

이 과정에서 정말 많은 의견을 교환하고, 팀원들의 생각을 들을 수 있었습니다. 팀원들 모두 중요하게 생각하는 것과 흥미를 느끼는 부분이 다르다는 것을 많이 느꼈습니다.

결론적으로 스트릿 코딩 파이터를 선택하게 되었습니다.

설계

저희 팀은 흐름도, 시스템 아키텍처, ERD 등 설계에 팀원 모두 참여하여 의견을 내고 토론하였습니다. 처음에는 “역할을 나누어서 하는게 더 효율적이지 않을까?”라는 생각을 하였습니다. 지금 돌아보면 이 방식이 더 좋았다고 생각합니다.

앞서 말한 것처럼 팀원들이 생각하는 우리 서비스와 내가 생각하는 우리 서비스는 차이가 있을 수 밖에 없다고 생각합니다. 따라서 함께 설계하고 기획을 구체화하면서 모든 팀원들이 같은 배를 탈 수 있도록 하는 작업이 중요하다고 생각합니다. 또한 서비스 흐름이 어떻게 흘러가는지, 시스템이 어떤식으로 설계 되었는지, ERD 설계 등에 대한 이해는 백엔드, 프론트엔드 따질 것 없이 중요하다고 생각하였습니다.

결국 저희 팀은 초반 설계에 많은 시간을 썼지만, 이후 개발 속도는 다른 팀에 비해 굉장히 빨랐고 소통이 원활했다고 생각합니다.

팀원들과 프로젝트에 대한 같은 생각을 가지고 있다는 확신이 들었던게 든든했습니다.

중반

그럼에도 불구하고, 모든 것이 순탄했던 것은 아닙니다.

제가 맡은 멀티 모드 기능은 MVP(Minimum Viable Product)였습니다. WebSocket을 통해서 구현해야하는 기능이었는데, 저는 WebSocket을 통한 개발 경험이 없다보니, 공부를 하면서 개발을 해나갔지만 확신이 들지 않았습니다. 또 나름대로 개발을 완료하고 테스트를 마친 후에도, 게임의 특성상 너무 많은 예외가 존재했습니다. 그래서 프론트와 연동하여 게임을 진행하며 테스트를 해보고 싶은 마음이 컸습니다. 하지만 멀티 모드를 맡은 프론트엔드 개발자분도 WebSocket 개발이 처음이었고, 개발하는데 시간이 오래 걸렸습니다.

소통의 부재 1..

저는 제 나름대로 테스트를 마친 기능을 개발 서버에 배포한 후, 프론트엔드 분의 개발이 진행되기를 기다렸습니다. 프론트엔드 개발자분은 제가 배포한 기능으로 연동하여 개발을 진행하고 있다고 말씀해주셨습니다. 하지만 이후 저는 독촉하는 것 같아서 진행 상황을 자세히 묻지 않았습니다. 며칠이 지나고 조심스럽게 여쭤봤을 때, 문제가 있는데 며칠째 해결을 못하고 있다고 하셨습니다. 그때서야 저는 어떤 문제인지 자세히 여쭤보았고, 알고보니 웹소켓 관련 저의 백엔드 로직 오류였고 잠깐 보고 고칠 수 있었습니다. (WebSocket을 통해 메시지를 보낼 때 모든 유저에게 BroadCast해야하는데, 저는 한 유저에게 메시지를 보내면 프론트엔드에서 해당 정보를 공유할 수 있다고 착각하였습니다.) 프론트엔드분은 내가 잘못했겠지라는 생각으로 말씀을 안하시고 계속 고민하셨다고 하였습니다. 이때 죄송한 마음이 컸고, 이후로 조금 더 적극적으로 대화를 해야겠다는 교훈을 얻었습니다.

소통의 부재 2..

MSA로 설계하면서 Nginx(API Gateway)에서 JWT토큰을 검증하고 Header에 userId를 자동으로 넣어주는 방식으로 구조를 변경했습니다. 백엔드 개발자들은 미리 Header로 userId를 받도록 수정했고, 인프라 담당자는 해당 작업을 수행하는 중이었습니다.

멀티 모드 담당 프론트엔드 개발자분이 최신화가 안된 문서로 인해, 개발 서버와 연동하여 테스트를 진행할 때 Header에 userId를 넣지 않아서 오류가 발생하여 오랜 시간을 소모했다고 하셨습니다. 최신화 하지 않은 것이 첫 번째 문제지만 소통이 잘 되었다면 바로 해결되지 않았을까라는 아쉬움이 남았습니다..

추가 기능 개발

저는 문제 서비스, 랭킹 서비스에 대한 개발을 추가적으로 진행하였습니다.

문제 서비스를 설계하면서 처음으로 기획 초기에 설계한 ERD 수정을 건의했고, 팀원들이 제 의견을 잘 듣고 동의해주어서 변경하는 것으로 결정하였습니다.

 

이후 랭킹 서비스를 설계하면서 많은 고민을 하였습니다. 저희 서비스에서 멀티 모드의 경우 하나의 방에 최대 100명의 유저가 플레이할 수 있습니다. N개의 방에서 플레이중인 최대 100명의 유저의 풀이를 안전하게 저장할 필요가 있다고 생각했습니다. 또한 N개의 방이 동시에 게임이 끝나게 될 경우, 게임 결과(랭킹)을 업데이트 하는 요청이 한 번에 쏟아지게 되어 게임 결과가 손실되는 문제가 발생할 수 있겠다고 생각했습니다. 

따라서 저희는 Kafka 메시지 큐를 도입하기로 결정하였습니다.

 

또한 잦은 업데이트와 많은 읽기 요청이 있는 랭킹 기능의 경우 Redis를 사용하여 구현하기로 하였습니다.

후반

후반에는 기능 개발을 마치고, 제가 만든 서비스의 예외 처리를 하면서 시간을 보냈습니다. 특히 멀티 모드 서비스는 고려할 기능과 예외가 너무 많아서 힘들었습니다..

게임 중간 답안을 제출하지 않고 유저가 방을 나갔을 경우 처리, 게임을 시작하지 않았는데 풀이 메시지를 비정상적으로 보내는 경우 처리, 게임에 참여하지 않은 유저가 풀이 메시지를 제출하는 경우 처리 등..

방장이 나갔을 경우 rotate하는 기능, 모든 유저가 정상적으로 나갔을 경우(웹 소켓이 비정상적으로 끊어지지 않고) 방을 삭제하는 기능, 유저가 웹소켓 연결이 끊겼을 경우 재연결을 처리하는 기능 등..

 

그리고 팀원 중 한명의 동생이 고등학생이어서, 동생의 친구들(5명)과 인터뷰도 하고 직접 게임에 대한 피드백을 받을 수 있었습니다. 실제 이용자를 대상으로 인터뷰도 하고 피드백을 받은 적은 처음이라 더 설렜습니다..ㅎ

 

마지막으로 다른 팀원들도 짜잘짜잘한 기능 추가하고 수정한다고 바빠서 발표 준비를 미리 못했습니다.. 그래서 하루전날 발표 준비한다고 다같이 디코로 준비하면서 밤을 샜습니다..

아쉬운 점

처음 적용하는 기술이 많다보니 체계적으로 개발하지 못한점이 아쉽습니다.. 미리 공부를 한 후 구현하려고 했지만 잘 안되는 부분이 많아서 이것저것 해보고 수정하고 하는 과정이 많았습니다..

또 기한에 대한 조급함으로 기능 구현에 급급하여 깊게 공부 못한 부분도 있고, 트러블 슈팅 기록을 제대로 못한점이 아쉽습니다.

사실 이번 프로젝트하면서 기록을 잘 해야겠다.. 1일 1블로그 써야겠다... 다짐했지만 실천하지 못한 점이 가장 아쉽습니다.

후기

그럼에도 불구하고 정말 만족하는 프로젝트였고, 팀 분위기가 너무 좋았습니다.

1. 서로서로 의견을 존중하고 다른 의견이라도 기분 나빠하지 않고, 경청하고 자기 생각을 말하는 점이 좋았습니다.

2. 특히 설계 할 때 서로 많은 의견을 내면서 다양한 관점을 고려하여, 프로젝트 끝까지 초기 설계가 거~의 변하지 않은 점이 대단했다고 생각합니다.

3. 새로운 기술을 많이 사용할 수 있어서 좋았습니다. 이번에 WebSocket, Redis, Kafka, MSA 모두 처음 시도해본 기술들이었는데 기간 내에 모두 적용할 수 있어서 다행이었고, 많이 배울 수 있었습니다.

4. 마지막으로 우수상을 받아서 뿌듯했습니다. 함께 열심히 달려온 팀원들에게 고맙고 감사한 마음이 큽니다..!

'기타' 카테고리의 다른 글

[회고] 늦은 2025년 회고.. 회사 적응기  (0) 2026.02.02
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday