http://subokim.wordpress.com/2013/04/21/what-is-user/

유저학 개론

비즈니스 세계에서 소비자, 고객은 매우 중요한 요소입니다.
성공과 직결된 요소이므로 그들에 대한 연구를 게을리 하지 않습니다.

반면, 아직 인터넷 시장에서는 ‘소비자’, ‘고객’, ‘사용자’ 등이 혼재되어서 사용되고 있습니다.
하지만, 명백히 다르므로 이것을 분류해서 이해하고자 합니다.

※ 참고
1. 국부론, 김수행 역, 비봉출판사
2. 경영학의 실체, 피터드러거
3. ‘고객, 클라이언트, 소비자’ 작지만 큰 차이, 조지틸먼

---

(아이패드를 보고 있는 아기는 사용자일까, 소비자일까, 고객일까?)

1. 소비자, 사용자, 고객

• 사용자(User)
물건의 기능을 이용하는 사람
리모콘을 사용한다고 하지 소비한다고 하지는 않습니다.
제조업에서 많이 사용한다.
기능은 물건을 팔리게 만드는 가치와 직결된다.
사용자는 기능을 어떻게 만들 것인가라는 고민에서 출발한다.
• 소비자(Consumer)
물건(또는 가치)를 이용해서 사라지게 하는 사람
음식물은 먹어서 없애는 거죠. 소비한다고 합니다.
생산, 공급, 소비 (=시장)로 나뉘는 경제학에서 주로 사용한다.
• 고객(Customer)
물건(가치)을 돈을 내고 사는 사람 또는 대상.
유통이나 마케팅 등 Sales 파트에서 주로 이야기한다.

2. 서비스를 발전시키는 키워드, 사용자(User)

사용자는 기능을 사용함으로써 자신의 욕구를 해소합니다.
그래서 좋은 서비스는 기능을 자꾸 사용하도록 사람의 욕구를 건드립니다.
사람은 욕망의 화신이기 때문에, 욕구를 건드리는 서비스는 오래 갑니다.
욕망이란, 큰 것부터 자질구레한 것까지 다양한 것이 있습니다.

얼마나 어떻게 욕구를 건드리는가 하는 것이, 서비스의 존속가치를 결정하는 것 같습니다.

3. 비즈니스 모델의 키워드, 소비자(Consumer)

가치를 소비하는 사람이 있어야 생산하는 사람이 삽니다. 
돈이 돌고 도는 게 아니라 가치가 돌고도는 겁니다. Value Chain 이라고 부르지요.

가치의 흐름은 예측가능하지 않습니다. 짐작해볼 수는 있지요. 과거에는 가치의 흐름을 생산자가 예측한대로 움직이게 하는 것이 중요했습니다만, 요즘에는 가치를 누구나 사용할 수 있도록 개방하고 접근성을 높여 시장이 가치흐름을 자율적으로 만들 수 있게 합니다.

하지만 , 돈을 벌려면 역시 가치흐름은 통제 되어야 합니다.
그리고 가치흐름은 절대 혼자 커지지 않습니다. 다양한 소비패턴에 의해 증가합니다.
따라서 ‘적절한 제휴’는 비즈니스 모델 뿐 아니라 서비스의 성장에도 매우 중요합니다.

어떤 것이 소비되고 있는지를 잘 파악하는 것이 매우 중요합니다.
소비되는 가치를 발견할 수 없다면 엉뚱한 것을 생산하다가, 고비용으로 사업이 쓰러질 수 밖에 없습니다.

4. 사업을 발전시키는 키워드, 고객(Customer)

소비자는 사실 사람보다는 소비되는 재화, 가치에 집중된 단어입니다.
고객은 사람을 표현하는 말입니다. 고객은 B2C, B2B의 고객일 수도 있습니다.

고객은 돈을 지불하고 제품을 사는 사람을 말합니다.
지불과 산다는 것에 초점이 맞추어진 용어입니다.

사업이란 재화를 팔아서 이윤을 남겨서 법인과 구성원이 존속하는 것이 목적입니다.
사업은 반드시 고객이 있어야 합니다.
그래서, 고객은 바로 ‘사업의 목적’이라고도 합니다. – 피터드러거

아직 고객을 정의하지 못했다면, 일이 아직 사업단계에 진입하지 못했다는 뜻입니다.
사업을 준비할 때 고객을 정의하는 것은 매우 중요합니다.

하지만, 많은 사람들이 신규사업을 준비할 때 존재하지 않은 ‘새로운 고객’을 정의합니다.
레드오션에서 경쟁하는 것보다 블루오션을 찾는 건 누구에게나 당연합니다.

하지만, 새로운 고객을 통해 새로운 시장을 여는 것은 아이디어 하나로 만들어지지 않습니다.
현실적으로 수많은 물량공세가 동반됩니다.
2013년 애플의 설비투자가 100억달러(11조)에 달하고, R&D비용이 한해 34억달러(3.8조)에 달한다고 합니다.

새로운 사업을 준비하는 사람들을 만나보면, 고객과 소비자가 헷갈리고, 사용자와 고객을 헷갈려 하는 경우를 자주 보아왔습니다.

준비가 완벽해야 한다고 말하려는 것은 아닙니다.
다만, 위 세가지 개념을 헷갈리신다면 아직 사업할 준비가 되어있지 않은 것입니다.

더 보기»

http://subokim.wordpress.com/2012/06/20/developer-story/

개발자의 인생은 프로그램이다.

프로그래머는 자신의 인생에 프로그래밍 습관이 베어 있습니다.
왜냐하면, 프로그래머는 하루시간의 대부분을 코딩을 하다보니 무의식 중에 그렇게 살고 있기 때문입니다.

몇가지를 볼까요?

1. 통신을 하기 위해서는 프로토콜을 맞추어야 합니다.
프로토콜을 맞추지 않고, 메시지부터 던지면 통신은 되지 않습니다.
당신은 혹시 회의석상에서 메시지부터 던지시진 않나요?
2. 그리고, 스펙도 정의해야 합니다.
즉, 같은 용어는 같은 뜻이어야 합니다.
같은 말을 다르게 듣고 있지 않으신가요?
논쟁을 하거나 회의를 할 때 만일 같은 이야기가 맴돈다면,잠시 중단을 하고 스펙을 정의하셔야 합니다.
3. 일을 시작할 때는 “{” 끝날 때는 “}” 라고 하십시요.
일의 시작선언과 종료선언을 하지 않는다면, 당신은 프로그래머가 아닙니다.
“언제 시작해서 언제쯤 끝날 것 같아요.”
“끝났습니다.” 이렇게 이야기를 해야 합니다.
늦어지면, 당연히 늦어진다고 이야기해야죠. 익숙해지셔야 합니다.
4. 그리고, 전역변수와 글로벌변수를 잘 선언해서 쓰십시요.
대화하면서, “아까 그거? 아니 그거” 를 자주 말씀하신다면, 변수선언을 잘못했을 확률이 큽니다.
잠시 대화를 멈추시고, “그건 A이고, 그건 B야.” 라고 다시 선언을 하세요.
5. 일이 많고, 혼란스러우신가요?
그러면, thread 를 더 만들어야 합니다.
thread 는 멀티태스킹을 의미합니다.
thread 없이 여러 개의 일을 혼돈해서 처리하고 있다면, 분명 잘못된 결과가 나올 가능성이 큽니다.
일이 복잡해진다면, thread를 분리하십시요.
6. 혼자서 할 수 없을만큼 일이 많다구요?
프로세스를 하나 더 만들어야 합니다.
자신과 비슷한 일을 하는 사람을 데려오세요.
그렇지 않으면, 현재 돌고 있는 프로세스(당신)가 dead-lock 이 걸려서 좀비상태가 되어버립니다.
만일, 혼자 밖에 없다면 혼자서 할 수 있는 만큼만 하세요.
dead-lock이 되면, throughput 이 제로이지만 혼자서라도 처리하면 적어도 제로는 아니니까요.
7. 그리고, 가능하면 super deamon이 process들을 control 하는 방식으로 일하지 마세요.
대용량 처리가 힘들어집니다. component 를 잘 정리하고 스펙을 잘 정리해서 event driven 방식으로 처리하세요.
(잘 안될겁니다. 하지만, 성공하면 업그레이드 되는 겁니다.)
당신이 사람인 이상, super process 의 한계는 있습니다.
일욕심을 혼자 내지 마세요.
일이 늘었다 줄었다 하는 동안 프로젝트는 실패를 향해 치닫게 될겁니다.
8. 일이 잘 진행되고 있는지 모르겠다구요? Alive check를 날리세요.
물론, 규격은 사전에 합의해야겠지요.
Alive check를 하지 않으면, 업무 펑크(장애)가 나도 알 수가 없습니다.
이건 매우 중요한 행위입니다.
9. 자, 중요한 건 로그입니다.
화면이 없는 서버프로그램의 경우, 로그를 통해서만 정상작동 여부를 알 수 있습니다.
당신은 업무로그는 어디에 찍고 계십니까?
만일 팀에 당신이 하고 있는 일을 찍은 로그시스템이 없다면, 당장 JIRA 를 설치하십시요.
그렇지 않으면 wiki 라도 설치해서, 하고 있는 일의 이력을 남기십시요.
그렇지 않으면, 일이 중간에서 멈추었을 때 추적하고, 분석하고, 감지하는 모든 행위를 할 수 없게 될 것입니다.
로그를 남기지 않는 서버 프로세스는 빠르지만, 결국 유지보수할 수 없는 프로세스가 되고 맙니다.
항상 하는 일이 똑같아서 소스변경이 없는 경우에는 로그를 남기지 않기도 합니다.
하지만, 매번 하는 일이 갱신이 되는데, 업무 로그를 남기지 않는다면 이미 당신은 프로그래머가 아닙니다.
빨리 다른 직업으로 전환하시길 권유드립니다.
10. 주석을 잘 달지 않는 사람들은 두 가지 경우입니다.
아주 쉽게 말을 하거나, 대화를 잘 하지 않는 성격인 경우입니다.
아주 쉽게 말을 하는 사람은 코드가 실제 언어처럼 쉽게 읽힙니다.
따라서, 주석을 달 필요가 없습니다.
하지만, 대인관계에 서투른 사람은 다른 사람을 배려하지 않기 때문에 주석을 달지 않습니다.
전자는 고수이고, 후자는 하수이죠.
11. 프로그래머가 procedual language 에서 object oriented language 를 배우게 되면, 사고체계도 그렇게 변하게 됩니다.
은행 전산실의 사람들은 일을 순차적으로 처리하는 걸 좋아합니다.
또, cobol의 숙련도만큼 순차적 일처리가 매우 세련됩니다.
일을 잘하는 것과 사고체계가 다른 것은 분리되어 이해되어야 합니다.
자신과 카테고리가 다른 개발자들을 무시해서는 안됩니다.
우리와 맞는지 안맞는지를 판단해야 합니다.
맞지 않다면, 빨리 제자리를 찾아주는게 좋습니다.
12. 웹 프로그래밍과 서버 프로그래밍과 클라이언트 프로그래머는 사고체계가 틀립니다.
프로그래머들도 그 변화를 겪을 때 매우 많이 성장하게 됩니다.
하지만, 꼭 클라이언트에서, 웹, 서버, DB가지 섭렵해보시길 강권해드립니다.
시장에서 강자가 되려 하신다면, 적어도 1년씩은 해보시길 추천드립니다.

