팀 프로젝트가 나에게 남긴 것

팀 프로젝트가 나에게 남긴 것

개발만 잘하면 될까?

당연한 말이겠지만, 개발 실력 즉, 프로그래밍 실력을 높이기 위해 우아한테크코스에서 하루하루 지내고 있다.
지금까지 미션을 했을 때는 커뮤니케이션의 대부분이 개발 이야기였다.
그래서 팀 프로젝트를 시작할 때 개발 공부만 열심히 하고 팀에 기여하는 방법은 개발할 때 조금이라도 도움이 되는 것으로 생각했다.
그러나 내 생각과는 달랐다. 첫 시작부터 개발하지 않고 가장 먼저 한 일은 '팀 문화 만들기' 였다.
팀 프로젝트 시작 시, 포비의 애자일 강의에서 팀 문화를 만드는 것을 강조하셨다. 팀 문화에 따라 달라진다는 것이었다.
그래서 일주일간 팀 문화 만들기에 전전했다. 처음으로 우아한테크코스에서 비 개발 이야기를 자주 나누다 보니, '이렇게 하면 언제 개발을 하는 거지?', '하나라도 빠르게 기능 개발을 해야 더 좋은 서비스가 나오는 거 아닌가?'라는 생각이 종종 들게 되었다.
며칠이 지나고 팀원도 나도 커뮤니케이션에 지쳐가며 내 생각이 문제가 닥치게 된다면 그때 정하자는 생각으로 변해가게 되었다. 그러다 보니 하나둘씩 명확하게 정하게 되는 게 하나둘씩 사라지게 되었다.
그 후 명확하게 정하지 않았던 문제가 닥치게 되었고 이미 그 부분을 생각하지 않고 개발을 하던 우리 팀은 문제가 봉착하게 되면서 도메인을 변경하게 되었고 그게 더 시간을 오래 잡게 되었다.
또한 '내 생각을 코드에 보여주면 되겠지?'라는 생각으로 공유하는 것보다는 개발에 급급하기도 하였다.
이런 것들로 인해 하나둘씩 문제가 수면위로 올라오게 되고 프로젝트 시간은 점점 흘러가기 시작했다.
최근 '함께 자라기'라는 책을 보고 있다. 여기서는 개발 실력 향상도 중요하지만, 신뢰를 얻는 것도 중요하다고 이야기한다.
신뢰 자산이 높은 조직은 커뮤니테이션 효율이나 생산성이 높다고 이야기하면서 신뢰 자산을 얻기 위해 상대방의 이해와 많은 대화가 필요하다고 이야기한다.
이번에 팀 프로젝트를 하면서 신뢰 자산이 쌓는 것이 중요하다는 걸 느끼게 되었다.
그렇다면 내가 신뢰 자산을 쌓기 위해 할 수 있는 일이 무엇일까 하는 생각을 했고, 그것은 힘들어하는 문제를 같이 고민하고 해결법을 같이 찾아가는 일이었다.
슬랙이나, 데일리 때 진행하면서 문제가 발생한 부분들을 공유하면서 발생한 문제를 같이 찾아보고 문제에 대해 같이 짜증도 내보고, 해결법을 같이 고민해서 해결하고 같이 기뻐하는 것이었다.
그러면서 서로 공감을 하고 서로 개발 실력도 향상되는 것을 느끼게 되었다.
결론은 '개발만 잘하면 될까?'라는 질문에서 내가 찾는 답은 '아니다.'이다.

쓰레기 코드는 무조건 안 좋은 것인가?

포비가 자주 이야기하신 말이 있다.
'일단 동작하는 쓰레기 코드를 만드세요.'
나는 개인적으로 이 말이 와닿지 않았다. 쓰레기 코드라는 것이 우테코를 들어오기 전의 내 모습이었다고 생각하기 때문이다.
기능 개발에 급급해 기능만 되는 코드를 작성했었다. 따라서 한번 코드를 작성할 때 결벽증 환자처럼 클린 코드를 고집했다.
그러나 현실은 달랐다. 명명을 짓고, 컨벤션을 지키고, 사소한 메서드 분리까지 개발 데드라인을 맞추기에는 쉽지가 않았다.
그러다 보니 한두 개씩 신경 쓰지 않고 PR을 보내게 되었다.
그러나 팀 문화에 코드리뷰가 있고 다른 팀원들이 내가 신경 쓰지 못한 부분을 피드백을 남겨주고, 이미 병합된 코드를 개발하면서 이상한 부분들을 계속 공유해주면서 변경되어야 하는 부분은 이슈에 등록하게 되었다.
팀 프로젝트를 하면서 팀원들을 믿고 피드백을 적극적으로 받아들이고 처음부터 완벽한 코드는 없다는 것을 느끼게 되었다.
결론은 '쓰레기 코드는 무조건 안 좋은 것인가?'라는 질문에서 내가 찾는 답은 '아니다.'이다.

같이 하는 것이 모두 좋은 것인가?

나는 처음에 프로그래밍 공부를 독학으로 시작해 우아한테크코스에 와서 페어 프로그래밍을 하는 것이 너무 좋았다.
정답이 존재하지 않는 프로그래밍 세계에서 다른 사람들의 생각을 들을 수 있던 것이 너무 좋았다.
따라서 팀 프로젝트에서도 페어 프로그래밍을 도입하면 좋겠다는 생각에 페어 프로그래밍을 적극 지지하기 시작했다.
그러나 페어 프로그래밍의 가장 큰 단점은 시간 소요라고 생각한다. 문제점에 대해 페어와 같이 논의를 하면서 각자의 생각이 다르기 때문에 계속해서 토론하게 된다.
장점이 수없이 많지만, 위와 같은 생산성 저하라는 단점이 있다. 이때 생각했던 것이 페어 프로그래밍을 할 수 있는 부분이 있고 혼자 했을 때 생산성이 올라가는 부분이 있다는 것을 느끼게 되었다.
예를 들면 도메인을 설계하고 그 부분을 프로그래밍 언어로 옮기는 과정이나 프론트엔드에서의 화면 디자인 설계 후 레이아웃 잡는 과정에서는 페어 프로그래밍이 훨씬 더 생산성이 나오게 된다.
그러나 개인적인 생각에서 인프라적인 CI/CD 같은 부분들은 혼자 진행하고 정리해서 공유하는 것이 훨씬 더 생산성이 나오게 된다.
결론은 '같이 하는 것이 모두 좋은 것인가?'라는 질문에서 내가 찾는 답은 '아니다.'이다.

결론

팀 프로젝트를 하면서 내 생각들이 많이 변하게 되었다. 개발자가 되기 위해 개발 실력은 당연하고 그 외적인 소프트 스킬이 너무나도 중요하다는 걸 느끼게 되었다.
개발자로 살아가면서 혼자 개발하는 시간은 많지 않을 것이다.
항상 누군가와 고민하고 이야기하면서 개발을 하게 될 텐데 함께 자라기에 나온 이야기처럼 팀원들과 신뢰를 쌓아가며, 쓰레기 코드에 인식을 깨고, 생산성을 위해 기능 개발을 고민하는 시간을 갖는 것을 깨닫게 되었다.
남은 레벨4의 팀 프로젝트와 협업에서는 좀 더 좋은 소프트 스킬을 구사하고 싶다.