brunch

매거진 일본 스타트업을 코딩하다

라이킷 15 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Seon Aug 08. 2017

#3. 개발 문화(1) : 조직 구성

개발팀 중심의 조직 문화에 대해 설명합니다.

근황

일주일에 한 번 정도는 정리를 하겠다고 시작했던 글이 3주가 지나도록 쓰지 못했습니다. 핑계를 대자면, 갑작스러운 개발 일정 투입으로 조금 바쁜 생활을 보냈습니다. 앞서 저는 JAVA 중심의 서버 개발자라고 말씀드린 적이 있었던 것 같습니다. 하지만 이번에 회사에서 안드로이드 개발에 투입되길 원해서 갑작스럽게 클라이언트 개발을 했습니다. 거의 생전 처음 해보는 개발이라 공부와 업무를 동시에 하느라 시간을 따로 내지를 못했네요.

무사히, 3주간의 개발 일정을 가지고 론칭하고, 오늘로써 개발 종료가 되었습니다. 개발도 종료되고 했으니 모처럼 쓰는 이번 주제는 우리 회사의 개발 문화를 가볍게 정리해 보고자 합니다. 개발 문화의 모든 부분을 10개월간의 근무 기간 동안 느끼기에는 한계가 있겠지만, 개인적으로는 꽤나 잦은 팀 이동을 통해 여러 팀의 문화를 짧은 시간 안에 겪어보았기 때문에 그동안 느꼈던 부분들을 정리해 보겠습니다.

개발 문화에 관련해서는 조금 긴 글이 될 가능성이 높아, 조금씩 끊어서 발행할까 생각하고 있습니다.

1. 개발자 구성 : 개발 포지션이 중요해?

우리 회사는 모바일 앱으로부터 받은 데모 그래픽(큰 의미에서는 인구 통계, 이곳에서는 사용자의 정보를 의미합니다. ex:나이대, 성별, 지역 등..)을 통해 각 앱들의 사용 정보를 분석하여 통계 리포팅을 하는 서비스를 주로 하고 있습니다. 따라서 회사 인원 중 개발자가 차지하는 비율이 적지 않습니다.

데모 그래픽을 수집하는 모바일 앱(클라이언트), 그 데모 그래픽을 쌓아놓는 서버(백엔드), 쌓아놓은 데이터를 분석하는 쿼리 및 알고리즘 연구(데이터 분석), 그 쿼리와 알고리즘을 적용하여 정기적으로 분석하는 분석 엔진(백엔드), 분석한 데이터를 웹으로 표현하는 웹서비스(프런트엔드)등 모든 프로세스를 자체적으로 만들어서 운영을 하고 있기 때문에 프로그램 엔지니어링의 모든 포지션을 필요로 합니다.

하지만, 각 엔지니어들의 포지션은 이 회사에서는 크게 의미가 없습니다. 위에서도 잠시 언급을 했었지만, 10년이 넘는 시간 동안 서버 프로그래밍만 주로 했던 저 역시도, 필요에 의해서는 안드로이드 개발을 하는 경우도 생기게 됩니다.

3주동안 생전 처음 만들어본 안드로이드 앱 - QR Code 인식 앱

어제까지 golang을 사용하여 서버 프로그래밍을 했던 친구가 오늘부터 워드프레스를 사용하여 테마를 만드는 경우도 있고, 파이선으로 개발했던 친구가 Swift를 이용해서 IOS 앱을 만드는 경우도 있습니다. 다행히 이 곳 개발자들은 호기심 대마왕들이라, 새로운 영역에 대한 개발에 대해 오히려 즐거워하는 경향이 많습니다. 자연스럽게 포지션을 옮겨가면서 개발하는 것에 대해 자연스럽게 받아들이는 이 친구들의 모습, 클라이언트의 ㅋ자도 모르는 저에게 자연스럽게 안드로이드 개발을 하기를 원하는 CTO의 모습들은 저에게 있어서 처음엔 쉽게 받아들여지지 않았던 모습이었습니다.

CTO : 안드로이드 개발해볼래?
나 : 필요하다면 하지 뭐. 어떤 건데?
CTO : 간단해, QRcode를 읽어서 그냥 링크를 띄우기만 하면 돼.
나 : 론칭은 언제까지야?
CTO : 2주 뒤.
나 :???
CTO : 넌 할 수 있어. 그럼 부탁해
나 : 누구랑 하면 되는 거야?
CTO : 너 혼자
나 :...

