'한국 소프트웨어 아키텍트 대회'에 해당되는 글 2건

허니몬의 IT 이야기/아키텍트, 'SW건축가'를 꿈꾸다

  지난 '2010년 한국 소프트웨어 아키텍트 대회'를 참가한 이후 2년만에 다시 대회를 찾았다.

  >> 2010/07/18 - [허니몬의 IT 이야기/IT 트랜드] - 허니몬, 2010 한국 소프트웨어 아키텍트 대회를 다녀오다.

  오늘은 아무런 준비없이 휴가를 쓴 날이었다. 그런데 휴가를 내고보니, 이 날에 아키텍트 대회가 있다는 이야기가 들려왔다. 아는 분에게 부탁드려서 무료참관 신청을 하고 수요일 아침 코엑스를 향했다. 코엑스에는 평일 이른 시간이었음에도 출근하는 직장은 외에도 많은 사람들이 있었다. 아직 우리나라에는 아키텍트 역할이 제대로 인정받고 있지 못하다. 그런 힘든 상황 속에서도 SW 아키텍트로서 다양한 경험을 공유하려고 하는 이런 대회는 참 좋다.

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:07:18 10:20:09


Architect!
Your Role, Our Future.

IT쪽에서 크게 관심을 기울이고 있는 몇가지가 있다.
* 생산성(여기서는 생산성보다는 관리적인 측면이 강하다)
    * 프로젝트에서 발생하는 위험(리스크)을 줄이고
    * 프로젝트를 관리하기 유용한 형태로 가고 있다.
* 빅데이터
* 클라우드 컴퓨팅
* 모바일 서비스


1. 통합된 개발환경 기반 어프리케이션 관리체계

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/20sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:07:18 09:37:43

  • 발표자 : 삼성SDS 김영신 수석보
  • 통합된 개발환경은 소프트웨어 개발 라이프사이클 전체를 지원하는 툴과 가이드를 통합하여 개발관리를 Seamless하게 할 수 있는 개발환경
    • 개발 라이프사이클 : 분석 -> 설계 -> 개발 -=–0 운영관리
  • 개발산출물
    • 개발자가 생산한 개발산출물에 대한 시스템 검증없이 구두 또는 테스트의 결과를 중심으로 공정, 진척, 품질관리ㅡㄹㄹ 수행
    • 관련자 : 개발자(납기), 고객(진척률, 이슈/위험), PM/PL(진척률, 결함, 이슈/위험, 공수), 아키텍트/품질담당
    • 개발자의 머리에 손을 얹고 ‘나는 너를 믿는다’ 라…
  • 아키텍처 구성방안
    • 개발환경은 복잡해짐
    • 단순한 툴 조합만으로는 개발생산성이 나지 않음
    • 개발생산성을 극대화 하려면 실행환경 구조, 개발환경, 관리환경을 Set화 하여 구성
      • 코딩 산출물(프로그램 소스코드)
      • 실행환경 구조(실행환경 구조, Runtime architecture)
      • 개발환경(IDE/형상관리/빌드/코드품질(PMD)/테스트/이관)
      • 관리환경(진척/결함/이슈 관리)
    • 아키텍트는 프로젝트에서 사용하는 다양한 솔루션들을 조합하여 개발에 최적화된 환경을 제공할 수 있도록 해야한다.
    • 관리툴이 연계가 잘 되어 있을 경우 시스템 오류가 생겼을 경우, 이것을 해결할 수 있는 손쉬운 방법들이 생겨난다.
    • 실행환경 구조를 얼마나 잘 잡았느냐에 따라서 손쉬워진다.
      • 실행환경 구조
      • 개발환경
      • 관리환경
      • 위의 세가지를 하나로 엮는다(발표자는 ’set화’라고 지칭 ).
  • 개발환경 set화
    • Set화된 개발환경이란 공공, 금융 등 프로젝트에 동일하게 활용하는 실행, 개발, 관리환경의 툴, 가이드, 설정을 포함하여 설치 및 커스터마이징을 최소화한 개발환경 패키지이며 상호호환 가능
      • 프로젝트의 성격에 따라서 필요한 솔루션들을 종합하는 작업이 필요하다.
  • 구성방안
    • 개발단계시 활용하는 Runtime, 개발자동화툴, 형상관리툴, 빌드툴, 인스펙션툴, 테스트툴, 운영이관 및 실물기반 관리기능이 연계되어 개발산출물 전체의 라이프 사이클을 통제, 관리하도록 구성
    • 개발환경에 맞춰서 최적화 하는 것이 중요하군.
    • 어플리케이션 실행환경 구성
      • Broker, Controller
        • TimeStamp
        • Application Error
        • Regression Test
        • Test Pass rate
        • Application Monitoring
      • Dao
        • Query Monitoring
      • 좋은부모 인생시스템이라…
    • 애플리케이션 개발환경 구성
      • 검수자(개발서버)
      • 개발자(개발PC)
      • 관리자(관리서버)
      • 아키텍트, 테스터 운영자(관리서버)
    • 현재 회사에서는 이와 같은 개발환경을 구축하과 관리할 수 있는 능력을 가진 사람이 없다. 그게 좀 큰 약점으로 적용된다.
    • 개발자가 작성한 코드가 주석인지 실제로 동작하는 코드인지 관찰한다라…
    • 실물기반 진척관리를 위한 관리체계 구성 예시
      • 서버환경
      • 개발툴
        • 개발IDE툴 -> 형상관리툴 -> 빌드툴 -> 인스펙션툴 -> 테스트툴 -> 이관툴
      • 실물자동 점검툴과 연계한 관리환경
      • 진척관리 절차
  • 적용사례
    • OO기관 구축 사업에 통합된 개발환경 기반 관리체계를 적용하여 소스코드 자동화율 증대, 구축 시간 단축, 실시간 실물기반 관리로 관리효율을 높였음
      • 관리효율을 높이는 것에 중점을 두고 있는 것인가?
      • 개발자가 많고, 생산되는 소스코드가 많을수록 통제하는 것이 좋다는 경험담
        • 그렇게했을 때 ’아키텍트’가 관리하기가 좋다.
      • LOC(코드라인수) 이 감소하는 효과가 있었다.
        • 개발환경을 통제하는 것이 개발효율을 높일 수 있다…로 정리될까
    • 아키텍트가 ’좋은 구조’를 잡아준다면 개발자들에게서도 호응을 얻을 수 있게 된다.
    • 실물자동점검을 위한 판정 기준
  • ‘좋은부모 시스템’
    • 품질, 관리
    • Risk
    • 중요도
  • 개발환경의 통합


