회사에서는 누구나 자기의 일이 있다.

개발자는 개발을 해야 하고
디자이너는 디자인을 해야 하고
기획자는 기획을 해야 한다.

하지만 모든 사람은 각자의 일 말고도 “팀원으로서의 일”이 따로 있다.

그것은 바로 비지니스적으로 좋은 프로덕트를 만드는 일이다.

(* 우선 ‘비지니스적으로 좋은 프로덕트’가 무엇인지에 대해 먼저 정의해야겠지만,
여기서는 일단 매출로 귀결되는 제품이라고 정의하고 넘어가자 )

좋은 코드를 짜는 것, 멋진 디자인을 만드는 것 등 모든 것은 수단일 뿐이다. 결국 모두의 최종적인 목표는 비지니스적으로 좋은 프로덕트를 만드는 것이다. 따라서 당장 눈 앞에 놓인 코드를 짜는 것보다 더 중요한 것은 비지니스적인 관점에서 영향을 미치는 일을 하는 것이다.

그게 무엇이든 간에.

팀원으로서의 일이 어려운 이유

하지만 '팀원으로서의 일'을 하는 것은 생각보다 쉽지 않은데, 그 이유에는 세 가지가 있다.

1. 문제를 발견하는 과정이 복잡하기 때문에.

직무와 관련된 문제는 어렵더라도, 문제를 정의하는 것 자체는 명확한 경우가 많다. 개발자라면 코드의 성능이나 구조에서 문제를 찾을 수 있고, 디자이너라면 사용성이나 인터페이스에서 문제를 찾을 수 있다. 문제의 범위와 해결해야 할 대상이 비교적 분명하기 때문이다.

하지만 비즈니스 문제는 다르다. 하나의 문제에도 제품, 고객, 시장, 매출 등 여러 요소가 얽혀 있고, 그 과정에는 다양한 이해관계자가 개입한다. 따라서 문제가 무엇인지 파악하기 위해 확인해야 할 것도 많고, 하나의 현상만으로 문제의 원인을 단정하기도 어렵다.

2. 문제를 발견하더라도 이를 해결할 권한이 없기 때문에.

각자의 직무에는 저마다의 책임과 권한이 주어진다. 개발자는 개발 영역에서, 디자이너는 디자인 영역에서 주도적으로 판단하고 실행할 수 있다. 하지만 직무의 경계를 넘어 비즈니스 문제에 관여할 때는 이야기가 다르다. 문제를 발견하고 개선의 필요성을 느끼더라도, 이를 직접 결정하고 실행할 권한까지 주어지는 경우는 많지 않다.

따라서 문제를 해결하기 위해서는 결국 여러 사람들을 설득하고 협조를 구해야 한다. 하지만 모두가 알듯이 이는 참 어려운 일이다. ‘사공이 많으면 배가 산으로 간다'는 말처럼 모두가 같은 목표를 바라보고 있더라도 각자 바라보는 관점과 우선순위가 다르기 때문이다. 따라서 문제를 안다 하더라도 모두를 설득해 하나로 의견을 모으는 일은 쉽지 않다. 권한도 없다면 더욱 더.

3. 그런 어려움을 헤치고 해내더라도, 좀처럼 눈에 띄지 않기 때문에.

개발자의 일은 함께 일하는 개발자들이 알아보고, 디자인적인 일은 디자이너들이 알아본다. 하지만 비즈니스적으로 중요한 일들은 대개 수면 아래에 있다. 문제를 먼저 발견하고, 여러 사람들을 설득하고, 여러 직군이 같은 방향으로 움직이도록 만들더라도 이는 결과물로 드러나기 어렵다.

어려운 일은 말 그대로 해내기 어려운데다가, 누군가 알아주지 않는 일은 힘이 빠지기 마련이다. 그렇기에 그 두가지의 특성을 모두 가진 ‘팀원으로서의 일’을 해낸다는 것은 그 두 배로 힘든 일이다.

그럼에도 불구하고…

그럼에도 불구하고, 일을 잘 해내고자 노력하는 사람에게 ‘팀원으로서의 일’은 결국 해내야 할 과제다.

내가 온아웃에서 했었던 일을 글로 정리해보고 싶다는 마음이 들었을 때도 가장 먼저 떠오른 건 그런 류의 일이었다.
개발자로서 해온 99%의 일보다 팀원으로서 해오던 그 1%의 일.

오늘은 그 일들에 대해 적어보고자 한다.
내 머리가 고새 까먹어버리기 전에.

한 일 1. 객관적인 데이터로 기획하는 문화 만들기

문제: 낮은 기획 성과와 팀의 방향성 혼선

내가 팀에 합류했을 때는 투자 유치를 위한 MVP가 이미 개발되어 있었다. 하지만 새롭게 나아가려는 방향은 기존과 달랐기 때문에, 사실상 제품을 다시 만들어가는 상황이었다. 그 과정에서 새로운 기획들의 성과는 기대에 미치지 못했고, 팀 내에서도 기획에 대한 공감대가 형성되지 않은 채 보이지 않는 불만이 쌓여가고 있었다.

성과가 낮고 팀 내 방향성이 일치하지 않았던 데에는 많은 원인이 있었겠지만, 내가 생각하는 가장 큰 원인은 데이터나 명확한 판단 기준이 아닌 주관에 의존하는 기획 방식이었다. 문제를 정의하고 해결 방향을 결정하는 과정에서 충분한 데이터나 근거가 뒷받침되지 않았고, 각자의 경험과 판단이 기획의 주요 근거가 되었다. 그러다 보니 기획에 참여하지 않은 팀원들에게 그 방향이 설득되기 어려웠다. 그러던 와중에 PO까지 몇 번 바뀌게 되었을 때는 기획의 방향이 더 크게 바뀌게 되었다. 그러다보니 다른 팀원들의 기획에 대한 신뢰는 낮아지고, 내부 회의에서도 불만과 피로감이 점차 드러나기 시작했다.

해결책: 객관적인 유저 데이터 확보

이런 상황을 바꾸기 위해서는 어떻게 해야 할까? 나는 객관적인 데이터에 기반하여 기획하는 것이 그 해답이라고 생각했다. 특정 개인의 주관적인 판단을 넘어 객관적인 데이터라는 공통의 근거를 바탕으로 기획 한다면 팀 내 방향성을 일치하는데도 도움이 될 것이고, 실제 성과도 더 좋아질 것이라고 생각했다.

하지만 프로덕트 초기에는 객관적인 데이터를 구하기란 생각보기 쉽지 않다. 이미 어느정도 유저가 있는 프로덕트의 경우, 측정하고 싶은 부분에 사용자의 행동을 추적할 수 있는 이벤트(트래커)를 심어놓고 관찰하면 된다. 하지만 프로덕트 초기에는 그런 미시적인 관점의 데이터보다는 거시적인 관점에서의 인사이트가 더 필요하다.

