champ poster

오랜만에 지방에 강의를 하러 내려갔습니다.  강의 비용은 서울에 비해 많이 적은 편이며, 이동 시간과 차비 그리고 하루를 꼬박 다 날려야 하기 때문에. 금액만 보면 솔직히 지방에 가기란 쉽지가 않습니다.

하지만 전 지방은 찾아 내려가는 편입니다. 저 역시 고향이 부산이라, 지방 개발자의 서러움을 잘 알고 있기 때문입니다. 소마에 과정에 만난 제자이며, 청출어람이라고 평할수 있는 고액 수입자인 Sleep if you can의 신재명 대표님과 같이 내려갔습니다. 먼길을 마다않고 같이 가준 신재명 대표에게도 정말 감사하구요.

도착을 하자 마자 깜짝 놀랐습니다.  현수막과 포스터까지 곳곳에 부쳐져 있었거든요.. 참 예전 생각이 많이 났습니다.  지방 에서 무엇을 하겠다고 깔짝 거리는 시절.  아는것도 없으면서 잘난체 하고, 정보를 몰라 좌절하는 옛날 기억들이 났습니다.

계속 읽기


패턴 저자 : 손영수, 오혜성, 양현철, 정승수 

소프트웨어 시스템에 있어서 아키텍처는 소프트웨어의 개발이 진행 되면서 지속적으로 성장해 나가며, 고객의 다양한 요구 사항들을 수용할 수 있도록 변화에 대응할 수 있어야만 한다.  높은 품질을 가지는 소프트웨어 시스템을 개발하기 위해서는 계속 진화하는 소프트웨어 시스템의 아키텍처를 실시간으로 확인할 수 있어야 한다. 그러나 현재 알려진 기본적인 방법들로는 이러한 아키텍처 파악이 매우 힘든 것이 현실이다. 그래서 이번에는 소프트웨어 시스템의 아키텍처를 시각화 할 수 있는 다양한 방법들을 패턴으로서 이야기 하고자 한다.

소프트웨어 시스템의 아키텍처는 다양한 사람들이 참여하여 개발하게 되면 처음 의도와는 다른 방향으로 바뀌어질 가능성이 존재하며, 이에 따라서 원치 않았던 잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는 상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의 아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해나가야만 한다.

이러한 소프트웨어 시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스 코드를 분석하여 파악하는 방법들이 존재한다. 그러나 이러한 방법들은 여러 단점들을 가지고 있는데 클래스 다이어그램을 기반으로 분석하는 방법의 경우 너무 넓은 시점에서 소프트웨어 시스템을 분석하기 때문에 정확한 아키텍처를 파악하기도 힘들며, 아키텍처적인 문제들을 해결하기에는 너무 적은 정보를 제공한다. 그리고 코드 기반 분석은 클래스 다이어그램 기반 분석과는 달리 너무 작은 시점에서 소프트웨어 시스템을 분석하기 때문에 아키텍처를 파악하는 것이 힘들고, 분석하는 것도 너무 많은 시간이 걸리게 된다. 이렇게 기존의 쉽게 접할 수 있는 방법들로는 소프트웨어 시스템의 아키텍처를 파악하기란 매우 어렵다고 할 수 있다.

그래서 여기에서는 소프트웨어 시스템의 아키텍처를 보다 간편하게 분석할 수 있도록 도와주는 아키텍처 시각화 기법들을 패턴으로써 정리하여, 해당 시각화들을 구현하기 위한 기본적인 방법들을 소개하고, 각각의 시각화 패턴을 활용한 분석들의 장점과 단점들을 소개할 것이다.

아키텍처 시각화 패턴을 위한 로드 맵

앞서 이야기 했던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나, 너무 좁은 범위에서만 보기 때문에 다양한 문제들이 발생 하였다. 그렇기 때문에 적절한 수준에서 소프트웨어 시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할 수 있게 된다. 이러한 적절한 수준으로 사용할 수 있는 분석 방법은 바로 소프트웨어 시스템의 다양한 Metric 정보(소프트웨어 시스템에 대한 아키텍처적인 수치 정보)와 구성요소(도메인)들의 의존성을 분석하는 것이다. 이 방법을 이용하게 되면 소프트웨어 시스템의 아키텍처에 대한 정보들과 여러 문제점들을 다양한 수치 정보로서 바로 파악할 수 있게 되며, 의존성 분석을 통해 얻은 정보로는 실제 소프트웨어 시스템의 아키텍처적인 의존성을 보여주기 때문에 아키텍처 분석이 더욱 용이해지고, 상호 참조와 같은 아키텍처적인 문제점을 찾기에 용이해진다.

