SlideShare a Scribd company logo
아키텍트란?


한국에서 아키텍트란?


Architect를 위한 조언들.




                     2
Architect
현업이 요구하는
기괴한 아키텍트의 역할.




http://vizend.tistory.com/37
Architect ?= GOD
그 누구의 일도 아니면..
여러분이 만난 S/W Architect.

                                                  Enterprise
                                   UX Architect
                                                  Architect
                         Data                                    Test
                       Architect                               Architect


            Service                                                        Security
           Architect                                                       Architect




    Business                                                                    Infrastructure
    Architect                                                                      Architect




 Application                                                                            …
  Architect
                                           Architect
                                              ??
아키텍트가 알아야할
  12/97가지
요구사항          설계         개발/운영        자세
                         가장 큰 문제는
Vasa호 이야기   1000 피트의 뷰                정경유착
                         기술이 아니다.

아키텍팅은 균형    A와 B의 사이의    반복 작업과 싸
                                     고객의 고객
 에 관한 것.       결정          워라!

            구현 가능한 것     드워프.엘프, 마   사과와 컨설팅
걸어다니는 해골
             만 설계해라.     법사 그리고 왕     이야기
왜 우리에겐 이런 일이 발생할까?
#조언 1
Mark Richards의 Vasa호 이야기
Vasa호 이야기

              스웨덴 왕실의 위엄을
              온 세계에 알리고

              덴마크와 동유럽을 침공하기 위해
              국왕이 직접 Vasa호의 설계에 참여.


아돌프 구스타프 2세
국왕으로 인해 변경된 요구사항

              하는 김에 화려한      사람을 많이 태워야
  함포 64문
               장식도 달자!       겠어! 갑판 확장!!


               금으로 도금한 병
                               호화로운 장식 채
  원래는 32문!     사 조각상 1000여
                                  우기
                   개!


                스웨던 왕실 상
  세계최초로 상하                     많은 탑승인원
               징!! 두마리의 사
  2열로 함포 배치                      450명!
                  자 등..
결국은 ..
사상 최대의 사망자? 왜?

배 출항식 탑승인원 구성

   귀족 100명
   선원 50명
오히려 다행!


덕분에, 전수식 후
항해하기로 했던

선원과 군인 450명은
  목숨을 건짐.
결론


Vasa호와 같이
모든 요구사항을 충족시키려는 시도는
궁극적으로 아무것도 수행할 수 없는
불완전한 아키텍처를 만들게 됩니다
반복되는 역사..
#조언 2 - Randy Stafford의
“아키텍팅이란 균형에 관한 것이다.”
요구사항 정하기.




출처 - IEEE1471 Korean Extension – 소프트웨어 아키텍처 정의(안)
Quality Attributes Workshop




                              P
QAW Roadmap
QAW Roadmap
Context


 단, QAW, ATAM은 구축하는
    시스템이 명확하고,
  이해당사자들이 시스템을
이해하고 있을 때 적용 가능하다.
Context


이해 당사자들간의 정치관계를 조심해라.

         또한

투표권을 전체 팀원에 적절히 배분해라.
#조언 3 – Alistair Cockburn

요구사항이 명확하지 않을 때.
걸어 다니는 해골로 시작해라
Rainy Day..
사례.

          경영 이론 시스템을 적용해

          의사 결정 도구 시스템을

          구축하는 프로젝트




신사웅님 - 요구사항이 명확하지 않을 때..
문제 발생
                     고객
                     • 경영 이론을 시스템으로 구축한
                     경험 전무
                     • 단지 경영진으로부터 방향성만
                     제시 받음




전산팀
• 안정화된 시스템에 새로운 기능
/프로세스를 추가해본 경험밖에
없다.
• 구체적인 요구사항이 없어 설명
한 경영 이론에만 의존해 시스
템 구축
갈등 발생!!
• 진행과정을 리뷰 하면서, 갈등 시작

• 전산팀은 나름대로 요구사항 정리 후 개발
 – 시연을 하게 되면 전혀 다른 요구사항이 발생
 – 고객이 원하는 시스템이 아니었다는 결론
 – 전산팀에서 아이디어를 고민해 제시해 달라!!


• 업무적인 갈등을 넘어 감정의 갈등으로..
상황정리.
고객의 입장에서는 최종 보이는 결과는 UI

실제 필요한 요구사항 파악 불가
QoS – (비기능적인 요구사항) 파악 불가

선정한 Framework의 사용성, 적합성 모름.
비즈니스 도메인에 대한 정보 예측 불가

구축 후 발생하는 여러 문제들을 파악 불가
Walking Skeleton
걸어 다니는 해골.

Prototyping보다 한 단계 앞선 모델.

종단(예를 들면 UI~DB까지) 간을 오가
   며 수행되는 가벼운 구현체.

모든 호출 경로를 실험할 수 있게 작동
      하는 작은 시스템.
걸어 다니는 해골.

모든 종단을 다 관통하는 주요 시
  나리오를 몇 개 만들어라.

그러다 보면, 시스템의 외적/내적
인 요구사항을 자연스럽게 도출
      할 수 있다.
#조언 4 – Erick Doernenburg
 “1000피트의 뷰를 가져라”
Architecture
Visualization
높이 (30000 feet)봐야 할까?
뭐가 보이시나요??
자세히
(0 feet) 봐야 할까?
제한된 코드로 프로젝트가
 잘되고 있는지 판단은?
3만 피트 vs 0 피트의 뷰.
      3만 피트
      • 다이어그램의 Line의 의미는?
       • 의존성?
       • 데이터 흐름?
       • 버스와 같은 공유자원?

          0 피트
          • 너무 상세한 정보임.
          • 전체적인 구조를 보지
           못함.
해결책은..
적절한 1000 피트의 뷰
STAN (Structure Analysis for Java)




STAN - http://stan4j.com/eclipse/eclipse-integration.html
Robert C. Martin의 그래프
Instability
•패키지의 움직일             수 있는 여력을 판단하는
지표
•다른 패키지에 영향을 미치지 않고,
 해당 패키지를 쉽게 변경 할 수 있는가?
•Instability I = Ce / (Ca+Ce)
•Ce = Efferent Coupling (Ingoing Dependencies)
•Ca = Afferent Coupling (Outgoing Dependencies )
Instability




                   Instability I = Ce / (Ca+Ce)
당신의 패키지가 다른 사람이 많이 쓴다면,
즉 Outgoing, Ca가 많다면, 여러분의 패키지는 변경하기 어렵다.

반대로 Outgoing하는 Ca가 적고, Ingoing(다른 패키지만 사용만 하는) Ce,
여러분의 패키지는 쉽게 변경해도 된다.

즉 0.0에서 0.3이면 안정적인 버전, 0.7에서 1.0이면 불안정적인 상태다
Abstractness
  Interface(Abstract) 와 Concrete Class를 비교

