표준의 규모. 작은 것이 맞는가? 큰 것이 맞는가?

한국MS의 어줍잖은 변증법 via Channy’s blog
당신은 무엇 때문에 기술표준을 따르나 via 서명덕기자의 人터넷세상

이 두가지 포스팅을 읽던 중, 눈에 들어온 것이 하나 있었다. 한국MS의 ODF(Open Document Format)에 한 반론중, OpenXML은 “크지만 안정적” 이고, ODF는 “간결하지만 지속적으로 규모가 증가” 한다는 이야기인데, 표준의 규모에 대한 생각이 문득 들었다.

물론, 무엇에 관한 표준인지, 무엇을 담고 있는 표준인지가 중요하겠지만, 내 생각에 표준은 작고 간결해야한다. 표준이 크고 복잡하면 복잡할 수록 구현은 힘들어지고, 고려할 사항이 복잡해지기 때문이다. 그리고, 복잡할 수록 재사용이 난감해지는 경향이 있다. 작고 간결한 여러 종류의 (다른 기능적인) 표준이 존재하고 서로 의존적인 관계를 갖고 있다고 하면, 원하는 결과물을 얻기 위해 표준을 섞는 일이 가능해진다. 다른 표준에 의존할 수 있는 것은 의존하는 것이 맞다. 예를 들어, XHTML에 벡터그래픽에 대한 요구사항이 커졌다고 해서, XHTML 3.0에 벡터그래픽요소를 정의할 필요는 없다. XHTML 1.0문서와 SVG문서를 섞어서 사용하는 것만으로 충분히 구현이 가능하기 때문이다.

작고 간결한 표준은, 해당 표준을 준수하는 처리기processor 나 구현체implementation를 만드는데 필요한 리소스를 줄이는 데에도 큰 역할을 할 수 있다. 그리고, 리소스가 줄어든다고 하는 것은, 해당 표준에 대한 오픈소스 처리기/구현체의 증가를 의미하기도 하며, 좋은 참조구현reference implementation의 등장을 의미한다. XML이 지금보다 훨씬 복잡하고 잡다한 내용을 전부 담고있는 표준이었다고 생각해보자. 지금처럼 히트칠 수 는 없었을 것이다.

OOP(객체 지향 프로그래밍: Object Oriented Programming)적인 관점에서 바라본다면, 표준은 일종의 클래스class라고 할 수 있다. 생각해보자, 거대하면서 모든 일을 혼자 다 해치우는 클래스 하나가 좋은지, 자기 할일만 제대로 해내는 (그리고 변경하기 쉬운) 작은 클래스 여럿으로 구성되는 것이 좋은지. 답은 명확하다. 할 수 있는 한, 클래스는 작아야한다. 표준도 마찬가지다. 가능한 작아야한다. 원하는 기능이 다른 표준에 정의되어 있다면, 가져다 쓰는 것이 맞다. 굳이 여러번 정의할 필요는 없는거다.

표준. 작고 간결해야 표준으로서 가치를 갖게 되리라 믿는다. 정의가 존재한다면…

ps. 무려 1달하고도 9일만의 포스팅.. 덜덜.

development as a war

프로로서 프로그래밍을 한다는 것 -즉, 돈을 받고 프로그래밍을 한다는 것-은 돈을 매개로 싸우는 전쟁터에 나간다는 의미이다.

결국은, 비용과의 전쟁이다. 하드웨어 비용과의 전쟁. 소스코드 유지비용과의 전쟁. 프로그래머의 임금과의 전쟁. 고객사 지출비용과의 전쟁. 고장난 하드웨어 기판 수리비용과의 전쟁.

이런 전쟁에서 프로그래머가 싸우는 필드는 자신의 컴퓨터와 마우스, 키보드가 아니라 팀원들과 공유하는 작업실 공간이다. 이런 전장에서 필요한 타입의 병력(?)이 존재한다.

지금 일하고 있는 팀을 이야기할때 종종 사용되는 비유가 있다. 기마병, 보병, 병참 및 작전.

기마병은 적진의 한가운데를 돌파하여 적진을 혼란에 빠지게 하면서, 돌파구를 찾는 역할이다. 프로그래머라면 전에 언급되었던 람보개발자일 것이다. 난제를 풀어 나가며, 길을 뚫어놓는 역할. 기마병이 없다면 팀은 앞으로 나아갈 수 없다.

