볼만한 아티클이 있어서 소개한다. 사이트 가입이 필요하지만 좋은 글들을 소개해주는 메일이 종종 날아오는 것 정도라 관심있는 사람이라면 오히려 도움이 될 거다.

Principles of Agile Architecture (Click Here)

주제는 제목이 잘 설명해주고 있다. 애자일 방법론이 엔터프라이즈 시장까지 급속히 번져감에 따라 대규모 프로젝트에 적합한 애자일 아키텍쳐링에 대한 노하우를 공유하는 글이다. 내용을 자세히 다루고 싶지만, 해당 사이트의 라이선스 정책을 정확히 몰라 간략히 소개만 하겠다. (읽어보았는데 번역에 대한 명시적 언급은 없고, 승인을 위한 컨텍 주소가 있지만 귀찮다 ㅎ)

이 글에서 제시하는 원칙은 아래의 7가지이다. 자세한 설명은 직접 글을 읽어보자. ^^ (주변인 중 사이트 가입이 내키지 않는 사람에게는 프린트해서 드리죠. ㅎ)

1. The teams that code the system design the system.
2. Build the simplest architecture that can possible work.
3. When in doubt, code it out.
4. They build it, they test it.
5. The bigger the system, the longer the runway.
6. System architecture is a role collaboration.
7. There is no monopoly on innovation.

맛을 보여 드리기 위해 일부만 발췌해 보았다.

1. The teams that code the system design the system.

Scrum 에서 이야기하는 Self Organization(자기 조직화) 와 연관해서 생각해봐도 좋을 것이다. 왜 애자일 팀이 기존 팀 대비 훨씬 능동적이고 활기 넘치고, 또 발전할 수 밖에 없는가에 대한 이유를 잘 정리해놓은 표이다.

6. System architecture is a role collaboration.

1번 원칙에서 이야기한 것 처럼 설계에 대한 기본적인 권한과 책임은 이를 구현하는 팀에게 있지만, 엔터프라이즈 레벨의 대규모 프로젝트에서 각각의 팀에게 모든 것을 맡겨 놓는 것도 그리 이상적이진 않다. 그래서 능력있는 전문 아키텍트나 멀리서 조망하며 큰 그림을 그려나가는 팀도 필요해진다. 그렇지만 여전히 어느 한 팀이나 특정인에게 모든 권한이 위임되지는 않는다. 아래 그림에서 묘사한 것처럼 조직의 여러 팀과 전문가들의 협력에 의해 전체 시스템 아키텍쳐가 발전해나가야 한다.

7. There is no monopoly on innovation.

혁신은 한 번에 일어나지 않는다는 정도로 이해하면 되는데.. 아래는 Rally Software Development 에서 수행해온 방식이라는데 마지막의 hackathon 이 아주 흥미롭다.

Hackathon 의 개념과 기원은 Wikipedia 에 잘 설명되어 있으니 참조하길 바라고 (Click Here), 위의 그림과 연관하여 간략히 설명하면 이렇다. 마지막 한 주 간은, 회사의 미션과 연관된 것이라면, 개발팀 누구나 자신이 관심있는 어떤 주제에 대해서도 자유롭게 탐구할 권한이 주어진다. 이런 기회를 통해 새로운 것을 배우고 사고의 폭을 넓혀가면서 차곡차곡 혁신을 이끌어낼 기반을 다지는 것이다. 구글의 20% 원칙도 같은 맥락에서 바라볼 수 있겠다.