그래서 이런 상황에서 중요하게 확인해야 하는 것이 있으니, 그것은 바로 유저의 말과 행동이다. 세상 모든 비지니스의 기본이 그렇다. 물건을 팔려면 사는 사람이 무엇을 원하는지 알아야 한다. 디지털 프로덕트도 마찬가지다. 초기 프로덕트에서 대체로 목표로 하는 것은 유저의 확보(또는 매출)인데, 이를 위해서는 유저가 무엇을 원하는지 알아야 한다.

그래서 결국 ‘유저 데이터’가 필요했다. 단순히 개인이 해석한 것이 아닌 모두가 볼 수 있는 유저의 말과 행동, 그리고 그로부터 파생된 수치. 그래서 개발 업무를 병행하면서 유저 데이터를 확보할 방법을 지속적으로 찾기 시작했다.

시도 1: 유저 인터뷰하기

유저 인터뷰 요청과 직접 인터뷰

우선 가장 먼저한 것은 대표님에게 미팅을 요청해 기존 유저 인터뷰를 확인한 것이다. 사업 초기에 진행한 몇 건은 있었지만 최근 자료는 없었다. 그래서 대표님과 미팅을 요청해서** 설득**했다. 유저 인터뷰가 기획의 성과를 높이는 데 도움이 될 것이라며 유저 인터뷰를 진행해줄 수 없냐며. 그 결과 그 요청은 받아들여졌다. 다만 다른 업무에 밀려 바로 실행 되지는 않았고,그 이후에도 몇 차례 요청을 이어갔다. 그렇게 회사 차원에서 약 10건 내외의 심층 인터뷰가 진행되었다.

회사 차원에서 인터뷰를 진행하는 동안, 나도 주변 지인을 통해 직접 인터뷰도 진행했다. 정리된 내용을 전달받는 것과 직접 듣는 것에는 차이가 있기 때문이다. 그래서 나도 직접 인터뷰를 진행하며 날 것의 인사이트를 얻고 싶었다. 내 주위에 사용자 타겟과 비슷한 사람이 적어 표본은 굉장히 제한적이었지만 그래도 나름대로 준비하여 진행하였고 이를 통해 새로 인사이트를 얻을 수 있었다.

회사와 개인적인 차원에서 인터뷰를 진행한 결과, 기획에 근거가 될 유저 인사이트를 얻을 수 있었다. 하지만 한계도 있었는데, 유저인터뷰라는 이 방법이 지속적이지 않다는 점이었다. 대표님으로부터 회사 차원에서 유저 인터뷰를 이어가기에는 비용과 인력, 시간 등 현실적인 제약이 있다는 피드백을 받은 것이다. 사실 내가 개인적으로라도 계속해서 진행할 수 있으면 좋겠지만, 시간과 표본적인 제약이 있어 어려웠다. 그래서 그 대신 이를 보완할 다른 방법을 찾기 시작했다.

시도 2: 유저 모니터링 툴 도입하기

유저 행동을 관찰할 수 있는 도구 도입

유저인터뷰를 지속적으로 진행하기 어렵다는 피드백을 듣고 그 대안이 없을지 고민했다. 그래서 생각한 것은 유저 모니터링 툴이었다.(Clarity, PostHog)

사실 여러 제약 때문에 유저 인터뷰를 지속적으로 하기 어렵다는 것은 스타트업에게 흔한 문제이다. 나 역시 지난 창업에서 비슷한 문제에 대해 고민했던 적이 있었는데, 그 때 생각해 낸 해결책이 유저 모니터링 툴이었다. 이 툴을 이용하면 매번 인터뷰를 진행하지 않더라도 유저가 제품 안에서 어떻게 움직이고 어떤 행동을 하는지 화면으로 관찰할 수 있었다. 직접 이유를 물을 수는 없지만, 수치만으로는 보이지 않던 사용 맥락을 살펴볼 수 있다는 점에서 도움이 많이 되었다.

그래서 그 때의 경험을 교훈삼아 이번 팀의 상황에 적절한 툴을 찾아서 제안했다. 그 중 가장 신경 쓴 것은 최소 노력을 들여서 최대 효과를 들일 수 있다는 점을 팀원들에게 보여주는 일이었다. 아무리 좋은 인사이트를 얻을 수 있더라도, 너무 손이 많이 가면 안그래도 바쁜 다른 팀원들의 반발을 사기 쉽다. 그래서 최소한의 ‘딸깍’으로 우리에게 지금 필요한 데이터를 얻을 수 있는 툴을 찾아 선택했고, 그 결과 다행히 큰 반발 없이 팀원을 설득하여 도입할 수 있었다. 최종적으로 모니터링 툴은 성공적으로 제품에 안착되었다. 그 이후 기획팀은 신규 기능이 추가되었을 때 실제 유저 행동을 관찰하고 인사이트를 얻는 데 이 도구들을 활용할 수 있었다. 처음에는 자동으로 툴에서 제공해주는 데이터를 위주로 활용했다. 그러다 점점 이 툴에 대한 활용이 늘면서 나중에는 직접 수동으로 이벤트를 심어서 더 구체적인 데이터를 수집하는 방향으로도 이어졌다.

이렇게 유저인터뷰와 유저 모니터링 툴 설치를 통해 객관적인 유저 데이터로 기획을 할 수 있는 토대가 마련되었다. 하지만 한 가지 문제가 있었으니,그렇게 파악한 데이터를 바탕으로 기획을 해도 여전히 리텐션이 낮았던 것이다. 유저인터뷰, 자동으로 수집된 데이터, 직접 심은 이벤트를 통한 데이터로 가능한 기획을 해보았으나 여전히 리텐션 지표가 올라가지 않았다. 그래서 이 문제를 해결하기 위해서는 지금껏 얻은 데이터 외에도 추가적인 데이터와 인사이트가 필요하다고 생각했다.

유저가 실제로 제품에서 무엇을 필요로 하는지를 이해할 수 있는 그런 데이터.

시도 3: 숨겨진 데이터를 활용하여 기획안 도출하기

이미 쌓이고 있던 검색 데이터 활용

여전히 해결되지 않는 리텐션 문제를 해결할 단서를 찾기 위해 이미 쌓인 데이터를 살펴보기로 했다. 그렇게 백엔드 DB를 확인하던 중 최근 추가된 검색 기능의 검색어 데이터가 눈에 들어왔다. 다른 데이터들에서는 유저가 제품을 어떻게 쓰는지 보여주었다면, 검색어에는 유저가 그 순간 앱에서 무엇을 찾고자 했는지에 대한 의도가 남아 있었다.

