소프트웨어 아키텍처는 어디에서 오는 것일까?

오늘은 아키텍처와 비즈니스의 관계에 대해서 적어볼까 합니다.

아키텍처… 비즈니스… 둘간의 무슨 관계가 있을까요?

별 관계도 없어 보이고…

혹시 제품의 아키텍처를 구성하고 설계를 하시고 계시나요? 그렇다면 비즈니스에는 얼마나 관심을 가지고계십니까? 

기술은 기술, 비즈니스는 비즈니스, 별 관계없다고 생각하실 수도 있습니다. 

결론은 말씀 드리면 "소프트웨어 아키텍처는 비즈니스에서 나온다."입니다.

이 글을 쓰게 된 주된 이유는 많은 선임, 고참 개발자들이 기술에만 관심을 가지고 비즈니스에 별 관심이 없는 경우를 많이 봐왔기 때문입니다.

개발자는 상위 개발자가 될 수록 비즈니스를 알아야 합니다. 아키텍처에 대한 대부분의 결정은 단순히기술적인 결정이 아닙니다. 비즈니스를 제외하고 기술적인 결정만 있는 경우는 별로 없습니다.

지금 만드는 제품이 딱 한 회사만 사용할지 100개의 회사가 사용할지 100만개의 회사가 사용할지에 따라서제품의 아키텍처는 완전히 달라집니다.

또 내년에는 100개의 회사만 사용하지만 내 후년에는 10,000개의 고객을 가질 것이라면 또 달라집니다.

한국에서만 팔 것인지, 아시아권에만 팔 것인지, 미국, 유럽에도 진출할 것인지에 따라서 Localization이슈가완전히 달라지고, 1,2년은 한국에서만 팔지만, 추후 유럽에서도 판매할 의도가 있다면 미리 이를 고려하지않으면 안됩니다.

그리고 이러한 아키텍처 관련된 결정은 매우 중요해서 잘못된 결정이 엄청난 손실을 가져옵니다. 코드 좀 잘못 짜고, 버그 좀 만드는 것과는 차원이 다릅니다.

이러한 비즈니스적인 요소를 고려하지 않고, 그냥 기술적으로 기능이 동작하는 정도만 생각하고 소프트웨어를 개발하고 있다면 선임개발자로서의 자격이 부족하다고 할 수 있습니다.

따라서 선임개발자가 되면 비즈니스에 대해서 부지런히 관심을 가지고 공부를 해야 합니다. 회사 내부만 보지 말고 Global한 시장이 어떻게 돌아가는지도 관심을 가져야 합니다.

아키텍트(Software Architect)가 되는 첫 걸음은 기술이 아니고 비즈니스를 알아가는 것입니다.

객체지향... 필요한가?

써니님의 "절차지향도 훌륭한데, 왜 객체지향인가?"라는 글을 읽고 객체지향에 대한 견해를 적어봅니다.

먼저 글을 읽고 계신 분이 C언어로 프로그래밍을 하시나요? 그러면 질문이 있습니다. "static 함수를 사용하시나요? 또 static 함수의 용도를 아시나요?" "static 변수가 아닙니다." 사용하고 계시고 정확한 용도를 알고 계시면 C언어로도 객체지향 프로그래밍을 하고 계시는 것일 겁니다. 이 질문에 갸우뚱하시는 분이 계시나요? 그럼 이야기를 시작해보죠.

여기서 이슈를 다음 두 가지로 나눠야 할 것 같습니다.

• 객체지향 프로그래밍
• 객체지향 프로그래밍 언어사용

첫째, 객체지향 프로그래밍은 당연히 필요하다고 생각합니다. 

우선 몇 만 라인 이하의 소규모 소프트웨어를 개발할 때와 혼자서 소프트웨어를 개발할 때는 좀 논외로 하고 싶습니다. 이런 경우의 예를 들기 시작하면 사실 어떻게 해도 불편할 것도 없고 안되는 것도 없습니다.

적어도 수십만 라인의 이상의 코드를 다루고, 5,6명 또는 수십, 수백 명의 개발자들이 같이 일을 할 경우를 기준으로 생각해야 할 것 같습니다. 지금은 혼자 소규모의 소프트웨어를 개발하고 있어도 언젠가는 이런 규모의 소프트웨어를 개발하는데 참여하겠죠. 따라서 혼자서 개발을 하고 있어도 "나랑은 상관없는 얘기다"는 아닙니다.