보병은 기마병이 혼란에 휩싸이게한 적진을 압박해나가며, 점령지를 늘리는 역할이다. 람보개발자가 뚫어놓은 돌파구를 다져가며, 안정성을 확보하고 제품을 제품답게 만드는 건축가개발자라고 볼 수 있다. 팀을 뒤로 가지 않게 하는 것, 지속적으로 돌파구를 뚫어낼 수 있는 기반을 확보하는 것, 이 일이 없다면, 제품은 제품이 아니라 아이디어일 뿐이다.

그런가 하면, 병참과 작전도 매우 중요하다. 다른 부서와의 인터페이스, 스케쥴의 조정, 방향성의 설정등의 전체를 조망하며 팀의 결속을 강화하고 팀을 유지시키는 것. 이것이 없다면, 람보개발자도, 건축가개발자도 일을 할 수 없을 것이다.

팀의 역량과 상황에 맞추어 저 역할들은 유동적으로 agile하게 변해야한다. 기마대가 너무 난리를 피우고 다니면, 보병이 뒷수습하기가 너무 힘들어진다. 역으로 보병이 뒷수습을 못해주면, 기마대는 전멸하게 되어있다. 이런 상황을 제어하지 못할 경우는 말할 나위도 없다. 때로는 기마대가 말에서 내려 보병이 되어야하고, 돌파가 힘들면 보병이 말에 타고 돌격을 해야한다.

프로그래머가 공부를 해야하는 이유는 바로 저 유동성에 있다. 언제라도 상황에 맞추어 작업할 수 있는 능력. 때로는 기마대가 되어 돌파를 하고, 때로는 보병이 되어 뒷수습을 하고, 병참과 작전을 도맡아 상황을 제어하기도 해야하니 말이다.

만약, 저 세 가지를 한번에 요구하는 경우가 생긴다면, 조직을 바꾸도록 노력을 해봐야한다. 해도 안된다면 이직을 고려하라. 🙂

Google Spreadsheets & 몇가지 잡상

구글이 이번에 테스팅을 시작했다는 Google Spreadsheets. 그냥 넘어가볼수는 없기에 어제 테스팅을 신청했습니다. 아침에 출근했더니 메일함에 “후딱 오셈” 이란 내용을 암시하는 듯한 초청장이 와있더군요. 후후. (실은 Writely도 신청했는데 아직 안나왔다는… analytics는 신청한지 한참있다 나왔어요.. -_-)

기존의 스프레드 쉬트 프로그램에서 자주 쓰던 함수들도 구현이 잘 되어있고, 그럭저럭 쓸만합니다. 뭐랄까.. 신기하달까? AJAX로 이정도의 구현이 가능하다는게 놀라울 따름입니다. 허허. Excel이나 csv로 출력하는 기능도 잘 되어 있구요.

MS의 Excel에서 자주 쓰던 기능을 몇가지 해보았는데, 함수 쓸때 드래그로 범위 잡아주는 건 잘 되고, Ctrl+클릭으로 여러 셀을 한번에 지정하는건 안됩니다. 숫자 2개를 써놓고 끝에 잡고 늘리면 등차수열이 만들어지는 기능(설명이 어렵나요?)도 안되고… 아직은 테스트 단계이니 수정이 되리라고 보긴 합니다만.. 구현이 만만치는 않을 듯 하네요. 아. 셀 서식 기능이 좀 딸립니다. 선긋기 정도는 되어야…. _-_

생각해보면, 옛날 도스시절에 쓰던 로터스 1-2-3같은 스프레드 쉬트랑 비교해보면, 기본에 충실해있다는 느낌이 강합니다. 그리고 Sharing option을 보니, 다른 사용자와 손쉽게 공유할 수 있도록 되어있네요.
문득 Gnumeric이 생각이 났었습니다. 초창기의 Gnumeric을 보는 느낌이랄까요? (요즘은 Excel에 절대 뒤지지 않습니다만.. 허허. 오픈 오피스에 좀 밀리는 느낌이.. T_T)

MS Office vs. Open Office가 데스크탑에서 열심히(표준을 놓고) 싸우고 있을때 웹기반의 생산성 플랫폼으로 변신을 꾀하고 있는 Google. 그들의 행보가 내심 무서워지는 것은 SF를 즐겨읽는 제 탓일까요?

