소프트웨어 아키텍트(구조 설계자)

IBM System/360 시리즈, OS/360을 개발하고, 1999년 튜링 어워드를 수상한 브룩스는 소프트웨어 개발에 있어서 은총알은 없다고 했습니다. 소프트웨어를 쉽게 개발할 수 있는 획기적인 방법은 없다는 의미입니다.

40년전의 얘기인데, 지금 의미가 있나? 이렇게 생각하나요?

2021년 그리어 교수는 소프트웨어 개발에 있어서 여전히 은총알은 없다고 얘기합니다.

무엇이 문제일까요? 소프트웨어 개발에 있어서 어떤 문제가 있어서, 40년이 지났지만, 또는 앞으로도 해결하기 어렵다고 말하는 것일까요? 소프트웨어 아키텍트는 이 문제를 직면해야 합니다. Neal Ford는 소프트웨어 아키텍트가 알아야 할 97가지에서 아키텍트가 해결해야 의무라고 얘기하고 있습니다.

소프트웨어 개발은 레고 블록을 조립하는 과정과 비교할 수 있습니다. 레고 블록이 다양한 방식으로 조합되어 무한한 가능성의 작품을 만들어 낼 수 있듯이, 소프트웨어도 동일한 요구사항에 다양한 솔루션이 존재합니다. 어떤 소프트웨어가 더 좋은 것일까요? 최적일까요? 엄청난 다양성에서 더 좋은 것, 최적을 찾아내는 것은 단순한 문제가 아닙니다.

더군다나 소프트웨어는 보이지 않습니다. 레고 블록은 잘 맞는지, 맞지 않는다면 눈으로 확인하면서 맞출 수 있지만, 소프트웨어는 그렇지 않습니다. 보이지 않기 때문에 상상하기 어렵고 이해하기 어렵습니다. 상상하기 어렵기 때문에 가시화하거나 문서화하기 어렵습니다.

가시화, 문서화가 어렵기 때문에 의사소통에 문제가 많습니다. 잘못 이해하기 쉽고, 공감대 형성이 어렵습니다. 이런 의사소통의 어려움은 협업을 어렵게 하고, 대규모 과제일수록 생산성이 떨어지는 것을 당연하게 만듭니다.

가시화, 문서화가 잘 안되고, 이해하기 어렵기 때문에 비교/분석하기 어렵습니다. 비교/분석이 잘 안되므로 더 좋은 것을 만들거나 최적 개발이 쉽지 않습니다. 이것이 아키텍트가 해결해야 할 근본적인 문제입니다.

아키텍트는 구조를 그려서 가시화합니다. 가시화된 구조는 상상하고 이해하도록 합니다. 이런 이해는 의사 소통과 협업을 원활하게 합니다. 또한, 이런 이해를 근거로 비교/분석하게 하고, 더 좋은, 궁극적으로는 최적 개발을 끌어 냅니다. 이것이 아키텍트의 역할입니다.

브룩스와 그리어 교수가 은총알은 없다고 주장한 것은 이와 같은 소프트웨어의 다양성, 복잡성, 비가시성 문제를 해결하는 획기적인 솔루션이 없다는 것입니다. 그럼 어떻게 해야 할까요?

근본적인 문제를 해결하는 유일한 방법은 기본에 충실하는 것입니다. 어려울수록 기본에 미쳐라.

이 로드맵을 통해서, 소프트웨어 아키텍트가 알아야 할 기본적인 지식을 정리하고 공유하고자 합니다. 또한, 필요한 지식을 전달하는 강의를 만들고자 합니다.

• 객체지향 소프트웨어 분석 및 설계(Object-oriented Analysis and Design), UML

• 객체지향 설계 원칙

• 구조도

• 구조적 의사결정

• 품질 요구사항과 설계 전술

• 디자인 패턴,

  아키텍처 스타일

• 구조 설계 활동 및 프로세스

소프트웨어 설계 어렵습니다. 그래서, 잘 안하게 되고, 안하니까 못하고, 못하니까 결과가 좋지 않고, 더 안하게 됩니다. 소프트웨어 설계 역량을 키우는 것은 소프트웨어 개발자로서 성공의 주춧돌이 됩니다. 노력할 만한 가치가 충분합니다.