안녕하세요, 타이젠 개발자 윤진입니다.


2015년 마지막 날을 맞이하여,

<아프니까 개발자다> 블로그 총결산을 진행하고자 합니다.

제 블로그를 찾아주시는 극소수의 개발자분들조차 총결산 따위에 관심없으시겠지만,

블로거로서 지난 한해를 돌아보고,

더 나은 내일을 구상하기 위해 2015년을 돌아보고자 합니다.


<아프니까 개발자다> 블로그 정보를 훑어보겠습니다.

그 동안 총 159개의 글을 썼습니다.

대부분의 글은 외부에 발행한 공개글이고,

열개 남짓한 글은 차후에 게시하기 위해 가다듬고 있는 중입니다.

댓글은 글마다 평균 0.6개 정도가 달리고 있습니다.

타이젠에 대해 전문적인 내용을 다룬 포스팅에는 댓글이 거의 없네요.

문의가 없다는 것은 그만큼 완벽하게 포스팅을 하고 있는 것이겠죠...?


마지막에 블로그 개설일이 뚜렷하게 찍혀있습니다.

2015년 3월 1일!

그렇습니다. 올해 3월 1일 삼일절에 블로그를 개설하였습니다.

일부러 삼일절을 되새기기 위해 굳이 그날 개설했습니다.

(농담 아닙니다. 히히;)




제 블로그는 주로 구글링으로 접근해서 들어오는 분이 많습니다.

불과 두어달 전까지만 해도 네이버를 통해서 들어오는 분들이 많았는데요,

어느 순간 구글이 치고 올라오기 시작하더니 압도적으로 수치가 올라가고 있습니다.

1위는 구글, 2~5위는 네이버, 6위는 다음입니다.


10위에 티스토리가 있네요.

아마 포스팅을 할때마다 티스토리 주제별 스토리에 게재가 되는데요,

그 때 타고 오는 분들이 있겠지요.


11위에는 카카오톡입니다.

카톡으로 제 블로그를 검색해서 오시는 분들도 있군요.

아직 1위인 구글의 1/100에 불과하지만 차츰 점유율을 높이길 기대해봅니다.


13위, 구글 재팬으로 들어오는 분도 있고,

14위, 구글 인도도 제법 있네요.

16위에는 구글 캐나다가 보이고,

20위에는 구글 호주도 있습니다.

영어공부를 열심히 해서 포스팅을 영어로도 해야하지 않나 고민하게 만드네요.


매달 방문한 사람수를 보며 어떤 글이 관심을 받았는지 정리해보고,

올 한해의 방문트랜드를 엿보고 내년을 예상해보겠습니다.



사실 개설한 첫달 3월은 하루 방문자 수가 극히 미미하였습니다.

3월 1일부터 31일까지 하루 평균 2명 정도가 다녀갔네요.

겨우 한 명이 방문한 14, 15, 16, 23일은 아마 제가 방문한게 아닌가 싶네요.

게다가 3, 12, 13, 18, 19, 20, 22, 24, 25, 26, 27일은 방문자가 없습니다.

블로거가 방문하지 않는 블로그!

대단합니다;


29일에 방문자가 폭증(?)한 것은 코딩컨벤션을 다룬 세번째 글때문입니다.

[Coding convention] 코딩의 기본, 시대의 흐름으로 살펴본 헝가리안 표기법

사실 첫달에 하루 방문자수가 두자리수가 되리라고 생각하지 않았는데요,

아직도 세상은 코딩컨벤션으로 다투는 개발자로 가득차 있어서,

제 블로그 기준으로 '많은' 개발자가 다녀간 것으로 보입니다;




4월은 매우 고무적인 달입니다.

하루 평균 방문자수가 무려 3명이 넘는 기염을 토하였습니다.

그 덕에 방문자 수가 한 명도 없는 날은 12일(일) 하루뿐입니다.

원래 전통적으로 토/일은 제 블로그가 굉장히 한산하죠...


이 달에 가장 인기있던 포스팅은,

오픈소스 타이젠에서 소스 형상관리를 위해 사용하는 'git'과 관련된 내용이었습니다.

[git] 깃의 속사정, 4대 원소를 파헤치기