이 발표는 주로 아키텍트의 '관리'에 특면에서 많은 내용이 발표되었다. 아키텍트는 '개발자'의 '최종진화'판이라고 생각한다. 프로젝트 내에서 발생하는 소프트웨어적으로 어려운 난제들을 해결하는 것을 주업으로 하는 '해결사'라고 생각해왔다. 그런데 국내 아키텍트들의 활동을 가만히 살펴보면 '관리자'의 역할이 더 강렬하게 수행하게 되는 것으로 보인다. 




2. Mobile-centric HTML5 어플리케이션 개발 및 아키텍처

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:07:18 10:21:08

  • 발표자 : SK텔레콤 IT 기술원 조문옥 Manager

  • 모바일 중심의 서비스 환경
    • 인터넷 연결 단말의 폭발적인 증가
    • 배경지식(Background-knowlege) 전달이 너무 길면 곤란해.
    • 타겟팅을 잘못했어.
    • 서비스 환경이 빠르게 모바일 중심으로 변경되어 가고 있다.
    • 서비스를 제공하게 될 때 고려해야할 것들이 더욱 많아지게 된다.
  • 모바일 애플리케이션 개발 및 아키텍처
    • 환경은 급변할 것이다. 그것에 미리 대비하여 준비해두는 것이 좋다.
    • 모바일 애플리케이션 특징
      • 모바일기기(스마트 단말, 스마트폰) 특징
        • 리소스 제약 : 크기의 제약으로 인해 화면 및 CPU 메모리, 디스 용량 등 리소스의 한계
        • 네트워크 제약 : 이동을 전제로 하는 무선 네트워크의 특성상 지속적 연결성을 보장하지 못함
        • 다양한 I/O
        • OS 및 기기의 다양성
      • 모바일 애플리케이션 개발시 고려사항
        • 표현계층 : 간단하면서 직관적, 유연함(화면)
        • 서비스계층 : 서비스지향, 적은연결, 멀티스레딩
        • 기타 : 플랫폼 의존성, 리소스 핸들링, 소형화(경량화)
          • 리소스 자원의 관리가 필요하다.
          • 애플리케이션의 크기를 줄이고, 필요한 데이터를 백그라운드에서 다운로드 받도록 조치하는 방법이 있다.
      • 모바일의 변화가 심하다
        • 하이브리드를 가는 것은 좋지 않다?
          • 고객에게 빠르게 지원하기 위해서
        • 네이티브앱을 개발하다가, HTML5가 정착되면 그때 웹으로 간다.
    • 모바일 애플리케이션 개발환경
      • 네이티브앱 개발환경
        • 장점 : 성능, 단말기 리소스 접근 등
      • 하이브리드앱 개발환경
        • 생산성, 유지보수 등
  • HTML5의 등장과 모바일 환경의 변화
    • 모바일 중심의 서비스 환경에 대응할 수 있는 차세대 웹기술의 등장
    • 인터넷의 성장에 따라서, 기존의 애플리케이션 기술이 웹기술쪽으로 이동하게 될 것이다.
    • Web Application 개발 환경의 변화
      • Web Application
        • Client-Side 개발
        • Server-Side 개발
      • Node.js
      • ‘HTML, JavaScript로 통합될 가능성이 있다.’’ 라는 전제를 깔고 있군.
    • Mobile-Centric 어플리케이션이란?
      • 다양한 모바일 기기들의 N-Screen 서비스 지원
      • 다양한 서비스에 대한 실시간 제공 및 Auto-Invoation
      • 상황에 따라 적절한 리소스 할당 및 확장성
      • * 다양한 단말 및 서비스 환경에 기민하게 반응할 수 있도록 HTML5와 JavaScript 기반으로 개발된 애플리케이션 *
      • 그래서? 어떻게 하면 그렇게 기민하게 반응할 수 있는 애플리케이션을 만들 수가 있지?
  • 모바일 중심 어플리케이션 개발 및 아키텍처
    • Runtime : HTML5 Runtime 엔진(브라우저 장착)
    • Clinet-Side 프레임워크
      • jQuery
        • Backbone.js : 자바스크립트의 MVC 아키텍처 패턴 지원
        • Require.js : 자바스크립트의 모뷸화, Lazy Loading 지원
    • Server-Side 프레임워크
      • Node.js
        • Express, Jade : 웹 개발 MVC프레임워크, View 템플릿 엔진
        • Socket.io : 웹소켓 등 실시간 웹 프레임워크
        • node-mysql : MySQL 클리아언트와 Connection Pool 제공
        • node-pool
        • node-MongDb
  • 의견정리
    • 가능하면 발표자료와 제공되는 자료의 이원화 관리도 필요할 것 같다.
    • 발표의 비중을 잘못뒀어.
    • 결국 이 발표에서 중요한 것은 모바일 중심 어플리케이션 개발 및 아키텍처인 것인데…


