실용기술 vs 기반기술

링크

이렇게 남의 것을 습득하는 것에 머무르다 보니, 실제로 머리를 써야 하는 것은 단순한 트릭 같은 것이다. 어떤 문제 상황이 주어졌을 때, 이것이 가진 의미가 무엇인가, 왜 이런 문제가 발생했는가, 일반해를 찾자면 어떻게 되는가, 더 좋은 방법은 없는가와 같은 고민은 전혀 하지 않은 채, 3일 내로 이 문제가 발생하는 것을 막으려면 툴에서 무슨 옵션을 써야 하는가와 같은 지극히 '실용적인' 문제로 치환하게 된다. 문제의 본질을 해결하려는 노력을 하지 않기 때문에, 딱히 대단한 기술 개발이 되지를 않는다. 전부 ad hoc 방식으로 해결하고, 논문이나 특허로 발전시키기 힘든, 혹은 그 수준이 높지 않은 것이 되기 ..

실제로 삼성에서 소프트웨어 개발하면서 위와 같은 경우가 비일 비재했다. 

대부분의 소프트웨어 모듈들은 외부에서 가져다 쓰고 주로 모듈들을 짜집기하는 일들이 많았었는데 접근법이 딱 위에 기술한 대로다.

하지만 이걸 잘하는 사람이 있고 실제 잘 못하는 사람이 있다. 대략 SW라는게 모듈화가 잘되고 API가 정의가 잘되있어도 꼭 아구가 잘 들어맞지 않는 경우가 많고, 특이한 문제는 모듈이 결합하기 전에는 드러나지 않는 경우도 많다.

대략 이런 인테그레션 잡에 특화되려면 여러 프로젝트에 참여하고 주요 모듈들을 다루어 보면서 경험이 쌓여야 하는데, 

• 노하우가 쌓이기 전에 매니져 트랙으로 넘어가는 경우

• 의지나 감각 부족으로 끝까지 파고들지 않고 땜빵식으로 시간만 때우면서 노하우가 않쌓이는 경우

• 프로젝트에서 메인 잡을 못잡고 계속 프로젝트의 허드레일만 해서 노하우가 안쌓이는 경우

등으로 10년이 지나도 제대로 못하는 사람도 많이있다. 요는 링크내용과 달리 10년이 지나도 이걸 제대로 못하는 사람이 많다.

대략 보면 이전에 결합한 적이 없던 이질적인 두개의 SW영역이 결합하는 경우 두개 영역을 결합하는 인테그레션 잡의 퀄리티는 작업시 엔지니어의 숙련도에 크게 좌우되고, 잘 맞추어진 tool이나 자동화로 cover가 안되는 부분이 있다.

바로 이런 부분에 SW엔지니어가 공헌할 영역이(이렇게 쓰고 돈을 벌 영역이라 해석한다) 있다. 그리고 요런 부분에서 속도감이 있어야 시장에서 치고 빠지는 전략을 쓰는게 가능하다.

안드로이드가 처음 나왔을때 (진저브레드 정도), Google은 Android소스와 API는 공개했지만 실제 내부 프레임워크 구조를 자세한 설명한 Document을 공개하지 않았다. 그런데 진저브레드 정도만 해도 안드로이드 프레임워크 내부에 버그가 많았고 프레임워크 자체도 불안했는데, 결국 안드로이드 폰 만드는 회사들이 안드로이드를 안정화 시키고 버그를 잡는데 순전히 숙련도에 의존했어야 했다, 그런 부분에서 삼성이 잘했었다.

초기 Gallaxy모델은 불안정한 안드로이드를 순전히 인테그레션 숙련도로 커버해서 쓸만한 모델을 만들어낸 예다.

물론 요즘은 Android프레임워크 자체가 이미 성숙된 상태이고 Google이 프레임워크 내부 구조에 대한 Document를 Open하고 있어서 인테그레이션 난이도가 낮아져 초기 진입하는 폰회사들도 괜찮은 수준의 모델을 만들어 낼수 있다.

삼성이 Tizen에서 죽을 쓰고 있는것을 보면 인테그레이션 잡같은 '실용적인'문제를 풀던 기술로는 새로운 프레임을 만들어내기는 여전히 어렵다는것도 알수 있으나 '실용적인' 문제푸는 능력도 사실 그리 쉽지 않다.

만일 내가 가진 능력이 '실용적인' 능력이라면 그쪽으로 매진해라, 여러 SW 영역이 합종 연횡하고 있는 시기라 분명 그쪽에도 길이 있을 것이다.