왜 람보 개발자인가?

밝혀두건데, 이번 “SW개발자들이여, ‘람보’가 되라” 사건(?)의 폭풍의 핵이신 김대환 사장님과 병특으로 2년째, 프리랜서까지 포함하면 3년째 같이 일하고 있습니다.

‘람보’라는 마초적인 단어가 내포하고 있는 의미는 영화에서 처럼 무식하게 혼자 일을 다 해치우는 슈퍼 울트라 히어로 메가톤급 개발자를 의미하는 것은 아니라고 생각합니다. 소프트웨어 분야는 분명, 소프트하며 이런 특성은 한명의 인력이 해낼 수 있는 것이 10인분 많게는 100인분이라고 볼 수 있지요. 코드의 미적 요소 (건축과 비견되는 것입니다. 웹디자인 생각하지 마세요.), 효율성, 매일 부딪히는 수학문제들(주로 Complexity지요.)과 같은 두뇌의 회전 방향에 의해 결정되는 것들이 많은 것이 소프트웨어 산업의 현장입니다. 더 보기 “왜 람보 개발자인가?”

영감과 코드

수많은 선구자들은 “기술적 영감- techinical inspiration”이라는 걸 얻어서 컴퓨터-기술역사에 한 획을 긋고 자신의 이름을 후세에 널리 알림과 동시에 저서를 통해 후세들이 먹고 살 기반까지 마련해주는 경우가 종종 있다. 비록 짧은 50년의 역사이긴 하지만, 가장 급속도로 발전한 학문분야라고 할 수 있으며, 수학에 단련된 천재라면 당연한 일이라고 생각될 수 도 있다.

더 보기 “영감과 코드”

프로그래머의 3대 덕목.

회사 인트라넷에 대충 올렸던 걸 다시 정리해서..말하자면 재활용입죠. 하하.

세계에서 가장 많이 쓰이는 스크립트 언어중 하나인 perl을 만든 Larry Wall아저씨는, laziness가 프로그래머의 덕목이라고 주장을 합니다아. 맞는 말이죠. Randal Schwartz라는 사람은 Camel Book에서 3대 덕목으로 확장시켜서 주장을 합니다..

원문 : Virtues of a Perl Programmer

펄 프로그래머의 덕목이라고 되어있지만, 실은 모든 프로그래머에게 적용되는 사항인듯 합니다.

머리아프다고.. 영어라고.. 저 쪽에서부터 돌이 날아오는 소리가 들리기에 대충 요약 해보지요.


1. Laziness – 게으름 혹은 귀차니즘.

에너지 소모를 줄이기 위한 노력을 하게끔 하는 녀석입니다. 요는 프로그래밍을 할 때 최대한 노동량을 줄이기 위한 방향으로 짠다는 것이지요. 예를 들면 자주쓰는 루틴 같은 것은 라이브러리로 빼놓는 다 던지, 상속관계를 잘 사용해서 타이핑 수를 줄이거나 생각해야 하는 량을 줄인다던지 하는 것들입니다. 이런 식의 작업을 하다보면, 모듈화/라이브러리화가 진행되기 마련이지요..

모듈화/라이브러리화가 진행되면 다른 사람들도 사용하게 됩니다. – 열린소스이든 닫힌소스이든 마찬가지지요. 혼자 코딩하는 것이 아니라면 말이죠.. – 이렇게 될 경우, 작성한 프로그래머는 수없이 많은 질문의 바다에 빠져 허우적대기 시작합니다. 그럼 그 질문들이 귀찮아서 문서화를 하게 되지요. 한번의 투자로 반복을 하지 않는 것. 이것이 게으름 혹은 귀차니즘 입니다. 멋지지 않나요?

2. Impatience – 참을성 없음

컴퓨터가 못놀게 하는 겁니다. 그때 그때 필요한 코드만 작성하는 것이 아니라, 앞으로 필요해질 것들까지 작성하는 것이지요. 꼭 작성하지 않더라도 최소한 준비는 하는 겁니다. 확장성이라든지 기타 등등.

할 수 있을때 미리미리 하거나, 아니면 미리미리 준비하는 참을성 없음. 참 아름다운 덕목입니다. 어찌보면, laziness의 확장판이라고도 할 수 있지요.

