사업 공정 관리(Business Process Management)는 IT 솔루션 카테고리 중 하나로 혹자는 workflow + EAI라고 BPM을 표현하기도 한다. 단순하게 설명해서, 기업의 업무를 프로세스화하여 표현하고 구현해놓으면, 직원들은 해당 프로세스를 따라 업무를 처리하면 되므로 자연스럽게 업무절차를 익힐 수 있고 실수도 방지된다. 각 업무들은 to-do list를 통해 관리가 되므로, 자기가 처리해야 할 업무가 무엇인지 놓치지 않게 되고, 다른 사람들과 함께 관련된 업무가 어떻게 흘러가고 있는지를 파악하기도 쉽다. 또한 업무 관리나 업무 혁신의 도구로도 쓰일 수 있다. 이런 일들은 workflow로도 가능한데, 여기에 EAI(Enterprise Application Interface) 개념이 결합됨으로써, 기존에 구현되어 있는 업무시스템 기능들이 하나의 프로세스로 묶이게 되어, 직원 입장에서는 각 업무를 어느 시스템에 들어가서 처리해야 하는지 등에 신경쓰지 않고 업무 흐름만 따라가며 수행하면 된다.
사업 공정 관리 - 위키백과, 우리 모두의 백과사전
http://ko.wikipedia.org/wiki/%EC%82%AC%EC%97%85_%EA%B3%B5%EC%A0%95_%EA%B4%80%EB%A6%AC
프로세스 관리
BPM은 프로세스관점에서 비즈니스와 IT전략의 개선에 초점을 맞춘 최초의 방법론 세트이다.
BPM은 비즈니스와 IT관리방법론으로 이뤄진 것으로, 비즈니스 전략과 IT 아키텍처 양쪽이 핵심적인 빌딩 블럭인 것으로 프로세스를 정의하고 있다. 이 스코프는 전략적이라고 할 수 있다.
비즈니스 전략 단계에서 그 목표는 전체 엔터프라이즈 기반의 프로세스를 발견하고, 이해하고, 최우선화시키고, 서로 연결시키는 것이며, 벤처캐피탈 조직이 그들의 투자 포트폴리오를 관리하는 방식처럼 능동적으로 이들 프로세스를 관리한다. 목적은 외적으로는 캐피탈 시장뿐만 아니라 고객들이 이해할 수 있도록 하여 이러한 조건하에, 내적으로는 BPM 중심의 기업들이 프로세스 기반의 경쟁력 있는 혜택을 통합시키는 것이다.
IT 아키텍처 관점에서 볼 때 BPM이란, 기업들이 하나 혹은 그 이상의 BPMS으로 관리되는 중심 프로세스 안에 어떤 프로세스를 조합시킬지(혹은 전환시킬지) 그리고, 애플리케이션 로직에 요약되는 IT 서비스 레이어에 어떠한 프로세스를 유지할 지 규명하는 것을 의미한다.
[출처] Workflow 대 BPM(Workflow versus BPM)|작성자 m
역동적인 조직 교차 프로세스
BPMS는 조직적(비즈니스단위와 부서) 경계와 IT 경계(기존시스템, CRM, ERP와 업무흐름시스템) 양쪽을 교차하는 시작부터 종료까지의 프로세스를 목표로 하며, 정기적으로 변화시킬 필요가 있다. BPMS는 IT 아키텍처의 프로세스 레이어를 강화시키는 것이다.
Pi미적분 대 Lambda 미적분
소프트웨어 제품보다는 비즈니스 프로세스별로 범주화시키는 것이 용이할 수 있다. 대부분의 업무흐름/BPM 제품들은:
- 다양한 배경을 가진다: 업무흐름 제품 출신, e프로세스 출신, EAI제품 출신
- 다양한 방식으로 패키지 된다: 애플리케이션 서버, 엔터프라이즈 비즈니스 애플리케이션, 콘텐츠 관리시스템, EAI 스위트의 컴포넌트로 패키지 된다.
- ‘내가 모든 것을 할 수 있다’로 마케팅된다: 어떤 제품이 어떤 프로세스에 가장 밀접한지 사용자가 규명할 수 있도록 지원하지 않는다.
그러나, 기능성 베이스에서보다는 설계 베이스로 업무흐름과 BPM제품간 차이를 구별할 수 있다.
이러한 설계의 차이는 Pi 미적분에 관련되는데, BPML(Business Process Management Language, 비즈니스 프로세스 관리언어, BPMI가 지원함)과
BPEL(IBM, Microsoft, SAP가 지원하는 마켓에서 보다 대중적으로 대체됨)같은 BPM 언어를 보강한다.
이 접근방식은 최종 사용자조직이, 업무흐름 시스템을 보강하는 전통적인 Lambda미적분/Petri Nets 기술보다는 보다 탄력적으로 프로세스를 정의할 수 있도록 해준다.
이런 기반에서, BPM 제품으로 최근 출시된 대다수 제품들이 실제적으로는 업무흐름 제품이라는 것이다.
- 서로 상호작용하는 프로세스 조각 조각처럼 프로세스를 정의함으로써 (반면 업무흐름은 일련의 과업으로 프로세스를 정의함)
- 과업간 전이가 이뤄지는 만큼 프로세스 참여자간의 수많은 메시지를 취급함으로써 (업무흐름에 관한 유일한 초점)
프로세스와 통합 이슈가 서로 관련되는 방식과, 프로세스가 사용되는 방식을, 단지 통합시킬 뿐만 아니라 강화시키며, 백엔드시스템을 업그레이드하는 것으로 재정의한다. 또한, 프로세스 실행시간을 정의하는 것에 최종사용자들이 관여할 수 있도록 하기 위하여, B2B 프로세스를 정의하는 것과, 잠재된 리소스로부터 프로세스를 추출해내는 것을 용이하게 한다.
Pi 미적분
http://en.wikipedia.org/wiki/Pi_calculus
Lambda 미적분
http://en.wikipedia.org/wiki/Lambda_calculus
프로세스 레벨 이슈로서의 통합
파이 미적분은 프로세스단계의 이슈 가운데 통합을 추가시킨다. 이와 같이, 프로세스 설계와, 프로세스와 통합 모두를 조절하는 모델링 환경이 필요하다. 이것은 보다 글로벌한 프로세스 부분처럼 각각의 프로세스간에 상호작용할 하위 프로세스를 사용하여 메시지를 정의하고자 하는 니즈에서 시작된다. 이들 메시지는 하위 프로세스가 따로 구분된 백엔드시스템를 대표할 때 좋은 매핑능력과 변형능력을 필요로 한다.
대부분의 업무흐름제품이 통합기능을 갖추고 있으나, 프로세스 설계 제품들과 연결되어 있지 않다. 이러한 케이스가 아닐지라도, 이들 제품은 여전히 단일 순차 흐름으로 프로세스를 정의하며, 프로세스 설계 단계에서 메시지를 통해 상호작용하는 하위 프로세스의 복합체로 프로세스 정의하는 능력과 탄력성을 통한 혜택을 얻지는 못한다.
통합뿐만 아니라 고객맞춤, 강화, 재사용 그리고 B2B 지원
BPMS는 사용자 조직을 통합시킬 뿐만 아니라 백엔드시스템을 확장 혹은 강화시킨다. 이들 조직의 프로세스 능력 중 일부를 취하여 이를 강화시킬 수 있도록 지원하게 된다. 개조하기가 쉽지 않거나 다음 버전으로 이동하기 쉽지 않은 내부 고객맞춤은 IT 아키텍처의 프로세스 레이어 안에서 관리되는 외부 프로세스와 확장을 통하여 대체된다.
패키지화된 비즈니스 애플리케이션으로부터 프로세스 요소를 구체화시키고, 그 외 애플리케이션까지 재사용하고 공유할 수 있도록 지원한다. 그러나, 전체 프로세스 바퀴를 재발명할 필요는 없는 것이다. 안정적이고, 로컬 프로세스들은, 비즈니스 애플리케이션과 기존 시스템과 업무흐름 제품에서 개선되어 IT 아키텍처의 IT 서비스 레이어 안에 안전하게 유지될 수 있다.
1990년대 후반에 ‘e비즈니스’ 개념이 등장하면서 ‘e프로세스/e업무흐름’ 신규기업 군단이 등장하였는데, 이들은 업무 흐름의 영역을 다양한 조직으로까지 확장시켰다. 현재는 전통적인 업무 흐름과 e프로세스가 다소 합병되었다. 그러나, 이들이 기술적인 관점에서 B2B를 지원하는 반면 (예를 들어, B2B 프로토콜을 지원함으로), 다른 종류의 비즈니스뿐 아니라 다른 종류의 비즈니스 단위를 엮는 프로세스 정의를 용의하게 하는 파이 미적분 접근을 통해 여전히 혜택을 얻지 못한다. 왜냐하면 동시에 한 프로세스의 사적 측면(하위 프로세스가 구분된)과 공적 측면(구분을 교차하는 메시지)을 명쾌하게 확인하고 연관시키기 때문에 그러하다.
백엔드 리소스로부터 추출
파이 미적분은, 단지 재사용뿐만 아니라 한편으로는 프로세스간에, 다른 한편으로는 이러한 프로세스로 상호작용하는 백엔드시스템과 사람간에, 더 상위 레벨의 추출을 가능케 하는 서비스지향 아키텍처(SOA)에서 요구되는 원리에 BPM이 더 근접할 수 있도록 한다.
업무흐름제품은, 일반적으로 양식 혹은 서류 (기본 프로세스 구조로 정의되는) 같은 구체적인 아이템이 한 사람에게서 다른 사람에게로 전달되는 형식의 구체적인 프로세스 흐름모델을 지원한다. 과업은 동일한 콘텐츠 리소스를 사용하는데, 이것은 이들 리소스가 프로세스 중에 과업을 통해 진전되는 것과 같이 상태를 변화시키게 되는 것이다.
BPM에서, 프로세스 내 과업은 정보리소스를 공유할 수 있으나, 그 프로세스 흐름이 그 정보리소스에 의존하는 것은 아니다. 이를 통해 통제 프로세스 흐름 모델을 유도할 수 있다. 따라서, 과업 수행에 대한 책임은 서류나 양식이기보다는 전수 되어지는 것이다. 이것은 BPM이 사용자를 고려하는 방식과 관련된다. 즉, 업무흐름이 비숙련자를 취급하는 반면 BPM은 사용자를 숙련된 전문가로 고려한다는 것이다.
업무흐름의 구체적인 흐름모델은 업무 흐름을 코디네이트하는 IT리소스 (ERP애플리케이션, 콘텐츠관리시스템, 데이타베이스)와의 밀착을 반영하는 것이다. BPM은 프로세스 운영에서 요구되는 백엔드시스템이 무엇이건 간에 IT리소스와는 다소 느슨하게 짝을 이룬다
백엔드시스템과 밀착된 까닭에, 업무흐름엔진은 이들 시스템에 트랜젝션 관리를 넘겨준다. 한편, BPMS는 그 프로세스 실행 엔진 속에, 이들을 구성하고 관리할 핵심 프로세스로 배치된 트랜젝션을 정의한다.
적극적인 최종 사용자가 중재하는 귀속적이고 역동적인 프로세스
업무흐름은 고정된 연쇄 프로세스 흐름모델에 고착된다. 업무흐름에서, 한 프로세스 내 모든 과업들은 단일한 최초 이벤트에서 시작된다. 소프트웨어에 사용된 리소스와 과업간 이전을 관장하는 규칙들은 설계시에 상세하게 규정된다. 파이미적분은 BPMS가 보다 이벤트 주도적이고 역동적인 프로세스 흐름모델을 지원할 수 있도록 한다. 여기서, 과업의 시작 종료되는 조건으로 매칭되거나, 혹은 적절한 조절 자에게 이벤트를 방송할 뿐만 아니라 자신의 전문기술을 갖춘 최종 사용자에 의해서 과업간의 전이로 귀속되고 결정된다.
업무흐름은 사람을 제일 먼저 생각하고 그 다음으로 백엔드시스템에 주안점을 맞춘다. BPM은 모든 프로세스 요소 (인간, 백엔드시스템, 하위 프로세스)을 동등한 레벨에 놓는다. 이것이 의미하는 것은, 엔드유저가 시스템과 상호작용할 수 있도록 지원하는 툴이 BPMS안에서보다 업무흐름 제품 내에서 훨씬 섬세하다는 것이다. 즉, 이것이 업무흐름 제품이 BPMS를 압도하는 유일한 내용이다.
수많은 업무흐름제품은 시스템 배송에서(‘이것을 수행하라’) 보다 유연한 시스템을 제안하는 모델 (‘이것 좀 해 보시겠습니까?’ ‘이것을 해볼 시간적 여유/기술을 가진 분은 누구입니까?’)로 이동하고 있으나, 이 방향으로 아직 충분히 진행된 것은 아니다. 그렇지만, 전체적으로, 최종 사용자 (상대적으로 비숙련자라고 기대하는)에게 무엇을 해야 하는지를 끊임없이 이야기하고 있으며 이를 위한 수단을 제공한다. 동일한 방법으로 매일매일의 고객을 다루는 데에 예외를 제거하기 위해 능동적으로 임한다.
설계단계에서 규명된 프로세스 프레임워크에 기초하여, BPM은 실행시간에 무엇을 해야 하며, 어떤 리소스를 사용해야 하며, 다음에는 어떤 과업이 진행되어야 할지 규명하는 최종 사용자의 전문기술에 좀더 의존할 것 같다. 이것은 예외를 취급하고, 개인의 특수 상황에 있는 고객과 맞부딪히게 되는 것을 의미한다 (최종 사용자는, BPM시스템이 그들에게 사용을 허용하는 리소스 기초만큼 그들의 전문기술 기초와 충돌할 것이다).
정보처리상호운영에서 이식가능성 표준
구체적인 프로세스 흐름모델과, 특정 백엔드 리소스와 관련된 밀착에 관해 업무흐름이 주력하는 것이 의미하는 것은, 새로운 환경에 재 설계함 없이 한 업무흐름제품의 프로세스에서 다른 제품으로 이동할 수 없다는 것이다. 즉 제품간 의사소통이 가능한 업무흐름제품을 갖기 위해 업무흐름제품벤더가 정보처리상호운영 표준에 초점을 맞추려는 지에 대한 이유이다.
BPM은 잠재된 IT 리소스로부터 프로세스를 추출해 낸다. 이것이 BPM 제품 벤더가 이식성 표준에 초점을 맞추는 까닭이다. 동일한 BPM언어가 지원된다면 제품간에 하나의 BPMS로 정의된 하나의 프로세스를 실행할 수 있게 된다(이론상이며 아직 실현되지 않음)
정보처리상호운영표준 대신에 이식성 표준에 대한 집중은(그러나 현재 아직 미성숙하다) 또 다른 결과를 낳는다. 업무흐름제품에서 설계와 실행 환경이 서로 의존적인 반면, BPM환경에서 이들은 서로 독립적이다). 동일한 BPM언어가 지원된다면 어떤 벤더의 설계 툴과 다른 벤더의 프로세스 엔진을 사용할 수 있을 것이다.
BPM 이식성 표준에 대한 초점은 프로세스 모델링 툴과 실행 엔진 (BPM 언어를 통해서)간의 이식성을 커버할 뿐 아니라, 프로세스 모델링 툴 (BPMN같은 표준을 통해서)간의 이식성 역시 커버한다.
번역된 언어 대 코드
최근 파이미적분은 BPML과 BPEL같은 프로세스 언어를 보강하고 있다. 이러한 언어는 아래와 같은 내용을 개발하는데 사용될 수 있다.
- 프로세스 모델: 프로세스를 모델화시키기 위해 요구되는 어휘와 문법 구조를 정의한다.
- 실행 가능한 프로세스: 사람과 백엔드시스템뿐만 아니라 프로세스간에 하나의 프로세스 모델을 형성하는 하위 프로세스를 연관시킬 구조를 제공한다. 실행되는 동안, 이러한 실행 가능한 프로세스들은 프로세스 엔진에 의해 이행된다.
BPML과 BPEL은 BPMS 프로세스 엔진의 핵심 요소인 버추얼 머신에서 구동되는 XML기반으로 번역된 언어이다.
이것은 업무흐름제품과 가장 뚜렷하게 구분되는 점으로써, 여기서 업무흐름 제품은 번역된 실행 모델이기보다는 애플리케이션 코드(예를 들면, 자바) 속으로 프로세스 모델을 전환시킨다는 것이다. BPMS프로세스에서 실행은 코드의 실행이 아닌 부분들의 커뮤니케이션을 통해 일어나는 반면, 프로세스는 변화되기 어려운 소프트웨어 코드 안에 내장된다. 개별 프로세스 사례는 ‘기민하게’ 채택, 조합, 쪼개진다. 이들은 띄어낼 필요도, 수정될 필요도, 실행환경에 다시 제안될 필요도 없다. 이것은 업무 흐름이 정적인 프로세스(IT아키텍처의 서비스 레이어 안에서)를 취급하는 반면 바로 왜 BPMS 접근이 역동적인 프로세스(IT아키텍처의 프로세스 레이어 안에서)를 다룰 수 있는지의 이유이다.
기술과 기능성 이슈들
스코프, 관련문제 그리고 설계 면에서 업무흐름의 수퍼세트 만큼이나 BPM은 차세대 업무 흐름은 아니다. 차세대 업무 흐름으로 잘못 정의 내리는 사람들은 단순히 기술과 기능성에만 초점을 둔다. 이러한 조망은 그림의 일부를 잃어버리는 것이다. 스코프, 관련문제 그리고 설계 이슈에 관해서 기술과 기능성에 비중을 두는 것은 잘못된 것이다.
기술
기술적 관심에서, 어떤 벤더는 BPM이 신 기술에 의존하는 반면 업무 흐름은 ‘구’ 기술에 근거한다고 정의하는데 이것은 업무흐름이 BPM보다 먼저 등장했기 때문에 자연스러운 것이다. 역시 이 또한 그리 관련성이 높은 것은 아닐 것이다. 실제로, 어떤 업무흐름제품은 C와 C++로 쓰여졌지 자바로 쓰여진 것이 아니며, J2EE 애플리케이션 서버의 모든 혜택을 취하지도 않았다. 그러나, 그러한 실행 환경이 설계된 작업에 달려있는 것인가?
관련된 기술에 보다 더 관련된 특징은 업무흐름제품이 산업 표준을 사용하는 방식과 연관되는데, 대부분의 웹서비스가 그러하다. 웹서비스는 웹서비스 인터페이스를 개발하였는데, 반면 보다 최근 BPM 제품은 인식의 웹서비스로부터 설계되었다. 이들은 외적(다른 시스템과 연결) 내적(BPM의 컴포넌트를 연결) 모두에 웹서비스 기술을 사용한다. 또한 콘텐츠 관리시스템에 연결되는 WebDav와 같이 다른 표준을 사용하려는 경향이 높다.
기능성
여러 해에 걸쳐, 업무흐름제품은 기능성의 폭과 깊이가 확장되어오고 있다. B2B, 통합 레벨, BI, BREs(비즈니스 규칙엔진), 협업 등 기타 영역에서도 마찬가지로 확장되어오고 있다.
실제로, 많은 벤더들은 BPM을 정의하기를, 업무흐름에 EAI, B2B, BRE, BI 기능성이 추가된 것이라 한다. 이 정의는 마케팅을 위해서 편리한 것일 수 있으나 너무나 단순화시킨 것이다. 왜냐하면 설계 이슈가 기능성보다 더 중요한 것일 뿐만 아니라, 기능성 이슈는 BPM이나 업무 흐름이 전반적으로 유사하게 관련되기 때문이다. 그림3은 업무 흐름과 BPM간의 기능성 차이를 보여준다.
비즈니스 인텔리전스(BI)
BI분야에서 업무흐름은 BPM제품과 더불어 아래와 같은 내용을 제공하기 위해 전력을 다하고 있다.
- 실시간으로 포괄적인 모니터링 데이터, 이는 인간 개입과 백엔드시스템뿐 아니라 프로세스 자체도 커버한다.
- 프로세스 모니터링 데이터에 기초하는 온더플라이(onthefly)프로세스를 변화시킬 능력
- 탑재된 프로세스를 변화시킬 필요를 최소하기 위해 탑재에 앞서 프로세스를 시뮬레이션하는 능력
마케팅 경쟁에도 불구하고 업무흐름, BPM 어느 것도 모두 세단계로 관리되지는 않는다.
BPM제품은 전략적 목표(비즈니스관리에서 그러하듯이 BPM은 비즈니스 실행관리에서와 같은 방식으로 BPM에 연관된다)에 맞서는 프로세스를 측정할 능력을 제공해야만 한다.
프로세스 대 비즈니스 규칙의 로직
유저조직들은 그들의 비즈니스규칙을 비즈니스 프로세스와는 별도로 이해하고, 서류화하고 관리할 필요가 있다. 비즈니스 프로세스 로직과는 별도로 비즈니스 규칙 로직을 유지해야 하는 것이다(프로세스를 정의하기 위해 사용된 동일한 환경 안에서 비즈니스 규칙을 정의하는 반면)
- 자동화된 프로세스: 한 프로세스에서 사람들에 의해 수행되어 사용되던 과업은 이제 비즈니스 규칙엔진에 의해 수행되어, 최상의 가치 과업에 집중하는 것에서부터 사람들을 해방시켰다.
- 탄력적인 프로세스: 비즈니스 규칙 엔진 사용은 프로세스를 더욱 다이나믹하게 만든다. 개발기간에 전체로 정의되는 대신에 규칙 번호에 기초하여 하나의 프로세스 상에서 어떤 과업이 그 다음에 일어나는지 유저들이 정의할 수 있도록 한다.
운 좋게도 업무 흐름과 BPM 제품 벤더 모두 이러한 필요를 알고 있으며, 자체적인 개발 혹은 OEM 개발이든지 프로세스에 비즈니스 규칙 엔진을 추가시키고 있다.
협업
업무 흐름과 BPM제품 모두 한 사람이 한번에 수행하는 것으로 과업으로 정의한다. 이들은, 작업은 팀 협업의 결과인 협업적 과업을 지원하지 않는다. 협업 툴을 통합하는 것은 업무 흐름과 BPM 벤더들에게 도전이 된다.
어느 제품도 모든 것을 하지는 않는다
이상적인 세계에서는, 엔드유저 조직이 아래와 같은 내용을 취급할 수 있도록 해주는 한가지 타입의 소프트웨어가 있을 수 있다:
- 전 프로세스 자동화 라이프사이클: 프로세스 발견, 사양, 설계 그리고 시뮬레이션; 프로세스 구성, 탑재와 실행; 프로세스 모니터링, 분석과 최적화, 프로세스 포트폴리오관리
- 프로세스 타입에 관련 없음: 여기에는 안정적이고 다양한 프로세스, 로컬 및 엔드투엔드 프로세스, 구체적이고 통제 흐름을 갖추었을 뿐만 아니라 시스템 배송과 제안을 하며 정적으로 연쇄되며 역동적으로 귀속되는 프로세스
어떠한 단일 제품도 이 모두를 수행할 수 없다. 유저는 이러한 작업을 수행할 수 있도록 다양한 업무흐름과 BPM 제품을 혼합하고 일치시킬 필요가 있으며, 이들 제품들이 서로간에 쉽게 통합되지 않는다는 사실을 극복해야 한다. 프로세스 포트폴리오관리와 같은 분야에서는 어떠한 제품도 이런 것을 만족시킬 수 없다.
전반적으로 유저는 중간 기간동안에 변화될 것 같지않은 별개의 과업을 자동화시킬 수 있도록 업무흐름제품을 선택해야 하고, IT시스템설계를 위해 SOA 접근의 일부로 여러 개의 하위레벨 프로세스를 코디네이트하는 전략적 접근을 위해 BPM으로 바꾸어야 한다.
Laurent Lachal
2005.01.25
[Ovum 제공]
원문 : http://www.swinsight.or.kr/newsList/newsView.php?newsID=2086&page=1&cateID=1000
BPM의 기본 개념에 관한 동영상
BPM의 개념1
http://uengine.org/web/guest/tutorial-videoBPM의 개념2
http://uengine.org/web/guest/tutorial-videoBPM의 개념3
http://uengine.org/web/guest/tutorial-videoBPM의 개념4
http://uengine.org/web/guest/tutorial-video
앞으로 공부해야 할 분야..
어렵다.
대학생활을 하면서 어렵다. 힘들다 했지만, 실무 전선은 그것 보다 더, 예상했던 것 던 것 보다 더 빨리 달리고 있다.
요새들어 느끼는 것은, 대학 교육이 너무나 과거의 지식에 머물러 있다는 것이다.
예전보다 더더욱 빠르게 신기술이 개발되고 발표되는 이 시점에서, 새로운 기술을 빨리 습득하고 응용할 수 있는 능력은
IT 세상에서 살아가는데 필수불가결한 사항이 되었다.
대학교육 또한 이러한 상황을 잘 반영하여 추진되어야 할 것이라는 생각이 든다.
'리뷰 > IT' 카테고리의 다른 글
| 아파치 미나(Apache Mina) (0) | 2010.08.20 |
|---|---|
| YouTube.com (0) | 2010.07.18 |