'아키텍처'에 해당되는 글 5건

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

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

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

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


Architect!
Your Role, Our Future.

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


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

  • 발표자 : 삼성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 어플리케이션 개발 및 아키텍처

  • 발표자 : 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 분석 및 아키텍처

  • 발표자 : 삼성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. 클라우드 컴퓨팅 아키텍처 사례

  • 발표자 : 삼성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

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

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

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

  • 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만대 판매
        • 사례제공을 통해서 고객을 설득해야한다.
        • 우리쪽 장치만 사용가능하다.
        • 유지보수도 우리가 한다.





허니몬의 IT 이야기/프로그래머, '코드 엔지니어'

  저는 세상을 관찰하는 관찰자(Outsider of Outsider)가 되고 싶었는데...!!

  오늘 집에서 출발할 때는 어젯밤 내리던 비가 그치고 구름이 걷히면서 화창했는데, 강남에 도착하는 순간 구름이 끼고 바람이 불기 시작하더니 이내 눈보라까지 휘몰아치더군요. 와우. ㅡ0-)!! 더군다나 세미나 시작시간을 잘못 파악해서 12시부터 입장하는 줄 알고 서둘러 갔습니다. 12시 30분쯤 23층 회의실에 도착했었드랬죠. 실제 세미나 시작은 오후 1시부터 입장을 하고 선착순으로 24명에게 도서를 선물로 했다고 하더군요. 

  ㅠㅅ-) 세미나에서 상품으로 책을 주는 것을 언제쯤 받아볼 수 있을까요?


20120324 7차 공감세미나
장소 : 강남 교보빌딩 23층 대회의실



1. 전자정부 표준프레임워크 = 오픈소스 + 알파


    - 발표자 : 허광남(전자정부 표준프레임워크 에반젤리스트!?)


    - @Before
        = ALM
        = source_20120324.zip
        = "개발팀이 체계적이면 좋겠다."

    - 전자정부
        = 공공기관의 행정 전산화 : 중소기업의 SI 프로젝트를 통해서 중소기업의 소득이 증가하지
        = 2조 5천의 비용
        = 1억 연봉자 * 25,000명 개발자 : 서버 및 제경비가 포함된 금액

    - 표준
        = 똑똑한 개발자들이 공통(표준안)을 만들어 개발자에게 하달
            -> 개발하는 과정에서 문제가 생길 경우 이를 다시 전달

        = 개발 표준 문서
            1. 아키텍처, 코딩 스타일
            2. 공통모듈 매뉴얼, 용어사전, 에러 해결 사례(트러블 슈팅), 모범, 비행사례
            3. 2번이 추가되고 갱신이 일어나면 좋은 개발 표준이 된다.

    - 프레임워크
        = 개발 프레임워크는 정보시스템 개발을 위해
        = 필요한 기능 및 아키텍처를 미리 만들어 제공함으로써
        = 효율적인 애플리케이션 구축을 지원합니다.
        = 프레임워크 도입을 통해서 기술의 장벽을 낮출 수 있다.
            -> 비즈니스 로직 구현 <-> 아키텍쳐 구현, !고급 기술자
        = 프레임워크에 대한 표준가이드가 제대로 지도해주지 않는다면, 프레임 워크를 제대로 활용하지 못한다.
            -> 관리를 제대로 해주지 않으면 성능이나 효율이 떨어진다.
        => 프레임워크 효과
            -> "전자정부 서비스의 품질향상" 및
            -> "정보화 투자 효율성 향상"을 달성하고
            -> 대중소기업이 동.일.한 개발기반 위에서 공정경쟁
                1. 대기업에서 사용하는 별도의 프레임워크(LafJ, DevOn, Systemier 등)들이 존재한다.
        = 오픈소스를 기반으로 했기 때문에 문제가 발생했을 경우 인터넷 검색과 커뮤니티에 문의하여 해결이 가능하다.

    - 전자 정부 표준프레임워크
        = 표준프레임워크 + 민원발급 게시판 공인인증 + 행정민원시스템
    - 기본 구조
        = 개발환경
            -> 구현툴, 테스트툴, 배포툴(허드슨, 메이븐), 설정 관리툴
            -> 이클립스, 메이븐, 스프링에 익숙하면 전자정부프레임워크도 어렵지 않아요
            -> 개발 프로세스 가이드
        = 실행환경
            -> 34개의 오픈소스
            -> Configuration Management <-> Version Control Management
        = 운영환경
    - 관련 자료
        = 표준에 대한 고찰
            -> http://benelog.springnote.com/  <- 유명하신 분입니다~ +_+)
        = 지속적인 통합
            -> http://pragmaticstory.com/224
            -> 지속적인 통합을 통해서 빅뱅 통합의 여파를 줄여보자.
    - 빠른 예제 실행을 통한 동작방식 이해가 될까??
    - 전자정부 프레임워크는 통합된 개발환경을 제공해주고 예제(Template)들을 추가하여 손쉽게 구현해볼 수 있다.


