Tripagram 회고
11월에 여행 정보 공유를 주제로 한 서비스를 개발하기 위해 팀 단위 프로젝트를 진행하였다.
프로젝트는 11월 8일부터 12월 7일까지 약 한 달 동안 진행되었다.
여기서는 해당 프로젝트를 진행하면서 느낀 점이나 경험한 것들을 기록하려고 한다.
1. 내가 뽑은 내 팀원
이번 프로젝트는 랜덤으로 팀이 정해질 수도 있었지만 내가 직접 팀원을 고를 수 있었다.
나는 랜덤으로 팀이 정해지는 것보다 내가 주도적으로 팀원을 선택하고 싶어서 직접 팀원을 선택하기로 했다.
직접 팀원을 고르려고 하니 내가 직접 팀원을 고를 때만 보이는 것이나 느낄 수 있었던 것들이 있었다.
팀원을 직접 선택하려고 하니 많은 사람들이 후보군으로 내 머릿속에 올라왔다.
각자 다 장점이 있었고 이 중에서 한 명을 뽑는 것은 결코 쉬운 일이 아니었다.
정말 많은 고민을 하다가 결국 몇 가지 기준을 세우고 그에 부합하는 팀원을 고르기로 했다.
첫 번째로 개발에 필요한 언어(Java)에 대한 숙련도를 봤다.
언어의 숙련도가 낮으면 비효율적인 코딩을 할 수밖에 없고 원활한 의사소통이 힘들 수 있기 때문이다.
예를 들어 내가 팀원에게 A를 부탁했는데 이를 쉽게 해결할 수도 있지만 언어 숙련도가 낮으면 괜히 어렵게 돌아가는 상황이 종종 나오기도 한다.
내가 Java에 대해 초고수는 아니지만 언어에 대한 숙련도가 많이 차이가 나면 위와 같은 경우가 발생할 수 있고 프로젝트 도중에 일일이 이를 케어해주기도 어렵기 때문에 일정 수준의 언어 숙련도를 팀원을 선택하는 주요 요소로 정했었다.
두 번째로는 문제 해결 능력을 봤다.
개발을 하다 보면 예외 상황이든 새로운 기술을 사용해야 되는 상황이든 간에 반드시 막히는 때가 온다.
이때 얼마나 효율적으로 문제를 해결할 수 있을지를 보았다.
특히 문제를 해결해도 수박 겉핥기로 해결하는 것과 원인을 분석해서 해결하는 것은 천지 차이이다.
지속적인 개발을 하기 위해서 이런 부분이 중요하다고 생각했기 때문에 나는 이런 점을 주요하게 보았다.
세 번째로는 유연함을 보았다.
팀 프로젝트는 서로 협력해서 개발을 진행해야 하는데 당연히 각자의 생각이 다를 수 있다.
특히 내 의견과 다른 사람의 의견이 부딪혔을 때, 논리 없이 자신의 의견만을 내세우지 않고, 냉정하게 프로젝트에 있어서 효율적인 생각을 고를 수 있는 사람을 팀원으로 선택하려 했다. 혹은 팀의 분위기나 능력, 상황 여러 상황을 고려했을 때 효율적이지 않더라도 여러 가지를 고려했을 때 다른 사람의 의견을 받아들일 수 있는 사람을 선택하려고 했다.
이건.. 굉장히 중요했다 이게 안되고 고집만 있으면 팀은 망한다 생각한다.
그 외에 의사소통 능력, 인성 등 여러 가지를 고려했지만 위의 세 가지 사항을 중점으로 만족하는 팀원을 선택했다.
나는 알고리즘 스터디에서 위의 요소들에 부합하는 분을 선택했다.
같이 개발은 한 번도 한 적은 없었지만, 알고리즘 문제를 푸는 모습을 보면서 검증된 언어 숙련도와 점점 발전하는 코드 그리고 새로운 기술들을 받아들이는 유연함이 돋보여서 그분을 선택하게 되었다.
결과적으로 다시 돌아보면 나는 같이할 팀원을 아주 잘 선택했다고 생각한다.
개발은 물 흐르듯이 진행되었고 다른 불필요한 것들을 최소화하여 오로지 개발에만 집중할 수 있었다.
권모술수가 난무하는 IT업계에서 어설픈 자는 살아남지 못한다.
지금 생각해보면 팀원을 선택하는 것도 능력이다
다행히 나는 심사숙고 끝에 팀원을 선택했고 좋은 결과를 얻었다.
2. 개발 규칙은 철저히
저번 프로젝트에서 개발에 대한 규칙을 구체적으로 정하지 않아서 고생 꽤나 했었다.
그래서 이번에는 정말! 세세하고 구체적인 부분까지 하나하나 규칙을 세웠다.
우선 내가 초안을 작성하고 팀원분과 같이 앞으로 개발에 적용할 커다란 규칙들을 정했다.
단순히 코드 컨벤션 같은 것뿐만 아니라 프로젝트의 구조와 주요하게 사용되는 클래스가 어떤 역할을 할지부터 기본적인 네이밍 까지 정말 개발 전반에 가이드가 될 수 있는 사항들을 정했다.
[개발 규칙]
처음에 이렇게 많은 양의 규칙을 정하는 것은 힘들었지만 지금 생각해보면 정말 정말 잘했다고 생각한다.
개발에 대한 전반적인 규칙과 가이드가 있었기에 팀원과 같이 개발한 코드는 일정 규칙아래 규격화된 모습을 보여주었다.
모두 같은 매뉴얼에 따라 코드를 작성했기에 예외 사항은 크게 발생하지 않았고 자잘한 부분을 코드 리뷰를 통해 조정하면 됐었다.
결론적으로 개발 시작 전에 전반적인 규칙을 정한 것은 성공적이었다.
3. 성능과 실무 상황을 고려한 프로젝트
개발을 시작할 때 구현하기로 정한 API는 2주 만에 완성되었다.
절대 억지로 급하게 한 것도 아니고 Mock API도 만들고 테스트코드도 다 작성하면서 했는데 2주 만에 완성을 해버렸다.
그런데 애초에 처음에 구현하기로 정한 API가 많지 않아서 빨리 완성했었던 거 같기도 하다.
프런트 쪽 개발 진행속도로 봤을 때 기능을 더 추가하기에도 애매했기 때문에 백엔드 팀은 프로젝트의 성능 고도화로 초점을 돌렸다.
멘토님의 도움을 받아 크게 두 가지 사항을 개선하였다.
첫 번째로 우리 프로젝트에서는 게시물에 대해 썸네일을 사용했었는데, 이 썸네일에 대한 크기를 적정 크기로 변경하는 작업을 추가하였다.
[홈페이지_썸네일]
화면에 렌더링 되는 썸네일의 크기는 작은데, 사용자가 아주 큰 크기의 사진을 썸네일로 지정하면 큰 크기의 사진을 작게 바꿔야 한다.
이 때문에 썸네일이 표기되는 화면을 렌더링 할 때 속도면에서 손해를 보게 된다. 특히 위 사진에서 보이는 것처럼 썸네일이 여러 개가 표기되기 때문에 속도적인 면에서 비 효율적으로 처리가 되고 있었다.
때문에 백엔드 서버에서 썸네일로 적용할 사진의 크기를 미리 줄여서 따로 관리하는 형식으로 이 문제를 해결하였다.
두 번째로 반복조회되는 게시물에 대해 캐싱을 적용했다.
게시물과 내 정보 같은 거의 변경이 없는 자원들에 대해 Redis를 사용해서 캐싱을 적용하였다.
조회수에는 쓰기 지연을 적용하였다.
조회수는 변경이 아주 많이 되는 값이기 때문에 이를 1차적으로 Redis에 저장해놓고 특정 시간이나 조건에 따라 RDB에 조회수를 반영하였다.
쓰기 지연 같은 경우 실무에서 고려할만한 사항이라고 얘기를 얼핏 들어서 한번 적용해보고 싶었는데 이번에 또 기회가 됐고 직접 구현할 수 있어서 너무 좋은 경험이 되었다.
API 구현은 조기에 끝났지만 이렇게 성능 고도화를 할 수 있어서 너무 좋은 경험이 되었다.
4. 테스트 코드
이번 프로젝트는 예외상황이 없는 견고한 API를 작성하는 것이 목표였다.
때문에 각 API 마다 테스트 케이스를 작성하였다.
다만 각 계층마다 테스트를 하기에는 시간적으로 무리가 있을 거 같아서 API 단위로 테스트 코드를 작성하였다.
테스트 코드에 대해서는 다른 것보다 멘토님이 얘기해준 말이 인상에 남았다.
"왜 테스트 코드를 작성하는가"라는 멘토님의 질문에 나는 "예외상황을 파악하기 위해서"라고 답했다.
멘토님은 그 이유도 있지만 다른 사람이 코드를 변경했을 때 변경사항을 단번에 파악하기 위함이라는 말을 해주셨다.
또한 이런 이유로 유지보수적인 측면에서 테스트 코드를 작성한다는 말도 해주셨다.
이게 왜 인상에 남았다면 프로젝트하면서 진짜 이를 경험했기 때문이다.
이번 프로젝트에는 모든 API에 테스트 코드를 작성하였는다.
때문에 다른 팀원분이 코드를 변경하거나 내가 코드를 변경했을 때, 발생하는 변경점과 사이드 이펙트들을 테스트코드에서 모두 잡을 수 있었다.
그래서 개발을 진행하면서 변경을 적용했을 때 모두 크게 예외 없이 처리했었다.
앞으로 테스트 코드를 작성할 때 이런 부분들을 생각하면서 케이스를 작성하면 더 좋을 거 같다고 생각했다.
5. 결론
내가 점수를 매기는 것도 뭐 하지만, 이번 프로젝트는 협업에 있어서 거의 만점이라고 나는 생각한다.
우리가 협업을 왜 하겠나? 결국 혼자 할 수 없는 양을 처리하기 위함이다.
그런데 마냥 1 + 1이 2가 되는 게 아니라 1.5가 될 수도 있고 0.5가 될 수 도 있다 진짜
1 + 1이 2를 넘기면 아주 잘한 거라는 말이다.
그런데 이번 프로젝트에서는 3 정도는 나왔다고 스스로 생각하니 아주 잘했다고 볼 수밖에 없다.
그래서 이번 프로젝트에서는 아쉬운 점이나 개선해야 할 점들이 아예 없는 건 또 아니지만 어떻게 하면 좋은 협업을 이뤄나갈 수 있는지에 대한 검증을 했다고 생각한다.
다음 프로젝트에서도 이번에 성공한 경험을 살려서 좋았던 부분은 더 철저하게 준비하고 적용한다면 문제없이 프로젝트를 진행할 수 있을 거 같은 자신감을 얻었다.
결과물에 대해서도 만족스러웠던 프로젝트였다.
물론 더 넣고 싶었던 기능이 있었지만, 우리 팀이 처음에 목표했던 것은 예외상황 없는 서비스를 론칭하는 것이었다.
론칭되는 서비스에서 예외상황이 발생한다면, 그것이 아무리 사소하더라도 사용자 입장에서는 서비스에 대한 신뢰도는 떨어지고 정말 허접해 보일 것이다.
이번 프로젝트에서는 이를 중요시해 팀원들과 정말 많은 테스트를 진행하였다. 내가 약간 고집했던 부분이기도 하지만 결과적으로 론칭된 서비스에서 기능적으로 발생할 수 있는 예외는 다 처리했다고 자부한다.
이번 프로젝트는 성공에 대한 검증이라고 결론 지을 수 있을 거 같다.
앞으로 내가 정한 방향에 스스로 확신을 가지고 개발을 진행하면 될 거 같다!
서비스 배포 주소 : http://seb40-mainproject.s3-website.ap-northeast-2.amazonaws.com/
'프로젝트 > Tripagram' 카테고리의 다른 글
| 쓰기지연 전략 (0) | 2023.02.13 |
|---|---|
| Reids를 사용한 Cache 전략 (0) | 2023.02.06 |
| [설정] 초기 개발환경 구성 (0) | 2023.01.20 |
댓글