많은 개발자들에게 필수툴로 자리잡은 git의 위력을 실감할 수 있습니다.

위의 포스팅 이후에도 git에 대해서는 다양한 이야기를 나누고 싶었지만,

최근에 git과 관련된 정보가 인터넷에 넘쳐나고 있어서 자제하고 있습니다.




5월은 거의 매일 두자리 수의 방문객을 유치한 혁신의 달이었습니다.

4월달의 평균 3명 방문했던 블로그가 평균 34명 방문하는 블로그가 됩니다.

무려 10배가 늘어났네요.

이 달의 격한 감동은 아직도 마음 깊숙한 곳에 자리잡고 있습니다.

하루 3명오던 블로그에 30명이라니!

게다가 5월 21일에는 무려 187명이 방문합니다.

세자리수를 처음으로 찍었습니다.


[Tizen] 타이젠 최초의 모바일 기기, "Z1"의 늦은 개봉기

5월 21일 포스팅은 타이젠 상품과 관련된 내용이었습니다.

타이젠을 다루는 블로그에 타이젠 상품과 관련된 포스팅이 관심받지 못하면 문제가 있는거겠죠;

서남아 시장에만 출시한 Z1의 개봉기를 간단하게 다루었었는데요,

개발자의 손에 하드웨어를 쥐어주면 참 많은 걸 할 수 있겠구나 생각이 들었습니다.



6월에는 하루평균 백여명이 방문하게 됩니다.

5월에 비해 3배 이상의 성장율을 달성하게 됩니다.

5월에는 31일 중 고작 이틀동안만 백여명 이상의 방문자를 유치했었는데요,

6월에는 거의 절반에 가까운 14일동안 백여명 이상의 방문자를 유치하였습니다.


그 중 가장 많은 사람이 찾아주었던 6월 13일에는 타이젠 보안의 핵심,

스맥을 다룬 포스팅이었습니다.

[SMACK] 스맥 레이블을 긋기 위한 manifest의 모든 것 - 파일편

대규모 플랫폼 중에서 타이젠이 가장 적극적으로 스맥을 사용하고 있습니다.

스맥을 알고 싶다면 타이젠 플랫폼을 분석하는 것도 의미가 있을 겁니다. 




7월에는 하루 평균 122명의 방문객이 다녀갑니다.

6월의 100명에 비해 22명이 더 늘어났습니다.

평일에는 거의 어김없이 세자리수를 유치하였고,

주말에는 역시 어김없이 두자리수에 머물고 있습니다.

제 블로그가 평일용으로 확정된 것이 7월달부터가 아닌가 싶습니다.

다들 업무시간에만 제 블로그를 찾는 것일까요?

그래서 업무 외의 시간에도 방문자를 유치할 수 있도록-

여러가지 다양한 내용을 다뤄야되겠단 생각을 했습니다.


7월에 가장 인기가 많았던 포스팅은,

[Tizen] 타이젠 스토어 182개국 오픈 중 4개국 유료판매가능

타이젠 앱스토어의 유료판매 정책에 대한 내용입니다.

182개국 중 4개국(인도, 방글라데시, 스리랑카, 네팔)에서 유료판매가 가능하게 되었죠.



8월에는 7월과 거의 유사한 수의 방문객이 다녀갔습니다.

7월에 122명이 다녀갔다면 8월에는 평균 123명이 다녀갔습니다.

하루 평균 2명 방문했던 블로그에 123명이 방문한다면 그야말로 대사건이긴 하지만,

100여명에서 정체된다면 아무래도 한계점에 다다른 것일 수도 있겠네요.


사실 8월에는 포스팅을 거의 하지 못한 기억이 납니다.

8월 29일에 서울 서초에서 타이젠 행사에서 세션발표를 맡게되어,

여러가지 준비를 하느라 정신없었죠.

[Tizen] 타이젠 DEVLAB @SEOUL 후기

위의 글이 가장 많은 방문자가 다녀간 날에 포스팅한 글입니다.

서울에서 열린 첫 타이젠 데브랩이니만큼 여러가지 많은 것을 느낄 수 있었습니다.




9월에는 하루 평균 120여명에 멈춰있었던 방문자수가 조금 증가하게 됩니다.

평균 145명으로 약 20여명의 방문자가 더 늘어났습니다.

