[개발자의 태도] 나를 위한 개발인가, 우리를 위한 개발인가?

개요

---

 프론트엔드 개발자라면 누구나 한 번쯤 이런 순간이 온다. 디자인 시스템이 없어서 매번 버튼 스타일을 복사-붙여넣기 하는 게 답답하거나, 레거시 코드가 섞인 컴포넌트 파일이 500줄을 넘어가는 걸 볼 때 참을 수 없는 충동을 느낀다.

 

 

"이거 내가 싹 정리해서 공통 컴포넌트로 만들면 대박이겠는데?"

"지금 쓰고 있는 라이브러리 너무 구려. 요즘 뜨는 걸로 바꾸면 개발 속도 빨라질 텐데."

 

 

 시작은 언제나 순수한 열정이다. 불편함을 해소하고, 코드를 우아하게 만들고 싶다는 선의다. 하지만 잠시 키보드에서 손을 떼고 냉정하게 생각해 보자. 그거, 정말 지금 우리 팀에 필요한 거 맞나? 혹시 나만의 기술적 만족감을 채우기 위한 욕심은 아닐까?

 

오늘은 현직 개발자들과의 대화 도중 나온 주제를 바탕으로, 주니어 프론트엔드 개발자가 흔히 빠지기 쉬운 '만들면 좋아하겠지'라는 착각과 '투영의 오류'에 대해 이야기해 본다.

 

 

"내가 만든 만능 컴포넌트, 남들도 좋아할까?"

---

 우리는 종종 머릿속에서 '이상적인 컴포넌트 구조'를 꿈꾼다.

 

 

"버튼 하나로 모든 케이스를 다 대응할 수 있게 만들어야지.

사이즈, 컬러, 아이콘 유무, 로딩 상태까지 props만 넘기면 다 되게!"

 

 

 좋은 의도다. 중복 코드를 줄이는 건 개발자의 미덕이니까. 그래서 주말을 반납하고 온갖 props를 다 받는 `SuperAwesomeButton`을 만들어서 배포했다. 하지만 며칠 뒤, 동료 개발자의 코드를 보니 내 컴포넌트를 안 쓰고 그냥 `<button>` 태그에 스타일을 입혀서 쓰고 있다. ▼

코드의 모든 <button>에 달리기 시작한 그의 리뷰

 

 

왜일까?

 

 

 이유는 간단하다. 내가 만든 '만능'이 그들에게는 복잡함이었기 때문이다. 그들은 당장 버튼 하나를 렌더링하고 싶을 뿐인데, 내가 만든 컴포넌트를 쓰려면 필수 props 5개를 채워야 하고, 타입 에러를 잡느라 문서를 뒤적거려야 한다.

 

 "이거 쓰면 편한데 왜 안 써요?" 라고 묻기 전에 생각해보자. 내가 만든 추상화가 그들의 업무 흐름을 방해하거나, 굳이 배우고 싶지 않은 새로운 학습 비용(Learning Curve)을 강요하고 있지는 않은가?

 

 그때부터 내가 만든 결과물은 '혁신적인 도구'가 아니라, '쓰기 귀찮은데 팀 컨벤션이라서 억지로 써야 하는 족쇄'가 되어버린다. 억지로 먹여주는 밥이 아무리 영양가 있어도 맛있게 느껴지지 않는 것처럼 말이다.

 

 

가장 위험한 함정: 내가 편하면 남들도 편할 거야 (투영의 오류)

---

 이 글에서 가장 강조하고 싶은 부분이다. 개발자, 특히 기술 트렌드에 민감한 주니어들은 흔히 '나의 니즈(Needs)'를 '팀의 니즈'로 투영하는 실수를 범한다. (이 대화부분에서 너무 찔렸다.)

 

 예를 들어보자. A는 최근 함수형 프로그래밍에 꽂혀서 Ramda.js나 fp-ts 같은 라이브러리를 공부하고 있다. 코드가 간결해지고 안정성이 높아지는 게 너무 좋아서, 회사 프로젝트의 유틸 함수들을 싹 다 이런 스타일로 리팩토링해서 PR을 올렸다.

 

 A는 '팀원들이 내 우아한 코드를 보고 감탄하겠지?'라고 기대했지만, 반응은 싸늘하다.

 

 

"이 코드... 해석하려면 라이브러리 문서를 새로 공부해야 하네요?"

"그냥 map, filter 쓰면 안 될까요? 디버깅하기 너무 힘들어요."

 

 

 "나는 보편적인 기준이 아니다." 이 사실을 뼈저리게 인정해야 한다. 나는 지금 기술 뽕(?)에 취해 있어서 새로운 문법이 즐겁지만, 마감에 쫓기는 동료에게 낯선 문법은 그저 장애물일 뿐이다.

 

 내가 좋다고 해서 남들도 좋은 게 아니다. 팀의 현재 기술 수준, 프로젝트의 성격, 마감 일정 등을 고려하지 않고 '이게 기술적으로 더 우월하니까 다들 좋아할 거야' 라고 단정 짓는 건, 일종의 지적 오만이자 공감 능력의 부재다.

 

 

칭찬받고 싶어서 만드는 예쁜 쓰레기