3. No-SQL DB를 활용한 대용량 LOG 분석 및 아키텍처

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/12sec | F/2.6 | 0.00 EV | 3.5mm | ISO-640 | Flash did not fire | 2012:07:18 11:33:13

  • 발표자 : 삼성SDS 엄재형 책임

  • anyframe-logmanager-pi.1.0.1

  • Bic Data 는 상대적임

  • NoSQL 은 ‘상대적으로’ 저렴한 비용으로 이러한 대용량 데이터를 처리하기 위해 고안된 Database의 일종

  • 로그데이터 처리를 위해서 NoSQL을 고려해야하는 이유
    • 입출력 속도가 빠르다?
  • NoSQL 종류
    • MongoDB
      • 다른 NoSQL Database 에서 제공하지 않는 기능들을 제공
        • 인덱스?
    • CouchDB
    • Cassandra
    • HBase
  • MongoDB
    • MongoDB 는 10gen 에서 개발한 NoSQL DB 제품의 한종류(Humongous)
    • APGL 3.0 라이센스 사용
    • 대형 업체에서 서비스하려고 하는 경우 제약사항이 발생
  • MongoDB is Fantastic for Logging
    • 입력이 비동기식으로 동작
    • 오래된 로그 데이터는 자동으로 LRU’s out : 과거데이터가 삭제된다.
    • Document-oriented(XML 과 같이 구조화 되어 있어서 문서자체를 저장하는 방식) / JSON 은 로그 정보를 위한 훌륭한 구조야?
    • Log4mongo
  • 로그 수집시 고려사항
    • 로그 수집
      • 직접 수집 : log4.xml -> append 처리
      • 배치 수집
    • 로그의 저장(=mongoDB 의 구성)
      • 환경구성
        • 싱글 노드/ 멀티노드
        • replica set
    • 정책의 관리
      • 로그 레벨의 (동적) 변경
      • (동적) Appender 추가
      • 변경사항의 중단없는 반영
      • 로그정책의 통합관리(분산되어 있는 로그시스템의 통일)
    • 데이터의 검색
      • matched 검색
      • range 검색
      • 순차검색
      • 검색항목
      • 어떻게 보여줄 것인가?
    • Enterprise Environment 대용량 환경에 적용할 때 고려할 사항
      • 클러스터링
      • 원격서버
  • Idea~
    • 고려사항을 해결하기 위한 오픈소스 해결방법 ->
    • Issue -> Open Source Technology -> Log Manager Feature
    • 로그 수집
      • 직접 수집 : log4.xml -> append 처리 : log4mongo
      • 배치 수집 : osgi / apache felix
    • 로그의 저장(=mongoDB 의 구성)
      • 환경구성
        • 싱글 노드/ 멀티노드
        • replica set
    • 정책의 관리
      • 로그 레벨의 (동적) 변경
      • (동적) Appender 추가
      • 변경사항의 중단없는 반영
      • 로그정책의 통합관리(분산되어 있는 로그시스템의 통일)
      • hessian, servletfilter, log4j api
    • 데이터의 검색
      • matched 검색
      • range 검색
      • 순차검색
      • 검색항목
      • 어떻게 보여줄 것인가?
    • Enterprise Environment 대용량 환경에 적용할 때 고려할 사항
      • 클러스터링
      • 원격서버
  • 해결방안 : LogManager
    • Apache 라이센스를 사용하는 오픈소스 로그관리도구
    • MongoDB를 Log Repository로 활용
    • OSGI 기반의 Agent Service 제공
    • Jetty 기반의 웹관리모듈 제공(별도의 WAS 불필요)
    • jQuery 기반으로 Ajax Web UI
    • 다양한 검색옵션 제공
    • 간단한 사용자 관리 기능으로 로그 접근권한 분리
  • LogManager Senario
    • 직접수집
    • 배치수집
  • Anyframe 쪽에서 확인 가능
    • WAS의 재가동 없이 로그 적용가능
  • Log Agent Service
    • OSGi - Apach felix
    • Log Agent 관리
    • Log Application 관리
      • Log Policy Editor
    • 계정 관리
  • Technology Stack
    • 기술적 종속관계를 통해 확인
    • 대부분 Java를 기반으로 구성되어 있다.
  • 오픈소스 라이선스의 로그관리 도구
    • 로그를 빅데이터 관점에서 접근하여 NoSQL 제품과 접목한 오픈소스 형태의 로그 관리도구
    • 자체로서 완결된 서비스를 제공하기 보다는 현장에서 보다 쉽게 응용하여 사용할 수 있도록 편의를 제공하는 것이 목적
  • 발전방향
    • 로그 프레임워크의 범위 확장 :Log back
    • NoSQL DB 추가 : 인터페이스표준화
    • 성능 최적화
    • 기능 최적화
    • 분석도구 제공
  • 프로젝트 : http://www.anyframejava.org/project/logmanager

  • JIRA : http://dev.anyframejava.org/jira

  • 개인의견
    • UI 에서 Agent를 관리하는 기술이 참 부럽군.
    • 저장된 로그를 필터링하여 관리하는 부분은 LogManager 사용자의 영역이로구나.
    • 우리 회사에서도 고려하고 있는 사항인데, 중요한 것은 이렇게 기록된 정보를 어떻게 가공하느냐…
    • 결국 빅데이터는… 그 방대한 데이터를 ‘어떻게 사용하느냐?’ 라는 사용방식의 차이가 그 효율성을 결정짓게 되는 것이다.