다만 한가지 문제점은 검색어 데이터를 그대로 활용하기 어려웠다는 점이다. 어떤 단어가 많이 검색되었는지는 볼 수 있었지만, 그것만으로 유저가 무엇을 원하는지 이해하기에는 부족했다. 같은 의도라도 표현이 달랐고, 하나의 검색어에 여러 의미가 섞여 있기도 했기 때문이다.

그래서 먼저 MySQL로 데이터를 직접 조회해가며 전반적으로 검색어들을 살펴보았다. 많이 검색된 단어부터 확인하고, 관련된 표현을 찾아 묶어보기도 하고, 기간을 바꿔가며 어떤 차이가 있는지 확인했다. 이 과정에서 고민한 것은 이 검색어들을 의미있게 만들기 위해서는 어떻게 가공해야 할 것인가와 그 가공된 검색어를 어떤 기준으로 묶을 것인가였다.

그래서 다음과 같은 과정을 거치며 문제를 해결해 나갔다.

1. 1차 가공 - 복합 검색어 분리

먼저 검색어를 의미 단위로 분리할 필요가 있었다.** **예를 들어 ‘겨울 데이트룩’, ‘여자 데이트 코디’는 다른 검색어지만, 둘 다 데이트 때 입어야 하는 옷을 검색하고 싶어하는 유저의 공통된 의도를 가지고 있었다. 반면 두 키워드는 ‘겨울’, ‘룩’ 과 ‘여자’, ‘코디’ 라는 서로 다른 의도도 함께 담겨 있다. 따라서 이를 효과적으로 분석하기 위해서는 키워드를 분리하여 그 안에 담긴 의미를 구분해 분석할 필요가 있었다.

따라서 이를 위해 두 가지 작업을 했다. 먼저 여러 개로 이루어진 검색어를 의미 단위(토큰)로 나눴다. 그리고 분석에 불필요한 단어(불용어)를 찾아 제거했다. 예를 들면, 룩 또는 코디와 같은 단어는 어디에나 붙을 수 있으므로 도움이 되지 않아서 없애는게 낫다.

그렇게 키워드로 나누고 불용어를 제거하여 1차적으로 데이터를 가공한 결과, 유저의 검색어는 각각의 의도를 따로 분석할 수 있는 개별 키워드로 분리될 수 있었다.

2. 2차 가공: 카테고리 데이터 추가

그렇게 그 다음으로 분리된 키워드를 어떤 기준으로 묶어서 분석해야 할 지를 고민했다. 1차 가공에 따라 분리된 키워드들을 살펴보니 키워드에는 다양한 의도가 있었다. 의류나 브랜드처럼 무엇을 입을지 찾는 검색이 있었고, 데이트나 여행처럼 어떤 상황에서 입을지 찾는 검색도 있었다. 청순한 분위기나 빈티지 스타일, 오버핏이나 레이어드처럼 옷의 스타일을 표현하는 검색도 있었다.

따라서 이러한 검색어들을 카테고리별로 분류하는 것이 필요하다고 생각했다. 적절한 카테고리로 분류하여 비슷한 키워드들을 그룹지어서 분석해본다면, 특정 시기에 어떤 스타일에 관심이 높아지는지, 최근 어떤 브랜드가 많이 검색되는지 등 사용자들이 제품을 사용하는 의도를 더 구체적으로 파악할 수 있을 것이라고 생각헀다.

그래서 고민한 결과 모든 키워드를 다음과 같은** 6개의 카테고리로 키워드를 분류**하기로 했다. 다만 유저가 검색한 키워드만으로는 이를 구현하기가 불가능했는데, OpenAI API 와 Python 코드를 통해서 데이터를 추가적으로 2차 가공하여 필요한 데이터를 완성할 수 있었다.

상위 카테고리	하위 카테고리	키워드 예시
의류	아우터	패딩, 코트, 재킷, 가디건
	상의	니트, 셔츠, 맨투맨, 후드
	바지	청바지, 슬랙스, 와이드팬츠
	원피스	미니원피스, 롱원피스
	투피스	투피스, 세트업
	스커트	미니스커트, 롱스커트
	트레이닝복	트레이닝복, 운동복
	비치웨어	수영복, 비키니
	신발	운동화, 부츠, 로퍼
	가방	숄더백, 크로스백
	액세서리	모자, 벨트, 머플러
	주얼리	목걸이, 반지, 귀걸이
스타일 (STYLE)	상황·장소	데이트, 여행, 결혼식, 바다
	무드	청순, 귀여움, 러블리, 따뜻함
	패션 스타일	스트릿, 빈티지, 캐주얼, 드뮤어
	핏	오버핏, 와이드핏, 벌룬핏
	스타일 디테일	레이어드, 크롭, 체크
브랜드	-	나이키, 아디다스, 유니클로
색상	-	블랙, 화이트, 그레이, 네이비
계절	-	봄, 여름, 가을, 겨울
기타	-	다른 카테고리에 해당하지 않는 키워드

3. 자동화 툴 제작

검색어를 의미 단위로 나누고 특정 카테고리에 따라나누자, 의미없던 검색 데이터가 점점 의미 있는 정보로 바뀌어 갔다. 유저들이 어떤 것들을 검색하는지, 유저들이 어떤 의도를 가지고 검색을 하는지 더 자세히 살펴볼 수 있게 된 것이다. 다만 처음에는 단순히 DB에만 넣어놓고 SQL을 통해서 하나씩 확인을 했었는데 이런 분석을 키워드 별로 매번 수동으로 반복하기에는 많은 시간이 들었다.

그래서 분석을 자동으로 해주는 자동화 툴을 빠르게 만들었다. 기존에 검색어 데이터들은 유저들이 친 검색어가 동일하지 않으면 동일한 의도로 묶어서 분석하기가 불가능했는데, 이제는 카테고리 별로 손쉽게 유저들의 검색의도를 파악이 가능하게 되었다. 나 역시 이 툴을 이용하여 빠르게 DB에 있는 검색어 데이터에 대한 전체적인 분석을 진행했고, 기획에 필요한 특정 인사이트를 도출할 수 있었다.

4. 기획 도출

결론적으로 그 인사이트를 바탕으로 기획안을 만들어 기획팀과 개발팀에게 발표하였다.

먼저 모니터링 툴로 분석한 주차별 리텐션 지표를 보여주며 문제를 정의하였다. 특정 주에 방문한 유저들을 추적한 결과, 초기 n주 차의 재방문율은 x%였지만 이후 점점 줄어들어 m주 차에는 y%로 낮아졌다. 이를 근거로 유저들이 장기적으로 앱을 다시 찾을 이유를 제공하는 것이 중요하다는 의견을 제시하였다.

