국내에서는 형상관리라고 불리우는 SCM(Software Configuration Management)에 관하여 정리하였습니다. 최근 이런 개념을 요하는 책을 접하고 있는 관계로 관련된 용어 정리를 나름대로 다시 할 필요성이 있어 정리하고 있습니다.

역시 가장 잘 정리되어 있다고 생각되는 Wikipedia에서 Software Configuration Management(SCM)에 관한 자료를 찾아보았습니다. 따라서 본 글의 내용은 Wikipedia 의 내용을 번역하고 더 필요한 내용을 정리한 것입니다. 참고하시기 바랍니다.


Software Configuration Management(SCM)

SCM은 Revision Control이나 Source control 및 Version Control과 같이 소프트웨어의 변경을 관리하고 작업을 추적하는 것이다. SCM은 버전관리(Revision Control)베이스라인 수립(establishment of baselines)를 포함하여 실행하는 것이다.

SCM은 Configuration Management (CM)의 한 부분이므로 우선 CM에 대하여 확인해볼 필요가 있다. CM은 국내에서 형상관리라고 불리우고 있다. CM는 시스템이나 제품의 성능과 기능 및 물리적 특성들을 요구사항(requirements), 설계(design), 기능적인 정보(operational information) 등과 함께 전 생애에서 지속적으로 관리하고 수립하는 것에 초점을 맞추고 있다. 관리 분야에서 제품의 성능이나 기능 및 물리적인 속성들을 요구사항, 설계, 운영 정보 등을 통하여 시스템의 일관성을 수립하고 유지하는 것이다.


특히 SCM은 "누군가 무슨 일을 하였다면, 어떻게 재현할 수 있을까?"에 대한 답을하기 위한 관점을 가지고 있다. 왜냐하면 수 많은 문제들은 결국 증가되는 변경을 제어하고 인식할 수 없기 때문에 해결하기가 어렵다고 보기 때문이다. 이러한 질문의 답은 결국 각 변경간의 차이점을 분석하여 결과를 비교하는 것이라고 볼 수 있다. 따라서 SCM은 복잡한 시스템이 개발되면서 발생하는 다양한 변경사항들을 처리할 수 있도록 구성되어 있다.

이에 따라 최근 형상관리를 넘어 SCM이 각광받고 있으며, 기존의 Revision Control 등과 구분된다.

대표적인 SCM의 개념을 지원 툴은 JIRA 등이 있지만, 보통 SCM은 다양한 툴을 종합하여 구현한다.

저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
최근 공개 소프트웨어 공모전에 참여하는 관계로 공개 소프트웨어에 대하여 많은 관심을 기울이고 있습니다. 이에따라 공개 소프트웨어란 무엇이고 공개 소프트웨어의 라이센스에 관하여 간략하게 정리하였습니다.

공개 소프트웨어에 대하여 간략한 이해를 하실 때 참고하시면 좋겠습니다.



전 세계적으로 공개 소프트웨어(Open Source Software)에 대한 관심과 활용이 높아지고 있으며, 이에 따라 많은 부분에서 적극적으로 공개 소프트웨어를 활용하여 경쟁력을 높이려는 노력을 기울이고 있습니다. 하지만, 공개소프트웨어는 무조건 무료라는 인식으로 인하여 공개 소프트웨어를 이용하여 개발한 소프트웨어가 공개 소프트웨어 라이선스와 충돌이 일어나는 경우가 많이 발생하고 있습니다.

이에 따라 공개소프트웨어를 바르게 이해하고, 각 공개 소프트웨어가 주로 채용하는 라이선스에 대하여 알기 쉽게 알려드리고자 합니다.




공개 소프트웨어와 비공개 소프트웨어(Close Source Software)의 가장 큰 차이는 소프트웨어를 구성하는 소스를 공개여부입니다.

더 정확하게 공개소프트웨어를 정의하면, 공개소프트웨어라 함은 라이선스 요금이 무료이면서 소스코드가 공개되어 있는 소프트웨어로서 누구나 자유롭게 사용할 수 있고, 활용할 수 있으며 배포할 수 있는 소프트웨어를 의미합니다.

그렇지만 공개소프트웨어가 공개된 소스코드에 대한 접근이 가능하다는 것만을 의미하는 것이 아닙니다. 이에 대해 대표적인 공개소프트웨어운동 비영리조직인 Open Source Initiative(OSI)는 특정 소프트웨어가 공개 소프트웨어로 분류되려면 다음과 같은 10여 개 조건을 충족해야만 한다고 정의하고 있습니다

  1. 자유로운 재 배포: 별도 라이선스 없이 프로그램의 배포 허용
  2. 소스코드 공개: 프로그램 배포 시 소스코드 배포
  3. 2차적 저작물 재 배포: 프로그램 원 저작물의 개작 및 배포 허용
  4. 소스코드 보전: 원 프로그램 보전을 위해 타인의 소스코드 수정 제한 가능. 단, 수정된 소프트웨어에 대한 재 배포는 허용
  5. 사용 대상 차별 금지: 모든 개인과 단체에 대해서 동일한 기준의 라이선스 적용
  6. 사용 분야 제한 금지: 특정한 용도에 대한 라이선스 사용 제한 금지
  7. 라이선스의 배포: 원작자의 승인 없이 프로그램 재 배포 가능
  8. 라이선스 적용상의 동일성 유지: 특정제품에 의존 금지
  9. 다른 라이선스의 포괄적 수용: 라이선스에 공개SW와 함께 배포되는 소프트웨어에 대한 제한을 설정해서는 안됨
  10. 라이선스의 기술적 중립성: 특정 기술 또는 인터페이스에 기초한 라이선스 규정 금지

공개 소프트웨어를 이해할 때 혼동되는 부분이 자유 소프트웨어(Free Software)와 공개 소프트웨어(Open Source Software)의 개념상의 차이입니다. 사실 두 용어는 근본적으로 같은 의미를 가지고 있습니다.


역사적으로 1984년 리차드 스톨만(Richard Stallman)이 GNU라는 공개프로젝트를 시작하면서 자유 소프트웨어 운동(Free Software Movement)이 시작되었습니다.

자유 소프트웨어 운동이라는 용어에서 "자유(Free)"라는 용어에 대한 오해의 소지로 인하여, 1998년 공개 소프트웨어(Open Source Software)라는 용어를 사용한 것이 공개 소프트웨어의 시작입니다. 즉, 자유 소프트웨어는 사용자에게 소프트웨어가 금전적으로 공짜(Free)라는 인식을 줄 수 있어, 보다 명확하게 의미를 나타내기 위하여 공개 소프트웨어라는 용어가 탄생하였습니다.

다만, 자유 소프트웨어라는 개념은 소프트웨어 자체는 항상 윤리적, 도덕적, 사회적으로 타당해야 하며, 소프트웨어 사용자들에게 이를 바탕으로 사용상의 여러 가지 권리가 주어져 있음을 강조합니다.

이를 정리하면 다음과 같습니다.

  • 공개 소프트웨어(Open Source Software): 소스코드를 공개하며, 소스코드를 일정한 라이선스에 따라 이용할 수 있는 공개된 소프트웨어를 나타내는 용어
  • 비공개 소프트웨어(Close Source Software): 소스코드를 공개하지 않으며, 프로그램을 실행할 수 있는 실행파일이나 실행환경만 제공하는 소프트웨어를 나타내는 용어
  • 자유 소프트웨어(Free Software): 공개 소프트웨어와 같은 의미이지만, 소프트웨어에 대한 책임과 사용자의 권리를 더욱 강조하는 용어

이 정리는 제 개인적인 생각을 바탕으로 간략하게 정리한 내용이라 약간 차이가 있을 수 있습니다. 의견 주시면 반영하겠습니다. :-)

공개 소프트웨어와 비공개 소프트웨어의 비교는 다음과 같이 비교될 수 있습니다.
 구분  비공개소프트웨어  공개소프트웨어
 비용분석  - 적용비용이 적음
 - 유지비용 및 시스템 개선비용이 높음(윈도우계열)
 - 소수의 관리자에 대한 관리비용 높음
 - 라이선스 수수료에 대한 비용발생
 - 적용비용이 낮음(무료)
 - 유지비용이 낮고 기능확장에 대한 추가비용이 들지 않음
 - 다수의 공개된 사용자에 의한 관리로 관리자에 대한 관리비용이 낮음.
 - 서비스에 대한 비용발생
 성능분석  - 규모가 큰 시스템 환경에서 비교적 높은 성능
 - 고가의 장비로 인한 고성능
 - 전체적으로 공개SW와 비슷한 성능
 - 규모가 작은 시스템환경에서 높은 성능
 - 높은 안정성 및 비용효율이 높음
 보안성  - 폐쇄적인 운영으로 인한 공개되지 않은 시스템 취약점 보유
 - 최근에 다수의 취약점 발견으로 많은 보안 위협에 노출
 - 프로토콜 호환이 어려워 인증체계가 취약함
 - 개발 시부터 공개되어 이미 많은 취약점이 해결된 안전화 상태
 - 공개키 기반의 인증 메커니즘 구현을 위한 통합패키지존재(적용이 용이)
 - 다양한 암호화 알고리즘 및 키 관리에 대한 기능 제공
 경제성  - TCO 높음
 - 구입비, 유지비가 높음
 - TCO낮음
 - 라이센스 비용없음
 기술성  - 재 사용성 없음  - 재 사용성 높음
 - 유지보수, 업그레이드 용이
 - 독점폐해방지
 저작권  - 일반 라이선스
 - 독과점에 의한 가격결정우려
 - GPL라이선스, BSD라이선스 등
 확장성  - 서버의 가용성 측면에서 클러스터링 비효율성
 - 소프트웨어간의 호환성이 보장되나 높은 적용비용과 제한된 시스템 운영환경
 - 효율적인 클러스터링 구현가능
 - 소프트웨어간의 호환성이 조금 떨어지나 적용비용이 거의 들지 않고 낮은 수준에서의 기능추가 가능
 경쟁력   - 소프트웨어선진국에 유리  - 공동개발상식에 따른 교육효과우수
 - 우리나라와 같은 후발국에 적합


