한국형 개발이란 우물에서 벗어나기 위한 새로운 소프트웨어 원칙들

안내: 이 글은 운영을 중단한 개인 블로그에 2015년 11월 3일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다.

구독 중인 블로그에서 현대 소프트웨어의 새로운 원칙들이라는 흥미로운 글을 올라왔다. 글 내용보다는 저자가 번역을 한 동기가 매무 적절해 메아리처럼 공명하여 글을 쓴다.

조직이슈들은 일반 컨설턴트들이 접근 가능하지만, 기술이슈들은 개발자들의 숙제로 아직 문제정의조차 되고 있지 않습니다.

(2003년부터 국내 IT컨설팅 회사에서 일해온 경험에서 볼 때) 안타깝게도 국내에선 개발자와 기술적 소통을 할 수 있는 컨설턴트는 극히 드물다. 데이터베이스 설계 영역은 상대적으로 매우 앞서 있지만, 애플리케이션 구축 관련한 전반적인 기술 수준은 10년 가까이 정체된 듯 한데, 확실한 점은 개인이 갖고 있던 노하우가 IT서비스 업계(아웃소싱을 전제로 한 컨설팅 + ITO + SI 업체) 노하우로 확산되지는 못했다. 업계 환경이 그렇다보니 지나치게 데이터베이스 의존적인 개발만 반복해서 점차 우물 안 개구리로 전락 해버린 것이 아닌가 싶다.

그렇다 보니 아무리 좋은 글이라도 Apigee가 맥락으로 삼는 개발 방식과 우리의 개발 방식의 차이를 무시한 단순 번역은 별다른 시사점을 주지 못한다. 우리가 행동으로 옮기지 못하면 무슨 의미가 있겠는가?

필자가 작년에 QCon SF 참석하고 충격을 받았는데, 이유인즉슨 우리와 미국의 프로그래밍 이슈는 전혀 달랐다. 사용하는 언어(혹은 오픈소스 제품)가 같을 뿐, ‘개발’이라고 부르는 행위 즉, 코드로 만들어내는 내용이 너무나도 달랐다. 그 후 필자는 지인들에게 우리 방식(몇몇 기술적으로 앞서가는 서비스 회사 개발자들이 쓰는 기법이 아닌 보편적인 아웃소싱 개발 방식)을 ‘(곧 지구상에 사라질) 한국형 개발’이라 부르고 있다.

사설이 길었는데, 번역의 가치를 더하고자 Apigee가 제시한 표를 ‘한국형 개발 탈피’ 관점에서 재해석했다. 깊이 고민한 것이 아닌 즉흥적 정리라서 표현이 거칠다. 누군가 피드백이나 댓글을 주신다면 정제할 수 있겠으나 시의성 있는 주제이기 때문에 꾸물거리기 보다는 글을 빨리 노출하는 편을 택한다.