프로그래밍에 객체지향 개념 도입된지는 매우 오래 되었습니다. 객체지향 프로그래밍 언어가 나오기 훨씬 이전부터 개발자들은 객체 지향적으로 개발을 하고 있었습니다. 그렇지 않고서는 너무 복잡해서 개발을 할 수가 없었거든요. 그 뒤로 이러한 요구를 만족시키기 위해서 객체지향 프로그래밍을 잘 할 수 있는 언어들이 나오기 시작한 거죠. 

객체지향의 기본 컨셉인 추상화, 캐슐화, 정보의 은닉 이런 것들은 오래 전부터 사용을 해왔죠.

그렇지 않고 절차적이고 구조적인 프로그래밍을 하게 되면 시스템의 규모가 커질 수록 그 복잡도가 너무 커져서 감당할 수가 없었죠.

그래서 개발을 할 때 시스템의 각 컴포넌트는 잘 나눠서 각 컴포넌트끼리는 간결한 인터페이스를 정의해서 해당 인터페이스만을 가지고 통신을 하도록 하고 각 개발자들은 자신이 담당함 컴포넌트만 개발할 수 있도록 했죠. 이러한 개념을 데이터와 메쏘드를 엮어서 객체지향 이론을 점점 발전시켜 왔습니다. 

C언어에서도 static 함수를 사용하면 해당 파일의 내부에서만 호출이 가능하고 외부 다른 파일에서는 호출할 수 없습니다. 즉 private 함수와 같은 효과를 발휘합니다. 따라서 public함수가 아닌 함수는 모두 static으로 정의를 해야 합니다. 그렇지 않으면 함수가 바뀌게 되었을 때 수천, 수만 개의 파일 중에서 누가 그 함수를 사용하고 있는지 정확하게 추적해서 문제없이 수정하는 것은 너무나 어려워 집니다. static함수는 해당 파일 내에서만 검토를 하면 되기 때문에 문제 없죠. 혹시 지금 C언어로 작성된 소스코드가 있으면 함수에 static이 정의 되어 있는지 확인해보세요.

둘째, 객체지향 프로그래밍 언어도 당연히 유용합니다.

C언어로도 객체지향 개념을 적용할 수 있지만, 한계가 있죠. 제대로 된 객체지향 프로그래밍을 하려면 객체지향 프로그래밍 언어가 필요합니다. 하지만 C언어로 개발을 하는 것에 대해서도 전혀 부정적인 의식은 없습니다.

주변에서 보면 언어만 C++을 사용하고 코드 내부를 뜯어보면 전혀 객체지향적이지 않는 소스코드를 많이 봅니다. 이런 경우보다는 C언어로 잘 작성하는 것이 더 낳죠.

물론 C++이 가장 훌륭한 객체지향언어라고 할 수는 없습니다. 그래서 객체지향 프로그래밍을 하기 위해서는 어떤 프로그래밍언어를 사용해야 한다고 주장하고 싶지는 않습니다.

한때 객체지향 개발방법론이 대두되어서 이전의 모든 문제를 다 해결해 줄 것처럼 떠들었지만, 이는 결국 언어를 무엇을 사용하고 방법론을 뭘 쓰느냐의 문제는 아니고 개발자들의 역량에 달린 문제 같습니다.

결론은 이렇습니다. 

"객체지향이 유용하기는 하나 무슨 언어를 쓰냐보다는 개발자의 객체지향 개발 역량이 더 중요하다."

객체 지향이라는 것이 꼭 알아야 하는 것이지만 툴에 목을 메지는 맙시다.

