객체지향의 탄생-프로젝트의 우선 순위에서 코드 품질이 최하위인 이유

4,5년차 자바 개발자였을때 나는 어떤 수수께끼를 궁금해했다. SI 할때는 왜 객체지향적으로 유연하고 확장성 높고 재사용이 가능한 개발이 안될까. 밤늦게 야근 하고 집에가는 어느날, 그때 어느 그림이 그려졌다.

 

[고민을 해결해 주는 컴포넌트 그림]

 

이 그림으로 모든 수수께끼가 해결했다. 왼쪽과 오른쪽의 컴포넌트는 같은 기능을 수행하는 컴포넌트이다. 예를 들어 우리가 자주쓰는 컴포넌트에는 네트워크 모듈이 있다. 저 컴포넌트 둘이 네트워크 모듈이라고 한다면 저 왼쪽과 오른쪽의 컴포넌트는 인풋과 아웃풋이 똑같은, 인터페이스가 똑같은 컴포넌트이다.

 

상단의 동그란 작은 원이 다른 코드에서 접속하는 인터페이스가 된다. 둘 컴포넌트의 차이는 왼쪽의 컴포넌트 안은 스파게티 면처럼 내부가 얽히고 섥혔고, 오른쪽의 컴포넌트는 잘 모듈화 되어 깔끔하게 구성되어 있다.

 

그래도 인풋과 아웃풋은 같다.

 

컴포넌트 내부 구성이 잘 되어 있어도 인풋과 아웃풋은 같다. 관리자는 내부 구성을 알 수 없다. 오직 인풋과 아웃풋의 정상 작동으로 컴포넌트의 성능을 판단한다. 프로젝트 우선순위에서 품질이 최하위인 이유는 내부 코드 품질이 엉망인 컴포넌트와 내부 코드 품질이 우수한 컴포넌트에서 눈으로 보이는 차이점을 찾을 수 없기 때문이다.

 

이 상황에서 일정을 압축하게 되면 일단 눈으로 보이는 결과물이 최우선순위가 되면서 체계적인 코드 구성과 코드 정리할 시간이 주어지지 않기 때문에 내부 코드 품질은 엉망이 되고 어떻하든 명시된 인풋 아웃풋을 맞추게 된다.

 

문제가 여기서 끝나면 다행이다. 더 큰 문제는 엉망이 된 내부 코드 품질 때문에 버그와 유지보수가 어려워지면 개발자 탓을 한다는 것이다.

 

코딩을 어떻게 했길래 버그가 생기냐~ 너는 코딩을 발로 짜냐~

 

그래서 일은 일대로 고되게 하고 자존심에 상처 입으면서 욕을 먹을 수 있다. 개발자가 바보되는 전형적인 경우이다. 이런 경우가 되지 않기 위해서 관리자가 과도한 일정압축을 요구하면 아무말 하지 않고 투덜 투덜 수용하지 않고, 이런 일정이면 버그와 유지보수 편의성에서 문제가 발생하고 나는 이런 일에 책임을 져야 한다고 어필을 할수 있어야 한다. 그러나 위엄있는 갑들에게 이런 어필 할수 있는 상황이 얼마나 될것인가 라고 생각하면 답이 보이진 않는다.

 

SI에서 객체지향적으로 개발하기 힘든 이유는, 일정에서 코드 내부 품질을 신경쓸 시간을 주지 않기 때문이다. 관리자가 코드 내부 품질을 일반적으로 고려하지 않는 이유는 저 그림처럼 내부 코드 품질 과는 관계없이 컴포넌트의 인풋 아웃풋이 같기 때문에 관리자로서는 굳이 내부 코드 품질을 신경쓰지 않아도 기능이 잘 돌아가는것 처럼 보이기 때문이다.

 

일정을 압축해서 생기는 버그와 코드의 질적저하를 자기탓이라 생각하지 않고 개발자의 실력 문제라고 생각하기 때문이다. 내부 코드 품질을 무시하면서 생기는 항아리에 구멍이 뚫린것과 같은 유지보수 비용의 누수는 눈에 잘 띄지도 않고 관리자가 책임지는 범위에서 벗어나기 때문이다. 그렇다면 프로젝트 우선순위에서 내부 코드 품질도 고려하게 만들거나 내부 코드 품질을 신경쓰는 곳으로 갈수 있을까.

 

납기일 준수가 최우선 순위인 우리나라 SI는 코드 품질에 신경쓰는 것이 불가능에 가깝다. 시원하게 포기하는 것이 낫다. 한번 코드 품질을 신경써보자~ 해도 단순 기능 구현에만 월화수목금금금 매달려도 될까 말까이다. 늪에 빠졌다면 죽기전에 늪에서 빠져나오는게 급하지 같이 빠진 장비나 옷을 신경쓰지 못하는 경우와 같다.

 

그렇다면 내부 코드 품질을 신경쓰는 프로젝트로 가는 방법이 있다. 솔루션 개발 업체는 관리자가 납기 준수뿐 아니라 내부 코드 품질도 관심을 가질 가능성이 있다. 개발자 컨퍼런스도 열고 개발자 문화가 고도화된 큰 회사로 가는것도 방법이다.

 

솔루션, 프레임워크 개발 업체이면서 개발자 그룹이 고도화된 곳으로 간다면 납기일 준수가 제일인 우리나라 아이티 환경에서, 나의 개발 스킬도 키우면서, 좋은 코드로 회사의 유지보수 비용 절감에 기여하고, 개발자 본인의 자존심도 세울수 있을것이다. 그러나 내가 겪어봤던 솔루션, 프레임워크 개발 업체들 역시 제안서만 화려하게 쓰고 실제 솔루션은 솔루션 개발자들이 SI에 같이 나와 솔루션을 SI 처럼 개발해서 SI개발자들을 베타테스터로 만드는 경우를 많이 겪었다.

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다.