아키텍트! 참으로 열망하고 있고 능력을 갖추기 위해 노력하고 있습니다.
아키텍트와 관련된 여러가지 글을 적었지만, 과연 우리에겐 아키텍트의 롤이 언제쯤 주어질까요? 이런 수동적인 상황을 깨는 좋은 만남을 가졌습니다.
많은 고심과 새로운 길을 개척하기 위해 노력하는 도중에, 지인의 소개로 System Architect를 만났습니다. 제가 머리속에 그리고 있는 아키텍트와는 전혀 다른 모습이었습니다.
개발자 출신이시며, 45세라는 나이, 솔로, 수많은 실패를 경험한 그분에게는 온실속 화초같은 생활을 하는 저에게 많은 가르침을 주셨습니다.
국내 환경에 적합한 생존 전략을 구사하시는 System Architect셨습니다.
4시간동안 그분의 열변과 경험을 전달해 주셨고, 느낀바를 여러분과 공유하고자 합니다.
Framework Design Guideline의 저자인 Krzysztof Cwalina의 TechED 2007 Framework Engineering 온라인 세션을 듣고 토론회를 가졌습니다.
편역을 하기전에 Framework 에 관해 배경지식을 쌓고, Paper Meeting 행사를 위한 가이드라인을 만들고 공유하기 위한 목적도 있었습니다.
Krzysztof Cwalina는 실제 .NET Framework를 설계한 분으로, 그의 경험을 책을 통해서 공유했을 뿐만 아니라, FxCop 이라는 툴을 이용해 VS.NET 내부 개발자들의 코드 품질을 검증하는 시스템을 외부로 공개하고 알린 분이기도 합니다.
Framework Engineering은 TechED2007 Europe 에서 발표한 세션으로 원래 일반인에게는 비공개이나, 고맙게도 자신의 블로그를 통해 공유해 주시고 계십니다.
토론을 즐겁게 하기위해서는 어떻게 해야 될까요?
Framework Design Guideline 번역 팀과 TechED 2007에 발표된 Framework Engineering 강의를 듣고 서로 공유하는 시간을 가졌는데요.
함께 재미난 토론 방식을 시도해 보았습니다.
이번 POST는 저희들의 토론 방식을 여러분들고 같이 공유하고자 합니다.
아키텍트가 되기 위해서 우리에게는 어떠한 덕목이 필요할까요?
2007년 10월에 소프트웨어 아키텍쳐 이론과 실제 (Software Architecture in Practice)의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였습니다.
세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는
질문을 했고, 이에 대한 멋진 답변을 해 주셨는데 제가 알고 있는 지식을 덧 붙여 여러분과 함께 공유하고자 합니다.
제 1회 Paper Meeting에 여러분을 초대합니다.
기존의 단방향 세미나에서 탈피해, 새로운 형태의 모임을 만들었습니다.
하나의 Paper를 선택하시시면, 여러분과 동일한 Paper를 선택하신 분들과 조를 나누어 토론/지식 공유 모임을 하고
맨마지막 조별 10분식 자신의 조가 나누었던 애기들을 마인드 맵 형태로 정리해서 나누는 유익한 세미나 입니다.
좀더 자세한 정보및 등록은 http://www.onoffmix.com/e/only2u4u/149 에서 얻으실수 있습니다.
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
호환성 (Compatibility) 이라는 말을 들어보셨나요?
- .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
- JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?
새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다. 이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
여러분에게 좋은 소식을 하나 전해드리고자 합니다.
POSA2에 이어 또 하나의 명서인 Framework Design Guidelines 2nd Edition의 편역을 위한 모임을 가졌습니다.
이 책은 Framework를 잘 설계하기 위한 Guideline을 제공하는 서적으로 Microsoft의 .NET Framework 설계팀들이 직접 집필한 서적입니다. Framework을 처음 설계하는 개발자에게는 매우 유용한 서적이 될듯 합니다.
현재 http://fdg.springnote.com 에서 작업을 시도하고 있으면, 저희 스터디시 만들어진 가치있는 공유물들을 여러분과 함께 나눌 생각입니다.
Architecture 101 