이상과 현실

회사를 차렸다. 그리고 드디어 회사에 개발자를 채용했다.

내 생각엔 이제 개발자가 출근하면 멋지게 자리에 앉아서 검은 창에 멋들어진 키보드로 현란한 타이핑을 하며 개발을 쭉쭉 이어가 줄 것 같다. 하지만, 그의 대부분 일과 중에서 코드를 짜는 시간은 그렇게 많은 비율을 차지하지 않는다. 대부분은 키보드 소리 좀 나다가 한숨 쉬다가 클릭 소리 좀 나고 그렇다.

뭐, 생각 했던 모습이 아니라서 약간 불안하긴 하지만, 이제 업무 지시를 해보자.

장팀장, 우리 이 기능 이렇게 좀 바꿔봐요.

어... 그거, 제 생각에는 안 바꿔도 될 것 같은데요?

뭐 좀 바꿔 달라고 하거나 기능좀 만들자고 하면 그걸 왜 그렇게 해야 하는지 되려 칼 같이 다시 질문으로 돌아온다.

"왜 그거 바꿔요?"

"그냥 이렇게 하면 안 바꿔도 될 것 같은데요?"

아니, 좀 그냥 해주면 좋겠는데 도대체 왜 개발자는 자꾸 안 된다고 하고, 또 그렇게 안 해도 된다고 할까?

개발자는 코드만 짜는 사람이 아니다

당황스러울 수는 있겠지만, 개발자 입장에서도 어쩔 수 없이 물어볼 수 밖에 없다. 그냥 하라는 대로 하면 오히려 쉽지만, 되려 왜 그렇게 해야 하는지 물어보지 않는 사람이 그 자리에 앉아있다면 나중에 공포스러운 일들이 벌어질 수도 있다.

개발자는 문제 해결을 꼭 코딩으로만 하지 않는다 물론 다른 직무를 담당하는 사람들도 그럴 것이다. 문제를 해결하는 더 좋은 방법이 있으면 경제적으로 선택한다. 혹여나 그 방법이 꼼수일 수도 있다. 하지만 꼼수라도 훌륭하게 문제를 해결하는 방법이라면 선택 할 수도 있다. 굳이 프로그래밍이어야만 할 이유는 없으니까.

질문을 다시 던지는 이유

개발자 입장에서, 잘 돌아가고 있는 프로그램이 있는데, 갑자기 중대한 의도하지 않은 버그가 아닌 이상, 그냥 기능을 바꿀 이유가 전혀 없다. 성능 개선이 필요하거나, 소프트웨어의 특성 때문에 계속해서 보수를 하지만, 개발자 타이틀을 빼고 생각 해보자.

가령, 굉장히 화면이 복잡한 SAP, ERP, 혹은 단순하지만 자주 사용하는 애플리케이션이 있다고 하자. 쉽게 쓸 수 있게 하자고 화면의 진입 위치만 바꾸더라도, "그 자리에 그 버튼이 없어서" 벌어지는 UX 의 참사만 생각해도 아찔해 진다.

화면의 요소만 해도 그러한데, 제품의 중대한 기능을 바꾸거나 한다면, 문제 해결 방법이 그거 밖에 없는지, 왜 그렇게 해야 하는지 당연히 물어볼 수 밖에 없다. 개발자 보다는 사실 문제 해결사에 가깝게 일하는게 대부분의 개발자의 역할이다.

문제 해결에 익숙한 사람

개발자는 계속해서 문제를 해결하는 사람이다. 제품에서 발생하는 이슈 부터, 코드 단위, 프레임워크 단위 이슈일 수도 있다. 요즈음엔 서로의 영역을 넘나드는 관계를 이해하고(가령, 요즘 클라우드 지식이 필수가 된 것 처럼) 복합적으로 해결해야 할 때도 있다.

같은 논리로, 문제를 다른 관점에서 바라보거나 거시적으로, 또는 미시적으로 바라보는데도 익숙하다. 예시로 OTIS(엘리베이터 브랜드)의 문제 해결 예를 들어보고 싶다.

엘리베이터는 엄청 느렸고, 고층 빌딩 이용자의 불만은 폭주했다.

엘리베이터 속 거울 이야기 - 문제 해결에 대한 다른 시점의 솔루션 만들기