A = (#abstract classes / total # of classes)
  •Abstract class = interface, abstract다 포함
  •Total # class = abstract class + concrete class
  •0 이면 concrete class만 있다.
  •1 이면 abstract class만 있다.
다시 보는 그래프




        다른데서 많이 쓰는
         녀석이니 조금 더
        abstract를 높여야
               돼!
그 외 용어

•Tangled Complexity
 •순환 참조가 있어 Boundary를 깰 때

•Cyclomatic Complexity
 •분기 문이 많아 hotspot이 될 가망성이 높은 곳
경고!!!
환자의 외부 증상만
고치는 의사가 되지 말자!!

이러한 정보는 좋은 가이드일뿐!!

숫자에 의존하다가
오히려 문제가 보이지 않게 된다.
#조언 5 – Kevlin Henney
  “설계의 기준으로
 불확실성을 사용해라!!”
A와 B 사이..

   A와 B 두 가지 선택 중
하나를 결정하려고 시도하는 대신,

“A와 B 사이의 결정을 덜 중요하게
만들기 위해 어떻게 설계해야 할까?”
        고민해라!!
경험…

• 계열사의 함정..
• 경비업체는 무조건 계열사로..
• 하지만.. 입주민의 요청으로..

• Infra성이기에 더 큰 비용을 지출..
전략적 접근 방법

•위험을 분산해라.

•유연성을 보존해라.

•가장 가능성 높은 것부터 먼저 구현.
 단 유연성을 잃지 말 것..
당신의 아키텍쳐(결정)은 변한다.



어떤 컴포넌트(분할 또는 캡슐화)가
 결정에 의존적인 코드로부터
  쉽게 변화를 수용할 수 있게
 잘 나뉘어져 있는지 파악해라.
풀어 말하면.


당신의 결정(아키텍쳐)이
 올바른지 알아보려면,

 비용을 줄일 수 있게
분할 가능한지 살펴봐라!
특히..


 하위 (프레임워크, 인프라) 단 중.
 비지니스와 밀접한 부분이 있으면
     유연하게 만들어라.

레이어 , Interface, Parameter Object
#조언 6 – Mike Brown
“구현 가능한 것만 설계해라”
주어진 문제를 우아하게 해결하기..


•정교한 설계와 추상화 적용

•프로젝트에 신기술 적용

•새로운 패턴 과 프레임워크 적용
많은 부작용을 수반한다.

•개발자의 새로운 학습곡선.

•데모처럼 과연 신기술이 잘 될까?

•개발자의 신뢰를 잃게 된다.

•불필요한 위험요소를 수반.
사례.



차세대 시스템 경험담
 유명 컨설턴트 A와의 경험
기술을 모르는 영업 상무
• 기술을 모르는 영업 상무
 – 비행기에서 유명 컨설턴트와 만나다.
  • CBD에 대해서 이야기를 나눔.
  • 당신의 솔루션이 재사용, 확장 가능해 진다.


 – 귀국 후 차세대 시스템 구축
  • 기존 시스템 유지보수에 지친 개발자들도 환호
  • 개발자의 추천으로 전문가 A를 아키텍트로 섭외.
전문가 A 컨설턴트와의 마찰!
• 새로운 신기술을 적용해야 밴더 사에 잘 보이겠지.
 – 맞지 않는 패턴 적용
   • Enterprise Pattern을 임베디드 시스템에 적용.

 – 정식 버전이 나오지 않은 신기술을 적용
   • 실시간성이 보장되어야 하는 시스템에서 첫 통신시 14초가 걸
     림.
   • 개발자들 왈: “임베디드 시스템 특성을 몰라? … “

 – 기존 기술에 익숙한 개발자들의 반발
   • 무엇이 좋아질지 모르는데 왜 바꿔?
   • 과연 이렇게 잘게 나누면 좋아질까?
결과!
• PM은 왜 일정이 연기되냐며 개발자 윽박
  지르기!
• 컨설턴트 조직은 계약만료 후 나 몰라라 사
  라짐.

• 결국 프로젝트 6개월 연기!
• 시스템 오픈 후 여기 저기 문제 떠짐.
#조언 7 – Mark Ramm
가장 큰 문제는 기술이 아니다.
지금도 어디선가
   실패하고 있는 프로젝트.

•기술의 잘못된 선택?
 •Java대신 Ruby를 선택해서..
 •Linux 대신 Windows를 사용해서..

•문제가 정말 어려워서?
모든 것은..



It’s all about people.
사람에 관한 것이다.
대화를 해라.
• 대화의 기술
 – 정면 대결이 아니라 대화라는 관점에서 접근해라
   • 사람들의 장점을 고려하고 대화해라.

 – 여러분의 태도가 올바로 갖춰진 후에만 대화를 시
   도해라
   • 화가 나거나 짜증난 상태에서 대화하지 말아라

 – 회의 시 침묵하는 사람들의 의견을 이끌어 내라.
   • 특정 사람에게만 발언권이 모이지 않게 해라.
   • 모든 사람의 관점을 다 들어보아라.
#조언 8 – Niclas Nilsson
 “반복 작업과 싸워라!”
생산성을 저해하는 이유..


•복제는 악이다.

•반복되는 작업.
계속되는 반복과의 싸움..




김국현의 낭만 IT - 후기
Architect가 줄여줘야하는 반복 작업



     전 Architect 입장에서
         개발자에게
    박수받을 만한 기법들을
      전달하겠습니다.
EA의 간략한 소개.
• UML 2.1 Full 지원
• 모델링 정보를 다양한 DBMS와 연동하여 저장가능
• 형식을 파괴하는 모델링 지원
    – Use Case에서도 Class Diagram의 요소들을 사용가능
• 다양한 언어를 지원
    – C++, C#, Delphi, Java, VB, VB.NET, PHP, Python
•   강력한 코드 탬플릿 생성 기능
•   테스팅 생성및 관리 (기존 Unit Testing 과 연동됨)
•   강력한 역공학 기능
•   다양한 Plug-in 지원
•   가장 저렴한 가격 1 Copy당 20만원 ~ 30만원 사이
                                                       73
EA의 장점.
강력한 코드 템플릿 생성 기능

몇 가지 Plug-in 소개

Legacy System을 위한 역 공학

문서 자동 생성 템플릿 소개

통합 개발 환경 구축 방법
                         74
Code Template




                75
1. StreoType 생성
• Setting – UML – Streotypes




                               76
2. 클래스 설계 후 StreoType 할당




                           77
3. 메소드 속성에 맞는 태깅생성
• 예를 들어 현재 재고를 파악하는 메소드
  는 Database에서 데이터를 가져오는
  (Get) 타입인 경우.




                       78
4. 코드 생성 탬플릿 작성
    • Settings – Code Generation Templates
  다양한                                   생성할 코드
 언어 선택                                    입력



생성할 코드 템
   플릿
Namespace,
  Class,
Operation 등




스트레오 타입
별 템플릿을 지
    정
                                             79
스트레오 타입 코드 템플릿 추가




                80
스트레오 템플릿 추가

• Import Section
  – DLL 이나 Namespace를 추가하는 부분


• Operation Body
  – 메소드 구현 부에 사용자 코드를 추가 함




                                81
간단한 예 - OperationBody
%if opTag:"DataAccessType" =="get" % //데이터를 얻어오는 쿼리
IDataReader reader = null;
%opReturnType% retVal = new %opReturnType%();
try
{
    // 1. Create the Database object, using the default database service.
    Database db = DatabaseFactory.CreateDatabase();
       log.Debug("Create Database Factory");

    // 2. Create DB Command
       string sqlCommand = "$queryName";
        dbCommand = db.GetStoredProcCommand(sqlCommand);
       log.Debug("GetStoredProcCommand(" + sqlCommand + ")");
        ….
} %elseIf opTag:"DataAccessType" =="set"% //데이터를 쓰는 쿼리
DbConnection connection = null;
UInt32 retVal = 0;
try
{ ……..


                                                                            82
                                                                                 82
Reverse Engineering




                      83
통합 개발 환경 구축하기




                84
통합 개발 환경 구축하기




                85
개발 환경 구축
– 프로세스로 디버깅 하기




                 86
프로세스로 디버깅하기




              87
디버깅 내용을
Sequence Diagram으로 생성




                        88
디버깅 내용을
Sequence Diagram으로 생성




                        89
Documentation




                90
다양한 포멧의 문서 제공




                91
문서 – Class및 Sequece




                      92
UNIT TESTING




               93
Unit Testing과 연동됨
• 현재 xUnit (JUnit, Nunit) 형태로 생성및
  관리가 가능함.
• 다른 Unit Test는 Package Script로 연동
  가능.




                                     94
Visual Studio 내장
 UnitTest 셋팅법




                   95
연동된 Unit Test




                96
문서 – Testing Report




                      97
#조언 9 – Evan Cofsky
“드월프, 엘프, 마법사 그리고 왕”
반지의 제왕 캐릭터.
반지의 제왕 캐릭터.
       드워프 - 근면한 일꾼 ,
       동굴 속의 어두운 고독 속에서
       꾸준히 산출물을 만드는 자


엘프 – 천부적인 재능
우아, 교양있으며, 다른 종족이
하지 못하는 마법을 만들어 냄.
반지의 제왕 캐릭터.

       마법사 – 강력한 종족,
       엘프와 달리 마법의 강력함과
       속성을 깊이 파악해, 놀라운 능
       력을 발휘

왕 – 보잘 것 없는 왕
단, 다른 종족과 무엇을 해야 할
지 아는 몽상가 (비전을 제시)
왕의 역할
• 왕 (아키텍트)는 모든 종족과 친해야 함

• 아키텍쳐가 하나의 캐릭터(팀원)에게만 흘
  러가지 않도록 균형을 맞추어야 함

• 한가지 퀘스트(도전과제)를 위해 모든 종족
  (이해 당사자)를 이끌어, 같이 일할수 있도
  록 도와야 한다.
서로 보완적인 능력을
     가진 팀 만들기.




Bill Gross : http://bit.ly/u4AV3r
      참고자료- 에스티마님의 글
Bill Gross
• 미국에서 가장 유명한 Serial Entrepreneur (연속
  해서 새 사업체를 설립하는 기업가).

• 많은 Startup을 창업하면서, 얻은 그가 보는 성공
  하는 팀의 조건

• 4가지 유형의 성격을 가진 사람들이 서로 조화를
  이룬 팀은 성공한다.
사람의 유형.
Entrepreneur – 창업가

새로운 것을 발명하는 사람. 큰 그림을 볼 수 있는
사람. 미래를 미리 준비하는 사람.


Administrator – 관리자

질서를 만드는 사람. 관료적일 수는 있지만 일이
제대로 되도록 룰을 만들고 실행하는 사람
사람의 유형.

Producer - 실제 제품을 만드는 사람


Integrator - 다른 세가지 유형의 사람들을
잘 이해하고 그들이 잘 지낼 수 있도록 도
와주는 사람.
4가지 유형이
다 모인다고 성공할까?

지저분한 창문…
더러워진 창문을 보며..
• E(창업가)는 창을 가르키며 이렇게 이야기한다.

 “저기를 보라고!! 저기 우리가 빌딩을 지을 수 있
 는 주차장이 있는데…”

 그는 창문자체는 보지도 않고 저 멀리 보이는 미
 래를 신이 나서 떠든다.
더러워진 창문을 보며..
• P(생산자)는 창문을 보며 …

“저기 창문에 보이는 스크래치와 더러워진 유리를
 보라고. 우린 저것을 빨리 청소해야 해!!”
더러워진 창문을 보며..
• A (관리자)는

“아니 그러지 말고 우리는 더러워진 창문이 보일
 경우 사람들이 총무과에 알릴 수 있도록 신청양식
 을 만들어 야해!!

 그럼 그 양식을 통해 신청을 받고 순차적으로 처
 리하면 돼”
더러워진 창문을 보며..
• I (통합자)는
  아무 말도 하지않고 다른 3사람을 보면서…

 “저 3사람의 머리 속을 들여다보고 싶다니까”
피플웨어….
성공하는 팀의 이상한 공통 조건??
#조언 10 – 김동열
“정경유착(政經癒着)”
아키텍트의 정치
• 아키텍트는 비즈니스 목표에 맞는 시스템
  을 만들기 위해,기술과 관련된 수많은 의사
  결정을 하는 사람입니다.

• 이해관계자 사이에서 정당성(rightness), 타
  당성(rational)을 바탕으로 이해관계를 조율
  하고 설득해야함.
제품 영업 담당자
• 효과적인 마케팅과 판매활동을 통해 이윤
  을 창출해야 하는 "경제"적인 역할을 담당.

• 맨발로 지내온 아프리카 원주민에게 구두
  를 팔고, 에스키모 인에게 냉장고를 파는 영
  업인에게 '사기 쳤다'고 이야기 하지는 않습
  니다.

• 오히려 새로운 시장을 개척했다고 말함.
사례.


아키텍트와 영업간의
이해관계가 맞을 경우.
영업 부장의 압력.
• EJB 기반의 WAS
 – EJB와 관계형 기반의 DB 시스템에 유리

 – 요구사항
   • CORBA도 넣어라
   • 최신제품이니, 객체 지향 DB도 쓰자

 – 결론 “넣긴 넣었다. 하지만..”
   • CORBA를 어디에 적용했는지 기억도 안남.
   • 객체지향 DB일부만 적용
또 다른 Vasa호
• 미션이 완전히 동일한 시스템은 없다.
• 모든 시스템의 목표를 만족시켜줄 아키텍
  쳐 , 솔루션은 존재하지 않는다.

• 만들수 있겠지만, 새로운 장애물이 나올경
  우 침몰하는 또다른 Vasa호가 될 뿐이다.
결론.
• 아키텍트는
 올바른 “정치”를 하기 위해,
 정경유착의 고리를 끊고,
 특정 제품에 자유로울 필요가 있습니다.
#조언 11 – Eben Hewitt
고객의 고객.. 고객을 알아라.
2011년 6월 24일

  Google은
두 개의 사업을
포기한다고 발표.
또 하나는…
Smart Grid란?
Google Powermeter 와
   스마트그리드
Google이 하고 싶은 것..
Google Powermeter의 파트너들..

   San Diego Gas & Electric? (California)
   TXU Energy (Texas)
   JEA (Florida)
   Reliance Energy (India)
   Wisconsin Public Service Corporation (Wisconsin)
   White River Valley Electric Cooperative (Missouri)
   Toronto Hydro Electric System Limited (Canada)
   Glasgow EPB (Kentucky)
하지만..
예상 외의 적수를 만나다..
Google의 전략
                            3rd Party


               OpenAPI
 Utility
Provider



              Web Service

                            Customer
OPower의 전략       3rd Party


               OpenAPI
 Utility
Provider
                   Web
                  Service

                Paper
                            Customer
OpenAPI를 이긴
    Paper
Personal Touch
Eager's innovation

                       C
                       H
                       A
                       S
                       M
              Early
             Adapter        Early      Late
                           Majority   Majority   Laggards
Innovators
             13.5 %                               16.0 %
   2.5%                    34.0 %     34.0 %
Know your customer
조그만 차이가
큰 차이를 가져온다.
Plant the seeds.
OPower의 늘어나는 점유율..




    60+ 이상의 전력회사,
 미국 Top 10 전력회사와 Cowork
Guru on your side.
         &
     Bit Jolt.
얼마 지나
 2010년 10월에


5000만 달러
여러 투자자로 부터
  펀딩 받음.
2011년 6월 24일

  Google은
Powermeter를
포기한다고 발표.
#조언 12 – ???
“컨설팅과 사과 이야기”
컨설턴트와 컨설팅 받는 사람

컨설턴트는 이해당사자들 모두를 이해하고
어떠한 benefit을 줄수 있는지 설명해야 한다.

컨설팅 받는 사람은
무조건 적인 저항보다는
더 도메인 전문가이니, 협상을 해 나가야 한다.
감사합니다.

More Related Content

What's hot

소프트웨어 아키텍처
소프트웨어 아키텍처소프트웨어 아키텍처
소프트웨어 아키텍처
영기 김
 
Wpfと非同期
Wpfと非同期Wpfと非同期
Wpfと非同期yone64
 
Docker volume基礎/Project Longhorn紹介
Docker volume基礎/Project Longhorn紹介Docker volume基礎/Project Longhorn紹介
Docker volume基礎/Project Longhorn紹介
Masahito Zembutsu
 
トランクベース開発を活用して爆速に開発した話
トランクベース開発を活用して爆速に開発した話トランクベース開発を活用して爆速に開発した話
トランクベース開発を活用して爆速に開発した話
Tier_IV
 
Domain storytelling-one size fit all process
Domain storytelling-one size fit all processDomain storytelling-one size fit all process
Domain storytelling-one size fit all process
Michael Chen
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
増田 亨
 
Ooc 2020
Ooc 2020Ooc 2020
Ooc 2020
Zenji Kanzaki
 
Qlik TechTalk What’s New May 2022リリースのご紹介
Qlik TechTalk What’s New May 2022リリースのご紹介Qlik TechTalk What’s New May 2022リリースのご紹介
Qlik TechTalk What’s New May 2022リリースのご紹介
QlikPresalesJapan
 
ジェネリクスの基礎と クラス設計への応用
ジェネリクスの基礎とクラス設計への応用ジェネリクスの基礎とクラス設計への応用
ジェネリクスの基礎と クラス設計への応用
nagise
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
 
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Springドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
増田 亨
 
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
 
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチレガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
増田 亨
 
deep dive distributed tracing
deep dive distributed tracingdeep dive distributed tracing
deep dive distributed tracing
Takayoshi Tanaka
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
Junyi Song
 
RDRA DDD Agile
RDRA DDD AgileRDRA DDD Agile
RDRA DDD Agile
増田 亨
 
Real Life Clean Architecture
Real Life Clean ArchitectureReal Life Clean Architecture
Real Life Clean Architecture
Mattia Battiston
 
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタはじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
 

What's hot (20)

소프트웨어 아키텍처
소프트웨어 아키텍처소프트웨어 아키텍처
소프트웨어 아키텍처
 
Wpfと非同期
Wpfと非同期Wpfと非同期
Wpfと非同期
 
Docker volume基礎/Project Longhorn紹介
Docker volume基礎/Project Longhorn紹介Docker volume基礎/Project Longhorn紹介
Docker volume基礎/Project Longhorn紹介
 
トランクベース開発を活用して爆速に開発した話
トランクベース開発を活用して爆速に開発した話トランクベース開発を活用して爆速に開発した話
トランクベース開発を活用して爆速に開発した話
 
Domain storytelling-one size fit all process
Domain storytelling-one size fit all processDomain storytelling-one size fit all process
Domain storytelling-one size fit all process
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
 
Ooc 2020
Ooc 2020Ooc 2020
Ooc 2020
 
Qlik TechTalk What’s New May 2022リリースのご紹介
Qlik TechTalk What’s New May 2022リリースのご紹介Qlik TechTalk What’s New May 2022リリースのご紹介
Qlik TechTalk What’s New May 2022リリースのご紹介
 
ジェネリクスの基礎と クラス設計への応用
ジェネリクスの基礎とクラス設計への応用ジェネリクスの基礎とクラス設計への応用
ジェネリクスの基礎と クラス設計への応用
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
 
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Springドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
 
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
 
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチレガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
 
deep dive distributed tracing
deep dive distributed tracingdeep dive distributed tracing
deep dive distributed tracing
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
 
RDRA DDD Agile
RDRA DDD AgileRDRA DDD Agile
RDRA DDD Agile
 
Real Life Clean Architecture
Real Life Clean ArchitectureReal Life Clean Architecture
Real Life Clean Architecture
 
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタはじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
 

Viewers also liked

1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스
Terry Cho
 
소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화
영기 김
 
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
Terry Cho
 
Bug sense 분석
Bug sense 분석Bug sense 분석
Bug sense 분석
logdog
 
03. it정보화전략-솔루션 도입
03. it정보화전략-솔루션 도입03. it정보화전략-솔루션 도입
03. it정보화전략-솔루션 도입
InGuen Hwang
 
유지보수성이 sw의 품질이다.
유지보수성이 sw의 품질이다.유지보수성이 sw의 품질이다.
유지보수성이 sw의 품질이다.
도형 임
 
IT표준화-아키텍처,프로세스-2015.09.30
IT표준화-아키텍처,프로세스-2015.09.30IT표준화-아키텍처,프로세스-2015.09.30
IT표준화-아키텍처,프로세스-2015.09.30
InGuen Hwang
 
ISP(Information Strategy Planning) Output
ISP(Information Strategy Planning) OutputISP(Information Strategy Planning) Output
ISP(Information Strategy Planning) Output
Il-woo Lee
 
고품질 Sw와 개발문화
고품질 Sw와 개발문화고품질 Sw와 개발문화
고품질 Sw와 개발문화
도형 임
 
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
한국디자인진흥원 공공서비스디자인PD
 
Devrookie Study / TA20110730
Devrookie Study / TA20110730Devrookie Study / TA20110730
Devrookie Study / TA20110730Yong-nam Kim
 
01. it정보화전략-it 기술기반 도입 계획
01. it정보화전략-it 기술기반 도입 계획01. it정보화전략-it 기술기반 도입 계획
01. it정보화전략-it 기술기반 도입 계획
InGuen Hwang
 
테스트 케이스와 SW 품질
테스트 케이스와 SW 품질테스트 케이스와 SW 품질
테스트 케이스와 SW 품질
도형 임
 
IT전략계획- 03.IT 도입계획
IT전략계획- 03.IT 도입계획IT전략계획- 03.IT 도입계획
IT전략계획- 03.IT 도입계획
InGuen Hwang
 
Change Requirement
Change RequirementChange Requirement
Change Requirement
DaeMyung Kang
 
IT전략계획 - 01.사업계획
IT전략계획 - 01.사업계획IT전략계획 - 01.사업계획
IT전략계획 - 01.사업계획
InGuen Hwang
 
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
2015 SW마에스트로 100+ 컨퍼런스
 
01 페이스북특강 (daum it pro bono) 140308
01 페이스북특강 (daum it pro bono) 14030801 페이스북특강 (daum it pro bono) 140308
01 페이스북특강 (daum it pro bono) 140308csr_hope
 
Selenium for XE
Selenium for XESelenium for XE
Selenium for XE
승훈 오
 
SW Maestro 1-1 Project Keynote PDF
SW Maestro 1-1 Project Keynote PDFSW Maestro 1-1 Project Keynote PDF
SW Maestro 1-1 Project Keynote PDF
진수 한
 

Viewers also liked (20)

1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스
 
소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화
 
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
 
Bug sense 분석
Bug sense 분석Bug sense 분석
Bug sense 분석
 
03. it정보화전략-솔루션 도입
03. it정보화전략-솔루션 도입03. it정보화전략-솔루션 도입
03. it정보화전략-솔루션 도입
 
유지보수성이 sw의 품질이다.
유지보수성이 sw의 품질이다.유지보수성이 sw의 품질이다.
유지보수성이 sw의 품질이다.
 
IT표준화-아키텍처,프로세스-2015.09.30
IT표준화-아키텍처,프로세스-2015.09.30IT표준화-아키텍처,프로세스-2015.09.30
IT표준화-아키텍처,프로세스-2015.09.30
 
ISP(Information Strategy Planning) Output
ISP(Information Strategy Planning) OutputISP(Information Strategy Planning) Output
ISP(Information Strategy Planning) Output
 
고품질 Sw와 개발문화
고품질 Sw와 개발문화고품질 Sw와 개발문화
고품질 Sw와 개발문화
 
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
통합재정정보 공개시스템 구축 - 기재부 정부3.0 브랜드과제 국민디자인단 운영 결과
 
Devrookie Study / TA20110730
Devrookie Study / TA20110730Devrookie Study / TA20110730
Devrookie Study / TA20110730
 
01. it정보화전략-it 기술기반 도입 계획
01. it정보화전략-it 기술기반 도입 계획01. it정보화전략-it 기술기반 도입 계획
01. it정보화전략-it 기술기반 도입 계획
 
테스트 케이스와 SW 품질
테스트 케이스와 SW 품질테스트 케이스와 SW 품질
테스트 케이스와 SW 품질
 
IT전략계획- 03.IT 도입계획
IT전략계획- 03.IT 도입계획IT전략계획- 03.IT 도입계획
IT전략계획- 03.IT 도입계획
 
Change Requirement
Change RequirementChange Requirement
Change Requirement
 
IT전략계획 - 01.사업계획
IT전략계획 - 01.사업계획IT전략계획 - 01.사업계획
IT전략계획 - 01.사업계획
 
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
2015 SW마에스트로 100+ 컨퍼런스_오픈스택 Swift로 시작하는 오픈소스 분석 삽질기
 
01 페이스북특강 (daum it pro bono) 140308
01 페이스북특강 (daum it pro bono) 14030801 페이스북특강 (daum it pro bono) 140308
01 페이스북특강 (daum it pro bono) 140308
 
Selenium for XE
Selenium for XESelenium for XE
Selenium for XE
 
SW Maestro 1-1 Project Keynote PDF
SW Maestro 1-1 Project Keynote PDFSW Maestro 1-1 Project Keynote PDF
SW Maestro 1-1 Project Keynote PDF
 

Similar to 아키텍트가 알아야 할 12/97가지

Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Sa-ryong Kang
 
4. 대용량 아키텍쳐 설계 패턴
4. 대용량 아키텍쳐 설계 패턴4. 대용량 아키텍쳐 설계 패턴
4. 대용량 아키텍쳐 설계 패턴
Terry Cho
 
시간 있으면 설계나 합시다
시간 있으면 설계나 합시다시간 있으면 설계나 합시다
시간 있으면 설계나 합시다codevania
 
분석과 설계
분석과 설계분석과 설계
분석과 설계
Haeil Yi
 
[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트
Chanwoong Kim
 
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
Chris Ohk
 
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
Terry Cho
 
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
Taekyu Lim
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
Amazon Web Services Korea
 
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
Gyuwon Yi
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
중선 곽
 
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
AWSKRUG - AWS한국사용자모임
 
실용주의 아키텍트
실용주의 아키텍트실용주의 아키텍트
실용주의 아키텍트
Haeil Yi
 
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
Yi-kwon Hwang
 
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
OpenStack Korea Community
 
해외 사례로 보는 Billing for OpenStack Solution
해외 사례로 보는 Billing for OpenStack Solution해외 사례로 보는 Billing for OpenStack Solution
해외 사례로 보는 Billing for OpenStack Solution
Nalee Jang
 
객체지향프로그래밍 특강
객체지향프로그래밍 특강객체지향프로그래밍 특강
객체지향프로그래밍 특강
uEngine Solutions
 
멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면
Byeongsu Kang
 
C++ 코딩의 정석.pptx
C++ 코딩의 정석.pptxC++ 코딩의 정석.pptx
C++ 코딩의 정석.pptx
sung suk seo
 
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
정민 안
 

Similar to 아키텍트가 알아야 할 12/97가지 (20)

Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
 
4. 대용량 아키텍쳐 설계 패턴
4. 대용량 아키텍쳐 설계 패턴4. 대용량 아키텍쳐 설계 패턴
4. 대용량 아키텍쳐 설계 패턴
 
시간 있으면 설계나 합시다
시간 있으면 설계나 합시다시간 있으면 설계나 합시다
시간 있으면 설계나 합시다
 
분석과 설계
분석과 설계분석과 설계
분석과 설계
 
[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트
 
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기
 
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
 
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
[2022]Flutter_IO_Extended_Korea_멀티모듈을활용한플러터클린아키텍처_...
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
 
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
 
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
온라인 주문 서비스를 서버리스 아키텍쳐로 구축하기 - 김태우(Classmethod) :: AWS Community Day Online 2020
 
실용주의 아키텍트
실용주의 아키텍트실용주의 아키텍트
실용주의 아키텍트
 
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
 
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
[OpenStack Days Korea 2016] Track4 - 해외 사례로 보는 OpenStack Billing System
 
해외 사례로 보는 Billing for OpenStack Solution
해외 사례로 보는 Billing for OpenStack Solution해외 사례로 보는 Billing for OpenStack Solution
해외 사례로 보는 Billing for OpenStack Solution
 
객체지향프로그래밍 특강
객체지향프로그래밍 특강객체지향프로그래밍 특강
객체지향프로그래밍 특강
 
멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면
 
C++ 코딩의 정석.pptx
C++ 코딩의 정석.pptxC++ 코딩의 정석.pptx
C++ 코딩의 정석.pptx
 
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
 

More from YoungSu Son

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
YoungSu Son
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
YoungSu Son
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
YoungSu Son
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
YoungSu Son
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
YoungSu Son
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
YoungSu Son
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
YoungSu Son
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
YoungSu Son
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
YoungSu Son
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
YoungSu Son
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
YoungSu Son
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
YoungSu Son
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
YoungSu Son
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
YoungSu Son
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
YoungSu Son
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
YoungSu Son
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
YoungSu Son
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
YoungSu Son
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
YoungSu Son
 

More from YoungSu Son (20)

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
 

아키텍트가 알아야 할 12/97가지

  • 1.
  • 4. 현업이 요구하는 기괴한 아키텍트의 역할. http://vizend.tistory.com/37
  • 6. 그 누구의 일도 아니면..
  • 7. 여러분이 만난 S/W Architect. Enterprise UX Architect Architect Data Test Architect Architect Service Security Architect Architect Business Infrastructure Architect Architect Application … Architect Architect ??
  • 9. 요구사항 설계 개발/운영 자세 가장 큰 문제는 Vasa호 이야기 1000 피트의 뷰 정경유착 기술이 아니다. 아키텍팅은 균형 A와 B의 사이의 반복 작업과 싸 고객의 고객 에 관한 것. 결정 워라! 구현 가능한 것 드워프.엘프, 마 사과와 컨설팅 걸어다니는 해골 만 설계해라. 법사 그리고 왕 이야기
  • 10. 왜 우리에겐 이런 일이 발생할까?
  • 11. #조언 1 Mark Richards의 Vasa호 이야기
  • 12. Vasa호 이야기 스웨덴 왕실의 위엄을 온 세계에 알리고 덴마크와 동유럽을 침공하기 위해 국왕이 직접 Vasa호의 설계에 참여. 아돌프 구스타프 2세
  • 13. 국왕으로 인해 변경된 요구사항 하는 김에 화려한 사람을 많이 태워야 함포 64문 장식도 달자! 겠어! 갑판 확장!! 금으로 도금한 병 호화로운 장식 채 원래는 32문! 사 조각상 1000여 우기 개! 스웨던 왕실 상 세계최초로 상하 많은 탑승인원 징!! 두마리의 사 2열로 함포 배치 450명! 자 등..
  • 15. 사상 최대의 사망자? 왜? 배 출항식 탑승인원 구성 귀족 100명 선원 50명
  • 16. 오히려 다행! 덕분에, 전수식 후 항해하기로 했던 선원과 군인 450명은 목숨을 건짐.
  • 17. 결론 Vasa호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다
  • 19. #조언 2 - Randy Stafford의 “아키텍팅이란 균형에 관한 것이다.”
  • 20. 요구사항 정하기. 출처 - IEEE1471 Korean Extension – 소프트웨어 아키텍처 정의(안)
  • 24. Context 단, QAW, ATAM은 구축하는 시스템이 명확하고, 이해당사자들이 시스템을 이해하고 있을 때 적용 가능하다.
  • 25. Context 이해 당사자들간의 정치관계를 조심해라. 또한 투표권을 전체 팀원에 적절히 배분해라.
  • 26. #조언 3 – Alistair Cockburn 요구사항이 명확하지 않을 때. 걸어 다니는 해골로 시작해라
  • 28. 사례. 경영 이론 시스템을 적용해 의사 결정 도구 시스템을 구축하는 프로젝트 신사웅님 - 요구사항이 명확하지 않을 때..
  • 29. 문제 발생 고객 • 경영 이론을 시스템으로 구축한 경험 전무 • 단지 경영진으로부터 방향성만 제시 받음 전산팀 • 안정화된 시스템에 새로운 기능 /프로세스를 추가해본 경험밖에 없다. • 구체적인 요구사항이 없어 설명 한 경영 이론에만 의존해 시스 템 구축
  • 30. 갈등 발생!! • 진행과정을 리뷰 하면서, 갈등 시작 • 전산팀은 나름대로 요구사항 정리 후 개발 – 시연을 하게 되면 전혀 다른 요구사항이 발생 – 고객이 원하는 시스템이 아니었다는 결론 – 전산팀에서 아이디어를 고민해 제시해 달라!! • 업무적인 갈등을 넘어 감정의 갈등으로..
  • 31. 상황정리. 고객의 입장에서는 최종 보이는 결과는 UI 실제 필요한 요구사항 파악 불가 QoS – (비기능적인 요구사항) 파악 불가 선정한 Framework의 사용성, 적합성 모름. 비즈니스 도메인에 대한 정보 예측 불가 구축 후 발생하는 여러 문제들을 파악 불가
  • 33. 걸어 다니는 해골. Prototyping보다 한 단계 앞선 모델. 종단(예를 들면 UI~DB까지) 간을 오가 며 수행되는 가벼운 구현체. 모든 호출 경로를 실험할 수 있게 작동 하는 작은 시스템.
  • 34. 걸어 다니는 해골. 모든 종단을 다 관통하는 주요 시 나리오를 몇 개 만들어라. 그러다 보면, 시스템의 외적/내적 인 요구사항을 자연스럽게 도출 할 수 있다.
  • 35. #조언 4 – Erick Doernenburg “1000피트의 뷰를 가져라”
  • 40. 제한된 코드로 프로젝트가 잘되고 있는지 판단은?
  • 41. 3만 피트 vs 0 피트의 뷰. 3만 피트 • 다이어그램의 Line의 의미는? • 의존성? • 데이터 흐름? • 버스와 같은 공유자원? 0 피트 • 너무 상세한 정보임. • 전체적인 구조를 보지 못함.
  • 43. STAN (Structure Analysis for Java) STAN - http://stan4j.com/eclipse/eclipse-integration.html
  • 44. Robert C. Martin의 그래프
  • 45. Instability •패키지의 움직일 수 있는 여력을 판단하는 지표 •다른 패키지에 영향을 미치지 않고, 해당 패키지를 쉽게 변경 할 수 있는가? •Instability I = Ce / (Ca+Ce) •Ce = Efferent Coupling (Ingoing Dependencies) •Ca = Afferent Coupling (Outgoing Dependencies )
  • 46. Instability Instability I = Ce / (Ca+Ce) 당신의 패키지가 다른 사람이 많이 쓴다면, 즉 Outgoing, Ca가 많다면, 여러분의 패키지는 변경하기 어렵다. 반대로 Outgoing하는 Ca가 적고, Ingoing(다른 패키지만 사용만 하는) Ce, 여러분의 패키지는 쉽게 변경해도 된다. 즉 0.0에서 0.3이면 안정적인 버전, 0.7에서 1.0이면 불안정적인 상태다
  • 47. Abstractness Interface(Abstract) 와 Concrete Class를 비교 A = (#abstract classes / total # of classes) •Abstract class = interface, abstract다 포함 •Total # class = abstract class + concrete class •0 이면 concrete class만 있다. •1 이면 abstract class만 있다.
  • 48. 다시 보는 그래프 다른데서 많이 쓰는 녀석이니 조금 더 abstract를 높여야 돼!
  • 49. 그 외 용어 •Tangled Complexity •순환 참조가 있어 Boundary를 깰 때 •Cyclomatic Complexity •분기 문이 많아 hotspot이 될 가망성이 높은 곳
  • 50. 경고!!! 환자의 외부 증상만 고치는 의사가 되지 말자!! 이러한 정보는 좋은 가이드일뿐!! 숫자에 의존하다가 오히려 문제가 보이지 않게 된다.
  • 51. #조언 5 – Kevlin Henney “설계의 기준으로 불확실성을 사용해라!!”
  • 52. A와 B 사이.. A와 B 두 가지 선택 중 하나를 결정하려고 시도하는 대신, “A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할까?” 고민해라!!
  • 53. 경험… • 계열사의 함정.. • 경비업체는 무조건 계열사로.. • 하지만.. 입주민의 요청으로.. • Infra성이기에 더 큰 비용을 지출..
  • 54. 전략적 접근 방법 •위험을 분산해라. •유연성을 보존해라. •가장 가능성 높은 것부터 먼저 구현. 단 유연성을 잃지 말 것..
  • 55. 당신의 아키텍쳐(결정)은 변한다. 어떤 컴포넌트(분할 또는 캡슐화)가 결정에 의존적인 코드로부터 쉽게 변화를 수용할 수 있게 잘 나뉘어져 있는지 파악해라.
  • 56. 풀어 말하면. 당신의 결정(아키텍쳐)이 올바른지 알아보려면, 비용을 줄일 수 있게 분할 가능한지 살펴봐라!
  • 57. 특히.. 하위 (프레임워크, 인프라) 단 중. 비지니스와 밀접한 부분이 있으면 유연하게 만들어라. 레이어 , Interface, Parameter Object
  • 58. #조언 6 – Mike Brown “구현 가능한 것만 설계해라”
  • 59. 주어진 문제를 우아하게 해결하기.. •정교한 설계와 추상화 적용 •프로젝트에 신기술 적용 •새로운 패턴 과 프레임워크 적용
  • 60. 많은 부작용을 수반한다. •개발자의 새로운 학습곡선. •데모처럼 과연 신기술이 잘 될까? •개발자의 신뢰를 잃게 된다. •불필요한 위험요소를 수반.
  • 61. 사례. 차세대 시스템 경험담 유명 컨설턴트 A와의 경험
  • 62. 기술을 모르는 영업 상무 • 기술을 모르는 영업 상무 – 비행기에서 유명 컨설턴트와 만나다. • CBD에 대해서 이야기를 나눔. • 당신의 솔루션이 재사용, 확장 가능해 진다. – 귀국 후 차세대 시스템 구축 • 기존 시스템 유지보수에 지친 개발자들도 환호 • 개발자의 추천으로 전문가 A를 아키텍트로 섭외.
  • 63. 전문가 A 컨설턴트와의 마찰! • 새로운 신기술을 적용해야 밴더 사에 잘 보이겠지. – 맞지 않는 패턴 적용 • Enterprise Pattern을 임베디드 시스템에 적용. – 정식 버전이 나오지 않은 신기술을 적용 • 실시간성이 보장되어야 하는 시스템에서 첫 통신시 14초가 걸 림. • 개발자들 왈: “임베디드 시스템 특성을 몰라? … “ – 기존 기술에 익숙한 개발자들의 반발 • 무엇이 좋아질지 모르는데 왜 바꿔? • 과연 이렇게 잘게 나누면 좋아질까?
  • 64. 결과! • PM은 왜 일정이 연기되냐며 개발자 윽박 지르기! • 컨설턴트 조직은 계약만료 후 나 몰라라 사 라짐. • 결국 프로젝트 6개월 연기! • 시스템 오픈 후 여기 저기 문제 떠짐.
  • 65. #조언 7 – Mark Ramm 가장 큰 문제는 기술이 아니다.
  • 66. 지금도 어디선가 실패하고 있는 프로젝트. •기술의 잘못된 선택? •Java대신 Ruby를 선택해서.. •Linux 대신 Windows를 사용해서.. •문제가 정말 어려워서?
  • 67. 모든 것은.. It’s all about people. 사람에 관한 것이다.
  • 68. 대화를 해라. • 대화의 기술 – 정면 대결이 아니라 대화라는 관점에서 접근해라 • 사람들의 장점을 고려하고 대화해라. – 여러분의 태도가 올바로 갖춰진 후에만 대화를 시 도해라 • 화가 나거나 짜증난 상태에서 대화하지 말아라 – 회의 시 침묵하는 사람들의 의견을 이끌어 내라. • 특정 사람에게만 발언권이 모이지 않게 해라. • 모든 사람의 관점을 다 들어보아라.
  • 69. #조언 8 – Niclas Nilsson “반복 작업과 싸워라!”
  • 70. 생산성을 저해하는 이유.. •복제는 악이다. •반복되는 작업.
  • 72. Architect가 줄여줘야하는 반복 작업 전 Architect 입장에서 개발자에게 박수받을 만한 기법들을 전달하겠습니다.
  • 73. EA의 간략한 소개. • UML 2.1 Full 지원 • 모델링 정보를 다양한 DBMS와 연동하여 저장가능 • 형식을 파괴하는 모델링 지원 – Use Case에서도 Class Diagram의 요소들을 사용가능 • 다양한 언어를 지원 – C++, C#, Delphi, Java, VB, VB.NET, PHP, Python • 강력한 코드 탬플릿 생성 기능 • 테스팅 생성및 관리 (기존 Unit Testing 과 연동됨) • 강력한 역공학 기능 • 다양한 Plug-in 지원 • 가장 저렴한 가격 1 Copy당 20만원 ~ 30만원 사이 73
  • 74. EA의 장점. 강력한 코드 템플릿 생성 기능 몇 가지 Plug-in 소개 Legacy System을 위한 역 공학 문서 자동 생성 템플릿 소개 통합 개발 환경 구축 방법 74
  • 76. 1. StreoType 생성 • Setting – UML – Streotypes 76
  • 77. 2. 클래스 설계 후 StreoType 할당 77
  • 78. 3. 메소드 속성에 맞는 태깅생성 • 예를 들어 현재 재고를 파악하는 메소드 는 Database에서 데이터를 가져오는 (Get) 타입인 경우. 78
  • 79. 4. 코드 생성 탬플릿 작성 • Settings – Code Generation Templates 다양한 생성할 코드 언어 선택 입력 생성할 코드 템 플릿 Namespace, Class, Operation 등 스트레오 타입 별 템플릿을 지 정 79
  • 80. 스트레오 타입 코드 템플릿 추가 80
  • 81. 스트레오 템플릿 추가 • Import Section – DLL 이나 Namespace를 추가하는 부분 • Operation Body – 메소드 구현 부에 사용자 코드를 추가 함 81
  • 82. 간단한 예 - OperationBody %if opTag:"DataAccessType" =="get" % //데이터를 얻어오는 쿼리 IDataReader reader = null; %opReturnType% retVal = new %opReturnType%(); try { // 1. Create the Database object, using the default database service. Database db = DatabaseFactory.CreateDatabase(); log.Debug("Create Database Factory"); // 2. Create DB Command string sqlCommand = "$queryName"; dbCommand = db.GetStoredProcCommand(sqlCommand); log.Debug("GetStoredProcCommand(" + sqlCommand + ")"); …. } %elseIf opTag:"DataAccessType" =="set"% //데이터를 쓰는 쿼리 DbConnection connection = null; UInt32 retVal = 0; try { …….. 82 82
  • 84. 통합 개발 환경 구축하기 84
  • 85. 통합 개발 환경 구축하기 85
  • 86. 개발 환경 구축 – 프로세스로 디버깅 하기 86
  • 92. 문서 – Class및 Sequece 92
  • 94. Unit Testing과 연동됨 • 현재 xUnit (JUnit, Nunit) 형태로 생성및 관리가 가능함. • 다른 Unit Test는 Package Script로 연동 가능. 94
  • 95. Visual Studio 내장 UnitTest 셋팅법 95
  • 97. 문서 – Testing Report 97
  • 98. #조언 9 – Evan Cofsky “드월프, 엘프, 마법사 그리고 왕”
  • 100. 반지의 제왕 캐릭터. 드워프 - 근면한 일꾼 , 동굴 속의 어두운 고독 속에서 꾸준히 산출물을 만드는 자 엘프 – 천부적인 재능 우아, 교양있으며, 다른 종족이 하지 못하는 마법을 만들어 냄.
  • 101. 반지의 제왕 캐릭터. 마법사 – 강력한 종족, 엘프와 달리 마법의 강력함과 속성을 깊이 파악해, 놀라운 능 력을 발휘 왕 – 보잘 것 없는 왕 단, 다른 종족과 무엇을 해야 할 지 아는 몽상가 (비전을 제시)
  • 102. 왕의 역할 • 왕 (아키텍트)는 모든 종족과 친해야 함 • 아키텍쳐가 하나의 캐릭터(팀원)에게만 흘 러가지 않도록 균형을 맞추어야 함 • 한가지 퀘스트(도전과제)를 위해 모든 종족 (이해 당사자)를 이끌어, 같이 일할수 있도 록 도와야 한다.
  • 103. 서로 보완적인 능력을 가진 팀 만들기. Bill Gross : http://bit.ly/u4AV3r 참고자료- 에스티마님의 글
  • 104. Bill Gross • 미국에서 가장 유명한 Serial Entrepreneur (연속 해서 새 사업체를 설립하는 기업가). • 많은 Startup을 창업하면서, 얻은 그가 보는 성공 하는 팀의 조건 • 4가지 유형의 성격을 가진 사람들이 서로 조화를 이룬 팀은 성공한다.
  • 105. 사람의 유형. Entrepreneur – 창업가 새로운 것을 발명하는 사람. 큰 그림을 볼 수 있는 사람. 미래를 미리 준비하는 사람. Administrator – 관리자 질서를 만드는 사람. 관료적일 수는 있지만 일이 제대로 되도록 룰을 만들고 실행하는 사람
  • 106. 사람의 유형. Producer - 실제 제품을 만드는 사람 Integrator - 다른 세가지 유형의 사람들을 잘 이해하고 그들이 잘 지낼 수 있도록 도 와주는 사람.
  • 107. 4가지 유형이 다 모인다고 성공할까? 지저분한 창문…
  • 108. 더러워진 창문을 보며.. • E(창업가)는 창을 가르키며 이렇게 이야기한다. “저기를 보라고!! 저기 우리가 빌딩을 지을 수 있 는 주차장이 있는데…” 그는 창문자체는 보지도 않고 저 멀리 보이는 미 래를 신이 나서 떠든다.
  • 109. 더러워진 창문을 보며.. • P(생산자)는 창문을 보며 … “저기 창문에 보이는 스크래치와 더러워진 유리를 보라고. 우린 저것을 빨리 청소해야 해!!”
  • 110. 더러워진 창문을 보며.. • A (관리자)는 “아니 그러지 말고 우리는 더러워진 창문이 보일 경우 사람들이 총무과에 알릴 수 있도록 신청양식 을 만들어 야해!! 그럼 그 양식을 통해 신청을 받고 순차적으로 처 리하면 돼”
  • 111. 더러워진 창문을 보며.. • I (통합자)는 아무 말도 하지않고 다른 3사람을 보면서… “저 3사람의 머리 속을 들여다보고 싶다니까”
  • 113. #조언 10 – 김동열 “정경유착(政經癒着)”
  • 114. 아키텍트의 정치 • 아키텍트는 비즈니스 목표에 맞는 시스템 을 만들기 위해,기술과 관련된 수많은 의사 결정을 하는 사람입니다. • 이해관계자 사이에서 정당성(rightness), 타 당성(rational)을 바탕으로 이해관계를 조율 하고 설득해야함.
  • 115. 제품 영업 담당자 • 효과적인 마케팅과 판매활동을 통해 이윤 을 창출해야 하는 "경제"적인 역할을 담당. • 맨발로 지내온 아프리카 원주민에게 구두 를 팔고, 에스키모 인에게 냉장고를 파는 영 업인에게 '사기 쳤다'고 이야기 하지는 않습 니다. • 오히려 새로운 시장을 개척했다고 말함.
  • 117. 영업 부장의 압력. • EJB 기반의 WAS – EJB와 관계형 기반의 DB 시스템에 유리 – 요구사항 • CORBA도 넣어라 • 최신제품이니, 객체 지향 DB도 쓰자 – 결론 “넣긴 넣었다. 하지만..” • CORBA를 어디에 적용했는지 기억도 안남. • 객체지향 DB일부만 적용
  • 118. 또 다른 Vasa호 • 미션이 완전히 동일한 시스템은 없다. • 모든 시스템의 목표를 만족시켜줄 아키텍 쳐 , 솔루션은 존재하지 않는다. • 만들수 있겠지만, 새로운 장애물이 나올경 우 침몰하는 또다른 Vasa호가 될 뿐이다.
  • 119. 결론. • 아키텍트는 올바른 “정치”를 하기 위해, 정경유착의 고리를 끊고, 특정 제품에 자유로울 필요가 있습니다.
  • 120. #조언 11 – Eben Hewitt 고객의 고객.. 고객을 알아라.
  • 121. 2011년 6월 24일 Google은 두 개의 사업을 포기한다고 발표.
  • 124. Google Powermeter 와 스마트그리드
  • 126. Google Powermeter의 파트너들..  San Diego Gas & Electric? (California)  TXU Energy (Texas)  JEA (Florida)  Reliance Energy (India)  Wisconsin Public Service Corporation (Wisconsin)  White River Valley Electric Cooperative (Missouri)  Toronto Hydro Electric System Limited (Canada)  Glasgow EPB (Kentucky)
  • 128.
  • 129. Google의 전략 3rd Party OpenAPI Utility Provider Web Service Customer
  • 130. OPower의 전략 3rd Party OpenAPI Utility Provider Web Service Paper Customer
  • 132.
  • 134. Eager's innovation C H A S M Early Adapter Early Late Majority Majority Laggards Innovators 13.5 % 16.0 % 2.5% 34.0 % 34.0 %
  • 137.
  • 139. OPower의 늘어나는 점유율.. 60+ 이상의 전력회사, 미국 Top 10 전력회사와 Cowork
  • 140. Guru on your side. & Bit Jolt.
  • 141. 얼마 지나 2010년 10월에 5000만 달러 여러 투자자로 부터 펀딩 받음.
  • 142. 2011년 6월 24일 Google은 Powermeter를 포기한다고 발표.
  • 143. #조언 12 – ??? “컨설팅과 사과 이야기”
  • 144. 컨설턴트와 컨설팅 받는 사람 컨설턴트는 이해당사자들 모두를 이해하고 어떠한 benefit을 줄수 있는지 설명해야 한다. 컨설팅 받는 사람은 무조건 적인 저항보다는 더 도메인 전문가이니, 협상을 해 나가야 한다.

Editor's Notes

  1. http://blogs.wsj.com/venturecapital/2010/11/29/opower-tallies-50m-amid-smart-meter-backlash/
  2. eager's innovation
  3. http://blogs.wsj.com/venturecapital/2010/11/29/opower-tallies-50m-amid-smart-meter-backlash/