Karen
15k
2018-01-16 13:44:47
3
8042

개발자의 삶 - 개발자의 현재와 미래



*에디터 주 : 해당 칼럼은 김수보 소장님께서 2015년 4월에 게시하신 글입니다. 시간이 많이 흐르긴 했지만, 지금도 많은 인사이트와 도움을 준다고 판단하여 올리오니 참고하시어 읽어주세요~ :)




모 인터넷 기업의 개발팀에게 강의한 내용으로 그 분야의 시각에서 IT를 담아보았습니다.

‘난 어디에 서 있지?’. ‘트렌드에 뒤쳐져서 혹시 도태되고 있는 게 아닐까?’하고 불안해 하는 분들에게 도움이 되었으면 합니다.


※ 파워포인트 다운로드 : http://www.slideshare.net/kimsubo/ss-46844044


1. 2013년 Daum DevOn에 좋은 내용으로 강의를 해주신 분들입니다. 혹시 아는 얼굴 있으신가요? 이 분들이라면 아마 우리나라 개발자의 롤모델이어도 모자람이 없을 듯 싶습니다.



2. 저는 올레맵 개발을 지휘했고 나중에는 아임IN을 고도화하다가 나왔습니다. 최초 버전을 만들 때는 참여하지 않았습니다.





3. 아래 분들의 이름을 모르는 분들이 계실까요? 나이들을 한 번 보세요. 주커버그는 1984년생이군요. 젊습니다. 혹시 이 분들이 롤모델이신가요?




4. 그런데 이 분들은 아시나요?

Alan Kay는 OOP의 창시자입니다. ‘미래를 예측하는 가장 좋은 방법은 미래를 창조하는 것이다.’라는 유명한 말을 남겼습니다.

Alan Cooper는 Visual Basic의 아버지이고 Ted Nelson은 Hyper Text를 만들었습니다.

Gerald Weinberg는 소프트웨어 심리학자로 애자일의 할아버지입니다.

Lary Wall은 Perl의 창시자입니다.

이 분들은 개발자 0세대로 대부분 70~80대입니다. 이 분들이 개발자의 진짜 롤모델이 될 수 있지 않을까요?



5. 국내 사례는 강의를 통해서 이것 저것 말씀드렸습니다.



6. 영화에서 상상하는 미래는 언젠가는 현실이 됩니다. 그런데 아래와 같은 시스템을 만드려면 현재 Java로 가능할까요?

현존하는 개발모델로 엔터프라이즈호를 움직이는 시스템을 만들 수 있을까요? 식량 보급, 자세 제어, 워프, 항로 기록 등 시스템 수가 약 1만 개는 넘게 들어가지 않을까요? 그리고 어떤 시스템은 정말 무장애 시스템이어야 할 겁니다. 우주선이 급발진되면 큰일입니다.

바로 이런 미래를 만들어야 하는 사람들이 소프트웨어 개발자들입니다.



7. 하지만 오늘의 현실입니다. 힘들고 삽질하는 건 전 세계적으로 비슷한데요. 재미있는 건 1975년에 실리콘밸리에서도 똑같은 생각을 했다는 것입니다. 시스템이 깨끗하게 유지되기 힘든 건 옛날에도 마찬가지였던 것 같습니다.



8. 슈퍼 컴퓨터였던 CDC-6600은 라즈베리파이보다도 40배 느렸고, 크레이는 펜티엄3 정도와 성능이 비슷했다고 합니다. 이 시기는 컴퓨터를 만들기 위해 인간에 대한 연구와 프로그래밍 언어가 눈부시게 발전한 때였습니다.

이후 PC가 발전하고 스마트폰이 등장했습니다. 이런 위대한 변화가 일어나는데 불과 70년 밖에 걸리지 않았습니다.



9. 통신이 발달되니 사업 환경이 변하고 기술 환경이 변합니다. 하드웨어가 저렴해지면서 범용 하드웨어 상에 소프트웨어를 이용해 다양한 기능을 제공하는 방향으로 환경이 변하게 됩니다.



10. IT기술이 발달되면서 통신인프라와 소프트웨어를 이용한 서비스업이 발전하기 시작합니다. 그래서 자꾸 소프트웨어를 변경해야 할 필요성이 생깁니다.



11. 보험설계사가 되면 훌륭한 라이프 플래너로 만들기 위한 다양한 교육 프로그램이 존재합니다. 하지만 IT는 아직 그렇지 못합니다. 훌륭한 개발팀장이 되는 법, 훌륭한 개발팀을 만드는 법 등은 책도 없고 누가 가르쳐 주지도 않습니다.



12. 엔터프라이즈호를 만들어야 하는 미래를 생각해보면 IT는 앞으로 한참 더 발전해야 합니다. 몇 세대가 지나야 할 것 같습니다. 지금의 개발자들은 그 역사의 시작점에 서 있습니다.