하지만 이러한 Metric 정보와 소프트웨어 시스템의 도메인들의 의존성을 분석하기만 하여서는 직관적이고 명시적인 분석결과를 얻을 수 없으며, 전체적인 분석 또한 빠른 시간 안에 할 수 없다. 그렇기 때문에 이러한 문제들을 해결하기 위해서는 Metric 정보와 도메인들의 의존성을 분석 정보들을 단순히 제공하는 것이 아닌 정보들을 시각화하여 분석 하고자 하는 사람이 쉽게 이해할 수 있는 다양한 Chart를 활용하는 형태로 분석 결과를 제공 해야만 한다.

이러한 아키텍처 시각화 기법을 사용하게 되면 코드 분석이나 클래스 다이어그램 분석에 비하여, 초기 비용(시각화 환경 구성 등)이 많이 필요하지만, 소프트웨어 시스템의 아키텍처를 보다 빠르게 분석할 수 있게 되며 잠재적인 아키텍처적인 문제점들을 미리 예방할 수 있도록 도와주며, 더 나아가 아키텍처를 확장 가능한 아키텍처로 유지할 수 있도록 도와주어, 고객의 요구 사항에 쉽게 대응할 수 있도록 해주게 된다.

이러한 형태로 아키텍처 시각화를 구축하기 위해서는 다음과 같이 패턴들을 적용해야 한다.

  • 가)   Domain Level Classifier 패턴을 기반으로 소프트웨어 시스템의 도메인들을 분류한다.
  • 나)   Class Relationship Classifier 패턴을 기반으로 분류된 도메인들 간의 객체 지향적인 의존성들을 모두 분류한다.
  • 다)   분류된 도메인들과 객체 지향적인 의존성들을 정보들을 바탕으로 Base Metric Extractor 패턴을 활용하여 소프트웨어 시스템의 품질에 관한 Metric 정보들을 추출한다.
  • 라)   구성된 Metric 정보와 의존성 정보들을 바탕으로 아키텍처 시각화(Dependency Chart 패턴, Size of Component Chart 패턴, Robert C Martin Chart 패턴, Pollution Chart 패턴)를 표현한다.
그림1. 소프트웨어 시각화를 위한 패턴언어

그림1. 소프트웨어 시각화를 위한 패턴언어

<그림 1>은 위에서 소개한 절차를 바탕으로 아키텍처 시각화 패턴을 구성하는 다양한 패턴들간의 관계들을 표현한 패턴 구성도(패턴 맵)이다. 앞으로 시각화 패턴을 구축하는 하위 패턴들부터 시작하여, 구체적인 아키텍처 시각화 방법들이 담긴 패턴들을 소개하는 일종의 하향식 접근을 통해 아키텍처 시각화 패턴에 대해서 이야기 하겠다. 추가적으로 여기에서는 설명을 보다 쉽게 하기 위해서 객체 지향 언어 중 Java을 기반으로 예제들을 설명하겠다.

계속 읽기

may2010-2x3릴리즈 및 설치 프로세스에 대한 디버깅이 프로젝트가 종료되는 시점까지도 진행되지 못하는 경우가 많습니다. 어떤 프로젝트에서는 설치도구를 작성하는 일이 릴리즈 엔지니어에게‘필요악’으로 주어집니다. 리뷰나 데모는 모든 것이 잘 동작함을 보장하기 위해 수작업으로 수행하는 경우가 많습니다. 결과적으로 팀은 너무 늦어서 변경하지 못할때까지도 릴리즈 프로세스 및 릴리즈하는 환경을 경험하지 못합니다.

설치/릴리즈 프로세스는 첫 번째로 고객에게 보여지는 것입니다. 단순한 설치/릴리즈 프로세스는 신뢰할 만한(또는 최소한 디버깅하기 쉬운) 동작 환경을 갖는 첫 단계입니다. 릴리즈된 소프트웨어는 고객이 사용하는 것입니다. 릴리즈된 프로그램이 올바르게 설치되는 것을 보장할 수 없다면, 여러분은 제대로 소프트웨어를 사용하지 못한 고객으로부터 많은 질문을 받게 될 것입니다.

