소프트웨어 스펙은 왜 쓰기 어려운가?

스펙을 잘 쓰는 것은 소프트웨어 프로젝트를 성공하기 위한 가장 중요한 요소중 하나라는 것은 이미 수차례 강조한 얘기다.

스펙을 적절히 제대로 작성하지 않았다는 얘기는 건설에서 설계도를 제대로 만들지 않고 건설을 하는 것과 같이 소프트웨어 프로젝트에서도 여러가지 문제를 야기시킨다.

• 프로젝트가 종료 일정을 지키지 못할 가능성이 높다.
• 소프트웨어 아키텍쳐가 엉망이 될 가능성이 높다.
• 소프트웨어 품질을 보장하기 어렵다.
• 개발자들이 야근에 내몰려 혹사를 당하기 쉽다.
• 개발에 관련된 지식 축적이 어렵다.
• 추후 요구사항이 변경되어도 소프트웨어에 어떠한 파급효과가 있는지 예측하기 어렵다.
• 업그레이드 프로젝트를 효과적으로 진행하기 어렵다.

실제로 많은 회사들에서는 소프트웨어 스펙을 잘 쓰기 위해서 많은 투자를 한다. 그럼에도 왜 스펙을 잘 쓰기 어려운가? 또한 개발자들이 분석 설계를 잘 할 수 있는 뛰어난 아키텍트로 성장이 잘 안되는가?

많은 개발자들은 독학을 통해서 뛰어난 프로그래머가 되기도 한다. 하지만 왜 스펙 작성은 독학으로 잘 안되는가? 스펙은 프로그래밍보다 훨씬 많은 측면으로 분석을 해야 하고 복잡하기 때문이다. 스펙 작성은 골프와 피아노에 비견되곤 한다. 그래서 스펙 작성을 골프와 피아노에 비교를 해보았다.

소프트웨어 스펙 작성	골프	피아노	효과
책을 보고 스스로 공부해서 스펙을 적는다.	골프 잘치는 책을 보고 혼자서 연습한다.	피아노 교본을 보고 혼자서 연습한다.	역효과
강연을 듣고 필요성을 절감해서 스펙을 적는다.	타이거 우즈 특강 모임에서 깨달은 바가 있다.	피아노 잘치는 법이라는 강연을 듣는다.	미미한 효과
인터넷에서 좋다는 Template을 구해서 각 항목을 채운다.	좋다는 골프채를 구매해서 골프를 친다.	좋은 피아노를 사서 열심히 연습한다.	미미한 효과 또는 역효과
일하면서 뛰어난 선배들이 작성한 스펙을 본다.	골프 연습장에 골프를 잘치는 프로가 많아서 수시로 골프 치는 것을 볼 수 있다.	피아노 교습소에 뛰어난 피아니스트가 있어서 연주를 수시로 볼 수 있다.	좋은 환경
스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	골프 코치에게 골프를 배우고 연습을 반복한다.	피아노 선생님에게 피아노 치는 것을 배우고 연습을 반복한다.	발전 가능성이 높은 환경
수년간 지속적으로 스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	수년간 실전 골프를 치면서 지속적으로 골프 코치에게 스윙을 교정받고 배운다.	수년간 피아노를 치면서 지속적으로 선생님에게 피아노 치는 것을 배운다.	발전 가능성이 가장 높은 방법
본인 스스로도 타 프로젝트의 수많은 스펙의 리뷰에 참여한다.	후배들의 골프 스윙도 봐주면서 이론적으로도 지식을 쌓는다.	후배들이 피아노를 치는 것을 봐주면서 조언을 해준다.	발전 가능성이 가장 높은 방법

이쯤 설명하면 많은 회사들이 왜 스펙을 잘 작성하기 어려운지 이해가 될 것이다.

개인관점으로 보면 좋은 환경을 갖춘 곳에서 일하는 것이 가장 좋다고 할 수 있다. 회사입장에서는 회사를 좋은 환경으로 만들고 좋은 관행을 만들어야 한다. 그럼 회사가 가져야 할 좋은 관행이란 무엇이 있을까?

• 뛰어난 아키텍트를 여러명 보유한다.
• 작은 프로젝트라도 스펙을 제대로 작성하고 개발하는 문화를 만든다.
• 철저한 정보 공유, 투명한 개발 환경
• 경영진을 비롯하여 많은 프로젝트 관련자들이 스펙을 충분히 리뷰한다.

그럼 반대로 이를 저해하는 나쁜 관행들은 무엇이 있을까?

• 빠르게 개발한다는 명목하게 주먹구구식 개발을 신봉한다.
• 원칙보다 기법에 현혹되어 여러 방법론을 기웃거린다.
• 복잡한 프로세스가 문제를 해결해 줄것으로 맹신하고 강요한다.
• 코딩이 가장 중요하다고 생각한다.
• 작성된 스펙에 관심들이 없어서 리뷰에 소홀하다가 개발 후에 부담없이 변경을 요구한다.
• 상명하복의 조직문화

이런 문화에서는 뛰어난 아키텍트가 있다고 하더라도 무용지물일 뿐이다. 회사는 좋은 관행을 만들어가고 개인들은 좋은 습관을 가지도록 노력할 때 수년 후에는 스펙을 제대로 작성할 수 있는 역량을 갖추고 소프트웨어 개발 역량이 글로벌 회사들과 경쟁할 중요한 기초 역량을 갖추어 가고 있다고 할 수 있다.

share with abctech.software

핵심은 아키텍트다

우리나라에는 뛰어난 프로그래머가 참 많다. 우리나라에서 연봉 4천만원 받는 개발자의 능력과 하는 일을 보고 외국의 억대 연봉 개발자가 입이 떡 벌어졌다는 우스개 소리가 인터넷에 떠돌고 있다. 전혀 근거가 없는 얘기는 아니다. 우리나라에서는 개발자가 많은 분야의 일을 해야 하고 밤을 지새면서 엄청난 양의 일을 소화하곤 하기 때문에 일단 많이 배우고 매우 빠르고 숙달되어 있다.

​

하지만 이것도 잠깐이다. 세월이 흘러 10년차, 20년차 개발자가 되고 나면 외국의 억대 연봉을 받았던 개발자와 비교해서 분석, 설계 역량에서 많이 뒤떨어지게 된다. 결국 연봉 값을 하게 된다. 이는 개발자들의 기본적인 재능이 아니라 환경차이 때문에 벌어지는 일이다.

​

우리나라에서는 빨리빨리 문화, 상명하복 문화를 비롯해서 여러가지 환경 때문에 아무리 좋은 프로세스를 도입한다고 해도 개발자들에게 분석, 설계 역량이 차근차근 축적이 되어서 10년, 20년 후에 뛰어난 아키텍트로 성장하기가 매우 어렵다.

[사진=Pixabay]

그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.

​

이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.

​

■ 비즈니스 이해해야 좋은 아키텍처 나와

​

소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?

​

한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.

​

누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.

​

좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.

​

우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.

​

왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?

​

개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.

​

개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.

​

설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트

일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.

​

■ "국내엔 축적된 노하우 계승해줄 선배들 부족"

​

그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?

​

빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.

​

소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.

​

아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?

​

대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.

​

이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론

수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.

​

그럼 아키텍트는 어떻게 양성해야 하는가?

​

교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

■ 아키텍트를 양성하는 세 가지 방법

​

첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.

​

둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.

​

셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.

​

막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.

​

조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

이글은 ZDNet Korea에 기고한 글입니다.

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

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

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

별 관계도 없어 보이고…

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

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

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

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

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

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

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

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

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

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

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

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