4. 프로젝트 유형별 어플리케이션 플랫폼 구축 전략


  • 발표자 : 삼성SDS 백창현 수석
  • 프로젝트의 특징에 대한 명확한 분석이 필요하다는 거지.
  • SI 프로젝트 기반 시스템 개발
  • Eclipse 기반
  • 배치 스케줄러 개발
    • 배치 스케줄러 시스템
    • 배치 스케줄러 구성요소
      • Schedule Admin
      • Schedule Agent
    • Hadoop Zookeeper
    • 일정을 어떻게 관리할 것인가
    • 요구사항을 정확하게 분석해야한다.
    • 설계 요소
      • 작업 일정과 개별 실행 작업 인스턴스의 관리
      • 쉽고 간편한 웹기반의 UI
      • 멀티 에이전트 관리
      • 스케줄러 어드민 이중화
      • 웹크롤링 스케줄러 에이전트를 다시 만들어볼까나.
    • Smart GWT
    • 프로젝트 성격
      • 개발목표
      • 개발형태
      • 요구사항 명확도
      • 도입기술
      • 기술적 난이도
      • 비용확정
      • 핵심이슈
      • 리스크
      • 아키텍트 역할
      • 프로젝트 기간
    • 프로젝트의 핵심요소들을 파악하여 어떻게 할 것인지 확인
  • 프로젝트 유형별 어플리케이션 플랫폼 구축전략 - 프로젝트 성격 분석 - 개발목표 - 개발형태 - 요구사항 명확도 - 도입기술 - 기술적 난이도 - 비용확정 - 핵심이슈 - 리스크 - 아키텍트 역할 - 고가용성 구조 정의, 핵심클래스 데이터 모델 정의 - 프로젝트 기간
  • 유형별 비교
    • 금융 SI 시스템 개발
      • 금융시스템 개발의 소프트웨어 아키텍처 및 기술 기반 구축
      • 프레임워크 도입 후 커스터마이징
      • 매우 명확함
      • 높음(표준, 규격)
      • 프로젝트 구축일정에 따라 M/M 투입
    • 시각적 로직 명세 툴 개발
      • SI 개발 지원을 위한 프로그램 상세 설계/명세 툴 개발
      • 제품 기획 후 아웃소싱 발주 수행
      • 불명확
    • 배치 스케줄러 개발
  • 정리
    • 프로젝트 유형별 상이한 어플리케이션 구축 방향
      • 프로젝트 유형별로 다채로운 아키텍트의 역할
    • 프로젝트에서의 아키텍트의 미션 : 제품과 시스템의 완성
      • 어떤 경우든, 아키텍트는 상황에 따른 중요한 설계 방향의 의사결정을 내리며,
      • 제품과 시스템의 완성 책임을 지는 존재
    • 매트릭스의 아키텍트
    • 아키텍트는 프로젝트안의 세계를 창조하고 관리하고 책임지는 존재


  5. 클라우드 컴퓨팅 아키텍처 사례

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:07:18 13:58:11

  • 발표자 : 삼성SDS 정유선 책임
  • ** Cloud Provider 의 입장에서 **
  • 클라우드 컴퓨팅 개요
    • 클라우드 컴퓨팅
    • 비즈니스 요구사항
      • Cloud Provider
        • TCO, ROI
        • Business Value
      • Cloud Consumer
      • 클라우드 서비스 제공자와 사용자의 두가지 관점에서 고려해야 한다.
    • Scope of Control
    • Available Service on Cloud, Cloud Computing Service model
      • PaaS
      • SaaS _ IaaS
  • 클라우드 참조 아키텍처
    1. 클라우드 참조 아키텍처
      • Cloud Provider - Service Orchestration
        • Service Orchestration 이 뭐야?
      • Cloud Computing Reference Architecture
        • Cloud Consumer
        • Cloud Provider
        • Cloud Broker
        • Cloud Auditor
        • Cloud Carrier
  • 오픈소스 클라우드 플랫폼
    • OpenStack
    • CloudFoundry
      • 사이트 : http://www.cloudfoundry.com/
      • PaaS
      • 3가지 모델로 설명
        • Cloud Provider Interface
      • Messaging Bus를 이용하여 각 계층별로 요청 처리
      • Service gateway <-> Cloud Controoler
    • BOSH
      • 우분투 진영만 지원
  • 아키텍쳐 패턴
    • Event-driven
    • Asynchronous
    • Independent
    • Shared-nothing
    • 공통 : Messaging bus
  • 정리
    1. 오픈소스 클라우드 플랫폼의 활용
      • 사내 private cloud 구축
      • Cloud 환겨에 대한 이해
      • IaaS 또는 PaaS 구축
      • 오픈소스 기술 지원 : 소스를 열어보고 그것을 이해하는 노력이 필요하다.
      • Trouble Shooting of Challenge
        • VM 시스템의 속도가 떨어진다.
    2. Cloud Migration
      • 물리적 환경의 일반적인 N-Tier 아키텍처
      • 클라우드 환경에서는 클러스터링이 어려운 문제다.
        • Memory tier를 분리하여 Session replication 및 객체 캐시를 통해 부하를 분산시켜 목적에 맞게 DB 선택
      • Message passing 을 통해 동작을 제어
    3. 제언
      • 전체 그림은 크게 그리고, 시작은 작게 천천히 시작하라.


  6. Fleible UI Reference method with Open Architecture

LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/15sec | F/2.6 | 0.00 EV | 3.5mm | ISO-250 | Flash did not fire | 2012:07:18 15:05:05

  • 발표자 : 삼성전자 황기영 책임

  • 초반 컨셉만 이해해도 성공한 것이다!!

  • 논문을 읽다가 아이디어를 얻어서, 그것을 정형화하다가 결과를 얻었다.

  • API Document
    • Library 의 사용시 일반적으로 API를 접근하기 위하여 Document를 분석하여 접근
    • API활용을 위한 일반적 구성요소
      • Method name or Interface name
      • Input data
      • Return data or Result
    • API가 너무 많다. 원하는 것을 확인하기 위해서는 샘플을 확인하고 필요에 따라서 API를 확인한다. 돌아가는 것을 먼저 확인한다.
    • 우리는 언어를 만드는 사람이 아니라, 만들어진 프로그래밍 언어를 이용해서 가치를 만드는 사람이다.
    • API를 어떻게 만드는 것이 좋을까?
  • Black box Approach
    • 기본 component 가 존재하는 상황에서 이를 활용하여 개발하는 개발자는 API의 활용시 컴포넌트의 결과값을 받는 기본적 절차
    • API Document 이해를 통한 Interface의 접근이 아닌 UI를 직접보고 API를 재사용할 수 있는 방법은 없을까?
  • Change our way of thinking
     논리적인 방법을 UI 행동방식으로 전환한다.
    
    • Change the concept from logical way to UI behavior way
      • 기존의 API 접근 방법을 UI화면에서의 사용자 동작으로 바꾸어 생각해본다면?
    • 기존 UI화면에서 item이 존재한다면 item을 선택하는 것은 interface에 input값을 보내기 위한 UI에서 동작

    • 선택 후 OK버튼을 누른다는 것은 Interface를 호출한다는 것

    • 최종화면은 이미 UI가 포함된 전체화면을 받는다는 것

    • Logical way(from Business layer)

    • UI behavior way(from Presentation layer)

  • OSGi Architecture
    • 구체적 적용 방안 설명을 위해 실제 구현 환경을 바탕으로 설명
  • UI Architecture Layout
    • 확장이 가능한 UI 영역을 선언
    • 확장점(Extension point) : 사용가능한 API 영역
      • UI의 특정부분은 다른 번들이 재사용하는 것을 허락하도록 오픈 플랫폼에 등록하게 된다. 이를 확장포인트(Extension point)라고 한다.
      • 외부에서 Injection이 가능하다. -> 새로운 기능을 추가할 수 있다.
  • 사용자 관점의 동작원리
    • 확장가능한 UI영역을 선언
      • 시스템을 사용하는 사용자는 자신이 추가 및 확장하고자 하는 Bundle 을 Plug & Play 형식으로 원하는 기능을 확장할 수 있다.
      • 사용자는 어떻게 실행이 되고 있는지 정확하게 알 수는 없다. 알 필요가 없지.
  • 실사례 동작 구성
    • 원래 번들은 자신의 UI화면을 가지고 있으며 이를 사용하여 주요기능을 사용하고 있다. 이러한 화면에서 추가 번들의 설치와 동시에 원래 번들의 화면에 수정및 변경을 가능하게 해준다.
  • 시스템 관점의 동작원리
    • 주요 번들 간의 확장UI를 작동시키기 위하여 목표가 되는 대상은 3가지의 주목표가 존재한다.
  • Open platform with OSGi
    • Open Platform 영역은 기존의 OSGi의 환경에 번들이 연결되기 전에 공통된 영역이나 UI를 관리하기 위한 Controller로 구성 > 주요 4개 영역으로 구성
    • 치사하게 소스를 공개하지 않고 API만 제공한다.
    • Common Library
    • AAA Controller
    • Debug/Logging
    • UI Layout controller
  • Usaual Architecture

  • Architecture for UI Extension Reference
    • 표현계층에서
    • 페이지 영역에서 컨트롤러로 동작 제어
  • 핵심구성요소
    • 확장점(Extension Point)
      • 확장이 가능한 지점으로 부터 타 OSGi 번들이 Injection을 허락하는 지점
    • 동작점(Action Point)
      • 확장점을 클릭했을 때
      • 특정 Action이 발생하였을 경우 확장점에서 UI가 해주어야 할 내용 정보
    • 설정정보(Configuration information)
      • 확장된 UI를 화면에 Display 해줄 때 어떠한 Text나 Icon 등으로 확장해줄 것인가를 선언해주는 부분
    • XML은 컴파일할 때 오류가 나지 않고, 런타임때 오류가 발생한다.
  • 결론
    • UI 계층을 통한 API의 활용
    • UI 계층에서 Injection 가능
    • UI 계층에서 기능의 확장화 = API의 재사용
    • 개발의 편리화, 빠른 개발화
    • 표준화된 커뮤니케이션 제공
    • 유지보수의 편리성 제공
    • 제품의 품질 향상
  • 예시
    • 기업은행
      • 솔루션을 제공한다.
      • 중소기업(3rd party)은 솔루션을 이용해서 쓰면 된다.
      • 결국 자신들에게 상속시킨다. 한정시킨다.
      • 사례 : Open Platform
        • 4만대 판매
        • 사례제공을 통해서 고객을 설득해야한다.
        • 우리쪽 장치만 사용가능하다.
        • 유지보수도 우리가 한다.



LG Electronics | LG-LU6500 | Not defined | Center-weighted average | 1/13sec | F/2.6 | 0.00 EV | 3.5mm | ISO-320 | Flash did not fire | 2012:07:18 14:31:22