• 문제 : 엘리베이터 속도가 너무 느려서 기다리느라 불만이다.
• 해결책 1 : 엔진을 개발해서 엘리베이터 속도 자체를 빠르게 만들자!
• 해결책 2 : 엘리베이터 기다리는 시간을 오래 걸린다 생각하지 않게 만들자!

개발자가 해야 할 것 같은 접근은 1번이다. 실제로 개발자가 매일 하는 일이다. 제품을 개선하고, 더 좋게 만들려고 노력한다. 이런 이슈는 루틴하게 개선하고 보완하면서 해결 되는 속도 보다 훨씬 빠르게 생겨나고 빠르게 해결해야 하지만 굉장히 어렵고 골치 아프다.

근본적인 해결책은 1번이다. 시간과 비용이 얼마 들지 모르는 모험을 해야 한다. 엔진 부터 개선하고, 기술을 새로 개발해야 할지도 모른다. 비슷한 느낌으로 제품에 이슈가 발생해 개발자에게 근본적인 해결책을 부탁하면, 기약 없는 일정과 비용을 말할 것이다. 그리고, 그 해결책이 준비되는 와중에 더 많은 이슈들도 발생할 것이다. 기간은 더 늘어나고 비용도 정비례 한다.

문제를 좀 더 비틀어서 생각해 보자. 정말 엘리베이터 사용자들이 엘리베이터의 속도가 느려서 불만이었을까? 아마도 당시의 엘리베이터 속도는 한계가 있었을 거니까 어떤 제품이여도 비슷했을 것이다.

현장에서의 VOC는 "엘리베이터는 느리고 답답하다" 라는 느낌이었다. 실제로 느린고 빠르다는 상대적인 느낌이고, 경험이다. 엘리베이터 속도 자체가 지금 보다 빨라져도 획기적으로 개선이 되지 않는다면 여전히 느리다고 생각하는 사람들도 있을 수 있다.

그리고 누군가는 말했다. "기다리는 시간이 지루해서 그럴 수 있으니 거울을 놓아보자!"고. 그렇게 문제가 해결되었다. 더 이상 지루하지 않게 엘리베이터를 기다릴 수 있으니까.

경제적인 방법으로 문제 해결하기

게으르게 보여도, 문제를 잘 해결하고 성과를 계속해서 잘 내는 개발자가 있다면, 문제를 쉽게 해결하기 위해 부던히 노력하고 다각도로 분석했을 거라 생각한다. 이런 모습이 내가 지향하는 방향이다.

개발자는 IT에 가까운 문제 해결하는 사람이라 생각한다. 그냥 프로그램 만드는 사람 쯤으로 쓰려 한다면, 능력의 30% 도 쓰지 않는 상황일 수 있다. 문제는 경제적으로 해결하는 게 제일 좋다. 물론 장기적인 목표로 KPI를 잡고 개선하는 건 필수이다. 하지만 요즘의 시장은 흐름도 빠르고, 자원도 넉넉치 않기 때문에 LEAN 하게 대응해야 한다.

개발자들이 요청하는 것들을 다 바꾸고 만들 수는 있겠지만, 계속해서 다른 방법은 없는지, 근본적인 이유가 뭔지 물어보고 빠르게 해결 할 수 있는 방법을 제시하는 것도 이런 논리이다. 개인적으론, 아직도 개발자는 커뮤니케이션 하기 어려운 포지션이라는 인식에서 자유롭진 못한 것 같은데, 서로 대화를 하면 할 수록 시너지가 나는 아주 중요한 포지션이라 생각한다.

기회비용

만약, 다시 돌아가 별 대꾸 없이 하라는 대로 했다고 생각해 보자. 불행하게도 개발은 방향이 바뀌게 되면 아주 큰 기회비용이 발생한다. 개발자가 "진작 그렇게 된다고 알려줬으면 좋을텐데. 이제 바꾸려면 좀 더 걸려요." 라고 말하는 걸 한번쯤 들어봤을 것이다.

엘리베이터의 사례를 들어보자. 바라는 대로 속도를 빠르게 만들었는데 안전 문제가 생기거나 너무 빨라서 사용하기 힘들 경우에는 또 다른 기회비용이 발생한다.

