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. 다음편엔 사용자측면 – 결론.

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

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

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

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

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

(2) 인력의 문제.

사회적으로 소프트웨어와 관련되어 들어가는 인력을 생각해본다면, 크게 제작/운영/유지에 들어가는 전문인력과 필요한 전문인력을 생산하는데 소모되는 비용을 들 수 있다.

전문인력이 실제로 자신의 능력을 효율적으로 사용하기 위해서는, 반복적인 작업을 줄여야 할 필요성이 강하게 대두된다. 이는
사회적으로 공유되는 공개된 코드의 양과 강한 연관관계를 갖고 있다. 동일한 문제를 놓고 이를 해결하기 위한 공개된 소스코드가
존재한다면, 이는 전문인력이 당면한 문제를 해결하기 위해 소모하는 시간/정신력이 급감한다는 이야기가 되기 때문이다.

그리고, (이것은 반 농담조로 이야기하는 것임;;) 전문인력이 필요한 소프트웨어를 사달라고 회사에 기안서를 내고 인가를 받는데까지 소모되는 시간 역시 줄일 수 있다. 필요하면 소스코드를 다운로드받아 쓰면 되기 때문이다. 🙂

전문인력을 생산하는데 소모되는 비용은 공개된 소스코드의 힘이 강렬하게 발휘되는 분야이다. 초보수준에서 보아야할 어떻게 코드를
작성하는가의 문제에서 부터, 고급개발자로 가기 위한 소프트웨어 아키텍트로서의 지식을 쌓기 위해서는 선배 개발자들이 어떤 고민을
갖고 어떤 코드/아키텍쳐를 만들었는지에 대한 공부가 필요하기 때문이다. 이 공부를 위해 필요한 것이 공개된 소스코드임은 말할
필요조차 없다.

물론 이 모든 것은 공개된 소스코드의 질과 관련되어 있다. 이 질은 상식적으로 볼 때, 공개된 소스코드의 손을 들어줄 수 밖에
없다. 상용과 다를 바 없는 (그리고 실제로 상업용 소프트웨어를 작성할때도 빈번히 사용되는) CVS나 SVN같은 훌륭한 코드
관리 도구에서 출발해서 (MS의 소스세이프에 비할바 아니다. -_-; Rational Rose의 Clear Case는 좀 다른거
같긴 하지만) 기타 제반사항에서 딸릴 것이 없다. 결정적으로 오픈소스 소프트웨어는 개발자를 장인으로 몰아간다. 상용으로 개발되는
소프트웨어는 릴리즈 날짜나 고객의 요구에 맞추어 모종의 "막개발"이 이루어질 수 밖에 없지만, 오픈소스 소프트웨어는 릴리즈
날짜나 고객의 요구에 조금 더 자유롭기 때문이다. 그리고, 회사의 이름으로 나가는 소프트웨어가 아닌 자기 자신의 이름이 더
중요하게 공개되는 소프트웨어란 점은 개발자에게 어떤 책임감을 부여한다.

"남이 읽기 쉬운 코드"라는 책임감을 말이다.

이런 토양을 통해 만들어지는 공개코드들은 (타인에게 귀감이 되지 못하는 코드가 많긴 하지만) 분명 전문인력과 관련된 문제를 해결하는데 있어서 막강한 힘을 발휘할 것이다.

5. 결론

오픈소스의 유지비용은 결코 상용소프트웨어에 비해 큰 것이 아니다. 물론 단기적인 안목에서는 상용소프트웨어가 편하고 저렴할 수
있겠지만, 좀 더 장기적인 안목을 갖고 넓게 본다면 오픈소스가 갖는 장점은 수 없이 많다. MS로 대표되는 독점(상용) 소프트웨어
진영에 의해 공격을 받고 있는 오픈소스는 많은 모함을 받고 저평가를 당하며 좀 더 나은 "컴퓨팅" 환경을 위해 "재미"로
살아가는 일종의 "전선"이다. 이러한 "전선이 승리할 것이냐의 여부는 중요하지 않다. "전선"이 존재한다는 사실 만으로 이미 오픈소스는 승리하고 있다.

지금도 원한다면, 언제라도 상용 소프트웨어에서 멀어질 수 있다. 거리낄 것 없이 공개된, 그리고 장기적으로 자신에게, 회사에게,
사회에게 도움이 되는 오픈소스 소프트웨어는 언제라도 문을 열고 있다. 언제라도 다가갈 수 있다. 남은 것은 의지의 문제이다.

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

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

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

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

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

4. 사회 입장의 유지비용.

앞부분에서는 기업, 사용자의 측면에서 볼 때 오픈소스가 가져다 줄 수 있는 유지비용의 감소를 알아보았다. 단순한 경제권에서 벗어나 사회전체로 볼때는 어떤 이익이 존재할 수 있는지 알아보기로 하자.

(1) 공공재 소프트웨어의 탄생.

