한빛출판네트워크

출처 : 데브멘토

김익환 KAIST 교수(ABC테크 대표)는 글로벌 소프트웨어를 꿈꾸기 위한 5가지 조건으로 조직의 전문성을 들었다. 소프트웨어 공학이라는 말에서 알 수 있듯이 전문성을 갖고 접근해야 한다는 것. 무엇보다 웹2.0의 정신이라 할 수 있는 참여, 공유, 개방의 문화가 필요하다고도 했다.

그는 기업들의 이슈관리시스템 도입을 적극 권유했다. 비행기 조종석의 대시보드처럼 이슈관리시스템은 기업의 가야 할 길을 제시한다는 것. 특히 소프트웨어 개발회사에게는 나침반 역할도 할 수 있다는 것이다.

김 교수는 해외 진출을 위해서는 구체적인 목표가 있어야 한다고 강조했다. 해외에 갈 것인지, 국내에만 머물 것인지를 염두해두고 제품을 기획하고 개발해야 하는 것이 첫 번째. 또한 해외 나가더라도 몇 개국에 나갈 것인지 등 구체적으로 정해놓아야 불필요한 투자가 없다고 강조했다.

김교수는 <글로벌 소프트웨어를 꿈꾸다>라는 책에서도 말했듯이 문서 작성의 중요성을 인터뷰에서 무척 강조했다. 무조건 많이 만드는 것이 중요한 것이 아니라 상황에 따라 적절하게 분량을 스스로 정해 만드는 것이 필요하다는 것이다.

김 교수는 "SW는 기술이 아니라 예술이다“고 주장했다. 똑같은 것을 읽으면서도 어떤 사람은 이해하고 어떤 사람은 이해 못하는 것. SW가 인류 역사상 가장 복잡한 지식산업이고 깨달음이 있어야 한다는 것. 깨달음이 있어야 한다는 것은 단순 기술이 아니라 예술이라고 할 수 있다는 것이다.



Q: 글로벌 소프트웨어를 꿈꾸기 위한 조건은 무엇입니까 ?

조직의 전문성이 필요하다. 전문성이 없을 때는 동네 축구하는 것과 같다. 과거에는 운동 잘하는 사람이 모둔 운동을 잘한다고 했지만, 그것은 아마추어일 때다. 전문성 있는 조직이어야 글로벌 회사로 자랄 수 있다.

"저 사람은 소프트웨어 개발을 참 잘해." 그런 말이 아니고 "저 사람은 어떤 분야를 잘해" 라는전문성이 있어야 하고 그들을 모아서 팀을 만들어야 한다. 조직의 전문성으로 커져야 한다는 것. 우리나라도 많이 좋아졌다. 소프트웨어 공학에 대해서는 미국보다 이론적으로 더 많이 아는 것 같다. 이론적으로 안다는 것은 실행하면 되니까 미래가 있다.

문화적인 측면도 중요하다. 참여, 공유, 개방이라는 웹 2.0 정신이 있어야 한다. 미국에서는 잘 돼 있다. 우리나라에서는 공유하고 나누는 것에 대해 아직은 인색한 것 같다.

Q: 기업들의 SW 이슈관리가 중요하다고 강조하셨는데, 그 이유는?

이슈관리시스템이 중요하다고 생각하는 사람은 많지 않다. 없어서는 안 될 중요한 시스템이다. 이슈관리시스템은 비행기 조종석의 대시보드와 같다. 단순 버그 관리로 생각하는 경우가 많은데, 경영자로서 한 눈에 볼 수 있는 시스템이 이슈관리시스템이다. 대시보드 없이 조종을 한다는 것은 상당히 어려운 얘기다. 대시보드를 보면서 쉽게 일하고, 문제가 생긴 것은 미리 알아서 보완할 수 있다면 얼마나 좋겠는가. 이슈관리시스템은 소프트웨어 회사만 필요한 것이 아니라 보통 기업에게도 필요하다. 다만 소프트웨어 회사들이 더 많은 혜택을 얻을 것임에 강조하는 것이다.

Q: 소프트웨어 회사의 분류와 의미를 둔다면?

분류하는 목표에 따라 달라진다. 정부가 하는 게 있는데, 그것은 소프트웨어 산업을 중흥시키기 위해서 정책을 세우기 위해 부합한 것이 무엇인가로 만들어지는 것이다. 아마존닷컴 같은 소프트웨어 온라인 상점의 분류는 개발자와 소비자가 가장 잘 찾고 살 수 있도록, 즉 매출을 높이기 위해서 만들어진다.

