개발자의 언어
지난 주에 커뮤니티 이벤트를 갔었는데 네트워킹 시간에 어떤 개발자 분이 이런 질문을 했다. “나는 신기술을 도입해보고 싶은데 사업, 동료가 나서주지 않아요. 너무 지치고 힘든데 이럴 때 어떻게 해야할까요?”
나는 비유하는 걸 좋아하니 이렇게 이야기해보자. “역 앞에 새 식당이 생겼는데 동료가 같이 가주지 않아요. 저는 꼭 가서 먹어보고 싶은데 어떻게 해야할까요?”
새로운 것이 항상 좋다고 할 수는 없다.
새로운 제품은 대부분 기존 제품이 가지고 있던 문제를 해결하기 위해서 나온다. ‘기존 제품의 이런 점이 어려웠으니 이번 제품에서 해결하자’ 또는 ‘전세계의 트렌드가 이런 방향이니 우리도 이렇게 하자’ 등 다양한 문제를 해결하기 위해서 새로운 제품이 나온다.
얼마 전에 iPhone 11이 나왔다. 나는 iPhone 11이 구매하고 싶고, 나의 현재 휴대폰 사용 경험은 아래와 같다.
- 지난 일주일간 나는 하루 평균 3시간 10분 휴대폰을 사용했으며,
페이스북과 사파리에 가장 오랜 시간을 사용했다. - 음식 사진을 찍을 때 휴대폰을 주로 사용한다.
찍은 사진은 트위터나 인스타그램에 올리는 편이다. - 기존에는 iPhone XS Max를 사용했고, 특별히 불편한 점은 없다.
자 그러면 나는 iPhone 11을 사야할까? 아니면 기존 휴대폰을 사용해도 될까? iPhone 11이 새로운 카메라와 새로운 디스플레이를 가지고 있고, 대부분의 기기 성능에서 iPhone XS Max보다는 좋을 거라 확신한다.
하지만, 내 휴대폰 사용 경험을 봐서는 굳이 iPhone 11을 살 필요는 없어보인다. 오히려 휴대폰 한 대에 170만원을 들이는 것보다는, 그 돈으로 다른 나라에 여행을 다녀오는 게 나에게는 더 가치 있을 가능성이 높다.
하지만 나는 iPhone 11을 살 것이다.
길게 바라보면,
단순히 스펙을 길게 나열하는 것 말고도, 인간의 만족도를 높이는 것도 중요하다. 첫 문장에서 이야기 한 ‘새 식당’ 에 대해서 이야기해보자. 왜 기존에 있던 이른바 검증된 식당을 두고 새로운 식당을 찾아갈까? 아래는 철저히 내 기준이다.
- 미지에 대한 기대감. 이 식당이 맛있을 수도 있다.
- 선택의 다양성. 다음에 점심 메뉴를 고를 때 후보지가 추가된다.
- 선구자라는 자부심. 내가 이 집 뚫었다.
- 주변 사람들의 만족. 내가 추천했는데 다른 사람들도 맛있대.
- 기존 집에 너무 익숙해져서. 맛있는데 너무 뻔해
제일 중요한 건 5번이라고 생각한다. 아무리 맛있는 집이라도 여러번 가다보면 질리기 마련이다. 만약 일 년 내내 같은 식당에 가서 비슷한 메뉴로 밥을 먹어야한다고 생각하면 벌써 지루해지는 느낌이다.
하지만 개발 세상에서는 이런 일이 꽤 흔한 일이다. 검증된 기존 기술을 계속 사용해나가면 개발자의 만족도는 낮아질 수 있지만 결국 제품은 맛있어질 가능성이 높다. 우리가 백종원의 레시피를 따르는 것은 그 맛이 아주 뛰어나서가 아니라 우리가 따라할 수 있는 범위에서 최대의 맛을 내는 것과 유사하다.
하지만 개발자의 만족도가 낮아지는 건 길게 보면 손실이다. 개발자의 만족도가 높아질 수록 해당 제품에 개발자의 에너지를 더 많이 사용할 가능성이 높아지고, 더 많은 에너지를 사용하는 건 제품의 완성도, 제품의 완성 속도와 이어지기도 한다.
다른 사람을 설득시켜보자
새로운 식당에 다른 사람을 데려가보고 싶다. 여러분들이라면 어떻게 하겠는가?
- 블로그를 열심히 찾아서 그 집에 대한 리뷰를 살펴보고,
맛있다는 리뷰가 많으면 데려간다. - 일단 혼자 가서 먹어보고, 먹어본 메뉴가 괜찮으면 다른 사람을 데려간다.
- 무작정 가자고 한다. (보통 실패한다)
나는 보통 2번을 가장 선호하는 편이다. 내가 새로운 기술을 도입하고 싶을 때에는 보통 새로운 기술을 이용한 프로토타입을 만들어보고, 이 기술이 우리가 가지고 있는 문제를 해결할 수 있는 지 검증해보고, 검증이 끝나면 사람들에게 공유한다.
1번은 2번의 전 단계일 때도 있고, 후 단계일 때도 있다. 지나가다가 발견한 집인데 새로 생긴 지 얼마 안되었다면 블로그 글이 많지 않아서 일단 가보고 맛있는 지 체크해본다. 내 입맛에는 별로였는데 맛집이 되는 경우도 있더라.
하루에 세끼를 먹는다고 생각하고, 180번 밥을 먹어야한다고 가정했을 때, 그 중 한 번을 설득하는 데에도 이렇게 어려운 데 한번 바꾸고 나면 바꾸기도 어려운 기술에 대한 이야기를 할 때는 얼마나 더 어렵겠는가?
따라서 프로젝트 중 꾸준한 검증이 필요하고, 검증을 거쳐 이 기술이 기존 문제를 해결할 수 있다는 확신이 생겼을 때 이 기술을 도입할 수 있어야 한다. 여기서 중요한 건, 기존 것이 절대적으로 별로라고 생각하면 안된다는 것이다.
그러면 이제 아래 질문에 답변해보자.
- 이 기술은 왜 생겨났는가?
- 이 기술은 어떤 문제를 해결하기 위해 있는가?
- 이 문제는 지금 우리 조직이 가지고 있는 문제인가?
- 이 기술은 지속적으로 업데이트가 이루어지고 있는가?
- 이 기술을 우리가 쓰면 어떤 점이 좋아지는가?
- 이 기술을 우리가 쓰면 어떤 점이 나빠지는가? (교육비용은 제외하고)
- 이 기술이 우리의 만족도를 높여주는가?
자, 이제 에디터에서 현실로 나설 차례다. 현실의 사람들을 설득시킬 많은 자료들을 준비하고, 새로운 기술을 서비스에 도입해보자.