설치 프로세스가 있는 프로젝트로 시작하면 제품 개발 주기 동안 프로세스를 발전시킬수 있는 시간을 벌 뿐만 아니라, 설치를 좀 더 쉽게 할 수 있도록 애플리케이션 코드를 변경할 수 있는 기회를 얻게 됩니다. 설치 프로세스를 주기적으로 수행하고 테스트함으로써 여러분이 작성한 코드가 개발 환경이나 테스트 환경뿐 아니라 사용자의 환경에서도 동작한다는 것을 확인할 수 있습니다.

계속 읽기

NIPA 소프트웨어 공학센터의 지원으로, Android Application Block이라는 안드로이드 참조 아키텍쳐 모델을 만들었습니다 .

컨퍼런스를 통해서 먼저 소개하였고, 프리젠테이션을 통해서 안드로이드의 문제를 해결할때 필요한 여러 오픈소스들을 설명해 드렸습니다.  (재미난 것은 외국에서도 Android Bootstrap이라는 형태로 기존 Android의  문제를 해결하기 위해 여러 오픈소스를 묶어 제공을 했고, 안드로이드 개발자에게는 꽤 인기가 좋은 것으로 알고 있습니다.  )

이 버전보다 더욱 업데이트된 모바일 참조 아키텍처 (안드로이드) 를 발간 하였습니다. (링크를 통해 다운 받으시면 됩니다 – 소프트웨어 공학센터에 이메일 가입이 필요합니다)

안드로이드 어플리케이션 블록 아키텍처 

기존의 안드로이드의 구조(젤리 빈 기준)는 진성주 군과 분석하여  정리해보았습니다 (이 링크를 클릭하시면 됩니다).

그리고 저희가 몇가지 오픈소스들을 더해서 아래와 같이 추가된 모델을 만들었습니다.  새로 추가된 오픈소스가  기존의 어떤 안드로이드 패키지와 연관이 있는지 색깔을 입혀 표현을 하였습니다.

android application block_nipa

계속 읽기

학교에서 컴퓨터 공학을 배우면서,  소프트웨어에 대해서 쓸 고객에 대해서 정말 고민한적이 있나요? 이 소프트웨어는 이러 이러한 것들을 제공하기때문에, 정말 좋아요. 라고 컴퓨터를 모르는 사용자가 알아들을 수 있게 가치를 설정하고 전달하도록 고민해 본적이 있을까요?  아마 우리는 공돌이기 때문에 이러한 것들을 몰라도 된다고 위안을 삼고 싶겠지만, 여실하게 대기업에서도 전 이 문제점과 부딪혔습니다.

대기업에서 나의 고객 - 보스

실제 고객을 한번도 만나보지 않고 기획이나 UX팀에서 날라온 공급자 중심의 설계, 그리고 고객들의 불만을 대응하기 위해 일정에 쫓겨가며 헐레벌떡 기능을 구현하게 만들고, QA팀과 이건 버그가 아니다라고 실강이 한 기억들이 납니다.  저의 고객은 임원인 경우가 많죠.

사실 저도 이러한 부분과 거리가 멀었고,  소프트웨어 마에스트로 과정을 통해서 깨닫게 되었습니다.

알람몬을 만든 김영호 사장님이나,  Sleep if you can의 신재명군과  같이 그들이 얼마나 고객의 피드백을 받아가며, 그리고 사업적으로 살아남기 위해 여기 저기 뛰어나닐수 밖에 없는 모습을 보며, ” 나는 저 나이에 저런 열정이 있었나?” 라며 되돌아 보게 됩니다. (이 친구들과 같이 한 정부 과제가 있는데 그중 일부가 여기에 있으니 참고하세요)

NHN NEXT의 휴먼 디자인 프로젝트나  소프트웨어 마에스트로 과정은 비록 리얼 월드는 아니지만, 최대한 그것에 가깝게 갈려고 많은 교수님들과 멘토님들이 날카롭게 질문을 합니다. (아무리 가깝게 할려고 해도 자기돈으로 하는 사업이 아니니 리얼월드가 아닌점은 사실이구요. 하지만 노력을 많이 가하고 있다는 점을 알아 주셨으면 합니다.)

기술을 학습하기 위해 억지로 만든 프로젝트가 아닌.  사용자에게 줄수 있는 핵심 가치(우리 프로젝트의 가치)가 무엇이고, 그걸 어떻게 찾아가는지에 대해서 많은 협의및 고민을 합니다. SK 컴즈 CEO 셨던 주형철 부학장님이나, 저와 많은 코웍을 하시는 장선진 멘토님에게  전혀 다른 두가지 입장 (거대한 기업을 이끌었던 경험과,  스타트업에서 정말 얻는 고충)들을 곁에서 많으 조언과 코치를 받았습니다.

