안녕하세요,

모스크바에서 생활하며 개발은 하지 않는 개발자 윤진입니다.


이 곳에서 정말 다양한 개발자를 만났습니다.

한 사람 건너면 반드시 프로그래머를 찾을 수 있을 정도로 많습니다.


С군의 요청으로 오로라 사진으로 대체


이번에 만난 사람은 현재는 영업업무를 하고 있는 '전직' 개발자 С군입니다.

С군과의 인터뷰는 개인적으로 굉장히 흥미로웠는데 실명을 밝히지 못해 아쉽습니다.


С군은 외고를 나와 컴퓨터공학과를 나왔습니다.

C군이 대학을 다니던 때는, Java가 대학수업의 헤게모니를 장악하던 때라

정규수업과정의 60% 혹은 그 이상이 Java로 이뤄졌습니다.

그래서 대학교 수업때 자연스럽게 Java를 중급 레벨 정도까지 익혔습니다.

그렇지만, 취직한 이후 Java를 사용한 적이 없어서 이제는 초심자와 다를바 없다고 하네요. :)


일부 학과 수업은 C언어로도 이뤄졌다고 합니다.

С군은 '중학교' 시절 C언어를 배웠기 때문에 대학교 때에 맨땅에 헤딩하는 삽질은 적게 할 수 있었습니다.


대기업에 취직한 이후에는 C언어만을 사용했습니다.

주로 퀄컴이나 브로드컴과 같은 업체들과 통신프로토콜을 개발하고 검증하는 일을 하였습니다.

1. 협력업체가 C로 작성된 코드가 정확히 구현되었는지 코드리뷰를 하고,

2. 타겟보드에 올려 테스트를 하며 로그파일을 분석하고,

3. 문제 코드를 찾아 직접 수정하거나 협력업체와 문제상황을 공유했다고 합니다.

여기서 문제상황이라하면 애초에 짜여진 스펙대로 동작하지 않는 경우이겠죠.


С군의 업무는 코드를 쓰는 능력보다는 읽는 능력이 더 중요했습니다.

코드리뷰개별함수의 parameter와 return 값의 의미를 정확하게 파악해야합니다.

그리고 이런 함수 조각들이 모여 이뤄지는 프로토콜의 동작을 세세하게 알아야 합니다.


함수내에 알고리즘을 Big O로 계산하며 성능을 높이는 것보다는,

코드를 정확하게 읽고 빠르게 파악하는 능력이 더 중요합니다.


이를 위해 신입사원때부터 프로토콜에 대한 책을 몇 권씩 읽으며 세미나를 하였다고 합니다.

선배 개발자들은 이미 프로토콜에 익숙하였기 때문에,

세미나는 신입 스스로 정리하며 선배에게 난도질 당하며 성장하는 시간이었습니다.


그리하여 3~4년의 수련기간을 거치면 모듈에 대해 전문가가 된다고 합니다.

사람마다 차이가 있겠지만, 대충 3~4년 경험이 필요하다고 합니다.

전문가가 되면, 모듈의 동작상태를 보고 문제상황인지 여부를 가늠할 수 있게 됩니다.


전체 아키텍쳐에 대해 꿰뚫으려면 그 이상의 시간이 필요하며,

그 정도의 수준에 오른 사람은 몇 손가락 안에 꼽을 정도로 적다고 합니다.

이는 개인의 노력이 부족해서라기 보다는,

전체를 꿰뚫으려면 여러 부서에서의 경험이 필요한데 실질적으로 그럴만한 기회를 갖기 힘들기 때문입니다.


이렇게 개발을 한 제품이 출시가 되어,

세간에서 좋은 평을 얻은 경험도 있다고 합니다.

사실, 이런 경험은 모든 개발자가 가질 수 없는 경험입니다. :)


하지만, С군은 홀연히 개발자의 길을 버리고 영업을 길로 넘어갔습니다.

영업직을 갖고 있는 지인들과 얘기도 해보고, 스스로도 많은 고민을 하여 내린 결론이었습니다.


그리하여 현재는 현장에서 엽업하는 사람들을 지원하는 영업지원업무를 하고 있습니다.

영업지원이란 원활한 영엽활동을 위해,

- 전세계에 분포한 공장에 발주를 넣는 것부터 시작하여

- 제대로 부품이 생산되고 있는지 끊임없이 확인하고,

- 궁극적으로는 제품을 생산스케쥴에 따라 생산해내어,

- 배에 선적하여 필요한 곳에 뿌리고,

- 온갖 판매지표를 분석하여 프로모션을 기획하는 일을 합니다.