이어서 검색어 데이터를 기획의 근거로 활용할 수 있는 이유를 설명하였다. 검색 기능 출시 이후 k주간 평균 z%의 유저가 검색을 이용하고 있었다. 따라서 검색어 데이터는 일부 유저의 개별적인 요구를 넘어, 실제 사용자들의 관심과 의도를 파악하고 기획 방향을 세우는 데 활용할 만한 근거라고 판단하였다.

그다음에는 검색어 분석 결과를 바탕으로 구체적인 해결책을 제안하였다. 한 달간 가장 많이 검색된 상위 n개 키워드 중 70%가 OO 카테고리 관련 키워드였다. ‘OO’는 n회, ‘OO’는 m회 검색되었고, 상황을 나타내는 ‘OOO’ 도 k회 검색되었다. 이를 통해 유저들이 OOO를 찾으려는 의도를 가지고 있다고 추정하였고, 그 목적을 더 쉽게 달성할 수 있도록 OOO 기능을 제안하였다. 검색량이라는 객관적인 근거를 제시하고, 이를 바탕으로 기획의 가설을 설명한 것이다.

이후 피그마로 제작한 Lo-fi 프로토타입을 보여주며 기획의 전체적인 흐름과 사용 방식을 설명하였다. 또한 실제 구현을 위해 기획·디자인·프론트엔드·백엔드·AI 각 팀이 검토해야 할 사항을 정리하고, 기획의 성공여부를 판단할 주요 지표와 보조 지표를 제시하였다.

발표 이후에는 기획팀과 개발팀의 우려 사항을 함께 논의하였다. 이를 반영해 몇 차례 수정하고, 현재 일정 안에서 가장 빠르게 구현할 수 있는 방향으로 범위와 기획을 조정한 끝에 기획안은 통과되었다.

이러한 과정을 거치며 지켜본 결과, 이전 기획 회의 때 보았던 분위기와는 확실히 다른 분위기가 보였다. ‘나는 이렇게 생각한다’는 주관을 기반으로 한 기획이 아닌, ‘실제 데이터가 이렇고 그래서 이렇게 해보려고 한다’는 객관적인 방식으로 이야기하자 논의의 초점이 더 분명해졌다. 각자의 생각과 우려를 구체적인 근거 위에서 이야기를 하니, 확실히 팀의 방향성 혼선을 줄이고 의견을 모으는데 도움이 되었다고 느꼈다.

결과: 객관적인 근거를 확보하는 문화

여태까지 주관적인 기획문화에서 생긴 팀 문제를 해결하기 위해 내가 노력해 본 내용을 적어보았다. 다방면에서 객관적인 유저 데이터를 확보할 방법을 고민했고, 확보했고, 그걸로 바탕으로 객관적인 데이터를 기반으로 한 기획안으로까지 연결 시켰다.

그리고 여기서는 짧은 기간에 일어난 일인 마냥 적었지만, 사실 위에 적은 일은 긴 기간동안에 걸쳐 아주 천천히 일어났던 일이다. 간단한 한 문장으로 요약되는 하나하나가 실제로 팀에 적용되기까지는 사실 더 많은 어려운 협의 절차와 노력이 필요했다. 시간적인 부분도 큰 제약이었는데, 위 문제들을 해결하는 중에도 다른 개발자들과 동일한 양의 개발업무가 있었으므로, 매우 시간이 제한되어 힘들었다.

당연히 이 모든 일을 나 혼자 해낸 것은 아니다. 유저 인터뷰는 디자이너분이 노력을 해주었고, 모니터링 툴로 추적할 이벤트를 기획하는 일은 PO분이 담당해주셨고, 검색어 원본 데이터를 쌓기 위한 기능을 만들기 위해서는 AI와 개발 팀원들이 특히 많은 노력을 해주었다. 그 중 나의 기여가 있다면 ‘안그래도 바쁜데 자꾸 귀찮게 굴기’ 정도로 요약 가능하겠다.

하지만 누가 얼마나 기여했느냐를 떠나서, 내가 애시당초 풀려고 했던 문제를 푸는 것에는 다소 성공한 듯하다. 객관적인 데이터가 중요하는 글을 쓰면서 수치를 제시하지 않고, 이 ‘다소’라는 말로 퉁치며 이렇게 마무리 짓는 것은 웃기지만…… 대개 이런 일들은 변인통제가 상당히 어려운 법이다. 그러므로 부족하게나마 이 정도로만 남겨두고, 이 파트는 마무리하고자 한다.

만약에 가능하다면, 기획 전달 때 팀원들의 미간이 미세하게 찡그려지는 횟수, 개발 팀 내부 회의에서 나오는 “몰라요” 횟수 등을 측정해보고 이를 개선의 근거로 제시해보고 싶다.

(농담이다)

한 일 2. 안 해도 되는 일을 없애서 실행 속도 높이기

문제: 느린 실행 속도

여태 기획에 대해서 이야기했다면 이제는 구현 측면에서 한번 이야기 해보고 싶다. 기획을 잘하는 것만큼 중요한 것은 이를 빠르게 구현하는 일이다. 시간과 자원이 제한된 팀에서는 기능을 출시하고 가설이 맞는지 확인해야 다음 시도를 할 수 있다.

하지만 모두가 늘 바쁘게 움직이고 있었는데 불구하고, 우리 팀은 새로운 기획을 제품으로 만들어 검증하는 데는 시간이 오래 걸렸다. 기능 자체가 어려워서만은 아니었다. 기획에서 출시까지의 과정에서 가설 검증과 직접 관계없는 업무가 각 단계에서 반복되고 있었다.

• 디자인

  디자인에서는 가설 검증과 무관한 디자인 디테일이 많았다. 하나하나는 사소해 보여도, 이를 구현하고 세부 표현을 맞추는 작업이 여러 화면에서 반복되면서 개발 시간이 쌓였다. 테두리를 한 가지 색으로 채우는 대신 색이 서서히 바뀌는 그라데이션을 넣고, 그 미세한 표현을 계속 논의하며 맞추는 일이라던가, 일반적인 방향과 반대로 움직이는 커서를 구현하는 일이 그런 예였다. 문제는 특정 표현 하나에 드는 비용보다, 이런 작은 작업이 새 기획과 화면마다 계속 추가된다는 점이었다. 각각의 필요성과 개발 비용을 함께 검토하지 않다 보니, 가설을 확인하는 데 꼭 필요하지 않은 작업에도 많은 시간을 쓰게 되었다.

