Claude Code를 만든 Boris Cherny가, 엔지니어링·프로덕트·디자인 같은 직군의 경계가 점점 녹아내리면 앞으로의 역할이 어떻게 바뀔지 정리한 트윗을 봤습니다.

그는 자기 팀에서 다섯 가지 유형이 보인다고 했습니다.

  • Prototyper: 새로운 아이디어를 끊임없이 쏟아내는 사람. 대부분은 세상에 나오지 못하고 사라집니다.
  • Builder: 그 아이디어나 프로토타입을 빠르게 프로덕션 수준의 제품·인프라로 만들어내는 사람.
  • Sweeper: UI를 다듬고, 코드와 시스템을 단순하게 깎아내고, 불필요한 걸 걷어내며 성능을 끌어올리는 사람.
  • Grower: 이미 만들어진 제품을 반복해서 개선하며 시장에 더 맞게 키우는 사람.
  • Maintainer: 성숙한 시스템을 안전하고 안정적이고 빠르게, 규모가 커져도 효율적으로 유지하는 사람.

대부분의 사람은 이 중 두세 개 유형에 걸쳐 있다고 합니다. 그리고 이 유형들은 직군과 딱 붙어있지도 않아서, 같은 엔지니어라도 어떤 사람은 Prototyper에, 어떤 사람은 Sweeper에 가깝고 디자이너나 기획자, 데이터 사이언티스트도 마찬가지라는 이야기였거든요.

건강한 팀은 제품의 단계에 따라 이 유형들을 다르게 섞어야 한다고도 했습니다. 이제 막 시작한 제품이라면 Prototyper·Builder·Sweeper가 강해야 하고, 시장을 찾아가는 중이라면 Builder·Sweeper·Grower에 약간의 Maintainer가, 이미 자리를 잡은 제품이라면 Sweeper·Grower·Maintainer에 약간의 Builder가 필요하다는 식으로요. 어쩌면 미래의 역할은 지금처럼 도메인별 직군으로 나뉘기보다 이런 모습에 가까워질지도 모른다는 게 그의 결론이었습니다.

읽다 보니 자연스럽게 “그럼 나는 어느 쪽일까?” 하는 생각이 들었습니다.

지금의 나

당당하게 내세울 강점 두 개를 꼽아보려 했는데, 생각보다 쉽지 않더라고요. 다만 하나는 분명했습니다. Maintainer입니다.

돌이켜보면 저는 새 프로젝트에 투입되기보다, 이미 돌아가고 있는 운영 환경을 꾸준히 도맡아 온 쪽이었습니다. 블로그에 쌓인 글들도 결국 대부분 그 이야기더라고요. velocity 템플릿 수정과 프로모션 실수가 겹쳐 홈메인이 9분간 먹통이 됐던 배포 장애를 뜯어보고 재발 방지 프로세스를 정리한 일, 여러 대의 인스턴스가 각자 들고 있던 로컬 캐시가 서로 어긋나던 문제를 Redis Pub/Sub 무효화 이벤트로 맞춘 일. 하나같이 살아있는 시스템이 죽지 않게 하는 이야기였습니다.

Sweeper는 그 다음입니다. 강하게 드러난다고 말하기는 조금 망설여지지만, 어느 정도는 갖고 있고 계속 지향하는 모습이거든요. 제각각이던 Redis 키 네이밍을 단일 진입점으로 강제해 정리하고, 3,000줄짜리 단일 파일 게임 코드를 모듈 구조로 찢어내고. 심지어 이 블로그 코드도 얼마 전에 중복된 로직을 걷어내 정리했습니다.

Builder는 전통적인 개발자라면 능히 가지고 있어야 할 요소라고 생각합니다. 저도 Pet-Pass와 피카밈처럼 몇몇 사이드 프로젝트를 기획부터 배포까지 혼자 끌고 간 경험이 있으니까요. 다만 요즘은 AI가 만드는 시간을 워낙 줄여줘서, ‘만들 수 있다’는 것 자체를 저만의 강점이라고 말하기는 애매해졌더라고요.

Grower와 Prototyper는 상대적으로 약합니다. 특히 Grower는 최근까지도 저와 거리가 먼 이야기라고 생각했거든요. 그런데 그 생각을 바꾼 일이 하나 있었습니다.

주문 동선을 고치다

최근 회사에서 주문 동선을 개선하는 작업을 했습니다. 문자메시지를 타고 들어온 고객이 주문까지 가는 경로가 지나치게 길었거든요. 주문서 페이지에서 바로 간편가입이 되게 하고, 여러 단계의 페이지 전환을 최대한 줄였습니다.

배포하자마자 비회원 주문서의 일일 접근량이 9배가 됐습니다.

일주일쯤 뒤에 담당 기획자님과 미팅을 했는데, GA4 이벤트를 분석해보니 주소 검색을 하고 난 직후에 이탈률이 급격히 튄다는 겁니다. 그 지점을 살펴보니, 모바일 웹이나 iOS에서는 정상적으로 동작하던 # 기반 URL 처리가 안드로이드에서는 취소 버튼을 눌렀을 때 적용되지 않아 고객이 주문서 바깥으로 강제로 튕겨나가고 있었습니다. 네이티브 개발자와 협업해서 이 부분을 고쳤고, 이탈률을 크게 줄일 수 있었습니다.

사실 이건 원래부터 있던 버그였습니다. 그런데 예전에는 비회원 주문서로 들어오는 고객 자체가 적어서 아무도 발견하지 못했거든요. 동선을 개선해 의미 있는 트래픽과 지표가 쌓이고 나서야 비로소 드러난 문제였습니다.

코드를 꼼꼼히 짜서 잡아낸 버그가 아니었습니다. 만들어 놓은 걸 지표로 관찰하고, 기획자와 같이 데이터를 들여다보고, 그 안에서 문제를 찾아 다시 개선한 과정이었거든요. Boris의 분류로 치면 Grower에 가까운 경험이었던 셈입니다.

그래서

이 경험 하나 가지고 스스로를 Grower로 부를 자신은 없습니다.

다만 이 일을 겪고 나서, 코드만 쌓아 올리는 개발자로는 부족하겠다는 생각이 들었습니다. 만들고 배포하는 데서 끝내지 않고, 그 뒤의 숫자와 사용자의 움직임까지 읽어야 서비스가 자란다는 걸 이번에 봤거든요.

그래서 지금 갖고 있는 Maintainer를 바탕에 두고, Sweeper를 계속 갈고닦고 싶습니다. 거기에 이번에 필요성을 실감한 Grower의 감각, 그러니까 만든 것을 지표로 보고 다듬는 눈을 조금씩 더해가고 싶고요.

Builder는 어찌 됐든 개발자로 사는 이상 계속 가져가게 될 소양이라고 생각합니다. 다만 만들어내는 일 자체는 이제 AI와의 협업으로 상당 부분 채울 수 있는 영역이거든요. 그래서 제 지향점은 아무래도 Grower 쪽을 향하게 될 것 같습니다.