지난해 다양한 소프트웨어 아키텍팅 강의를 진행해 왔습니다. 아키텍처 설계 및 평가 기법, 그리고 부하테스트/ 성능 최적화에 대한 강의가 주를 이루었습니다. 아키텍처 설계 프로세스는 말그대로 진행은 하면 되지만, 결국 많은 설계 기법을 알지 못하면 좋은 설계를 하지 못하는 상황이 빈번하게 발생했습니다. 2022년에 다음과 같은 강좌 들을 진행했습니다. 강의를 하다보면서, 아직 많은 교재들이 디자인패턴에 지식이 머물러있고, 몇몇 […]
제가 패턴학회에 이사회 맴버로 있고, 저에게 가르침과 영향을 많이 주신 두분이 계십니다. 한 분은 유연하면서도, 지혜로운 삶을 사는 자세를 가르쳐 주신 Linda Rising 이시고, 또 한분은 AT&T에서 네트워크 스위치 개발을 시작으로, 오랫동안 Fault Tolerant 패턴을 정리해 주신 Robert S. Hanmer 님입니다. Bob Hanmer 님은 요즘 외부 활동을 잠시 쉬고 계시지만 이 분의 여러가지 노력들을 아래와 […]
소프트웨어 아키텍트의 길은 멀고 험난합니다. 그 와중에 조금이나마 아키텍트를 꿈꾸거나, 진입하시는 분들을 위한 과정을 진행하고 있습니다. 이미 다양한 대기업에서 강의를 했습니다. 수업의 커리큘럼은 다음과 같습니다. 관심있는 기업 교육자 담당자 분들은 연락을 주시면 됩니다. 시간당 25만원이 아니면 강의를 하지 않습니다. 시간당 20만원의 요청이 제법있는데, 안 하기로 했습니다. 다만 수도권이 아닌 지방이라면 지식 공유를 위해 훨씬 저렴하게 […]
제 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을 좋아한다고, 가치가 있다고 말할 수 있는가?”
아키텍트가 알아야할 12가지의 Presentation을 공개합니다. 아키텍트가 알아야할 97가지중 제가 선별한 12가지의 내용이 들어가 있으며, 앞으로 +1 씩 더해가면서 점차 내용을 확대하고 다듬을 생각입니다. 많은 분에게 도움이 되셨으면 합니다. 상업적 자료 사용은 금지이며, 저작자의 이름을 공개한 상황에서 사용하는 것은 허락합니다.
“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다. 기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠. 기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.
지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이 아마 한 명 이상 있을 것입니다.
왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?
실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?
대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.
한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.
범위는 프로젝트의 크기를 언급합니다.
얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.
소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.
범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.
프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.
직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.
역사[1]는 ,직관이 제안했던 것처럼, 미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의 커뮤니케이션 비용이 들것입니다.
건축가에 배워야 하는 교훈들을 여러분과 공유하고자 합니다.
“아키텍쳐는 사회적 행동과 인간 활동의 중요한 극장이다. — Spiro Kostof”
명시적, 주도적, 기술적으로 자신의 배역(역할)을 아는 아키텍트가 얼마나 있을까요? 오히려 소프트웨어 아키텍트는 이해 당사자 (stake-holders) 사이에서, 서로 의견이 충돌이 발생하는 파벌들의 중재인, 중개인, 조정자 이지 않을까요?
소프트웨어 아키텍트의 일 중 인적 요소(human-factor)에 적절한 가중치를 부여하지[1] 않고, 순수하게 지적인 정신(소프트웨어 설계)을 요구하는 일이 얼마나 있을까요?
위대한 아키텍트는 머리가 아니라 노력과 풍요로운 마음으로 만들어진다. — Frank Lloyd Wright
여러분 조직에서, 아키텍트 선발 기준은 무엇입니까? 순수한 지적인 능력, 유사한 문제를 겪어봤고, 문제를 간단하게 정리하고(정제), 기술적으로 상세부분까지 기억해 내는 방대한 지식 또는 경험, 그리고 너그러운 마음? 당신은 어떤 분위기에서 일 하는 것이 좋은 가요?
오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다., 우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에, 우리의 시스템들이 (변화에) 유연하길 원합니다.
오늘날의 환경에서 유연함은 매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.
그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다. “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..
불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.
예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.
Architecture 101 