사실 공개 소프트웨어를 사용하면서 가장 어려운 점이 각 라이선스 별 특징을 아는 일입니다. 어떤 라이선스를 사용하였는가에 따라 공개 소프트웨어의 이용 범위와 한계가 달라지기 때문입니다.

이러한 사항을 공개 소프트웨어에서 사용하는 대표적인 라이선스 별로 정리하면 다음과 같습니다.

 라이선스  배포의 자유  소스코드 공개 및 수정  2차 저작물 재 공개 의무  소스코드 수정 제한  사용대상 차별  사용분야 제한  무료 이용  독점적 SW와 결합
 GPL  허용  가능 공개
없음
없음
 없음  무료 불가능
 LGPL  허용  가능  공개  없음 없음
 없음 무료
 가능
 BSD  허용  가능  비공개 가능
 없음  없음  없음  무료  가능
 MPL  허용  가능  공개  없음  없음  없음  무료  가능
 일반적인 비공개 소프트웨어 라이선스  금지  불가능  2차 저작 금지 또는 협약하에 저작
 있음  있음  있음  유료  불가능


상기 표의 내용을 간략하게 설명하면 다음과 같습니다.

GPL(General Public License)는 대표적인 공개 소프트웨어 라이선스로서 Linux, MySQL, GCC 등에 널리 적용되고 있는 라이선스로서, 독적점인 소프트웨어와 결합이 불가능한 특징을 가지고 있습니다. GPL 라이선스를 적용한 공개 소프트웨어를 이용한 소프트웨어를 만들었다면, GPL 라이선스에 따라 해당 소프트웨어의 소스코드를 공개하여야 할 의무가 있습니다. 이러한 점이 GPL 라이선스를 이용한 개작 소프트웨어를 상업적으로 이용하려는 기업이나 단체에 걸림돌로 작용하고 있습니다. 다만 이러한 특징은 앞에서 설명한 자유 소프트웨어의 사상을 반영하였기 때문입니다.

이러한 제한을 약하게 적용시킨 것이 바로 LGPL(Lesser General Public License)입니다. GPL의 개작 소스코드 의무 공개 및 재배포 규정을 완화하여 사용기업에서 활발하게 이용이 가능하도록 만든 라이선스입니다.

BSD(Berkeley Software Distribution) 라이선스는 소스코드의 개작 이후 재 공개를 개작자의 판단에 맡기는 라이선스입니다. 이에 따라 다른 라이선스와 달리 2차 저작물의 소스코드를 공개하지 않아도 됩니다.

MPL(Mozilla Public License)의 경우 개작 시 소스코드를 공개할 의무는 있지만, 상업적으로 이용이 가능한 특징이 있습니다.

이상으로 간단하게 공개 소프트웨어와 비공개 소프트웨어의 주요 특징을 살펴보고 공개 소프트웨어에서 사용하는 라이선스에 대하여 알아 보았습니다. 공개 소프트웨어의 활용은 경쟁력을 높이는데 많은 도움을 주지만, 그 만큼의 책임이 있음을 알고, 필요에 맞게 활용하시는 것이 중요합니다.

감사합니다.
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  8개가 달렸습니다.
  1. 음, 오픈소스에 대한 글 잘 읽고 갑니다.

    복잡한 내용을 참 알기 쉽게 잘 정리를 하셨네요.
  2. 안녕하세요, 오랜만에 글을 올립니다.
    역시 깔끔한 정리와 핵심을 짚어 주셨네요. 감사합니다.
    참고로 Android의 경우 GPL과 BSD가 혼용되어 있습니다.
    예를 들어 S나 L같은 제조사가 Android 제품에 포함되는 device driver에 대한 개발 소스를
    공개하기 꺼려진다면 BSD로 하면 됩니다. (국내 사업자 특성 상 대부분이 BSD로 할 것 같아요 ^^)
    여러 license 체계로 인해 오해도 많지만 그만큼 다양하고 오랜 역사를 반증하는 것 같습니다.
    좋은 글 감사합니다~
  3. 체계적으로 잘 정리해 주셨네요. 매우 유용한 자료네요.

    여튼 공모전 좋은 결과 있으시길 바라겠습니다. !! 홧팅!!
  4. 멋지게 정리하셨네요. 잘 읽었습니다. ^^
  5. 안녕하세요.
    선진님 블로그 종종 들르는데 한 번도 인사 못드렸네요.
    알기 쉽게 정리해 주셔서 감사합니다. ^^
  6. 형님, 공개 소프트웨어에 대한 좋은 정리 감사합니다.

    하는 일도 많으신데 언제 또 이런 좋은 글을 정리 하셨는지 정말 대단하십니다.

    라이선스 정책에 대해서 좀 더 고민해 봐야겠네요 ... 어렵습니다.
  7. 공개 소프트웨어에 대한 정리 너무 좋네요.
    제가 기획하고 있는 기부웨어 공익 단체 제안서에서 참고 하고자 합니다.
    괜찮을런지요.
    참고로 기획안을 메일로 보내드렸습니다.
  8. 표좀 퍼가겠습니다! 출처 밝히겠습니다~감사합니다^^
secret
최근 좋은 책 하나를 번역하고 있습니다. 이 책의 내용중에 Big Visible Charts라는 내용이 나옵니다.

Big Visible Charts는 http://www.xprogramming.com/으로 유명하신 Ron Jeffries님의 글인 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm에 자세하게 설명이 나옵니다.


우선 이해를 돕기 위해서 Big Visual Charts에 대하여 간략하게 요약하면 다음과 같습니다.

사람들이 알아야 할 것들(People Need to Know)

XP의 가치중에 하나가 의사소통(Communication)입니다.
팀간에 의사소통을 하는 여러가지 방법이 있습니다. 가장 일반적인 방법이 대화이지만, 기록이 필요하거나 민감한 주제이거나 트렌드가 변경되는 경우 XP에서는 "큰 시각화 차트(Big Visible Charts)"라고 부르는 것을 이용하는 것을 좋은 접근방법입니다.

간단한 차트를 벽에 붙여 놓음으로써 팀 전체가 주목하게 되어 정치적으로 민감한 정보까지 쉽게 전달할 수 있습니다.

벽에(On the Wall)

차트는 웹 사이트나 예쁘장한 슬라이드 쇼보다 많은 경우 벽위에 있는게 효과적입니다. 차트가 벽에 있으면 눈길이 벽에 머물며, 가까이에서 쉽게 바라보고 인식할 수 있기 때문입니다.

간편한게 더 좋다(Casula is Better)

차트를 그릴때 엑셀이나 비지오 등의 수 많은 전문적인 프로그램을 이용하는 것은 약간 재미있을 수 있지만, 대부분 자동화해줌에도 불구하고 전문적인 차트들은 작성하는데 많은 시간을 소비하게 됩니다.

따라서 더욱 간편한 대안을 찾아야 합니다.
포스트잇을 가지고 쉽게 붙이고, 굵은 펜으로 간단하게 그리면 매일 갱신하는 시간을 줄일 수 있습니다.
그냥 손으로 그리면 간편하여 더 좋습니다.

어떤 차트를 사용해야만 하는가?(What Should We Chart?)

차트는 여러분이 무었인가 관리하고 걱정하고, 다른 사람들이 알아야하는 것들을 나타내야합니다. 대부분 모든 XP 사례들은 차트를 위한 자료들을 제공합니다. 문제, 근본적으로 재발하는 것들 들이 가치있는 차트입니다.

명심해야 할 것은 스토리 구현(stories implemented)과 같이 차트가 좋은 역활을 하려면 결함들을 고쳐야합니다. 또는 상사가 언제 마지막으로 피자나 도넛을 사왔는지와 같은 나쁜 것들도 고쳐야 합니다. :-)


이상 간략한 요약이었습니다. Ron Jeffries님이 제시한 차트의 종류는 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm 에서 확인하실 수 있습니다.

그냥~ 큰 백지위에 잘 그리면 될듯 합니다. 자알요~ ;-)



사실 저의 근본적인 고민은 The "Big Visual Charts"를 정말 "큰 시각화 차트"로 번역을 할 것인가? 였습니다.
뭔가 어색하시지 않습니까?

그래서 XP 책을 번역하셨던 유명하신 박현철 아키텍트님께 질문을 드렸습니다. 과연 Big Visual Charts를 어떻게 번역하는것이 좋을지에 관해서요~



역시 좋은 해결책을 주셨는데~ 바로 간판이었습니다.

Kenji Hiranabe님이 InfoQ에 올리신 "간판을 이용하여 Agile 프로젝트를 시각화하기(Visualizing Agile Projects using Kanban Boards)" 이었습니다. 원문은 http://www.infoq.com/articles/agile-kanban-boards에서 보실 수 있습니다.

일본 도요타 자동차에서 사용하는 Lean 시스템 역시 Agile 프로젝트와 같이 Big Visual Charts와 같은 것을 사용하여 프로젝트의 상태를 시작화한다는 내용이었습니다.

Kanban Boards와 Big Visual Charts는 의미상이나 목적상에서 같은 것이라는 점입니다.
물론 약간씩은 차이가 있지만 프로젝트의 진행상태를 나타낸다는 점에서는 같으며, Big Visual Charts가 더 자유분방하고 Agile적인 요소를 기반으로 시각화를 한다면, Kanban Boards는 도요타에서 일정 수준의 체계화한 것들을 바탕으로 시각화를 하여 더 구체적이고 명확한 관점이나 요소나 항목을 가진다는 점이 다릅니다.

작업현황판(Task Kanban Board)의 경우 할일(To Do), 진행하는 일(Doing), 마친 일(Done)으로 구분되어 있습니다.

