개발자 그 위대함에 대하여…(기획자 관점)

최근 회사에서 운영중인 Docswave라는 서비스를 새로 업데이트했다.

말이 업데이트지 서비스를 새로 만든 것이라고 보면 된다. 물론 기획서도 처음부터 다시 작성했다. ERD도 완전히 변경되었고 디자인/UI도 처음부터 끝까지 새로 작업했다. 게다가 기능들도 많이 추가되었고 다국어도 제공한다.

우리팀은 이 모든 작업을 약 3개월만에 완료했는데 나는 기획자로서 지금까지 내가 기획한 서비스들 가장 빠른 속도로 기획서를 작성했고 UI에 가장 많이 신경썼다. 물론 우리 개발자들도 아마 그들의 인생에서 가장 빠르고 힘들게 코딩한 기간이었을 것이다.

이 힘든 과정에서 내가 알게 된 개발자들의 위대함(?)을 기획자의 관점에서 이야기 하고자 한다.

기획자에게 좋은 개발자란?

대부분의 기획자들은 에러없이(혹은 에러가 굉장히 적은) 개발하는 개발자와 일하기를 원한다. 솔직히 나도 그랬다. 그런데 그런 개발자가 얼마나 있을까? 그리고 짧은 시간내에 빨리 개발해야 하는 한국 개발자들에게 에러없이 개발할 수 있는 환경은 주어지지 않는다. 이번 업데이트 된 Docswave도 운영서버에 배포 전까지 엄청난 에러가 있었다. 우리는 프로젝트 툴로 JIRA를 사용하는데 JIRA에 등록된 에러 항목이 600개를 넘어섰다. 심지어 마이그레이션에도 진행을 했기 때문에 우리가 모르는 문제가 분명 발생할 소지가 있었다. 그런데 업데이트 버전을 오픈한지 1주일 정도만에 대부분의 에러를 해결했고 지금은 어느정도 안정화되었다. 이 과정에서 내가 느낀 점은 이렇다.

훌륭한 개발자는 문제를 발생시키지 않는 사람이 아니라 문제를 해결할 수 있는 사람이다.

내가 볼 때 현대 웹은 사용자들의 UI는 단순해졌지만 기술은 굉장히 복잡해졌다. 또한 프론트엔드와 백엔드가 분리되어 있는 상황에서 어느 한쪽만 잘한다고 제품이 완성되지 않기 때문에 에러는 항상 발생할 수 밖에 없다. 다만, 그 문제를 해결하느냐 못하느냐가 중요하다. 그리고 문제를 해결하는데에는 기술력도 중요하지만 내가 볼 때 서비스에 대한 이해와 일에 대한 태도가 더욱 중요하다. 개발을 아무리 잘한다고 해도 문제가 생겼을 때 자신의 코드에는 문제가 없다는 식으로 문제해결에 대한 의지가 없으면 결국 그 프로젝트는 완성되지 못한다.

사실 Docswave를 처음에 개발한 개발자는 우리회사를 퇴사했다. 그 당시에 백엔드를 그 개발자 혼자서 했기 때문에 많은 부담감이 있었던 것 같다. 그 개발자는 신기술에 대한 욕구가 굉장히 컸고 코딩도 굉장히 잘하는 편이었다. 내가 볼 때 개발에 분명 재능이 있는 사람이다. 그래서인지 퇴사를 한 후 대부분의 개발자들이 입사하고 싶어하는 좋은 기업에 입사를 했다.

그런데 확실한 것은 만약 그 개발자가 이번 프로젝트에 참여를 했으면 지금도 문제가 해결되지 않았을 것이라는 점이다. 그 개발자가 분명 개발을 잘하는 것은 맞지만 프로젝트에 대한 태도가 좋은 것은 아니었기 때문에 이번 업데이트를 하는 과정에서 우리들이 진행한 수 많은 삽질과 인내를 견디지 못했을 것이다. Docswave와 같이 다른 서비스(Google)의 API를 많이 이용하는 프로젝트는 개발실력과 상관없이 많은 삽질을 하게 되는데 그 힘든 과정을 버티는 것은 실력이 아니라 일에 대한 태도이기 때문이다. 