허광남님은 '트렌드 기술'을 빠르게 익히고 개발자들에게 전파하는 것을 즐긴다. 전자정부 표준프레임워크는 우리나라에서 공공기관의 공통프레임워크로 만들기 위한 다양한 움직임이 있다. 

  전자정부 표준프레임워크를 활성화 시키려고 정기적으로 청계천에 있는 한국정보화진흥원 무교청사에서 세미나를 진행하고 있다. 공공기관에 적용된 표준프레임워크 성공사례에 대한 이야기들과 프레임워크 안에 들어가 있는 기술들에 대한 사용방법을 전파하려는 노력을 끊임없이 하고 있다. 개인적으로 스프링 프레임워크, jQuery 자바스크립트 프레임워크에 대한 조언을 구하려는 목적으로 사용하기에는 괜찮지 않은가 생각하고 있다. ^^;


바로가기 : http://www.egovframe.go.kr

  로그인을 하기 위해서 보안모듈을 설치해야한다는 것이 참... 거시기하다. ㅡ_-);;

  인터넷 익스플로러로  접속하면 ActiveX, 비 인터넷 익스플로러로 접속하면 Java Applet 으로 구현된 듯한 보안 모듈을 설치하려고 하고... 표준프레임워크에 대한 정보를 확인하고 의견을 나눌 수 있는 공간으로 들어가기 위해 쓸데없는 보안모듈의 관문이 생기면 진입하기 싫어진다. 오늘도 개발환경 다운로드 받으려고 했는데 계속 보안모듈을 설치하라는 메시지가 귀찮았다.


 2. 개발자와 천공수(Punch Operator, 코더?)의 차이

    - 발표자 : 신호승(유와이즈원)
    - 발표자 '쩐다.' 라는 표현을 좋아했음

    - 40시간을 50분만에 줄일 수 있을까?
    - 천공수
        = 천공수(Punch Operator) : 과거 워크스테이션을 사용했을 때 천공카드에 구멍을 뚫어주는 사람
            <-> 지금의 코딩만 하는 코더 와 크게 다르지 않다.
    - 컨설턴트 - PM - 아키텍트 - 개발자 - 천공수(BP : Business Process)
        = 비즈니스 프로세스적인 관점에서 영역을 본다라.
        = 개발을 위한 IT 목표
        = Enterprise Contents Managements
            -> 의도적이지 않은 계급화가 되었다.

    - 도메인Domain(Boundary)
    - 애자일방법론 : 기술, 문화적인 성숙도 없이 애바일 도입으로 가려고 하면서 문제가 많이 생기는 것이다.
        = ex) 도요타 : 린 애자일
    - SW 아키텍처가 필요한 이유
    - 개발자가 비즈니스 프로세스를 알아야 하는 이유
        = 우리는 평범한 사람들
            -> 공학적인 접근을 통해 공학적인 프로세스를 지켜야 한다.
            -> 미국의 학문이 정답은 아니지만, 전혀 모를 때는 닥치고 따라해보는 것이 가장 빠른 길이다.
            -> 실리콘밸리의 신입사원은 기존 문서화된 정보에서 70%의 지식을 배우고,
    - Customer Development로 부터 모든 Software 개발이 시작
        = 개발자에게 필요한 기본적인 소양
        = Customer Development <- 고객지향 개발기법 이랄까? ㅡ_-)?
    - 아키텍처 확립의 의미
        = 정리하고 산다는 의미
        = 현실을 정확하게 추상화하고 모델링하여 미래에 대한 계획과 위험에 대한 유연성 확대
        = 아키텍처를 통해 본질에 대한 파악
    - 자신이 만드는 제품에 대한 가이드 제공...
    - 요구사항 -> 변경사항 적용에 대한 공지

    - ** Agile 방법론이나 TDD등이 중요한 것이 아니라,전체적인 일하는 방법을 Agile하게 바꿔야하는 사례
    - ** 개발자도 비즈니스를 잘 알아야 한다.
    - IT는 ROI를 줄이기 위해서 필요한 것이다.
    - CMMI, Matrix
        = Level 2는 'Star'가 일을 하는 시스템
        = Level 5는 '조직' 일을 하는 시스템
    - 소프트웨어 개발은 SDLC(Software Development Life-Cycle)
        - 요구사항, 분석, 설계, 구현, 테스트
    - Software는 Intangible 하고 Human 집약적이다.
        = 80%가 사람에 대한 인력비용이 들어간다. 무조건.
        = 모델링(분석, 설계)이 필요
        = Human과 Intangible에 대한 가시성을 확보하기 위해 아키텍트가 필요
    - Agile
        = 개발자적인 Agile != Business적인 Agile
        = 애자일한 개발환경을 수행하기 위해서 천공수가 아닌 개발자가 필요
        = 높은 수준급의 개발자 역량 필요, 흔한 말로 고수가 필요하다.
        = 애자일 프로세스의 가장 중요한 Key
            1. Scope : 프로젝트에 문제가 생기면 조정가능한 것은 Scope 밖에 없다.
            2. Time/Cost
            3. Quality : 애자일하게 되면 퀄리티를 유지하면서 개발을 할 수 있...
    - 산업의 발전 : R&D -> Engineering -> Manufacturing
    - 소프트웨어 아키텍쳐
        = 아키텍처는 비전문가 고객이 쉽게 이해해서, 가슴으로 받아들일 수 있도록 설명하는 것이 가장 중요하다.
        = 아키텍쳐 평가 Architecture Evaluation
    - 미국에서 잘나가는 소프트웨어 업체에서 진행하는 소프트웨어 엔지니어링 기법을 따라가면 된다.
    - 우리나라 개발자가 잘되기 위해서는 영어공부부터...

    - 현재 수준의 내가, 어떻게 할 수 있는 수준은 아니구나....
    - Software Engineering

        = 소프트웨어공학 : 소프트웨어의 위기 해결



  소프트웨어 공학자가 바라보는 우리나라의 소프트웨어 업계에 대한 비판적인 시선을 접해볼 수 있는 기회였다. 대학교 다닐 때 '소프트웨어 공학'을 배웠다. '소프트웨어의 위기'가 도래하는 상황이 오게된다. 사람들이 가내수공업식으로 만들어내는 소프트웨어의 생산성이 수요를 감당하지 못하는 상황이 오게 되는데, 이를 해결하기 위해 공학적인 접근과 해법으로 해결해보려는 것이었다.