시각화를 위하여 이 글에서는 간판(Kangan Boards)와 Burndown Charts와 Parking lot Chart 및 달력(Calendar)를 사용하고 있습니다.
정리하면 하면 다음과 같습니다.

http://www.infoq.com/articles/agile-kanban-boards



그래서 결론은 The Big Visual Chart를 간판이라고 번역하기로 결정했습니다.
그래도 약간 어색하긴 합니다면, 큰 시각화 차트보다는 명확하게 다가올것 같습니다.

혹시 더 좋은 의견 있으시면~ 댓글 많이 많이 부탁드립니다. :-)
감사합니다.
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  6개가 달렸습니다.
  1. 간판이라고 하면 왠지 실내에 부착하는 것보다 옥외간판을 먼저 떠올리게 되서..
    딱 다가오지가 않네요.
    설명해주신 내용을 보고 머리에 떠오른 단어는 포스터 였습니다.
    광고나 선전을 위한 매개체라는 의미에서 괜찮은것 같은데..
    우리말로는 뭐라 표현할지는 역시 애매하네요. ^^
  2. 말씀하신 간판,Kanban과 차트를 같이 쓰는것은 약간 어색한거 같습니다. 차라리 풀어쓰시거나 과감히 생략하시는게..예를 들어 큰 도표나 크게 잘 보이는 도표 등등..용어 번역은 항상 어려운거 같습니다.
  3. 의견을 공개하시니, 방문하셔서 피드백을 주시네요.

    이렇게 함으로써, 더 나은 글이 만들어 지다니. 역시 문제나 생각은 공유해야 다듬어 지는가 봅니다.
    여튼 짧은 시간동안 고생 많으셨어요, 선진님 힘내세요 홧팅!!
  4. 실천가를 위한 실용주의 프로젝트 관리에 보니 BVC를 크고 눈에 띄는 차트로 번역하셨네요. 참고하세요.
  5. 구글에서 검색하다 보니 옛날 글에 오게 됐네요. Kanban과 BVC는 구분돼서 사용되고 있습니다. 간판을 사용하는 순간, 독자들이 Lean으로 오해할 위험이 있다고 생각합니다. 대부분의 간판(kanban)은 거대하지 않고, 카드 등으로 처리하기 때문에 혼란을 가중할 수 있다고 보구요.
    • 영어 약자란 게 조금 아쉽지만, 역주만 충실히 달면 괜찮을 것 같아요.
secret
지난 금요일 KT DigiEco 후원의 SW 공학 스터디 포럼인 "미래의 소프트웨어공학 기술 연구회" 에서 4월 정기세미나가 열렸습니다.
주제는 "IT 시장의 태풍 SaaS"이었습니다.

제가 평소 SaaS(Software as a Service)에 많은 관심을 가지고 있었는데 미래의 소프트웨어공학 기술 연구회에서 저를 초대하여 주셔서 "소프트웨어와 서비스(Software and Service)"란 주제로 발표를 하였습니다.

발표 내용을 함께 나누고자 이렇게 글을 올립니다.

참고로 미래의 소프트웨어공학 기술 연구회가 역사는 오래되지 않았지만, 여러모로 의미있는 주제를 가지고 많은 세미나를 기획하고 있습니다. 처음 초대받아 간 자리지만, 내공이 탄탄한 좋은 분들을 많이 만나뵐 수 있어서 참 좋았습니다. 여러모로 뜻깊은 모임이기에 미래의 소프트웨어공학 기술 연구회에 회원으로 활동하기로 하였습니다. 따라서 잠깐의 홍보를 드립니다. :-)

그리고 혹시 저의 생각을 나눌 수 있는 자리가 있다면, 언제든지 연락하여 주시기 바랍니다. 부족하지만, 제가 가진 생각들을 함께 나누겠습니다. 저의 이메일 주소는 본 블로그 하단에 이미지로 있습니다. 감사합니다. :-)

제 발표 내용을 보시면서 여러모로 부족한 부분이 있을 수 있지만, "SaaS라는 애매모호한 IT 패러다임을 사용자 관점에서 어떻게 받아들어야 하는가?"에 대한 저의 생각이 담겨져 있는 발표자료입니다.

제가 말로 다 표현하지 못한 내용들을 아래에 정리하였습니다. 따라서 보시면서 천천히 요약자료를 보시면 한결 쉽게 이해되실 것 같습니다.
발표 내용은 다음과 같습니다. 약 30분정도의 발표 내용입니다. 그리 무겁지 않은 내용이기 때문에 쉽게 이해되실거라고 생각합니다.



본 발표 내용을 요약한 내용은 다음과 같습니다.

SaaS(Software as a Service)는 사용자와 공급자에게 모두 가치있는 소프트웨어 패러다임입니다.

SaaS에서 가장 중요하게 부각되었던 점은 공급자적인 가치였습니다. 특히 하나의 소프트웨어(Software based Service)를 여러 사용자(Tenant)에게 쓸 수 있는 패러다임이라고 인식되고 있습니다.

하지만, SaaS에서 가장 중요한 요소는 사용자(Tenant and User) 입니다.

따라서 현 상황에 맞는 가장 중요한 사용자적인 가치가 무었인가에 대하여 확인할 필요가 있다고 생각합니다. 이에따라 IT에서 사용자적인 가치를 가장 높였다고 말하는 Web 2.0에 대하여 생각해 보았습니다.

일반적으로 Web 2.0을 참여와 공유를 지원하는 새로운 인터넷 환경으로 인식하는 경우가 많습니다. 그렇다면 Web 2.0 이전의 세대를 Web 1.0이라고 보았을 때 Web 1.0에서는 참여와 공유가 없었을까요?

제 생각에는 Web 1.0시대에서도 참여와 공유는 계속 있어왔습니다. 그 방식이 다를 뿐이지 언제나 인터넷 환경은 참여와 공유로 이루어져 있었습니다.

따라서 Web 2.0에서 말하는 참여와 공유는 그다지 Web 2.0을 설명하는 중요한 차이점이 아닌것 같습니다. Web 2.0의 여러가지 구성 요소를 살펴보면서 저는 Web 2.0과 Web 1.0의 차이를 신뢰의 차이라고 생각하였습니다.

특히 사용자가 다른 사용자를 신뢰하는 영역이 넓어졌으며, 이러한 신뢰를 바탕으로 많은 변화가 일어나고 있다고 생각합니다. 대표적으로 Wikipedia와 Blog입니다. 알지 못하는 우리가 우리를 신뢰하지 못한다면 Wikipedia는 존재할 수 없습니다.

Wikipedia라는 사이트의 시스템이 중요한것 보다 우리가 우리를 신뢰하는 신뢰성이 증대되었기 때문에 Wikipedia가 가치있어 졌다는 것입니다. 마찬가지로 Blog도 Blog의 저자를 Blog의 독자가 신뢰하였기 때문에 Blog란 생각보다 아주 단순한 시스템이 현재 새로운 가치를 만들어 내고 있는 것입니다.

따라서 저는 현재 가장 사용자에게 가치있는 부분은 신뢰라고 생각하며, 사용자가 소프트웨어를 신뢰할 수 있는 기반이 마련되었다고 생각합니다.

즉 이러한 사용자간의 신뢰성이 확장되면서 새로운 소프트웨어 시스템들이 사용자에게 널리 사용되기 시작한 것입니다.
이러한 새로운 소프트웨어 시스템의 예가 Blog입니다. Blog는 1994년 미국의 펜실베니아 스와스모어 단과대학생 저스틴 홀이 처음 시작하였다고 말합니다. 이미 15년 전에 Blog란 소프트웨어 시스템은 존재하였습니다.

하지만 지금에 와서 Blog가 각광받고 있는 이유는 무었입니까?
제 생각에는 이전에는 Blog의 저자가 만들어내는 정보를 신뢰하지 못하였기 때문입니다. Blog의 정보를 신뢰하지 못하였기 때문에 Blog의 정보를 사람들이 참고하지 않았습니다.

지금은 많은 사용자들의 Blog의 저자의 글들을 신뢰합니다. 어찌보면 누가 쓴 글인지도 정확히 모르는 이러한 정보들을 신뢰하기 시작한다는 것입니다.

이러한 예는 무수히 많습니다.
이 모두 근간에는 신뢰라는 것이 있기 때문에 발전한 것들입니다.

따라서 저는 Web 2.0의 가장 중요한 가치를 신뢰라고 생각합니다.

이러한 흐름을 볼 때 사용자들이 다른 사용자들을, 즉 우리가 우리를 신뢰할 수 있는 가장 큰 원동력이 무었일까 고민해 보았습니다.
그 가장 큰 동기는 바로 Prosumer의 탄생입니다.

이미 1980년에 앨빈 토플러에 의하여 예측된 Prosumer는 일정 수준의 전문성을 갖춘 생산자이면서 소비자입니다. 일반적인 공급자들보다 더 좋은 생산을 해 낼 수 있는 전문적인 사람들이 탄생한 것입니다.

물론 Prosumer들은 항상 존재하였지만, 최근 Prosumer들은 대폭 늘어나고 있습니다. 특정 부분에 전문가적인 지식을 바탕으로 새로운 지식을 창조하고, 이를 나누고, 다른 정보들을 소비하는 Prosumer들을 우리는 많이 볼 수 있습니다.

대표적으로 Blog의 저자들인데요, 저 역시 Prosumer라고 볼 수 있습니다.
이러한 Prosumer들은 정보의 질을 한층 신뢰할 수 있도록 만들었습니다. 따라서 우리는 대학 교수들이나 전문 의사만이 가질 수 있었던 지식의 신뢰성을 나누어 가지게 되었습니다. 이러한 신뢰성은 계속 증대되어 우리가 우리를 신뢰할 수 있는 단계에 와 있습니다.

