로마인의 세계에서, 야누스는 시작과 끝, 문과 통로의 신입니다. 야누스는 다른 방향의 바라보는 두 개의 머리로 보통 묘사되며, 영화나 동전에서 볼 수 있는 상징입니다. 야누스는 전환과 변화를 나타냅니다. 우리의 삶에서 예를 든다면 과거에서 미래로, 젊음에서 늙음, 결혼, 탄생, 시대의 도래와 같은 것이 있습니다.
소프트웨어 또는 건축물이든 어떤 아키텍트도, 앞과 뒤로, 과거에서 미래로 볼 수 있는 야누스의 능력은 꼭 필요한 능력입니다. 아키텍트는 비전과 현실, 향후 방향과 과거의 성공, 개발 제약과 사업/관리 기대치를 융합하기 위해 노력합니다.
이러한 (간극을 메우는) 다리를 만드는 것은 아키텍트의 중요한 역할입니다. 종종 아키텍트는 프로젝트를 완성하기 까지, 프로젝트에 영향을 미치는 다른 영향력들(예를 들어 접근 용이성 vs 보안, 경영의 미래 비전을 설계하면서 현재 비지니스 프로세스를 만족시키는 것)이 발생시키는 간극을 극복하기 위해 노력할 때, 희로애락을 느끼기도 합니다.
다양한 프로젝트의 이해당사자를 만족시킬 수 있는 소프트웨어(product)를 만들기 위하여, 좋은 아키텍트는 두 가지의 다른 아이디어나 생각, 다른 목표와 비전을 처리할 수 잇는 두 개의 머리를 가져야만 합니다. 아키텍트인 당신은 단순히 두 개의 얼굴이 아닌, 야누스가 가진 두 개의 머리를 주의 깊게 보아야 합니다. 훌륭한 IT 아키텍트는 뛰어난 경청 자[1] 이자 평가자 이어야 합니다.
안녕하세요 🙂 일전에 약속한 대로 여러가지 패턴 이야기들을 가져 왔습니다!!
사실 이미 많은 분이 접하셨을 겁니다. 바로 마소 5월호에 저희 스터디 팀이 Cover Story를 기고했는데요 그 내용들입니다.
처음 기고를 하신 분들도 있고, 아닌 분도 있지만 모두에게 좋은 경험이 되었다고 생각이 듭니다. 저 역시 저희 커뮤니티 맴버들이 뭉쳐서 이런 좋은 글을 만들었다는 것이 매우 큰 기쁨으로 느껴집니다.
사실 커뮤니티를 운영하면서 가장 만족감을 느끼는 것은, 서로에게 성장할 수 있는 경험과 기회를 주고 나누는 것이죠. 그리고 같이 성장해 가는 것을 보고 느낄때 기쁨은 이루 말할수 없습니다.
이 것이 제가 생각하는 커뮤니티의 올바른 모습이며, 앞으로도 잘 유지될 수 있도록 노력하겠습니다. 🙂 그럼 이번에 저희 EVA 팀이 기고한 글들을 차례대로 간략히 소개하겠습니다.
많은 분이 기다리셨던 The Productive Programmer가 현재 1차 교정 작업을 마쳤습니다.
(어쩔수 없이 블로깅하게 되네요.. 참 민망합니다. 아무래도 저의 사적인 일이 아니니, 이해해 주시길 부탁드립니다. 🙂 )
지식 공유와 큰 열정을 가지시고 번역관련 개론 서적까지 읽으시면서 고생해 주신 김현수 님 덕분에 드디어 이 서적이 한국에 나오네요.
좋은 서적이 국내에 나오게 되어 너무 기쁩니다.
김 현수님이 베타리더를 모으고 직접 베타리더 분들과 대화를 나누는게 맞지만, 현재 호주로 이민을 가셔서 부득이하게 제가 베타리더를 모으고, 가교의 역할을 하고자 합니다.
사실 번역 거리를 제가 현수님에게 드려서, 책임감을 가지고 할수밖에 없네요.
에전 More Joel on Software에서 많은 분이 참여해 주신것 처럼, 이번에도 활발한 신청 부탁드립니다.
이번 제 1회 닷넷 커뮤니티 컨퍼런스에 발표한 TP 자료를 많은 분이 요청하셔서 부득이하게 공유합니다.
- 패턴의 정의
- 패턴에 대한 오해와 진실
- 패턴으로 가는 길
- 패턴 빌드 오더
- 패턴 + 생산성 두마리의 토끼 잡기
블로그 포스트를 적으면서.. 보람된 것은 그나마 저의 부족한 지식을 좋게 봐 주시는 분이 많고, 격려해 주시는 분이 많다는 것입니다.
전화 위복이라고 했던가요 🙂
이번 사건으로 오히려 다시 한번 아키텍팅에서 SoC가 차지하는 중요성에 대해서 생각할 수 있게 되었습니다. 개인적으로는 유명 컨설턴트들과 함께한 프로젝트 만큼 더 큰 교훈이었다고 생각합니다. 저의 아키텍팅 공부방향의 진로를 정하게 되었다고 할까요..
SoC와 복잡성에 대한 고찰..
전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요. 일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다. 🙂
복잡성(Complexity) 에 대한 생각들..
먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.
어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다. 여러개가 묶여 있는 것을 복잡하다고 말을 합니다. 그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요. 결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.
우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..
우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.
예전에 Framework’s Day에 발표했던 Framework Engineering 의 동영상 강좌를 지난 토요일날 찍었습니다.
Framework 구축시 여러분이 겪을 시행 착오를 조금이나마 줄일 수 있길 바라며 강좌를 공유합니다.
이 강좌에 대한 내용은 저의 머리에서 나온 것이 아니라, .NET Framework의 설계자인 Krzysztof Cwalina의 강좌와 현재 저희가 번역하고 있는 Framework Design Guideline 2nd 추가해 정리한 것입니다.
이 발표의 전체적인 내용은 아래와 같습니다.
Seperation of Concerns (걱정거리들의 분리) 줄여서, SoC 라는 용어를 들어 보셨나요? 걱정 거리또는 관심거리의 분할(분리)라고 부르는 데요 🙂
각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다. N – Tier 기반의 Application이 좋은 예라고 할 수 있을 겁니다. (물론 성능적인 이슈도 있지만요)
하지만 이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서, 실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다 발생하기도 합니다.
안녕하세요. 요즘 블로깅이 뜸하다고 몇분이 저에게 사적으로 말씀하시더라구요 🙂
이유는 나중에 말씀 드리도록 하고, 조만간 있을 세미나 2개에 대한 정보를 알려 드리고자 합니다.
1. 미워도 다시보는 패턴 이야기 (4월말에 있을 초대형 세미나에 한 섹션)
행사의 구체적인 정보를 말해 드릴수 없지만, 조만간 1000명이상을 위한 세미나가 4월말에 열릴 예정입니다.
추후 행사에 대한 자세한 내용을 Update하도록 하고, 제가 진행하는 세션 정보를 공유하고자 합니다.
패턴 이라는 것이 너무 GoF 패턴, 그리고 소프트웨어 설계 기술에만 치우쳐 한국 개발자에게 공유되어 지고 있는것 같습니다.
패턴에 대한 오해들과 프로세스나 실제 개발자 삶에 도움이 되는 패턴 이야기를 여러분들에게 전달하고자 합니다.
그리고 Code 보다 Model에서 생각하는 방법과 개발 생산성을 증대시키는 이야기들도 나눌 겁니다. 아마 이게 백미라고 생각이 드네요.
이미 대전에 한 중소기업에서 세미나를 진행했고, 피드백이 매우 괜찮았습니다. 4월 말 기대하셔도 좋습니다.
분산 (네트웍 ) 기반의 시스템에서 성능 측정시 고려해야 되는 사항들은 어떠한 것들이 있을까요?
서버나 네트웍 기반의 어플리케이션 구축을 업으로 삼고 있는 프로그래머라면 참고하시면 좋은 그림을 발견해 공유합니다.
위 그림을 눌리시면 큰 그림을 다운 받으실 수 있습니다.
Architecture 101 