절차지향도 훌륭한데, 왜 객체지향인가?  by 써니 구조적 프로그래밍 혹은 절차지향적 프로그래밍이라고도 말하는 C언어를 학습하시거나, 현장에서 C언어를 이용해서 개발하시는 분들과 대화를 나누다 보면 굳이 객체와 클래스라는 생소하고 어색한(?) 개념을 도입해서 개발해야 하는지 그 필요성을 잘 느끼지 못한다고 하십니다. 저 또한 베이식 - 베이직 보다 베이식이 정확한 발음이더군요 - 그리고, C언어를 먼저 학습한 사람이기 때문에 어느 정도 공감하고 있습니다. 단순한 프로그램을 개발하건, 복잡한 프로그램을 개발하건 구조적 프로그래밍이건 객체지향 프로그래밍 기법을 사용하건 어떠한 문제를 풀던 간에 눈에 보이는 결과 자체로는 차이점을 발견할 수 없습니다. 그러니까, C언어로 윈도우 어플리케이션을 만들어도 잘 동작하고, C#으로 만들어도 잘 동작합니다. 여전히 대부분의 운영체제는 C언어로 개발되고 있고, 전세계에서 운영되고 있는 수많은 제품들과 정보시스템들이 여전히 C언어로 구현 및 유지보수 되고 있습니다. 여전히 수많은 금융기관에서는 코볼로 작성된 프로그램들을 사용하고 있고, 게다가 아주 성공적으로 운영되고 있습니다.

코더(Coder)의 비애

블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 

안녕하세요. Ray입니다.

써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠.

적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다.

이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠.

하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다.

실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다.

하지만 이런 구현 외주는 미국과 인도에서는 흔한 일이죠. 물론 설계를 가르쳐 주는 곳도 없어서 배울 수는 있지만, 애초에 이러한 환경에서 같이 일을 했으면 잘 작성된 설계서를 보고 구현도 하고 아키텍쳐 설계회의에도 참석하고 많이 배우죠.

우리의 예를 보면 소규모 기업에서 좋은 소프트웨어를 히트쳐서 회사가 갑자기 켜지고 2,3명이서 개발하던 개발팀이 수십명으로 늘어나면서 제품은 복잡해지고 켜졌는데, 제품은 이전만 못한 경우를 많이 봤습니다.

여러 다른 이유가 있지만, 설계 방법에 대한 이슈도 그 문제에 한몫을 합니다.

밑에 Cavin님이 말씀하신 것 처럼 설계 컨설턴트는 있을 수 없습니다. 제 직업이 소프트웨어 컨설턴트이지만, 설계자체를 컨설팅 해줄 수는 없습니다.

또 설계를 가르쳐주는 것도 거의 불가능합니다.

설계의 기본 컨셉, 방법, 툴 사용법 등을 가르쳐 줄 수는 있습니다.

하지만 이것들이 설계를 할 수 있게 해주지 않습니다.

그런 것들을 모두 다 알고도 오랜 경험이 또 필요하고, 문서화를 할 수 있는 실력도 필요하죠. 알고 있는 기술 분야도 워낙 다양해서 최고의 설계 컨설턴트가 도와준다는 것도 말이 안되는 얘기고 일부 기술이나 아키텍쳐에 대해서 도움을 받는 정도 이죠.

여기서 "설계는 뭐다"라고 얘기할 것은 하나도 없습니다.

그래도 이렇게 끝나는 글이 되면 너무 썰렁하니 설계의 시작과 끝 정도 정의하고 그 속은 워낙 다양하니 차차 여러 가지 의견을 글로 남겨보도록 하겠습니다.

설계의 시작은 우선 인터페이스을 찾아내는 것입니다. 그래서 인터페이스와 컴포넌트들을 구분하면서 시작이 됩니다. 이 개념은 OOP에서 출발한 것도 아니고 가장 전통적인 방법입니다. 소프트웨어의 분야는 수없이 바뀌어 왔지만, 설계의 원리는 크게 변하지 않았습니다. 코볼로 만들던, 자바로 만들던 소프트웨어를 만드는 철학은 기본적으로 많이 다르지 않습다. 설계의 기본은 시스템의 단위를 좀 더 작은 단위로 분할해 가면서 아키텍처를 설계하는 것입니다. 설계는 시스템을 잘게 나눠서 컴포넌트와 모듈을 정의하고 그 인터페이스를 정하는 작업입니다. 수많은 설계 방법들이 있지만 그 기본은 바뀌지 않았습니다. 카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 주창한ADD(Attribute-Driven Design, 속성 주도 설계) 방법이든, 다른 여러 아키텍처 수립 방법론들은 결국 이 방법을 체계화 한 것입니다.