반면, 이번 프로젝트에 참여한 개발자들은 기존 개발자가 퇴사하면서 새로 뽑은 개발자들인데 기술력이 엄청나게 뛰어난 분들은 아니다. 오히려 기술력은 기존 개발자가 더 좋다. 하지만 그들은 API를 이용하는 과정에서 구글에서 뱉어내는 알 수 없는 에러에 대해 집요하게 파고들었고 오랫동안 해결할 수 없었던 여러가지 문제들을 해결했다. 그리고 결국 시스템을 안정화 시켰고 현재 약 1,500조직에서 많은 사람들이 Docswave를 잘 사용하고 있다. 나는 지금 이 개발자들이 나와 같이 일하고 있음에 감사함을 느낀다.

기획서(스토리보드)를 작성하는 일은 정말 어렵다. 그런데 그 기획서를 보고 개발하는 일은 더 어렵다. 기획자는 개발자를 도와줘야 한다.

기획자가 서비스에 대한 정책을 정하고 프로세스를 설계한 후 스토리보드를 작성하는 일은 정말 힘든 일이다. 기획이 잘못되면 서비스의 모든 것이 꼬일 수 있다는 불안감이 기획자들의 마음속엔 항상 존재하기 때문이다. 남방 하나를 입을 때도 첫 단추를 잘못 끼우면 단추를 다시 뺀 후 처음부터 다시 시작해야 하지 않은가!

그러니 개발자들의 마음은 평소에 얼마나 불안하겠는가! 기획서 변경에 따라 시스템을 다시 설계할 수도 있는 불안감이 분명 그들에겐 항상 존재할 것이다. 기획서가 변경되더라도 일정은 변경되지 않을테니 그 불안감은 더욱 클 것이다. 

그래서 기획자들은 개발자들이 문제를 해결할 수 있도록 도와줘야 한다. 개발자들이 알아서 문제를 발견하고 해결할 것이라고 기대하기보다 문제를 발견하고 그 문제를 해결할 수 있도록 도움을 줘야한다. 이렇게 말하면 기획자들이 약간 희생(?)을 해야한다는 것처럼 들릴 수 있지만 내 생각엔 그건 잘못된 생각이다. 내 생각엔 이것도 기획자의 임무이다. 특히, 규모가 작은 스타트업의 경우 더욱 그러하다. 한국 대부분의 개발자들은 작업 도중에 자신이 작성한 코드에 대해서 세심하게 검토하고 집요하게 테스트를 해볼 수 있는 여유가 없다. 이유는 간단하다. 그렇게 하면 일정을 못 맞추기 때문이다. 그래서 기획자들은 개발자에게 현재 시스템의 문제점과 그 문제가 발생하는 원인에 대한 추측, 혹은 가설에 대해서 제시를 함으로써 개발자가 문제해결에 투자할 시간을 단축시켜줘야 한다. 만약 기획자가 시스템의 모든 문제를 개발자의 탓으로만 돌린다면 그 기획자는 그 어떤 개발자와 일을 해도 프로젝트를 완성할 수 없을 것이다.

위에서 이런 저런 이야기를 했지만 사실 나도 아직 많이 부족하다. 에러가 너무 많으면 나도 개발자에게 짜증을 낸다. 아무래도 프로젝트 중간에 생기는 기획자와 개발자 간의 의견충돌은 피할 수 없는 것 같다. 하지만 분명한 것은 그 과정에서도 기획자와 개발자 모두 문제를 집요하게 파고들어 시스템이 안정화된다면 기획자는 개발자를 위대한(?) 개발자로 인정할 것이고 개발자는 기획자를 위대한(?) 기획자로 인정해줄 것이다. 문제해결만 된다면 그 과정에서의 불협화음은 아무것도 아닌 것이 되어버린다.