그리고, 당신이 프로그래머라면 지켜야 하는 당연한 것들이 있습니다.
만일 당신이 동료들과의 커뮤니케이션조차 어려움을 겪고 있다면 분명 당신은 이 업종이 적성에 맞지 않는 겁니다.

더 보기»

http://subokim.wordpress.com/2013/01/23/it-project-feature/

IT 프로젝트 종류와 특징

“IT프로젝트 is not 빔프로젝트”
Joke 입니다. (_ _)

IT에 입문하는 사회 초년생의 눈에 소프트웨어 개발이라는 것이 비슷해 보입니다.
하지만, 각 산업분야별로 그 프로젝트 특성들이 모두 다릅니다.
처음에 잘못된 길로 들어왔다가 적성에 맞지 않다고 소프트웨어 개발을 포기하지 않았으면 하는 마음에, 특징들을 모아서 정리해보았습니다.
궁금해하시는 분들께 참고가 되었으면 좋겠습니다.

혹시 제가 잘못 알고 있거나 첨언을 해주실 내용이 있으면 댓글을 부탁드립니다. (좀 오래된 경험도 있어서. 긁적)

그리고, 한 분야을 하다가 다른 분야로 넘어가는 것은 굉장한 도전이 됩니다.
IT를 천직으로 생각하시는 분이 있다면, 충분한 시간과 계획을 가지고 다양한 도전을 해보시길 권하고 싶습니다.(물론 한 분야를 깊이 파는 것도 좋습니다.)

---

1. 은행 프로젝트
검증된 기술만 쓴다. 기술보다는 업무처리가 중요하다. 검증되지 않은 새로운 기술을 이야기 하면 바보취급 당한다. ‘한 번 해봅시다.’ 식의 접근은 거의 없다.
기본이 안정성이다. 대부분 24시간 365시간 무중단 운용성은 기본이다.
레거시를 걷어낼 수 없다. 레거시를 두고 가능한 좋은 성능과 결과를 낼 수 있어야 한다.
코드가 깔끔해야 한다. 언제나 유지보수할 수 있어야 한다. 만료된 서비스는 적시에 종료되어야 한다.

새로운 기술은 쓰지 않지만, 여러 기술분야의 체계성을 배우기 좋은 곳이다.

2. 보험사 프로젝트
업무요건들이 대부분 10년이상 장기 상품들이다. 삼성생명 ‘종신보험’과 신한생명 ‘종신보험’은 같으나 다르다.
재개발 수준의 고도화는 거의 없다. 대부분 덧붙이기 식으로 개발한다. 종료되고 폐기되는 상품은 거의 없다. 상품특성이 비슷해서 소스코드 재활용률이 높다. 하지만, 똑같지 않으므로 모듈레벨의 재활용은 거의 없다.
업무 전문성이 높은 개발자를 우대한다. 기존 소스코드가 자산이 된다.
트렌디한 기술을 사용하는 경우는 많지 않다.

금융업무에 관심이 많은 개발자라면 해볼만 한다.

3. 공공부문 프로젝트
전국 데이터는 기본이다. 규정(보안 등)을 준수하는 개발이 중요하다.
재기발랄하고 창의적인 분야는 거의 없다. 트렌디하지 않다. 공공의 편의성이 우선이다.
법제도가 바뀌거나, 규제가 늘거나 하는 등에 의해 유지보수가 발생한다.
큰 정부정책이 내려오면 대부분 큰 시스템의 개발이나 고도화가 동반된다.
큰 고도화의 경우 대부분 재개발이다. 깔끔한 개발보다는 일정준수가 중요하다. (대부분 제도 시행과 맞물려 일정이 잡힌다.)
기술보다는 업무목표 완성이 중요하다. 필요에 따라서 신기술도 자주 쓴다.

SI 프로젝트 중심이다. 기술습득이 빠르고, 여러가지 기술을 배우기에 좋다. 폭넓게 기술전반을 이해하기 좋다.

4. 이통사 내 부가서비스 프로젝트
24*365서비스가 기반이다. 레거시가 많다. 빌링과 인증 연동이 까다롭다. 대부분 연동을 많이 해야 한다. 클라이언트보다 대부분 서버 중심의 기술환경이다.
shut down되는 서비스는 거의 없다. 돈이 한 푼이라도 벌리면 살려둔다.
플랫폼형 서비스가 많은데 외부 CP등 제어할 수 없는 요인들이 많다. 당연히 예외처리가 많다. 상용반영하다가 장애나는 경우가 허다하다.
레거시가 오랫동안 살아있는 반면, 매뉴얼이 거의 없고 개발업체도 다양해서 유지보수하기 쉽지 않다. 작은 서비스를 계속 개발해서 런칭한다.
이통사 서비스는 오픈하면, 대부분 어느정도 트래픽을 확보한다.

서버 개발 기술(API, 연동, 통신 등)을 마스터하려면 이통사 프로젝트를 해보길 추천한다.
대용량 트랜잭션 처리의 경우도 많고, 현금이 실시간으로 흘러다니는 경우가 대부분이어서 긴장감이 매우 높은 편이다.

5. 이통사 레거시 프로젝트
회원관리, 빌링과 인증이다. 레거시를 걷어낼 수 없다.
오래된 코드의 경우 제대로된 유지보수 매뉴얼도 없는 경우가 많다. 덧붙이기식으로 개발한다. 폐기하기 힘들다. 정밀한 운영프로세스가 필요하다.
원복시나리오 없이 반영하지 않는다.
오래된 기술이 남아 있는 곳도 있다. 복잡도가 매우 높다.

큰 시스템을 경험하고 싶다면 한 번쯤 도전 해볼만 하다.

6. 웹포털 프로젝트
웹페이지 중심의 빠른 개발이 중요하다. 서버기술보다 프론트엔드 기술이 중요하다.
서비스가 끝나면 빠른 폐기도 중요하다. 웹기반 연동방식을 많이 쓴다. 트렌디하다.
정통적이고 무거운 개발환경보다 2 Tier 중심의 가벼운 개발환경을 선호한다.
특정기간에 치고 빠지는 개발을 많이 한다.
기술난이도가 높지 않다. 무료의 대용량 트래픽이 많기 때문에 라이센스 비용 등에 민감하다. 소스의 형상관리 등은 중요하지 않다. 빠른 속도의 오려붙이기식 개발을 한다.

웹서비스의 성공과 실패를 경험해보고 싶어하는 개발자들이 많이 지원한다.
현실적으로 포털이 네이버와 다음 밖에 남지 않아서, 입사하기 어렵기도 하다.

7. 스마트폰 앱기반 프로젝트
서버와 클라이언트로 나누어 개발한다. 서비스 피쳐를 기능으로 만들고, 서버와 클라이언트로 나누어 처리한다.
아직 인프라가 부족해서 이해해야할 기술의 폭이 넓고 다양하다.
기술 난이도가 높고 복잡도가 높은 반면, 빠른 개발속도가 필요해서 초급자가 도전하기 쉽지 않다. 복잡한 온라인형 서비스보다 단순한 단독형 앱서비스를 선호한다. 소규모 팀의 팀웍이 중요하다.
기술장벽을 극복하기 위해 REST API 등 기술트렌드 변화가 심한 분야이다.

새로운 기술을 배우고 싶어하는 개발자들이 도전해볼만 하다.
하지만, 베테랑이 충분한 팀을 선택하시길.

