나는 그동안 무엇으로 성장했을까?

개발 어린이 시절에는 다양한 라이브러리와 프레임워크를 사용해 보는 것을 성장이라고 생각했다. 새로운 기술을 찾고, 예제 코드를 작성하고, 사용해봤다는 걸 열심히 자랑했다. 사용해 본, 또는 공부한 프레임워크의 종류는 늘어갔지만 밖에서 자랑한 것만큼 현실이 아름답지는 않았다. 여전히 내 코드는 유지보수하기 힘들었고, 버그가 많았으며, 빠듯한 일정에 허덕였다.

깊이는 제쳐두고, 넓은 폭만을 동경했다. 낯선 것에 익숙해지는 데에는 시간이 필요했다. 배운 것을 잘 쓰기 위해서는 많은 수련을 해야 한다는 당연한 사실을 그때는 몰랐다. 그냥 도구가 문제를 제대로 풀지 못한다고 믿었다. 도구를 비난하는 게 가장 쉬웠다. 이 녀석은 내 말에 대꾸를 하지 못한다.

새로운 기술을 탐닉하는 것 자체를 나무랄 일은 아니다. 열정과 호기심이 있기에 가능한 일이다. 더 나은 개발자로 성장해가는 과정의 하나이고, 스펀지처럼 빨아들일 수 있는 그때가 어쩌면 탐닉하기에 가장 좋은 때인지도 모르겠다. 경험이 쌓이면 새로운 걸 받아들이기 힘들어지기도 한다. 장점과 단점은 동전의 앞면과 뒷면이다.

API 수집가.

어쨌든 나의 개발 어린이 시절은 새로 나온 API를 수집하는 게 일이었다. 그 시절 내 관심은 오로지 코드에 머물러 있었다. 코드는 나에게 목적이었다. 코드를 어떻게 작성해야 할지, 어떤 알고리즘이 시간 복잡도가 가장 낮은지, 어떤 라이브러리가 더 예쁜 인터페이스를 제공하는지. 이런 질문을 주로 머리에 담고 살았다. 개발은 나 자신과의 싸움이었다. 나만 잘하면 되는 그런 일.

사람은 자신에게 유리한 쪽으로 현상을 해석하려는 경향이 있나 보다. 새로운 API로 팀이 겪는 모든 문제를 해결하고 싶었다. 훌륭한 개발자라면 최신의, 아름다운 논리로 무장한 기술을 당연히 칭송해야 하지 않겠는가. 그렇게 낡은 jQuery를 밀어내고 React를 도입하면 꽃길을 걸을 수 있을 거라 믿었다.

React를 공부했고, 콘퍼런스에서 발표도 했다. 발표했음을 동료에게 자랑하며 지식을 뽐냈다. 팀에 도입을 제안했다. 동료의 반응은 냉담했다. 내 말이 논리적으로 합당하고, 그걸 증명할 수만 있다면 당연히 모두가 따라줄 거라 믿었던 내 기대가 무너졌다. 사실 제대로 증명하지도 못했다. 결론을 내려놓고 근거를 가져다 끼워 맞춘 논리는 어색하기 마련이다.

기대와 현실의 간극을 동료를 비난하는 걸로 매워야 했다. 내 말을 안 들어주는 사람은 권위적인 꼰대이며, 우리 조직에는 수직적 잔재가 남아있다고 말이다. 킹왕짱 신기술 앞에 조심스러운 동료가 지나치게 보수적이라고 생각했다. 그래야 견딜 수 있었다.

한참이 지난 후 엉뚱하게 웹툰을 보다가 깨달았다. 이것이 신뢰의 문제임을.

사람을 모르고 사람과 일을 할 수는 없겠다 싶었다. 설득하고, 협상하고, 인내하는 일련의 과정을 이끌어야만 내가 원하는 것을 얻을 수 있다는 걸 경험으로 배웠다. 이 과정에서 불편한 사람과 대화도 해야 할 것이며, 다수 앞에 나서야 할 일도 있다. 때로는 내가 중요하게 여기는 것을 일부 포기하기도 해야 했다. API를 수집하는 일 외에도 알아야 할, 싫지만 견뎌야 할, 어렵지만 잘 해야 할 일이 있었다.

React가 아무리 좋은 기술이고, 내가 React를 잘 안다고 해도 이 녀석을 팀이 받아들일 수 있게 설득할 수 있는 능력이 없다면 React가 다 무슨 소용이람. 당위성을 설명하고, 일정을 확보해야 한다.

어렵사리 도입을 결정해도 꽃길만 걸을 수는 없다. 레거시 위에서 낡은 것과 새로운 것을 엮는 일의 난도는, 인터넷에 떠도는 예제를 작성하는 것에 비해 훨씬 어렵다. 옛것과 새것이 공존하는 혼란의 시기도 견뎌야 한다. 혼란에 지친 동료의 투정을 다독이며 앞으로 나아가는 가시밭길의 쓰라림은 또 어떤가.

생각이 여기에 미치니, 1차원이었던 세상(코딩)이 2차원(팀), 3차원(조직과 조직)으로 확장되어 보이기 시작했다. 제품을 개발하는 전 과정을 아우르는 모든 것들을 관심사에 담았다.

고민의 결이 바뀌었다.