개발업무와는 상당히 동떨어져 있는 업무이기 때문에,

개발능력 혹은 개발인맥이 영업지원업무에 직접적으로 도움을 주는 것은 없습니다.


다만, 개발업무를 하며 제품개발 프로세스를 체득하였기 때문에,

개발팀의 개발스케쥴은 누구보다 잘 이해하고 있습니다.


그렇지만, 영업지원업무 자체는 학교에서 가르쳐주지 않는 업무이기 때문에,

상경개발을 나온 사람도 대학지식을 참고지식 정도로만 사용할 수 있습니다.

경영학과를 나왔다고 하더라도 그렇지 않은 사람보다 월등하게 잘할 수는 없습니다.


영업지원업무는 오전 8시에 출근하여 오후 8시에 퇴근하는 패턴이라고 합니다.

식사시간을 제외하면 10시간 정도 일하는 셈입니다.

토요일에는 가끔 출근하고 일요일에 출근할 일은 없다고 하네요.


기술센싱이나 마켓트렌드를 분석하여 끊임없이 시장이 원하는 바를 파악하는게 필요합니다.

그런 이해를 바탕으로 제품에 대한 세일즈 전략을 세울 수 있습니다.


궁극적으로 С군은 개발과 영업을 아우르는 Generalist가 될 거라고 생각합니다.

이미 개발업무를 하며 그 능력을 인정받았기에,

(구체적으로 얘기하고 싶은데 신분이 노출될지도 몰라 언급은 않겠습니다)

영업에서도 훌륭한 전략을 많이 세워 혁혁한 성과를 거둘거라 믿어의심치 않습니다.


제조업체의 영업은 지금도 유망하고 앞으로도 창창합니다.

이 분야는 인공지능이 대체하기 힘든 영역이기도 합니다.

새로운 업에서 자기 만의 즐거움을 찾길 바랍니다.




안녕하세요,

골방에 쳐박혀 개발하길 즐기는 윤진입니다.


전 누군가를 멘토링할 정도로 훌륭한 사람이 아닙니다.

게다가 사색을 즐기는 지극히 내향적인 사람이기 때문에,

결단코 먼저 나서서 멘토링을 하지 않습니다.


하지만 왠일인지 지난 8월부터 SCSA 인력에 대해 멘토링을 하게 되었습니다.

이번이 아마 생애 처음이자 마지막으로 진행하는 SCSA 멘토링이겠지요.

멘토로 추천해주신 분의 언변에 홀라당 넘어간 것이 멘토링의 시작이었는데요,

앞으로는 넘어가지 않습니다! 후훗; :)


8월/9월/10월/11월

매달 초에 멘티들과 만났으니 이번 달이 네번째 만남입니다.

여느때와 마찬가지로 멘티들의 시험이 끝나는 날로 일정을 잡았었는데요,

이번 시험은 어찌된 일인지 다음주로 연기되었다고 하네요.

단기간에 소프트웨어 교육을 진행하다보니 여러가지로 사정이 생기겠지요.


SCSA는 '융합지향'의 소프트웨어 개발자를 양성하고 있으니,

멘티들에게 개발의 다양한 측면을 보여주고 싶었습니다.

그래서 첫번째 만남에서만 '개발'에 대해서 신나게 떠들고,

두번째 달부터는 '개발 외의 영역'을 보여주기 위해 여러 주제를 정해 진행하였습니다.

- SCSA 선배들의 진로

- 플랫폼 / 앱 기획

- UX 디자이너

- 개발 UX의 역할


그리고 마지막으로 이번 달에는 개발행사 총괄/기획/진행에 대해 주제를 잡았습니다.

개발자의 테크트리에 행사영역이 있다는 사실에 멘티들도 굉장히 흥미로워하더군요.


이 영역에 대해서는,

그저 개발자일 뿐인 제가 해줄 수 있는 얘기가 많지ㅎ 않습니다.


그래서 평소 개발자 행사에서 발표를 하며 여러가지로 도움을 받았던 조재민 책임연구원님께 부탁드렸습니다.

조재민 책임연구원님은 타이젠 데브랩 행사를 기획 & 진행을 해주신 분이신데요,

SCSA의 취지를 이해하시고 적극적으로 나서주셨습니다.

이 자리를 빌어 감사하단 말씀을 전하고 싶습니다.


조재민 책임연구원님은 개발자 행사를 기획 & 진행하기 위해,

기술에 대한 리더십 뿐만 아니라 외국어에도 능통해야한다는 조언을 해주셨습니다.

외국어에 대한 부분에서 심히 뜨끔하며 격하게 공감되더군요;