타이젠에 관심을 가지고 있는 사람이 늘어났다기보다는,

일반적인 개발방법에 대해 다룬 글을 몇 개 올려서 외부 소프트웨어 개발자가 유입된 것으로 보입니다.


그 중 가장 많은 방문자를 유입한 날에 작성한 글은,

[소프트웨어 개발] Man-Month 허상과 히어로 개발자입니다.

위의 글은 타이젠 플랫폼을 만들고 계신 분들 중에 없어서는 안될 개발자분들을 떠올리며 작성했죠.

지금은 좀 더 늘어나긴 했지만,

저 글을 썼었던 당시에는 5명의 히어로 개발자 분들을 염두했죠.

물론 그 다섯 분들은 자신이 히어로 개발자들인 것을 인지하지 못하실 수도 있겠네요. :)

지극히 개인적인 생각입니다만,

저런 훌륭한 개발자들이 타이젠 플랫폼에 남아있는한,

타이젠은 점점 흥미로운 플랫폼으로 변모해나갈 것임을 확신할 수 있습니다.




시월에는 평균 145명 방문자가 192명으로 늘어납니다.

어느새 평균 200여명의 문턱에 다다르게 되었습니다.

이런 날이 이렇게 빨리 오게 될 줄은 상상하지 못했죠.


사실 시월에는 타이젠 외에 다양한 주제를 다루었습니다.

우선 삼성 오픈소스 컨퍼런스를 주제로 몇 건 포스팅하였죠.

삼성 대학생 프로그래밍 경진대회가 열린 달이기도 하고요.

코리아 리눅스 포럼에 대해서도 살짝 포스팅을 했습니다.

그래도 가장 많은 사람이 방문한 글은 SCSA에 대한 글이었습니다.

[SCSA] Samsung Convergence Software Academy를 말하다

삼성에서 만든 굉장히 독특한 제도이니 만큼,

외부의 관심도 많았습니다.

더불어 개인적으로도 아주 관심이 많습니다.

앞으로도 SCSA 전반을 계속 주시하며 정보를 '적극적으로' 갱신할 생각입니다.




11월은 앞으로 돌아오지 않을 호시절과 같은 달이었습니다.

이전달의 평균 192명 방문자는 이제 평균 378명으로 거의 두 배 가까이 늘어납니다.

방문자수가 폭발적으로 늘어나게된 이유는 기어S2가 출시되면서 타이젠에 관심이 많아진 것이겠지요.


가장 방문자가 많았던 글은,

[Tizen] 타이젠 세번째 웨어러블 기기, "Gear S2" 리뷰

위의 글이었습니다.

개발자들의 관심을 받게된 만큼,

타이젠은 생태계 구축에 더욱 힘을 쏟아야할 때입니다.



이 글을 쓰고 있는 12월 25일 기준으로,

하루 평균 218명의 방문자가 블로그를 찾고 있습니다.

기어 S2가 출시된 후 시간이 많이 흘렀기에 기어S2로 검색하여 들어오는 사람은 많이 줄었습니다.

그 대신 타이젠을 키워드로 들어오는 사람들이 200명이 넘습니다.


물론 이미 널리 알려진 여러 플랫폼들을 주제로 다룬 블로그는,

<아프니까 개발자다> 보다 10배 혹은 100배 많은 방문객을 유치하고 있겠죠?

내년에는 타이젠이 더 많은 사람들에게 사랑 받아서 덩달아 제 블로그에도 다시 호시절이 오면 좋겠습니다. :)

역시 타이젠 관련 블로그는 타이젠이 흥해야 같이 살아난다는 만고의 진리를 다시 한 번 확인하게 됩니다.


마지막으로 재미삼아서,

최근에 분석하기 시작한 구글 애널리틱스 분석자료를 보겠습니다.



제 블로그에 재방문자가 40%나 됩니다.

재방문자가 있다는 것은 뭔가 쓸만한 글이 있다는 반증이겠지요?

재방문자들을 실망시키지 않도록 2016년에는 흥미로운 주제를 더 많이 찾아내겠습니다.

"단골이여, 영원하라."



방문객은 평균 2~3분 정도 블로그에서 글을 읽었습니다.

