DAMP 프로젝트를 마치며

다른 글을 작성할 때와 마음가짐부터가 다른 것 같습니다.

이번 프로젝트를 관통하면서 정말 힘들게 얻은 결실이기에 모두와 나누고 싶다는 생각에 조금 더 진중하게 글을 작성하게 되는 것 같습니다.

저는 DMAP 프로젝트를 팀장과 팀원인 저, 2명이서 frontend를 구성해서 작업했습니다.

프로젝트를 진행하면서 처음에는 제 자존심이 먼저였습니다. 제가 옳지 않은 방향으로 갈 때, 그것을 인정하려 하지 않았습니다.

코드리뷰를 진행하면서 팀장이 방향을 바로잡아 주려 했지만, 그때는 이해하지 않고 내 코드는 내가 더 잘 이해한다고 생각했습니다.

결국, 제 근시안적인 시각 때문에 프로젝트 진행 속도는 예상보다 더뎌졌고, 협업 과정에서 여러 시행착오를 겪게 되었습니다.

따라서 여러 시행착오와 함께 이를 해결하는 과정과 깨달음에 대해서 말해보고자 합니다.

1. 디자인 패턴의 충돌

저희는 FSD(Feature-Sliced Design) 구조를 채택하기로 결정했습니다.

하지만 저와 팀장은 FSD 패턴을 적용하는 방식에서 차이를 보였습니다.

제가 적용한 방식은 컴포넌트를 폴더 단위로 분리하고, index.js 파일을 오직 외부와의 단절을 위한 용도로만 사용하는 것이었습니다.

import Component from "./Component";
export default Component;

반면, 팀장은 컴포넌트를 폴더 단위로 나누되, index.js만을 활용하는 방식을 선호하였습니다.

또한, 저는 당시 FSD에 대한 충분한 이해 없이 무조건적인 분리를 시도했으며, 팀장으로부터 아토믹 구조에 가까워졌다는 지적을 받았습니다. 하지만 저는 코드 중복을 허용할 수 없다는 논리를 고수했고, 이로 인해 팀장의 의견과 충돌이 발생했습니다.

그 결과, 모든 재사용 가능할 것 같은 컴포넌트를 일단 Widget이나 Shared에 넣는 것이 올바른 방식이라고 생각했습니다.

그러나 이러한 접근 방식은 결국 코드 복잡성을 증가시키는 결과를 초래했습니다.

이러한 차이로 인해 협업 초반에는 디자인 패턴을 둘러싼 마찰이 많았습니다.

특히 Modal을 어떻게 관리할 것인가에 대한 논의가 많았으며, 전역 상태로 Modal을 관리하는 방식도 고려했지만 최종적으로 채택되지는 않았습니다.

이 과정을 통해 협업에서는 디자인 패턴을 통일하는 것이 필수적이라는 점을 배우게 되었습니다.

같은 디자인 패턴을 사용하더라도 사람에 따라 조금씩 달라질 수 있음을 인지하고 팀원의 코드를 읽는 습관을 길러 획일화해야 함을 느꼈습니다.

팀장은 어느 정도 코드 중복을 허용하더라도 디자인 패턴을 깨서는 안 되며, 지나치게 세분화된 분리는 피해야 한다고 말했는데, 돌이켜보면 너무나도 맞는 말이었습니다.

제로초 선생님의 영상에서도 봤는데, 같은 코드가 두 번 반복될 때는 그대로 두고, 세 번째부터 분리를 고민하는 것이 좋다고 하셨습니다.

코드 중복을 적절히 허용하는 것도 하나의 기술이며, 이를 상황에 맞게 활용하는 것이 필요하다는 점을 다시 한번 깨닫게 되었습니다.

2. 코드 컨벤션의 차이

코드 컨벤션에서도 팀장과 저의 방식은 달랐습니다.

저는 커스텀 훅의 반환값을 객체로 통일하는 방식을 선호하였고, 팀장은 배열을 사용하여 반환하는 방식을 적용하고 있었습니다.

이 차이는 후에 API 커스텀 훅을 만들면서 문제가 되었습니다.

// 팀장의 방식
const useGetMatchParticipants = (matchIdx: number) => {
  return [matchParticipants, setMatchParticipants, loading];
};

// 제가 사용한 방식
const useGetMatchParticipants = (matchIdx: number) => {
  return { matchParticipants, setMatchParticipants, loading };
};

처음에는 큰 문제가 되지 않는다고 생각했지만, 점차 프로젝트가 진행되면서 API 호출 방식이 통일되지 않아 유지보수가 어려워졌습니다.

결국, 팀원들과 논의 후 코드 컨벤션을 맞추기로 결정하였고, 이 경험을 통해 자신의 코드만 집중할 것이 아니라, 팀원의 코드도 읽고 흐름을 이해하는 것이 중요하다는 점을 배우게 되었습니다.

📌 리액트 클린 코드 강의를 통해 배운 점

강의에서 강사는 **“리턴 값이 하나일 경우 변수로, 두 개 이상일 경우 배열로, 네 개 이상일 경우 객체로 관리하는 것이 좋다”**라고 설명했습니다.

즉, 아래와 같은 상황을 방지하기 위함입니다.

const [_, _, _, setValue] = useGet();

이러한 조언을 바탕으로 저 역시 코드 컨벤션을 수정하게 되었습니다.

3. 무한 스크롤 구현 방식의 차이

