경험있고 훈련된 아키텍트들은 확보했지만 구현자 수가 많은 상황에서, 아키텍트의 결정 내용을 모두 이들이 듣고 이해하고 구현하도록 할 방법은 무엇인가?

1. 문서화된 명세: 메뉴얼

 메뉴얼은 제품에 대한 외부적인 명세 로, 사용자가 보게되는 모든 세부사항을 기술하고 규정한다. 따라서 이것이 아키텍트의 가장 주요한 산출물 이다.

 메뉴얼은 인터페이스를 비롯해서 사용자가 보는 모든 것을 기술해야 하며, 사용자가 보지 않는 부분은 기술하기를 자제해야 한다. 그 부분은 구현자의 소관이며, 설계의 자유를 그 안에서 마음껏 펼칠 수 있어야 한다.

 메뉴얼의 체제는 꼼꼼하고 완전하며 세부사항이 정확해야 한다. 사용자는 종종 항목 하나만 참조할 것이므로, 각 항목에는 필요한 내용을 빠짐없이 반복하되 그 모두가 전체적으로 일치되어야 한다.

2. 형식적 정의

 영어를 비록한 자연 언어들은 본질적으로 메뉴얼 정의에 적합한 정밀한 도구가 아니다. 매력적인 대안은 정의를 내리는데 형식적 표기법 을 사용하는 것이다.

 형식적 정의는 정확하며 완결적이려는 경향이 있기 때문에 빠진 부분이 있더라도 금방 눈에 띄어 채워지게 된다. 그러나 서술적 정의 와 달리 구조적 원리를 보이거나, 단계 별로 구조를 묘사하거나, 예를 드는 것이 쉽지 않다.

- 명확한 기준을 세우기

 위와 같은 이유로 앞으로는 형식적 정의와 서술적 정의가 동시에 쓰이게 될 것이다. 그러나 두 가지가 같이 쓰인다면 둘 중 하나가 기준이 되고 다른 하나는 보조적인 역할 이어야 하며, 이런 점은 명확히 드러나야 한다.

두 개의 크로노미터를 가지고 항해에 나서지 마라. 한 개든, 세 개든지 하라.

 형식적 정의는 하드웨어나 소프트웨어 시스템의 외부적 측면을 규정하는 것이지만, 거의 대부분 실제 구현된 내용을 포함하거나 기술 하고 있다. 특정 프로그램이나 하드웨어는 그것 자체가 하나의 구현체이므로 이는 아키텍처를 과도하게 규정하게 된다. 따라서 작성자는 형식적 정의가 외부적인 측면에만 해당됨을 명시 해야 하고, 그것이 어느 부분인지도 일러두어야 한다.

- 구현체로서의 형식적 정의

 형식적 정의가 하나의 구현체인 것처럼 구현체도 형식적 저의로 사용될 수 있다. 메뉴얼에 모호한 곳이 있는가? "기계에게 물어보라!" 동작 방식을 결정하는 테스트 프로그램은 만들고, 이것을 써서 기존 장비에 맞춘 새 장비를 제작할 수도 있다.

 구현체를 정의로 사용하게 되면 모든 의문은 실험에 의해 확실하게 정리되며, 토론이 전혀 필요치 않으며 즉각적으로 답을 얻을 수 있다.

 반면에 무효한 구문을 사용하게 될 경우 항상 무언가 결과가 산출되는데 관리되는 시스템에서는 문제가 없으나, 관리되지 않은 시스템에서는 온갖 종류의 부작용 이 생길 수있고 프로그래머는 그것을 하나의 기능으로 사용하게 될 수 있다.

 또한 구현체를 형식적인 정의로 사용하게 될 경우 서술적인 것과 형식적의 것 중 어느 쪽이 진짜 표준인지 혼동하기가 쉽다.

3. 직접 포함하기

 소프트웨어 시스템 아키텍트에게는 정의된 내용을 퍼뜨리고 강제할 수 있는 멋진 방법이 있다:

전달될 인자나 공유 저장소에 대한 선언부를 설계하고, 그 선언부를 구현체가 포함하도록 하는 것이다.

4. 회의와 법정

 회의를 두 가지 단계로 나눠서 진행하는 것이 효과적이다.

- 주간 회의

 모든 아키텍트가 모이는 반나절 가량의 주간회의로, 하드웨어 및 소프트웨어 구현 파트의 공식 대표들과 마케팅 담당자들이 함께 참석하며, 의장은 수석 아키텍트가 맡는다. 이는 다음의 이점을가진다:

1. 아키텍트, 사용자, 구현자로 구성된 동일 집단이 여러 달 동안 매주 만나므로, 최선 정보를 갱신하기 위해 시간을 들일 필요가 없다.
2. 이 집단은 생기있고 수완 좋은 사람들로, 이슈를 잘 파악하고 있으며 결론의 향방에 깊이 관련되어 있다. 어느 누구도 자문 역할을 하지 않으며, 모두 구속력있는 약속을 할 권한이 있다.
3. 문제가 제기되면, 그 문제가 내포하는 명백한 경계의 안쪽 만이 아니라 바깥 쪽에서도 해결책을 모색하게 된다.
4. 문서화된 제안서의 공식성은 주의를 집중하게 하고 결정을 내리도록 만들며, 위원회에서 나온 초안처럼 앞뒤가 맞지 않는 일이 없게 해준다.
5. 의사결정권이 수석 아키텍트에게 있음을 명확히 함으로써 타협과 시간 지연을 피할 수 있다.

- 법정

 사소한 항의나 공개된 현안, 불만 사항들을 담아둔 백로그가 점차 늘어나기 때문에 이것을 정리하기 위한 최고 법정을 연다. 이 법정은 메뉴얼의 주요 프리즈 날짜 직적엔 개최한다.

 참석자는 아키텍트들과 각 파트의 설계 관련 대표자 뿐만 아니라 프로그래밍, 마케팅, 구현 쪽 관리자들도 포함된다.

 여기에서 모든 이들의 의견이 청취되고, 모두가 참석하며, 수 많은 결정 사이의 복잡한 제약 사항과 상호 관계를 모두가 더 잘 이해하게 만들 수 있다.

4. 여러 벌 구현하기

 아키텍트의 정치적 영햑력은 구현체들 간의 엄격한 호환성 에서 유래되며 따라서 여러 구현체를 동시에 구축함으로써 명세를 강제할 수 있다.

5. 통화 일지

 구현에 불명확함과 불확실성이 있는 때에는 담당 아키텍트에게 전화를 걸어 물어본다. 또한, 그런 질문에 대한 답변은 아키텍처에 대한 '권위있는' 해석이며 모두에게 공유 되어야 한다.

 이를 위해 통화 일지를 관리하고 내용을 기록해두면, 다소 비공식적이지만 신속하고 알기 쉽다는 장점이 있다.

6. 제품 테스트

 모든 개발 조직은 건전성을 담보하기 위해 제품 테스팅 조직과 같은 독립된 기술 감사 조직이 필요하다. 주의 깊은 제품 테스트덜은 말이 제대로 전달되지 않았거나 설계 상의 결정이 잘못 이해되었거나 정확하게 구현되지 않은 곳을 몇 번이고 찾아 낼 것이다.

 이런 이유로 인해 테스팅 조직은 설계 내용의 전달 계통에 필수적인 연결 고리이며, 설계와 동시에 초반부터 가동 될 필요 가 있다.

출처

[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)