2~3분이 결코 긴 시간은 아닌 만큼,

좀 더 퀄리티가 높은 글을 공유해야겠다는 생각이 듭니다. 



방문객은 1.5개 정도의 글을 읽고 돌아갔네요.

검색한 하나의 글만 보고 가는 분들도 있겠지만,

두개 이상을 보고 가는 분도 있네요.

흥미롭군요.



위의 그래프는 매일매일 시간에 따라 방문자를 나타낸 겁니다.

예외없이 평일 오후 3시에 그래프가 정점을 찍습니다.

제 블로그는 오후 3시에 들어오기 좋은 블로그인가 봅니다.

도대체 그 시간에 무슨 일이 벌어지고 있는 건가요?


이상으로 어쩌면 제게만 유의미할 지 모르는 2015 총결산을 마치겠습니다.

2016년 새해 복 많이 받으세요.

2016년 총결산때 다시 찾아뵙겠습니다.


감사합니다.

끝_




  1. 시스템가이 2015.12.31 23:44

    타이젠에 대해 이렇게 멋진 블로그를 운영하시는 분이 또한분 계시다니 감동이에요 ^^ 총 결산 글을 보니 다른 글들도 보게 되네요 잘 읽고 갑니다 ^^

    • 안녕하세요, 시스템가이님.
      새해 복 많이 받으세요~!
      시스템 가이님의 댓글을 보니 더 흥미로운 글을 많이 써야되겠다는 생각이 듭니다. 아직은 많이 부족하니 올 한해 바짝 허리띠를 졸라매야겠네요 :) 좋은 말씀 감사해요!

  2. 코코콩 2016.01.05 18:12 신고

    오후 3시는 점심먹고 업무에 몰두하다가 안풀려서 쉬는타임이죠 ㅋㅋㅋ

    • 제 블로그를 보면서 쉬는 분이 계실 수도 있겠군요.
      3시 고객을 위해 좀 더 재미나게 읽을거리를 준비해야겠네요. :)


바로 이전 포스팅에서 Man-Month를 설명하다가 히어로 개발자를 언급했는데요,