---

 신입 개발자 시절, 혹은 새로운 팀에 합류했을 때 "뭐라도 보여줘야 한다"는 압박감에 시달린다. 그래서 눈에 띄는 성과를 만들기 위해 무리수를 두곤 한다. 가장 흔한 케이스가 바로 '명분 없는 리팩토링'이나 '화려한 UI 인터랙션 구현'이다. (필자도 대화 도중 돌이켜보니 정확히 이 수순을 밟고 있었다.)

 

 기획서에도 없는 화려한 애니메이션을 라이브러리까지 깔아가며 구현해 놓거나, 잘 돌아가는 레거시 코드를 "그냥 코드가 더러워서"라는 이유로 싹 다 뜯어고친다. 그러고는 기대한다. '선배들이 나의 열정과 실력을 칭찬해 주겠지?'

 

 하지만 냉정하게 말해보자. 회사는 학교가 아니다. 학교 과제라면 "와, 이런 애니메이션도 구현했어? 대단하다"라고 칭찬받을 수 있다. 하지만 비즈니스의 세계는 다르다.

 

 

"주말 동안 애니메이션 깎아왔습니다!"

"음... 예쁘긴 한데, 이거 때문에 번들 사이즈 늘어났나요? 모바일에서 렉 걸리진 않나요? 유지보수는 누가 하죠?"

 

 

이 질문에 "어... 성능은 아직 체크 안 해봤지만 예쁘잖아요..." 라고 대답한다면, 그건 그저 회사의 리소스를 낭비한 것이다. 심지어 그 코드를 유지보수해야 하는 미래의 기술 부채까지 생각하면 회사의 빚을 늘린 셈이다.

 

 결국 "칭찬받고 싶어서", "내가 이만큼 한다는 걸 증명하고 싶어서" 만드는 것은 나를 위한 자기만족적 행위일 뿐이다. 회사가 월급을 주며 원하는 건 당신의 코딩 쇼(Show)가 아니라, 사용자의 문제 해결이다.

 

 

핵심은 핀포인팅(Pinpointing)

---

 그렇다면 우리 주니어들은 무엇을 만들어야 할까? 가만히 시키는 것만 해야 할까? 아니다. '정말 아픈 곳'을 찾아야 한다. 대화중에 나온 표현을 빌리자면 '핀포인팅(Pinpointing)' 능력이 필요하다. 만연한 불편함 속에서 진짜 핵심적인 문제를 정확하게 짚어내는 능력이다.

 

 프론트엔드 상황에 대입해 보자.

 

내 옆자리 동료가 개발할 때마다 한숨 쉬는 포인트가 어딘가?

• 빌드 속도가 너무 느려서 5분씩 멍 때리고 있다면? -> 빌드 환경 최적화
• 백엔드 API가 아직 안 나왔는데 개발을 못 해서 손가락 빨고 있다면? -> MSW(Mock Service Worker) 세팅
• QA 팀에서 "이 페이지 특정 브라우저에서만 깨져요"라는 리포트가 계속 온다면? -> 크로스 브라우징 이슈 해결

 

강요는 폭력이다

• 내 눈엔 Redux가 낡아 보이고 Zustand나 Jotai가 좋아 보여도, 팀이 현재 Redux로 잘 굴러가고 있다면 굳이 건들지 마라. 섣부르게 "요즘 누가 리덕스 써요?"라며 도입을 강요하는 건 팀의 생산성을 떨어뜨리는 폭력이 될 수 있다.

 

설득도 개발이다

• 정말 기술 도입이 필요하다면, "제 취향이라서요"가 아니라 "이걸 도입하면 보일러플레이트 코드가 50% 줄어들고, 신규 입사자 온보딩 시간이 단축됩니다"라고 숫자와 논리로 설득해라. 그들이 자발적으로 원하게 만드는 것까지가 개발자의 몫이다.

 

 

가치 있는 30분 vs 낭비된 3시간

---

 그렇다고 모든 시도를 하지 말라는 것은 아니다. 개발자에게 호기심과 실행력은 중요한 덕목이다. 중요한 건 투입 비용 대비 가치(ROI)를 판단하는 것이다.

 

 만약 30분 정도 걸려서 `utils/date.ts` 같은 간단한 날짜 변환 함수를 만들어 팀에 공유한다면? 이건 시도해 볼 가치가 있다. 실패해도 30분 날린 거고, 성공하면 모두가 편해진다.

 

 하지만 3시간, 3일, 혹은 그 이상의 시간이 들어가는 작업이라면 이야기가 다르다. 예를 들어 멀쩡한 웹팩(Webpack)을 비트(Vite)로 마이그레이션 한다거나, 디자인 시스템을 밑바닥부터 구축하는 일 같은 것들 말이다. 그때는 철저한 검증이 선행되어야 한다.

 

"이게 정말 내 3일, 아니 회사의 3일을 투자할 만한 가치가 있는 일인가?"

"이걸 만듦으로써 우리가 얻는 이득이, 들어가는 공수보다 확실히 큰가?"

 

이 질문에 명확하게 "YES"라고 대답할 수 있을 때, 그리고 그 확신이 나만의 뇌피셜이 아닐 때, 비로소 키보드 위에 손을 올려야 한다.

 

 

마치며

---

 우리는 특별한 존재가 되고 싶어 한다. 아무도 해결하지 못한 난제를 나만의 기술력으로 멋지게 해결해 내는 '슈퍼 개발자'가 되고 싶어 한다. 하지만 현실의 개발은 그런 영웅담보다는, 동료의 사소한 불편함을 묵묵히 덜어주는 과정에 가깝다.

 

 주니어 개발자로서 성장하고 싶다면, '코드를 짜는 행위' 자체에 취하면 안된다.

 

 대신 '무엇을, 왜, 누구를 위해 짜야 하는가'를 고민해야한다. 나의 만족이 아닌 팀의 문제를 해결하는 것, 그리고 나의 기술적 취향을 팀에게 강요하지 않는 것. 그것이 진짜 프로가 되어가는 과정이다.