제 2회 대한민국 커뮤니티 데이에 meetup 세션으로 “아키텍트” 선배 분들을 만나실 수 있습니다.
많은 아키텍트들 중에, 제가 믿고 신뢰할 수 있는 아키텍트 4분을 모시고 토크쇼를 7월 7일 엽니다.

신현묵 이사님, 김동열 소장님, 강승준 책임님, 문용준 아키텍트님.

 

“아키텍트를  말하다” 가 토크쇼의 주제이며, 선배 아키텍트들의 여러가지 고충과 경험을 들어볼 생각입니다.

7월 7일 나눌 토크쇼의 주제

  • 아키텍트의 길을 선택한 이유
  • “자신의 도메인 영역 소개 ( 재미난 에피소드, 도메인 진입의 고통들)”
  • 프로젝트시 겪었던 에피소드
  • “개발자와 아키텍트가 된 후의 차이점 (지식 체계, 만나는 사람들, 하는 일등..)”
  • 아키텍트로 성장하기 위한 패스
  • 아키텍트로써 겪는 고충들
  • 가장 실패한 프로젝트에 대해서
  • 아키텍트가 생각하는 소프트웨어 개발자의 미래
  • 이해 당사자 (고객, 운영, 개발팀 등)와이 에피소드
  • 아키텍트가 되고 싶은 후배들에게 해주고 싶은 이야기들

정말 현업의 아키텍트들에게 이러한 이야기를 들을 경험이 얼마나 있을까요? 많은 참여 바랍니다.

박현철 이사님으로 부터 정말 즐거운 메일이 왔습니다.

일전에 Meet the Architect라는 세미나를 진행해 주셨고, 정말 많은 가르침과 깨달음을 주셨던 박현철 이사님께서 Scrum 세미나를 진행해 주십니다.

산전 수전 다 겪으시고, 풍부한 컨설팅 경험을 가지신 이사님께서 Scrum 세미나라니. 단순히 스터디가 아니라,  현업의 목소리를 들려 주실 것 같습니다.

일전에 Meet the Architect 세미나로 감명을 받으신 분이라면, 한번 다시 찾아 뵙는 것이 어떨까요?

100명 선착순이니 서두르셔서 예약하셔야 될거 같습니다.

세미나  주제 : “Scrum 네~ 이놈!

부제 : “도()를 닦기 위한 Scrum인가? 프로젝트 성공을 위한 Scrum인가?” , 기존 방법론은 방법론이 나빠서 실패하고, Scrum은 사람이 나빠서 실패한다?”

“당신이 Scrum을 진정 좋아한다면, Scrum의 잠재적인 문제를 얼마나 고민했고, 실제 상황에서 이들을 극복하기 위해 얼마나 시도했고 발전시켜왔는가? 당신이 Scrum을 진정 가치가 있다고 생각한다면, Scrum으로 무엇을 했고, 어떤 성과가 있었는가? 도대체… 당신이 진정 Scrum을 좋아한다고, 가치가 있다고 말할 수 있는가?

<<세미나 등록하기>>

http://www.bitacademy.com/etc/semina_list.asp

  계속 읽기

아키텍트가 알아야할 12가지의 Presentation을 공개합니다. 아키텍트가 알아야할 97가지중 제가 선별한 12가지의 내용이 들어가 있으며, 앞으로 +1 씩 더해가면서 점차 내용을 확대하고 다듬을 생각입니다. 많은 분에게 도움이 되셨으면 합니다.  상업적 자료 사용은 금지이며, 저작자의 이름을 공개한 상황에서 사용하는 것은 허락합니다.

“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다.   기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠.   기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.

지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이  아마 한 명 이상 있을 것입니다.

왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?

실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?

대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.

한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.

계속 읽기

dave quick범위는 프로젝트의 크기를 언급합니다.

얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.

소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.

범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.

프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.

직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.

역사[1]는 ,직관이 제안했던 것처럼,  미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의  커뮤니케이션 비용이 들것입니다.

계속 읽기

Keith_braithwaite

건축가에 배워야 하는 교훈들을 여러분과 공유하고자 합니다.

“아키텍쳐는 사회적 행동과 인간 활동의 중요한 극장이다.  — Spiro Kostof”

명시적, 주도적, 기술적으로 자신의 배역(역할)을 아는 아키텍트가 얼마나 있을까요? 오히려 소프트웨어 아키텍트는 이해 당사자 (stake-holders) 사이에서, 서로 의견이 충돌이 발생하는 파벌들의 중재인, 중개인, 조정자 이지 않을까요?

소프트웨어 아키텍트의 일 중 인적 요소(human-factor)에 적절한 가중치를 부여하지[1] 않고, 순수하게 지적인 정신(소프트웨어 설계)을 요구하는 일이 얼마나 있을까요?