8. 폰게임 프로젝트
대작게임은 1년 정도의 개발이지만, 대부분 3개월 개발하고 출시하면 1개월 정도 팔린다.
빡세다. 빨리 개발해야 하므로 업무 체계성이 상대적으로 부족하다.
개발자 개인의 능력에 많이 좌우된다. 실패율도 높다. 출시 후 뜨더라도 6개월 가기 힘들다.
다작으로 승부하는 분야다. 체력 좋은 젊은 개발자 중심이다.
게임에 관심이 많은 개발자들이 도전한다.
온라인 게임보다는 단독형 게임이 대부분이라 클라이언트 개발이 대부분이다. 서버기술을 배울 기회가 많지 않다.

9. 대형 온라인 게임 프로젝트
기획도 좋아야 하고 개발도 체계적으로 해야 한다. 분업화하지 않으면 성공적으로 런칭하기도 힘들다. 돈이 많이 든다.
메인 게임에 Oracle, MySQL같은 RDB는 안쓴다. 빠른 ISAM DB(File DB)를 쓴다. (물론 회원정보 저장 등을 위해 쓰기도 한다.) 빠른 통신과 동접처리, 게임엔진 등이 중요하다.

폐인 기질이나 스스로 천재라고 생각하는 개발자라면 도전해볼만 한다.

10. 솔루션 프로젝트
스펙(규격)이 중요하다. 제품전략이 중요하고, 기능하나가 수익과 밀접하므로 기능 하나 쉽게 더하기 힘들다. 아름다운 설계가 중요하다.
완성도가 매우 중요하다. 최적화와 다양한 시험케이스가 매우 중요하다.
한번 출시되면, AS 하기 힘든 경우가 많기 때문이다.

완성도 높은 개발을 어떻게 하는지 알고 싶은 개발자라면 도전해볼만 한다.

11. ERP 프로젝트
회사마다 조금씩 다를 뿐 업무가 정형화되어 있다. ERP 패키지를 주로 사용한다.
기술적 도전이나 성취감은 낮다. 그러나, 회사라는 기업이 어떻게 돌아가는지 아주 잘 이해하게 된다.(현실적으로)

한 번 참여해보게 되면, 자기 회사를 할 때 매우 큰 도움이 된다. 또는, 전산실을 노린다면 도전해볼만 하다.

12. 학생들 프로젝트
학점이 중요하다. 기능이 구현되면 신기하다.
내 손으로 만든 것이 돌아간다는 게 놀라운 경험이다.

IT에 입문하고 싶어하는 사람이라면 반드시 한번은 거쳐야 한다.
동아리나, 커뮤니티에 들어서 많은 프로젝트를 해보길 바란다.

13. 기타
물류 프로젝트. 고생이라고 들었다. 소프트웨어는 그냥 수단이다. 개발서버가 별도로 없는 경우가 많다고 들었다.
병원 프로젝트. 모르겠다.

더 보기»

http://subokim.wordpress.com/2014/05/12/software-industry/

소프트웨어에 대한 이해

최근 소프트웨어가 화두가 되고 있습니다.
정부나 대기업들의 접근 방식을 보고 있자면 인식의 변화가 필요하다는 생각이 절실합니다.
IT종사자 분들이라면 많은 분들이 저와 비슷한 생각을 하십니다.
그러나 소프트웨어 분야를 잘 모르시는 분들이라면 소프트웨어가 무엇이 다른지 알기 어렵습니다.
도대체 소프트웨어는 무엇이 다를까요?
그동안의 현장경험을 바탕으로 생각을 정리해 보았습니다.

---

소프트웨어는 대량 생산 대량 소비의 논리로 해석될 수 없다.

자본주의 사회에서 돈을 벌기 위한 공통된 법칙은 대량생산 대량 소비입니다.
원가에 이익을 더한 제품을 대량으로 팔아서 큰 수익을 남기는 것입니다.

공산품의 경우는 대량생산을 위해 설비를 갖춥니다.
값싼 노동력을 컨베이어 벨트에 투입합니다.
제품의 불량율을 낮추기 위해 절차를 만들고 숙련공을 기릅니다.

대량생산, 대량소비는 오랫동안 자본주의 사회의 성공논리가 되어 왔습니다.
그리고 이에 대한 경제이론들도 많이 등장했습니다.

하지만, 소프트웨어는 어떨까요?
초기에는 소프트웨어도 대량 생산 대량 소비라는 관점에서 접근했습니다.
대형 국책 사업에서는 100명 이상의 개발자들이 일 년 동안 일을 하기도 합니다.
IT기업들은 많은 사람들을 공급함으로써 인건비에서 돈을 남기는 방법을 선택했습니다.
하지만, 애플과 구글, 링크드인, 넷플릭스 등의 사례를 보면서 인식이 달라졌습니다.

이제 기업들은 소프트웨어는 ‘값싼 노동력을 통한 대량 생산’이 중요한 게 아니라, 생태계나 플랫폼과 같이 ‘건강한 비즈니스 환경이나 훌륭한 상품을 만드는 것’이 훨씬 중요하다는 것을 알게 되었습니다.

소프트웨어 산업이 기존의 산업과 어떤 차이가 있는지 간단히 정리해 보았습니다.
편의상 인터넷 서비스도 넓은 의미에서의 ‘상품’, ‘소프트웨어’라고 부르겠습니다.

1. 대량생산 대량 소비가 핵심이 아니다.
공산품에서 ‘생산’이란 같은 제품을 복제하는 행위입니다.
컨베이어 벨트 위에서 똑같은 제품을 똑같은 품질로 만들어냅니다.
노동력은 엄연히 제품가격에 포함되는 생산원가 입니다.
그래서 저렴한 노동력을 필요로 합니다.
사람들은 공장에서 만들어진 똑같은 제품을 소비합니다.
똑같은 효용가치를 똑같은 방식으로 소비합니다.

그러나 소프트웨어는 대량 생산이 핵심이 아닙니다.
홈페이지에 올려 놓기만 하면 누구나 다운로드 할 수 있기 때문입니다.
또한 설치 파일은 복사를 통해 간단히 대량 생산됩니다.
컨베이어 벨트 옆에 사람들을 세워놓을 필요가 없습니다.

그리고 소프트웨어는 대량 소비가 아닙니다. 맞춤형 소비입니다.
소프트웨어의 효용가치가 사람마다 다르게 소비되어 집니다.
엑셀로 누구는 회계장부를 만들고, 누구는 이력서 양식을 만듭니다.

소프트웨어의 이런 산업적 특징은 전통적 경제 이론으로 접근하기에는 부족한 부분이 있습니다.

2. 소프트웨어는 비용이 아니다.
일반 제조업에서 소프트웨어는 비용을 줄이기 위한 업무 자동화를 목적으로 사용됩니다.
그러나 전자제품에서는 소프트웨어가 새로운 기능이 됩니다.
전자는 생산비용을 줄여주거나 생산성을 높여주는 것이고 후자는 그 자체가 제품입니다.
그래서 전자는 적당한 기술을 싸게 구매하는 것이 중요하지만, 후자는 비싸더라도 훌륭한 기술을 구매하는 게 중요합니다. 또한 전자는 구매 후 추가 비용이 들지 않는 것이 좋지만 후자는 상품성을 높이기 위해 계속해서 투자를 해야 합니다.

어떤 경우는 두 가지 경우가 구분되지 않기도 합니다.
택배물류 사업은 전산시스템이 업무자동화 시스템이자 물류상품 입니다.
현대물류 산업에서는 전산시스템이 없으면 그 복잡한 배송체계를 소화할 수 없습니다.
또한 배송추적 기능이나 빠른 배송 시스템은 상품 그 자체이기도 합니다.

그리고 인터넷 서비스에서 소프트웨어는 제품 전체이기도 합니다.
인터넷 쇼핑몰은 별도의 설비 없이 컴퓨터상에서 돌아가는 순수한 소프트웨어인 것입니다. 이렇게 소프트웨어는 다양한 형태로 기존의 산업과 융합되어 있습니다.

그리고 융합 형태에 따라 소프트웨어의 역할과 가치가 다릅니다.
그래서 어떤 종류의 소프트웨어인가에 따라 투자와 운영방식이 달라져야 합니다.
소프트웨어를 비용으로 바라본다면 어려운 골칫거리일 뿐 이지만, 투자로 바라본다면 소프트웨어는 경쟁력 강화를 위한 훌륭한 무기가 됩니다.

3. 개발 유지보수 역량이 경쟁력이다.
전통적인 제조업에서 사후지원은 전혀 제품의 경쟁력이 아니었습니다.
기껏해야 고장난 제품을 수리해주는 정도에 불과했습니다.
하지만 소프트웨어가 등장하면서 지속적 업데이트가 중요한 경쟁력이 되었습니다.
지속적 업데이트가 제품의 효용가치를 유지시켜 구매경쟁력을 높여주기 때문입니다.

그러다 보니 제품 판매 후에도 소프트웨어 개발팀을 지속적으로 유지할 필요가 생겼습니다.
특히 설치형 소프트웨어에서 인터넷 서비스로 갈수록 개발 유지보수의 중요성은 더 커졌습니다.

