개발자라는 업의 본질
요즘 개발자라는 직업은 무슨 직업일까에 대해 종종 고민하곤 한다. 취미 수준에서의 개발을 하던 때에서 벗어나 돈을 받고 일하는 개발자로서 내가 제공해야 하는 가치가 무엇일까, 무엇을 더 잘해야 할까에 대한 고민 탓이다.
업의 본질이라는 추상적인 말보다 실제로 개발자가 하는 작업들이 뭔지를 생각해보자. 보통 소프트웨어 개발을 한다고 말하는데, 실제로는 소프트웨어 개발 내에 다양한 작업들이 포함되어 있다. 현실 세상을 모델링하고, 코드를 작성하여 모델링 된 문제를 컴퓨터가 풀 수 있게(계산할 수 있게) 만들고, 코드를 유지 보수할 수 있게 문서화하고, 코드가 실행되는 컴퓨터 또한 유지 보수한다. 이 외에도 다양한 작업들이 있을 것이다. 보통 개발자가 하는 일을 코드 작성 위주로 많이 이야기하는데 실제로는 코드를 작성하는 것보다 다른 것에 더 많이 시간을 쓴다고 할 정도이다.
컴퓨터를 아주 손이 빠르지만 외계어를 쓰는 생물체 정도로 바꿔서 생각해보면 이해가 더 잘 될 것 같다. 어떤 마트의 주인은 계산대에서 사람들이 오래 기다린다는 것을 알고 이 외계 생물을 통해 빨리 결제를 할 수 있게 해야겠다는 결정을 했다. 문제는 외계 생물이 쓰는 언어를 모르니 일을 시킬 수가 없다. 그래서 개발자라는 사람을 통해 통해 물건 값의 총합만큼 결제하는 작업을 외계 생물에게 시켜달라고 한다. 개발자는 외계 생물이 알아들을 수 있는 언어로 번역을 해서 일을 시킨다. 물건이 오면 물건 가격을 확인한다, 가격을 하나씩 더해서 총합을 구한다, 현금을 받는다, 거스름 돈을 계산한다, 거스름 돈을 돌려준다와 같은 식이다. 나중에 이 생물이 하는 일을 다른 개발자가 와서도 이해할 수 있게 하기 위해 외계어와 함께 사람의 언어도 써둔다. 그러고 얼마 뒤, 마트 주인은 할인 쿠폰을 발행하여 모객을 더 많이 해야겠다는 결정을 한다. 외계 생물은 아직 할인 쿠폰을 어떻게 적용해야 하는지 모르기 때문에 개발자를 통해 할인 쿠폰이 적용된 물건 값을 계산할 줄 알도록 업그레이드한다.
마트 주인은 당연히 마트의 매출이 증대되고, 지출을 줄여서 수익을 늘리길 원한다. 10명의 계산원을 고용하는 것보다 1명의 개발자와 외계 생물을 통해 동일한 물건 값 계산 일을 할 수 있다면 인건비가 많이 줄어드므로 수익이 늘어난다. 이제 고객의 입장에서 생각해보자. 사실 고객 입장에서는 물건 값이 빠르게 잘 계산된다면 계산대에 사람이 있던 외계 생물이 있던 상관이 없다. 사람이 주판을 튕겨서 외계 생물보다 빨리 계산할 수 있다면 사람을 더 선호할 것이다. 좀 더 정감 가고 익숙한, 그리고 말로 대화가 통하는 사람이 더 편하니까. 하지만 사람 대신 외계 생물을 고용해서 마트의 인건비가 절감되어 물건 값이 저렴해진다면 그것 또한 좋아할 것이다. 이처럼 회사에서 소프트웨어를 개발하고 운영하는 것은 고객이 소프트웨어를 좋아해서가 아니라 소프트웨어를 이용하여 더 효율적으로 서비스를 운영할 수 있는 경우가 많기 때문이다.
예전에 배달 음식 주문 서비스 초창기 이야기를 들은 적이 있다. 초창기에는 배달 주문 자동화 시스템이 개발되기 전이어서 사용자의 주문을 받는 콜센터가 있고 콜센터에서 배달 업체에게 주문을 전달해주는 식이었다고 한다. 요즘 시대에 저런 식으로 서비스를 운영하는 곳이 있냐며 웃는 사람들도 있었지만 어쨌든 고객이 원하는 핵심 가치인 배달 음식 주문은 잘 됐었다. 물론 지금은 자동화 시스템이 개발되어 중간에 사람이 끼지 않고도 배달 음식점에 주문이 잘 접수되고, 고객은 여전히 편하게 잘 이용한다.
고객 입장에서 배달 주문 시스템이 얼마나 깔끔하게 구현되어 있는지는 전혀 관심이 없을 것이다. 그저 내가 한 주문이 누락 없이 잘 전달이 되고, 내가 주문하고 싶을 때 잘 주문 접수가 되면 된다. 실제로는 월드컵 경기 등 특수한 상황에서 많은 주문이 갑자기 몰릴 때 문제가 발생할 수 있지만 그런 경우에도 주문이 잘 처리돼야 한다. 하지만 고객은 시스템이 얼마나 복잡한 코드로 만들어져 있고, 고도화되어 있는지는 알고 싶어 하지 않는다. (물론 나는 개발자니까 알고 싶어 한다.)
이렇게 생각을 정리하다 보니 개발자의 업의 본질은 외계어인 프로그래밍 언어를 잘 다루는 것보다 "컴퓨터를 이용하여 고객에게 가치를 전달하는 것"이 아닌가 싶다. 물론 고객에게 가치를 전달하는 과정에서 여러 부침이 있기 때문에 모델링을 잘하고, 코드를 잘하는 등의 능력과 노력이 필요하지만 그것은 가치를 전달하기 위한 과정인 것이지 목적은 아니어야 한다. 코드를 잘 짜기 위해 가치 전달을 하지 못하고 있으면 안 된다. 혼자서 시스템을 열심히 고도화시켜나가고 있어 봤자 고객에게 가치를 전달하지 못하면 무용지물이다.
제품 개발팀은 점점 커져가기 마련이다. 그러다 보니 고객에게 가치를 전달하기 위해 여러 사람들과 협업해야만 한다. 또한, 팀이 커져갈수록 구두로 설명하는 것보다 문서로 전달해야 하는 상황이 많이 생긴다. 그런 상황에서 말하기, 글쓰기와 같은 커뮤니케이션 능력이 좋을수록 유리할 수밖에 없다. 내 의견을 더 잘 주장하고, 효과적으로 전달할 수 있기 때문이다. 또한, 협업이라는 것 자체가 사람 간의 커뮤니케이션이 받쳐줘야 하는 일이기 때문에 개발자에게 커뮤니케이션 능력을 요구하는 것도 당연하다. 그러므로 커뮤니케이션 능력이 좋은 개발자는 과거에도 그래 왔고 앞으로도 계속 사랑받을 것이다.
행동력 또한 중요하다. 앞서 이야기한 것처럼 고객에게 가치 전달은 하지 못한 채로 혼자 방망이 깎는 노인처럼 코드만 깎고 있어 봤자 소용없다. 물론 아름다운 코드로 개발하여 문제를 일으키지 않는 소프트웨어를 개발하는 것은 멋진 일이지만 가치를 전달하지 못하는 소프트웨어는 무용지물이다. 당장 고객에게 가치를 전달하는 코드를 작성하는 것뿐만 아니라 반복되는 작업들을 자동화하는 것은 생산성을 향상해서 결과적으로는 고객에게 더 가치를 잘 전달하는데 도움된다.
너무 당연하고 널리 쓰이는 말이지만 문제 해결 능력도 중요하다. 대체 문제 해결 능력이 무엇인가는 또 하나의 굉장히 복잡한 주제이지만 여기서는 가성비의 영역을 말하고 싶다. 나도 가끔은 정말 좋은 문제 해결 방법을 적용하고 싶어서 비용이 더 많이 드는 선택을 하거나, 잘 해결하기 싫어서 임시 처방을 하는 유혹에 끌리곤 한다. 상황에 맞게 적절한 수준의 처리가 무엇인지 고민하는 것은 정말 중요하다 생각한다. 엔지니어링의 본질은 가성비인데, 가성비가 안 나오는 작업을 하게 될 수도 있기 때문이다. 개발을 하다 보면 주로 추상화의 영역에서 이 문제가 발생한다. 얼마나 추상화를 해서 작업할 것인지가 항상 고민되는데, 아직 많은 케이스를 알지 못한 상태에서 추상화를 했다가 오히려 시간 낭비를 하게 되는 경우가 종종 발생하기 때문이다. 아직 나도 이건 명확한 규칙보다는 감에 의존한다. 경험이 쌓여감에 따라 이 감의 정확도가 올라가는 것 같다는 게 그나마 다행이다.
지금까지 개발자라는 업의 본질과 내가 더 잘해야 할 일들이 무엇인가에 대해 구체화해봤다. 커뮤니케이션 능력, 행동력, 문제 해결 능력 모두 새로운 이야기는 아니었다. 개발자에게 중요한 역량이 무엇인지 논하는 글들은 이미 많고, 항상 다뤄지는 주제이니까... 새로운 주제는 아니었지만 내 생각을 구체화했다는 것에 의의를 두고 글을 마무리해본다.