위대한 아키텍트는 머리가 아니라 노력과 풍요로운 마음으로 만들어진다. Frank Lloyd Wright

여러분 조직에서, 아키텍트 선발 기준은 무엇입니까? 순수한 지적인 능력, 유사한 문제를 겪어봤고, 문제를 간단하게 정리하고(정제), 기술적으로 상세부분까지 기억해 내는 방대한 지식 또는 경험, 그리고 너그러운 마음? 당신은 어떤 분위기에서 일 하는 것이 좋은 가요?

계속 읽기

Gregor_Portrait오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다.,  우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에,  우리의 시스템들이 (변화에) 유연하길 원합니다.

오늘날의 환경에서 유연함은  매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.

그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다.  “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..

불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.

예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.

계속 읽기

제 2회 아키텍트 Summit에 발표 자료입니다.  아키텍트에 ‘아’짜도  따라가지 못하는 저가, 우여 곡절 속에 수많은 쟁쟁한 분과 함게 발표를 맡게 되었습니다.

다른 쟁쟁한 아키텍트 분들에게 누가 되지 않았길 바라며, 발표를 준비했습니다.  주제는 패턴과 EA의 활용에 대해서 간략히 언급해 드렸습니다.

계속 읽기

DaveBartlett로마인의 세계에서, 야누스는 시작과 끝, 문과 통로의 신입니다. 야누스는 다른 방향의 바라보는 두 개의 머리로 보통 묘사되며, 영화나 동전에서 볼 수 있는 상징입니다. 야누스는 전환과 변화를 나타냅니다. 우리의 삶에서 예를 든다면 과거에서 미래로, 젊음에서 늙음, 결혼, 탄생, 시대의 도래와 같은 것이 있습니다.

소프트웨어 또는 건축물이든 어떤 아키텍트도, 앞과 뒤로, 과거에서 미래로 볼 수 있는 야누스의 능력은 꼭 필요한 능력입니다. 아키텍트는 비전과 현실, 향후 방향과 과거의 성공, 개발 제약과 사업/관리 기대치를 융합하기 위해 노력합니다.

이러한 (간극을 메우는) 다리를 만드는 것은 아키텍트의 중요한 역할입니다. 종종 아키텍트는 프로젝트를 완성하기 까지, 프로젝트에 영향을 미치는 다른 영향력들(예를 들어 접근 용이성 vs 보안, 경영의 미래 비전을 설계하면서 현재 비지니스 프로세스를 만족시키는 것)이 발생시키는 간극을 극복하기 위해 노력할 때, 희로애락을 느끼기도 합니다.

다양한 프로젝트의 이해당사자를 만족시킬 수 있는 소프트웨어(product)를 만들기 위하여,  좋은 아키텍트는 두 가지의 다른 아이디어나 생각, 다른 목표와 비전을 처리할 수 잇는 두 개의 머리를 가져야만 합니다. 아키텍트인 당신은 단순히 두 개의 얼굴이 아닌, 야누스가 가진 두 개의 머리를 주의 깊게 보아야 합니다. 훌륭한 IT 아키텍트는 뛰어난 경청 자[1] 이자 평가자 이어야 합니다.

계속 읽기

닐 스티븐슨의 소설인 크립토노미콘[1]에서, 랜디 워터하우스(Randy Waterhouse)는 자신이 만나는다양한 사람들의 유형에 빚대어 자신의 분류 시스템을 설명했습니다.

드워프[2]는 근면한 일꾼으로, 동굴속의 어두운 고독속에서 꾸준히 아름다운 산출물을 생산합니다. 드워프의 장인 정신은 정평이 나있으며, 산을 움직이고, 지구를 형성하는 엄청난 힘을 발휘 합니다.

엘프는 우아하며, 교양 있고, 하루를 새롭고 아름다운 마법을 만들면서 보냅니다. 엘프는 매우 천부적인 재능을 가지고 있어, 다른 종족이라면 실현할 수 없는 마술들을 거의 초자연적인 힘으로 생각해냅니다.

마법사는 다른 종족과 달리 거의 완벽하고 대단히 강력한 종족입니다. 하지만 엘프와는 다릅니다.마법사는 마법, 마법의 힘, 마법의 본질에 대해서 알고 있으며,  놀라운 광경과 함께  마법을 부립니다.

하지만 워터하우스가 특별히 언급하지 않은 네번째 타입의 캐릭터가 있습니다. 바로 왕입니다, 이들은 다른 종족들과 함께 무엇을 해야 할지를  아는,  몽상가(비젼을 제시하는 자)입니다.

계속 읽기