UML과 같은 도구는 설계를 하는데 일부 도움은 될 수 있지만 설계에 꼭 필요한 것은 아닙니다. 설계한 결과를 적는 하나의 도구일 뿐입니다. 설계라는 작업은 소프트웨어 개발에 있어서 가장 자유도가 높고 창의성이 요구되는 작업입니다. 설계 기간은 선임 개발자들의 실력이 가장 많이 드러날 수 있는 기회이기도 합니다. 소소의 사람만이 쓸 수 있는 능력을 가지고 있는 SRS와는 달리 설계는 모든 선임개발자가 가져야 하는 필수적인 역량입니다. 설계에 대해서 너무 많은 제약을 가한다면, 좋은 설계가 나오기는 어려울 것입니다. 

그럼 설계의 끝은 어디일까요. 적어도 어느 정도까지 설계가 되어야 구현이 진행될 수 있을 까요?

설계가 끝나면 빌드(Build)가 시작되는 것이 기본 원칙입니다.

Class나 수많은 Public함수들의 Prototype이 모두 정의 되어 있고, Build Script까지 완성이 되어서 Daily Build가 시작됩니다. 그러면 Coder는 함수들의 내용과 Sub-function을 만들게 됩니다. Coder에게 함수와 Class를 어떻게 작성해야 하는지 설계서를 작성하는 것은 여기서 설명하기는 어렵겠죠.

여기서 말하려고 하는 것은 이정도까지 설계 단계에서 진행이 되지 않으면 Coder에게 일을 시키는 것은 사실 상 어렵습니다. 

설계를 중점적으로 담당하는 선임 엔지니어들은 지루한 코딩 작업은 가능하면 하지 않을려고 하죠. 설계가 훨씬 재미고 창의적인 작업이기 때문이죠. 그래서 코딩 작업은 신입사원이나 초급 개발자를 시키는 거죠.

이글을 보고 개발자들이 설계를 하는데 일말의 도움이 될 것이라고 생각하지 않습니다.

그냥 주변에서 돌아다는 Software Engineer, Archict, Coder등의 용어들에 너무 구애 받지 말고 자신의 일을 했으면 하는 바랍입니다.

물론 설계 능력 향상을 위한 노력은 매우 중요하죠. 수많은 책을 봤다는 분도 계시는데, 분명 도움이 될 것입니다. 그동안 쌓아온 많은 경험도 필수고요.

앞으로 계속 이에 대한 글들을 써보도록 하겠습니다.

위 글중의 일부는 제 책(소프트웨어 개발의 모든것)에서 인용했습니다.

각 블로그들의 인용문입니다.

저는 여전히 코더(coder)입니다~ by 써니

하지만, 분명하게 이야기 하고 싶은 것은 제가 매일 하고 있는 일은 코딩이지 설계가 아니라는 것입니다. 그 근거로서 말씀드리지요. 저희 회사에 개발자가 저 혼자 뿐입니다. 누구에게 지시를 내리고 할 위치가 아니라는 것입니다. 또한 코더와 아키텍트, 고수와 하수를 나누고 그들 사이에 편가르기를 시도하려고 하지도 않습니다. 편가르기를 하려면 어느 한 편에 서야만 하는데 저는 양쪽 위치에 다 서 있는 입장입니다. 개발을 하면서 프로젝트 매니저의 역할을 맡은 적도 몇번 있지만 그런 상황에서도 한번도 코딩을 손에서 놓은 적이 없습니다. 그러니까 지금도 코딩을 할 수 있는 것이죠. Software Design은 결코 쉬운 일이 아닙니다. 10년 20년을 개발했다고 해도, UML을 철저히 공부했다고 해도 여전히 어려운 것이 소프트웨어 디자인입니다. 실용주의 프로그래머, GoF의 디자인 패턴, Head First 시리즈, 아무도 가르쳐주지 않는 프로그래밍 설계 기법, XP 방법론, 리팩토링, Test Driven Development... 온갖 좋은 책을 다 읽어도 구구단을 쉽게 설계하는 법은 아무 책에도 나와 있지 않습니다. 즉, 현실 문제는 책에서 다루는 이상과는 달리 그 변화와 종류가 너무나 방대하기 때문에 정답을 얻기가 어려운 것입니다. 앞서 언급한 기술들과 그 기술들을 저술한 분들은 분명히 손꼽히는 대가인데도 말입니다.

  