• 개발

  개발에서는 비슷한 기능을 처음부터 다시 만드는 일이 반복되었다. 예를 들어 선택한 항목을 표시하는 칩도 프로덕트마다 모서리 둥글기·테두리·그림자가 조금씩 달랐고, 클릭했을 때의 세부 동작도 달랐다. 같은 역할을 하는 요소지만 모양과 동작이 함께 묶여 있어, 기존 것을 그대로 가져다 쓰거나 일부만 바꾸기 어려웠다.

  버튼이나 입력창 같은 컴포넌트를 조합한 큰 컴포넌트에서도 같은 문제가 있었다. 필터 영역처럼 입력창과 칩, 버튼을 함께 쓰는 부분도 기존 요소를 조합해 만들기보다 하나의 덩어리로 개발되었다. 이전에 비슷한 선택·해제 기능을 구현했더라도, 새 컴포넌트 안에서는 그 기능을 다시 만드는 식이었다. 작은 요소도, 이를 조합한 큰 구성도 재사용하기 어려워 새 기획마다 이미 구현한 기능과 스타일을 반복해서 개발하는 일이 늘어나고 있었다.

• QA

  완성된 기능과 디자인이 의도대로 동작하고 보이는지 확인하는 QA 단계에서도 반복 업무가 있었다. 화면마다 다른 디자인 값을 하나씩 확인하고 맞춰야 했다. 기능 구현이 끝나도 색상·글자 크기·줄 높이 같은 세부 값의 수정은 남았고, 화면이 늘어날수록 확인할 대상도 함께 늘어났다. 예를 들어 새 기능을 개발하는 중에도 이전 화면의 디자인 QA 요청이 들어와 두 작업을 함께 처리해야 했다. 수정 작업을 끝내더라도 다음 화면에서 비슷한 차이를 다시 확인해야 하는 구조였다.

기획이 바뀔 때마다 새 디자인과 코드가 추가되었고, 관리하고 수정할 대상도 함께 늘어났다. 그런데도 다음 기획에서는 비슷한 기능을 처음부터 다시 개발해야 했다. 개인이 더 빠르게 작업하는 것만으로는 팀의 실행 속도를 높이기 어려웠다. 반복되는 일 자체를 줄일 구조적인 해결책이 필요했다.

해결책: 더 빨리 만드는 대신 만들 일을 줄이기

실행 속도를 높이기 위해서는 가설 검증에 필요하지 않은 일 자체를 줄여야 한다고 생각했다. 핵심은 기존 디자인과 개발 코드를 재사용하는 것이었다. 이미 만든 요소로 같은 가설을 검증할 수 있다면, 매번 새로운 값을 정하고 비슷한 기능을 다시 구현할 필요는 없었다.

이를 위한 해결책으로 생각한 것이 디자인 시스템이었다. 디자인 시스템은 색상과 타이포그래피 같은 공통 스타일 기준, 그리고 버튼과 입력창처럼 재사용하는 컴포넌트를 함께 정리한 체계다. 디자인과 개발이 같은 기준을 사용하면 세 가지 반복 업무를 줄일 수 있다고 보았다.

• 반복적인 결정과 논의 줄이기. 기본 요소의 모양과 동작을 정해두면 새 기획마다 세부사항을 하나씩 결정하고 구현 가능 여부를 확인하는 부담이 줄어든다. 새롭게 판단해야 하는 부분에 논의를 집중할 수 있다.
• 중복 개발 줄이기. 같은 역할에는 같은 컴포넌트를 사용하고, 달라지는 부분만 추가하면 된다. 디자인에서도 기존 요소를 활용하고, 개발에서도 이전에 만든 코드를 가져다 쓸 수 있다.
• 수정할 곳 줄이기. 공통 기준과 컴포넌트를 한곳에서 관리하면 화면마다 흩어진 값을 찾아 바꾸는 일이 줄어든다. 같은 원본을 사용하는 곳에 변경을 함께 반영할 수 있고, QA에서도 정해진 기준을 바탕으로 확인할 수 있다.

다만 디자인 시스템을 도입한다고 무조건 일이 줄어드는 것은 아니다. 만드는 일도, 팀이 함께 사용하는 일도 비용이 든다. 특히 기획이 빠르게 바뀌는 우리 팀에서는 다음과 같은 부담을 고려해야 했다.

• 당장의 개발 시간을 써야 한다. 기존 디자인과 코드를 분석하고 공통 기준을 정하는 동안에도 신규 기능은 개발해야 한다. 모든 화면을 한 번에 바꾸려 한다면, 속도를 높이려는 작업 때문에 오히려 출시가 늦어질 수 있었다.
• 배우고 관리하는 일이 추가된다. 디자이너와 개발자가 사용 방법을 익혀야 하고, 디자인 파일·코드·문서도 같은 기준으로 유지해야 한다. 새 요구가 생길 때 기존 기준을 사용할지, 예외를 허용할지 논의하는 비용도 생긴다.
• 잘못 묶으면 변경이 더 어려워진다. 지금 비슷해 보인다는 이유로 여러 화면을 하나의 컴포넌트에 묶어두면, 기획이 달라질 때마다 예외와 옵션을 추가해야 한다. 한곳을 고친 영향이 다른 화면까지 번질 수 있고, 필요한 차이를 표현하기 위해 공통 구조를 우회하는 일이 생길 수도 있었다.

이런 비용을 고려해도 최소한의 디자인 시스템은 필요하다고 판단했다. 기획과 화면 구성은 바뀌어도 색상·글자 스타일·버튼·입력창처럼 반복되는 요소는 계속 쓰이고 있었다. 이 부분을 그대로 두면 새로운 기능을 만들 때마다 비슷한 결정과 구현, QA 비용을 다시 치러야 했다. 이미 반복해서 발생하는 비용이 있었고, 앞으로도 같은 방식으로 쌓일 가능성이 컸다.

그래서 반복되는 업무와 그 비용을 설명하고, 앞으로 만드는 화면부터라도 기존 디자인을 더 많이 재사용하자고 제안했다. 하지만 디자이너는 우리 프로덕트에 디자인 시스템을 적용하기 어렵다는 입장이었다. 디자인이 중요한 서비스이고, 프로덕트마다 필요한 화면과 동작도 달라 지금의 차이는 불가피하다는 것이었다. 공통 기준을 적용하면 제품마다 필요한 디자인의 차별점까지 사라질 수 있다는 우려였다.

이 우려를 풀려면 업무를 줄여야 한다는 필요성만 설명해서는 부족했다. 디자인 시스템을 도입해도 제품별 디자인의 차별점을 유지할 수 있다는 구체적인 방안이 필요했다. 그래서 내가 먼저 실제 제품을 분석해 우리 상황에 맞는 설계안을 만들어보기로 했다.

시도 1: 상황에 맞는 디자인 시스템 설계