3. Hurbis – 자만

하늘을 찔러 구멍을 내고 바다를 찍어 마르게 할 정도의 자존심! 감히 단점이 언급되지 않을 정도의 프로그램을 작성하게 하는 자기만족! 더 말할 나위 없이 세번째!


참 글을 재밌게 쓰는 사람들 입니다. 하하.
전적으로 동의하게 만드는 사항들이지요. 하아. 언제쯤이면 3번째를 만족시키며 살 수 있을까나..

들뢰즈와 programming.

(들뢰즈라기 보단 이진경이긴 한데.. -_-;)

노마디즘을 다시 읽고 있는 요즘, template을 이용한 Generics와 유사한 점을 발견. 순간 기뻤다.

"기계" 라는 개념과 "template"라는 기능이 의외로 유사한 점을 보여주는데, 이는 배치와 접속에 따라 달라지는 무언가를 공유하고 있다는 느낌.

template는 형과 상관 없이 어떤 알고리즘이나 구조를 서술하는데는 적격인 녀석이다. int이든 double이든 float이든 (심지어는 string이든!!) 상관하지 않고 적용될 수 있는 알고리즘 같은 것 말이다.

이런 유사성을 발견하고 나서, 생각해보니 programming에 들뢰즈씨의 멋진 개념들이 적용될 수 있는 것은 무엇일까 라는 생각이 들었다.

생각의 선은 주욱 타고 올라가, 한때 논란거리였던 마이크로 커널과 모놀리딕 커널까지 올라가게 되었다. 이힛. 마이크로 커널은 좀
자율적인 모듈(프로세스)들이 서로 메시지를 주고 받으며 자신이 해야할 최소한의 역할만 수행하면서 유기적으로 연결되어 작동하는
일종의 리좀(스러운 무언가)이고, 모놀리딕 커널은 그런 분화없이 서로 동일한 공간내에서 tight하게 연결되어 제어되는 일종의
수목(스러운 무언가) 라고 생각된다. 결론은 어떻게 났냐고? 마이크로 커널로 개발되던 GNU/Hurd와 모놀리딕 커널로 개발되던
Linux의 양대 오픈소스 커널이 어떤 길을 걸었는지 생각해보면 쉽게 나온다. 모놀리딕이 이겼다.

그렇다고 해서, 오랜만에 찾아낸 멋진 단초를 버릴 수는 없다. 요즘 필요한 것이 flexible한 framework이고, 이
framework를 설계하는데 중심사상(?)으로 사용될 무언가를 발견하고자 하는 의지. 이게 산다는 것이지. 우훗.

"기관없는 신체"와 연결되어 프로그래머의 욕망을 실현시킬 수동적인 버젼의 리좀. 욕망의 실현을 위해 전부 재작성 하지 않고,
단지 배치만 바꾸어 원하는 바를 이룰수 있는 framework. 많은 사람들이 꿈꿔온 것이고, 사례도 많지만, COM+나
EJB나 기타 등등 다른 것들이 현재 요구사항을 만족시키지 못하는 것도 사실이니…

한 2주정도 고민해봐야겠다. 🙂

Activity Based Programming

회사동료인 ica씨와 이야기하다 3년 전에 만들어둔 개념이 문득문득 불끈불끈 솟아올라서 정리해보기.

Entity
Flow를 타고 흐르는 시작에서 끝까지의 Instance를 의미.
단위 트랜잭션으로 볼 수도 있고, 단위 컨텍스트로 볼 수도 있다. 기본적으로는 인풋이 발생할때마다 하나씩 생성된다.
공장으로 치면 컨베이어 벨트위에 있는 가공중인 제품이다.

Activity
Entity를 받아서 가공하고 넘겨주는 최소로직의 단위.
공장으로 치면 각각의 작업자.

Resource
Activity에서 사용하는 시스템 자원들.
역시나 공장으로 치면 작업자들이 쓰는 공구.

Flow
Entity가 어떤 Activity를 거쳐서 지나가는지에 관한 정의.
공장으로 치면 컨베이어 벨트다.

사실 이런 개념을 만드는데 영향을 준 Business Process나 Manufacturing Process에서는 모든걸 Resource로 보는 경향이 있긴 하지만, 이건 생각하기 나름인거 같다.