많은 공급자들인 이렇게 강화되는 Prosumer들의 의견을 적극 수용하기 위하여 흔히 이야기하는 얼리어답터에게 제품 출시전에 미리 제품을 공급하여 반응을 살피기도 합니다. 얼리어답터역시 Prosumer이고, 이들의 조언은 전문가적인 수준이기 때문에 가능한 것입니다.

이러한 변화는 소프트웨어 분야에도 많은 변화를 일으키고 있습니다.
예전에는 무지막지한 블루 스크린을 무작정 사용자에게 던지던 소프트웨어들이 사용자에게 어느 순간부터 신뢰를 주기 시작합니다.

점점 블루스크린을 보는 기회가 줄어들고 있으며, Google의 Gmail과 같이 Beta 버전이지만, 사용자에게 많은 효용과 신뢰를 주는 소프트웨어들이 생겨나기 시작하고 있습니다.

이러한 이면을 보면 소프트웨어를 사용자들이 점점 신뢰하기 시작하고 있다는 것을 알 수 있습니다. 사용자의 개인 정보들을 가장 많이 담고 있는 E-Mail을 아무런 꺼리낌없이 Gmail이란 E-Mail 시스템에 맡기고 있습니다.

Google이 만약 신뢰할 수 없는 곳이라면 사람들인 Gmail의 기능이 아무리 뛰어나더라도 사용하지 않을 것입니다. 왜냐하면 나의 가장 소중한 개인정보들은 신뢰할 수 없는 곳에 노출하기를 원하지 않을 것이기 때문입니다.

따라서 Google의 Gmail이 여러분들에게 주는 가장 큰 가치는 바로 소프트웨어에 대한 신뢰인 것입니다.

여러분들은 어느 순간부터 블루스크린과 에러만 뱃어내던 소프트웨어를 신뢰하기 시작하고 있습니다. 무수한 버그 투성이로 얼룩져있던 소프트웨어를 신뢰하고, Web Application이건 Stand-Alone Application이건 신뢰하기 시작하고 있습니다.

특히 Web Application에 대한 신뢰가 증대되고 있습니다. 패키지 소프트웨어의 경우 기존에 컴퓨터에 설치하여야만 그 기능이 업그레이드 되었지만, 지금은 어느 순간 동일한 기능을 제공하면서도 새로운 신뢰할 수 있는 기능을 제공하고 있기 때문입니다.

그래서 요사이에 Web Application에 대한 신뢰가 더 커지고 있는 것입니다.
이를 SaaS 관점에서 바라본다면, 사용자에게 더욱 유용한 소프트웨어를 제공하는 기술 중에 Web Application을 구축하여 제공하는 것이 더욱 좋은 방법이다라는 관점이 생길 수 있습니다. 왜냐하면 여러가지 Web Application의 장점을 사용자들이 신뢰하고 있기 때문입니다.

따라서 많은 SaaS의 정의를 보면 Web 기반으로 소프트웨어를 제공하는 기술이라고 바라봅니다.

하지만 꼭 소프트웨어가 웹 기반으로 제공되어야만 사용자에게 신뢰를 줄 수 있는 것은 아닙니다.
패키지 소프트웨어도 신뢰를 줄 수 있으며, 콘솔 게임 소프트웨어도 사용자에게 신뢰를 줄 수 있습니다. 가족 모두 모여서 즐거운 게임을 즐길 수 있다라는 새로운 가치와 신뢰를 만들어준 Nintendo Wii가 그러한 예입니다.


이러한 변화를 한번 종합하여 생각해볼 필요가 있습니다.
사용자들은 사용자간에 서로 신뢰하기 시작하였으며, 소프트웨어 역시 신뢰하기 시작하고 있습니다. 특히 소프트웨어는 이러한 신뢰를 높여줄 수 있는 기능을 제공하고 있으며, 더욱 신뢰를 높일 수 있는 기능이 필요로 합니다. 이러한 변화는 Prosumer에 의하여 더욱 가속화되고 있으며, Prosumer들은 이러한 변화에 더욱 유연하게 적응하고 있으며, 이러한 변화를 이끌고 있습니다.

이러한 변화의 시대에 맞는 소프트웨어가 필요하다는 공통의 인식이 있으며, 이렇게 사용자에게 신뢰할 수 있는 소프트웨어를 제공할 수 있다는 소프트웨어 패러다임이 생겨났습니다. 이러한 패러다임을 총칭하여 SaaS라고 불리운다고 생각합니다.

따라서 우리는 SaaS를 너무 공급자적인 관점에서 바라보지 말고 사용자적인 가치를 찾을 필요가 있습니다.
SaaS의 기존의 공급자적인 관점을 넘어서 사용자적인 정의를 저는 다음과 같이 내렸습니다.

사용자 관점에서 SaaS란 소프트웨어를 바탕으로 사용자에게 신뢰할 수 있는 서비스를 제공하는 활동이라고 생각합니다.
즉 사용자에 있어 SaaS의 기술이나 각 요소들이 중요한것이라기 보다 이제 소프트웨어를 신뢰할 수 있으며, 마치 서비스처럼 신뢰할 수 있다는 것이 중요한 변화입니다.

사용자에게 가치있는 신뢰를 제공하려면 이를 종합적으로 제공할 수 있는 플랫폼이 필요합니다.
그 플랫폼을 Service Platform이라고 생각하며, Service Platform은 다음과 같은 구성요소를 가질 수 있습니다.
Service Platform

Service Platform



여러가지 공급자적인 가치와 함께 살펴본다면 더욱 이해가 높아질 수 있지만, 이러한 변화의 중심에는 사용자들의 신뢰가 높아지고 있으며, 신뢰의 가운데 소프트웨어가 함께 한다는 것이 중요한 의미라고 생각합니다.

마지막으로 헨리포드가 가장 혁신적인 방식으로 싸게 수 많은 자동차를 만들어 냈지만, 정작 사용자에게 외면을 받은 것은 공급자가 너무 사용자에게 원하는 것을 제공하지 못하였기 때문입니다. 즉 사용자가 받고 싶은 서비스들을 이해하지 못하고, 공급자, 헨리포드 자신이 원하는 자동차를 소비자에게 강요하였기 때문에 결국 크라이슬러에게 밀리고 말았던 것입니다.

사용자는 좋은 서비스를 받고 싶어하며, 그리고 제공하는 많은 것들을 신뢰하려고 하는데, 이러한 사용자들의 요청을 묵살한다면 아무리 좋은 기술과 새로운 방식으로 소프트웨어를 만든다고 하더라도 헨리포트의 T 자동차처럼 결국 사용자의 외면을 받을 것이라고 생각합니다.

이상입니다.

휴~ 정리가 쉽지 않았습니다. :-) 물론 이전에 원고를 써 놓긴 하였는데요~ 약간 수정하였습니다.
여러분들에게 조금이나마 새로운 시각을 제공하는 발표자료였기를 기대합니다.

혹시 궁금한 점이나 부족한 점이 있다면 댓글 부탁드립니다.
감사합니다. ;-)

저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  4개가 달렸습니다.
  1. 좋은 강의 고맙습니다.
    서비스는 벤더에 종속되지 말고 사용자관점으로 되어야 함과 신뢰가 밑바탕 되어야 하고 이런 신뢰가 어느정도 바탕이되어 많은 서비스가 되어야 한다.는 관점이 좋고 공감합니다.^^


    읽고 들으면서 조금 의문이 되는 부분이 있었습니다.
    일단 서비스를 제공하는데 신뢰가 가장 중요한 부분이라는 점입니다.
    하지만 지금 신뢰성 있는 서비스여서 사람들이 사용하는 것 보다는
    선택맹에 빠져 안전 불감증에 사용하고 있지 않나 생각해 봅니다.

    얼마전 카메라 렌즈를 중고시장에 팔고있는데... 동생이 깜짝놀랠 정보를 알려줬습니다.
    렌즈 구매하려는 사람의 ID를 가지고(일반적으로 다른곳에서도 같은 아이디를 사용하기에) 구글등 검색엔진에서 검색해서 그사람의 이름과 전화번호... 심지어 그 사람의 와이프가 의료사고를 당해서 의료소송을 걸고있다는 사실까지 알아내더군요...ㅡㅡ;;;
    기능을 보고 아무생각없이 서비스에 가입하고 ActiveX 설치 동의를 하는것이 일반적 사용자가 아닌가 합니다. (물론 프로슈머는 다르겠죠.)
    신뢰할 수 있는 서비스인지의 여부는 현재 SaaS가 아직 많이 활성화 되지 않고 제공되는 정보가 지엽적이여서 문제시 되고 있지 않을 뿐이라는 생각이 듭니다.
    하지만 어느순간 프로슈머들의 활동으로 인해 신뢰성 낮은 서비스는 공격을 받겠고 자연히 신뢰가 그 서비스의 성패를 좌우하게 되겠네요. (결국 장책임님과 의견을 같이하네요.^^)

    이런 신뢰성은 결국 말씀하신대로 Service Platform으로 보장받을 수 있을 것 같은데 이 플렛폼은 얼핏보기에 벤더가 제공하는 프레임워크와 비슷한 역할을 한다는 생각을 해봅니다.
    사용자가 원하는 서비스를 제공하는데 벤더의 프레임워크가 제약이 된다거나 너무 크다는 면에서 밴더 독립적인 플랫폼이 되어야 한다고 말씀하시는것으로 이해했는데 그렇다면 이 플랫폼의 주체는 어디가 될지 궁금합니다. (각 프로젝트?,각 회사?,-벤더- ,아님 표준스펙?, 방법론??)
    벤더보다 작은단위가 되었을 때 신뢰성을 어떻게 보장받을 수 있는지 (아무리 프로슈머라도 비기능 요소를 보기는 힘들지 않나 생각합니다.)
    그럼 서비스 위에 서비스가 2중 3중으로 올라가게 될 서비스는 큰 거품위에 있게되고 어느순간 다같이 무너지게 될 수도 있지 않나 생각해 봅니다.
    ex) 기본되는 서비스의 보안문제 or 서비스 중단문제
    (각 회사나, 팀에 속한 플랫폼이 신뢰하지 못한다는 것이 아니라 누구도 확신 할수 없다는것이죠..)




    ps 동영상이 외국에 있어서 그런지 자주 끊기네요.^^
  2. 와!

    꼭 들어봐야겠군요!!!
    일요일에나 들을 수 있을 듯 합니다 =ㅂ=
    당분간은 계속 바쁠 듯 해서... 쩝
    듣고 나서 다시 댓글 드릴께요 ^^
    • 네~ 보시면서 궁금하신 점이 있으시면 댓글 부탁드립니다.
      공급자적인 SaaS의 가치도 나중에 한번 같이 고민해보면 좋겠습니다.
  3. 안녕하세요 선진님
    :) 이 동영상을 저한테 좀 주셔와요.

    저희 EvaCast (http://www.EvaCast.net)에 올리려구요.
    여기 올리면 더 많은 분들이 보실수 있고, 그러니 공유 부탁드립니다.

    물론 선진님 profile과 사진도 필요해요 :)
    제발 please~~~ T_T
    http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=148
    그럼 부탁 드리죠 :)
