%EC%B0%A8%EC%84%B8%EB%8C%80

코로나19로 달라진 삶을 이야기하는데, 우리회사(베터코드 주식회사)의 상황과 내 삶 역시 많이 달라졌다. 나이탓인지 우리가 공동체의 생활을 한다는 사실을 점차 체감한다. 내 삶에 급격한 변화가 일어나는 3개월 남짓의 기간동안 겪은 일중에 공동체에 내놓아 함께 논의할 만한 내용이 있어 글을 쓴다. 서울에서의 영업 시작 코로나19로 인해 그간 북경에 상주하며 중국에서 SaaS 시장 진입을 노리던 일을 일단 중단하기로 했다. 일보 후퇴 후에 전진해야 하는 상황이 되었다. 일단, 가만히 있지 못하는 성미가 작용했다. 아직 중국 철수를 결정하기 전에 북경 복귀를 기다리던 중에 사회적 거리두기 때문에 조심스럽게 몇몇 기업에서 비슷한 고민을 하는 분들을 만났다. 대개는 서울을 떠나기 전인 5년 전 즈음까지 인연을 맺었던 분들이다. 그들과 나눈 주제는 다양했지만, 함께 나누는 이야기의 키워드는 '클라우드', 주로 리테일 부문의 'Digital Tranformation' 그리고 '리팩토링'이었다....

베이징에서 생활하다가 설을 보내려고 서울에 왔다. 소프트웨어 관련 종사자들이 다수인 필자의 페이스북 친구 글 상당수가 우리은행 차세대 연기 소식을 다루고 있었다. 과거에도 명절을 기해 차세대 시스템 오픈을 했던 터라 그러려니 하고 특별히 관심을 두지 않았다. 그랬는데 아이들 통장이 우리은행이라서인지 아내까지 우리은행에 대한 불평을 이야기했다. 필자가 금융권 프로젝트에 참여 했던 일은 2010년이 마지막이다. 8년의 세월이 지났고, 더구나 보험이나 공금융의 경험일 뿐, 은행에서는 일해본 일도 없다. 그럼에도 불구하고 이 글을 쓰는 이유는 아직도 과거의 방식에 익숙한 분들께 시대가 바뀌었음을 알려드리고 싶은 마음이다. 알려드리고 싶다고 그들이 읽으려 할지 또는 들으려 할지에 대해서는 회의적이지만, 감사하게도 답답한 마음은 여기에 털어놓을 수 있다. 해외에 나가보면 배운다....

차세대 프로젝트는 실패한다. 그렇다고 우리 시스템을 그대로 두어선 정상적인 기업 활동을 할 수가 없을 지경이다. 이 상황을 어쩌란 말인가? 나는 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...

지난 주에 있던 일이다. 동료 중국 개발자에게 모듈 개념 구현을 설명하기 위해 코드 리뷰를 했다. 코드를 보며 다룬 대화의 내용을 대략 묘사하면 아래 그림과 같다. [caption id="attachment_13446" align="aligncenter" width="472"] Multi-tenancy를 위한 배송(shipping) 모듈 설계[/caption] 모듈화의 기준은 무엇인가? 애초에 M(앞서 언급한 중국 개발자)이 짠 코드는 위 그림과 조금 차이가 있었다. M이 짠 코드는 Tenancy 모듈(우리는 REST API를 제공하는 웹 서비스를 모듈이라 부른다)에 접근할 때 파라미터로 태넌트 ID를 주면서 특정 택배사가 우리 시스템에 발급해준 key 값을 받아왔다. 내가 M에게 조언한 것이 바로 위 그림처럼 '외부 시스템이 발급한 key를 Tenancy에 넣지 말고 택배사 식별자 정도로 수정하자'는 내용이다. 이해를 돕기 위해 그림을 조금 바꾼다.   [caption id="attachment_13447" align="aligncenter" width="600"]...