인성·소프트 스킬

원칙은 단순합니다. 사용자에게 보이는 일정과 사용자에게 보이지 않는 시스템 건강성을 분리해서 우선순위를 매기되, 결합할 수 있으면 결합합니다.

구체 사례를 말씀드리면, 멀티 프로덕트 패키지 재편을 진행하던 시기에 Emotion v10 → v11 메이저 업그레이드라는 별도 부채가 있었어요. 둘을 따로 진행하면 사용처에서 import 경로를 두 번 손대야 해서 동료 부담이 컸습니다. 그래서 한 PR에 두 변경을 결합했어요. 단, 결합의 정당화 조건이 있었습니다 — 시각 회귀 테스트라는 안전망이 미리 깔려 있어서, 어디가 깨지면 즉시 잡힐 수 있었어요. 안전망이 없었다면 결합을 포기하고 별도 PR로 분리했을 겁니다.

다른 사례로, "이 부채는 지금 안 잡으면 6개월 뒤엔 못 자른다"는 신호가 있을 땐 일정을 일부 양보해서라도 잡았습니다. core 패키지를 product별로 자른 결정이 그 사례였어요. 반대로 "지금 잡든 1년 뒤 잡든 비용이 같다"는 부채는 일정을 우선했고요.

결국 판단축은 세 가지입니다 — 사용자 임팩트, 안전망 유무, 결합 가능성. 이 세 가지를 동료들과 공유하고 결정 근거로 합의한 뒤 진행하면, 일정과 부채 둘 다 어느 정도 챙길 수 있다고 봅니다.

순서가 정해져 있어요. 첫째, 지금 푸는 문제가 라이브러리 없이는 해결 못 하는 문제인가를 자문합니다. 단순 useState로 충분한 화면에 상태 관리 라이브러리를 넣지 않아요. 둘째, 여러 후보를 같은 기준으로 비교합니다. 도입 비용·러닝 커브·번들 사이즈·메인테이너 건강성·생태계 — 이 다섯 축으로 매트릭스를 만들어서 명시적으로 비교했어요. 셋째, 마이그레이션 비용을 본다. 신규로 도입하는 거라면 부담이 작지만, 기존 코드를 옮기는 거라면 6개월~1년 단위 작업이 될 수 있어요. 넷째, 메인테이너의 건강성. OSS는 메인테이너가 떠나면 끝이라 활동도·릴리스 주기·이슈 응답 시간을 본 뒤 결정합니다.

구체 사례로, Recoil → Jotai 결정 때 Zustand·Redux Toolkit·Valtio까지 네 가지를 매트릭스로 비교했어요. Zustand는 store 단위 사고라서 atom 단위로 잘게 쪼갠 코드를 옮기는 비용이 컸고, Redux Toolkit은 보일러플레이트가 늘어 학습 곡선이 가팔랐습니다. Jotai만이 atom 모델을 1:1 매핑하면서 Recoil의 약점(key 충돌)을 보완하는 선택지였어요. 이 비교가 PR description에 표로 정리돼서 동료들이 의사결정 근거를 함께 검토할 수 있었습니다.

반대로 안 도입한 사례도 많아요. use-context-selector는 Context value 일부만 구독할 수 있는 좋은 라이브러리인데, useMemo + React.memo로 우리 케이스에선 충분해서 의존성을 늘리지 않았습니다. "안 도입한다"는 결정도 도입만큼 의식적으로 합니다.

디자인 시스템 v2를 Compound Component 패턴으로 전환할 때의 사례가 가장 잘 기억나요. 일부 동료들이 v1의 단일 Props 방식이 익숙하고, 새 패턴은 학습 비용이 든다는 이유로 처음에 반대 의견을 줬어요. 단순히 "Compound가 더 좋다"고 우기지 않고 두 가지를 했습니다.

첫째, 데이터로 보여줬어요. v1에서 prop이 10개 넘어가는 컴포넌트들이 어떤 화면 변형 요구에 막혔는지를 실제 PR 리스트로 정리해서 공유했습니다. "이 16개 PR 중 N개가 prop 추가만으로는 해결 안 돼서 컴포넌트를 fork했다"는 식으로요. 둘째, 작은 spike로 직접 써보게 했어요. v2 후보 컴포넌트(Accordion) 한 개를 먼저 만들어서 storybook에서 v1과 v2를 나란히 띄워두고, 동료들이 직접 마크업을 작성해 본 뒤 의견을 받았어요. 직접 써본 동료들의 80% 이상이 "확실히 v2가 자유롭다"는 피드백을 줬고, 그 시점부터는 도입에 대한 합의가 자연스럽게 만들어졌습니다.

