개발 엘리트주의

장인 정신 내려놓기

며칠 전 친구랑 재밌는 얘기를 나눴다. 개발자지만 기획도 겸하는 친구인데 처음으로 직접 신규 기능을 기획하는 업무를 맡게 됐다고 했다. 친구가 생각하기엔 단순한 기능이라서 큰 어려움이 없을 것이라고 판단했다. 그래서 출시 일정도 단축하고 개발 기간도 짧게 잡았다. 그런데 진행해 보니 생각한 기간보다 2배 넘게 소요했고 (말 안 듣는 개발자들 데리고 일하느라) 생고생을 했다고 한다.

같이 일하는 개발자들은 예상보다 더 많은 시간을 요구했다. 물론 기획단계에서 예상한 것보다 시간이 더 필요한 경우도 있다. 기존 로직 자체가 복잡하게 꼬여 있거나 확장성을 고려하지 않은 코드였다면 단순한 기능을 구현하는 것도 쉽지 않다. 나도 여러 번 경험해 본 일이라 이해하지 못하는 건 아니다. 하지만 친구가 개발자이기도 했고 관련 로직도 경험했기 때문에 나는 친구의 말에 신뢰가 갔다.

친구가 회의시간에 오고 갔던 대화를 알려줬다. 개발자들이 간단한 Parser 만드는데 일주일을 요구했다고 한다. 듣고 나니 무슨 갈등이 오고 갔는지 짐작할 수 있었다. 빨리 피드백을 받고 싶어 하는 기획자와 100점짜리 프로덕트를 만들고 싶어 하는 개발자 간의 첨예한 줄다리기였다.

개발 세계에선 똑같은 기능이라도 만드는 방법이 수십 가지다. 가장 간단한 방법은 기능 그 자체만 구현하는 것이다. 소위 말해 동작만 하는 코드다. 그런데 동작만 하는 코드는 빠르게 개발할 수 있지만 코드가 단순하기 때문에 수정할 때 어려움이 생긴다. 그래서 개발할 때는 추상화를 적절히 활용해 변경용이성도 함께 생각해서 개발한다.

때로는 테스트 코드를 만들기도 한다. 일하다 보면 기능을 변경하기 위해 동작하는 코드를 수정하는 경우가 종종 생긴다. 그런데 원래 문제없이 동작하던 기능이 수정사항을 배포한 다음 갑자기 안 되는 문제가 생길 수도 있다. 이때 미리 작성한 테스트 코드를 실행해 보면 예상치 못하는 버그를 사전에 찾아낼 수 있다.

어떤 상황에서도 대처가 가능한 코드. 이것이야 말로 100점짜리 프로덕트다. 장인정신이 있는 개발자라면 누구나 완벽한 코드를 만들고 싶다. 나도 친구랑 일하는 개발자들의 심정을 충분히 이해한다. 그런데 장인정신이 투철하면 문제가 생긴다.

기획의 입장에서는 빠르게 기능을 배포하고 유저의 피드백을 받는 과정이 중요하다. 그래야 다음 전략을 세우기 쉽다. 그런데 유저와 맞닿아 있는 부분이 빨리 바뀌지 않는다면 기획 입장에선 난감할 따름이다. 마치 머리는 활발하게 움직이는데 손발이 마비된 느낌이다.

개발자에겐 장인 정신이 깃든 코드가 중요하겠지만 기획의 입장에선 개발자들이 내세우는 가치에(변경용이성, 테스트 코드) 공감하기 쉽지 않다. 오히려 전문 용어를 남발하며 개발 일정을 쥐락펴락하는 것이 개발 권위의식으로 보이기도 한다.

과거에 나는 기획과 개발 사이에서 무조건적으로 개발자의 편이었다. 솔직히 말하면 ‘감히 개발자의 말을?’ 같은 심보가 없었던 것도 아니다. 나도 개발 엘리트주의에 빠져 있었던 것 같다. 그런데 기획에 직간접적으로 참여해 보면서 이젠 중립을 지키게 됐다. 장인정신이 깃든 코드라도 누군가는 사용해야 의미를 갖게 되는 것을 깨달았기 때문이다.

서비스 성공이라는 공동의 목표를 두고 있는 만큼 기획과 개발 모두 적절한 유연성을 갖는 태도가 필요하다. 특히 개발자는 장인 정신을 조금 내려놓을 필요가 있다. 몇몇 개발자의 경우 책에서 배운 내용이나 트렌드를 무조건적으로 신봉하는 태도가 있는데 그게 반드시 정답은 아니라는 것을 깨달을 필요가 있다. 나의 장인 정신이 누군가에겐 고집일 수도 있다.