secret
일반적으로 프로젝트에 관하여 이야기할 때 스테이징(Staging)이란 용어를 사용하면서도 명확하게 스테이징(Staging)에 대한 용어 설명이 부족하여 스테이징의 의미를 쉽게 이해할 수 없었습니다.

저 역시 스테이징이란 용어를 사용하면서 스테이징이란 것이 과연 정확하게 무었인지 잘 모르고 사용해왔던것 같습니다. 그래서 명확하게 스테이징(Staging)이란 무었인지 위키피디아와 함께 정리하였습니다. 늘 감사한 이 위키피디아~ 땡큐입니다.


위키피디아의 내용중 프로젝트 관리(http://en.wikipedia.org/wiki/Project_management)에 대한 부분 중 프로젝트 관리 접근방법(Project management approaches)부분에 스테이지(Stage)에 관한 내용이 나옵니다.

따라서 프로젝트 관리 접근방법(Project management approaches) 의 내용을 정리하면 자연스럽게 스테이지와 스테이징이란 용어의 의미를 파악할 수 있습니다.

따라서 위키피디아의 내용중 스테이징(Staging)과 관련된 내용을 추려서 정리하였습니다. 정리한 내용은 다음과 같습니다.

프로젝트 관리를 위한 전통적인 접근방법(The traditional approach of Project management)


전통적으로 단계화된 접근법은 프로젝트를 완료하기 위하여 일련의 단계를 식별한다. "전통적인 접근방법"은 프로젝트의 개발에서 프로젝트를 5가지 컴포넌트로 구분한다. 5가지 컴포넌트는 4개의 스테이지(stage)와 1의 컨트롤(control)이다.

  • 초기화 스테이지(Project initiation stage)
  • 프로젝트 계획 또는 설계 스테이지(Project planning or design stage)
  • 프로젝트 실행 또는 제품화 스테이지(Project execution or production stage)
  • 프로젝트 모니터링과 제어 시스템(Project monitoring and controlling systems)
  • 프로젝트 완료 스테이지(Project completion stage)

도표로 표시하면 다음과 같다.

http://en.wikipedia.org/wiki/File:Project_Management_(phases).png

http://en.wikipedia.org/wiki/File:Project_Management_(phases).png



모든 프로젝트가 각 스테이지를 거쳐야만 종료되는 것은 아니다. 여러 프로젝트들은 계획(Planning) 단계를 거치지 않을 수 있으며, 또한 모니터링(Monitoring) 단계를 거치지 않을 수 있다. 몇몇 프로젝트는 단계 2와 단계 3 및 단계 4를 여러번 반복한다.

많은 분야(Industries)에서 이러한 스테이지를 활용하고 있다. 종종 이런 접근 방식을 폭포수 모델(Waterfall model)이라고도 부르며, 선형 흐름에 따라 하나의 작업들을 진행하고 다른 작업을 진행하도록 구성되어 있다.

이러한 접근 방식을 약간씩 다르게 적용한다 하더라도 실제적으로 스테이지들은 문제를 해결하기 위하여 다음의 공통된 절차를 따른다.

"문제를 정의하고, 대안을 검토하고, 방안을 선택하고, 구현과 평가를 한다.(defining the problem, weighing options, choosing a path, implementation and evaluation.)"

따라서 각 스테이지는 이러한 문제를 해결하기 위하여 존재하며, 앞에서 이야기한대로 일반적으로 5가지 컴포넌트를 바탕으로 각 스테이지를 진행하는 것이다.

따라서 이러한 결과를 종합하여 볼때 스테이지(Stage)에 따라 각 단계를 구분하여 프로젝트가 진행되는 것을 스테이징(Staging)이라고 한다.

이상으로 스테이징(Staging)에 대한 용어 정리를 마쳤습니다. 언제나 든든하게 옆을 지켜주고 있는 위키피디아 덕분에 이번에도 용어 정리를 마칠 수 있었습니다.

여러모로 스테이징이란 용어의 분명한 의미에 관하여 많이 궁금하였는데, 이번에 확실히 정리할 수 있어서 좋았습니다.

혹시 다른 의견이나 정리가 있으시면 댓글 부탁드립니다.
감사합니다. ;-)
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  4개가 달렸습니다.
  1. 마치 이터레이션의 순환 사이클을 프로젝트 단위로 키운것 같은 느낌이네요 ^^
    전통적이라고는 하나 제가 최근에 익힌 방법론 들과도 유사하기도 하구요

    좋은 정보 잘 들었습니다
    스테이지는 처음 들어봤어요 ㅎㅎ
    • 네~ 저도 그런 생각이 많이 듭니다.

      그~ RUP의 경우에 이 주기를 길게 한번씩 더했다면, Agile의 경우 더 짧게 하는것 같습니다.

      하지만 근본적으로 스테이지를 거친다는 점은 비슷한것 같습니다. 다만 스테이지가 예전에 비하여 명확하지 않아서 그 구분이 애매모호한 점이 있는 것 같습니다.

      좋은 댓글 감사합니다. :-)
  2. 스테이징에 그런 뜻이 있었나요. 새로운 사실을 하나 배우며...

    DW 구축할 때는 Staging Area를 집결지라는 의미로 사용하고 있습니다.

    데이터를 DW에 올려서 본격적으로 사용하기 직전에 각종 데이터 소스로부터 필요한 데이터를 추출하여 변환하고 모으는 곳이지요.

    군대에서도 비슷한 경우에 사용하더군요. 총 공격에 앞서 병력과 화력을 집결하는 장소를 Staging Area라고 부르네요.

    일반적으로는 시가 행진을 할 때 행사에 참여하는 인력과 장비, 소품 등이 집결하는 장소도 Staging Area라고 하네요.

    뭔가를 보여주려고 할 때 관련 인력과 장비가 총 동원되어 대기하는 집결지 == Staging Area

    괜히 아는 척 한 번 해봤습니다.
  3. 음... 저도 스테이징이라는 용어의 정의에 대해서 많이 궁금했었는데 제가 정리한 내용은 다음과 같습니다.

    애플리케이션을 개발하고 나서 우선은 개발자의 시스템에서 테스트를 해 보겠죠.

    그 다음에는 실제 테스팅 환경을 만들어서 테스트를 해 볼 테구요.

    그러나 테스팅 환경에서 잘 되었다고 실제 Production 환경에서 잘 돌아가리라고 확신할 수는 없고,

    결국 실제 운영환경(Production 환경)과 동일한 환경을 구성해서 운영환경으로 넘어가기 직전에 마지막으로

    점검해 보는 것을 스테이징이라고 하고, 이러한 환경을 스테이징 환경, 이때 쓰는 서버를 스테이징 서버 라고 합니다.....

    라는 게 제 나름대로 정리해 본 내용입니다.

    아무도 가르쳐 주는 사람이 없다 보니 대화와 문맥을 통해, 그리고 나름 여기저기 조사해서 얻은 짜투리 지식을

    종합해 봤습니다.

    혹시 틀린 내용이 있다면 알려 주세요..
secret
Ruby on Rails의 확산과 Aspect-Oriented Programming(AOP)의 확산으로 인하여 많은 분들이 Convention over Configuration(CoC)에 관하여 많은 관심을 가지거나 한번정도씩은 들어보신 경험이 있을 것입니다.

하지만 Convention over Configuration(CoC)만을 설명하는 자료가 부족한듯합니다. 최근 하는 일중에 독자들에게 명확하게 Convention over Configuration(CoC)에 관하여 설명할 필요가 있는 일이 있는 관계로 Wikipedia의 자료를 바탕으로 Convention over Configuration(CoC)에 대한 개념을 정리하였습니다. 이런 개념이 나올때마다 얼마나 Wikipedia가 고마운지~ ;-)

보시면서 부족한 점이 있다면 적극적인 피드백이나 참고자료에 관한 조언부탁드립니다.
최근 개념이 부족해서 그런지 이런 개념을 정리하는 작업이 재미있네요~ :-)



Convention over Configuration(CoC)

우리나라에서는 일부 "설정 이상의 관례", "설정보다 관례", "설정을 넘은 관례" 혹은 "설정보다 규범" 등으로 번역하고 있는 Convention over Configuration는 최근 국내에서 CoC로 번역이 통일되어 가고 있는 것 같습니다.

저 역시 CoC를 어떻게 번역할까 많은 고민을 하였으며, 지인들에게도 물어보기도 하였는데, 우리나라에서 사실상의 표준(De-facto)로 CoC로 자리잡혀 가고 있는것 같으며, 저 역시 애매한 번역보다는 CoC가 표기 및 의미 면에서 독자들에게 더 쉽게 이해될 것으로 생각되어 CoC로 번역하기로 결정하였습니다. CoC의 모습이 마치 이모티콘 같아서 쉽게 기억될 것 같습니다. :-)