소프트웨어 위기의 원인은 전반적인 소프트웨어 프로세스의 복잡성과 소프트웨어 공학이 전문분야로서 상대적으로 미성숙한점에 관련되어 있다.

  • 소프트웨어 규모의 대규모화, 복잡화에 따른 개발비용 증대
  • 하드웨어 비용에 대한 소프트웨어 가격 상승폭 증가
  • 유지보수의 어려움과 개발적체 현상 발생
  • 프로젝트 개발 및 소요예산 에측의 어려움
  • 신기술에 대한 교육 및 훈련의 부족

출처 : 위키피디아 : 소프트웨어의 위기 

    개발자들은 발표자와 다른 생각을 가지고 있는 이들이 많았다. 이것은 아마 학문적인 입장에서 접근한 상황과 실무적인 입장에서 접근한 상황의 차이가 만들어낸 상황이라고 생각된다. 아키텍트보다 컨설턴트적인 입장에서 하는 이야기였다는 생각을 하게 되었다. 전에 KIPA에서 알바를 할때 'CMMI' 인증을 한 국내기업들에 대한 관리를 지원했던 적이 있었는데, 등록한 대,중,소기업이 꽤 많았었는데 정작 그들 기업은 그 수준에 미치지 못한다는 생각을 가지고 있다. 

  개발자들도 비즈니스적인 부분에 대한 관심과 이해를 가져야한다는 의견에는 공감한다.


3. 티타늄을 활용한 스마트폰 앱 개발
    - 발표자 : 방현우

    - 모바일 애플리케이션 개발방법
        1. 네이티브 앱
            = 해당 운영체제에 종속적인 애플리케이션
        2. 웹앱
            = 모바일 디바이스에 최적화되고 인터렉션이 많은 사이트
        3. 하이브리드 앱
            = 네이티브앱+웹앱의 장점을 활용한 것
            = 개발방식 : iPhone/Android 앱 개발자 + 모바일웹 개발자 협업 형태로 개발
    - 다른 하이브리드 플랫폼과의 차이점

        = 개발확장성

     - 생각 정리 :

        = 티타늄은 멀티플랫폼 개발 도구...랄까?
        = One source multi use.