이런 방식은 보통 프로그래밍을 할때 생각하는 방식을 좀 벗어난 것으로, 실제로 적용된다면 프로그램의 수정/유지보수가 상당히
간단해질 듯 하다. 사실 OOP라는게 너무 광범위 하고 사람별로 멋대로 짤 수 있는 상황인 반면에 OOP를 이용해 ABP를
적용하면 틀(?)이 좀 더 쉽게 잡히지 않나 싶다.

내가 생각해낸게 그렇지만, 누군가 미리 해놓은걸꺼다. 🙁
오랜만에 Research나 해볼까? ㅋㅋ

최근 즐겨쓰기 시작한 C++ Template등을 이용해 만들면 이쁘지 않을까.. 라는 생각이 들어버렸다.

오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (사용자편)

오픈소스. 유지비용의 감소. (사회편1)
오픈소스. 유지비용의 감소. (사회편2 – 결론)

0.

function __toggle_hide_zone10()
{
elm = document.getElementById(“hide_zone10”);
if(elm.style.visibility == ‘visible’) __hide_hide_zone10();
else __show_hide_zone10();
}
function __show_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’visible’;
elm.style.display=”block”;
}
function __hide_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’hidden’;
elm.style.display=”none”;
}


그냥 살아온 부분

해커문화를 접하게 된 건, 고등학교때 읽었던 몇권의 서적에서.

오픈소스를 접하게 된 건, 대학들어와 만난 모씨에 의해서.

처음 접하게 된 오픈소스는 모씨에 의한 영향인지 맑스와 연관되어 생각되기 시작했다.

FSF와 GNU, GPL에 의해 만들어진 신세계는 놀라운 것이었으며, 활발하게 활동하는 수많은 멋진 프로그래머들은 동경의 대상이 되어버렸다.

그리고, 사용.

과서버를 관리하기 시작한 뒤, 리눅스를 사용할 수 밖에 없게 되었고, Social Contract라는 멋진 약속을 표방하는 Debian을 만나게 되었다. (thx to 승준)

대부분이 영어권 사용자인 오픈소스의 세계에서 CJK문제를 만나게 되었고, 이를 해결하기 위한 유니코드를 만나게 되었으며,
w3c와 같은 표준안 제정 단체를 알게 되었다. 표준을 알면 알수록 독점적 지위에 의해 발생하는 안타까움을 알게 되었고, 이
안타까움은 일종의 신념으로 변했다.

CJK문제를 해결하기 위한 버그레포팅, 패치 제안 등을 하면서.

잡히지 않는 랜카드를 잡기 위해 커널소스를 분석하면서, 조금씩 발전하는 모습을 발견하곤 하였으며, 묘한 희열도 느끼게 되었다.


1. 견제.

MS는 이미 독점을 맛보았으며, 독점으로 얼마나 돈을 벌 수 있는지를 알고 있다. 한때, 기업시장(PC급 서버 및 그보다 조금
상위의 장비들)에서 윈도우NT의 비율은 Unix를 누르며 급격히 성장했으며 이 당시 리눅스는 상대도 안되는 것으로 치부하고
있었다. 그러나, 엔터프라이즈 리눅스를 표방한 2.4의 발표와 함께 진입하기 시작한 리눅스의 거센 공격에 MS는 초조함을 감추지
못하고 각종 언론에 노출되는 여러 문서들을 남기게 된다. (정확히 기억은 안나지만, 몇가지 되는 것으로 기억함)

리눅스를 견제하기 시작한 것이다.

얼마전, MS측에서 리눅스의 총소유비용(TCO)이 윈도우에 비해 크다고 주장한 적이 있다.

굉장하다. 핀란드의 한 프로그래머가 시작한 프로젝트가 MS에 의해 견제를 받는 지위까지 올라가다니.

물론, 실제로 발표된 논문은 그런 내용이 아니었다.

ZDNet 관련기사

MS는 자신들의 NT가 사용되고 있는 위치에서 리눅스에게 시장을 빼앗기고 싶어하지 않는다.

2. 기업입장의 유지비용


(1) 개발자를 잡기 위해서.