회고하자면, 추상적인 주장보다 작은 검증 결과 한 개가 훨씬 강하게 합의를 만든다는 걸 배운 사례였어요. 다음에 비슷한 결정을 할 때도 spike → 직접 써보기 → 합의의 순서로 가려고 합니다.

가장 후회되는 결정은 디자인 시스템 v1을 처음 만들 때 일반화 욕심을 너무 부린 것이에요. "한 컴포넌트가 가능한 모든 변형을 prop으로 받을 수 있게 하자"는 사고로 시작했는데, 6개월쯤 지나니 prop이 10개 넘는 컴포넌트가 생겼고 동료들의 학습 비용이 누적됐습니다. 결국 v2에서 Compound Component 패턴으로 전면 개편하는 비용을 치렀어요.

학습 두 가지가 있었습니다. 첫째, 추상화는 미래의 모든 케이스를 예측하려고 시도하면 실패한다는 것. 추상화는 3번 이상 반복되고 변화 축이 같을 때 가치 있고, 처음부터 만능 컴포넌트를 설계하는 건 오버엔지니어링이라는 걸 체감했어요. 둘째, API 설계는 prop이 아니라 마크업으로 표현되는 게 자유도가 높다. JSX 트리 자체가 사용자에게 자유도를 주는 인터페이스라는 사고가 v1 시점엔 없었습니다.

지금 다시 한다면, MVP는 가장 단순한 prop 형태로 만들고, 변형 요구가 3번 이상 누적되는 시점에 Compound로 진화시키는 점진적 설계로 가겠습니다. v1의 학습 덕에 v2에서는 그 균형을 더 잘 잡을 수 있었습니다.

의견을 데이터·작은 검증으로 표현하는 동료와 가장 잘 맞습니다. "이게 좋다고 느낀다"보다 "이걸 spike로 해봤더니 이런 결과가 나왔다"는 식의 의사소통이요. 추상적인 주장만 오가는 회의는 시간 낭비라고 생각하고, 작은 검증을 만들어 와서 같이 보는 자리가 합의가 가장 빠르다는 걸 여러 번 경험했어요.

협업 스타일은 세 가지로 정리됩니다. 첫째, PR description에 의사결정 근거를 길게 씁니다. "왜 A를 골랐고 B는 안 골랐는지"를 명시해서 미래의 동료(또는 미래의 나)가 맥락을 잃지 않게요. 둘째, 솔직하게 말합니다. 모르는 건 모른다고 하고, 잘못된 결정이었으면 회고를 빠르게 공유합니다. 셋째, 동료의 학습 비용을 항상 의식합니다. 새 패턴을 도입할 때 마이그레이션 가이드부터 같이 만드는 게 습관이에요.

토스는 외부에서 봐도 데이터·솔직함·학습 비용 의식 세 가지를 강하게 공유하는 컬쳐라는 인상을 받았고, 그게 제 스타일과 자연스럽게 겹치는 부분이라 지원에 대한 자신이 있었습니다.

다 못 한다는 사실을 가장 먼저 인정합니다. 그 다음 우선순위 기준을 명시적으로 세웁니다. 제 기준은 사용자 임팩트 → 안전성 → 동료 DX → 본인의 코드 만족도 순이에요. 단기 일정에서는 본인의 코드 만족도를 가장 먼저 양보합니다.

구체 사례로, 디자인 시스템 v1을 출시할 때 "30개 컴포넌트를 다 만들고 싶다"는 욕심이 있었는데, 일정상 20개로 잘랐습니다. 자르면서도 사용처 빈도가 높은 것 위주로 남겼고, 안 만든 10개는 "다음 분기 작업"이라고 명시적으로 백로그에 등록했어요. 동료들에게 "지금은 이 20개만 가능합니다"를 분명히 알린 게 핵심이었습니다.

명시적으로 자르지 않으면, 동료들은 "곧 나오겠지"라고 기대하고 본인은 일정 압박에 시달리는 회색 지대가 생겨요. 그래서 자를 땐 자른다고 알리고, 보존할 땐 보존한다고 알리는 게 일정 관리의 절반이라고 봅니다.