하나의 소스를 개발하여 이 소스를 다양한 플랫폼에 맞춰 앱으로 개발할 수 있다.



  4. 자바 웹 개발자의 학습 로드맵
    - 발표자 : 박재성

    - 내가 기대하게 된 이유 : 나도 누군가에게 알려줘야하는 때가 오고 있어.
    - 미리미리 학습을 해두면 좋지.
    - 따라해보기
    - 기술의 홍수
    - 지속가능한 개발자
    - 로드맵

    - 시간적 여유가 있다 / 시간적 여유가 없다. -> 일단 취업이 중요하다.
    - 단기 속성 : 취업이 빠른 2012년
        = 이클립스 -> 자바 -> JSP/Servlet -> Spring + iBatis(or myBatis)
        = 취업성공 후 쌩깐다.
    - 장기 과정 : Step by Step
        1. 통합개발도구(IDE) : ****
            -> 앞과 뒤에 알아야 하는게 많다. 방법론, 개발기술, 커뮤니케이션, 도구
        2. 자바(Java, Language) : *****
            -> 근간, 기본, 기초를 너무 소홀히 하지 않는 것이 중요하다.
        3. JSP/Servlet : *****
            -> 중요도 : JSP < Servlet
            -> 데이터베이스 : **** or ***
        4. 빌드도구(Ant, Maven) : ***
            -> 나는 개인적으로는 중요하다고 생각한다.
        5. 버전관리도구(VCM, Subversion, Git) : ****
            -> 버전관리를 안하는 개발은 '하드코어'로 하는 디아블로다! 
        6. 테스트 주도 개발(TDD)과 리팩토링 : ****
            -> 잘 안되고 어려운 프로젝트
            -> 경력자, 앞단에서 리딩하는 TDD와 개발자가 성장해가면서 겪게되는 TDD는 다르다.
            -> 테스트 과정이 복잡하고 어려우면 소스수정을 하려고 하지 않는다.
            -> 빠른 피드백을 통해서 코드가 개선되는 것에 대한 희열. 초반부터 습관화 시켜야한다.
            -> 테스트 주도개발 방법론이 실패하는 이유는 그것을 익히고 습관화하는데 시간이 많이 걸리기 때문이다.
            -> UI없는 예제, 데이터베이스 없는 예제를 통해서 익혀라.
            -> TDD를 통해서 객체지향을 익힌다.
            -> UI, DB가 얽히게 되면 절차적인 프로그래밍이 된다.
            -> ** OOP의 개념을 잡아라
        7. 프론트엔드(HTML & CSS) : **
        8. JavaScript : ****
            -> JavaScript의 기본 개념을 이해해라.
            -> 자바스크립트에 대한 기본적인 이해
        9. Database 처리:
            -> 처음에 개발할 때는 Model1 방식으로 웹 개발 : 원래 해보고 그것이 가지는 장단점을 깨달아라.
            -> 프레임워크를 사용하고 기존의 방식을 뛰어넘음으로 해서 자신이 하고 있는 일에 대한 '왜Why?'를 알지 못하게 된다.
        10. OOP, Design Pattern : ***
            -> 자바코드를 더 풍부하게
            -> 쉽게 따라올 수 없는 영역, 다른 사람과 차이를 가지게 되는 부분이다.
            -> 피부로 느끼고 깨닫는 것이 중요하다. 그 때서야 시야가 넓어진다.
        11. DI(Dependency Injection) : ***
            -> 프레임워크에 대한 이해
            -> 기초가 잡혀 있어야 해.
        12. Callback Interface, Class 개념 이해 : *****
            -> 중복을 리팩토링을 통해서 해소하면서 깨닫게 되는거지
            -> 추상화에 돌입하게 된달까?
        13. RDBM, ORM : ****
            -> ORM : 학습비용이 높다. 무지 높다.
                => 솔루션, 자체 서비스 개발
                => 테이블 정규화가 자연스럽게 된다.
                => 생산성 향상이 크다.
            -> RDBM : 학습비용이 적고, 빠른 결과를 얻을 수 있다.
            -> 그러고보니 이번 프로젝트에서는 DB에 의존적인 도메인 설계를 했어.

    - 인프라 구축 및 교육
        -> 이에 대해서 관심가지고 있는 많은 사람들이 있다.
        -> 하고 싶은 일을 위해 용단을 내리신 자바지기님 멋쟁이!!


    이번 자바지기님의 발표를 들으며, '자바 개발계의 애정남'의 느낌을 받았다. 애매한 자바 초보 개발자들이 습득해야하는 기술들에 대해서 정해주는 감사한 강의였다. 지금까지는 누군가에게 모르는 것을 물으며 배워왔다. 모르는 것이 있으면 찾아보기도 하고 찾다가 없으면 물어보고 답을 얻어왔다. 이쪽에서 일한지 만 2년을 넘기고 있는 지금 내 후임으로 누군가가 들어왔을 때 그들에게 무엇인가를 알려줘야할텐데 어떻게 알려주는게 좋을까 생각하고 있었는데 그것을 정리할 수 있는 좋은 기회였다.

  얼마 전에 교보문고에 가서 개발서적을 둘러보다가 Java 언어 쪽에서 어떤 책을 읽을까 고민하는 대학생의 모습을 봤을 때, '나는 자바개발자인데, 저런 학생들에게 '이렇게 공부하면 돼.'라고 명확하게 말해줄 수 있을까?' 라는 생각을 떠올렸다. 그 때 너구리님 블로그에 올라왔던 글을 찾아봤다.

  참고 사이트 :
   - 권남 : http://kwon37xi.egloos.com/3666564
   - 너구리님 '여름으로 가는 문' : http://blog.doortts.com/93 '그림으로 보는 자바 학습 로드맵'

  모든 개발자가 같은 길을 걸어가지는 않는다. 그러나 시작하면서 홀로서기를 할 수 있는 준비를 할 수 있는 길이 있다면 큰 도움이 된다. 최근 대외활동을 하면서(난 관찰자다!! 개발자들의 모습을 지켜보고 있다.) 나름 많은 개발자들의 모습을 보면서 느낀 부분이다.

  자바 웹 개발자가 걸어야하는 길은 멀고도 멀다.

  개발을 위한 환경구축을 할 수 있는 능력(소프트웨어 아키텍트가 되기 위해 갖춰야하는 것 중 하나라 생각한다), 서버 프로그래밍, 프론트엔드 개발, 기획자와 PM과 싸울 수 있는 전투력(그들이 이해할 수 있는 표현으로 설명할 수 있는 능력, 커뮤니케이션), 자신의 생각을 구현하여 상품화할 수 있는 실천력 등 다양한 능력을 필요로 한다. 

이제는 '브로그래머(Brogrammer : 외톨이형 아닌 돈 많고 즐길 줄 아는 프로그래머)' 읭?!