그 당시 나는 안드로이드가 어떤 개발 툴을 사용하는지만 알고 있는 수준이었습니다.

하지만, 어찌어찌 꾸역꾸역 2주 동안 구현해서 릴리즈를 했고, 1주 동안 사용자 피드백과 추가 구현 기능, 버그 수정을 통해 3주간 안드로이드 개발을 했습니다. 다행히 잘 릴리즈가 되었지만, 3주간의 시간이 어떻게 지나갔는지 모를 정도로 정신없이 보냈던 것 같습니다.

약 15년간(대학 포함) JAVA에 매달려 지내왔지만, 입사 후 10개월 동안 제가 담당했던 프로그래밍 언어는 4가지가 넘을 정도로 이 곳에서는 다양한 언어를 모든 엔지니어에게 경험을 시키고 있습니다. 저를 포함한 각 엔지니어들은 이 회사를 통해 다양한 언어를 경험하게 되고 폭넓은 언어 커버리지 능력을 키울 수 있는 좋은 기회라고 생각합니다.

링크드인에 정리해본 지난 10개월간 담당했던 스킬셋..

다만, 넓고 얇은 개발 경험보다는, 좁고 깊은 개발 경험이 더 도움이 된다는 개인적인 신념과는 조금 반하는 부분이 있어서 조금 걱정되는 부분도 있기는 합니다. 이런 부분은 좀 더 회사를 경험해 본 뒤에 판단해도 늦지 않다는 생각을 하고 있습니다.

하지만, 비개발자 입장에서 바라보는 [개발자]라는 사람은 개발을 해서 서비스나 시스템을 만드는 사람입니다. 언젠가 누군가 나에게 "너 개발자지? 안드로이드 앱인데 이런거 하나 만들줄 알아?"라고 했을 때, "아, 나는 서버프로그래머야. 그건 안드로이드 개발자한테 부탁해야지. 나는 그거 못해."라고 한적이 있었습니다.

그 친구는 내 대답에 대해서 오랜 시간동안 의아해 했었고, 나는 그 이유를 설명하느라 오랜시간동안 애를 쓴적이 있었습니다.

요즘 드는 생각은.

[개발자]라는 직업은 포지셔닝 구분없이 원하는 시스템이나 서비스를 만들어줄 수 있는게 진짜 [개발자]일지도 모른다는 생각을 해봅니다.

'LG'기기만 수리해주고 '삼성'기기만 수리해주는 각 회사의 수리 기사 분들보다는 모든 메이커를 수리할 줄 아는 동네 전파사 아저씨가 더 장인스러워 보였던 어린 시절 기억이 요새들어 정말 새삼스럽게 깊은 고민을 하게 만듭니다.

2. 팀 구성 : 고인물은 썩는 법

이 회사에 입사를 결정한 큰 요인이 된 부분이 몇 가지가 있었는데 그중 하나가 [업무는 수직적으로, 회사생활은 수평적으로]라는 느낌이 강하게 왔기 때문입니다.

몇 년 전부터 국내에도 수평적인 회사생활을 위해, 각 회사들이 사원들을 좀 더 윤택한 회사생활을 누릴 수 있도록 많은 노력을 해온 것으로 알고 있습니다. 저 역시 군대를 포함한, 대학교, 대학원 시절, 회사 초기 시절 비정상적으로 수직적인 문화를 경험하면서 큰 거부감을 가지고 있는 사람 중 하나입니다만.

이전 국내 스타트업 회사 재직 시절, 수평적 문화를 너무나 강요한 나머지 넘쳐흘러 나타나는 부작용들을 보면서 [기준 없는 수평적 문화] 또한 거부감을 가지고 있습니다. 크던 작던 회사 입장에서는 하나의 프로젝트에 대해 성공을 해야만 하는 목표를 가지고 있으며, 그 목표를 이루기 위해서는 비전을 공유하고 퍼뜨려야 할 리더가 필요하다고 생각합니다. 리더는 멤버들이 같은 비전을 바라볼 수 있도록 설득해야 하며, 멤버들은 리더가 올바른 방향으로 리딩(Leading)하고 있는지 끊임없이 견제해야 한다고 봅니다. 또한 지금의 리더보다 더 좋은 리더십이 있는 멤버가 있다면, 가감 없이 평가하고 교체해야 한다고 생각하고 있습니다. 그래야만 그 팀의 멤버들은 서로에 입장을 이해하고, 자유롭게 공유하고 견제하고 평가할 수 있을 테니까요.