(관련 포스팅, http://storycompiler.tistory.com/142)

이번 포스팅에서는 히어로 개발자라면 응당 받아야할 대접에 대해 써볼까 합니다.


물론, 히어로 개발자의 출몰을 경계하는 의견도 있습니다.

히어로 개발자도 엄연히 사람인지라 후진적인 정치활동으로 조직을 퇴화시킬 수 있습니다.

그렇기 때문에 오히려 히어로 개발자의 등장을 막아야 한다는 의견도 있습니다.


- 독단적인 결정에 따른 그릇된 방향설정

- 의사결정권자 부재에 따른 위험부담 증가

- 의사결정 소요시간의 증가


언뜻 생각해봐도 줄줄이 떠오르는 위와 같은 폐단을 막기 위해,

제 2의 잡스가 출현하는 것을 철저히 막고 있는 것인지도 모릅니다.


하지만, 위의 부정적인 요소는 '히어로' 개발자로 인해 발생하는 것은 아닙니다.

조직에 부여된 권한이 개별 구성원에게 알맞게 부여되지 않았기 때문입니다.


히어로 개발자가 한 명만 살아남은 조직은 결코 건강한 조직처럼 보이지 않습니다.

히어로 개발자 다수가 각각의 하부조직을 견실하게 떠받들고 있어야

조직 전체가 기민하게 움직이며 큰 그림을 함께 그릴 수 있습니다.

그렇게 하기 위해서는 다수의 히어로 개발자가 자랄 수 있는 자양분이 필요합니다.


이 글은 히어로 개발자가 무럭무럭 성장할 수 있는 환경에 대해

아주 편협한 일개 개발자의 시각으로 언급하고 있습니다.

무식하면 깡패라고 편협한 시각에서 오는 무지가 글 곳곳에 듬뿍 담겨 있습니다.

그 점 미리 양해 부탁드립니다.


조직 곳곳에서 자생하고 있는 히어로 개발자 분들은 어떤 대접을 받고 있을까요?

연봉이나 승진에 대한 보장은 이 글의 관심사가 아닙니다.

대신 히어로 개발자에게 주어지는 권한과 의무에 초점을 맞출 생각입니다.


결론부터 말하자면,

히어로 개발자에 대한 처우는 아티스트에 대한 대접과 비슷해야합니다.

다각적인 면에서 오랜 고찰을 통해 히어로 개발자의 생태를 연구한 끝에 내린 결론입니다.


아티스트가 예술작품으로 천문학적인 부가가치를 창출해내듯,

히어로 개발자도 소프트웨어를 예술작품으로 승화시켜 부가가치를 창출합니다.

수많은 국경없는 사용자들이 소프트웨어에 빠져들게 만들지요.


아티스트에 따라 피조물이 완전히 다르듯,

히어로 개발자에 따라 최종결과물도 천차만별입니다.

잘 키운 히어로 개발자는 먼훗날 박물관에 전시해도 손색이 없는 대중문화재를 만들겠죠.


그렇게 하기 위해서는,

히어로 개발자가 작품에 몰입할 수 있는 환경을 제공해주어야 합니다.



프로젝트 선택권

개발자들에게 특히 히어로 개발자에게 자신이 참여할 프로젝트를 선택하게 해야 합니다.

사실, 얼마전에 스타트업 회사에 방문한 기억이 있습니다.

그 회사는 사내게시판에서 신규 프로젝트에 참여할 사람을 공개적으로 모집하고 있었습니다.

프로젝트가 충분히 '될 성 부른 나무'라면 파티인원을 금새 모을 수 있습니다.

하지만, 장애가 많은 프로젝트라면 파티원을 구성하는데도 어려움이 생기겠죠.

다수가 프로젝트에 대해 고민할 수 있는 환경 자체가 시너지가 될 겁니다.

특정 사람들의 이권에 따라 현실성없거나 부질없이 생성되는 프로젝트는 사라질 겁니다.


단기실적이 아닌 장기적인 시각으로 접근하는 프로젝트에는,

파티원이 섣불리 참여하기가 힘들 수도 있습니다.

프로젝트간 적절한 보상장치는 따로 고민해봐야하겠지만,

이 경우 프로젝트 리더의 역량이 파티원에게는 중요한 판단근거가 될 수 있습니다.

훌륭한 리더 밑에는 우수한 파티원이 모일겁니다.

그렇지 않은 보스는 파티원을 모으기조차 힘들어지겠죠.



백로그 결정권

백로그는 우선순위가 명시된 작업열람표입니다.

애자일 개발방법론에서는 백로그 리스트로 작업사이클마다 다뤄야할 일을 확정합니다.

프로젝트를 위해 반드시 해야할 일은 백로그에 추가합니다.

그리고 할 필요가 없는 일은 백로그에서 제외합니다.


해야할 일과 그렇지 않은 일을 나누는 것에 대한 결정을 누가 해야할까요?

그리고 해야할 일에 우선순위를 부여하는 것은 누구일까요?


기획, 디사인, 개발, 검증, 영업?

프로젝트에 관여하는 모두가 프로젝트에 대해 자유롭게 의견을 낼 수 있습니다.

다양한 시각에서 다양한 이유를 들어 다양한 항목을 백로그에 추가하려 시도할 수 있습니다.

하지만, 최종결정은 프로젝트에 참여하고 있는 개발자의 손에서 이뤄져야 합니다.

Product owner, Team leader, Project leader...

어떤 이름이건 실제 개발에 참여하고 있는 개발자가 해야합니다.

개발자 중 가장 탁월한 히어로 개발자가 '합리적으로' 최종의사결정을 내리게 되겠지요.



아키텍쳐 결정권

프로젝트를 위해 해야할 일이 결정되면,

요구사항에 따라 아키텍쳐를 설계해야합니다.

새로운 요구사항이 기존 아키텍쳐에서 수용하기 힘든 경우가 있습니다.

그럴 경우에는 아키텍쳐를 완전히 뜯어고치더라도 요구사항을 개발해야 합니다.


어떤 경우든 아키텍쳐는 프로젝트를 담당하고 있는 히어로 개발자가 선택할 수 있어야 합니다.

더 나은 길이 존재하는 경우라면 그 길을 선택하면 됩니다.

하지만, 가치나 정책의 충돌에서는 프로젝트의 철학을 꿰뚫고 있는 개발자가 나서야 합니다.

그리고 그게 대부분은 히어로 개발자가 되겠군요.



정예개발자 육성

히어로 개발자도 처음에는 루키였습니다.

처음부터 히어로인 개발자는 거의 없을 겁니다.

따라서 개발자를 히어로 개발자로 성장시키기 위한 고민을 언제나 해야합니다.

어제는 형편없다고 생각했던 개발자가 내일은 우수한 개발자로 성장할 수 있습니다.


히어로 개발자가 오만에 빠지지 않도록 유의하며,

자신과 함께 일하는 개발자들의 성장에도 관심을 기울여야 합니다.

그리고 개발자 교육을 위해 필요한 수단을 결정할 수 있는 권한이 있어야 합니다.

필요하다면 몇 주간 교육을 보낼 수도 있고,

책 몇 권을 사다주며 세미나를 부탁할 수도 있겠죠.



자유 도서구입권 & 컨퍼런스 자유이용권

히어로 개발자도 끊임없이 공부해야합니다.

개발자 세계에서 영원한 진리는 없습니다.

그렇기 때문에 개발자 자신은,

매일의 트렌드를 익히고,

새로운 기술을 익히고,

참신한 이론을 엿보고,

신선한 발상에 끊임없이 노출되어야 합니다.


그렇게 하기 위해서는 개발자 성장에 적극 투자해야합니다.

읽고 싶은 책은 마음껏 구매하게 합니다.

참석하고 싶은 컨퍼런스에는 마음껏 참석하게 합니다.

개발자 성장을 위한 비료가 투자아닌 비용으로만 여겨진다면,

개발자 문화나 조직문화에 문제가 있는게 아닐까요?



개발을 위한 개인공간

히어로 개발자는 예술가에 가까운 존재라고 언급했습니다.

매일같이 고도의 집중력을 요하는 작업을 수행하고 있습니다.

그러나 열린 공간을 지향하다 보니,

집중할 수 있는 시간 5분을 마련하기 힘듭니다.


다른 부서의 히어로 개발자들 의견을 들어보면,

새벽이나 밤이 되서야 비로소 자기 일을 할 수 있다고 합니다.

낮시간에는 주로 다른 개발자나 다른 부서의 의문이나 요청을 처리한다고 합니다.

이런 식으로 개발이 진행되면,

히어로 개발자의 업무효율을 바닥을 치게 됩니다.

일과시간에도 집중하여 자신의 업무를 처리할 수 있는 시간이 필요합니다.


하루 종일 폐쇄된 공간에서 활동할 필요는 없습니다.

그렇지만, 개인업무에 필요한 시간 만큼은,

개인공간을 보장해주어야 합니다.



최상의 도구 제공

히어로 개발자 뿐만 아니라 모든 개발자는 최고의 도구를 갖고 있어야 합니다.

목수는 연장 탓을 하지 않지만,

개발자는 철저히 연장 탓을 해야 합니다.

컴퓨터 성능에 따라 개발자의 업무 효율을 극단적으로 바뀝니다.

빌드가 10초내로 되느냐에 따라 개발자의 집중도에 차이가 납니다.


모니터의 크기나 개수에 따라 개발효율이 달라집니다.

한 눈에 필요한 정보를 얻을 수 있게 뒷받침해줘야 합니다.


키보드, 마우스, 의자는 개발자의 건강생활과도 직결되어 있습니다.

건강한 개발자가 건강한 코드를 작성하는 법입니다.



이 글은 제 주위에 있는 히어로 개발자들을 보며 쓰게 되었습니다.

임원급, 간부급, 사원급 모두에 히어로 개발자가 있더군요.

히어로 개발자에게는 더 좋은 소프트웨어를 만드려는 순수한 열정이 넘칩니다.

그런 사람들과 함께 일하는 것만으로도 충분히 동기부여가 됩니다. :)


