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

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

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

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

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

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

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

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

구분 Lagacy Approach 한국형 개발 Modern Software Principle 한국형을 벗어나 생존하기
Scalability Expensive two-phase commit 시스템이 아무리 커도 ERD는 하나로 통합 Eventual Consistency 무결성(Integrity)을 DBMS에 완전 위임하지 않기(무결성을 보장하는 시스템 분할-DB도 함께 분할)
Reliability Expensive reliable queues 멀티 채널 통합(MCI)과 같은 극단적 통합 Replication & Idempotency 나뉘어진 시스템에 대한 무결성 고민을 해봤어야 판단 기준 마련 가능
Unknown threats Rules and humans 보안 전문가를 이용해 개발자 겁주기 Data-driven 평소에 공개된 Rule 체크나 제대로 하자
Operations Care and revive 버티다가 차세대 (할 수는 있나?) Rip and replace (대충 묻고 사는) 결함 근본 원인 제거하기
Cooperating Services ESB and message broker (묻지마로) 벤더에 맡기기 Distributed networks 진짜 전문가나 오픈소스를 활용하되 결국은 자사 개발자가 해결


Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.