꼭 그래야만 하는 이유

사실 Coder를 거치지 않는 Programmer, Architect는 존재하지 않는다고 봐도 무방합니다. 기본적인 Code에 대한 이해를 가지지 않고 그 일을 한다는 건(현실에서 ‘종종’ 있는 일입니다만..) 배재하고 이야기 해보겠습니다. Coder와 Programmer, Architect의 차이는 뭘까요? 남들 모르는 몇가지 알고리즘을 더 아는 것? 남들 모르는 지식 몇가지를 더 알고 있는 것? 그런 사소한 차이는 같은 Coder,Programmer 사이에 비일비재한 일입니다. 그런 것들로 Coder, Programmer, Architect 는 구분되지 않습니다. 그럼 (나름)구분 할 방법은 무엇일까요? 아니 사람들은 대체!! 어떤 기준으로 너는 Coder, 나는 Programmer! 이런 이야기를 하는 걸까요? 사실 저도 잘 모르겠습니다만… 위의 컨설팅 과정 중에 나온 여러가지 이야기들과 그간의 사람들과 대화를 나누며 격어본 경험들에 비추어 (여러가지로 표현가능하지만) 문제 인식의 차이라고 표현하고 싶습니다.

  

납득할 수 있는 설계를 어디서 배울 수 있을까?

업계에 설계전문 컨설턴트란 롤은 들어보지 못했다. 예로, 최근 설계에 대한 이슈를 안고 있는 대형 프로젝트가 두 개가 있는데.. 이례적으로 아키텍처가 상세하게 분화되서 분야별 아키텍트가 컨설턴트로 투입되었고, 솔루션 기반의 implementation consulting이라는 롤도 별도로 존재하고 투입되었다. 하지만 이런 환경임에도 설계 컨설팅은 없다. 별도 롤로 구분하지 않고 기술관련된 전반적인 문제들을 아키텍처 팀이나 그룹에 위임을 하는게 일반적인 프로젝트들의 전략이기 때문. 실제로 대형 프로젝트 아키텍처 팀이나 그룹은 그러한 이유로 팀사이즈가 꽤 큰 편.   그렇다면 프로젝트에서 누가 설계를 가이드해야 할까? 설계는 다분히 전략에 대한 내용들도 많고, 영향을 미치거나 받는 부분이 많다. 시간적으로도 일정 'phase'에 국한되지 않고, 특정 'discipine'에 한정되지도 않는다. 전략들을 설계로 모으고 드라이브 하는 사람은 방법론과 아키텍트. 아키텍처 적용이전은 방법론, 적용되는 시점부터는 아키텍트. 따라서 방법론, 아키텍트 둘의 긴밀한 협조로 설계를 일궈나가야 한다. 그렇지만, 200억, 500억대 프로젝트에서 아키텍트, 방법론 둘 다 빵꾸내기도 하는 이 현실은 완전 시궁창이지만서도..(먼산~)

  

꼭 그래야만 하는 걸까요?

너희 같은 하수는 평생 그렇게 코딩만 해라 나는 아키텍트의 길로 가련다... 하는 분들도 있을것 같네요. 예, 저는 하수 입니다. 당장 MFC나 위저드의 도움 없이는 Window도 제대로 생성하지 못하는 바보일 뿐이죠. 당장 개발해야 할 당면 과제는 COM 이나 CORBA 컴포넌트 제작이 아닌 제공되는 컴포넌트와 API를 이용한 어플리케이션 제작 입니다. 그렇다고 해서 삽질이나 하는 바보 개발자로 취급 받아도 좋은 걸까요? 훌륭하신 여러분들이 그렇게 무시하는 코더들은 그야말로 코드를 생산하는 위자드 보다도 못한 그런 사람들 일까요? 저는 잘 모르겠습니다. 그렇게 자기가 정한 기준에 맞지 않는 다른 사람들을 무시하는 풍토가 IT 업종의 3D화를 이뤄냈다고는 생각해본적 없으신가요?