반대로 이야기하면 그만큼 여러가지 노하우나 기술의 부족에 시달리고 있다는 뜻입니다. 그래서 현재 개발자들의 역할과 태도들이 매우 중요합니다. 능동적이고 적극적인 마인드가 중요합니다.



13. 우선 개발팀에 대해 이야기해보겠습니다.

2013년 실리콘밸리의 개발자가 블로그에 올린 그림입니다. 팀 프로젝트는 우리나라만 그런 것이 아닌 모양입니다. 누군가 혼자서 99%의 일을 다 하고 대부분은 말로만 도와준다고 합니다. :-)



14. 자동차는 모든 부품을 처음부터 만들지 않습니다. 많은 부품을 재활용합니다.

훌륭한 시스템도 많은 컴포넌트나 라이브러리들이 필요합니다. 그래서 마찬가지로 소프트웨어도 부품을 재활용할 수 있는 인프라가 매우 중요합니다.(소스,컴포넌트,라이브러리,프레임워크 등)



15. 품질도 마찬가지입니다. 경험상 품질은 기술이 아니라 개발자의 시간과 땀을 먹고 조금씩 좋아집니다. 품질은 디테일이기 때문입니다.

품질 활동은 그만두면 계속 떨어집니다. 목표가 되는 사업 요구사항이 계속 변하기 때문입니다.



16. 오버 엔지니어링은 SI에서 많이 나타나지만 일반 기업도 작다고는 할 수 없습니다. 국세청 사이트는 대표적인 오버 아키텍쳐링 사례입니다. 프로젝트 종료 후에는 수정하기 어렵기 때문에 가능한 모든 경우를 고려하여 시스템을 구축하는 것입니다.

그러다보면 발생확률이 1%인 문제를 걱정해서 50%의 서비스 사용성을 희생시키기도 합니다. 그런데 서비스업은 규제를 지키는 것이 목적이 아닙니다.



17. 1968년 ‘모듈화 학술포럼’에서 멜빈 콘웨이가 이런 말을 합니다. ‘훌륭한 시스템은 훌륭한 조직(소통구조)이 만든다.’ 좋은 조직 문화가 없으면 좋은 개발자가 들어와도 훌륭한 시스템이 만들어지지 않습니다.



18. 전통적인 소프트웨어 공학은 메인 프레임을 움직이기 위한 도구로 시작되었습니다. 하드웨어가 중요하던 시절 코볼과 같은 절차형 언어와 함께 만들어졌습니다. 그래서 먼저 완벽한 설계가 끝나야 구현을 할 수 있었습니다. 그래서 건설적인 방법을 차용해도 문제가 없었습니다.

그러나, 점차 실리콘밸리 개발자들은 기존의 공학이 일하기에 불편하다고 느꼈습니다. 객체지향언어는 절차형일 때보다 훨씬 구현과 배포도 자유로웠습니다.

그래서 2001년 선언을 통해 일하는 방법을 바꿉니다. 그것이 애자일입니다. 그런데 애자일은 들여다 보면 결국 사람 이야기입니다. 소프트웨어 회사는 훈련된 개발자가 핵심 자산입니다.



19. 기술 자산을 쌓는 이유는 품질이 한 번에 좋아질 수 없기 때문입니다. 그래서 기술 자산을 자꾸 열어보고 개량할 수 있게 해야 합니다. 그리고 개발자들이 기술 자산을 이용해 새로운 것을 계속 만들어보게 하는 것입니다. 이들은 서비스를 직접 만든 사람이기 때문에 변형도 자유롭게 합니다. 이것이 우연성을 만들어 냅니다.

최근의 글로벌화는 Developer시장을 먼저 공략합니다. 그들이 사업 파트너를 찾는 징검다리 역할을 하기 때문입니다. 서비스업에서 개발자들은 사업 전파의 매개자이자 새로운 기회를 만드는 역할을 합니다. 물론 이후에 사업이 붙어야 합니다.



20. 레진코믹스의 개발자들도 대부분 10년 이상의 베테랑들입니다. 그런데 레진은 구글의 PaaS를 선택했습니다. 몰라서가 아니라 그 선택이 적정했다고 판단했기 때문입니다. 그런 선택을 “적정기술”이라고 부릅니다.



21. 애자일이 만능은 아닙니다. 생산 공정이 안정되어 있고 분업화 효율이 중요한 곳에 가서 애자일 이야기 하면 바보 취급 받습니다. 그러나 우리 팀의 일을 잘 정리해보고 어떻게 일해야 큰 효과를 낼 수 있는지 고민해 볼 필요가 있습니다.



22. 개발자 이야기 해보겠습니다. 아래 그림은 캐나다, 미국, 아르헨티나 등 전세계에 떠돌고 있는 그림입니다. 글로벌하게 비슷하게 느끼고 있는 듯 합니다. 그런데 디자이너가 보는 개발자는 정말 배 나온 뚱보인가요? ㅠㅠ (배 나와서 찔리는 1인)