Convention over Configuration(이하 CoC)는  Coding by Configuration이라고도 알려져 있습니다. 항상 개념이란것이 그러하듯이 CoC 개념 자체는 매우 단순합니다.


CoC는 개발자가 내려야할 수 많은 결정들(decisions)을 줄여주어, 단순성(simplicity)을 확보하면서, 유연성(flexibility)을 잃어버리지 않도록 하기 위한 소프트웨어 디자인 패러다임 입니다.


CoC의 단어상의 근본적인 의미는 개발자는 단지 어플리케이션에서 관습적이지않은 면(unconventional aspects of the application)만 정의할 필요가 있다는 것입니다. 예를들어 Model에 Sale이란 클래스가 있다면, 데이터베이스 내에 대응하는 테이블은 기본적으로 sales라고 불리운다라는 관례(convention)가 있다면, 모든 데이터베이스에 테이블을 생성할때 테이블 명을 관례에 따라 작성한다면 자연스럽게 모델에 대응될 것입니다. 만약 이 관례에 벗어나는 테이블인 products_sold와 같은 테이블이 있는 경우에만, 개발자들은 이러한 테이블 명에 대응하는 코드를 작성할 필요가 있다는 것입니다.

여러분이 원하는 기능들에 일치하는 관례에 따라 툴에 의하여 개발한다면, 여러분들은 설정 파일을 작성할 필요없이 이러한 장점들을 누릴 수 있는 것입니다.

만약 여러분들이 Spring Framework 1.x를 사용해본 경험이 있다면, 수 없이 많은 XML 들을 xdoclet을 통하여 작성하여야만 했을 때의 고통을 잘 알것입니다. 하지만 여러분들이 개발하시려는 어플리케이션의 공통적인 관례(Common Conventions)들만 통일시켜 놓는다면 AOP와 같은 툴을 통하여 이런한 설정의 고통에서 벗어날 수 있다는 의미입니다.

현재 Spring 2.x대에서는 이러한 설정의 고통들이 많이 해결되었으며, Spring 2.5에서는 별다른 설정없이 어노테이션(Annotation)을 통하여 특별한 설정외에는 별다르게 설정할 필요가 없어 개발자들에게 고통을 가져다주면 의미없는 설정들을 하기 위한 결정을 할 필요가 없어졌습니다. 즉 일관된 관례를 통하여 공통적인 관례에 따르는 개발을 진행할 경우에는 개발자의 수고가 많이 줄어드는 장점이 있습니다.

하지만, 이러한 공통의 관례는 모두가 알고 있어야 한다는 점을 주의하여야 합니다.
즉 공통 부분을 책임지시는 분들의 경우 CoC 기반의 개발을 지원하고 계신다면, 공통 프레임웍이나 유틸리티 뿐만 아니라 개발자들에게 공통의 개발 관례까지 지원하여야 합니다. 만약 관례를 벗어나는 개발을 하는 경우에 공통된 관례를 따르지 않으므로, 공통의 관례를 따를 때 자동으로 지원하였던 트랜잭션 처리, 로깅 등의 처리를 개별적으로 처리할 수 있는 방안까지 마련해주어야 하며, 이를 최소화 할 수 있도록 개발자들에게 공통의 관례에 대한 이해를 높일 수 있도록 지속적으로 교육을 할 필요가 있습니다.


CoC는 실질적으로 추상화 레이어를 생성하지 않고도 높은 수준의 추상화 작업을 프로그래머들이 할 수 있도록 지원하는 프로그래밍적인 접근 방식이며, 수 많은 설정들에서 프로그래머들을 해방시켜줍니다.


CoC의 동기
전통적으로, 프레임웍은 여러 다중 설정 파일들을 필요로하며, 각 설정 파일은 많은 설정들을 포함하고 있습니다. 이러한 설정 파일들은 각 프로젝트에 맞는 특정한 정보를 제공하며, 이러한 설정의 범위는 URL에서부터 클래스들과 데이터베이스 테이블 사이의 매핑까지입니다. 즉 엄청나게 다양할 수 있다는 의미입니다. 어플리케이션의 복잡도에 따라 이러한 설정 파일들의 수와 크기는 매우 쉽게 늘어납니다. 이에따라 설정의 방법도 복잡해지며, 이러한 설정을 개발자가 일일이 하여야 하기 때문에 개발의 속도는 감소되며, 개발의 복잡도는 증가하게 됩니다.

예를들어, 잘 알려진 자바 영속성 매퍼(Java persistence mapper)인 Hibernate의 이전 버전의 경우, 엔티티들을 엔티티에 대응하는 데이터베이스의 필드를 연결시키기 위하여 XML 파일 안에 각 관계를 기술하여야 하였습니다. 클래스(class) 명은 데이터베이스의 테이블(table) 명 같으며, 필드(field) 명은 컬럼(column)과 각각 같도록 관례적으로 표현하였기 때문에 대부분의 정보는 이러한 정보들을 가지고 있었습니다. CoC를 채용한 이후의 버전에서 이러한 XML 설정 파일들 대신 많은 관례(convention)들을 채용하였으며, 자바의 어노테이션을 사용하여 이러한 변화를 수용하였습니다.


활용
대부분의 현대적인 프레임웍에서는 CoC적인 접근방법을 사용하고 있습니다.
CoC는 현재 Ruby on Rails, Zend Framework, Grails, Spring, Castle MonoRail, JUnit, JBoss Seam, CakePHP, symfonyKohana에 포함되어 있습니다.


참고자료



Wikipedia 덕분에 정리가 점 되었습니다.

http://softwareengineering.vazexqi.com/files/pattern.html를 보면 CoC는 패턴으로도 나와 있는데, 추후 CoC에 패턴적인 의미를 고찰해 보겠습니다.
감사합니다. :-)
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  7개가 달렸습니다.
  1. 우왕 이해를 못하겠어요 ;ㅁ;
    아직은 멀었다는 생각만... 크윽!

    좋은 개념에 대해서 소개해 주셔서 감사합니다.
    나머지는 제 몫이겠죠
  2. 비밀댓글입니다
  3. 개념이라 설명하기 힘든 것이겠지요
    저도 참 좋아라 하는 개념입니다.
    단지 그 개념을 표준화 할 수 없다는게 문제라 생각합니다.
  4. 도움 많이 됐습니다.
    그런데 오타가 하나... ^^

    단순성(simplicity)을 확보하면서, 유연성(flexibility)을 읽어버리지 않도록 하기 위한 소프트웨어 디자인 패러다임 입니다.

    --> 잃어버리지..
  5. 안녕하세요 이번 사내 Maven 세미나에서 장선진 님의 글을 조금 많이 인용하려 합니다.
    인용구에 대한 출처는 남겼습니다. ^^
  6. 글 잘읽고 갑니다~
  7. 잘봤습니다~!
secret
최근 태스크 중심의 인터페이스(Task-Focused Interface)란 용어를 접했습니다. 제대로 그 뜻을 이해하지 못하여서 결국 Wikipedia의 내용을 중심으로 정리하기로 하였습니다.

정리한 내용은 다음과 같습니다. 태스크 중심 인터페이스에 관심있으신 분들은 참고하시기 바랍니다.


태스크 중심의 인터페이스(Task-Focused Interface)

태스크 중심의 인터페이스(Task-Focused Interface)는 컴퓨터 어플리케이션을 위한 것으로 University of British ColumbiaSoftware Practices Lab에서 2004년에 연구 프로젝트로 시작되었다. 2005년에는 Tasktop Technologies Inc에서 이끄는 오픈소스 이클립스(eclipse) Mylyn 프로젝트를 통하여 첫번째 태스크 중심의 인터페이스의 배포판이 나타났었다. 태스크 중심의 작업의 장점으로 인하여 재빨리 채용하기 수많은 개발자들이 바로 나타났다.
오늘날에는 Tasktop Technologies Inc.에서 이클립스 Mylyn  오픈소스 프로젝트를 지속적으로 이끌며, 수십만명의 사용자들에게 이 기술로 매일 효용을 주고 있다.

기술관련 사항
태스크 중심의 인터페이스의 가장 중요한 목적은 사용자의 현재 태스크에 관련되어 있는 컴퓨터 어플리케이션에서 나타내는 정보를 바로 보여주는 것이다. 사용자의 상호작용을 기반으로, 사용자가 개개인별로 사용할 수 있는  식별 가능한 정보의 요소들은 DOI(Degree-of-Interest) 순위에 할당된다.
사용자가 조금 더 자주 최근에 상호작용했었던 정보의 요소들이 작업(Task)을 위한 DOI의 항목에 더 높게 책정된다.

정보 요소들을 위한 DOI 순위는 4가지 방법으로 태스크 중심의 인터페이스(Task-Focused Interface)에서 사용된다. DOI를 사용하는 항목들은 나타나게될 수많은 항목들을 줄이기 위하여 걸러진다. 항목들을 관리하는 DOI에 의하여 순위가 정해질 것이다. 예를 들면, 가장 관심있는 항목들이 목록의 가장 최상위에 보여질 것이다. 항목들은 DOI의 범위를 표시하기 위하여 색상으로 장식될 것이다. 마지막으로 구조화된 정보 항목들이 표시될 때 DOI에 의하여 자동적으로 관리될 것이다. 예를들면, 낮은 DOI의 항목은 자동적으로 감추어질 것이다.

작업(Task)의 한 부분과 같이 상호작용된 각 정보 항목을 위한 DOI의 값은 어플리케이션의 사용자 작업과 같이 기록된 상호작용 이벤트 히스토리 저장소에서 얻는다.(즉 DOI에 따라 사용자가 작업한 결과 값은 어플리케이션에서 기록되고, 이를 다시 DOI에 반영하여 DOI 항목을 조정한다는 의미입니다.)