설계에서 가장 중요했던 것은 프로덕트별 차이를 유지하면서 반복되는 부분만 공통으로 묶는 것이었다. 복잡한 제품을 하나의 틀에 맞추려는 것이 아니라, 그 안에서 함께 쓸 수 있는 최소한의 기준을 찾고자 했다. 이미 잘 만들어진 디자인 시스템도 우리에게 필요한 부분만 참고하기로 했다. 기획이 자주 바뀌고, 팀원들이 새 규칙을 배우고 관리할 시간도 충분하지 않았기 때문이다.

그래서 세 가지 원칙을 정했다.

• 작업 대비 효과가 큰 것부터 정리한다. 여러 화면에서 반복되는 색상과 글자 스타일, 기본 컴포넌트처럼 한 번 정리하면 다음 작업에서도 계속 쓸 수 있는 부분에 집중했다.
• 팀원이 쉽게 이해하고 사용할 수 있게 만든다. 처음부터 많은 규칙을 추가하기보다, 기존 작업에서 무엇을 선택하고 무엇을 재사용하면 되는지 분명하게 정했다.
• 제품마다 필요한 차이는 남긴다. 공통으로 쓰는 기준과 개별 화면에서 바꿀 수 있는 부분을 나누어, 재사용 때문에 디자인과 기능에 필요한 차이를 포기하지 않도록 했다.

범위도 그에 맞춰 줄였다. 색상·타이포그래피·간격·모서리와 그림자, 그리고 버튼 같은 기본 컴포넌트를 먼저 정리하고, 변경이 잦은 큰 컴포넌트의 통합과 아이콘 전체 정비는 뒤로 미뤘다. 새 기능 하나를 만들 때마다 공통 시스템까지 크게 고쳐야 한다면, 오히려 일을 더 만드는 셈이기 때문이다.

구체적인 설계는 다음 다섯 가지로 나누었다.

1. 색상: 같은 용도에는 같은 색상을 쓰기

먼저 기존에 제품 안에서 쓰인 색상을 살펴보니 관리하는 항목이 83개였다. 쓰임새는 크게 두 가지였다. 하나는 화면 배경이나 버튼처럼 여러 화면에서 반복해서 쓰는 색상이고, 다른 하나는 특정 화면의 디자인을 위해 일회성으로 쓰는 색상이었다. 같은 용도로 반복해서 쓰이지만 미세하게 다른 색상은 통일할 수 있었다. 반면 제품의 분위기나 특정 콘텐츠를 표현하는 데 필요한 일회성 색상까지 없앨 필요는 없었다.

그래서 비슷한 용도로 쓰이던 값을 통일해, 공통으로 쓸 색상값을 22개로 정리했다. 여기에 배경·텍스트·구분선·강조 등 자주 쓰는 용도를 12가지로 정했다. 예를 들어 화면 배경과 그 위에 놓이는 카드 배경의 색을 각각 정해두고, 새 화면에서도 같은 기준을 사용하도록 했다. 배경색을 매번 새로 고르거나 미세한 차이를 다시 맞추는 일을 줄이려는 것이었다. Material Design·IBM Carbon·LINE·원티드의 체계를 비교한 뒤, 우리에게 필요한 구분을 갖춘 원티드 체계를 간소화해 참고했다. 특정 화면의 디자인에 필요한 새 색상은 추가할 수 있게 두었다. (global) 다만 색상 계열과 아홉 단계의 밝기를 기준으로 이름을 붙여, 필요한 차이는 유지하면서 비슷한 값이 다시 무분별하게 늘어나는 것은 막고자 했다.

2. 타이포그래피: 크기·굵기·줄 간격을 스타일로 묶기

그 다음은 타이포그래피, 즉 제품 안에 쓰이는 텍스트와 관련된 요소였다. 제품에 쓰이는 타이포그래피를 분석해봤을 때, 서로 다른 텍스트 크기만 23종류이었고, 같은 크기여도 굵기와 줄 간격이 달라 관리할 조합은 더 많았다. 하지만 대부분 비슷한 용도였고 서로 약간의 차이밖에 없었다. 하지만 모두 크기, 줄 간격, 굵기 등이 그 때 그때 따라 조금씩 달라져서, 개발과 QA에서 그 차이를 다시 확인하는 일이 반복되고 있었다.

따라서 제각각이던 텍스트 조합을 크기·굵기·줄 간격까지 묶은 7개 스타일로 정리했다. 제목용 3개, 본문용 3개, 짧은 설명용 1개였다. 같은 16px이라도 제목은 굵게, 본문은 줄 간격을 넓게 정하는 식으로 용도에 필요한 차이는 남겼다. 모든 글자를 똑같이 만드는 것이 아니라 비슷한 조합을 묶는 방식으로, 디자인의 차별점이 사라질 수 있다는 디자이너의 우려도 반영했다. 이제 텍스트를 넣을 때마다 크기·굵기·줄 간격을 따로 정하는 대신, 디자인과 개발에서 같은 이름의 스타일 하나를 선택하면 되도록 했다.

3. 스페이싱: 디자인과 개발에서 같은 숫자로 읽기

화면에 쓰인 간격을 살펴보니 1pt·3pt처럼 작은 단위까지 값이 잘게 나뉘어 있었다. 버튼 안쪽의 여백이나 카드 사이의 간격도 비슷한 용도인데 화면마다 조금씩 달랐다. 이 차이는 개발 이후에도 반복 작업으로 이어졌다. QA에서 간격을 조금 늘리거나 줄여달라는 요청이 들어오면 수정하고 다시 확인하는 과정을 거쳐야 했고, 여러 화면에서 이런 미세한 조정이 반복되면서 간격을 맞추는 데만 많은 시간이 들었다.

간격은 요소의 종류와 배치에 따라 세부 규칙을 만들기 시작하면 너무 복잡해질 수 있었다. 그래서 ‘모든 간격은 4pt의 배수로 정한다’는 단순한 규칙으로 통일했다. 조금 더 자유롭게 배치가 가능하도록 화면에 필요한 배치는 자유롭게 하되, 간격은 4·8·12·16·20·24pt처럼 정해진 단위에서 선택하도록 한 것이다. 비슷한 간격을 1pt씩 조정하며 별도의 값으로 늘리는 대신, 디자인과 개발이 같은 기준을 사용해 불필요한 결정과 QA 수정을 줄이고자 했다.

4. 그 외 요소들: 비슷한 모양은 정해진 값을 함께 쓰기

모서리 둥글기·테두리 두께·그림자도 화면마다 조금씩 달랐다. 색상이나 타이포그래피만큼 우선순위가 높은 부분은 아니었지만, 통일하는 데 드는 비용이 적고 그에 비해 반복적인 QA를 줄일 수 있어 함께 정리하기로 했다.