공학적인 측면에서 볼 때는 소프트웨어 근본은 다 똑같다. 분명히 임베디드, 패키지 등 개발 방법은 다르다. 하지만 근본적인 부분은 다 똑같다. (글로벌 소프트웨어를 꿈꾸다라는 책에서는 이 부분에 대한 분류와 의미에 대해 상세히 나와 있다.)

Q: 해외 진출을 위해 필요한 것은 무엇이 있다고 보십니까?

소프트웨어 회사를 만들기 시작할 때 글로벌하게 나갈 수도 있고 아닐 수 있다. 국내에서 성공해 국내에서만 먹고 살기 충분하다. 그게 목적이라면 글로벌하게 할 필요가 없다. 근데, 글로벌 기업이 되겠다고 하면서 국내 기업처럼 활동하면 그것이 잘못이다. 글로벌하게 나갈 때 계획을 세웠다고 한다면 가져야 하는 생각이나 관점이 달라야 한다.

동물원에서 살 것이냐, 거기에서 나갈 것이냐에 따라 전략이 달라진다. 두가지가 있을 수 있다. ‘처음에 국내에서 성공하기, 국내에서만 하고 나서 해외로 나가자’, 이런 방식이 있고, 처음부터 전 세계를 대상으로 아키텍처도 짜고 확장성도 하는 방법이 있을 것이다. 글로벌 회사로 나가겠다고 하는 관점은 전략을 잘 짜야 한다. 몇 나라로 나갈 것이냐. 20개국이냐, 5개국이냐, 아키텍트 자체가 달라진다. 소프트웨어 코딩을 할 때 하드코딩을 하느냐 마느냐 전략이 뭐냐에 따라 소프트웨어도 개발해야 하기 때문이다.

Q: "소프트웨어는 기술이 아니라 예술이다"라는 표현을 하시던데, 그 이유는?

워드프로세스를 잘한다고 소설을 잘 쓰는 것은 아니고, 음악이론을 다 한다고 해서 작곡을 잘하는 것도 아니다. 탬플릿만 있으면 잘할 수 있다는 것은 기법, 기술의 세계에 국한된 것이다. 소프트웨어는 그 단계를 넘어서야 잘 만들 수 있다.

이론적으로 알아도 깨닫지를 못한다. 예를 들어 문서를 만들면 개발시간이 줄어든다라는 말을 하자. 농담하지 말라는 부류가 대부분이고, 그 부분을 깨달은 사람은 많지 않다. 그것을 깨닫는 순간 방법도 눈에 보이고, 문서를 만들면 개발시간이 줄어든다. 그것을 깨달아야 하는데 그것을 깨닫기 어렵다. 그런 깨달음이 예술의 세계다.

기법이나, 템플릿이나, 기술이나 이런 것보다 문서를 만드는 방법, 소프트웨어를 개발하는 방법 등의 가이드라인으로 나와 있지 기법으로 나와 있지는 않다. 바라보는 입장이 기법으로 바라보면 당연한 소리 적어놓은 것이고, 똑같은 것을 읽으면서도 어떤 사람은 이해하고 어떤 사람은 이해못한다. 소프트웨어가 인류역사상 가장 복잡한 지식산업이다. 기법만 갖고는 한계가 있다. 깨달음과 핵심, 예술은 핵심적인 것을 파악해 자기 나름대로 소화해가는 것이다.

Q: 문서 만드는 것을 강조하시던데. 잘 만들기 위해서 어떤 것이 필요하나?

문서를 잘 만든다는 것을 많이 만드는 것으로 생각하는데 착각이다. 문서 만드는 방법 4가지가 있다. 이슈관리시스템에 이슈 하나 등록하는 것. 1분이면 될 일이다. 미국에서 개발할 때 많이 사용하는 한 페이지 문서를 만드는 것, 그것도 있고, 그 다음에 가장 많이 쓰는 30페이지 스펙 문서. 그런 경우도 있고, 수십 개 만들때도 있다. 문서를 만든다는 것은 넷 중에 하나인데, 그 사이에서 뭘 만들어야 한다고 결정하는 것이 어렵다. 그게 예술이다. 누가 지시할 수 있는 사안은 아니니까. 그 사이에 어디에 떨어질 때 결정하는 것이 선택이며, 직감이며, 어려운 것이다. 문서를 만들테니 템플릿 달라는 것, 그것은 기법적인 측면에서 그런 질문 자체가 나오는 것이다.