더 많은 히어로 개발자가 한국에 출몰하여,

한국의 소프트웨어 경쟁력을 몇단계 올릴 날을 기대해봅니다.


끝_


  1. 코코콩 2015.10.13 13:41 신고

    와 글 잘보았습니다.
    윤진님 밑에서 개발을 배우면 엄청난 정석개발자가 될 것 같네요 ㅋㅋㅋ
    윤진님께서는 스타트업하실생각없으신가요?
    지금 계신곳 밑으로 따라가긴 제가 너무 부족하고 ㅎㅎㅎ 스타트업하신다면 헐값에라도 일하고싶은생각이 드네요
    좋은하루되세요( _ _ )

    • 코코콩님, 이 댓글에는 함부로 답을 달면 안될 것 같아서 망설이고 있었습니다. 히힛;
      히어로 개발자도 아니거니와 저도 열심히 공부해야할 때라서요. :)
      하지만, 코코콩님과 함께 일해보고는 싶습니다.
      이 세계는 의외로 좁은 세계이니 열심히 하다보면 만날 날이 오지 않을까요? :)

    • amaze_ 2015.10.15 00:26

      엇. 저도 비슷한 생각을..
      이런사람 밑에서 일해보고싶다구요ㅎㅎ
      많이 성장할수 있을것 같습니다

    • amaze_님,
      뭐 드시고 싶으세요? :)