그래서 자주 쓰는 값을 공통 스타일로 묶어 선택하도록 했다. 테두리는 몇 가지 두께를 기준으로 정리하고, 그림자도 미리 정의한 스타일을 가져다 쓰게 했다. 새 화면마다 비슷한 효과를 따로 만들고 QA에서 미세한 차이를 맞추는 대신, 같은 스타일을 재사용하도록 한 것이다.

5. 컴포넌트: 반복되는 요소를 조합해 새 화면 만들기

이미 만든 기능을 다른 화면에서 쓰기 어려운 이유도 살펴보았다. 여러 곳에서 쓸 수 있는 작은 요소와 특정 화면에만 필요한 기능이 한 덩어리로 묶여 있었다. 필터 영역을 새로 만들 때도 기존 입력창·칩·버튼을 조합하기보다 비슷한 것을 다시 개발하게 되는 구조였다. 반대로 큰 화면 전체를 하나로 통일하면, 기획이 바뀔 때 다른 화면까지 함께 수정해야 할 수 있었다.

그래서 이를 해결하기 위해 아토믹 디자인(Atomic Design) 도입하기로 했다. 기본 컴포넌트는 한 번 만들어 함께 쓰고, 큰 화면은 이를 조합해 만들도록 나누었다. 예를 들어 칩의 모양과 기본 동작은 공통으로 만들고, 새 필터 화면에서는 어떤 항목을 선택하고 해제할지만 연결하는 식이다. 제품별 배치와 데이터 처리는 각 화면에 남겼다. 모든 화면을 같게 만드는 대신, 이미 만든 부분은 가져다 쓰고 새 기획에 필요한 부분만 개발할 수 있게 하려는 것이었다.

이렇게 구체적인 디자인 시스템 설계안을 준비하여 이제 ‘우리 프로덕트는 복잡해서 적용하기 어렵다’는 우려에 답할 수 있는 초안이 생겼다. 화면마다 필요한 차이는 남기고, 그 안의 기본 요소와 공통 기준만 함께 쓰는 설계였다. 하지만 적용할 수 있는 방안을 만드는 것과 팀이 그 방안을 받아들이는 것은 다른 일이었다. 다음으로는 준비한 설계안을 실제 화면에 대입해 보여주고, 각자의 작업 부담을 함께 조정할 필요가 있었다.

시도 2: 설득

설계안을 실제로 쓰기 위해서는 디자이너와 개발자가 각각 걱정하는 부분을 풀어야 했다. 디자이너에게는 우리 제품에도 적용할 수 있다는 설명이 필요했고, 개발자에게는 방대한 기존 코드에서 어디부터 시작할지 보여줄 필요가 있었다.

1. 디자이너: 제품의 차이를 유지할 수 있는 구체적인 사례 제시

디자이너에게는 앞서 우려했던 제품의 복잡성과 디자인의 차이를 설계안이 어떻게 다루는지 보여주는 데 집중했다. 색상과 글자 스타일을 함께 쓴다고 모든 화면이 같아지는 것은 아니고, 기본 컴포넌트를 재사용해도 화면의 배치와 구성은 다르게 만들 수 있다는 점을 설명했다. 준비한 기준을 실제 제품에 대입해, 공통화할 부분과 그대로 유지할 부분을 구체적으로 보여주고자 했다.

이를 위해서 실제 우리 프로덕트에 적용할 수 있는 디자인 시스템 초안을 준비했다. 또한 적용하기 어렵다는 의견이 나온 부분은 피그마로 시안을 만들고, 핀터레스트와 모빈에서 찾은 디자인 레퍼런스를 함께 제시해 구체적인 적용 방안을 설명했다. 또한 작업 부담도 함께 조정했다. 아이콘처럼 정리할 문제는 있지만 당장 효과에 비해 부담이 크다고 의견을 표시한 것들에 대해서는 과감히 범위에서 제외했다.

여러 차례 설명하고 설계안을 조정하면서, 처음에는 적용하기 어렵다는 입장이었던 디자이너의 태도도 조금씩 달라졌다. 구체적인 해결책으로 우려를 하나씩 해소하자, 이후에는 설계 방안을 함께 논의할 수 있게 되었다. 이를 통해 디자인 시스템 도입의 가장 큰 벽이었던 디자이너의 공감을 얻고, 디자인 시스템 도입을 함께 추진할 수 있었다.

2. 개발자: 구현 초안을 보여주고 신규 작업부터 점진적으로 적용

그 다음은 개발자를 설득하는 일이었다. 개발 쪽에서는 도입 자체에 반대하지는 않았지만, 어디부터 어떻게 적용해야 할지 갈피를 잡기 어려워했다. 이미 여러 프로덕트에 코드가 쌓여 있었고, 새로운 기준을 넣으려다 기존 화면까지 전부 수정해야 하는 것은 아닌지 우려가 있었다. 좋은 기준이라는 데 동의하더라도, 당장의 업무에 어떻게 연결되는지 분명하지 않았던 것이다.

그래서 내가 먼저 개발 환경을 설정하고 사용할 수 있는 초안을 만들어 보여주기로 했다. 공통 스타일과 컴포넌트를 어디에서 가져다 쓰면 되는지 확인할 수 있게 하려는 것이었다. 적용 범위도 기존 코드 전체가 아닌 새로 개발하는 부분부터로 정했다. 이미 동작하는 화면은 두고, 새 기능을 만들거나 기존 화면을 다시 작업할 때 공통 기준과 컴포넌트를 사용하도록 했다. 별도 시간을 들여 한꺼번에 교체하기보다, 제품을 개발하는 과정에서 조금씩 새 시스템으로 바뀌게 하는 방식이었다.

시도 3: 구현

구현에서는 정한 기준을 쉽게 가져다 쓰고, 여러 서비스에서 함께 관리할 수 있는 구조를 만드는 데 집중했다. 디자인 시스템이 문서에만 남아 개발자가 매번 값을 찾아 옮겨 적어야 한다면 반복 업무는 크게 줄지 않을 것이다. 그래서 공통 스타일을 코드에 반영하고, 컴포넌트를 함께 사용할 수 있는 환경을 마련했다.

1. Tailwind: 디자인 시스템을 코드에서 바로 선택할 수 있게 만들기

먼저 설계한 디자인 시스템을 기존에 사용하던 Tailwind에 반영했다. 미리 프리셋으로 색상·타이포그래피·간격·그림자를 미리 설정해놓아서, 개발자가 값을 직접 입력하는 대신 정해진 스타일을 선택해 적용할 수 있도록 했다.

‘팀원이 쉽게 이해하고 사용할 수 있게 만든다’는 원칙에 맞춰 이름을 붙이는 방식도 단순하게 정했다. 크기는 sm·md·lg처럼 작은·중간·큰 단계를 구분하는 이름을 쓰고, 색상과 타이포그래피도 같은 규칙으로 이름을 붙였다. 예를 들어 color-fill-primary는 주요 채움색, typography-title-md는 중간 크기의 제목 스타일을 나타내도록 했다. 이름만 보고도 어떤 용도로 쓸지 짐작할 수 있게 하려는 것이었다.