MS플랫폼 (뿐만 아니라 기타 상용 플랫폼) 을 사용하는 개발자들 중, 상용툴이나 플랫폼들을 돈주고 직접 구입해서 사용하는
개발자는 드물다. 사실 많은 수의 버그들이 개발자들이 개발을 하다가 발견하게 되는 경우가 많은데, 돈주고 사서 쓴게 아니므로
레포팅을 안하게 된다. (걸릴일 있습니까.. 버그 레포팅하게)

하지만, 오픈소스라면 다르다. 작업을 하다 버그사항을 발견하면 이를 직접 고쳐서 사용할 수 도 있고, 자신이 고친 내용을 해당
커뮤니티에 공개하고 다음 버젼에 적용시킬 수도 있다. 개발자에게 "자유"를 주는 것이다. 이 자유는 개발자가 마음대로 개발을 할
수 있는 토양을 제공해주며, 지원하는 해당 기업들에겐 자신들이 자사제품에 사용하고 있는 오픈소스 코드에 대한 관리/개발/유지
비용을 줄일 수 있다.

– 기업의 지원을 받는 많은 오픈소스 프로젝트들이 대부분 컨소시엄형태로 구성된다. 대표적인 사례가 IBM에서 오픈소스로 시작한
자바 개발툴인 Eclipse (http://www.eclipse.org) 프로젝트인데, 이에 참여한 기업들을 보면 손가락이
모자랄 정도의 숫자다. 각 기업들은 Eclipse의 기술을 자사제품에 적용시키고 있다. –

활발한 버그 레포팅과 이에 대한 능동적인 사용자의 패치시도, 적용 등은 오픈소스의 원동력이라고 할 수 있다.

(2) 기술지원 비용의 측면.

MS는 자사 웹서버인 IIS에 대한 기술지원을 위해 기술지원팀을 운영하며, 고객들의 전화에 머리가 아플지도 모르겠다. 대부분 돈주고 산 제품에 대해서는 전화해서 엄청나게 따져댄다. (직접 보고, 겪는 일입니다 ㅡㅜ)

하지만, ASF(Apache Software Foundation)도 그럴지는 의문이다. 아파치를 사용하는 사람들은 알아서 서로
기술지원을 해주기도 하고(주로 IRC?), 책도 사서 보고 공부도 하고, 정중하게 메일링리스트에 질문을 올리기도 한다.

(물론 대형 벤더들에서 만든 리눅스나 기타 유닉스에 포함된 아파치에 대해 각 벤더들에서 기술지원을 해주기는 한다.)

오픈소스 소프트웨어는 기술지원의 측면에서 상당히 자유로운 편이다. 해당 소프트웨어를 어떻게 사용하느냐의 문제는 전적으로
사용자에게 달려있기 때문이다. 물론, 메일링 리스트나, 게시판,매뉴얼 정도의 지원은 이루어진다. 이를 통해 해결되지 않는 것은
사람들끼리 서로 도와주거나, 자신이 직접 해결책을 찾아내야 한다. 이런 문제점은 아주 특수한 경우가 아니라면, 대부분 다수에게
발생하기 마련이고 누군가는 해결책을 찾아낸다. (대부분 개발자일 경우가 많죠.) 그리고, 이는 인터넷이라는 공간을 통해
축적된다. – 구글이 상당히 잘 찾아줍니다. 🙂 –

물론 오픈소스 소프트웨어에 대한 기술지원을 제공하는 회사들도 있다. 이는 어떤 보장을 원하는 대기업에 의해 파생된 부분이라고 볼
수 있는데, 대부분 해당 소프트웨어를 개발한 개발자들이 모여있는 회사에서 담당하는 경우가 많다. (일종의 부가사업?) 이때도,
일반적인 오픈소스 소프트웨어 사용자들의 지식이 농축되어있는 메일링 리스트나 게시판등을 효율적으로 활용할 수 있다.

대부분의 상용소프트웨어는 그 가격의 대부분이 기술지원비용이다. 돈 주고 사서쓰는 가장 큰 이유가 기술지원이기 때문이다. 하지만,
기술지원이 필요없을 정도의 인력이 존재한다면 굳이 기술지원을 받을 필요가 없다. 불필요한 비용이 발생하는 것이다.

회사라는 울타리를 넘어선 개발 – 기술지원의 분리와 협업은 분명 생산성 측면에서도 유리할 것이다.

ps. 다음편엔 사용자측면 – 결론.