그리고 깜짝 손님으로 오픈소스그룹장 한지연 수석연구원님을 초빙해주셨습니다.

아... 평소에 만나뵙기도 힘든 거물이신데,

마지막 멘토링에 유종의 미를 거둘 수 있게 자리를 빛내주셨습니다.


왼편부터 조재민 책임연구원, SCSA 최수웅, SCSA 조예나, 한지연 수석연구원

SCSA 김기현, SCSA 이우진, SCSA 홍소희 그리고 개발자 한분;


한지연 수석연구원님은 개발영역에서 기반을 다지시고,

수년전 사내에서는 다소 생소했던 오픈소스분야를 개척하셨습니다.

초기에는 오픈소스를 가져다가 이용하는 사용자 입장에서 오픈소스를 다루셨지만,

이제는 오픈소스에 컨트리뷰션하고 나아가 리딩하도록 최전방에서 이끌고 계십니다.

Tizen Developer Conference나 Samsung Developer Conference를 총괄하고 계시고,

("[Tizen] TDC 타이젠 개발자 회의 2015 선전 개최" 포스팅 참고)

얼마 전에 1차 예선이 치뤄진 SCPC도 총괄하고 계십니다.

("[대회] SCPC 삼성 대학생 프로그래밍 경진대회" 포스팅 참고)

흥미로운 이야기거리가 잔뜩 준비되어계신 분이라 그냥 보내드릴 수는 없었습니다.


똘똘한 멘티들과 합세하여 열심히 질문공세를 날렸고,

그 중 뼈에 새길만한 이야기를 여기에 남깁니다.

개발자 모두에게 하는 조언도 있고 SCSA에 타게팅된 대답도 있습니다.

녹음을 하지 않은 것에 한탄하며,

조악한 기억력을 짜내보도록 하겠습니다.


질의응답은 크게 아래 카테고리로 진행되었습니다.

- 개발자로서 어떤 족적을 남기며 살아오셨는지 

- 지금은 어떤 일을 하고 계시는지

- 힘들었던 점은 무엇이 있는지

- 어려움을 극복하는 방법이 무엇이었는지

- 우리가 가는 길이 맞는 길인지


한지연 수석연구원님의 경력은 사무실 안에서 흡연이 허용되던 시대까지 거슬러올라갑니다.

비행기나 버스처럼 밀폐된 공간에서조차 흡연이 가능했던 시대였으니,

금연아파트가 등장하는 요즘 기준으로 봤을때는 꽤나 먼 과거입니다.


전산계열 전공을 하신 후 동양, KT를 거쳐 삼성전자에서 개발자의 길을 걸으셨습니다.

(동양이라고 언뜻 들었는데 요즘 가는귀가 먹어서 잘못 들었을 수도 있습니다;)

Software Engineering 분야에서 개발을 위한 툴을 개발하시며,

프로그래머 더 나아가 아키텍트로의 소양을 쌓으셨습니다.


이 정도까지 경력을 쌓았으면,

자기계발 못지 않게 기술전파에도 무게를 실어주어야겠지요?

SE의 특성상 본사 개발자들을 위해 수많은 기술전파교육을 맡아하셨을겁니다.

거기에 더불어 해외연구소에도 파견을 가셔서 본사의 기술을 이식하셨겠지요.


해외연에도 똘똘한 연구원들이 굉장히 많지만,

본사의 기술전파로 해외 연구원들의 성장판에 탄력을 줄 수가 있습니다.

인도와 중국 등에 위치한 연구소에 아키텍트 과정을 비롯하여 개발 과정 전반을 이식하셨다고 합니다.

그 때 성장한 인도와 중국 연구원들이 이번 TDS와 TDC 행사에서 발표자로 맹활약을 할 수 있었죠.


해외연구소 생활을 마치고 복귀한 후부터 오픈소스를 맡으셨습니다.

그 당시에는 오픈소스에 대한 인식이 지금과 같지 않았기에,

고작 한 줌의 연구원들과 함께 오픈소스 전반을 다루셨겠지요.

사내플랫폼에서 사용하고 있는 오픈소스에 대한 관리가 주업무였을겁니다.

하지만, 이제는 오픈소스에 코드를 직접 컨트리뷰션할 수 있도록 길을 터주시고,

나아가 오픈소스그룹에서 기술을 선도할 수 있도록 발판을 마련해주고 계십니다.


거기에 더불어 현재는 삼성전자에서 하는 대규모 외부개발자 행사를 총괄하고 계시는데요,

개발자 행사기획에 관심있는 SCSA 멘티들에게 의미있는 조언을 해주셨습니다.


