창의와 열정, 소프트웨어 엔지니어

창의와 열정 ,Software 엔지니어2011 년 5 월 25 일윤경구

차례

1. Software 는 지식 노동2. 두뇌 구조와 지식 노동3. 좋은 엔지니어4. 당부참고 : SW R&D Survival Guide

2/18

3

SOFTWARE 는 지식 노동

Software 주도 Smart 혁명 4/18

SW 가 HW 를 리드

• Hardware• 차별 한계 : 시장 경쟁 심화 , 기술 차별성

약화• 기술발전 방향의 변화가 많지 않음

• Software• 무궁무진한 창의가 발현되고 적용 가능• SW 의 진화 방향이 매우 다양

5/18

지식 노동의 산물 SW

• SW 가 인간의 삶 요소에 침투하는 시점 ( 무한대의 경우의 수 )• 구글이 주도한 클라우드 기반의

Machine Learning 이 응용 분야를 확대 . 점점 가치있는 정보를 만들어 . 클라우드가 인간의 뇌를 특정 영역에서는 훨씬 능가하는 거대한 인공지능화• 터미네이터의 스카이넷

6/18

지식 노동의 요소

•전문지식 ( 숙련 )• 기본 지식 외에 분석 능력 , 통찰 능력의

결합 필요로 하는 지식 노동•창의• 즉자적으로 추론되지 않는 아이디어를

동력으로 하는 지식 노동• 한계를 두지 않는 생각이 중요

7/18

8

두뇌 구조와 지식 노동

좌뇌와 우뇌의 비대칭

• 좌뇌• 직렬처리 방식• 논리성• 자아 인지• 몸의 오른쪽에 연결

• 우뇌• 병렬처리 방식• 몸의 왼쪽에 연결

9/18

지식 노동의 개선 방법

• 전문지식 ( 숙련 ) 의 향상• 순차적 논리성 , 귀납과 연역을 교차한

지적 추상화 능력을 끊임없이 발전시켜야

• 창의의 향상• 생각을 막지 말고 끝없이 의문을 던져야

• 핵심은 집중 , 생각의 몰입

10/18

11

좋은 SW 엔지니어

코딩 능력 향상법

• 탑다운 코딩• 소설을 쓰듯 논리적으로 탑다운 코딩• 코딩 완료하기 전에는 컴파일하지 말라• 논리 장악력이 떨어진다• 비논리적인 코딩은 우연에 의존하는 것 . 발전이 없음

• 배치로 개인 업무 관리• 지식 노동은 인터럽트를 최소화하고 생각의 연속성 필요• 컨텍스트 스위칭이 되기 때문 .

• 순차적으로 집중해서 코딩하고 완성되면 컴파일해서 에러 고치고 , 디버깅하라 .

• 모든 논리에 단위 테스트를 작성하는 습관을 들여라 .• 의심나는 논리는 손으로 (작은 코드 작성하여 ) 검증 .

12/18

아키텍처 능력 향상법

• 숙련이 필요• 시스템 아키텍처를 잘 이해하는 사람들과

함께 해야 빠르고 제대로 배울 수 있다 .

• 지적 추상화 능력• 핵심 아키텍처 혹은 이슈를 논리적으로

추상화해낼 수 있는 훈련이 반복적으로 필요

13/18

14

당부

기업가 정신 Entrepreneurship

• 창업 바람이 있지만 좀더 많은 것을 제대로 배울 수 있는 환경을 택하라 .

• 너무 일찍 창업하면 돈과 영업은 알지 몰라도 기술은 배울 기회가 없다 .• 학교에서 배운 것은 ( 특히 SW 는 ) 기업에서는 출발점도

안되는 경우가 대부분이다 .

• 판단을 기업가의 입장에서 하는 습관을 가지면 기업 환경의 결정들을 이해하는 데 도움이 된다 . ( 내가 사장이라면 ?)• 관리자로 성장하거나 창업하는 데 도움이 된다 .

15/18

엔지니어의 자세

• 끊임없이 평생을 배워야 한다 . ( 지식 노동의 특성 )• 끊임없이 “왜”라는 질문을 던지며 생각의

수준을 높여가야 한다 .• 자기 머리로 이해하고 생각하지 못하면 지식

노동에서 가장 단순한 반복 노동밖에 하지 못한다 .

• 배우는 것을 , 도전하는 것을 두려워하지 말라 .

16/18

결어

• SW 엔지니어는 자부심이 필요• 전문지식의 숙련도와 통찰력을 높이고 창의적 지식 노동의

비중을 높이려면 엄청난 도전과 노력이 필요 .• 단순 노동자보단 지식 노동자를 선택하길

• 기업에는 항상 기술을 주도하고 발전시키는 부류와 불평 , 불만에 급급해 자기 발전을 못하는 부류가 자석의 양극처럼 존재• 어느 극쪽으로 자신의 존재를 위치시킬 것인가 ?• 지금 당장의 기업을 볼 것이 아니라 자신의 발전을 중시하라 .

• 더 나은 엔지니어가 되려면 자료구조 , 알고리즘 나아가 확률 통계 등 수학 기반을 잃지 않도록 노력하길

17/18

참고 : 연구원 SURVIVAL GUIDE ( 비공식 )

발표 능력 = 사고 능력 = Software 능력= 추상화 능력 + 수학적 기반

명확한 개념

추상화

아키텍처 능력

정확한 이해

Metaphor ( 은유 )

• 적절한 Metaphor ( 은유 )

• 구체적인 상을 머리속에 그려야• 좋은 비유는 연역을 쉽게 하며 창의의 중요한 동력이 된다

• 정확한 이해의 전제• 엄밀한 개념 구분• 각 개념들의 metaphor 들이 잘 짜여져 살아있는 것처럼 느껴질 때

비로소 개인의 view 에서 정확한 이해에 가까이 간 것• 발표는 개인의 개념적 이미지들에 대한 집단적 공유 및 검증 과정• 설명할 수 없다면 이해한 것이 아니다

Terminology ( 용어 )

• Self-Explanatory Terms• 소집단에서만 사용되는 독특한 은어나 , 내부에서 편의적으로 사용하기 위해 원래 의미를 변형한 용어 사용 금지

• 보편적인 용어를 사용하여 표현할 수 있어야 (보통명사화 )• 충분한 감성적 이해를 수반하지 않을 경우

외래어 / 영어 / 전문어 등 “좋은 단어” 사용 금지

논리적 추상화

• 분석에 기반한 추상화• 세부 내용에 의해 뒷받침되어야 (bottom-up)• 개념 구체화 과정1. 선험적 직관에 의한 가설 / 개념 설정2. 세부 사실에 의한 가설 / 개념 검증3. 가설 / 개념의 재설정 및 검증 반복

• 논리 전개는 top-down• 논리 전개 즉 , 발표는 추상화 기반에서 top-down• 내용이 많으면 적절히 분류 분할하여 명확하게 전달할 수

있는 단위로 축소하여 재구성

아키텍처 능력

• Software 의 각 논리적 역할에 기반한 구성• 각 모듈 , 라이브러리를 Role 에 기반하여

개념 분류 및 추상화• Role 기반 분류는 Objected Orientation 원칙과도 부합

• System View 와 논리 역할 View 는 구분해서 접근