2. 공통 UI 패키지: 한 번 만든 요소를 여러 서비스에서 재사용하기

버튼이나 칩처럼 여러 곳에서 쓰이는 컴포넌트는 각 서비스의 코드에서 분리해 공통 UI 패키지에 모았다. 여러 앱의 코드를 한곳에서 관리하는 모노레포 구조를 활용해, 각 서비스가 같은 컴포넌트를 가져다 쓰도록 했다. 서비스마다 비슷한 코드를 복사해두는 대신 함께 사용하는 원본을 둔 것이다.

공유하는 과정에서 새로운 반복 업무가 생기지 않도록 하는 것도 중요했다. 공통 컴포넌트를 조금 고칠 때마다 별도로 빌드하고 새 버전을 배포해야 한다면 사용하는 데 부담이 생긴다. 그래서 각 앱을 실행하거나 배포할 때 공통 컴포넌트도 함께 처리되도록 구성했다. 가져다 쓰는 경로도 한곳으로 모아, 공통 패키지 안의 파일 구성이 바뀌어도 각 서비스에서 경로를 일일이 수정할 필요를 줄였다.

3. Storybook: 디자인과 개발이 같은 결과물을 확인하게 만들기

공통 컴포넌트가 있어도 무엇을 가져다 쓸 수 있는지 알기 어려우면 비슷한 것을 다시 만들게 된다. 그래서 Storybook에 디자인 기준과 컴포넌트를 모아볼 수 있는 공간을 마련했다. 실제 서비스의 페이지를 찾아 들어가지 않아도 색상·타이포그래피와 버튼·입력창 등을 따로 확인할 수 있도록 했다.

디자이너와 개발자가 같은 결과물을 보며 이야기할 수 있다는 장점이 있었다. 다만 실제 코드가 바뀔 때 이 공간도 함께 업데이트해야 해, 최신 상태를 유지하는 일이 또 다른 부담이 되었다. 반복 업무를 줄이려고 만든 도구에도 관리 비용이 든다는 점을 경험했고, 돌아보면 이 부분은 초기 도입 범위에서 제외해도 괜찮았겠다고 생각한다.

이렇게 마련한 환경을 바탕으로 새로 개발하는 부분부터 디자인 시스템을 적용했다. 실제 사용해보면서 빠진 부분을 보완하고, 팀이 계속 가져다 쓸 수 있도록 다듬어갔다. 그 결과 설계안에 머물렀던 디자인 시스템은 개발 프로세스에 자리 잡을 수 있었다. 이후 디자이너가 바뀌고 프로덕트의 방향도 달라졌지만, 디자인 시스템은 여러 변화 속에서도 다음 가설을 구현하고 검증하는 데 계속 활용되었다.

결과

디자인 시스템이 도입되면서 가설 검증과 무관한 디자인 디테일을 매번 새로 구현하는 일이 줄었다. 같은 기능은 기존 컴포넌트를 재사용하고, QA에서도 화면마다 미세하게 다른 값을 맞추는 부담을 줄일 수 있었다. 숫자로도 일부 변화를 확인할 수 있었다. 색상 관리 항목은 83개에서 22개로 줄었고, 글자 크기는 15종에서 4종으로 줄었다. 굵기와 줄 간격까지 제각각이던 타이포그래피는 7가지 스타일로, 간격, 그림자 그 외의 여러 디자인 요소들도 3~4개의 통일된 스타일로 줄었다.

하지만 이 숫자들 자체가 중요한 것은 아니다. 처음부터 해결하려던 문제는 색상이나 스타일을 줄이는 것이 아니라, 불필요한 업무들을 줄여 실행속도를 빨리하는 것이었기 때문이다.

그렇다면 객관적으로 실행속도는 빨라졌는가?
— 잘 모른다.

….

여태 객관성에 대한 긴 글을 적었으면서도 이렇게 밖에 평가하지 못하는 이유는 이를 객관적으로 측정하는 것은 매우 힘들기 때문이다. 물론 어느정도 수치화는 가능할 것이다. 원래 몇 개였던 QA 티켓이 얼마로 줄었다는 둥, 각 프로세스에 걸리는 작업이 몇 퍼센트 줄었다는 둥…. 하지만 그건 수치화를 위한 수치화라는 점 외에는 별 의미는 없는 것 같다. 누군가에게 있어보이려고 한 작업은 아니고, 정말 필요하다고 느껴서 한 작업이다. 그래서 있어보이려고 별 의미 없는 수치들을 늘어놓기보다는, 객관적으로 확인할 수 없는 것은 그냥 모른다 정도로 남겨두려고 한다.

하지만 그럼에도 불구하고, 결과에 대한 나의 주관적인 의견 정도는 밝힐 수 있을 것이다.

이 일이 비지니스적으로 중요했다고 생각하는가?
— 매우 그렇다.

주관적으로는 실행속도가 빨라졌는가?
— 매우 매우 그렇다.

(그리고 개발자들이 덜 화나있다.)

마치며

이 글에서는 ‘팀원으로서의 일’만 이야기했지만, 사실 회사에서 일하는 동안에는 개발자로서의 일들로 고민하던 날들도 참 많았다. 당장 해결해야 할 기술적인 문제와 빠듯한 마감일은 늘 있었고, 개발 문제를 해결하는 것 또한 중요한 일이었기 때문이다. 다만 그럴수록 잊지 않으려 했던 것은, 왜 이 개발을 하고 있는지 생각하는 일이었다.

그 질문을 붙잡고 있다 보면 내 직무 밖의 일에도 의견을 내게 되었다. 하지만 의견을 내는 것과 그것을 팀에 적용시켜내는 일은 다른 일이었다. 설명과 설득을 반복해야 했고, 그 과정이 힘들게 느껴질 때도 있었다. 같은 직무의 어려움은 함께 일하는 동료들이 알아주지만, 여러 역할 사이에 걸친 일은 누가 알아주는 일이 드물기 때문이다. 이런 일들은 대개 권한은 없고 책임과 의무만 있는 일이기 마련이다.

하지만 중요한 일이라는 건 종종 그런 특성을 가지고 있는 듯 하다. 중요한 일 중에 쉬운 일이란 없다. 그리고 사람이 빠진 일도 없다. 그래서 더 어렵고, 그래서 더 중요하다.

‘팀원으로서의 일’도 그런 일 같다.
어려운 일. 하지만 중요한 일.

어려운 일 앞에서도 항상 물러서지 않는 그런 사람이 되고 싶다는 생각을 하면서, 온아웃 회고를 마친다.