조대협의 블로그

GTM 전략의 이해조대협 (http://bcho.tistory.com)  IT 시스템은 기존의 비즈니스를 지원하거나 또는 IT 서비스 자체가 제품이 되는 경우인데, 이러한 IT 서비스를 설계하기 위해서는 개발하고자 하는 시스템이 제공하는 가치와 그 비즈니스를 이해해야 한다. 비즈니스의 이해가 없이, 비지니스에 활용되는 시스템을 설계 한다는 것은 전체 그림을 보지 못하면서 일부만을 이해하고 그 일부가 전체인 것처럼 이해하고 시스템을 구축하기 때문에, 좋은 시스템이 만들어질 수 없다. 비즈니스에서 제품/서비스를 기획하고, 이를 마케팅,판매하고 측정하는 일련의 계획을 GTM 전략이라고 한다. GTM 전략 GTM(Go-to-Market) 전략은 기업이 새로운 제품이나 서비스를 시장에 성공적으로 출시하고 판매하기..

MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 #1조대협 (http://bcho.tistory.com) MSA(마이크로 서비스 아키텍쳐, 이하 MSA)와 함께 근래에 떠오르고 있는것이 API 게이트 웨이이다. API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능 까지 많은 기능을 담당할 수 있다.API 게이트웨이의 시작은 MSA가 SOA(서비스 지향 아키텍쳐)에서 시작한것 처럼 ESB (Enterprise Service Bus)에서 부터 시작 되었다. 그래서 ESB의 대부분의 컨셉을 많이 승계했는데, ESB의 실패와 단점을 보완해서 만들어진 사상이 API 게이트웨이이다..

대용량 분산 시스템 아키텍쳐 디자인 대용량 분산 시스템에 대한 아키텍쳐 설계에 대한 내용을 공유합니다. 아직 많이 부족합니다. 많은 피드백 부탁드립니다. 1. 아키텍쳐 설계 프로세스 대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론 from Terry Cho 2. 대용량 분산 시스템 아키텍쳐 대용량 분산 아키텍쳐 설계 #2 대용량 분산 시스템 아키텍쳐 디자인 패턴 from Terry Cho 3. 대용량 분산 시스템 아키텍쳐 디자인 패턴 대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐 from Terry Cho 4. 레퍼런스 아키텍쳐 - SOA 대용량 분산 아키텍쳐 설계 #4. soa 아키텍쳐 from Terry Cho 5. 레퍼런스 아키텍쳐 - REST 대용량 분산 아키텍쳐 설계 #5. ..

아키텍트의 종류와 역할 아키텍쳐를 설계 하는 사람은 아키텍트(Architect)라고 한다. 이 아키텍트는 아키텍쳐 설계 프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의된다. 계층 구조를 제외하면 아키텍쳐는 5가지로 분리된다.(http://bcho.tistory.com/667 참조) Business Architecture, Application Architecture, Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개의 역할로 정의된다. Enterprise Architect (EA) Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 진다. 비지니스 이해를 바탕으로 전..

아키텍쳐 아키텍쳐란 무엇일까? 소프트웨어 시스템에 대해서 이야기 하다보면, “아키텍쳐가 어떻다”. “최신 아키텍쳐를 적용했다.” 등 아키텍쳐에 대한 언급이 많다. 그렇다면, 소프트웨어 아키텍쳐에 대한 정의는 무엇일까? http://www.sei.cmu.edu/architecture/start/glossary/community.cfm 를 보면, 수많은 아키텍쳐에 대한 정의가 있다. 지금부터 설명하고자 하는 아키텍쳐에 대한 정의는 다음과 같다. “아키텍쳐는 비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서로, 시스템을 구성하는 컴포넌트와, 그 컴포넌트간의 관계, 그리고, 컴포넌트가 다루는 정보(데이타)를 정의한다.” 또한 소프트웨어 아키텍쳐는 현재의 요구사항뿐 아..

처음에는 프로그래밍이 좋아서 개발자로 시작을 했었고, 나름 벤쳐에서 영업도 해봤고 CTO도 해보고, 프리도 해보고, 그러다가 외국회사에서 엔지니어,컨설턴트,프리세일즈를 거쳐서 아키텍트로 일을 하다가 지금은 프로젝트 메니져를 하고 있습니다. 구축 프로젝트라기 보다는 사업을 만들고 구축까지 End 2 End를 책임지는 과정인데.. 확실히 메니져에 입장이 되보니 생각할것이 훨씬 많아지는 것 같습니다. 그 중에서 가장 중요한 것은 개발팀과 사업부의 중간에서 사업의 당위성을 설득하고 기술과 비지니스 중간의 브릿지 역할을 하는 일입니다. 예전에 프리세일즈 경험이 있어서 요즘 들어 큰 도움이 되고 있습니다. 가장 중요한 것은 비지니스나 사업부 그리고 Executive는 개발이 어쩌고 저쩌고, 기술이 어쨌다는 것이 아..

Microsoft에 근무한지 약 1년이 좀 지났는데, 기대하지 않던 기회가 와서 회사를 다시 한번 옮기게 되었습니다. 좋은 패키지 제안 해주신 모社의 존경하는 임원분께 진심으로 죄송하게 생각합니다. 블로그를 통해서 다시 한번 감사드리고, 어떤 형태로든지 함께 일할 수 있는 기회가 오기를 기대해 봅니다. Microsoft의 지난 1년은 저에게 상당히 의미가 있었던 한해였습니다. 먼저 Java/Unix/Open source 기반의 제 기술 Background를 MS 진영의 기술까지 확장할 수 있었으며, 기술에 대한 편견을 버리고 모든 기술에 대해서 동등하게 바라볼 수 있는 식견을 가질 수 있었습니다. 아울러서 주로 임원 관련 미팅등을 통해서 전통적인 기술 지향적인 사고에서 비지니스를 바라볼 수 있는 능력과 ..

Support engineer를 거쳐서 본격적인 컨설팅을 한지도 대략 3년정도 되가는것 같네요. 예전에는 주로 SA (Solution Architect)의 역할을 맏았습니다. 제품을 가지고 delivery를 어떻게 할까 고민을 하고, 솔루션 기반의 아키텍쳐를 그리는 역할을 합니다. 그러다가 작년 초인가 부터 AA (Application Architect)의 역할을 하고 있습니다. 실제 전체 시스템의 윤곽을 잡고 delivery를 하는 역할입니다. 솔루션에 대한 부분은 파트너나 presales들의 도움을 받아가면서 delivery하는데... 예전에는 제품에 대해서 아주 깊숙한곳까지 속속들이 꿰뚫고 있었는데, 요즘은 제품보다 큰 그림이나 비지니스 모델 그리고 전략에 대해서 많은 고민을 하고 있습니다. 그러다..

요즘 프로젝트가 바쁘다 보니, 블로그에 포스팅할 시간이 없다. REST, ROA (Resource Oriented Architecture), Collaboration, Code Review등 포스팅 하고 싶은 것들이 많은데.. 그나마 시간내서 쓰던 포스팅들도 이번달에는 거의 힘든 상태가 되었다. 아마도 다음달이나 되야, 포스팅들이 올라가지 않을까? 이번 글은 어제 저녁에 써놨던 아키텍트,PM,개발자의 차이 중 2번째로 아키텍트에 대해서 이야기 해보고자 한다. 아키텍트 아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다. 아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다. 비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지..