회사에서 필요 없는 사람이 되는 것
"이건 제가 살펴본 후에 답변드리도록 하겠습니다."
자주 사용했던 표현인데요. 정말 제가 살펴봐야 하는 일도 있었습니다. 하지만 어떤 날의 이 말은, 이 일엔 내가 필요하다는 것을 그럴싸한 문장으로 포장한 어필에 그치기도 했습니다.
개발자로 일하면서 저는 꽤 오랫동안 역할이라는 틀 안에서 움직였습니다. 나는 이런 것까지 할 수 있는 사람이고, 이 영역은 내 담당이니 나를 거쳐야 한다고요. 스스로는 그걸 책임감이라고 불렀습니다. 하지만 돌이켜보면 나의 입지를 드러내고 영역에 선을 긋는, 기존의 조직 문화와 다를 게 없는 모습이었습니다.
선을 긋다 보니 일하는 방식도 릴레이가 됐습니다. 기획 합의가 끝나면 디자이너분이 Figma로 디자인하고, 저는 그 결과물을 이어받아 코드로 옮깁니다. 그리고 구현된 화면을 함께 확인하다 아이콘 하나, 이미지 하나, 몇 픽셀의 조정이 필요해지면 그 사소한 수정조차 같은 릴레이를 한 바퀴 더 돌아야 했습니다. 디자이너의 의도가 제품에 닿으려면 반드시 저라는 관문을 지나야 했으니까요. 어떤 일이든 제가 껴야만 진행됐고, 그때는 그게 당연하다고 생각했습니다. 코드는 개발자의 영역이니까요.
이 릴레이가 흔들리기 시작한 건, 조인트에서 일하는 방식 자체가 바뀌면서였습니다.
막연한 두려움
올해 초부터 조인트의 모든 직군이 GitHub에서 일하게 됐습니다. 그 전환 과정은 모든 직군이 GitHub에서 일하게 되기까지에 담겨 있는데요. 이 흐름 속에서, 디자이너가 FE 저장소에 직접 접근해 작업하게 된다는 이야기가 나왔습니다.
솔직히 말하면, 처음 든 감정은 기대가 아니라 두려움이었습니다. 우선 저장소가 playground가 된다는 건 디자이너에게도 개발자에게도 두려운 일일 겁니다. 개발자에게 내가 모르는 코드가 수천 줄씩 쌓이는 것은 꽤 무서운 일이니까요. 힘들게 잡아놓은 코드 구조가 흐트러질 수도 있고, 그게 장애로 이어질 수도 있고요.
그런데 이 두려움을 가만히 들여다보니, "무슨 일이 벌어질지 내가 통제할 수 없다"는 막연한 추측에서 오는 감정이었습니다. 그리고 이 두려움은 기다린다고 사라지지 않습니다. 걱정할 필요가 없는 구조를 만들어야만 사라집니다. 그래서 저는 디자이너와 어떻게 일하는 게 좋을지 계속 대화하면서, 걱정을 대신해 줄 장치들을 하나씩 만들기 시작했습니다.
두려움을 장치로 바꾸는 일
비개발 직군의 메이커들에게 접근 권한을 주는 것만으로는 부족합니다. 안전장치까지 갖춰져야 저장소는 정말로 playground가 됩니다. 그리고 저는 이 환경이 AI로 제품을 만드는 메이커들에게 필수적인 환경이라고 생각하게 됐습니다.
이를 위해서 가장 먼저 한 일은 사람이 반복적으로 확인하고 가이드해야 하는 것들을 자동화하는 것이었습니다. 기본적인 브랜치 보호 규칙 위에, 디자인 작업에서 지양해야 하는 요소들과 다크 모드 도입에 따라 지켜져야 하는 컨벤션들이 CI 단계에서 자동으로 걸리도록 했습니다. 규칙을 지켰는지 확인하는 일은 이제 제 기억력이 아니라 파이프라인으로 해결합니다. 이 장치 덕분에 디자이너는 코드 퀄리티 대신 디자인 의도에만 집중할 수 있게 됐고요.
다음으로는 제가 리뷰에서 하던 판단을 자동화했습니다. 브라우저별로 고려해야 하는 사항, 컴포넌트로 분리해야 하는 케이스, 메모이제이션이 필요한 케이스처럼 개발자의 기초적인 리뷰가 필요한 항목들을 리뷰 에이전트로 만들었습니다. 이제 작업을 마무리하는 단계에서 제가 자리에 없어도 제가 의도한 리뷰가 반영됩니다. 말하자면 제 리뷰 관점 자체를 코드베이스에 심어둔 셈입니다.
실제로 부딪혀 보니 의외의 발견도 있었습니다. AI가 이 가이드를 예상보다 훨씬 잘 따른다는 것이었습니다. 저희가 AI에게 제품의 맥락을 알려주기 위해 해온 준비는 AI는 우리 제품을 모릅니다에서 다룬 적이 있는데, 그 맥락 위에서 AI는 기대보다 안정적으로 움직였습니다. 시작하기 전에 머릿속으로만 걱정하던 문제의 상당수는 애초에 일어나지 않았습니다.
"이 정도는 제가 작업해서 PR 열어 둘게요"
새로운 환경에 적응을 해 갈수록 일하는 방식은 효율적으로 변화했습니다.
디자이너는 이제 FE 저장소에서 직접 다양한 시안을 제품에 녹여 테스트하고, 완성도 높은 디자인을 훨씬 빠르게 전달합니다. "피그마 완성됐어요, 확인해 주세요"라고 전달하던 과거에서, 이제는 PR로 업무를 주고받습니다. 릴레이를 한 바퀴 돌게 만들던 픽셀 단위 조정, 이미지와 아이콘 교체 같은 수정들은 디자이너가 직접 작업한 뒤 리뷰만 받아 바로 제품에 반영됩니다. 저는 Figma 결과물을 코드로 옮기던 비용이 사라진 만큼, 그 시간을 리뷰와 구조 개선에 씁니다.
이 방식의 속도를 가장 잘 보여준 게 최근의 다크 모드 작업입니다. 조인트는 1년 넘게 발전해 온 복잡한 제품의 다크 모드를 2일 만에 완료했습니다.
흐름은 이랬습니다. 개발자가 디자인 시스템의 컬러 체계에 다크 모드라는 차원을 추가하고 컨벤션을 개선해 전달합니다. 디자이너는 그 위에서 전체 컬러셋을 바꾸고, 고정으로 가져갈 컬러와 모드별로 달라질 컬러를 컴포넌트 단위로 조정합니다. 그동안 저는 다크 모드 컨벤션에 맞게 CI와 가이드 문서를 개선하고, 마지막에 결과물을 리뷰합니다. AI 딸깍이 아니라 컴포넌트마다 디자이너의 의도가 반영되고 개발자의 설계와 기술 리뷰가 들어간 작업이었죠. 다만 두 사람이 서로를 기다리지 않고 나란히 움직였을 뿐입니다. 예전의 릴레이였다면, 서로를 기다리는 시간만으로 2일을 넘겼을 겁니다.
내가 필요한 게 맞나?
디자이너의 PR을 리뷰하는데, 가이드에 맞춰 AI가 짜낸 코드에 지적할 게 별로 없는 겁니다.
이거 내가 리뷰하는 게 맞나?
AI가 더 잘해주는데?
나는 필요한 게 맞나?
예전의 저였다면 이 질문 앞에서 다시 선을 그었을 겁니다. 그래도 이건 개발자가 봐야 한다고, 이 일엔 제가 필요하다고요. 하지만 이번에는 질문을 피하는 대신 뒤집어 보기로 했습니다.
이 경험을 지나며 저에게는 새로운 목표가 자리 잡았습니다. 회사에서 제가 필요 없는 사람이 되는 것.
조금은 자극적인 표현으로 보일 수 있다는 걸 압니다. 하지만 내가 없어도 내가 하던 일이 프로세스에 녹아들고, 그게 제품에 도움이 된다면 — 저의 역할은 0에 수렴해 갈 수 있지 않을까요. 브랜치 보호 규칙도, CI에 심어둔 컨벤션도, 리뷰 에이전트도 모두 그 목표를 위한 작업이었습니다. 그리고 신기하게도, 제가 필요 없어지는 만큼 팀은 빨라졌습니다.
그래서 지금은
모두가 저장소에서 일하게 되면서, 제가 신경 써야 할 것도 달라졌습니다. 예전에는 누가 어떤 코드를 쓰는지 제가 알고 있어야 했다면, 지금은 제가 일일이 보지 않아도 되게 만드는 일에 시간을 씁니다.
리뷰에서 반복해 짚던 규칙들은 계속 CI로 옮기고 있습니다. 디자인 시스템과 공용 컴포넌트를 어떻게 관리해야 하는지도 문서로 남기고 있고요. 이렇게 남긴 컨벤션과 문서는 사람만 보는 게 아니라, AI가 우리 제품의 맥락을 읽는 데도 쓰입니다.
이제 누구나 제품을 만질 수 있게 됐으니, 제가 확인하지 않아도 문제가 걸러져야 합니다. 그 기준이 코드베이스 안에 있어야 하는 이유입니다.
저를 거쳐야 하는 일이 줄어든 만큼, 제 판단을 규칙과 문서로 옮기는 데 시간을 씁니다.
이 일엔 내가 필요하다고 어필하던 사람이, 이제는 제가 필요 없는 프로세스를 만드는 데서 재미를 느끼고 있습니다. 필요 없어진다는 게 할 일이 없어진다는 뜻은 아니었습니다. 이 블로그의 내용이 비슷한 고민을 하고 계신 분들께 작은 참고가 되었으면 합니다.