23. 공장의 로봇 프로그램은 베이직이나 파스칼을 이용해서 짭니다. 절차형 언어가 좀 느리더라도 확실하고 안정적이기 때문입니다. 포트란은 메모리나 포인터 연산 없이 복잡한 행렬 연산을 간단하게 짤 수 있는 좋은 언어입니다.



24. 인생 1,2,3막을 이렇게 나누는 기준은 일본에서 시작된 것으로 알고 있습니다. 아마 우리나라 경제활동의 구조가 일본을 베꼈기 때문일 것 같은데요.

실리콘밸리의 개발자들이 인생 3막을 살고 있는 것에 비해 우리나라의 베테랑들은 현재 2막을 지나고 있습니다. 그래서 롤모델로 삼을 만한 분들이 아직 많지 않습니다. 그러다보니 개발자들의 미래에 대한 불안들이 다양하게 나타나고 있습니다.



25. 개발자의 가장 큰 무기는 직접 무언가를 만들어볼 수 있다는 것입니다. 자신을 위한 Product를 만들어 보십시요. 첫 술에 배부르진 않습니다.

그런데 무얼 만들려면 동기가 있어야 합니다. 동기를 찾기 위한 시간을 가져보십시요. 또한 개발자는 평판이 매우 중요합니다. 왜냐하면 60이 넘어도 일할 수 있는 몇 안 되는 직업이기 때문입니다.



26. 제가 개인적으로 느꼈던 교훈들입니다.



27. 뛰어난 개발자보다는 좋은 개발자가 되십시요. 개발은 협업을 기본으로 하기 때문입니다. 개발은 혼자서 할 수 있는 일이 많지 않습니다. 시스템이 커질수록 협력 능력이 매우 중요합니다. 두 번째로 중요한 요건은 발전 동기입니다. 발전 동기가 강한 사람은 누구나 탐을 냅니다. 물론 흔치 않습니다.



28. 10,000개 이상의 라이브러리를 혼자 만들고 관리할 수 있다면 협업 능력은 없어도 되는 걸로…인정하겠습니다.



29. 병원에 와서 환자들이 ‘머리가 아프고 열이 나니 감기약을 처방해 주세요.’라고 말하고 의사들이 ‘네 선택하신 대로 처방해 드릴게요.’라고 한다면 올바른 의료행위라고 할 수 없습니다.

마찬가지로 IT도 그렇게 된다면 앞에서 상상했던 미래는 절대 오지 않습니다. 개발자들이 의사처럼 전문적인 소견(의견)을 제시하고 기술에 대해 책임 있는 의사 결정을 할 수 있어야 합니다.

스스로 전문 직업으로 대우하지 않으면 남들도 그렇게 대우하지 않습니다.



30. 위의 변화는 주로 실리콘밸리를 대변합니다. IT 업계 전체는 아닙니다. 그러나 실리콘밸리가 IT 업계 전체를 바꾸고 있다는 것도 잊으면 안 됩니다. 들여다보고 좋은 것은 선택하고 맞지 않은 것은 내려 두십시요.



31. 우선 좋은 취미를 하나 골라보세요. 그리고 그걸 소프트웨어로 만들어보십시요. 세상이 달라 보일 겁니다.







김수보 소장님 블로그 - IT의 중심에서  


4
  • 댓글 3

  • isNotEmpty
    2018-01-17 08:44:00

    29. 병원에 와서 환자들이 ‘머리가 아프고 열이 나니 감기약을 처방해 주세요.’라고 말하고 의사들이 ‘네 선택하신 대로 처방해 드릴게요.’라고 한다면 올바른 의료행위라고 할 수 없습니다.

    마찬가지로 IT도 그렇게 된다면 앞에서 상상했던 미래는 절대 오지 않습니다. 개발자들이 의사처럼 전문적인 소견(의견)을 제시하고 기술에 대해 책임 있는 의사 결정을 할 수 있어야 합니다.

    스스로 전문 직업으로 대우하지 않으면 남들도 그렇게 대우하지 않습니다.




    이 말이 가장 마음에 와닿네요.

    좀 더 소신있게 개발해야겠습니다.

    좋은 글 잘 읽었습니다.

  • 기분전환
    1k
    2018-01-19 21:00:31

    마음을 울리는 글이네요.. 정말 잘 봤습니다

  • 모티
    3
    2018-01-26 23:37:42

    40대 초반 대기업에서 아직 개발은 끈을 놓지 않고 코딩하고 있는 한 사람으로써 여러가지 생각을 많이 하게 되는 내용입니다.

    SW후진국이라고 냉소적인 자세로 조직탓 문화 탓 만 하는 나에게는 참으로 반성이 될 만 한 내용이었습니다.

    개발의 미래가 치킨도 아니고 매니저 아니길 바라는 한 사람으로써 개발자 모두 응원합니디/

  • 로그인을 하시면 댓글을 등록할 수 있습니다.