소프트웨어 아키텍처와 가장 연관이 있는 것은 조직과 문화

 소프트웨어들의 완성된 모습을 보면 그 소프트웨어를 만든 조직의 모습과 놀랄만큼 닮아있는 것을 보게 된다. 콘웨이법칙이라고 해서 나름 유명한 법칙이다.

 이는 단순히 모듈의 갯수나 레이어등을 말하는 것 뿐만 아니라 Responsibility나 Collaboration 방식까지도 매우 유사하게 된다.

 최근에 많은 기업들이 우수한 소프트웨어를 만들기 위해서 해외의 유명한 전문가들도 모셔오고, 강의도 듣고 BP를 찾아서 적용하기 위해서 노력한다. 그런데 가장 중요한 것은 문화이다.

 Top-Down방식으로 경영전략을 세우고, 조직별로 목표를 수립하고 KPI를 달성하기 위해서 일하면, 그러한 모습의 소프트웨어가 나온다. 정해진 프로세스를 준수했기 때문에 정해진 결과물이 나온다. 때로는 수준에 못 미치더라도 억지로 끌어올린다. 품질지표를 만족하는 결과물이 어떻게든 나온다.

그러나 그 소프트웨어의 수명은 조직의 수명과 동일하기 때문에 몇년뒤면 자연스럽게 사라지고 다시 다른 소프트웨어를 만들기 시작한다. 개발자는 그때 그때 필요한 부품에 불과하다.

이렇게 해서는 절대 좋은 소프트웨어가 만들어질 수 없다.

 하나의 소프트웨어 프로덕트가 어느정도의 안정성과 성능, 기능을 확보하려면 제품마다 다르겠지만 최소한 2년, 넉넉하게는 3~5년정도가 걸린다. 그리고 이러한 성장가능한 구조, 아키텍처를 세우는 것은 무엇보다도 중요하다.

 가장 피해야 할 시나리오는 다음과 같다. 최초 A사이트를 타겟으로 v 1.0 을 만들었다. 이후 B사이트가 새로 생겼다. 그런데 새로운 요건을 만족시키기 위해서는 v 1.0 로는 안되기 때문에 v 2.0을 만든다. 물론 v 1.0과는 호환이 안된다. C사이트가 새로 생겼다. 다시 v 3.0을 만든다. 버전별 유지보수는 시간이 흐를수록 불가능이 된다..

 그렇다고 좋은 아키텍처를 잡기위해서 초반에 마냥 시간을 보낼 수도 없다. 우리가 선정한 기술이 목표와 부합하는지 검증도 해야하고, MVP모델도 개발해야한다. 실제 적용도 빨리 해봐야 더 많은 요구사항을 뽑아낼 수 있다. 이러한 과정을 진행하기 위해서 우리는 시간이 매우 부족하기 때문에 애자일을 선호하게 된다.

 많은 사람들이 착각하는 것이 애자일을 하나의 방법론으로 이해하고, 과거해왔던 방식처럼 무언가를 자꾸 적용하고 표준 프로세스와 산출물을 만들려고 한다.

착각하면 안된다. 애자일의 핵심은 좋은 코드를 빠르게 만들어 내는 것에 중점을 두고, 이를 방해하는 것들을 없애는 것이다. 필요한 것을 넣는 것이 아니라 필요없는 것을 빼는 것이다. 꼭 필요한 것만 남기는 것이다.

애자일을 설명할 때 나오는 수많은 기법들이 있다.

이건 그냥  "우리가 이렇게 해봤더니 도움이 되더라.."  일뿐이다. 참고자료이지 정답은 아니다.

애자일 선언과 그 배경원칙들에 대해서 수십번 읽어보시고 곱씹어보시기를 추천드린다.

 기존에 개발팀이 개발하던 방식을 존중하고, 그들의 문화를 관찰해야 한다. 개발자 한명 한명의 성향까지도 고려해야 한다. 어느조직에나 딱 맞는 방법론이란 존재하지 않는다. 자신들만이 가지고 있는 방법을 더욱더 간결하게 다듬어서 맞춰가는 것이 애자일이다.

 실질적으로 이렇게 일하는 문화가 자리잡히면 자연스럽게 Bottom-Up으로 할 일들이 도출된다. 내가 이렇게 만들었더니 이러한 단점이 있더라. 이걸 어떻게 보완하면 좋을까? 서로 의견을 나누어서 더 나은방향으로 개선시킨다. 

 자신의 설계를 공유하고, 코드를 공유하며 Review한다. 자연스럽게 소프트웨어의 품질을 올라갈 수 밖에 없다.

 남들에게 뒤쳐지지 않기 위해서 스스로 학습하고 새로운 것을 항상 찾아본다. 냅두면 알아서 공부하고 자기가 만든 분신과도 같은 소프트웨어를 더욱 발전시키기 위해서 노력한다. 자기주도 학습이다.(self-self-self!!!)

다른사람들과 개발순서를 맞춰야 하기 때문에 자연스럽게 일정이 조정되고, 그 일정은 매우 타이트하다.

 스스로 세운 일정을 준수하는 것은 본인과의 약속이기 때문에 누가 시키지 않더라도 야근을 한다. 그리고 만족할만한 성과가 나온 날은 기분좋게 일찍 퇴근한다. 

다른 사람들은 속일 수 있을지 몰라도 나 자신은 속일 수 없다.

 개발자의 역량이 발전하고 다시 소프트웨어는 새로운 기능으로 무장한다.(개발자에게 있어서 소스는 분신과 같은 존재이다.)

왜 조직은 개인을 믿지 못하고 자꾸 관리하려 드는가? 이에 대해서는 각자 반성해볼 필요도 있다.

그동안 개인은 어떻게 일해왔길래 조직이 신뢰할 수 없는 것일까...

좋은 소프트웨어는 관리를 통해서 만들어질 수 없다.

좋은 아키텍처는 좋은 조직과 문화에서 만들어진다.

조직과 문화는 사람이 만들고 구성원은 계속 변화한다.