기존 산업의 경우 일단 제품의 생산능력과 판매능력이 차별화 되면 시장 우위가 쉽게 바뀌지 않았습니다. 하지만 소프트웨어는 새로운 제품을 설치하거나 인터넷 주소만 바꾸어 주면 이용자들이 다른 제품으로 손쉽게 이동할 수가 있습니다.
이런 특징 때문에 환경에 적응하지 못한 제품들은 금방 뒤로 밀려나버리고 맙니다.
예를 들면 블로그 서비스는 SNS에 의해 뒤로 밀려났고 PC 메신저는 스마트폰 메신저에 밀려나 아예 사라져 버렸습니다. 그리고 오랫동안 컴퓨터에서 왕좌를 지켜왔던 MS오피스는 구글 문서도구의 등장으로 시장을 잃게 될까 두려워하고 있습니다.
모두 한 때 최고의 인기를 누리며 영원할 것 같았던 존재들이었습니다.

이렇게 소프트웨어는 기술과 생활의 변화에 발맞추어 계속 변화해야만 생존할 수 있습니다.
그러기 위해서는 훌륭한 개발 유지보수팀의 효과적 운용이 매우 중요합니다.
소프트웨어 산업은 전통적인 제조업과는 달리 개발자의 역량과 개발팀의 운용이 핵심을 차지하고 있습니다.
따라서 이를 위한 비용 및 투자계획, 조직관리 등이 경영에서 빼놓지 말아야 할 중요한 요소가 되었습니다.

4. 상품개발이 핵심.
소프트웨어는 생산설비가 없으므로 제품 개발이 완료되면 바로 소비자들에게 보급됩니다.
따라서 소프트웨어 제품 개발은 제조업의 연구 개발과 차이가 있습니다.
제조업의 경우 연구 개발 제품은 상품화 과정 중에 여러 가지 이유로 많은 기능들이 삭제 변경됩니다. 따라서 시제품과 상품이 차이가 나는 경우가 많습니다.

하지만 소프트웨어는 제품 개발 과정을 통해 바로 상품이 만들어 지므로 시제품이 곧 상품입니다.
따라서 목표를 선정하고 만들어 가는 과정이 많이 다릅니다.
일반적으로 공산품은 ‘기획-시제품 개발-설비 구축-대량 생산-유통-판매-대량 소비’의 단계를 거치게 됩니다.
반면 소프트웨어는 ‘기획-상품개발(반복)-판매-소비’ 단계를 거치게 됩니다.
소프트웨어 분야는 설비구축과 대량생산, 제품 유통 과정이 별도로 존재하지 않으며 상품 개발에서 신경 써야 할 많은 부분들이 제품 개발 과정에 녹아 있습니다.

그래서 소프트웨어는 개발자들의 업무 역량이 매우 중요합니다.
소프트웨어 상품개발은 시행착오를 빠르게 반복하고 겪으면서 만들어 집니다.
그래서 상품개발은 정부가 주도하기 힘듭니다.
느린 연간 예산 제도로는 시장의 트렌드를 따라가기 힘들기 때문입니다.

소프트웨어 산업은 훌륭한 개발자와 좋은 팀워크, 높은 업무 숙련도가 필수인 분야입니다.
그래서 일반 제조업과는 다른 인재상과 조직 운영 노하우가 필요합니다.

제품의 생산, 유통, 소비 과정 자체가 아예 다르다는 것을 인정해야 합니다.
소프트웨어 비즈니스를 하는데 소프트웨어 특성을 이해하지 못하고 사업기획을 한다면 당연히 실패할 수밖에 없습니다.
따라서 먼저 그에 맞는 가치관과 철학을 갖추는 것은 당연하고도 합리적인 접근 수순이라 할 수 있습니다.

더 보기»

http://subokim.wordpress.com/2011/11/07/agile-work/

Agile하게 일하기

Agile 방법론이 대세이고, 화두입니다. (Agile = 날렵한, 재빠른, 기민한)
“어떻게 일해야 하고, 어떻게 해야 성공적일 수 있을까?”를 고민해보았습니다.