저작자 표시
신고
0 0
허니몬의 IT 이야기/IT 트랜드
  올해로 3번째인 한국 소프트웨어 아키텍트 대회를 다녀왔다.


  금요일 오전 8시 30분부터 시작해서 6시까지 끝나는 장기간의 발표대회이기도 했고, 40개의 주제를 가지고 4개의 트랙에서 동시에 진행되는 큰 규모로서, 주제는

  • Track 1 : 비즈니스와 SW(SW Architecture in Business)
  • Track 2 : 아키텍처와 오픈소스 활용
  • Track 3 : 엔터프라이즈 모바일 아키텍처 & 클라우드 컴퓨팅
  • Track 4 : 엔터프라이즈 SW 아키텍처

 의 큰분류를 바탕으로 해서 각 발표자가 40분의 발표시간을 가지고 발표하는 형식으로 진행이 되었다. 대부분의 발표자들의 40분의 시간보다 많은 발표자료를 준비해오는 덕분에 대부분이 40분을 넘기는 경우가 많았다. 40분을 넘기는 경우가 자주 있어서 원하는 트랙을 찾아 이동하다보면, 이미 발표를 시작하고 있는 경우도 심심찮게 목격할 수 있었다. 발표와 발표사이에 5분 정도의 시간적인 여유를 두어서 참관자들이 이동할 수 있고, 발표자들이 발표를 준비할 수 있는 시간적인 여유를 주었으면 어땠을까 하는 아쉬운 생각도 든다.


  대회가 진행된 곳은 삼성동 Coex Conference Room 307A, B, 308A, 308B 지역이었다. 각 방에서 Track 1, Track 2, Track 3, Track4 가 진행이 되는 방식이었다. 대회는 15일 시작되어 있었지만, 내가 듣고 싶은 주제들이 16일에 발표되었기 때문에 16일 9시 30분에 맞추어 현장에 도착했다.

  우리나라의 '코리아 타임' 때문인지 30분이 되었는데도 발표는 시작되지 않았다. 10여분의 시간이 흐른뒤에서야 발표가 시작되었다. 처음 발표하는 발표자의 시간이 10분 지체되는 상황이 벌어졌다.


  첫번째 발표는'Agile 개발실 - 자부심, 행복감 그리고 놀라운 결과'라는 주제로 넥스트리소프트의 김동열 팀장님이 발표했다. 약간 시간에 좇길 수밖에 없는 상황이어서 발표는 조금 빠르게 진행되었다. 그래도 처음 발표자로서 처음 스타트는 잘 끊어주신 편이었다. 우리나라에서 애자일과 XP 등의 개발방법론에 대한 관심이 조금씩 일어나고 있는 상황 속에서, 아키텍트들은 이런 새로운 개발방법론을 아키텍쳐에 어떻게 적용할지를 고민하는 이들이 많은 것이 사실이다. XP 그룹이나 KSUG 등에서도 많은 개발자들 사이에서 오고가는 이야기들이 대부분 그런 이야기들이기도 하다.
me2photo


  두번째 발표는 '전자정부 2.0을 위한 아키텍쳐(공공 정보자원 공유 인프라 구축을 위한 아키텍처"라는 주제로 기술문화연구소의 류한석 소장님이 발표를 하셨다. 지난 안드로이드와 관련된 세미나에서 뵈었던 친숙한 얼굴이기도 하다. ^^; 하지만 그 분은 나를 잘 모를테지만, 발표를 들은 후 날린 트윗에 '피드백 고맙다'는 답을 주시는 것을 잊지 않으신다. 우리나라 정부는 전자정부 프레임워크를 발표하기도 했으며, 전자정부2.0 이라 하여 '공개할 수 있는 정보는 공개한다'는 주제 아래 정부가 가지고 있는 정보들을 API 형태로 개발자들에게 제공할 준비를 하고 있다. 정부가 API를 제공하면 Volunteer(봉사자) 개발자들이 나서서 그 API를 이용하여 여러가지 웹서비스를 제공하는 것이 정착된 미국과 호주와는 달리, 우리나라는 지난 참여정부 시대 이후, 사라진 정보통신부와 IT에 대한 무관심 속에서 개발자들은 정부에 대한 불신을 품고 있다. 인터넷과 연결된 많은 개발자들이 Anti MB 정신을 내걸고 있다고 봐도 될 것이다.
me2photo
 '4대강 사업 집중'에 따른 국가예산이 대부분이 국토해양부와 한국수자원공사로 편중되는 현상이 발생하면서, 전 정부에서 주도하던 다양한 정보화 사업이 도중하차하는 상황이 벌어졌다. 우리나라는 정부에서 주도적으로 IT 사업을 육성하기 위하여 정부에서 주도적으로, 행정정보화를 추진하여왔다. 그 덕분에 우리나라는 행정 전산화에 있어서 국제적으로 상위권을 유지하고 있지만, 그것은 어디까지나 전 정부에서 집중투자한 덕분이지, 현재 정부에서는 현재 진행되는 행정정보화 사업을 유지하는 것도 벅차보이는 것이 현실이다.
  류한석 소장은 전자정부 2.0이 성공하기 위해서는 '신뢰'가 구축되어야 한다고 이야기 했다. 문득....
신뢰소셜미디어시대의성공키워드
카테고리 경제/경영 > 경영전략 > e-비즈니스일반
지은이 크리스 브로건 (에이콘출판, 2010년)
상세보기
라는 책이 생각났다. 현 정부에 들어, 국민들은 정부를 불신하기 시작했다. 너무나 많은 사건들이 터졌고, 그 사건들을 수습하는 과정에서 전혀 수긍할 수 없는 헷소리를 지껄이는 정부를 누가 믿을 수 있겠는가... 국가와 국민이 신뢰를 쌓을 수 있는 시기는 다음 정부때로 넘어가야할 것으로 보인다. 이렇게 글을 쓰면서... ㅡ_-);; 이 글이 감시받고 있을지도 모르겠다는 생각... 들지만, 정부의 인력으로는 나같은 변두리 개발자까지 신경쓸 여력은 없다는 것이 개인적인 판단이다. 
me2photo
소통은 서로의 '신뢰'를 쌓는 방법 중 하나다. 하지만, 그 소통이 꽈악 막힌 현 상황에서 정부와 국민들의 소통과 이를 통한 '신뢰 구축'은 요원해보인다.



  세번째 발표는, '아키텍트, 오픈소스 Spring Framework에 길을 묻다"라는 주제로 아이티와이즈 컨설팅의 조만희 컨설턴트가 발표했다. 최근 Java 6 EE가 발표되었다(라지만 몇개월 된 것으로 기억한다. ^^;;). Enterprise 환경을 위한(나는 기업 업무와 관련된 전반적인 비즈니스 로직 처리 환경이라고 정의했음...) 각 벤더사들의 요구사항을 집어넣다 보니 EJB의 스펙은 너무 광대해졌다. 그 안에 담겨있는 스펙들에 아키텍트를 비롯한 컨설턴트들은 거대한 파도에 집어 삼켜졌다. 그렇게 파도에 삼켜진 표류자들을 구한 구원의 손길이 있었으니, 그것이 'Spring Framework'라는 식의 결론이랄까? ^^;