개발행사기획은 개발자를 대상으로 하는 행사를 기획하는 일입니다.

그렇기 때문에 개발자와 기술을 철저히 이해해야 합니다.

참여자와 발표내용을 이해하지 못하는데 행사를 제대로 진행할 수 있을리 없습니다.

따라서 개발행사기획은 개발영역에서 탄탄한 기반을 닦고 난 후에 해야 합니다.

최소 3~4년 개발을 하며 개발에 대한 감각과 노하우를 익히세요.

개발에 대한 깊이가 없는 개발기획은 그저 기획과 다를바 없습니다.

기획은 개발자가 아닌 다른 영역에 있는 사람들도 할 수 있습니다.


이왕에 소프트웨어 개발자가 되었으니,

장차 어느 테크트리를 타든 소프트웨어 개발을 최소 3~4년을 해야한다고 멘티들에게 이야기했었는데요,

한지연 수석연구원님께서 정확하게 다시 지적해주셨습니다.

일만시간의 법칙을 거들먹거릴 필요없이 3~4년의 기간을 거쳐야만,

얼추 한 사람의 개발자몫은 능히 해내는 수준이 될겁니다.

형편없는 실력의 개발자도 이 기간을 잘 거치면 훌륭한 개발자로 괄목상대할만큼 성장하게 됩니다.


지금의 길에 다다르기까지 수많은 어려움이 있으셨을텐데요,

여성개발자로서 가사와 병행하기 힘들지 않으셨냐는 질문에는,

"가족들이 많은 부분에서 희생을 해주었습니다."라고 답하셨습니다.


남편보다 늦게 퇴근하는 날이 태반이었습니다.

아이들은 왜 시험기간에만 출장을 가느냐고 하기도 했습니다.

하지만, 벌써 수능을 볼 정도로 잘 자라주었습니다.


이런 질문은 여러 곳에서 많이 들으셨겠지요.

다소 담담하게 대답해주긴 하셨지만 감당하기 힘든 순간도 있으셨겠지요.


어느 사회나 그렇듯,

상대가 여자이기 때문에 무턱대고 들이대는 잘못된 잣대가 있습니다.

개발영역에서도 마찬가지입니다.

여성 개발자라는 이유로 근거없이 무시하는 개발자가 있습니다.

그런 개발자의 선입견은 쉽사리 고쳐지지 않습니다.

그렇기 때문에 여성개발자로 살아가는게 그리 녹록치만은 않습니다.

결국 스스로 이겨내어야 하는 부분이 있겠지요.


어려움을 극복해내는 방법으로 가장 간단하지만 가장 강력한 방법을 추천해주셨습니다.

어려움에 봉착했을때 저 역시도 자주 사용하는 방법입니다.


자신의 고민을 털어놓을 수 있는 동료가 필요합니다.

"임금님 귀는 당나귀 귀" 얘기처럼,

맘 속 깊은 곳에 있는 얘기를 꺼내놓으면 그것만으로도 위안이 됩니다.

몇 년 전만 해도 그런 이야기를 나눌 수 있는 여자 동료들이 많았었는데요,

지금은 많이 줄어들었습니다.


마지막으로 제가 다소 맹랑한 질문을 드렸습니다.

"타이젠에 미래가 있다고 생각하시나요?"

우문에 현답으로,

"제겐 종교와 같습니다."라고 답해주셨습니다.


저 역시 마찬가지입니다.

타이젠에 제 젊음 또한 고스란히 들어있습니다. :)

그럴듯하게 만들어놨으니 많은 개발자들이 맘껏 놀고 가길 희망합니다.


한참을 적어놓고 보니,

실제로 한지연 수석연구원님께서 하신 발언과 다를 수도 있겠다는 생각이 들기도 합니다.

그 부분은 그저 제 허물일 따름입니다.


좋은 말씀해주신 한지연 수석연구원님께 감사드립니다.

그리고 더불어 부족한 멘토링을 장장 4개월 동안 인내심으로 감내해준,

김기현, 이우진, 조예나, 최수웅, 홍소희 멘티들에게 감사의 마음을 전합니다.

우면에서 봅시다.


끝_


바로 이전 포스팅에서 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_님.
      처음 뵙겠습니다~
      히어로 개발자가 아니라서 안타깝습니다;
      더 재미난 글을 쓰도록 부단히 노력해야겠네요.
      감사합니다!



일시 : 2015년 7월 30일 ~ 31일

장소 : 인도 남부 벵갈루루 리츠칼튼 호텔

웹사이트 : http://tizendevsummit.com/index.html



인도 남부 벵갈루루의 위치는 위의 지도에서 확인하실 수 있습니다.