평가 시즌을 거치면서 우리가 만든 소프트웨어의 가치는 무엇이고, 이 가치를 팀원 모두가 잘 공유하고 있고, 이게 프로젝트가 끝날때 까지 잘 유지되어서, 핵심 가치를 잘 전달할수 있는 소프트웨어가 될수 있을까? 에 대한 고민을 가지게 되었고, 결국 상품기획, 개발자, 디자이너 성향을 가진 종합 예술인(?) 분을 모셔서 어렵게 코칭을 받았습니다.

그 과정을 어떻게 하나 하나 진행했는지를 이번 포스트에서 공유하고자 합니다. 소마에 과정의 예산으로 한 것이라, 당연히 외부에 공유가 되어야 할거고, 지금 NHNNEXT 학생들도 이 주제에 대해서 크게 고민을 하고 있을거 같아 적어 봅니다.

계속 읽기

조엘 온 소프트웨어에 나온 하나의 글이 돌아다니기에 생각을 적어봅니다. 정말 오랜만에 개인의 생각을  적어본 글이네요…

더 나은 코딩을 만들기 위한 12단계 라는 주제로 아래와 같은 지침을 제시하고 있습니다.

  • Source Control(소스 컨트롤)을 사용하십니까?
  • 한번에 빌드를 만들어낼 수 있습니까?
  • daily build(일별 빌드)를 만드십니까?
  • 버그 데이타베이스를 가지고 있습니까?
  • 새로운 코드를 작성하기 전에 버그들을 잡습니까?
  • up-to-date(최신) 스케줄을 가지고 있습니까?
  • spec(설계서)를 가지고 있습니까?
  • 프로그래머들이 조용한 작업환경을 가지고 있습니까?
  • 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
  • 테스터들을 고용하고 있습니까?
  • 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
  • hallway usability testing(무작위 사용성 테스팅)을 하십니까?

계속 읽기

지앤선에서 진행한 “아키텍트가 알아야 할 97가지 Face 2 Face ” 행사가 성공적으로 마쳤습니다. 독자들과 한발짝 다가가서 더 많은 이야기를 나눌수 있어서 좋았습니다. 아래와 같은 주제들을 60분간 나누었습니다. 소프트웨어 아키텍트가 알아야 할 97가지 어떤 책인가? 아키텍트는 신기술에 대한 이해가 필수적인데 어떻게 기술을 접하고 있나요 국내에서 아키텍트가 되는 법 아키텍트는 코딩을 잘 해야 한다. 기획자로 일하는 것이 […]

아실 분은 아시겠지만, 저랑 저희 스터디에 김지원 군이 PLoP을 이끄는 Hillside Group의 이사회 위원으로 2012년 부터 합류하게 되었습니다.
Hillside-logo

PLoP을 다닌지 5년만에 되었네요.  아시아 학회의 공동 의장이기도 하지만, 이로서 더 넓은 영향력을 얻게 되었습니다.

계속 읽기

첫번째 세션인데도 불구하고, 많은 분들이 서서 들으실 정도로 참여해 주셔서 정말 감사합니다 . 많은 분들에게 도움이 되길 바라구요. 슬라이드 쉐어에 공유를 해 놓았고,  pptx를 다운 받으실 수 있게 해 놓았습니다. 이번 발표에는 다음과  같은 내용을 다루었습니다 오픈소스의 역사및 현재 이야기 라이센스 변화에 따른 에셋으로써 오픈소스 안드로이드의 로그 문제 해결 – Logdog  구현 이야기   오픈소스 […]

여러분과 함께 소프트웨어 아키텍트가 알아야 할 97가지의 역자로써 만남을 가지고자 합니다. 시간: 2월 28일 수요일 오후 9시 부터 ~ 10시(?) 이구요  준비물 : 마이크랑 화상 캠이 필요합니다.  등록하는 곳 : 지앤선 이벤트 페이지   이 행사는 위 책의 출판사인 지앤선에서 야심차게 준비하는 프로젝트입니다. 가능한 지방에 있는 분들과 좀더 소통을 하고, 추후 고등학생들과 같이 꿈나무들과 이야기를 나누는 […]