me2photo
확실히 이번 발표대회에서는 Spring Framework 와 오픈소스에 대한 관심이 높아진 것으로 보인다. 이와 관련해서 신경써야할 것은 License이다. 대부분의 오픈소스들은 License를 강력하게 따르기를 원한다. 특히나 오픈소스가 그렇다. 지난번 한국 오픈소스 소프트웨어 개발대회 기술세미나에서도이 점에 대해서 귀에 딱지가 들어앉을 만큼 반복적으로 말했다. 이는 앞으로 더욱 중대한 문제가 될 것으로 보인다.
me2photo
현재 많은 기업들이 스프링 프레임워크 등의 오픈소스를 바탕으로 해서 자사의 프레임워크를 개발해낸다. 그러면서 자사만의 고유한 프레임워크라고 선전하면서 계약비를 높이는 용도로 사용한다. 하지만, 살짝만 파고들어보아도 오픈소스 라이센스를 위반한 경우가 많아서 나중에 큰 문제로 부각될 수 있다는 것은 쉬쉬하고 있다. ㅡ_-);; 묻어둬서 누군가 밟으면... Orz... 요즘 나도 모르게 묻어둔다는 표현을 참 많이 사용하네.

네번째 발표는, '오픈소스 기반의 RIA에 대한 Enterprise 활용방안' 이라는 주제로 SK C&C의 홍도석 과장이 발표했다. 흠... ㅡ_-);;; 이 때는 딱히 뭔가 느껴지는 부분이 없었... Orz... 아는만큼 보이고, 모르는 만큼 이해하지 못한다...!!

점심을 먹고!!
me2photo

마침 삼성동 코엑스 쇼핑몰 한켠에 갤럭시S 현장 전시회장이 있어서 잠시 구경 좀 했다. ㅡ_-);; 아이폰이랑 디자이어 꺼내놓고 갤럭시를 만지고 있으니... 안내원이 다가오다가 다른 사람에게로 다가간다.
me2photo

화면이 쪼금 작기는 하지만, 내 디자이어가 훨씬 아기자기하면서 반응성은 좋다. 물론, 이것은, 루팅하지 않은 갤럭시S와 비교했을 때의 이야기다. 루팅한 갤럭시S에게는 제법 후달린다.
me2photo



  다섯번째 발표는, '모바일 웹 플랫폼 SW 표준화'라는 주제로 한국전자통신연구원의 이승윤 님이 발표하셨다. 가트너가 발표한 2010년 부터 2011년 까지 이끌 모바일기술에 대해서 (http://www.gartner.com/it/page.jsp?id=1328113) 이야기하면서, 앞으로 스마트폰과 타블릿 등의 모바일기기 환경에서 앱보다는 모바일웹을 바탕으로 많은 것들이 이루어질 것이라는 이야기를 한다. 이부분에 대해서는 상당히 많은 공감을 하고 있다. 최근 많은 개발자들과 개발사들이 모바일앱 개발에 뛰어들고 있다. 그래서 가격도 천차만별이고 정말 다양한 형태로 난립하고 있다. 지금의 시기는(앞으로 2012년 정도까지는) 모바일앱 개발과 관련한 사업은 서부개척기 때의 '골드러쉬'와 같은 모습을 할 것으로 보인다. 많은 이들이 앱개발을 통한 '성공'을 찾아 모바일 시장으로 뛰어들 것으로 보인다. 아이폰과 안드로이드폰 앱 개발로 유명세를 떨친 많은 이들이 여러 곳을 다니며 '모바일 앱'은 기회의 땅이며 많은 '기회'가 있다고 말하고 있다.
  얼핏보면 모바일앱 개발은 손쉬워보인다. 개그맨의 유행어 마냥 '그까이꺼 대충~ 3.7인치 화면에 맞춰서 버튼 넣고, 데이터 몇개 넣으면 되잖아.'라는 생각으로 달려드는 많은 이들은... 얼마 못가서 이 모바일 세계에서 떨어져나갈 것이다. 이미 그런 이들이 많지 않을까...라는 것이 개인적인 생각이다. ^^;
me2photo
  아이폰의 앱스토어에서 성공한 이야기를 보고서, 많은 개발자들이 맥북과 아이폰을 구매했다. 그들은 자신이 만든 어플을 앱스토어에 올린다. 그리고 몇몇 사용자들이 그들의 앱을 다운받아 사용한다. 그들은 불편한 사항에 대한 개선을 요구(피드백)한다. 개발자들은 것을 개선한다. 그리고 더 많은 이들이 쓰기 시작한다. 그리고 더 많은 피드백이 들어온다. 이 피드백을 수용하고 개선하기 위해서 이전보다 많은 노력이 들어가게 된다. 이 때, 일반 회사에 소속되어 개인적으로 개발하던 개발자들은 떨어져나갈 수밖에 없다.
  그들은 처음에는, '단순히' 앱을 앱스토어에 올리면 '돈'을 벌 수 있을거라 생각했다. 하지만, 막상 뚜껑을 열어 보니, 그 안 담긴 장에 '구더기'들이 득시글하다. ㅡ_-);; 구더기 무서워서 장 못 담그는 경우가 바로 이런 경우가 아닐까?
  그래서 이제 많은 이들이 이야기한다. '팀'을 이루라고. 기획, 분석, 설계, 구현, 유지보수에 이르는 과정의 업무를 분담하여 처리할 수 있는 '팀'을 이루라고... 그런데, 또 그게 쉽지 않다. 우리나라 개발자들은 대부분이 '독고다이'다. ㅡ_-);; 협업에 대한 개념이 제대로 서있지 않다. 그게 현실이다. 그래서 많은 이들이 꺼려하다가... 어느샌가 미묘하게 급변하는 모바일앱의 시장에서 떨어져 나간다. 흠... ㅡ_-);; 이 바닥이 원래 그렇다....

  우리의 관심은, 현재 모바일, 정확하게는 '스마트폰'에 꽂혀 있다. ㅡ_-);; 워낙 신문, 방송, 매체들에서 '스마트폰, 스마트폰' 떠들어대니까 일반대중들마저 '스마트폰'이 대단하구나 하면서, 다른 변화의 흐름에 대해서는 신경쓰지 못하고 있다. 그러는 사이, 구글과 애플은 iAD와 adMob이라고 하는 모바일 광고관려 사업을 시작했다. 우리나라는 아직 모바일 광고와 관련된 어떤 사업도 진행되지 않고 있다. ㅡ_-);; 기껏해야 모바일 포탈페이지 내에 몇 개의 광고를 띄우는 정도랄까? 구글과 애플은 스마트폰과 모바일 기기 내에서도 적극적인 광고사업을 벌이고 있다. IT 업종에서는 다른 어떤 사업보다도 '선점'을 하는 것이 유리한 입지를 차지할 수 있다. 그런 면에서, 선진국에 비해 4년 정도 뒤쳐졌다고 판단되는 우리나라의 모바일 환경은 아쉬운 점이 많다.

  그는 말한다. 스마트폰만 보지 말고, '모바일 기기'를 보라고. 애플의 '아이패드', 아마존의 '킨들' 등의 타블릿을 포함한 다양한 모바일환경 속에서 '범용적인 서비스와 프로그램'을 개발할 수 있는 환경을 구축할 수 있다면, 정말 기회를 잡을 수 있을 것이다. 그런 의미에서 본다면, 구글의 안드로이드 OS 환경은 꽤나 매력적으로 변모할 것으로 보인다. 이 OS를 바탕으로 구글TV가 나오게 된다면... 어떻게 될까? 한번 상상해보자. +_+)
  미래 사회는 , 모바일 기기 - (정보처리/전달 서버) - 일반가정기기 를 하나로 이어주는 환경이 구축될 것이다. '홈오토' 시스템이라고 해야할까?

  모바일 앱에서, 모바일웹 환경으로 변해갈 것이다. 모바일 앱은, 업그레이드를 하기 위해서 수시로 모바일 기기에 다운로드를 해야한다. ㅡ_-); 아직까지는 모바일기기에 있는 다양하고 효율적인 시스템을 쓰기 위해서는 앱(App)이 더 효율적이다. 하지만, 웹(Web)이 더 발전하게 된다면, 웹쪽이 더 매력적인 개발환경을 제공하게 될 것이다. 이 부분에 대해서도 나중에 한번 이야기 해보자. ㅎㅎ