늘상 그렇듯,

오늘도 일개 개발자로서 체감하는 개발현실을 얘기해볼까 합니다.

'일개 개발자'로서의 생각이기 때문에 코끼리의 꼬리만 만지고 있다고 생각하셔도 무방합니다.


Man-Month는 한 사람이 한 달간 하는 일의 규모를 토대로,

프로젝트에 투입할 인력과 일정을 계획할 때 사용합니다.


10명이 1년간 프로젝트를 진행해야하면,

10명 x 12개월 = 120 M/M(Man-Month)

120 M/M 규모의 프로젝트라고 말할 수 있습니다.


프로젝트에 투입한 사람을 좀 더 늘려볼까요?

120 M/M 프로젝트에 12명을 투입하면,

120 M/M / 12명 = 10개월

12개월에서 10개월로 2개월이 줄었습니다.


이 수식에는 한가지 전제가 필요합니다.

투입되는 인력의 수준이 동일하다는 전제이지요.


하지만, 소프트웨어 개발에 발담고 있는 동안,

여실히 깨달은 사실은 개발자 간에 수준이 천차만별이라는 것입니다.


초보개발자와 고급개발자 간의 차이가 20배가 넘는다는 글을 읽은 적도 있습니다.

입사 직후에 정말 아무 것도 몰랐던 저와

여전히 아무 것도 모르는 지금의 저만 비교해봐도

20배는 가뿐히 넘는 것처럼 느껴집니다.


소프트웨어 개발은 제조의 영역과 예술의 영역 사이 어디쯤 위치하기 때문에,

초보개발자와 고급개발자 간의 차이가,

제조업계의 비숙련공과 숙련공의 차이보다는 월등하게 크고,

연습생과 천재 아티스트 간의 차이보다는 좀 작을 거라 생각합니다.


게다가 때로는 대체불가능한 사람이 있습니다.

그런 히어로 개발자들은 개발자들 사이에서는 천재 아티스트와 맞먹는 파급력을 지닙니다.

초보개발자와 히어로 개발자의 간극은 거의 무한대에 가까울 거라 생각합니다.


왜냐하면, 히어로 개발자의 기발한 발상은,

히어로 개발자가 아니면 도출해낼 수 없는 직관의 비약에서 나오기 때문입니다.


제가 일하는 곳에서도,

히어로 개발자 다섯 분이 있습니다.

무려 다섯 분이나 있다는 사실 자체에 놀랍기도 하고 행복하기도 합니다.


약간의 사례를 소개해보겠습니다.

외부 개발자가 사용할 수 있게 API를 설계하는 시간이었습니다.

기존 담당자는 견고하게 구축되어있는 아키텍쳐를 언급하며,

현 아키텍쳐를 기준으로 다음 버전을 준비하고자 하였습니다.

지극히 논리적이고 합리적이었습니다.

히어로 개발자가 딴지를 걸기 전까진요.


히어로 개발자는 기존 담당자의 논리를,

실제로 API를 사용하는 개발자가 불편할 수 있다는 논리로 깨버렸습니다.

히어로 개발자가 원하는 '사용하기 편한' API를 준비하기 위해서는,

오랜 전통을 가지고 있는 아키텍쳐를 전부 바꿔야했습니다.