Quora.com - How does a programmer become a brogrammer?

  이제 프로그래머도 내적으로 외적으로 적극적으로 왕성하게 활동해야하는 시대가 되었다. 자신의 의견을 피력하고 자신을 사람들에게 드러내야 하는 시대가 와버린 것이다. 하아... 일단 뱃살부터 줄여야지.



   


  Adobe 제품을 쓰지 않는다. 브라우징을 하는 과정에서 필요한 Flash Player를 설치한 것 이외에는 쓰지 않는다. Adobe의 웹관련 솔루션들은 이제 끝물이 아닐까? HTML5가 안착하게 되면 더욱 더 그 입지가 좁아지게 될 것이라 생각한다. 동의하지 않습니다. 죄송합니다.

  이것이 나의 세미나 참가 하면 갖추는 기본 셋팅(노트북, 노트, 펜, 음료)이 되었다. 맥북의 사용시간이 긴 편이라 들고다닌다. 가끔 낙서를 하기 위한 용도로 노트도 펼쳤다. 스마트폰의 핫스팟 기능을 통해서 인터넷 연결을 하는 편이었는데 이번 스마트폰(LGT Optimus Q2)은 데이터 통신이 안정적이지 않아서 애초에 무선인터넷을 끄고 사용한다.

 

  휘몰아치던 눈이 그치고 언제 그랬냐는 듯이 햇살이 쨍하게 내려쬔다.
  아키텍처(+아키텍트)에 대한 이야기를 들으며 남긴 낙서. SW 아키텍트를 통과점으로 생각하고 있는 내게 여러가지 생각을 갖게 만드는 발표가 있었다. ROI에 중점을 둔 아키텍트와 아키텍처 관련 내용들이 조금 혼란을 야기했다. 이 발표는 정책결정권자나 컨설턴트들이 듣기에 더 적합하지 않았나 하는 생각이 들었다. 아직은 코더에 가까운 위치에 있는 나로서는, 관심을 가지고 있는 개발기법들에 대해서 무익하다는 투의 발표는 조금 거북스러운 멶이 많았다.

  컨설턴트 <-> PM <-> 아키텍트 <-> 개발자

서로의 입장과 생각이 다르다는 것은 확실히 알았다.



뒷풀이는 순대수육!!

이번 '7차 공감세미나'에서 중요한 것은 따라하기
  이번 공감세미나를 들으면서 떠오른 것은 '따라하기' 였다. 새롭게 일을 시작하는 새내기가 가장 빠르게 일을 익힐 수 있는 방법은 '따라하기'다. 고수들이 어떻게 하는지 알아내서 그것을 따라하면서 자신에게 맞는 방법을 찾아내는 것이 가장 효과적인 학습방법이라고 생각한다.

  전자정부 표준프레임워크는 컴퍼넌트 예제를 추가하여 동작하는 원리를 쉽게 익힐 수 있다.

  소프트웨어 공학자는 '미국'의 SW기법들을 따라하라고 했다. 

  자바지기님은 자신이 익혔던 학습로드맵을 보여주시며 따라해보라고 했다.

  고수들이 나와서 자신들의 이야기를 해주는 자리가 있다면, 빠짐없이 참가해서 그들이 하는 것을 보고 듣고 느끼고 뜯고 맛보고 즐기면 되지 않을까? 아직 내가 가야하는 길은 멀고도 멀었구나 생각하게 된다. 

  나는 앞으로도 당분간은 지켜보는 자리를 지켜야겠다.



