개인적인 경험담이다.

개발자로써 프로젝트 중간에 투입되어 소스를 보면 일단 그림이 머릿속에 안그려진다. 기존 개발자에게 물어봐도 사각형 몇개그려놓고 이게 다라고 한다. 이 단계는 너무 추상적이여서 실제 개발에서는 별의미가 없다.

즉, 아키텍쳐에 룰이 없고 개발자맘대로 라는것이다.

문제는 알고있지만 한국 특유의 계급문화로 문제제기도 힘들뿐더러 설사 하더라도 쉽게 묵살되고 난리쳐봐야 자기만 손해라는것을 본능적으로 느낀다. 더구나 아는것도 없다면 지금 프로적트에서 하는것이 정답인것처럼 강요받아 점점 꼰대 개발자로 변해간다. 완성도 높은 소프트웨어의 레퍼런스조차 없다보니 결국 쳇바퀴도는 일밖에 안된다.

실제 코드를 분석해보면 공통적인 부분이라곤 '초기화는 사용하기 전에 하자' 정도밖에 없다. 이건 해당 프로젝트에 아키텍쳐가 없는것이다. 실제 개발자가 느끼고 있는 룰은 해당 언어의 것이거나 차용해온 프레임워크의 것이지 해당 프로젝트에 대한 룰은 아니다.

개발이 시작되면 개발자는 자유롭다. 여기저기 메소드를 만들고 여기저기서 호출한다. 여기서 안되면 좀더 상위스트림으로 올라가 호출해보기도하고 순서를 바꿔보기도 한다. 완벽하게 파악하지 못해도 상관없다. '내 로직은 독립적이니까 남이 만든로직에 내꺼하나 껴넣는다고 뭐 달라지겠는가' 라는 생각이 앞선다. 컴파일은 잘되고 겉보기도 그럴듯하다.

이렇게 몇번하다보면 코드에 계층이 희미해진다. 계획안된 전역변수가 여기저기 생성된다. 그럴듯한 이름의 남의 변수를 가져다쓴다지저분한 if else 가 삽입된다. 개발자 입장에서는 어쩔수가 없다. 비슷한 if else 들을 묶어보지만 한계가있다.

버그가 생기거나 요구사항이 바뀌면 지옥문이 열린다. 처음엔 if else 몇개 집어넣으면 될것같았던일이 이것저것섞이면서 더많은 변수와 if else 들이 생성된다. 이젠 이름 짓는것도 일이다. 슬라임처럼 하나의 변수가 두개로 나눠진다. 성능개선이슈나 주기적으로 가끔 튀어나오는 이슈라도 생기면 집에갈생각을 버려야된다.

개발은 점점 느려지고 사이드이펙트 때문에 버그하나고치기 조차 두렵다. 하나고치면 세개가 튀어나오는 매직박스다.여기까지 오면 뜯어고치기란 불가능에 가깝게 된다.

이젠 기존 아키텍쳐는 찾아볼수가 없고 한덩어리의 코드뭉치가 되어있다.

좋은 프레임워크와 플랫폼에는 추상화가 잘되어있고 강력한 룰이 있다. 안드로이드 엑티비티 라이프사이클같이 직관적이고 gstreamer처럼 추상화단계에서 그림이 그려진다. 프로젝트가 커지다보면 여러 프레임워크를 차용하고 상용라이브러리, 오픈소스들이 혼합된다. 하나의 프로젝트는 하나의 프레임워크처럼 움직여야한다. 이를 위한 룰은 필수이다. 좋은 룰이 있으면 그 프로젝트 자체가 좋은 프레임워크가된다.

추상화가 잘되어있으면 롤이 명확하다. 어떤 계층에서 무엇을 구현해야하는지 쉽게 알수있다. 어느 부분이 문제인지도 쉽게 알수있다. 내가 구현한부분이 어느곳에 영향을 미칠지 룰에 의해 보장받는다.

따라서 반드시 상위수준에서 코드를 바라볼 개발자가 필요하다. 그사람이 아키텍터, 프로젝트리더, 동료개발자 누구라도 될수있다. 익스트림프로그래밍에서 페어프로그래밍 룰 도입도 고려해볼만하다.

이대로라면 우리나라 소프트웨어는 10년이지나도 똑같을것이다.