1. 왜 대세인가?
소프트웨어 제품은 만드는 것도 중요하지만, 계속해서 온라인으로 업그레이드 시킬 수 있다는 장점이 있습니다.
이것은 제품 출시 후에는 업그레이드 할 수 없는 하드웨어보다는 매우 매력적인 특성입니다.
온라인 서비스의 경우는 특히 “신규 개발”보다 “운영 및 지속적 업그레이드”가 중요한 비즈니스입니다.
하지만, 안타깝게도 비즈니스 환경이 개발자가 선호할만한 환경은 아닙니다.
1. 체계적인 요구사항이 없다.
2. 사업 환경에 따라서 구현하거나 보완해야 할 사항이 자주 바뀐다.
3. 어떤 것이 목표인지 목적인지 뚜렷하지 않다. 신기술이나 실험적인 시도도 필요하다.
4. 이런 짓을 평생 반복해야 한다.
이런 상황에 대해 분석, 설계, 개발을 엄격하게 규정짓는 Waterfall 방법론은 넌센스라고 할 수 있습니다.
Waterfall 은 “요구사항을 Fix시키지” 않으면, 이후 프로세스를 진행할 수 없기 때문입니다.
그리고, “요구사항이 변경”되면 그만큼 Roll back해야 합니다.
과거 하드웨어 중심의 프로젝트에서는 제품출시 후 변경하기 어려웠으므로, 개발 착수 전에 모든 걸 결정짓는 Waterfall 방법론이 적합했습니다.
하지만, 소프트웨어 비즈니스에서는 위와 같이 규정짓기 힘든 경우가 태반입니다.
즉, Agile 이 주목받고 있는 이유는, 소프트웨어 시장이 포화가 되어서 신규구축이 많이 없어졌고, 시장에 유연하게 대응하면서 사업을 성장시키는 노하우가 중요해졌기 때문입니다.
2. 누가 필요로 하는가?
Agile 한 환경을 누가 필요로 할까요?
Waterfall 은 버려야 할까요? 그렇지 않습니다. 방법론은 “프로젝트를 성공시키는 수단”일 뿐.
방법론을 잘 지켰다고 반드시 프로젝트가 성공하지는 않기 때문입니다.
Agile하다는 것은 “눈에 보이는 (작은)성과물을 가지고 Speedy 하게 Communication 하는 것”을 말합니다.
• Agile 은, “프로세스가 없어서 일을 못한다고 이야기하는 조직”이 해야 합니다.
프로세스를 이야기하는 조직은 대부분 큰 조직들입니다. 프로세스는 감정적인 분쟁을 억제하고, 전체적인 책임으로부터 자유롭게 해줍니다.
프로세스를 중시하는 조직에서는, Agile을 “또 하나의 프로세스”로 이해하는 경우가 있습니다.
그러나, Agile 은 일하는 방법이지, 프로세스가 아닙니다.
작은 조직이이라면, 프로세스를 논의하기 전에 Agile 한 방법을 도입해보길 강력히 추천드립니다.
큰 조직이라면 상황이 다릅니다.
• Agile 은 “매일 상황이 변하는 서비스 운영 조직”에서 해야 합니다.
작게 일을 나누고, 작게 개선합니다. 그리고, 많이 커뮤니케이션합니다.
“이야기하면서 방향을 정하고, 이야기하면서 피드백합니다.”
상황이 매일 변하므로 약속과 원칙에 얽매이면, “변화의 시기”를 놓쳐버리기도 합니다.
여기서 중요한 것은, 노하우를 기록하고 남겨야 한다는 것입니다.
Agile 은 작고 가볍기 때문에 체계가 부족합니다.
즉, 실패를 기록해두지 않으면 반복할 가능성이 큽니다.
노하우가 유사한 환경의 멤버들에게 공유될 수 있어야 합니다.
기록을 공유하는 가장 쉬운 방법은 사내 게시판을 활용하는 것입니다. 잊지 마십시요. Agile은 툴이 아닙니다.
사내 게시판이 없는 경우는 메일을 사용해도 좋습니다.
3. 어떻게 일해야 하는가?
Agile 방법론은 “프로세스”가 아니라“문화”입니다.
일하는 방식에 대한 것입니다. 형식없는 형식입니다. (무슨 도 닦는 이야기 같군요.)
• 첫째, 목표를 정하라.
진행하다가 목표가 달라지면, 연관된 것을 재점검합니다.
목표를 정하는 것은 협업의 기본입니다.
무엇을 바라봐야 할지 정하는 것은 당연합니다.
목표가 공유되지 않았는데, 이야기할 거리가 있을까요?
아무도 그 목표에 대해 고민하지도 않을거고 서로의 역할에 대해서 말하지도 않을 겁니다.
주욱, 텍스트로 적으십시요. 그리고, 그것으로 논의하십시요.
• 둘째, 기한을 정하라.
언제쯤이면 무엇을 눈에 볼 수 있는지 기한을 정하십시요.
그래서, 무엇을 평가하고 어떻게 피드백할 것인지도 사전에 공유하십시요.
“이 기능이 되면, 이런게 만족 되는지 보자.”라고 이야기하십시요.
iteration의 기본은 반복하는 것입니다. 즉, iteration 이라는 갈림길에서 어떤 의사결정을 할 것인가를 미리 공유해두는 건 매우 중요합니다.
팀원들은 그 의사결정을 할 수 있도록 충분히 준비할 것입니다.
• 셋째, 각 일의 책임자를 정하라.
애매한 것이 없도록 나누어서 맡아야 합니다.
애매한 것의 업무부담은 PM이 조절해야 합니다.
PM은 쪼개어진 일에 따라 전문인력을 쉽게 넣고 빼고 할 수 있어야 합니다.
모듈의 전문성을 높이기 위해서는 일단위의 시작과 끝을 적절히 자르는게 중요합니다.
그렇지 않으면, 한 번 투입된 인력이 오랫동안 투입되고 단위업무의 품질은 떨어지고, 전체일정의 혼란은 가중될 것입니다.
PM은 Job Load 에 대한 분배와 함께 전체 스토리가 초점을 잃지 않도록 관리해야 합니다.
• 넷째, 빠진 것이나 이슈는 bucket list로 관리하라.
iteration 을 도는 동안 test 를 하면서, 문제나 이슈가 제거되거나 완화되어야 합니다.
iteration 을 하면서 만들어진 새로운 기능이 “다른 문제를 야기”하지 않도록, Business Unit을 모듈화시키고, “Sandbox 형태”로 설계해야 합니다.
만일, exception을 발생시킨다면 다른 iteration에서 쉽게 참조할 수 있도록 document 가 있어야 합니다.
project wiki page 를 하나 만들고, 거기서 관리하십시요. 아니면, issue tracker도 좋습니다.
이슈 관리에 “메일”은 가능하면 쓰지마십시요. “메일”은 공유의 개념보다 책임 떠넘기기로 오해될 수 있습니다.
wiki 나 게시판 같이 함께 볼 수 있는 곳에 게재하십시요.
• 다섯째, 위험의 크기를 사전에 공유하라.
기일을 정했는데 변할 수 있습니다.
Feature를 정했는데 변경될 수 있습니다. 기한 내에 맡은 일을 못할 수도 있습니다.
어떤 경우든 팀원들이 빨리 위험신호를 알리고 미리 대응할 수 있게 해야 합니다.
위험을 미리 예상하여 작게 쪼개어서 점검할 수 있게 계획하십시요.
실패에 대한 부담이 적을수록, 창조적으로 일하게 된다.
기일을 못맞추면 어떤 일이 생기는지 구성원들이 사전에 공유하십시요. 위험에 대한 인식이 다르면, 협업이 힘들어집니다.
4. Agile 방법론의 종류
이 항목은 wiki 페이지를 참조하였습니다.
• eXtreme Programming 해야 할까?
무조건 우선 개발을 시작하는 방식입니다.
처음에 고객과 2주 정도 이야기하면서 컨셉을 잡고는, 우선 개발합니다.
구성원들이 시스템에 대한 이해도가 높아야 하고, 전문가들이어야 합니다.
따라서, 외주활용이 힘듭니다.
중요한 것은 자동화된 테스트 시스템이 있어야 합니다.
즉, 개발환경(테스트가 가능한)이 없으면 결과를 확인할 수 없어서 다음 Cycle에 진입할 수가 없습니다.
개발환경 하에서 짧게 짧게 Cycle을 돌면서 개발을 하는 것이므로, “기능개선 중심의 과업”에 적합합니다.
하지만, 개선효과를 금방금방 확인할 수 있으므로 신기술을 플랫폼에 도입하거나, 중소규모의 기능을 플랫폼에 추가하고자 할 때 적합합니다.
개발환경없이 신규멤버로 맨땅에서 시작하는 경우라면, XP 개발은 하지마십시요.
구성원들 간 커뮤니케이션에 혼란이 생길 것입니다.
XP 를 하기 위해서는 개발환경을 잘 갖추는게 중요합니다. 아주 빡센 개발방법입니다.
• Scrum 원래 Scrum은 한 달 단위로 한다고 합니다.
사전에 개선할 목록을 뽑고, Iteration 마다 동작가능한 결과물을 내어 놓을 수 있도록 일을 나누어 일하는 방식입니다.
매일 정해진 시간에 모여서 짧게 개발을 하는 방식인데, 오픈 소스 커뮤니티가 많이 사용한다고 합니다.
조금 느슨하므로, 구성원들의 참여의욕이 높아야 합니다. 너무 Free 해보여서 기업형 개발에는 적합하지 않을 것 같네요.
• Feature-Driven Development
도메인 객체 모델이 중요합니다. 전체 업무를 객체단위로 부품화하고, 이 목록대로 기능을 나누어서 개발합니다.
2주 단위로 Cycle 을 돌면서, 반복 개발합니다.
분석 설계를 끝나고, 개발단계 이후로 iteration을 할 수 있네요.
최근에 “아키텍쳐 개발방법”에 많이 사용되기도 합니다.
• Adaptive Software Development
이게 Agile 을 대표하는 방법론이 아닐까 싶습니다. 이 방법은 Rapid Application Development 의 확장판입니다.
이것은 상시 적용이 가능하다는 전제에서 시작합니다.
ASD는 추측, 협동, 학습을 반복하는 것인데요.
추측이란 의사결정권자들이 어떤 관점에서는 이슈를 잘못 판단할 수 있다는 가정에서 시작하는 것입니다.
학습이란, 디자인-개발-테스트를 반복함으로써 의사결정권자들이 알게하는 것을 말합니다.
ASD 는 의사결정권자들이 쉽게 결정할 수 있도록, 포인트를 나누어서 iteration을 도는 것을 말합니다.
Waterfall 방법론과 섞어서 진행할 수도 있습니다.
중요한 건, 중간 성과를 자주자주 보고하는 것입니다.
5. Agile 하게 일하지 않아야 하는 경우는?
SI 용역 프로젝트의 경우 Agile 하기 힘듭니다.
외부집단이 내부 내용까지 깊이있게 이해하기 힘들 뿐더러, 책임감이나 위기의식이 공유되기 힘들기 때문입니다.
Agile을 적용하기 힘들다면 “전통적인 Waterfall 방법론에 Agile 한 문화를 조금 섞어서” 해보길 추천드립니다.
중간 산출물에 대해 Feed-back 만 제대로 할 수 있어도 Risk는 꽤 줄어듭니다.
그러기 위해서는, PM 이나 아키텍쳐가 상세레벨까지 이해할 수 있어야 합니다.
6. 어떻게 끝낼 것인가?
Agile 은 끝이 있을까요? 취지에 따르면 끝이 없다고 봐야 합니다.
하지만, 모든 일에 끝이 없다면 멤버들은 금방 지치고 말 것입니다.
일정을 너무 내세우면 Agile 하게 일하기 힘듭니다. 실패하면 다시 해야 하거든요.
• 단위 과업의 목표품질을 가지고 이야기하십시요.
• 그 품질목표를 만족해야 단위 프로젝트가 끝나게 하십시요.
• 그 목표에 다다르기 위해 일정과 리소스를 정하고,
• 리소스을 얼마나 활용할 수 있는지 미리 예측하십시요.
만일 그렇게 한다면, Agile 은 “장기 인프라 개발”에도 꽤 유용한 방법론입니다.

※ 엮인글 : 애자일방법론
※ 참조 :

위키피디아

블로그 : Agile과 프로젝트 현실

Adaptive Software Development

더 보기»

http://subokim.wordpress.com/2013/03/31/technical-domain-knowledge/

Domain Knowledge-기술지식

소프트웨어 뿐 아니라 대부분의 분야에서, Developer와 End User와의 커뮤니케이션은 쉽지 않습니다.
왜 그럴까요? End User의 도메인 지식(Domain Knowledge)이 부족하기 때문인데요.
도메인 지식에 대해 간단히 고민을 해보았습니다.

1) Domain Knowledge란?
Wikipedia에 보면, “도메인 지식이란, 인간활동 영역이나 자율적인 컴퓨터활동이나, 다른 전문분야에서 사용되어지는 유효한 지식을 말한다.” (Domain knowledge is valid knowledge used to refer to an area of human endeavour, an autonomous computer activity, or other specialized discipline.)고 기술되어 있습니다.

소프트웨어 기술에서 Domain Knowlege라 한다면, 목표 시스템이 운영되는 환경에 대한 지식을 이야기합니다.
하지만, 창업이나 사업을 준비하다보면 Domain Knowlege를 조금 더 넓은 의미에서 이해할 필요가 있습니다.

2) 종류
당신이 의류브랜드를 가진 사장님이라면, 종이 위에 그려진 디자인, 색상만 가지고 사업전략을 짤 순 없습니다. 컨셉수립 정도는 할 수 있겠지요.
의류업에 종사하는 사장님들을 만나보면 옷감의 종류, 나염의 종류, 세탁방법, 무게와 재질 등에 해박한 지식이 있습니다.
이런 걸 모르고 의류사업을 시작했다가 망한 경우를 주변에서 많이 보셨을 것입니다.
자동차 회사에서 디자이너나 마케터도 마찬가지입니다. 엔진, 시트(재질, 질감, 내구성), 전기제품 등에 대한 지식이나 이해도가 일반인들보다 훨씬 깊습니다.
반도체, 건설, 백화점, 유통업도 마찬가지입니다.

어떤 업종이든 제품 기획이나 사업전략을 수립할 때, 반드시 그 분야의 ‘기술지식’, ‘업무지식’, ‘재무지식’ 세 가지를 함께 생각합니다.
업종마다 각각 달라서, 새로운 분야에 들어갈 때마다 새로 익혀야 하는 것들입니다.
이 세가지를 Domain Knowledge 라고 할 수 있을 것 같습니다.

3) 기술지식 (Technical Knowlege)
시장을 돌아다니다보면, 세부 사업전략을 수립할 때 아직도 기술팀 없이 진행되는 경우가 종종 있습니다. 또는, implementation의 역할로만 한정되어 중요한 부분에서 의견 개진이 안되는 경우도 있습니다.

IT회사에서 소프트웨어와 개발을 모르고, 제품기획이나 전략수립이 가능할까요?
이론적으로야 가능하겠지만, 경험적으로 불가능합니다.
현장을 이해하지 못하고 만든 전략은 반드시 ‘구현단계’와 ‘성장단계’에 벽에 부딪혀 고꾸라지고 맙니다.

소프트웨어는 하드웨와 형상이 다르지만, 사용자에게 “효용가치를 주는 제품”이라는 점에서는 동일합니다.
Domain Knowledge에서 ‘기술지식’은 팔기 위한 제품자체를 의미하므로 ‘업무지식’이나 ’재무지식’에 못지 않게 중요합니다.
하물며 소프트웨어 분야(서비스든 솔루션이든)도 예외가 될까요?

소프트웨어의 특성, 가치, 제작방법, 제작 후의 유지보수, 그에 필요한 기술적 지식 등을 이해하지 못하고, 어떻게 좋은 전략과 디자인이 나올까요?
사업논리에 묻혀 기술논리를 등한시 한다면 ‘제품’없이 제조업을 하겠다는 것과 같습니다.

‘Technical Domain Knowledge’ 없이 IT 사업에 도전하는 것은, 경쟁자들에게 스스로 호구임을 자처하는 꼴입니다.

4) 개발팀의 에너지가 키워드다.
개발팀은 UI,UX 등 제품의 ‘제작에 참여하는 모든 팀’을 말합니다.
자기 제품을 가진 회사라면, ‘재무지식’과 ‘업무지식’ 만으로 차별된 제품가치를 만들어 내기 힘듭니다.
– 개발팀을 단순히 구현을 위한 역할로 한정짓지 말고,
– ‘개발팀의 에너지를 어떻게 활용하는가?’를 기본으로 깔고 가는 것이 매우 중요한 키워드임을 의사결정권자들이 충분히 공감했으면 좋겠습니다.

그러한 시스템이 되지 않은 상태에서, 개발팀의 열정을 독려하는 것은 물에 젖은 종이에 불을 붙이고자 하는 것과 같습니다. 그런 시스템을 만드는 것은 의사결정권자들의 역할입니다.

5) 사업지식(Business Domain Knowlege) 
사업현장에서 개발팀의 에너지가 유용해지려면, 비즈니스에 대한 지식공유나 이해가 선행되어야 합니다.

중동지방의 기후적 특성이나 고객의 기호를 이해하지 못하고, 수출가능한 자동차를 만들 수는 없습니다. – 중동지방은 밤낮의 온도차가 크고 모래바람이 심해, 도장처리나 철판의 팽창,수축에 대한 심화된 기술지식이 필요했다고 하더군요.

제품을 제작하는 사람이 사업에 대한 이해도를 높이는 건 ‘매우 당연하면서 자연스러운 일’입니다.

큰 회사건 작은 회사건 개발자들의 사업에 대한 이해가 없다면, 핵심과는 동떨어진 기술과 아이디어들로 많은 시간을 낭비하게 될 것입니다.

6) 기타
Domain Knowledge에서 업무지식이나 재무지식도 중요합니다.
다음에는 IT 산업에서의 ‘업무지식’과 ‘재무지식’ 등에 대한 관련 포스팅을 해보겠습니다.

※ 같이 읽기 : Domain Knowledge – 재무지식

더 보기»

국내 IT산업의 어제와 오늘

http://subokim.wordpress.com/2012/11/12/itswhistory/

국내 IT산업의 어제와 오늘(1)

연간 약 1만명 정도되는 사람이 소프트웨어 업계에 들어오고 있지만, 정작 국내 IT가 어디서 와서 어디로 가고 있는지 터놓고 이야기할 기회가 많지 않습니다.
참고할 만한 자료를 뒤지다가 “2011년 소프트웨어산업 연간보고서”를 보고 우리나라 소프트웨어 산업의 역사를 정리해보았습니다.
아래 구분의 기준은 위 자료를 따랐습니다.
※ 참고 :
– 정보통신산업진흥원, 2011 소프트웨어산업 연감 보고서
– 우리나라 컴퓨터 역사(1995년 전자신문 기사)

우리나라 소프트웨어 산업 역사

1. 태동기 (1960~1969)
1967년에 한국 IBM이 설립됩니다. 키펀치로 개발하던 시대죠.
그리고, 과기처 산하에 한국전자계산소가 설립됩니다.
이 때는 산업이라고 부를만한 무엇이 없었을 듯 합니다.
2. 전산화 (1970~1979)
1970년에 숭실대에 국내 처음으로 전자계산학과가 만들어집니다.
1971년에 한국 유니시스 국내 법인이 설립됩니다.
유니시스는 IBM과 함께 전세계적으로 메인프레임을 공급하던 회사입니다만, 2010년에 결국 한국에서 철수합니다.
1976년에 삼성그룹에 종합전산실이 구축되고, 1977년에 한국증권전산이 발족되고, 상업은행 보통예금이 온라인으로 처리되기 시작합니다.
지금 관점에서 보면, 이 때의 개발자들은 기계적 지식에 기반한 하드웨어 운영자에 가까웠습니다.
소스코드는 비인부전으로 선임에서 후임으로 전해지는 것이었고, 개발이란 영역은 미래를 이끌어갈 정말 초스페셜 특수직군이었습니다.
3. PC대중화 (1980~1989)
이전까지는 메인프레임의 시대였습니다만, 1981년 컴덱스에서 IBM PC가 처음 발표되면서 세상이 바뀌기 시작했습니다.
국내에는 1984년이 되어서야 비로소 삼보컴퓨터를 통해 XT가 보급되기 시작했습니다.
1989년에 아래한글1.0이 나오고 나서야 비로소 소프트웨어라는 개념이 분리되어 인식되기 시작합니다.
1985년에는 삼성SDS, 1987년에 LG CNS가 설립되었습니다.
이것은 IT가 비로소 사업적 면모를 갖추게 되었다는 것으로 인식할 수 있습니다.
4. 인터넷혁명(1990~1999)
1994년에 국산서버를 만들고자 주전산기가 만들어집니다.
1990년에 윈도우 3.0, 94년에 워드 5.0이 발표되었지만, 1995년 윈도우95가 출시되면서 시장구조가 크게 변화되기 시작합니다.
윈도우95는 사용의 편리성을 바탕으로 업무환경을 메인프레임과 터미널 시스템을 클라이언트-서버기반의 PC시스템으로 변경시키게 됩니다.
이 때 시스템 가격이 많이 낮아지면서, SI(System Integration)시장이 급속도로 커지게 됩니다.
이 때는 “시스템 도입”과 “업무전산화”가 9시 뉴스에 나오던 시대였습니다.
시장이 늘어나면서 개발자 유입이 급속도로 늘어났습니다.
개발도구가 3GL의 파워빌더에서 델파이와 같은 4GL로 넘어가면서, CORBA와 같은 C/S기술들도 진화하게 됩니다.
1994년에 ISDL과 함께 인터넷 상용서비스가 시작되고 1999년에 인터넷 이용자가 1,000만명이 됩니다.
인터넷의 폭발적인 성장과 더불어 코스닥(1996)을 통해 묻지마 투자가 성행합니다.
후반부에는 SI시장이 C/S환경에서 웹환경으로 넘어가면서, 웹 개발자들의 몸값이 천정부지로 치솟았습니다.
이 때 html 1년 정도 했던 개발자가 연봉 4,000만원 정도에 이직을 했던 걸 본적이 있습니다.
1996년에 CDMA가 상용화됩니다.
이 때 들고다니던, 애니콜 폰이 생각나네요.

1997년에는 IMF를 맞습니다. 아참, 그리고 Y2K사건도 있었네요.
5. 디지털컨버전스(2000~2011)
2001년에는 검색엔진, 2002년에는 ERP, 2003년에 방카슈랑스도입, 2006년에는 모바일웹 표준화 등이 있었습니다.
2000년 IMT-2000, 2006년 와이브로 사업과 같이 정부 주도의 IT사업도 있었습니다.
2007년이 되어서야 공공기관에서 소프트웨어 개발을 분리발주 합니다.
그 이전에는 하드웨어와 함께 발주되는게 관행이었습니다.
“국내 SI시장이 포화되면서, SM(System Management) 시장으로 넘어갑니다.”
개발자 공급이 넘치다보니, 개발자 단가가 점점 낮아집니다.
대기업의 경우 유휴인력들을 낮은 가격으로 SI, SM시장으로 풀게 되는데, 이와 함께 개발환경이 급격히 악화되기 시작했습니다.
반면, 시장이 운영환경으로 넘어가다보니 효과적인 유지보수 방법들이 중요해지게 됩니다.
ADSL 보급이 확대되면서 일반인 시장이 열리고, 인터넷이 고도화되면서 국가간 IT장벽도 사라지게 되었습니다.
포털시장이 커지고, 인터넷 쇼핑몰이 일반화되었습니다.
Auction과 같은 Open Market은 유통시장을 바꾸기도 했습니다.
모바일은 2003년 정도에 256컬러LCD와 16폴리 휴대폰의 출시로 배경화면,벨소리 시장이 최대였던 것 같습니다.
2009년 드디어 아이폰이 국내에 들어오면서 기존 휴대폰 기반 서비스들은 막을 내리게 됩니다.

시사점과 고민