이 회사는 3개월마다 팀을 변경합니다. 물론 기존 팀에 잔류하는 멤버들도 있고, 새로운 목표를 향한 TF팀을 만들어 배정을 하기도 합니다. 리더 또한 팀이 변경될 때마다 계속 연임하기도 하고, 교체되기도 합니다. 리더에 대한 기준은 단 한 가지입니다. 해당 팀에 대한 이해도가 가장 높은 멤버. 그 이외에는 경력이나 나이는 상관이 없습니다. 현재 제가 소속된 팀의 리더는 23세 데이터 분석가입니다.

가운데 회식 후드티의 남자가 지금 우리 리더!

경리팀, 영업팀은 큰 변함이 없으나 개발팀은 3개월마다 멤버 이동이 비교적 많은 편입니다. 일반적으로 개발팀의 구성은 리더+개발자들+디자이너+(영업)가 기본이 됩니다. 리더의 경우에는 특별히 개발자만이 지정되는 것은 아니고, 영업담당을 했던 멤버나, 디자이너, 데이터 분석가, CEO들도 담당하는 경우도 빈번하게 있습니다. 한국처럼 기획자라는 담당자는 존재하지 않으며, 모든 멤버들이 함께 기획을 한 뒤에 개발을 진행합니다.

이 회사의 분위기도 국내 여느 스타트업과 별 차이 없이 자연스럽게 발언하고, CEO 등의 임원이 잘못을 한다면 거침없이 쓴소리를 해가면서 자유로운 소통을 하고 있지만, 업무에 관해서는 전적으로 리더의 결정을 따르고 존중하는 문화입니다. 당연한 소리겠지만, 리더의 결정은 혼자만이 결정하는 경우도 있지만 대부분은 회의를 통해 담당자와의 조율을 통해 결정을 합니다. 해당 멤버와 마찰이 생겨 결정이 늦어질 경우에는 그 멤버와 밤새도록 회의를 해서라도 공통 결론을 만들어서 다음날 결정하는 경우도 있습니다.

개인적으로는 잦은 팀 변경으로 정신도 없고 적응할만하면 팀이 옮겨져서 곤란한 생각이 들기도 하지만, 모든 사원들의 업무 매너리즘을 예방하고자 끊임없이 노력하는 모습은 매우 긍정적으로 받아들이고 있습니다.

개발자의 구분 없는 포지셔닝이나, 3개월마다 주기적인 팀 변경 및 role 변경은 자칫 얕아 보일 수 있고 정신없어 보일 수도 있습니다.

하지만, 10개월 동안 바라 본 이 모습들은 단순히 양적인 경험 육성이라던가, 다이내믹한 것처럼 보이려는 연출이 아닌 각자가 어쩔 수 없이 느껴버리는 매너리즘과 오랫동안 한 곳에서 쌓으면서 늘어나는 아집을 없애려 노력하는 회사의 의도가 조금씩 느껴지기 시작합니다.

저 역시 JAVA라는 일반적인 프로그래밍 언어를 10년이 넘도록 하면서, 모든 시스템과 서비스는 JAVA로 모두 커버할 수 있으며, 가장 합리적인 언어라고 자부한 적도 있었던 부끄러운 과거가 있습니다. 지금도 가끔 새로운 언어로 며칠을 고민하고 있노라면, 가장 익숙한 JAVA로 해결해버리면 금방 되는데 왜 이리 시간을 낭비하고 있는가.라는 유혹적인 고민에 빠지기도 합니다.

요샌 40세가 되서야, 경력이 두자리숫자가 넘어서야 이런 생각을 하기 시작했다는게 한없이 부끄럽기만 합니다.

저는 또 내일(2017.8.8)부터 다른 팀으로 이동합니다. 4번째 팀 변경이긴 하지만 맨 처음 배속되었던 팀으로 다시 돌아가게 됩니다. 아직 어떤 업무를 담당할지, 어떤 시련(?)이 있을지는 모르겠지만 새로운 경험을 할 수 있다는 것에 감사하고 있습니다.