무한 스크롤을 구현하는 방식에서도 팀장과 저는 다른 접근 방식을 사용하였습니다.

저는 마지막 요소에 inView를 적용하고, 스크롤이 바닥에 도달하면 page를 증가시키는 방식을 사용하였습니다.
반면, 팀장은 마지막 요소가 inView에 도달하면 page를 증가시키되, hasMoreContent라는 상태값을 추가로 관리하는 방식을 적용하였습니다.

처음에는 비슷한 결과를 내는 것처럼 보였지만, 팀장의 방식이 불필요한 API 호출을 방지하고 엣지 케이스(빈 페이지 응답 등)를 더 명확하게 처리할 수 있다는 것을 나중에 깨달았습니다.

같은 기능을 구현하는 코드였지만, 서로 다른 방식이 적용되면서 유지보수의 어려움이 발생할 가능성이 커졌습니다.

결국 협업을 위해서는 코드 스타일을 맞추는 것이 필수적이라는 점을 다시 한번 깨닫게 되었습니다.

4. 팀의 속도를 위한 선택: Disagree and Commit

아무리 제 방식이 더 낫다고 생각하더라도, 저는 팀원이었습니다.

그리고 팀장은 저보다 경험이 많고 뛰어난 실력을 갖춘 사람이었습니다.

처음에는 저도 제 의견을 고수하고 싶었습니다.

“내 코드가 더 효율적인데, 왜 굳이 바꿔야 하지?”*라는 생각이 들었기 때문입니다.

하지만 팀장이 해준 한 마디가 저에게 큰 울림을 주었습니다.

“내가 팀원이었다면, 팀장인 너의 코드 스타일을 따랔을 것이다.”

이 말을 듣고 깨달은 것은 단순히 팀장이 상급자라서 따른 것이 아니었습니다.

설령 내 코드가 기술적으로 더 우수하더라도, 팀 내에 두 가지 스타일이 공존하는 순간 유지보수 비용은 기하급수적으로 늘어난다는 것을 이해하게 되었습니다.

코드베이스가 파편화되면:

새로운 팀원이 온보딩할 때 혼란스러워집니다
버그를 찾을 때 두 가지 패턴을 모두 이해해야 합니다
코드 리뷰 시간이 배로 늘어납니다

팀장의 스타일로 통일하는 것이 **우리 팀의 개발 속도(Velocity)**를 높이는 가장 빠른 길임을 인정한 것입니다.

이를 통해 **‘주관은 갖되, 팀의 결정을 따르는 것(Disagree and Commit)‘**의 중요성을 배웠습니다.

이 원칙은 단순한 코드 스타일의 문제가 아니라, 협업 전반에 적용될 수 있는 원칙이라는 점에서 큰 의미가 있었습니다.

이후 저는 조금씩 생각을 바꾸게 되었고, 지금 돌이켜보면 팀장의 조언이 없었다면, 저는 여전히 혼자만의 방식에 갇혀 있었을지도 모릅니다.

5. 코드 리뷰, 그리고 성장

코드 리뷰를 받는 과정은 결코 쉽지 않았습니다.

제가 충분한 근거를 가지고 작성한 코드가 팀원들에게 평가받는 과정이었기 때문입니다.

하지만 그 과정을 견디면서, 그리고 그 피드백을 받아들이면서 점점 성장할 수 있었습니다.

그렇다고 팀원은 사람이기에 실수를 할 수 있습니다. 따라서 실수를 했을 때는 올바른 근거와 함께 주장하여 바로잡는 것 또한 팀원의 책무 중 하나라고 생각합니다.

“세 살짜리 아이에게도 배울 점이 있다”*라는 말도 있는데, 나보다 뛰어난 사람의 조언을 받지 않는 것은 얼마나 손해인지 느끼게 되었습니다.

고집을 부리기보다는 주관을 가지되, 뛰어난 사람들의 조언을 받아들이는 스펀지가 되는 것이 성장의 길이라는 것을 깨닫게 되었습니다.

6. 마치며: 함께 성장하는 개발자가 되기 위해

자신이 항상 정답이라고 생각하기보다는, 잘하는 사람의 의견을 존중하며 협업하는 것이 중요하다는 생각이 들었습니다.

그리고 무엇보다, 같은 팀원이지만 내가 배우고 있는 입장이라면, 커피 한 잔이라도 더 사 가서 팀원과 함께 대화를 나누는 것이 어떨까 싶습니다.

그렇게 소통하다 보면, 프로젝트를 거듭할수록 실력이 쌓이고, 자신도 점점 성장해 나갈 수 있을 것이라 생각합니다.

이번 프로젝트를 통해 저의 협업에 대한 태도는 확실히 달라졌습니다.

누구에게든 코드를 리뷰받고, 피드백을 받아들이면서 성장해 나간다면, 결국에는 모두의 장점을 흡수하는 스펀지 같은 개발자가 될 수 있을 것입니다.

이 프로젝트에서 기술적인 성취도 물론 있었지만, 무엇보다도 내적인 성장이 가장 크지 않았나 싶습니다.

앞으로도 이러한 마인드를 바탕으로 더 많은 프로젝트를 경험하며, 더욱 성장해 나가고 싶습니다.

개발의 진정한 매력은 모든 사람에게 배우며, 소통하는 능력 그리고 하나라도 습득해 나가는 과정에 있지 않을까 생각합니다. 🚀