굴뚝 기업이 어떻게 디지털화 할 수 있을까?
7년째 유통 IT에서 일하다 보니 소프트웨어 구축이나 개발 문화같은 본업에 더해 유통 비즈니스에 대해서도 흥미를 갖게 되었다. 사실 지금은 본업이 아니라고 할 수 없을 정도로 유통에 깊이 들어와 있다. 한편, 함께 일한 조직이 홈쇼핑에서 출발한 인터넷 쇼핑몰 회사였고, 지금은 의류 생산과 판매에서 출발한 유통회사다. 이렇다보니 IT 활용은 물론 소비자 환경의
한국형 개발이란 우물에서 벗어나기 위한 새로운 소프트웨어 원칙들
안내: 이 글은 운영을 중단한 개인 블로그에 2015년 11월 3일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다. 구독 중인 블로그에서 현대 소프트웨어의 새로운 원칙들이라는 흥미로운 글을 올라왔다. 글 내용보다는 저자가 번역을 한 동기가 매무 적절해 메아리처럼 공명하여 글을 쓴다. 조직이슈들은 일반 컨설턴트들이 접근 가능하지만, 기술이슈들은 개발자들의 숙제로 아직
마이크로 서비스 구축 경험 공유
아키텍처, 시스템 구성, 모델링, 개발 프로세스를 고민하고 만들었다기 보다는 현재의 조직 구성원으로 서비스를 만들 수 있는 가장 최선의 방법을 선택한 것입니다. 복잡한 것은 만들기 어려우니 아주 잘게 쪼개고, 잘 만들고 있는지도 모르겠으니 일주일에 한번씩 확인하는 방식이었던 것입니다. 우리의 여정이 11개월째로 접어들 때 합류한 김형준님이 내 의도를 너무나 잘 정의했다.[1]
차세대 프로젝트 딜레마 벗어나기
SSOT(Single Source of Truth) 실천을 위해 <차세대 프로젝트 딜레마에 대한 돌파구 (2017)>로 옮깁니다.
차세대 프로젝트 딜레마에 대한 돌파구
SSOT(Single Source of Truth) 실천을 위해 <차세대 프로젝트 딜레마에 대한 돌파구 (2017)>로 옮깁니다.
시스템 개선을 위한 REST API 도입?
안내: 이 글은 운영을 중단한 개인 블로그에 2015년 6월 9일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다. 어떤 경로나 동기로 찾았는지 지금은 기억나지 않지만, StackOverflow의 REST 관련 질문이 눈에 들어왔다. 인터페이스 계층과 비즈니스 계층 사이에 인터페이스로 API를 두는 것이 바람직한 아키텍처 설계인지 그리고 API 구축에 REST를 채용하는 것이
왜 시중은행은 카카오뱅크처럼 못하는가?
이전 글에서 카뱅 신드롬과 차세대 프로젝트란 소제목으로 아래와 같은 내용을 다룬 바 있다. SNS를 통해 접하는 지인들 소식이나 한국 뉴스를 보면 인터넷 전문은행인 카카오뱅크 이야기가 큰 화제다. 내 또래 소프트웨어 개발자에겐 짜릿한 현상이다. 15년, 20년씩 개발을 좋아해 이 일을 해왔던 이들에겐 도리어 긴 부조리속에서 기대했던 (당연한) 일이 벌어진 것이다. 반면에
적폐의 응용: The Application of 積弊
지난 정부에는 대한민국 소식을 일부러 듣지 않으려고 노력했다.[1] 누군가가 'CSS가 문제'라는 개발자만 이해할 수 있는 농담을 했을 때도 촛불집회 결과로 이런 변화가 있으리란 생각은 미처 못했다. 그 가운데 썩어빠진 언론속에서 새싹처럼 JTBC가 탄생하더니, 상상도 못할 방법으로 정권이 바뀌고, 상식적인 대통령이 나타났다. 그리고, 그가 주도하는 적폐(積弊)
설계란 무엇인가?
지난 주 기고에 이어서 모듈 구현을 위한 (중국) 동료 개발자와의 코드 리뷰 이야기를 계속한다. M은 자신이 만드는 모듈인 Tenancy와 다른 두명(X와 C)이 개발하는 모듈인 Shipping 사이의 연관성을 충분히 이해했다. 그래서 다른 둘에게 자신이 이해한 것을 설명해서 코드를 수정하게 하라고 요청했다. 다음 날, 코드 수정이 완료되어 리뷰 요청을 받았다.
다양한 아기발걸음으로 배우기
지난 주에 있던 일이다. 동료 중국 개발자에게 모듈 개념 구현을 설명하기 위해 코드 리뷰를 했다. 코드를 보며 다룬 대화의 내용을 대략 묘사하면 아래 그림과 같다. 모듈화의 기준은 무엇인가? 애초에 M(앞서 언급한 중국 개발자)이 짠 코드는 위 그림과 조금 차이가 있었다. M이 짠 코드는 Tenancy 모듈(우리는 REST API를
애자일이 중요한 것이 아니다!
간만에 네트워크 환경이 쾌적한 한국에 들른 김에 쓴 글이다. 흥행을 바라는 마음에 다소 자극적인 제목을 썼다. 요즘 애자일Agile은 한물간 키워드이긴 하지만, 그래도 실제로 겪은 바를 토대로 내 이야기를 하면 노력하는 실천가들에게는 조금이나마 도움이 되지 않을까 싶다. 2008년 첫 경험 PM프로젝트 관리자는 2008년 첫 경험을 했다. 그전까지 컨설턴트로 조언을 하거나 감시자
아마존에서 MS로 옮긴 백기선씨 이야기
우리나라 문화와 달리 쿨cool 할 것으로 여겼던 미국회사에서 겪은 쿨하지 않은 측면을 아마존에서 봤습니다. 아마존 입사 후 1년 동안 겪은 일련의 사건이 저를 돌아보는 좋은 기회도 된 것이 사실이에요. 다만, 그러면서 자신감도 많이 잃었습니다. 그러던 차에 한줄기 빛으로 저에게 손을 내밀어 준 것이 마이크로소프트(MicroSoft)입니다. 1편은 여기서 확인: 아마존