허니몬에 관한 보고서/허니몬의 물병편지
  • 안드로이드 마켓에 등록된 앱이 10만개를 돌파하고 10억 다운로드를 달성했다고 한다. 안드로이드의 ㅛㅓㅇ장세는 여전히 무섭다!! // 씻고 나가봐야겠구나… ㅡㅅ-); 출근이랑 뭐가 달라!!(월차내고 세미나 들으러 가는 남자... ㅡㅅ-);; 다들 신기한 듯 쳐다보더라... Orz.... 프로그래머라면 의당 그러해야하지 않을까?? me2mobile) 2010-07-16 06:37:32
  • 갤럭시S 루팅했더니 성능이 2배 향상! - JOINS | 아시아 첫 인터넷 신문 // 내용은 괜찮아. ㅡ_-); 그런데 기사 중간중간에 있는 키워드의 링크를 눌러보면… 전혀 연관없는 사이트로의 링크라니… ㅡ_-);; 장난해? 결과랑 성형외과회사랑 무슨 상관이야?(조중동의 기사 중 링크를 암생각없이 클릭하면... 전혀 엉뚱한 곳으로... ㅡ0-);;) 2010-07-16 07:02:01
  • ㅡㅅ-);; 안되던 디자이어 이어폰을 한달만에 다시 꺼내었더니… 잘 된다!? 호잇!?(자가치료되믄 디자이어 이어폰!? me2mobile) 2010-07-16 08:14:33
  • 2010 한국 소프트웨어 아키텍트 대회 왔쩌염 'ㅅ' 뿌우움!!(현장기록 코엑스 2010 한국 소프트웨어 아키텍트 대회 // Agile 개발실 - 자부심, 행복감 그리고 놀라운 결과 me2mobile me2photo) 2010-07-16 09:16:24

    me2photo

  • 요구사항, 시장흐름에 흔들리지 않게 프로세스를 통해 흔들리지 않을 수 있도록 하자.(아키텍트와 애자일의 결합... me2mobile me2photo) 2010-07-16 09:49:15

    me2photo

  • 바쁘신 류한석님 출현!! ㅎㅎ 자주 뵙네요.(전자정부 2.0 을 위한 아키텍처(공공 정보자원 공유 인프라 구축을 위한 아키텍처) 류한석 me2mobile me2photo) 2010-07-16 09:53:54

    me2photo

  • 한국에서 쓸 수 있는 한국형 SNS는 없다…라고 말씀하시는 류한석님. 흠… 미투데이에 대해 잠시 생각해본다…(소셜네트워크 SNS... 미투데이 트위터 페이스북 흘랫폼... 흠... 미투데아는 플랫폼이 될 수는 없는 걸까?? me2mobile me2photo) 2010-07-16 10:04:10

    me2photo

  • 전자정부2.0이전에 국가와 국민과의 신뢰를 두둑하게 구축해두어야 한다… 그러나 지금 정부를 보면 신뢰할 수가 없다… 전자정부2.0 데이터셋 공개에 앞서 국민들을 팬보이들을 만들어야 한다.(전자정부 2.0 하지만... 지금 정부와 정권과 정계는 신뢰할 수 없다. 불신하고 있다... 전자정부2.0을 위한 선순환이 이루어지지 않는 이유... me2mobile) 2010-07-16 10:26:28
  • 아키텍트, 오픈소스 Spring framework에 길을 묻다. 철학적인 접근… 조만희 아이티와이즈 컨설팅(한국 소프트웨어 아키텍트 대회 // 프레임워크 오픈소스 me2mobile me2photo) 2010-07-16 10:39:42

    me2photo

  • 아키텍트, 스펙의 홍수에서 길을 잃다… 경험이 더욱 절실하게 목말라지는 요즘…(네스팟 좋은데... 컨퍼런스룸마다 다 터져. 티존은 어디에..!? me2mobile me2photo) 2010-07-16 10:46:36

    me2photo

  • 많은 발표자를 본다… 그들은 무의식적으로 빔을 쏘는 화면을 본다… 잡스처럼 할 수는 없겠지만… 가능하면 노트북 화면과 청취자들의 눈과 아이컨텍트릉 하는 게 좋지 않을까???(눈으로 말해요... 나도 주의하자... ^^;; me2mobile) 2010-07-16 11:21:39
  • 완성도 높은 UI Designer… 생산성 좋은 개발자… 인력부족… 나도 언젠가는 어디서나 모셔가고 싶은 능력자가 되고파…!! ㅡㅅ-)(하지만 현재 나는 늦깍이 초급 개발자... 기다려!!! me2mobile) 2010-07-16 11:36:53
  • 트위터나 페이스북으로 계정하나 개설해서 DM이나 멘션 으로 질문하라고 하면 될걸… 발표 끝날 때마다 “질문지 작성해주세요.”하면서 분위기를 쌔야겠니… 트렌드도 읽지 못하는 운영이라니…(한국 소프트웨어 아키텍트 대회 운영진의 고리타분함과 무지함... me2mobile) 2010-07-16 11:55:59
  • 삼성동 한켠에 자리잡은 갤럭시 광고터…(안드로이드 갤럭시s 최고라 할만한 하드웨어 스펙을 제대로 최적화하지 못한 범작... 아쉽다. OS 2.2 업뎃 후 루팅해서 SKAF 들어내면 최고의 안드로이드폰을 쓰실 수 있습니다. me2mobile me2photo) 2010-07-16 12:06:59

    me2photo

  • 점심은… 혼자먹는… Orz… 태국식 새우 볶음밥!! 그래도 맛나게 먹어줄테다!!!(여기는 풀무원 경영하는 엔즐 me2mobile me2photo) 2010-07-16 12:10:49

    me2photo

  • MyDesire와 갤럭시s 잠시 비교결과!! MyDesire 승리!!(htc와 삼성의 스마트폰 최적화 능력의 차이... me2mobile me2photo) 2010-07-16 12:39:22

    me2photo

  • 곧 지스타도 열리겠군… 넥슨은 당연히 참가하죠?? 넥슨PC방님. ㅎㅎ 잘 지내시냐며 소환(내가 요즘 게임에는 도통 관심이 없어서... 그래도 잘 지내실테니 무걱정!!! me2mobile me2photo) 2010-07-16 12:48:59

    me2photo

  • 4번 트랙이신가요!? ^^
    2010 소프트웨어 아키텍트 대회에서 만난 [짱가™]님과 성현님 :) 넘 반가웠어요!! by 너구리 에 남긴 글 2010-07-16 13:12:23
  • 올해 안에 국내 모바일 웹표준안 mobileOK가 발표될 것이라고 하는군요… 단말기에 독립적인 웹표준을 위해서라는 군요.(2010년 연내 국내 모바일웹 표준안 mobileOK 발표됨... 흐음!? 뭔가 더 적절한 단어가... me2mobile me2photo) 2010-07-16 13:29:48

    me2photo

  • 플랫폼… Platform… EcoSystem… API… Enterprise… Framework… Opensource… Architect… Architecture… Software… SNS… twitter… facebook…(e-govment 2.0 me2day w3c mobile smart web app development developer and me!! 오늘의 키워드들... 흠..!! 머리가 더 복잡해지고 있어!!! me2mobile) 2010-07-16 15:14:18
  • Framework Engineering… 손영수님 발표. 트랙4 시즈모드 돌입.(최근 나의 관심사는 framework 이기도 하니까 me2mobile me2photo) 2010-07-16 15:20:17

    me2photo

  • 아키텍트 대회라 그럴까…. 개발자보다는 분석설계자가 더 많아…. 왠지!! 씁쓸한데…!! 그래도 나는 아키텍트가 되어보련다…!!(me2mobile 2010 한국 소프트웨어 아키텍트 대회... 프레임워크 framework 재사용 그것을 통한 생산성 고취) 2010-07-16 16:11:39
  • 안영회님의 출현!!!(블로그를 통해서만 뵈었었는뎅...!! ㅎㅎㅎ me2mobile me2photo) 2010-07-16 16:41:02

    me2photo

  • 울까 말까 삼성 // 루팅하는 사용자들의 속출…. 어쩌면 안드로이드폰은 루팅이 기본코스가 될지도 모르겠네…. ㅎㅎ 하드웨어 최고성능을 죽일 수 밖에 없는 이유 중 하나는…(me2mobile 말 안해도 알지...?? SKT 통메...) 2010-07-16 17:46:39
  • 비가 억수로 오는구마잉!!(me2mobile 바지가 척척 붙어주네) 2010-07-16 18:31:25
  • 집에가서 밥이 있으면 밥에 소고기 구워먹고… 아니면 팔도비빔면에 얹어 먹을테다.(me2mobile 소고기는 미디엄으로... // 아놔 퇴근타임 버스 괜히탔어.) 2010-07-16 18:42:55
  • 아!!! 오늘은 금요일이지!! 회사에 안가서 토요일 인줄 알았어….(me2mobile 비오는 금요일...) 2010-07-16 18:44:41
  • 5분이면 뚝딱 육덮 비빔면!!(저녁 굶지 마세요!!! me2mobile me2photo) 2010-07-16 19:27:55

    me2photo

  • 하아아앙… ㅡ0-);; 이건… 또… 치명적 유혹!!
    Toby님이 심혈을 기울여 지은 책. 토비의 스프링 3: 스프링 프레임워크 3 기초 원리부터 고급 실전활용까지 완벽 가이드 8월 5일 출간! 1400페이지에 하드커버양장으로 나옵니다. 이아스님, fupfin님, 호랭이님, okgosu님 등이 써주신 추천글도 읽어보세요~ by bliss 에 남긴 글(사실... ㅡ_-);; 컴퓨터 서적으로 해서 양장본은 좀 ... 그래요. 프레임워크 파트별로 해서 3권정도로 분리할 수 있게 했음 어땠을까하고 생각합니다....) 2010-07-16 21:54:49
  • 우리는 언제부터… 무엇인가를 사기위해 기대를 품게 되었을까? ㅡ_-)?(그것이 나오면 조금 참았다가 욕구불만에 쌓여 카드로 그것을 싸지른다. 그런데 문득 생각해본다... 그게 정말 나의 의지일까?) 2010-07-16 22:20:55