얼마 전 내 페이스북 타임라인에 올라온 박성철 님의 포스트가 재밌다. 어떤 논문에 나와있는 내용을 근거로 학교와 실무에서 배우지 못해, 정작 실무에서 필요로하는 만큼 역량을 쌓기 힘든 분야 10가지를 나열하고 있다.

1. 협상
2. 인간-컴퓨터 상호작용 / 사용자 인터페이스
3. 리더십
4. 실시간 시스템 설계
5. 관리
6. 소프트웨어 비용 추정
7. 소프트웨어 지표
8. 소프트웨어 신뢰성(reliability)과 장애 내성(fault tolerance)
9. 윤리와 전문가 의식
10. 요구사항 수집/분석

모두 다 제품을 잘 만들기 위해서 우리가 챙겨야할 것들이다. 물론 한 개인이 모든 방면에서 뛰어나기는 어렵다. 그게 사람이기에 사람은 분업을, 더 나아가 협업을 한다.

어쨌든 이런 내용은 종합적으로 엮어서 체계적으로 가르쳐주는 데가 없다. 더군다나 나처럼 인문학도에, 비전공자인 경우는 아예 이런 주제가 있다는 걸 모르고 사는 경우도 많다.

운이 좋았다. 복잡한 조직에서, 복잡한 제품을 만들며, 복잡한 문제 속에 놓여있었기에 자연스레 이런 주제에도 관심을 가질 수 있었다. 체계적으로 배울 수 있는 곳이 없었기에 인터넷에 떠도는 글을 찾아서 읽거나, 선배에게 조언을 듣거나, 파편적으로 책을 찾아서 보고 얻은 지식을 연결해서 패턴을 찾았다.

하지만 배운 내용을 하루 아침에 실전에서 발휘할 수는 없었다. 리팩터링 책을 아무리 읽고 읽어도 도대체 어디에 써먹어야 할지 알 수 없듯이. 프레젠테이션 교육을 받았다고 내일 당장 내가 스티브 잡스가 될 수는 없듯이.

읽어둔 이론을 토대로 현실과 이론 사이의 연결고리를 찾고, 현실에 조금씩 적용해나가며 경험치를 쌓았다. 물론 경험이라는 것 또한 단순히 쌓는 걸로 체득되지는 않았다. 경험은 애써 잡아두지 않으면 흩어져서 사라져버린다. 뒤를 돌아보고 개선하고 시도하고 다시 반복하는 과정. 이게 없으면 흔히 농담으로 말하는 나이(연차)를 똥으로 먹은 사람이 되기 쉽겠더라.

어제를 돌아보며 경험을 체계화하고 개선하는 사이클을 반복했다. 조금씩 아는 것들이 생겼고 나아졌지만 때로는 미친 척하는 용기도 필요했다. 확신하기 어려운 일을 동료들 앞에 서서 해보자고 제안할 때면 그냥 혼자 코딩하던 시절이 그리울 때도 있다. 사람들 앞에 서는 순간이면 숨이 가빠진다. 그걸 견뎌야만 원하는 걸 얻을 수 있었기에 참고 있을 뿐. 다행히도 견디다 보니 조금은 무뎌지더라.

작년에 팀에서 성장에 대해서 설문조사를 한 적이 있다. 개인의 성장과 조직의 성장 사이의 간극을 찾고 서로의 목표를 최대한 맞춰보려는 시도였다. 그러기 위해서는 저마다가 생각하는 성장의 의미를 읽어야만 했다. 질문을 받았지만 선뜻 답이 나오질 않았다. 진지하게 고민해본 적이 없었다.

언젠가 팀의 업무 프로세스를 개선하려고 사용자 스토리를 도입할 것을 제안했던 적이 있다. 이 제안을 하기 위해서 같은 책을 5번은 읽었고, 관련 글을 인터넷에서 20개도 넘게 찾아서 읽었으며, 의도를 설명하는 전체 메일을 3번은 쓴 것 같다. 위키를 2번 정도 작성해서 공유했으며, 모든 동료가 모인 자리에서 2번이나 설명을 했다. 아니 3번이었나?

어쨌든. 물론 개인 대 개인으로 자잘하게 설명한 경우는 더 많다. 이제는 모두 이해했을까 싶었을 때 누군가 내게 물었다.

"스토리 포인트가 꼭 필요한가요?"

.

.

.

이제 와서 돌아보니 더 나은 방향을 찾아서 동료와, 리더와, 제품과, 코드와 투닥거리는 이 모든 과정이 성장이었더라.

오늘 나에게 누군가 성장이 무어냐고 묻는다면, 다양한 사람의 의지가 뒤섞이는 개발이라는 큰 운동장에서, 본인의 역할을 질문하고 찾아가는 과정이라고 답하고 싶다.

직업 전문인으로서, 개발자에게 코딩은 목적이 아닌 수단이어야 한다는 꼰대 아닌 꼰대 같은 생각을 가끔 한다. 개발이라는 더 큰 관점에서 자신의 업무를 돌아보면 좋겠다. 나를 보고, 동료를 보고, 조직을 보고, 제품을 보고, 일이 흘러가는 흐름을 보자.

모두가 그 안에서 자신의 가치를 찾을 수 있기를 바라며.