%EB%94%9C%EB%A0%88%EB%A7%88

차세대 프로젝트는 실패한다. 그렇다고 우리 시스템을 그대로 두어선 정상적인 기업 활동을 할 수가 없을 지경이다. 이 상황을 어쩌란 말인가? 나는 2년쯤 전엔 이런 상황을 차세대 프로젝트 딜레마 라고 이름 지었다. 흥미로운 사실은 그말을 쓸 당시 실제로 딜레마로 골치를 앓는 사람들이 있었다는 점이다. 그렇다고 해도 2년이나 지난 글을 다시 꺼내는 이유는 무언가? 당시 그 분들이 얼마 전 연락을 해왔다. 여전히 그 문제를 겪고 있다는 사실과 함께... 그 탓인지 방금 느닷없는 충동에 휩싸였다. 대상이 그 분들일지 아니면 어디선가 또 차세대 프로젝트 딜레마로 고민하는 분일지 모르지만, 내 경험을 살려 그들에게 전할 수 있는 책을 쓰고 싶다. 하지만, 책을 떠올린 것은 너무나 터무니없는 충동이란 사실은 순식간에 깨달았다. 책 쓰는 고통을 내가 감수할 수도 없을 터이고, 무엇보다 일반화 하거나 체계화 하지 않은 경험을 그대로 전한다고, 누군가에게 도움이 될 가능성은 거의 없다. 그래서, 책을 쓰는 충동을 억누르는 대신 스스로 선언하는 글인 동시에 앞으로 차세대 프로젝트 딜레마를 극복할 용기있는 누군가를 독자로 하는 주제가 둘인 글을 쓴다....

안내: 이 글은 운영을 중단한 개인 블로그 에 2015년 6월 18일 올렸던 글 입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다. 앞선 글 에서 슬쩍 차세대 딜레마란 말을 썼다. 흔히 듣던 말도 아니고 엄밀한 정의 없이 쓴 말인데, 요즘 많은 곳에서 시스템 운영 비효율을 겪지만 섣불리 ‘차세대 (프로젝트)’ 즉, 시스템 전면 재구축을 시행하지 못하는 경우를 본다. 이를 ‘차세대 (프로젝트) 딜레마’라 지칭했는데, IT서비스 업계(어느 기사에서 이렇게 표현하던데 개발자들 사이에서는 흔히 SI업계란 말이 많이 쓰인다)에 몸담고 있는 사람이라면 이런 현상을 인식하는 분들이 있을 것이다. 재작년엔가 보통 소문으로만 도는...

안내: 이 글은 운영을 중단한 개인 블로그 에 2015년 6월 9일 올렸던 글 입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다. 어떤 경로나 동기로 찾았는지 지금은 기억나지 않지만, StackOverflow의 REST 관련 질문 이 눈에 들어왔다. 인터페이스 계층과 비즈니스 계층 사이에 인터페이스로 API를 두는 것이 바람직한 아키텍처 설계인지 그리고 API 구축에 REST를 채용하는 것이 적절하냐( is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer...