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 – 재무지식

http://subokim.wordpress.com/2013/02/13/the-type-of-it-comapny/

IT회사의 유형

(Technical Sales, 실제 현장에서 이런 멋있는 화면은 거의 연출되지 않는다.)

---

취업을 준비하는 예비 개발자들이 어떤 회사에 취직해야 할 지 선배들을 찾아 다니는 때인데요.
베테랑들이라면 대부분 알고 있습니다만,모르는 사람들께 정보가 될까 하여 아는 범위 내에서 몇 개 회사 유형별로 “무엇을 만들고”, “무엇을 파는지” 정리해보았습니다.
회사의 형태가 다양하기 때문에 아래처럼 똑 부러지게 분류되지는 않습니다.
많지는 않지만, 그냥 참고가 되었으면 합니다.

1) SI (IT 아웃소싱) 회사

“영업은 계약을 수주하고, 개발은 일을 하고 돈을 받아냅니다.”

개발팀은 프로그래머로 구성됩니다.
기업이 과제에 대한 입찰 공고를 내면, 업체들이 자신들의 기술을 이용해 과제수행 계획을 제안합니다. 이 제안서를 쓰는 것은 개발팀의 역할입니다.

영업은 기존 고객 관리와 새로운 시장 탐색을 합니다.

“돈은 프로젝트 수행 대가를 받아서 법니다.”

해외 시장의 경우는, 인건비가 높아서 인기있는 직업인데, 우리나라의 경우 기준 인건비가 낮아서 기피현상이 심합니다.
우리나라도 수요가 공급보다 높아지면 상황이 많이 달라질거라고 생각해봅니다.
(2000 년대는 개발자 유입이 수요에 비해 많았습니다.)

삼성SDS, HP, IBM 등 큰 회사부터 작은 회사까지 다양합니다.
하지만, 큰 회사나 작은 회사나 일하는 건 별반 차이가 없습니다.
큰 회사일수록 개발업무보다는 관리업무를 더 빨리 배울 수 있습니다.

2) 패키지 솔루션(오라클, ERP, CRM 등) 회사

“개발은 제품Product을 만들고, 영업은 제품Product을 팝니다.”

개발팀은 프로그래머와 제품 기획자, 엄격한 검수자로 구성됩니다.
영업은 고객영업(채널)과 기술영업으로 나뉩니다. 기술영업은 컨설턴트로 불리우기도 합니다.
사이트 별로 기술지원하는 SE(솔루션 엔지니어)가 있습니다.
SE는 개발자들이 잘 개발할 수 있도록 기술지원을 하거나, 솔루션의 최적화를 지원합니다.

신규 제품은 SI 회사를 통해 시장에 팝니다. 즉, SI 회사가 제품의 시장보급 역할을 맡습니다.
제품이 팔리고 나면 기술지원, 서버 확장, 라이센스 등을 통해 유지보수 수익을 올립니다.

“돈은 제품 판매 수익New Sales과 유지보수 수익Maintenance으로 법니다.”

SI 시장이 포화가 되면서, 판매 중심에서 유지보수 중심으로 시장전략이 바뀝니다.
최근에는 클라우드와 오픈소스의 출현으로 유지보수 시장마저도 축소되고 있어서, 전략변화가 심합니다.

국내 솔루션은 오랫동안 정책적으로 육성되지 않아서 거의 찾아보기 힘듭니다.
일반적으로 제품의 완성도가 올라갈 때까지 정부가 꾸준히 투자해주어야 하는데요.
IT 솔루션이 하나의 훌륭한 산업이 된다는 정부의 인식이 부족했기 때문이 아닌가 싶습니다.

오라클 외산 솔루션의 경우는 내부 개발자가 없고, Timax, Altibase, Kairos 등 국내 회사는 개발팀을 보유하고 있습니다.

3) 솔루션 SI 회사

“개발팀은 제품을 만들고, 영업은 계약을 수주합니다.
프로젝트 팀은 제품을 이용해 프로젝트를 합니다.”

SI를 통해 반제품을 만들고, 비슷한 프로젝트에 들어가서 소스를 재활용합니다.
repetition-plus-capabilities 라고, 반제품을 통해 개발원가를 낮추어서 이익을 실현하는 전략입니다.
어떤 회사는 시장 검증을 통해 자사 솔루션의 완성도를 높이기 위해 SI를 하기도 합니다.

업무가 정형화되어 있는 분야에서 많이 취하는 전략으로, 금융 분야나 ERP 분야에서 많이 볼 수 있습니다.

회사 내에 연구소와 SI 프로젝트 팀을 가지고 있습니다.
우리 나라의 경우는, 커스터마이징이 많고, 반제품의 가치를 인정해주지 않아서 이익실현이 어렵습니다. 그래서, ASP 서비스 형태로 전환을 시도하기도 합니다.

그러나 솔루션SI는 개발원가를 낮추고, 박리다매로 빠른 프로젝트를 통해 돈을 버는 모델이고,
ASP는 월 이용료를 받아서 돈을 버는 서비스 모델인데요.
고객과 시장이 달라지므로 이에 맞게 판매와 영업조직도 바뀌어야 하는데, 이를 이해하지 못하고 사업모델을 전환하다가 실패하는 회사가 많습니다.

4) 응용소프트웨어(아래한글, V3, 기업용 패키지) 회사

“개발팀은 제품을 만들고, 유통을 통해 제품을 판매합니다.
공공에 납품하기 위해 전문 영업조직을 만들기도 합니다.”

제품의 품질이 중요해서 개발팀의 역할이 매우 중요합니다.
제품 출시 후 업데이트가 불가능하므로, 기능 하나를 더하고 빼는게 매우 어렵습니다.
개발팀은 제품기획자, 프로그래머와 검수자를 포함합니다.

“패키지솔루션”과 다른 점은 SI회사를 통해 공급하지 않고, 직접 시장에 제품을 판다는게 다릅니다.

“마케팅과 유통으로 제품을 팝니다.”

반면 기업용 협업 도구들은 오픈소스화되거나, 클라우드 기반의 사용료 모델로 가고 있는 등, 제품 전략과 판매 전략의 변화가 심합니다.

기술구조가 PC기반 클라이언트 중심에서 웹환경으로 바뀌고 있는 추세이고, 그에 따른 수익모델도 바뀌어야 해서 새로운 사업적 시도가 많이 되고 있습니다.

5) 서비스 회사

“개발팀이 서비스를 만들고, 마케팅이 서비스를 팝니다.
무료 서비스로 사람을 모으고, 광고를 통해 돈을 버는 전략입니다.
중개수수료 등 복잡한 사업모델을 가진 회사도 있습니다. 쇼핑몰처럼 오프라인 유통을 카피한 회사도 있습니다.”

개발팀은 프로그래머와 기획자로 구성됩니다.
마케팅은 고객을 연구하고 시장전략을 수립합니다.

“판매는 비즈니스모델을 통해서 합니다.”

창의적인 아이디어만 있으면 소프트웨어 만으로 제품Product을 만들 수 있어서 스타트업이 많은 분야입니다. 무형이므로 고객이 느끼는 서비스의 가치와 만족도가 매우 중요합니다.

대박이 터지면 크게 터지지만, 성공율이 높지 않습니다.

6) 컨설팅 회사

“고객의 문제를 해결하는 고민의 결과물이 상품Product입니다.”

비슷한 패턴의 문제는 있은나, 동일한 문제는 없습니다.
따라서 비슷한 문제를 접했더라도 지식노동의 강도는 동일합니다.

고객에게 컨설팅이라는 용역을 제공하고 돈을 받습니다. 다만, 대가의 크기는 고객이 문제로 인해 고생하는 만큼 비례합니다. 또는, 향후 사업가치의 크기에 비례하기도 합니다.
물론, 그만큼 고생합니다.

컨설팅은 고객의 문제를 발견해내거나 고민을 끄집어 내는 행위가 영업 행위입니다.
본질과 요점을 짚어야 하므로, 고객에 대한 깊은 이해가 기본입니다.
따라서, 신규 사이트를 떠돌아 다니는 영업보다는 사이트별로 관리하는 채널영업이 중심입니다.

High Level 컨설팅은 드라마에서 나오는 것처럼 멋집니다만, 입사하기 매우 힘듭니다.
맥킨지 등이 있습니다. Mid Range 컨설턴트는 현업에서 발생되는 실무적 고민을 컨설팅합니다. 생각보다 화려하지 않습니다.
HP나 IBM의 경우 컨설턴트가 대형프로젝트의 마스터PM으로 나가는 경우도 종종 있습니다.

7) 게임회사

관련링크를 첨부합니다.

국내 게임회사들

해외 게임회사