이러한 방식은 작업(Task)의 시작점을 사용자에게 명시할 필요가 있다. 모든 상호작용 이벤트의 집합은 Task Context라 불리우는 단일 작업(Task)을 하는 동안 일어난다.

태스크 중심의 인터페이스는 정보의 과부화를 줄여주고 생산성을 향상시켜주는데 효과적이라는 것이 입증되었다.

이클립스 Mylyn 프로젝트는 태스크 중심의 인터페이스의 구현체이다. Mylyn은 현재 활성화된 작업을 바탕으로 이클립스 IDE에서 수많은 뷰(View)를 위한 필터(filters), 정렬(sorts), 강조(highlights), 접기(folds), 그리고 관리 트리 확장을 지원한다.


오픈 소스 구현체

Open Source Implementations


이상입니다.  저도 이렇게 정리하고 나니 이해가 오는군요 :-)
혹시 조금 더 깊에 살펴보고 싶으신 분들은 http://www.ibm.com/developerworks/kr/library/j-mylar1/http://www.infoq.com/news/2008/02/tasktop-10 를 참조하셔도 좋을 것 같습니다.

보시면서 좋은 자료를 알고 계시거나 보완해야 할 점들이 있다면 바로 댓글 부탁드립니다.
감사합니다. ;-)
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글 하나 달렸습니다.
  1. 와 이거 재미난데요!
    자바를 모르니 툴들이야 그렇다 치더라도
    태스크 중심이라니... ㅎ
    재미난 개념 감사합니다 ^^

    (참, 저 블로그 두개로 나뉘었어요 놀러와주세요)
secret

SaaS 기반의 어플리케이션이 많은 각광을 받을 것 같습니다.

이에 따라 SaaS기반의 어플리케이션이 제공하는 서비스를 평가하는 기준이 필요한 시점입니다.

여러 가지 좋은 평가 기준들이 존재하지만 Google의 평가기준이 여러모로 좋은 관점을 제공하고 있는 것 같습니다.

아직 국내에서는 Google Apps를 많이 사용하지 않고 있지만, 알게 모르게 많은 분들이 큰 관심을 보이고 계십니다.

  

특히 소규모 기업이나 조직(비영리 조직인 동아리나 클럽 등)에서 Gmail을 자신들의 도메인과 연동시켜 사용하고 있습니다.

이에 관한 자세한 내용은 다음에 한번 다루겠습니다.

 

이처럼 SaaS 기반의 서비스들을 사용하려고 할 때 여러 가지 고민해야 할 점들이 있습니다.

이러한 점들을 모아 Google에서 "SaaS를 통한 비즈니스 및 IT 생산성 향상"이란 문서를 만들었습니다.

쉽게 질문 형식으로 정리되어 있어서 SaaS 기반의 서비스를 도입하시려고 할 때 참고하시면 좋을 듯합니다.

 

참조 1 http://www.google.com/a/help/intl/ko/security/platform.html

간단한 소개는 다음과 같습니다. 참 SaaS 기반의 어플리케이션을 구축하실 때 고려하셔야 할 점들이 매우 많습니다.

 

IT 조직에서 통신 보안 및 규정 준수 주문형 솔루션 제공업체를 평가하기 위해 고려해야 하는 5가지 주요 요소는 다음과 같습니다.

 

효율성
높은 효율성은 통신 보안 및 규정 준수 솔루션의 선정에서 가장 우선적으로 고려되어야 하는 요소입니다. IT 조직에서는 변경이 필요할 경우 이를 수행할 수 있을 뿐 아니라 변경 중에도 지속적으로 효율적인 통신 보안 및 규정 준수를 제공할 수 있는 솔루션인지 평가해야 합니다. 주문형 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

 

  1. 이메일이나 웹 등 모든 통신 채널을 통해 보안 및 규정 준수를 제공하는 플랫폼 기반 방식으로 솔루션이 구현되었습니까?
  2. 서비스 중단 없이 신속하고 간편하게 새로운 서비스나 응용 프로그램을 솔루션에 추가할 수 있습니까?
  3. 필요할 경우 간편하게 솔루션을 변경해 최신 규정 및 법적 기준을 적용할수 있습니까?
  4. 새로운 보안 위험 요소를 신속하게 파악하고 이에 따른 보호 방안을 솔루션에 채용하여 고객의 위험에 대한 노출을 최소화할 수 있습니까?
  5. 고품질의 SaaS를 안정적으로 제공할 수 있는 축적된 경험이 있습니까?

 

유연성
주문형 통신 보안 및 규정 준수 솔루션을 선정할 때에는 확장성을 지원하는지 알아보는 것이 중요합니다. 조직에서는 자신들의 구체적인 요구사항을 해결하며 기술 직원이 수익 창출에 도움이 되는 보다 가치 있는 작업을 수행하는 데 더 많은 시간을 쓸 수 있도록 편리하게 관리할 수 있는 솔루션을 찾아야 합니다. 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

  1. 이메일과 웹 상에서 유사 정책 및 이의 처리 결과는 어떻게 관리됩니까?
  2. 동일한 정책 설정을 중복해서 사용할 수 있습니까? 아니면 각 정책에 대해 별도의 프로필을 작성해야 합니까?
  3. 새로운 보안 위험 또는 규정에 따라 긴급하게 정책을 변경해야 할 때 얼마나 신속하게 변경내용을 적용할 수 있습니까? 수분이 걸립니까, 아니면 수시간이 걸립니까?
  4. 정상적인 프로세스에서 조직 내 서로 다른 부서별로 독립적인 정책 또는 규정 요구사항을 만들 수 있습니까?
  5. 메시지 추적 및 조사를 위해 얼마나 세밀한 수단을 제공합니까?

 

배포 및 사용의 용의성
통신 보안 및 규정 준수 솔루션에서 가장 중요한 기능 중 하나는 배포 및 사용의 용의성입니다. 이 두 가지 측면에서 솔루션이 어렵고 복잡할수록 보안 수준은 낮아지고 조직 내 지속적인 규정 요구사항을 준수하기가 어려워집니다. 이러한 측면에서 솔루션이 갖춰야 할 주요 요소는 다음과 같습니다.

  1. 솔루션 실행에 걸리는 시간은 얼마입니까?
  2. 솔루션을 설정하거나 정기적으로 구성을 변경할 때 어느 정도의 작업이 필요합니까?
  3. 솔루션이 전자 통신을 처리하는 데 걸리는 부하는 어느 정도입니까? 처리지연 및 보안 위험을 초래할 수 있는 디스크 저장 과정이 필요합니까? 아니면 고급 수준의 메시지 처리 프로세스를 제공합니까?
  4. 직원들이 셀프 서비스 포털을 통해 필터 적용과 같은 일반적인 업무를 직접수행할 수 있습니까? 아니면 관리자가 있어야만 수행할 수 없습니까?
  5. 솔루션을 사용하는 데 필요한 데이터 용량은 얼마나 됩니까?
  6. 솔루션 실행 및 관리에 하드웨어 및 인력자원이 별도로 필요합니까?

 

총소유비용(TCO)
통신 보안 및 규정 준수 솔루션의 초기 투자 비용은 빙산의 일각인 경우가 많습니다. 조직에서는 초기 투자 비용 및 추가 관리 비용이 낮은 주문형 솔루션을 선정할 수 있도록 정밀한 조사를 실시해야 합니다. 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

  1. 솔루션을 배포하는 데 소요되는 기간은 얼마입니까?
  2. 솔루션을 배포하는 데 필요한 리소스는 무엇이 있습니까?
  3. 업체에서 솔루션 구현을 관리합니까? 아니면 기업에서 전문가를 고용해야합니까?
  4. 솔루션을 구현하는 데 추가 하드웨어, 소프트웨어 또는 기타 리소스에 대한 추가 자본 투자가 필요합니까?
  5. 솔루션 초기 투자 비용은 얼마입니까? 향후 관리 비용이 추가로 필요합니까?

이 외의 자세한 내용은 "SaaS를 통한 비즈니스 및 IT 생산성 향상" 에서 확인하세요~

 

신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
컴퓨터와 관련하여 플랫폼이라는 용어는 응용프로그램이 실행될 수 있는 기초를 이루는 컴퓨터 시스템을 의미한다. PC에서는 두 개의 서로 다른 플랫폼의 예로서 윈도우95와 매킨토시를 들 수 있으며, 대형 서버나 메인프레임에서는 IBM의 System/390을 하나의 플랫폼 으로 볼 수 있다.

하나의 플랫폼은 운영체계, 컴퓨터 시스템의 보조 프로그램, 그리고 마이크로프로세서, 논리연산을 수행하고, 컴퓨터 내의 데이터 이동을 관장하는 마이크로칩 등으로 구성된다. 운영체계는 특정 마이크로프로세서의 명령어 집합과 함께 동작할 수 있도록 설계되어야 한다.

예를 들면, 마이크로소프트의 윈도우95는 같거나 비슷한 종류의 명령어 집합을 공유할 수 있는 인텔의 마이크로 프로세서군과 함께 동작할 수 있도록 만들어졌다. 마더보드나 데이터버스 등과 같이 어떠한 컴퓨터 플랫폼이라도 보통 다르게 적용된 부품들이 있지만, 이러한 부품들은 점차적으로 모듈화되고 표준화되어가고 있다.

역사적으로 대부분의 응용프로그램들은 특정 플랫폼 상에서만 운영되도록 개발되어 왔다. 각 플랫폼은 다른 시스템 서비스들을 위해 다른 응용프로그램 인터페이스를 제공한다. 그러므로 윈도우 플랫폼에서 운영되기 위해 개발된 PC 프로그램을, 매킨토시 플랫폼에서 운영하기 위해서는 프로그램을 처음부터 다시 개발해야만 했다. 비록 이러한 플랫폼의 차이들은 계속 존재하고, 그들 사이에는 항상 독점기술에 관한 차이가 존재하겠지만, 표준을 따르는
새로운 개방형 인터페이스를 통해 이제는 일부 프로그램들이 다른 플랫폼에서 운영될 수 있고, 브로커 프로그램 등의 중재를 통해 서로 다른 플랫폼간의 상호 운영이 가능해지고 있다.