이 글은 허니몬님의 2010년 7월 16일의 미투데이 내용입니다.

허니몬에 관한 보고서/허니몬의 물병편지

이 글은 허니몬님의 2010년 7월 15일에서 2010년 7월 16일까지의 미투데이 내용입니다.

허니몬에 관한 보고서/허니몬의 행성, 허니스(Honies)
  • 위험은 가능성만으로도 피해야 합니다. // 성공은 희망만으로도 추구해야 하오. 사실상 성공보다 희망이 더 중요하지.(me2mobile me2book 위기는 기회인 것은 분명하지만, 위기의 강도는 잘 재어봐야지) 2010-03-24 07:52:15
    그림자 자국
    그림자 자국
  • 어제오늘, 저에게 한걸음 더 가까이 다가와주신 ^^ 친구 두분을 소개합니다. 늘봄님과 씨트러스님을 소개합니다. ^^ 저도~ 한걸음 더 다가서겠습니다. 오늘하루도 즐겁고 행복한 일들이 많이 생겼으면 좋겠습니다.(미친소개, 미친결연, // 하지만... 하지만!!! 오늘 하는 일은 귀찮군요!!) 2010-03-24 08:57:06
  • 오버보컬 // 안드로이드를 배우는 건, 프로그래밍(자바쪽?)에 대한 어느정도의 경험이 있으면 어렵지는 않지. ㅎㅎ 아마 대부분의 프로그래밍을 배우는 것도 마찬가지겠지만… 문제는 거기서 한걸음 더 나아가는 것. // 아직은 ADT가 투박하고 빈약한게 흠.(안드로이드 프로그래밍, 시작은 그럴 수밖에 없을지도. ㅎㅎ) 2010-03-24 08:59:36
  • 기업미투의 친신을 받으면 잠시 고심하는 이유…
    내일 이벤트가 끝나면 특별한 사정이 없는 한 이벤트를 하지 않겠습니다. 이벤트 때문에 이곳을 찾은 분들은 스스로 떠나주세요. 불고기브라더스와 우리 문화, 세상사와 IT, 예술에 관심있는 분들과 친구로 지내고 싶습니다. by 불고기브라더스 에 남긴 글(일순간 관심을 받기 위한 이벤트성 미투개설인지, 미친들과의 교류를 위한 개설인지 살펴보게 된다.) 2010-03-24 10:00:00
  • 새삼스러운 것은 아니지만… ㅡ_-);; ㅎㅎ 현정부 관련자들의 군면제 사실은… 놀랍군요. 신의 자식들만 모여있는 우리나라 현정부 관료들이로군요. ㅡ_-);;(죄다 면제, 군면제를 받는 것은 신의 축복과도 같아서 '신의 아들'이라 불리는 평민들의 삶과는 다르군요. ㅎㅎ) 2010-03-24 10:11:38
  • 어떤 사이트에 가입하던지 기본 사용자정보로 주민번호, 주소, 이메일, 연락처를 요구하는 우리나라의 서비스들. 그게 과연 보안담당자들만의 문제일까? ㅡ_-)? 개인정보를 움켜쥐고 고객을 쥐어짜려는 기업의 잘못된 고객관리정책이 낳은 부작용을 일개 직원에게 떠넘기다니…
    실력 없는 보안 담당자는 형사 입건 by 바사아자 에 남긴 글(보안 담당자의 형사입건, 이건 친구에서 '니가 가라 하오아이' 라고 말하는 거잖아. ㅡ_-);; 범죄물에서 피가 뚝뚝 떨어진 칼을 부하에게 쥐어주는 못된 두목 같잖아? 그렇잖아!?) 2010-03-24 10:19:19
  • 쉼표를 가지란 글을 보다가 어디선가 읽은 글을 보고, 구체적으로 찾아보려다가 구글에서 번역한 내용이 눈에 들어왔다. / 마음이 따라오길 기다리다 (Waiting to come to the mind) /'왠지 눈과 마음에 와닿는 문구로 검색어를 했구나'하는 생각이 든다.(마음이 따라오길 기다리다. 너무 바쁘게 지내는 나머지 몸과 마음의 속도가 일치하지 않는 현재, 앞서간 몸이 뒤따라오는 마음이 따라오길 기다리는 여유를 갖는 하루가 되었으면 한다.) 2010-03-24 10:54:31
  • 졸려… ㅡ0-)!!!!(일찍 잤는데...) 2010-03-24 11:50:57
  • 작업하는 플랫폼의 관계를 배워라. // 당신이 작업하는 플랫폼(언어, 운영체제, DB 등)에는 그것을 효과적으로 사용할 수 있는 다양한 나름의 관례가 있다. 단지 구현 기술을 현명하게 사용할 경우 전체적인 성능을 개선할 수 있음을 말하고자 함이다.(그러려면 당신이 작업하는 플랫폼을 철저하게 이해해야 한다. me2book 소프트웨어 아키텍처 2.0) 2010-03-24 13:30:14
    소프트웨어 아키텍처 2.0
    소프트웨어 아키텍처 2.0
  • twi2me 태그만 남기시는 분들과 미친을 끊었음….(그냥 트위터를 하세요. ㅡ_-);; twi2me 가 날리는 RT는 미친에게는 스팸이나 마찬가지임) 2010-03-24 13:59:24
  • 슬며시 졸음이 찾아온다. ㅡ_-);;(식곤증이 지나갈 무렵이 아닌가?) 2010-03-24 15:39:54
  • 삼성전자, 개발자 없어 아이디어 갈취하나?, kbench // 약관이 아주 개떡같구만… ㅡ_-);; 완전 거저먹으려는 심보가 약관에서 보인다. 오픈소스 라는 것에 대한 개념부터 잡았으면 좋겠구나…대략난감한 약관. 역시 삼성은 돌아볼 필요가 없다. ㅡ_-);;(삼성전자 TV용 애플리케이션 개발관련 약관, 개발자들의 아이디어를 아무런 협의없이 삼성전자 맘대로 쓰겠다고 해석이 되는 것은 비단 나뿐인가? 개발자가 없다기보다는 머리가 없어서?) 2010-03-24 17:20:40
  • 집에 가고 싶어요.. ㅠㅅ-)> 아직 9시 전(me2mms me2photo) 2010-03-24 20:32:01

    me2photo

  • 집!! 집!!! 집!!!! 지이입…!!!!!(me2mobile 곧장 가는거야!! 괜히 달리는 버스에서 뛰어내리고 뜨거운 떡볶이를 호호 불면서 먹지 말자고!!) 2010-03-24 21:15:13
  • 그림자 지우개.. 하나의 존재를 존재하지 않는 것으로 만드는 것. 그것은 끊임없는 자기부정의 .구일지 모른다(me2mobile me2book 그것은 남을 부정하지만 스스로를 부정하는 딜레마의 상징) 2010-03-24 21:40:58
    그림자 자국
    그림자 자국
  • 미래와 과거의 접점인 현재. ㅡㅅ-)> 이 양반은 그런 과거 현재 미래의 접점과 그 접점이 낳는 혼돈을 적절하게 혼돈할줄 아는 카오스틱한 작가다.(me2mobile me2book 자신만의 세계를 창조할줄 모르는 정치가 따위가 좌빨이라 규정지을만한 사람은 아니지) 2010-03-24 22:06:19
    그림자 자국
    그림자 자국

이 글은 허니몬님의 2010년 3월 24일의 미투데이 내용입니다.

1
블로그 이미지

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

허니몬