1. PC가 나온지 이제 겨우 30년이 지났습니다. 제조업이나 금융업과 비교하면 매우 짧은 시장의 역사를 지니고 있습니다.
실패나 성공에 대한 학습시스템이 아직 시장에 없습니다.
“대형,장기 프로젝트에 대한 노하우나, 사람관리에 대한 노하우가 업계 내에서 재학습되는 구조도 없을 뿐더러 공유되고 토론되면서 발전하는 구조도 없습니다.”
당연히 모든 프로젝트는 항상 새롭고, 항상 어렵습니다.
아직 IT시장은 거칠게 격변하고 있기 때문입니다.
2. 기술은 빨리 발전했으나, 관리철학이나 사업노하우 등 “마인드”의 영역은 매우 느리게 발전하고 있습니다.
개발방법론이나 유지보수방법론 같은 이론적인 접근도 현장을 중심으로 조금씩 이루어질 뿐입니다.
하지만, IT가 하나의 산업으로 성장하려면 이러한 기술 외적 부분들의 성장이 필수적입니다.
이런 시스템과 문화는 시간이 지나면서 구성원들에 의해 만들어지는 것이므로, IT종사자들이 지속적으로 정보와 경험을 공유하면서 노력해야 한다고 봅니다.
3. IT가 앞으로 쇠퇴하거나 역사속으로 사라지진 않을 겁니다.
다행히 30여년의 시간을 되짚어보면, 기술과 시장의 진화속도가 국내와 해외가 크게 다르지 않습니다.
시장이 포화된 듯 보이지만, 다른 산업군과의 융화를 통해 앞으로도 무궁한 성장과 산업적 진화가 기대됩니다.
또한, 소프트웨어 산업은 인터넷의 발달로 쉽게 세계화될 수도 있습니다.
IT는 그만큼 성공신화가 많이 기대되는 블루오션이라고 할 수 있습니다.
많은 개발자들이 현재의 시장에만 안주하지 말고, 새로운 시각으로 주변에 눈을 돌려 창의적 도전을 계속 할 수 있었으면 합니다

국내 IT산업의 어제와 오늘(2)

“2011년 소프트웨어 산업연감 보고서”를 좀 더 살펴보고자 합니다.
저는 IT산업구조를 1)SI사업, 2)패키지SW, 3)컨설팅등 서비스업으로 분류를 했는데요, 여기서는 1)패키지SW, 2)IT서비스, 3)임베디드SW로 나누었습니다.

패키지SW는 오라클,알티베이스,Tmax 등을 생각하시면 됩니다.
IT서비스는 컨설팅/기획, SI, SM 세 가지로 인력용역 기반의 사업을 말합니다.

---

시사점 및 의견

국내 소프트웨어 시장의 주류는 SI/SM 중심이라고 할 수 있습니다.
하지만, 비정상적 갑을 문화와 영세한 기업 규모는 미래를 낙관하기 힘들게 합니다.
사회 초년생들이 작은 SI기업에서 개발자로 시작하는 것은 이제 흔히 볼 수 있는 풍경들입니다.

반면, 국내 SW개발생산성을 높일 수 있는 사회적 교육시스템은 전무하다고 할 수 있습니다. 개발자들이 자생적으로 오픈소스를 공부하거나, 커뮤니티 활동을 통해 진화를 모색하고 있으나 그 힘은 아직 매우 부족하다고 보여집니다.

2011년 11,510개의 공공프로젝트가 발주되었는데, 모두 1년짜리라고 가정한다면 프로젝트당 평균 14명 정도가 일을 했습니다.
연간 프로젝트 수 대비 개발자가 적다고 볼 수 있는데요.

3D직종으로 인식되고 있고 대박성공 신화의 기회가 점점 줄어드는 만큼, 앞으로 개발자 유입이 줄고 개발품질도 점점 떨어질걸로 예상이 됩니다.
개발자들이 SI나 SM과 같은 단순구축업무 외 “지식기반 경제적 부가가치를 창출”할 수 있는 “사회적 선순환 구조”를 만드는 것이 정말 시급한 시기가 아닌가 싶습니다.

더불어 장기적 안목을 바탕으로 한 정부의 소프트웨어 정책 지원도 절실히 필요합니다.
그와 함께 선임 개발자들이 나서서 소프트웨어 문화를 향상시킬 수 있는 자생적 노력들을 해나가야 한다고 생각합니다.

1. 국내 소프트웨어 시장규모
   
   부문별 생산액은 유통시장을 제외한 부분을 말합니다.
   
   ITO(IT Outsourcing)는 SM시장을 말합니다. ITO, SI, 컨설팅 시장은 외주용역기반의 시장인데요.
   국내 IT서비스 시장의 대부분이 SI 관련 시장(SM포함)임을 알 수 있습니다.
2. 전체 소프트웨어 기업 현황
   
   2005년 4,785개에서 2010년 6,826개로 연평균 7.5%씩 업체 수가 증가했습니다.
   2008년에 기업 수가 급격히 증가한 것은 ‘홈페이지 제작’서비스와 ‘호스팅 서비스’ 분야 때문이라고 합니다.
   
   패키지소프트웨어는 계속 감소하다가 2009년 스마트폰의 등장과 함께 증가세를 보입니다.
   패키지분야와 IT서비스분야의 기업수 비율이 약 30대70 정도이군요.
   
   연매출 300억 이상 규모는 3%에 불과합니다.
   매출 10억 이하가 52.1%, 10억~50억 미만이 32.3%입니다.
   연매출 100억 미만의 기업을 합치면 92.3%로 대부분의 기업이 영세하다는 걸 알 수 있습니다.
   연매출 10억 정도는 약 10여명의 직원이 근무하는 회사로 보시면 됩니다.
   50억에서 100억 정도하는 규모는 아주 장사가 잘되는 SI회사 정도로 생각하시면 됩니다.
3. 패키지 소프트웨어 기업현황
   
   
   글로벌 SW를 대기업 SI를 통해 시장공급을 하는 구조로 2004년 이후 기업 수가 점점 줄어들다가, 2009년 모바일 확산에 따라 스마트폰, SaaS, 보안업체등의 기업이 증가하고 있습니다.
   하지만,연매출 10억 이하 기업이 55.5%, 50억 미만의 기업이 87.3%로 여전히 영세한 구조입니다.
4. IT서비스 기업현황
   
   
   IT서비스 기업은 컨설팅, SI, SM 세 분야를 포함하고 있습니다. 결국 인건비 기반의 외주산업인데요. 2005년 이후 다소 편차가 있지만 연평균 11.5%의 꾸준한 성장세를 보이고 있습니다.
   연매출 10억 이하 기업이 50.5%, 50억 미만이 83%로 패키지 소프트웨어 기업보다는 조금 더 상황이 낫습니다.
   하지만, 영세성은 동일하다고 볼 수 있습니다.
5. 소프트웨어 산업 인력현황
   
   
   2010년 국내 SW산업인력은 16.6만명으로 2009년 대비 9.2% 증가했습니다.
   2008년 홈페이지 외주제작,호스팅 서비스의 증가로 12.1%의 가장 높은 증가율을 보였습니다.
   이 때 타산업 전산직(전산실)의 경우 지속적인 감소추세를 보입니다.
   패키지소프트웨어 보다 IT서비스 분야의 증가율이 뚜렷해서 “SI, SM시장의 성장”이 인력유입을 견인했던 것으로 보여집니다.
6. 국내 소프트웨어 기업 실적 현황
   
   
   매출추이를 보는 건 현실감이 떨어지는 것 같습니다.
   쉽게 이야기하면, SI, SM기업의 경우 영업이익률이 7%, 패키지SW의 경우 9% 정도입니다.
   실패율이 높고 속임수가 있지만, 자꾸 개발자들이 프랜차이즈나 치킨집(32%)에 눈을 돌리는 이유도 이해가 갑니다.
7. 업종별 IT투자예산 현황
   
   국내 기업의 경우 투자예산의 88%정도를 실제로 집행했다고 합니다.
   2011년 기준 국내 기업들은 평균 매출액의 0.57%를 IT투자에 사용했군요.
   2010년을 보면 통신이 1.26%로 가장 높았는데, 합병을 통한 시스템 통합 및 고도화 이슈 때문이었던 것 같습니다.
   금융업은 차세대시스템 구축 이후 지속적으로 기간계 및 정보계 시스템에 고도화 투자를 진행하면서 두번째로 투자율이 높았습니다.
   
   
8. 국내 SW개발생산성 및 공학기술 현황
   
   SW공학 관점에서 평가한 점수라고 합니다.
   해외사례와 비교할 만한 자료는 찾지 못했습니다만, “프로세스, 도구 및 기법, 정량적 관리 영역에 대한 혁신적인 노력이 필요하다고 언급하고 있습니다.”

국내 IT시장의 한계

정철환 님의 글 “소프트웨어 개발자,미래는치킨집”에서 “아직 소프트웨어 만큼은 첨단화가 되어 있지 않다.”는 말에 공감이 갑니다.
오진연 님의 글 “개발자라고 다 금성출신인가?”에서 “개발자로서 자신의 영역을 한정짓지 말라.”는 말에도 공감이 됩니다.

이와 관련해서 국내 IT시장이 처해있는 몇가지 한계점에 대한 짧은 생각들을 정리해 보았습니다.

---

IT에 종사하는 사람들은 “대박신화”를 바라는 사람들이 유달리 많은 것 같습니다.
대부분의 성공신화는 “자기사업”에서 나오지 “아웃소싱” 분야에서 나오지 않습니다.
그러나, 국내 IT시장은 게임, 포털, 쇼핑몰 등 몇개 분야를 제외하고 나면, 대부분 “아웃소싱”시장이라고 할 수 있습니다.
이 아웃소싱 시장의 현황를 짚어보았습니다.