플랫폼은 다른 기술들 또는 공정들이 그 위에서 구현될 수 있는 일종의 기술 기반을 의미하기도 한다.

실제로 사용자들이 컴퓨터 시스템을 사용한다는 것은 해당 컴퓨터 시스템을 활용하여 사용자 자신이 원하는 결과를 얻을 수 있는 것을 의미한다. 대부분의 사용자들은 자신이 사용하는 컴퓨터 시스템을 이용하여 자신이 원하는 결과를 얻기를 바라며, 이를 위하여 주로는 응용 프로그램을 사용하여 자신의 목적을 달성하려 한다. 일반적으로 사용자는 컴퓨터 시스템의 응용 프로그램을 사용하여 원하는 결과를 얻게 마련이므로, 실제로 사용자들의 주된
관심은 컴퓨터 시스템의 응용 프로그램(Application s Progr am )에 있다. 응용 프로그램은 실제로 컴퓨터 시스템의 운영 시스템(OS : Operating Sy st em )에 의존적이므로, 사실상 사용자가 어떤 응용 프로그램을 사용하는가하는 것은 어떤 운영 시스템을 가지고 있는가 라는 질문에 대한 답과 마찬가지의 경우가 된다.

Eclipse Platform architecture


플랫폼의 예

일반 사용자들의 경우는 어떤 운영 시스템 환경에서 작업을 하는가하는 것은 사실상 관심이 없으며, 어떤 응용 프로그램을 사용할 수 있는가에 더 관심을 가지게 된다. 예를 들어, 486DX 기종의 하드웨어와 P entium 기종의 하드웨어를 직접 비교해 본다면, 분명히 Pentium 기종이 하드웨어적으로 우월한 기종임은 말할 필요가 없다. 그러나, 여기에 운영 시스템을 포함하여 비교한다면 이야기가 상당히 달라질 수 있다. 486DX 기종에는 Windows 95가 설치되어 있고, 하드디스크(Hard Disk )의 빈 용량이 상당히 있다고 가정해 보자.
또한 Pentium 기종은 하드디스크의 빈 공간은 상당히 많으나, 운영 시스템이 MS - DOS 5.0이 설치되어 있다고 가정해 보자. 이 두 시스템을 이용하여 Spr eadsh eet 작업을 하여야 한다면, 어떤 기종을 선택할 것인가? 일단 사용자는 Spread Sheet 작업용 응용 프로그램이 설치되어 있는 기종을 선택할 것이나, 현재 설치되어 있지 않다고 해도 설치가 가능한 기종을 선택하게 될 것이다. 따라서 위와 같은 경우에는 Pentium 기종을 선택하기보다는 486DX 기종을 선택하게 될 것이다. 이 경우, 사용자는 도스 플랫폼을 선택하지 않고 윈도우 플랫폼을 선택했다. 라고 이야기 한다.


플랫폼의 일반적 의미

어떤 특정 시스템의 하드웨어와 소프트웨어를 통칭하여 일컫는 표현이 플랫폼이다. 만약 예를 들어, 휴대폰을 단말기(T erminal) 삼아서 무선 인터넷에 접속하고자 하는 경우에, 사용자는 일단 두 가지 요구 사항을 갖추고 있어야 한다. 첫째는 무선 인터넷 접속이 가능한 휴대폰 기기를 가지고 있어야 하며, 또한 해당 휴대폰에는 인터넷 접속이 가능하도록 해주는 소프트웨어가 설치되어 있어야 한다. 즉, 어떤 사용자가 휴대폰으로 인터넷을 사용하기 위해
서는 하드웨어와 소프트웨어가 모두 갖추어져 있어야 가능한 것이다. 즉, 어떤 특정 과업이나 작업을 완료하기 위해서 실제로 하드웨어뿐만 아니라 소프트웨어도 갖추어져 있어야 한다.
실제 어떤 특정 과업을 수행하기 위해 필요한 하드웨어와 소프트웨어를 총칭하는 개념이 바로 플랫폼이다. 무선 인터넷에 접속하기 위한 플랫폼에는 여러 종류가 있을 수 있다. 앞서 예를 든 경우처럼, 휴대폰 단말기에 소프트웨어를 총칭하는 것일 수도 있고 노트북 PC에 무선 랜 카드를 갖추고 소프트웨어까지 갖추고 있는 경우도 될 수 있다.


컴퓨터 시스템에서의 플랫폼의 의미

일반적인 의미의 플랫폼은 하드웨어와 소프트웨어를 총칭하는 개념이다. 그러나, 컴퓨터 시스템에서 플랫폼의 의미는 하드웨어와 운영 시스템을 총칭하는 개념으로 바뀌어 진다. 왜냐하면 소프트웨어들 중의 상당수는 응용 프로그램이며, 이 응용 프로그램들은 운영 시스템에 종속적이기 때문이다. 어떤 특정 응용 프로그램은 지정된 운영 시스템에서만 구동될 수 있도록 설계된다. 그렇기 때문에 사실상 컴퓨터 시스템에서의 플랫폼은 하드웨어와 운영 시
스템을 총칭하는 개념만으로 충분하다 할 수 있을 것이다.


컴퓨터 시스템에서의 플랫폼의 종류

일반적으로 컴퓨터 시스템의 플랫폼은 크게 두 종류로 나눌 수 있다. 하나는 한 사람의 사용자가 접근하여 사용할 수 있도록 설계된 운영 시스템을 가지고 있는 플랫폼이고, 또 다른 하나는 동시에 두 명 이상의 사용자들이 접근하여 사용할 수 있도록 설계된 운영 시스템을 가지고 있는 플랫폼을 의미한다. 전자를 가리켜서 클라이언트(Client ) 플랫폼이라 하고, 후자를 가리켜서 서버(Server) 플랫폼이라 한다. 일반적으로 컴퓨터 시스템을 크게 나누어 클라이언트와 서버로 구분할 수 있는 것처럼, 컴퓨터 시스템의 플랫폼도 역시 클라이언트 플랫폼과 서버 플랫폼의 두 종류로 나뉘게 된다.

신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
최근 소프트웨어 아키텍처 정의에 대한 글을 찾다가 좋은 문서를 찾아서 올립니다.

2004-141-318.pdf

소프트웨어 아키텍처 연구 분야 및 IEEE 1471 국제표준 저자: 함동한발행일: 2004.03.22발행기관: 한국정보통신기술협회



짧게 요약하면 다음과 같습니다.

소프트웨어 아키텍처의 정의
소프트웨어 아키텍처는 한마디로 개발하려고 하는 소프트웨어의 큰 밑그림을 그리는 것으로 소프트웨어 개발에 직간접적으로 영향을 미치면서 복잡도를 높이는 다양한 요소들을 체계적으로 다루기 위한 청사진이라 할 수 있다.

소프트웨어 아키텍처의 학술적인 정의는 소프트웨어를 구성하는 컴포넌트들, 이들간의 상호작용 및 관계, 각 컴포넌트들의 특성 및 이들이 구성하는 소프트웨어의 설계 및 진화를 위한 각종 원칙들의 집합이라고 할 수 있다.

실제적으로 아키텍처는 대상이 되는 시스템에 관련된 여러 이해관계자(stakeholder)의 관심사항과 이에 따른 관점을 반영한 다양한 모델들의 집합이 된다.


소프트웨어 아키텍처 관련 국제표준

2000년에 제정된 IEEE 1471 국제표준(IEEE Recommended Practice for Architectural Description of Software-Intensive Systems)은 아키텍처가 표현해야 하는 내용 및 이들간의 관계를 제공하고 있다.

사용자 삽입 이미지

출처: http://www.ibm.com/developerworks/rational/library/nov06/ferm/



IEEE 1471은 아키텍처를 만들기 위해 다음과 같은 활동을 해야 한다고 규정하고 있다.
  • 아키텍처 관련 문서의 파악
  • 이해관계자, 그들의 역활 및 아키텍처상의 관심 사항의 파악
  • 뷰 포인트의 선택 및 명세
  • 뷰의 명세
  • 뷰들간의 존재하는 불일치성의 파악 및 기록
  • 선택되어 설계된 아키텍처에 대한 논리적 근거(Rationale) 작성

또한 위의 각 활동별로 아키텍처 명세에 포함되어야 하는 정보를 규정하고 있는데 예로 뷰 포인트 명세를 위해 다음의 정보가 다루어져야 한다.
  • 뷰 포인트의 이름
  • 뷰 포인트에 의해 다루어지는 이해관계자
  • 뷰 포인트에 의해 다루어지는 관심사항
  • 뷰 포인트에 근거한 뷰를 만들기 위한 방법론
  • 뷰 포인트 라이브러리의 출처(적용 가능한 경우)

IEEE 1471은 수년간 아키텍처 개발에 관련된 Best Practices에 기반하여 만들어진 국제표준으로 아키텍트가 유용한 아키텍처를 개발하기 위하여 필요한 정보와 불필요한 정보를 구분하고 이를 바탕으로 아키텍처 모델 및 이와 관련한 정보를 일관성있게 조직화할 수 있도록 효과적으로 활용될 수 있을 것으로 기대된다.



최근 필자는 좋은 아키텍처를 구성할 수 있는 방안에 대하여 많은 관심을 가지고 있습니다.
IEEE 1471에 대하여 앞으로 많은 공부가 필요할 듯합니다. 혹 본 포스트를 보시면서 IEEE 1471에 대하여 알고 계시거나 관련 자료가 있으신분은 공유 부탁드립니다.

감사합니다.
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret