StackOverFlow(Clone) 회고
10월 말에 팀과 같이 StackOverFlow를 클론 코딩하는 프로젝트를 진행하였다.
여기서는 이 프로젝트에 대해 내가 느꼈던 것과 경험했던 것들을 정리하고 부족했던 점이나 개선해야 할 점을 기록하려고 한다.
이 프로젝트는 10월 20일부터 11월 14일까지 약 2주간 진행되었다.
1. 협업의 이상과 현실
나는 지금 까지 내가 배운 기술들을 적용해서 웹사이트를 만들어보고 싶은 마음에, 간간히 사이드 프로젝트를 혼자서 진행했었다.
혼자 서비스를 구상하고, API를 만들고 어떨때는 타임리프 같은 것을 사용해서 직접 화면을 만져보기도 했었다.
하지만 타인과 팀을 짜서 한 프로젝트를 위해 같이 코드를 짜고, 협업 프로그램(git)등을 사용해서 "협업"이라는 것을 해본 적은 단 한 번도 없었다.
IT분야에서 협업은 당연히 필수 요소이다.
방대한 서비스를 개인 혼자서 구축하는것은 현실적으로 매우 어렵기 때문이다.
하다못해 요즘은 프런트, 백엔드로 분야를 나누어놔서 웹서비스를 개발하기 위해서는 필연적으로 다른 사람과 협업을 이루어야 한다.
나는 개인적으로 사이드 프로젝트를 끄적이면서 시작할 때 포부는 컸지만 끝을 흐지부지하게 끝낸 적이 많다.
혼자 개발하고 마감일도 딱히 없기 때문에 혼자했던 사이드 프로젝트는 장기화되면 결국, 끝에 목표를 잃고 잠정 종료했었던 적이 많았던 거 같다.
[개인 사이드 프로젝트]
서비스를 구상하고 시작한 사이드 프로젝트지만 누가 평가하는것도 아니기 때문에 목표의식이 옅어졌다.
마지막에는 내가 사용해보고 싶었던 기술들을 썼다는데 의의를 두고 스스로 합리화하며 프로젝트를 잠정 종료했었다.
이런 경험들 때문에 나는 제대로된 협업을 경험해보고 싶었고 다 함께 힘을 합쳐 하나의 서비스를 만들어 보고 싶었다.
어차피 겪어야 할것이고 준비해야 될 것이니까.
하지만 처음 겪은 협업은 그리 녹록지 않았다.
1.1 팀은 개인의 집합체이다.
팀을 구성하고 협업을 시작하고 나서 나는 벽을 만났다. 존시나 두꺼운 벽을 말이다.
내가 만난 문제는 협업할 때 흔히들 걱정하는 의견의 차이, 일정 조율에서 발생하는 문제 같은 게 아니었다.
진짜 문제는 프로젝트의 코딩 스타일이 맞혀지지 않았다는 것이다.
[다른 메서드 명, 반환 타입]
위는 우리 프로젝트의 초창기 코드이다.
각각 Answer와 Question을 저장하는 역할을 하지만 메서드 명으로 Answer는 create, Question은 add를 사용한다.
더 문제인 건 도메인만 다를 뿐, 같은 행위를 하는 메서드인데 Answer는 저장된 엔티티를 반환하는 반면 Question은 아무것도 반환하지 않는다.
우리가 여러 사람과 코드를 작성할 때는 어느 정도의 규칙을 정하곤 한다.
규칙(Convention)을 만들지 않으면 다 각자의 스타일, 생각대로 코드를 작성할 것이고 이러면 유지보수에 어려움이 생기기 때문이다.
이 프로젝트에서도 백엔드에서 개발할 때 상용할 Convention을 정해야 했다.
앞서 언급됐듯이, 이 프로젝트는 2주간의 짧은 시간 동안 진행되었다.
때문에 아주 기본적이고 당연한 규칙들, 당장 정하지 않으면 애매할 거 같은 규칙들만 정하고 나머지는 개발을 하면서 맞춰 나가기로 했다.
Git에서는 자신의 작업을 PR을 사용해서 기여할 수 있다. 이 PR에서 이루어진 작업은 타인에 의해 평가(코드 리뷰)된다.
우리는 개발 중 코드 리뷰를 하며 다른 사람이 작업한 것을 리뷰하며, 서로 맞춰야 될 부분은 코드 스타일을 맞추고, 변경이 필요할 거 같은 부분은 의견을 제시하자고 하였다.
즉, 개발 시간이 부족하니 Convention을 따로 정하지 않고, 개발을 하면서 유기적으로 코드 스타일을 맞추자고 하였다.
그러나 이 생각은 협업을 겪어보지 못한 사람의 낙관적인 망상일 뿐이었다.
그리고 최악의 판단이었다.
결론부터 말하자면
이후에 이것이 지켜져서, 유기적으로 코드 스타일이 맞춰지는 일 따위는 없었다.
앞서 언급된 메서드 형식이 맞지 않는 것도 치명적이라고 생각했는데, 클래스 형식, 테스트 코드, API 문서, 심지어 URL과 공용문서 형식 조차도 다 제각각이었다. 아무것도 맞지 않았다.
누군가 먼저 코드를 작성해도 PR은 승인하지만 그 코드를 자신의 도메인에서 작성할 때는 반영하지 않았다.
어찌 보면 당연한 일이다.
팀은 한 몸이 아니다. 결국 개인의 집합체이다.
근데 어떻게 생각을 공유하는 것 마냥 맞춰야 될 거 같은 부분을 서로 판단하고 맞추겠는가?
이 일의 원인은 초반에 제대로 된 규칙을 정하지 않고 애매하게 뒤로 미뤄버린 나의 무책임이었다.
솔직히 초반에 할 건 많은데 세세하게 개발 전반에 걸친 규칙을 작성하는 게 여러모로 귀찮았던 마음이 있었다.
이 잠깐의 귀찮음이 결국 프로젝트가 끝날 때까지 날 괴롭혔다.
[치타]
실전은 가혹했다.
결국 프로젝트 개발이 시작되고 1/3쯤 지났을 때, 뭔가 잘못됐음을 느끼고 부랴부랴 팀원들과 컨벤션을 작성했다.
[급조한 컨벤션]
그러나 앞서 언급했듯이 이 문제는 프로젝트가 끝날 때까지 나를 괴롭힌다.
[서비스 메서드 차이]
우리 프로젝트는 처음부터 계속 서비스 계층에 DTO가 넘어오지 않도록 하고 있었다.
서비스 계층이 화면에 너무 결합되지 않도록 말이다. 다들 이것만은 맞추고 있어서 나는 이런 형식으로 계속 개발이 될 줄 알았다.
근데 이건 나 혼자만의 생각이었다.
프로젝트 말기에 위 그림처럼, 한 팀원분이 서비스 계층에 메서드를 전부 DTO를 받는 형식으로 바꾸셨다.
이 팀원분이 맡은 Account 부분만 형식이 바뀐 것이다.
계층에 대한 정책은 여러모로 맞춰야 된다고 생각했기 때문에 다시 원래 했던 방식대로 바꿔달라고 말하고 싶었지만, 나는 이것에 대해 아무 말도 할 수 없었다.
"원래 했던 방식"이라는 것은 그냥 나 혼자의 생각이였고 우연히 형식이 맞춰진거였다. 나혼자의 궁예질로 서비스 전체를 변경한 작업을 다시 돌려달라고 하기도 뭐했다.
무엇보다 우리가 작성한 컨벤션에서는 "서비스에서 DTO가 넘어오지 않도록 한다"는 규칙은 없었다.
규칙으로 정한 것은 지켜야 한다.
그러나 반대로, 규칙이 아닌 것은 개인의 판단하에 달라져도 된다는 뜻이기도 하다.
유지보수적인 측면에서도 한 곳만 형식이 다른 것은 문제가 있어 보여 바꿔달라고 하고 싶었지만, 위와 같은 이유로 선뜻 바꿔달라는 말을 할 수 없었다.
나는 죽음의 이지선다에 걸려버린 것이다.
[죽음의 이지선다]
나는.. 고자가 돼버렸다.
정말 프로젝트 끝무렵에 바꿔버리셔서 다시 돌려달라고 말해도 큰 의미가 없을 거 같았다.
나는 그냥 프로젝트가 끝나는 걸 기다렸다.
이 경험은 나에게 협업에 대해 많은 생각을 하게 해 주었다.
팀은 한 몸이 아니지만 한 몸처럼 행동해야 한다.
이를 위해서는 규칙이 필요했다. 존나쎄고 강한 규칙, 개발 전반에 걸쳐 가이드가 될 수 있는, 모두를 묶어줄 수 있는 그런 규칙 말이다.
2. 팀장으로서 어려웠었던 점
짧지만 나는 우리 프로젝트의 팀장이었다.
전체 팀장으로서, 백엔드 팀의 팀장으로써 몇가지 어려웠던 점이 있었다.
2.1 독재자와 무능의 사이
전반적으로 어려웠던 것은 팀장으로써 너무 독선적이지 않게, 반면 너무 결정력이 없게 행동하지 않는 것이었다.
이 상반된 두 가지 행동의 줄타기가 내게는 어려웠다.
지금 생각해보면, 팀원들의 의견은 존중하되, 팀장으로서 결정해야 할 부분을 판단하고 방향성을 지정해주는 게 팀장으로서의 역량이라고 생각한다.
2.2 글보다는 말로 소통해야 할 때가 있다
주제가 무엇이든.. 팀원이 내 생각대로, 또는 요청대로 행동하지 않을 수 있다.
나는 팀원에게 A를 빼달라고 부탁했는데 계속해서 A를 넣는 경우가 있다.
처음에는 나는 이런 상황에서 단순히 A를 빼달라고 여러 번 요청했었다. 하지만 그럼에도 불구하고 팀원이 A를 넣는다면?
이런 상황에 대처하는 것이 나는 쉽지 않았다.
당시에 나는 그냥 답답해했었다. 게다가 같은 요구를 여러번 부탁하는 것은 꽤 부담이었다.
아무리 옳은 소리라도 여러 번 들으면 사람에 따라 기분이 상할 수도 있기 때문이다.
지금 생각해보면 이 문제의 해결법이 아예 없었던 것은 아니었던 거 같다.
나는 요청사항을 주로 글로 공지하거나 팀 회의시간에 전달하였다.
그런데 아무래도 이런 방식으로는 내 요청에 대해 팀원의 즉각적인 피드백이 어려울 수 있다.
즉, 팀원이 내 요청을 제대로 이해하지 못하거나 못 받아들였기 때문에 이를 수행하지 않았을 수 있다.
실제로 프로젝트 도중 PR에 이전 커밋이 계속해서 중첩되고 있어서, 브랜치를 새로 파서 작업을 하던지 이 문제를 해결하고 PR을 해줬으면 좋게 다고 요청했던 적이 있었다.
[PR1_Commit]
[PR2_Commit]
하지만 다음 PR에도 또 이와 같은 문제가 발생하였고, 이와 같은 이슈는 몇 번 더 발생했었다.
나는 해당 팀원분께 다음에 작업할 때 나를 불러달라고 했다.
같이 작업하고 원인을 찾지 않으면 계속해서 같은 문제가 방치될 거 같았기 때문이다.
결과적으로 local의 main 브랜치에 옛날에 작업한 브랜치가 병합되어서 이런 문제가 발생했었던 거였고 이를 해결하였다.
이후로는 이와 같은 문제는 발생하지 않았다.
이 팀원분은 나름대로 이 문제를 해결하려고 노력했을 수 있다. 하지만 방법을 찾지 못했을 수도 있다.
이럴 때 내가 좀 더 빨리 팀원분의 상황에 대해 파악하고 적극적으로 소통했다면, 좀 더 조기에 원인을 파악하고 문제를 해결했을 수 도 있었을 것이다.
나는 내 기준으로 팀원에게 요청했겠지만 팀원은 내가 아니다.
분명 생각하는바, 어려워하는 바가 다를 것이다.
이번 프로젝트는, 이 간격을 메우기 위해 글보다는 개인적인 말로 소통해야 될 때가 있다고 생각하게 되는 계기가 되었다.
3. 아쉬운 점 & 개선해야 할 점 정리
3.1 아쉬운점
개발적으로 가장 아쉬운 점은 테스트 코드를 면밀히 작성하지 못했다는 것이다.
손으로 일일이 테스트를 하는 것은 아무래도 항상 불안함이 남는다. 시간적으로 매우 비효율적이라고 느껴지기도 하고 말이다.
다음 프로젝트에서는 적어도 API 단위만으로라도 다양한 테스트 케이스를 작성해서 서비스의 완성도를 높이고 싶다.
3.2 개선해야 할 점
- 코드 스타일 & 아키텍처 전반에 걸쳐 규칙 정하고 개발하기
- 적극적으로 소통하기. 최대한 애매한 부분 없애고 명확하게 의사 전달하기
- 넓은 시야로 프로젝트 관리하기. 코드만 작성한다고 프로젝트가 끝나는 것이 아니다. 테스트, 배포, 문서 작성 등 완수해야 할 작업들을 고려해서 개발 일정을 조정하자.
2주간의 짧은 프로젝트였지만 내가 얻어간 것은 아주 많다.
협업이 쉽지 않고 왜 기업에서 협업을 중요한 덕목으로 보는지 잘 이해할 수 있었다.
이 프로젝트에서 내가 했던 실패와 경험을 기반으로 다음 프로젝트에서는 더 성장한 모습을 보여주겠다.
댓글