Essay

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

Written by vonzone

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

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

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

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

 

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

ProblemSolution

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

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

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

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

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

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

 

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

developers

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

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

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

 

화해

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

About the author

vonzone

소프트웨어인라이프에서 서비스 기획을 하고 있습니다. 평범한 사람임에도 불구하고 특별한 일을 해내고자 합니다.

  • disqus_i7r41l4jQf

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

    라고 하셨는데 그 전 프로젝트에서 문제 해결 못하고 새로 갈아엎은 느낌이 좀 드네요 600개의 에러라는건 그 전에 일했던 사람도 그걸 그냥 둘만한 갯수는 아닌 것 같은데요.
    혹시 신기술이나 요즘 트랜드에 대한 이해도가 없으신건 아닌지?
    어떻게 프로젝트 완성하셨는지 코드 좀 보고싶네요.

    • 안녕하세요.
      전 기획자이기 때문에 개발자의 실력에 대해서 뭐라고 말 할 순 없지만 그 전 개발자도 나름 개발을 잘 하는 사람이라고 생각이 됩니다. 다만, 서비스 오픈 후 발생한 여러가지 문제점에 대해서 해결을 하지 못하고 이직을 한 것 같아요. 아무래도 마음이 떠나니 서비스에 대한 애착도 떨어졌을 것이라고 생각이 됩니다.
      프로젝트를 갈아엎은 건 ERD를 분석해보니 여러가지 문제점이 발생할 수 밖에 없는 구조였기 때문에 결정한 사항인데요. 아무래도 전 개발자가 혼자서 개발하다보니 여러가지 사항을 고려하지 못한 것 같습니다.
      다만, 지금 저와 일하고 있는 개발자들은 프로젝트에 대한 태도와 열정이 커서 여러가지 문제점을 잘 해결할 수 있었던 것 같습니다. 물론 기획팀에서도 극한의 테스트를 하면서 업데이트 버전을 공개하기 전에 에러를 많이 발견하고 그 리스트 정리를 잘 했고요. 진부한 이야기이긴 하지만 팀웍이 좋았던 것 같습니다.(물론 어느정도의 의견충돌은 있었습니다.)

      코드는 보여드리기 어렵습니다. 다만, 시스템이 어느정도 안정화 되었기 때문에 리팩토링을 하면서 점차 깔끔해질 것이라고 말씀드릴 수는 있을 것 같네요.^^

  • Jongmin Lee

    안녕하세요. 좋은 글들을 발견하면 페이스북에 공유만 했었는데 페이스북이 아닌 곳에 덧글 쓰는 게 최초네요.
    이유는 본문에 언급된 내용이 평소에 제가 생각하는 것과 100% 일치하는 거 같아서 기쁜 마음이었기 때문입니다.
    첨언이 필요 없긴 하지만… 굳이 첨언을 하자면
    “기획자는 기획한 무언가가 만들어지기 전부터 완성된 이후까지 최선을 다해 열렬히 책임질 책무가 있다!”
    정도를 언급할 수 있겠네요.
    (여기서 책무에는 무언가를 만드는 그 누군가의 좋은 컨디션과 좋은 주변환경까지 보장함이 포함)

    ps. 앞으로도 좋은 글 많이 부탁 드립니다^^

    • 안녕하세요.
      별거없는 글인데 좋게 평가해 주셔서 감사합니다.

      그리고 좋은 의견 감사합니다.
      말씀하신 책무까지도 기획자는 고려를 해야 한다고 생각합니다.
      제가 기획을 처음 배웠을 때 사수한테도 그런점을 많이 배웠었는데요…
      그럼 점들이 현재에도 많은 도움이 되고 있습니다.
      결국 그런 것 하나하나가 모여 팀웍이 만들어지는거니까요.
      이종민님도 좋은 정보 있으면 공유부탁드립니다.^^

  • guest

    개발에 대한 이해도가 없는 기획자가 개발자를 평가한다는 지점은 무의미할지도 모릅니다. 본문에 보면 코딩을 잘 한다 등의 판단을 하려는 의도가 보이는데, 개발실력이 좋은 개발자다 아니다 라는 기준이 아니라, 서로를 존경할 줄 아는 마인드의 개발자냐 아니냐 정도를 판단할 수는 있겠습니다. 같이 일하는 다른 영역에 대해 모른다 라는 마음이 전제되어야 합니다. 그렇지 않다면 확실하게 알고 있어야 하구요. 프로젝트를 런칭한 기획자님과 팀원분들 모두 축하드립니다.

    • 안녕하세요. 좋은 의견 감사합니다.
      다만, 개발자의 실력에 대해서 제가 평가를 하려고 한다는 해석은 제 의도와는 맞지 않은 것 같습니다.
      예를들어, 반대로 기획서가 디테일하게 작성되어서 개발자가 개발하는데 도움이 되었습니다. 그래서 개발자가 해당 기획자에게 기획서가 잘 작성되었다고 말하는 것이 개발자가 기획자를 평가하고 판단하는 행위라고 볼 수는 없기 때문입니다. 고마움의 표현이나 존중의 표현이라고 보는게 맞지 않을까요?
      그리고 제 글을 보시면 아시겠지만 글의 요지는 개발실력이 좋은 사람이 에러없이 개발하는 것보다 프로젝트에 대한 태도와 의지가 있는 사람이 프로젝트 완성에 더욱 큰 도움이 되었다는 것입니다. 따라서 말씀하신 ‘개발에 대한 이해가 없는 기획자가 개발자의 실력에 대해서 평가한다’는 의미는 제 의도와 완전히 다른 해석입니다.

      반면, 말씀하신 다른 영역에 대해서 서로 모른다는 마음이 전제되어야 한다는 것은 동의합니다. 그래서 개발자는 기능개발이 안되는 이유에 대해서 기획자에게 차분히 설명할 수 있어야 하며 기획자도 기능이 추가되었을 때 그 기능이 왜 필요한지를 개발자에게 설명할 수 있어야 합니다. 다행히 제가 다니고 있는 회사에서는 직원들 서로 그런 부분들을 잘 이해하고 있어서 감사하게 생각하고 있습니다.

      마지막으로 축하의 말씀 감사드립니다.^^
      나중에 시간되시면 Docswave 한번 이용부탁드립니다.
      사용해보시고 좋은 의견주시면 많은 도움이 될 것 같습니다.

      감사합니다.

%d 블로거가 이것을 좋아합니다: