개발자의 현재와 미래

모 IT기업에 가서 강의한 내용입니다.
개발팀이 청중이었습니다.
그 회사의 시각에서 IT를 생각해보았습니다.

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

※ 다운로드 : SlideShare

00.소프트웨어 개발자

2013년 Daum DevOn에 강의해 주신 분들입니다.
혹시 아는 얼굴이 있나요?
아마 잘 모르신다고 해도, 이분들이라면
우리나라 개발자의 롤모델이어도 괜찮을 겁니다.

01.유명한 사람들?

윗 사람들의 이름은 어떨까요?
모르는 분들이 있나요?
음, 나이들을 한 번 보세요.
주커버그는 1984년생이군요. 젊습니다.
그런데 혹시 이 분들이 롤모델은 아니죠?

02.이분들을 아시나요?

혹시 이 분들은 아시나요?
아마 대부분 처음 보는 얼굴일 겁니다.

그러면 소개해볼께요.
Alan Kay는 OOP의 창시자입니다.
‘미래를 예측하는 가장 좋은 방법은 미래를 창조하는 것이다.’
이런 말을 남겼죠.

Alan Cooper는 Visual Basic의 아버지,
Ted Nelson은 html(Hyper Text)을 만든 사람입니다.

Gerald Weinberg는 소프트웨어 심리학자로 “애자일”의 할아버지입니다.
Lary Wall은 Perl의 창시자구요.

이 분들은 개발자 0세대로 대부분 살아계십니다.
70~80 대죠. 아직도 활동을 하고 계시죠.

어떤가요?
이 분들이 진짜 개발자의 롤모델 아닐까요?

03.국내 사례

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

04.소프트웨어 산업의 미래

영화에서 상상하는 미래는 언젠가는 현실이 되죠.
그러면 위와 같은 시스템은 언제쯤 가능할까요?
지금의 Java Spring으로 가능할까요?

현존하는 개발모델로 “엔터프라이즈호”를 움직이는 시스템을 만들 수 있을까요? 식량보급, 자세제어, 워프, 항로기록 등 내부에 들어가는 시스템 수가 1만개는 넘을 겁니다.
그리고 정말 무장애시스템이어야겠죠.
그렇지 않으면 우주를 떠돌게 될거니까요.

이런 걸 만드려면 하드웨어 말고도, 소프트웨어가 해야할 일이 엄청스레 많죠.
바로 이런 미래를 만들어야 하는 사람들이 소프트웨어 개발자들입니다.

05.현실

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

06.컴퓨팅 환경의 역사

슈퍼컴퓨터였던 CDC-6600은 라즈베리파이보다도 40배 느렸고,
크레이는 펜티엄3 정도와 성능이 비슷했다고 합니다.
이 시기는 컴퓨터를 만들기 위해 인간에 대한 연구와 프로그래밍 언어가 눈부시게 발전한 때였습니다.
이후 PC가 발전하고 스마트폰이 등장했습니다.
이런 위대한 변화가 일어나는데 불과 70년 밖에 걸리지 않았습니다.

07.소프트웨어 시장

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

08.소프트웨어의 역할변화

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

09.사람의 속도

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

10.무엇이 없을까?

엔터프라이즈호를 만들어야 하는 미래를 생각해보면,
IT는 앞으로 한참 더 발전해야 합니다.
몇 세대가 지나야 할 것 같습니다.

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

11.프로젝트 팀

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

12.왜 팀이 필요한가?

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

13.잰 걸음

품질도 마찬가지입니다.
경험상 품질은 기술이 아니라 개발자의 시간과 땀을 먹고 조금씩 좋아집니다.
품질은 디테일이기 때문입니다.
품질활동은 그만두면 계속 떨어집니다.
목표가 되는 사업 요구사항이 계속 변하기 때문입니다.

14.한번에 짓기

오버엔지니어링은 SI에서 많이 나타나지만 일반기업도 작지는 않습니다.
국세청 사이트는 대표적인 오버 아키텍쳐링 사례입니다.
프로젝트 종료 후에는 수정하기 어렵기 때문에 가능한 모든 경우를 고려하여 시스템을 구축합니다.
그러다보면 발생확률이 1%인 문제를 걱정해서 50%의 사용성을 희생시키기도 합니다.
그런데 서비스업은 돈을 버는 것이 목적이지, 규제 지키기가 목적이 아닙니다.

15.시스템과 조직문화

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

16.왜 애자일인가?

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

객체지향언어는 절차형일 때보다 훨씬 구현과 배포도 자유로웠습니다.
2001년 선언을 통해 일하는 방법을 바꿉니다.
그게 애자일입니다.

그런데 애자일은 들여다 보면 결국 사람 이야기입니다.
소프트웨어 회사는 훈련된 개발자가 핵심자산입니다.

17.IT회사의 자산

기술자산을 쌓는 이유는 품질이 한 번에 좋아질 수 없기 때문입니다.
그래서 기술자산을 자꾸 열어보고 개량할 수 있게 해야 합니다.
그리고 개발자들이 기술자산을 이용해 새로운 것을 계속 만들어보게 하는 것입니다.
이들은 서비스를 직접 만든 사람이기 때문에 변형도 자유롭게 합니다.
이것이 우연성을 만들어 냅니다.
최근의 글로벌화는 Developer시장을 먼저 공략합니다.
그들이 사업파트너를 찾는 징검다리 역할을 하기 때문입니다.
서비스업에서 개발자들은 사업전파의 매개자이자,
새로운 기회를 만드는 역할을 합니다.
물론 이후에는 사업이 붙어야 합니다.

18.적정기술

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

19.좋은 개발팀

애자일이 만능은 아닙니다.
생산공정이 안정되어 있고 분업화 효율이 중요한 곳에 가서,
애자일 이야기 하면 바보취급 받습니다.

그래서 우리팀의 일을 잘 정리해보고,
어떻게 일해야 큰 효과를 낼 수 있는지 고민해 볼 필요가 있습니다.

20.소프트웨어 개발자

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

21.개발자가 필요한 곳

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

22.개발자의 미래

인생 1,2,3막을 이렇게 나누는 기준은 일본에서 시작된 것으로 알고 있습니다.
아마 우리나라 경제활동의 구조가 일본을 베꼈기 때문일 것 같은데요.
실리콘밸리의 개발자들이 인생 3막을 살고 있는 것에 비해,
우리나라의 베테랑들은 현재 2막을 지나고 있습니다.
그래서 롤모델로 삼을 만한 분들이 아직 많지 않습니다.
그러다보니 개발자들의 미래에 대한 불안들이 다양하게 나타나고 있습니다.

23.개발자의 자산

개발자의 가장 큰 무기는 직접 무언가를 만들어볼 수 있다는 것입니다.
자신을 위한 Product를 만들어 보십시요.
첫술에 배부르진 않습니다.
그런데 무얼 만들려면 동기가 있어야 합니다.
동기를 찾기 위한 시간을 가져보십시요.

또한 개발자는 평판이 매우 중요합니다.
왜냐하면 60이 넘어도 일할 수 있는 몇 안되는 직업이기 때문입니다.

24.내가 얻은 교훈

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

25.다시 일하고 싶었던 개발자

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

26.만나고 싶지 않은 개발자

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

27.주관과 철학

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

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

28.배우기

이제까지 우리는 주로 실리콘밸리를 벤치마킹했습니다.
유럽 쪽 IT는 아닙니다.
그러나 실리콘밸리가 IT업계 전체를 바꾸고 있다는 것도 인정해야 합니다.
하지만 모두 좋은 건 아닙니다.
해보고 맞는 것은 선택하고 맞지 않은 것은 포기하세요.

29.당장 해야 할 일은

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

끝.