그렇기 때문에 담당자는 굉장히 강하게 거부의견을 펼쳤습니다.

그렇지만, 히어로 개발자는 그 어느때보다 단호한 고집으로 자신의 주장을 관철했습니다.


아키텍쳐보다 사용자 편의가 우선한다는 히어로 개발자의 의견에 전적으로 동의합니다.

아키텍쳐 따위야 언제든지 바꿀 준비가 되어있어야 합니다.

아키텍쳐가 중요하지 않다는 얘기는 아닙니다.

당연히 아키텍쳐는 소프트웨어 개발에 근간이 됩니다.

하지만, 아키텍쳐보다 중요한게 있습니다.

바로 실제로 소프트웨어를 사용할 사람들이지요. :)


물론 사용자 요구사항은 천차만별입니다.

경우에 따라서는 자신이 요구하는게 뭔지 모르는 경우도 있습니다.

따라서, 요구사항을 비판적으로 가려낼 수 있는 합리적인 절차가 필요합니다.

그 부분에 대한 논의는 다음으로 미뤄두겠습니다.


또 다른 예도 있습니다.

라이브러리 A에서 DB가 필요한 경우가 있었습니다.

라이브러리 A에서 DB 파일을 열고 read / write 해야만 할까요?

그렇게 되면 라이브러리를 사용하는 프로세스에서 DB에 직접 read / write 하게 될지도 모릅니다.

자칫하면 DB에 있는 table을 drop할 수도 있겠지요.

그걸 방지하기 위해 서버-클라이언트 구조를 차용하여,

클라이언트에서 서버에 DB 오퍼레이션을 요청하고,

서버에서는 인증된 오퍼레이션에 대한 동작을 처리하도록 구조를 잡지요.


하지만, 히어로 개발자는 라이브러리 A에서 직접 서버-클라이언트 구조를 만드는 것 대신,

컴포넌트 B에서 마침 사용 중인 서버-클라이언트 구조를 절묘하게 이용하는 것을 제안합니다.

컴포넌트 B의 역할상 라이브러리 A가 기생해도 아무 문제없는 구조였습니다.

히어로 개발자의 제안으로 플랫폼은 불필요한 프로세스를 만들지 않았습니다.


히어로 개발자들의 고집과 발상은 대체불가능합니다.

소프트웨어 개발업체에서 하는 가장 큰 착각은,

이런 히어로 개발자를 부속품 갈아끼우듯이 교체할 수 있다는 겁니다.

아직 제 경험이 미천하긴 하지만,

제 경험상 히어로 개발자는 교체할 수 없습니다.

히어로 개발자를 바꾸면 소프트웨어는 다른 모양으로 변하게 됩니다.

소프트웨어가 원래 가고자 했던 방향으로는 더 이상 갈 수 없습니다.


이 글의 시작은 Man-Month였는데요.

결론은 "히어로 개발자는 대체불가능하다" 정도가 되겠네요.

히어로 개발자는 제조영역 종사자라기 보다는 예술영역 종사자라고 보는게 맞습니다.


애초에 피카소나 샤갈을 다른 사람으로 대체할 수 있다는 정신나간 소리를 하는 사람이 있나요?

히어로 개발자들도 마찬가지입니다.


히어로 개발자가 많아져 소프트웨어 업계 전반의 개발자에 대한 인식이 바뀌면 좋겠습니다.

끝_

  1. 코코콩 2015.10.13 14:00 신고

    초보개발자인 저조차도 현재에서 +@를 하려고 생각만했는데요...
    글을 보니 반성하게 됩니다. 언제나 감사합니다,

    • 하지만,
      그럼에도 불구하고,
      왠지 코코콩님은 저보다 나으실거란 생각이 듭니다. :)
      저야말도 언제나 감사드립니다.

  2. amaze_ 2015.10.13 19:25

    왠지 히어로 개발자이실것만 같습니다. 명쾌한 글 잘 보고 있습니다

    • 안녕하세요, amaze_님.
      처음 뵙겠습니다~
      히어로 개발자가 아니라서 안타깝습니다;
      더 재미난 글을 쓰도록 부단히 노력해야겠네요.
      감사합니다!

+ Recent posts