7월 30일 기준으로 리츠칼튼 호텔 1박에 28만원입니다.

아직 방이 여유가 있으니 예약하고 싶어지는군요.


타이젠 개발자 회담은 앱 & 플랫폼 개발자를 위한 행사입니다.

올해 인도에서 출시된 Mobile Z1은 물론이고 Wearable, TV, IoT까지 행사내용에 포함되어 있습니다.

앱개발자, 플랫폼 디자이너, ISV업체, OEM업체, 하드웨어업체, 소프트웨어업체 등 기술 컨텐츠에 관심을 가질만한 사람은 누구나 참석할 수 있습니다.

C언어 기반의 Native앱을 개발하는 개발자와 HTML5 기반의 웹앱을 개발하는 개발자 모두에게 이틀동안 타이젠에 대해 설명하는 자리가 되겠군요.


이틀간 열리는 행사에서 흥미로운 주제를 몇 개 뽑아보았습니다.

첫날 점심시간 이후에 열리는 "Breakthrough Games with Tizen"이 흥미롭습니다.



삼성전자 타이젠 R&D 그래픽스팀의 최성열 연구원께서 발표하시는군요.

OpenGl-ES와 DALi 툴킷으로 게임그래픽개발에 대해 설명하는 자리가 되겠네요.


같은 시간에 열리는 다른 세션도 구미가 당깁니다.

드디어 TV SDK가 나오나 봅니다.

삼성전자 타이젠 스마트 TV가 국무총리 대상을 받았는데요.

타이젠 TV에 올라가는 앱을 개발하는 SDK에 대한 세션입니다.

SDK 환경 및 가이드를 해주는 자리가 되겠네요.

C언어 기반의 Native 앱보다는 HTML5 기반의 웹앱을 위한 세션으로 보입니다.


다음 시간에 열리는 세션 중에 웨어러블 세션이 있습니다.

타이젠 플랫폼은 이미 삼성 기어 시리즈에 탑재되어 있습니다.

웨어러블 플랫폼의 주요 기능에 대해 전파하는 자리가 되겠네요.

이 세션 역시 웹앱 위주로 설명하는 자리가 되겠네요.


16:30분부터는 타이젠 UI Framework인 EFL과 DALi에 대해 설명하는 자리도 있습니다.

타이젠 네이티브앱에서 사용하는 EFL과 DALi를 엿볼 수 있습니다.

단지 UI 컴포넌트를 설명하는 자리는 아니고,

scene graph나 opengl 가속렌더링, mainloop, thread 등에 대해 훑어보는군요.

게다가 여기에 DALi라는 3D UI 엔진도 소개할 예정입니다.

1시간이 무척이나 짧아보이네요.


이제 둘째날로 넘어갑니다.

둘째날 아침 10시에 타이젠 플랫폼의 퍼포먼스에 대한 세션이 있습니다.

Z1 스마트폰의 사양을 생각할 때,

부팅속도가 상당히 최적화되어 있다고 생각하는데요.

모바일이나 웨어러블 앱을 최적화하는 툴&팁을 공유하는 자리가 되겠군요.


그 다음 시간에는 IoTivity에 대한 세션도 있습니다.

IoTivity의 API셋을 소개하는 자리가 될 것으로 보이는데요.

Things & 센서 관리 서비스를 엿볼 수 있겠군요.

Protocol Manager Service를 사용하여 OIC 규약에 맞게 다양한 디바이스들을 연결할 수 있다고 하니 실체가 궁금해집니다.

IoTivity는 삼성전자가 리드하고 있는 만큼,

타이젠 플랫폼과도 거리를 좁히고 있나보군요.


둘째날 점심에 열리는 세션에서 타이젠의 방향을 볼 수 있습니다.

타이젠앱은 모바일, 웨어러블, TV에서 동작합니다.

다양한 프로파일, 특히 TV까지 포괄하는 플랫폼은 타이젠이 처음이겠군요.

마무리하는 세션이니만큼 타 플랫폼과 차별화되는 특장점들이 나와주겠군요.


이틀간 열리는 짧은 행사입니다.

플랫폼을 설명하기에 이틀은 터무니없이 짧죠.

그렇지만, 타이젠을 미래의 먹거리로 생각하는 사람에게는 좋은 시작이 되겠네요.


Early bird로 1,999루피(35,000원)에 입장권을 구매할 수 있습니다.

이 정도면 거의 공짜...

이참에 휴가내어 인도로 놀러가야겠군요.


끝_

  1. 김재천 2015.06.27 19:15

    잘봤습니다^^

+ Recent posts