me2photo
  여섯번째 발표는, 'SW 아키텍처 기반의 프로젝트 Risk Management"라는 주제로 삼성 SDS의 장세영 책임이 발표를 했다. 불확실성이 높아지면 RISK가 높아지게 된다...가 주제라고나 할까? ^^; 아키텍트들은 이 불확실성을 낮추기 위해서 노력을 해야한다.
4가지 핵심 요소가 있다.

  • Scope (요구사항의 증가와 결과물 제출 후 요구사항의 변화 등에 의한 불확실성 증가)
  • Schedule (Phase가 명확하지 않음, 기획, 분석/설계, 구현 등의 각 과정별 결과가 명확하게 파악되지 않은 채로 진행됨)
  • Budget (인권비, 개발자원비의 변화)
  • Quality (고객'갑', PM, 영업자, 개발자가 생각하는 품질에 대한 정의가 다르다)


 그리고 소프트웨어 아키텍쳐는 두가지 측면에서 접근해야 한다고 한다. Risk(사전적 예방), Disater(재해복구)를 고려해야한다고 이야기 했다.

나머지 발표는 'Framework'와 관련한 내용들을 들었다. 최근에 Framework에 대해 관심이 많은 덕분이기도 하다.

 두 개를 봐도... 사실 이해는 잘 안된다...? ㅎㅎ.

프레임워크자주 사용되는 코드들을 잘 정리한 코드들의 집합이며, 사용자가 간단한 환경설정 작업을 통해 제품화할 수 있는 반제품(Half-Product)이라고 할 수 있겠다. ^^; 생산성을 높이기 위한 '코드 재사용'이 중심이라고 할 수 있을 듯 하다. 이제 프레임워크에서는 정말 다양한 기능들을 제공하고 있다. 우리나라에서 많은 관심을 받고 있는 것은 Spring Framework(http://www.springsource.org/)이다. 나도 이 녀석에 대해서는 공부를 하고 있는 중이다. ㅡ0-);;

  마지막 발표자는 아이티와이즈컨설턴트의 안영회님. ^^; '프레임워크의 지속 개선(Evolving) 전략'이라는 주제로 발표를 하셨습니다. ^^ 블로그(http://younghoe.info)에 종종 방문해서 스프링과 아키텍쳐에 대한 이런저런 이야기를 종종 읽고 있습니다. 여전히 제가 프레임워크에한 이해도가 낮은 편이라서 

me2photo

글이 조금 길어지는 것 같아 이 정도에서 마무리를 지어볼까 한다.

아키텍트는 말그대로 '건축가'라고 생각한다. 소프트웨어 아키텍트는 거대한 IT 시스템을 아름답고 효율적으로 사용할 수 있게 설계하고 건축하는 '건축가'다. 자신의 이름을 담은 작품을 만들어내는 직업이라고 생각하기에 나는 이 직업을 멋지게 생각한다. 추후 경험을 쌓으면서 한단게씩 위로위로 올라가며 '아키텍트'에 도달하는 것을 목표로 하고 있다. 아직 갈길이 멀지만 한걸음 한걸음 차근차근 나아가다보면 도달할 수 있지 않을까? ^^;;

저작자 표시
신고
4 0
1
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