1) 멘토가 없다.

당신이 IT 사업을 하고 있다. 여러가지 문제로 어려움을 겪고 있다면, 대뜸 찾아가 터놓고 이야기 할 누군가가 있을까?
아마 생각나는 사람이 많지 않을 것이다. (교수님? 전 사장님?)

아래한글(1989)-리니지(1998)-네이버(1999) 등으로 이어지는 성공신화가 있고 그 주역들이 대한민국 IT성공 1세대로서 여러 곳에서 멘토로서 활동하고 있지만, 나머지 계층과의 거리감은 꽤 크다고 할 수 있다.
국내 IT 는 SI 중심으로 성장했는데(심지어 게임회사도 SI를 한다.), 아래한글의 성공과 SI의 성공은 많이 달라 참조하기 어려운 부분이 많다.

금융부문은 어떨까?
수많은 성공과 실패사례가 책과 사람의 입을 통해 떠다니고, 예순,일흔이 되시는 멘토들도 주변에서 어렵지 않게 구할 수 있다.
심지어 ING생명 같은 회사는 160여 년의 현장의 경험들이 사내지식으로 활용되고 있다.

반면 IT부문은, 성공1세의 대표라고 말할 수 있는 아래한글 개발진들도 아직 쉰살이 되지 못했다.
산업이 성장하려면 오랜 경험을 가진 멘토층의 역할이 매우 중요한데, 경륜을 통해 거시적 관점에서 문제를 짚고 멘토링할 수 있기 때문이다.

IT는 소프트웨어와 하드웨어에 대해 두터운 경험을 가진 베테랑 멘토층을 가질 필요가 있다.
도전과 성공, 실패에 대한 교훈들이 후배들에게 제대로 전수될 수 있어야 계속 발전할 수 있지 않을까 생각해본다.

2) 소프트웨어 개발자가 다양하지 않다.

윈도우 95이후 4GL 기반 C/S 시스템을 구축할 때 전공불문으로 사람을 뽑고 교육을 시켜서 개발자로 쓰던 시절이 있었다.
전문성이 떨어지는 단점이 있었지만, 품질시스템과 체계적 프로세스를 통해 어느정도 커버가 가능했다.
다양한 분야의 사람들이 모이다보니, 새롭고 창조적인 시도들이 많았다.
심리학 전공자가 소프트웨어 개발을 배우게 되니 당연히 자신의 학문과 접목하려던 시도를 하게 되었다.
이런 열기가 벤처창업의 열풍으로 이어져 나갔다.
반면, 최근에는 IT교육 인프라가 열악해서 거의 대부분 전산과 출신들만 개발자로 입문한다.
전문성은 높아지는 반면, 창의적인 시도들이 많이 줄어들게 되었다.
– 비합리적이고 무대뽀적인 창업도전은 보기 힘들어졌다. :-)

IT 기술이 생활 속으로 들어와야 산업이 성장할 수 있다고 생각한다.
꾸준한 소비가 꾸준한 투자를 만들어내기 때문이다.

그러기 위해서는 다양한 사회적 경험들이 소프트웨어나 하드웨어 개발의 세계와 만나야 한다.
– 예를 들면, 하이마트나 쇼핑몰은 오프라인 유통을 IT로 해석했기 때문에 가능한 사업모델들이다.

제일 좋은 것은 다양한 전공을 가진 학생들이 개발자로 유입되는 것이다.
그 다음은 의사나 교수 등이 개발을 배워서 해볼 수 있도록 기술장벽이 낮아지는 것이다.
개발자의 다양성은 창의성과 도전을 낳고 사회를 폭넓게 발전시킬 수 있을거라고 생각한다.

쉽게 되지 않겠지만, 다양한 문제들을 IT를 통해 풀고자 하기 때문에 필연적으로 그렇게 되지 않을까 생각된다.

3) SI 시장이 한계에 다다랐다.

SI란 시스템 통합(System Integration)을 말한다.
기업들이 신규사업을 위한 전산시스템을 도입하거나 수작업 업무를 전산화할 때는, 평소에 잘 사용하지 않던 하드웨어와 소프트웨어의 여러 분야에 걸친 통합된 기술들을 필요하게 된다.
본업이 전산이 아닌 경우는 이 경우 IT 아웃소싱을 통해 해결했는데, 차츰 사업특성이 용역 개념으로 바뀌면서 이제는 “SI”는 “전문 소프트웨어 개발용역업”을 지칭하는 대명사가 되어버렸다.
그동안 우리나라에서 이 시장이 성장한 이유는 두 가지로 볼 수 있다.

첫째, 전산화될 수작업 영역이 지천에 널려 있었다.

한국 정보화 진흥원에서 정리한 “IT 역사자료관” 을 들러보자.
우리나라는 1994년 정통부 설립부터 2008년 정통부가 없어질 때까지 국가에서 많은 돈을 시장에 쏟아내었다.
한때 공공근로 사업을 하기도 했었다.
이때 인력파견 업체를 만들어 어렵지 않게 돈을 버신 분들도 있다.
새로운 가치를 만들어 내는 것보다, 그냥 무언가를 만든다는 것이 중요했다.
뭔가를 만들면 가치가 만들어질거라고 생각했다.
SI산업의 성장과 함께, 이제는 대한민국 땅에서 전산화되지 않은 것이 거의 없을 정도가 되었다.

둘째, 몇 개의 시스템을 통합하는 것만으로도 쉽게 비용효율화가 달성될 수 있었다.

메인프레임에서 유닉스 시스템,Linux, Cloud 등 하드웨어 가격이 지속적으로 낮아지고 IT환경이 빠르게 바뀌면서, 효용성이 다한 시스템들이 골치거리로 떠올랐다.
대형 SI업체들이 비용 효율성을 팔았고, 공공이나 기업들은 그 혜택을 보았다.

포스코 DW 구축사례(2004),

국세청 차세대 국제통합 시스템 구축(2006)

하지만, 경쟁과열로 인한 단가 하락과 대형사업에 대한 경험부족으로 주사업자와 고객이 모두 막대한 피해를 입기도 했다.

대한생명,한국HP ‘NK21′ 지연비용 논란(2003.11)

SKT NGM 프로젝트 중단배경, 전망 (2005.3.28)

차세대 IT 프로젝트 실패에서 배운다(2009.8.30)

SI시장이 포화되면서 신규 투자가 줄고, 아웃소싱 시장이 점차 개발 유지보수 시장으로 넘어가고 있다.
유지보수 시장은 변화가 적은 만큼 경쟁도 치열하고 부가가치와 생산성이 낮은 편이다.
사업자들은 리스크는 높지만, 수익률이 높은 자체 사업을 시도하거나 새로운 생존방식을 모색할 수 밖에 없게 되었다.
SI 중심의 시장은 질적성장보다 양적 성장 중심으로 획일화되어 있어, 좀 더 다양해질 필요가 있다.
그런 측면에서 최근의 변화를 오히려 긍정적으로 바라볼 수도 있을 것 같다.

4) 멘토부터 시작하자.

위에 이야기한 시장의 한계는 쉽게 극복될 수 있지는 않을 것이다.
다루어야할 주제가 크고 사회적, 정책적 접근도 필요하다고 생각한다.
하지만, 멘토라는 주제는 노력하면 만들 수 있는 문화라고 생각한다.

스마트폰을 기반으로 한 앱스토어 시장이 열리면서,소프트웨어 시장환경이 글로벌화 되어버렸다.
그래서, 개인창업 기회도 좀 더 넓어졌다.경기불황과 함께 새로운 창업도 늘어나고 있다.
개인창업이 늘고 있는 건 어떤 관점에서 좋은 변화라고 생각한다.
올해도 대학 졸업생들은 어디선가 벤처에 취직해서 사회생활을 시작할 것이다.
하지만, 이들이 미래를 위해 참고할 이정표는 매우 부족하다.

IT의 선배들이 수줍음을 깨고 블로그나 트위터를 통해서 좀 더 많은 기록활동 들을 했으면 좋겠다.
기록활동은 모이면 모일수록, 시간이 지나면 지날수록 뒤따르는 자에게 큰 도움이 되기 때문이다.
그리고, 커뮤니티를 통해 적극적으로 후배들과의 교류를 넓혀갔으면 좋겠다.
이 분야의 멘토로서 같은 길을 가는 동료로서, 많은 정보의 교류들이 이루어졌으면 좋겠다.

먹고 사는 문제도 중요하지만, 개발자들이 개발자 세계에 대한 소속감을 가지고 주변에 조금 더 관심을 가져야 한다고 생각한다.
하드웨어나 소프트웨어 개발자가 되기 위한 진입장벽이 낮아지면, 다양한 경험을 가진 사람들이 IT의 세계로 들어올 것이다.
그렇게 되면, 다양하고 새로운 창업들이 많이 나타날 것이다.
그리고, 그 창업에너지는 국내사회의 여러 산업에 대한 부가가치를 더 높일 수 있을 것이다.

IT가 없는 미래사회는 상상할 수 없다.
그 미래사회는 선배가 후배를 양성하고 함께 일하는 선순환 구조가 만들어져야지만 갈 수 있는 길이라고 생각한다.
트위터나 블로그 등 과거에 비해 정보 커뮤니케이션이 더 많아졌지만, 좀 더 적극적으로 활성화되었으면 싶다.
좀 거창한 이야기가 되었지만, 업계의 베테랑이라면 꼭 한 번 관심을 가지고 생각볼 주제가 아닌가 싶다.

더 보기»