"Write Once, Run Everywhere" 라는 문구가 있다.
Sun사에서 만든 Java라는 언어 혹은 플랫폼의 문구로, 한번 소프트웨어를 작성하면 어디서든(맥이든 WinTEL이든
Solaris등 기타 등등이든) 실행할 수 있게 하겠다는 야심찬 포부이지만, (적어도 클라이언트 쪽에선) 실패한 듯하다.

하지만, (비록 필자의 머릿속에서 나온 말이긴 하지만.)
"Write Once, Own Everywhere" 라는 문구는 현실성을 갖고 있으며, 실제로 구현되고 있다.

한번 작성하고 어디서든 소유한다. 소프트웨어가 가진 특성, 아니 모든 지적 재산(혹은 미디어에 담긴 무엇)이 가진 특성인
재생산비용이 실물 재화에 비해 매우 적다는 특성에 기반한 이 현상은 "공공재 소프트웨어" 라고 부를 수 있을 법한 자유
소프트웨어 혹은 오픈소스 소프트웨어(이하 오픈소스로 통일)로 나타난다.

오픈소스 소프트웨어의 가장 대표적인 상품 중 하나인 리눅스는 경쟁자라 불리는 마이크로소프트의 윈도우즈와는 다르게 오직 커널만을
지칭한다. 그리고, 이 커널을 이용한 실제 사용 가능한 시스템을 배포판이라고 부른다. 배포판들은 흔히 상용으로 개발되고
판매되는데, Red Hat이나 Suse Linux, 한컴리눅스같은 회사들이 대표적이다.

만약, 리눅스가 단지 커널에서 머물러 있었다면, 이런 이야기를 꺼내지도 않았을 것이다. 공공재라고 부를만한 배포판이 있기 때문이다. (그리고 익숙해진다면, 그 어떤 배포판보다도 편하다고 자부하는.)

바로 Debian GNU/Linux 이다. 이 운동(?)의 가장 큰 특징은 이들이
표방하는 Social Contact(우리의 약속)
있다. 공동체로의 환원, 소스코드의 유지를 기조로 하는 이 선언문은 소프트웨어가 공공재로써 어떤 역할을 할 수 있는지 가능성을
강하게 보여준다.

먼저, Debian GNU/Linux는 네트워크를 통한 소프트웨어의 설치(리눅스에서 구동 가능한 대부분의 오픈소스 소프트웨어들을
사용할 수 있다. 물론 "무료"로)를 기반으로 한다. 심지어는 네트워크를 통해 설치할 수 있기도 하다. 이러한 점은 "자본"이
들어간다는 것을 의미하는데, 이 "자본"의 충당을 많은 오픈소스 소프트웨어와 마찬가지로
기여로 해결을 한다. 기여(물적이든 자원봉사이든)를 하는 대부분의
개인 사용자나 회사는 Debian GNU/Linux의 철학에 찬성하거나 실제로 이 프로젝트를 통해 이익을 보는 경우가
대부분이다. 이는 공동체에 의한 소프트웨어 프로젝트의 유지를 의미하며, 그 자체로 하나의 사회를 이루고 있다.

사회 간접 자본이란 이름으로 공공재를 생각한다면 큰일이다. 우리가 접하는 공기나 물 역시 공공재이기 때문이다. 모두의 것이며,
모두가 아껴야 하고, 모두에 의해 관리되는 것을 공공재라고 본다면 Debian GNU/Linux는 최소한 그 사회 내에서는
공공재라고 부를 수 있을 것이다.

이러한 사례가 오직 Debian GNU/Linux에서만 보이는 것은 아니다.

FreeBSD, NetBSD, OpenBSD
같은 386BSD의 후손들의 프로젝트나 또다른 리눅스 배포판인 Gentoo Linux
같은 프로젝트에서도 이런 현상은 나타난다.

자본에서 벗어나, 조금씩의 기여와 자원봉사로 운영되는 이러한 운영체제(윈도우즈 같은) 프로젝트들은 소프트웨어가 공공재로써 어떻게 유지될 수 있는지를 잘 보여준다.

순수한 의미의 오픈소스 소프트웨어 프로젝트들은 기술에 대한 높은 이해도와 상당히 많은 참여도를 요구하는 반면, 운영체제
프로젝트들은 약간의 참여로 높은 효과를 볼 수 있는 것이 장점이다. 패키지 관리나 서버제공, 혹은 홍보활동등 상당히 많은
분야에서 다양한 사람들을 요구하기 때문이다.

한 회사에서 한 운영체제를 유지하는데 들어가는 비용을 생각한다면, 자연스럽게 유지되는 이러한 운영체제의 가치는 비할바가 아닐
것이다. 많은 비용을 들이고도 역사의 뒤안길로 사라진 NextSTEP이나 BeOS등의 운영체제를 생각한다면, 더욱 말이다.