그래서 시장의 반응과 고객의 의견이 어떤 걸 의미하는지 문제의 진짜 속내를 파악하려 노력하고 서로 의견을 자주 나누는 게 중요하다. 누군가는 분명 거울을 달자는 얘기를 듣고 "얘 또 일하기 싫으니까 딴생각하네" 하고 지나갈 수 있겠지만, 결론적으론 당시에 많은 자원을 벌 수 있게 한 아이디어였을 것이다.

개발자들은 기회비용을 많이 따져 볼 수 밖에 없다. 잘 쓰지 않는 기능도 나중에는 쓸 것 같으니 넣어달라는 주문이 그렇지 않아도 많고, 돌아가고 있는 제품이 문제가 생기지 않게 계속해서 가꾸는 일도 게을리 하면 안된다.

개발하지 않고 비용으로 대체할 수 있는 많은 방법들도 있다. 구독형 서비스를 이용하거나(가령, SMS나 이메일을 보내는 서비스를 우리 자체적으로 만들 수도 있지만, 클라우드에서 구독형 서비스로 제공하거나 다른 서드 파티 업체에서 쉽게 쓸 수 있게 제공하는 경우가 많다.), 정책적으로(특정 부분은 품이 많이 들지만 데이터가 모이기 전까지 우리가 하자!) 해결할 수도 있겠다.

만들기 전에는 수정하고 바꾸기가 비교적 쉽지만, 서비스가 운영되는 순간부터는 운영과 개발이 동시에 관심사가 되기 때문에 생기는 기회비용도 크다. 당장 라이브 되고 있는 서비스의 스펙이 바뀌게 되면 사이드 이펙트들이 발생할 수 있기 때문이다.

결제를 한번만 받는 단일 결제 방식에서 구독 방식으로 바뀐다면? 기존 고객들을 대응하는 서비스와 새로운 고객에 대응하는 서비스 2개가 돌아야 할 것이다. 돈 받는 일이 뭐 크게 달라지냐 싶지만, 결제일 계산 부터 실패 시나리오까지 복잡도가 기하급수적으로 늘어난다. 배포와 패치, 그리고 실시간 처리를 신경써야 한다면? 더더욱이다.

부록 : 아무 일도 없어야 월급 값어치를 하는 경우

해달라는 건 안 해주고 맨날 바쁜척만 하는 것 처럼 보일 수도 있겠지만, 아무 일도 없게 하는 게 더 어려운 경우들도 있다. 프로그램들은(웹 서비스나 애플리케이션도) 소프트웨어라는 닉값 하듯 주변 환경이 바뀌면 계속해서 관리해 주어야 기본 동작을 한다.

안드로이드나 iOS, Windows나 OSX 같은 운영체제들은 계속해서 업데이트를 하고 있고, 그 위에서 돌아가는 프로그램들도 대응을 해야 할 때가 있다. 멀쩡한 프로그램들이 운영체제 업데이트 이후에 정상적으로 안 돌아가는 경우가 있을 것이다. 바로 그 문제이다.

정책 변경으로 인해 현상유지를 하기 위해서 작업해야 하는 경우도 있다. 지금은 당연하지만 소셜 로그인을 사용할 경우, 애플은 애플 ID를 지원하지 않으면 애플리케이션 심사에서 반려된다. 잘 운영하고 있던 서비스가 정책 변경으로 인해 작업할 내용이 생기는 것이다.

게으른, 게으르게 보이는 실력 있는 개발자가 되고 싶다

개발하지 않는 게 제일 나은 경우가 생각 보다 많다. 오히려 그냥 시키는 대로 개발하는 게 더 마음이 편할 때도 있다. 하지만, 개발이 아니라 문제 해결로 현상을 바라보면서 부터 마음이 복잡해진다. 미래에 이 기능을 유지보수 해야하는 동료나 미래의 내가 욕하는 상황은 아니였으면 한다. 최신의 기술과 근본적인 문제 해결은 아닐지라도, 지금 상황에 맞는 기술과 문제 해결 방법을 택하려 노력하는 게으르고 바쁜 개발자가 되고 싶다.

일 하기 싫어서 별 논리를 다 펼쳐보았다. 사실 천재 개발자들은 이미 다 근본 원인 해결하고 퇴근했을듯.