아마존 킨들 개발자가 된 백기선씨를 만남
2015년 9월 작성하고, 10월 1일 개인 블로그에 올렸던 글을 다시 여기로 옮깁니다. 오래된 글을 다시 살려내는 이유는 그가 1년 넘게 겪었던 사실에 대해 최근에 알게 되었기에 이에 대한 글을 올리기 전에 지난 줄거리를 올리는 것입니다. 2006년 어느날 필자는 교수님의 소개로 백기선씨를 만나게 됩니다. 당시 학부생이던 백기선씨가 이제는 후배 개발자의 롤
기능이 형태를 지배해야 한다
아래는 문래학당 임춘봉훈장님께서 편집해주신 루이 설리번의 고전이다. 내가 아키텍트 혹은 설계자로써 딱 하나 잊지 않는 유일한 공학원리 항목이기도 하다. 공학적 배경지식이 없거나 건축에 소프트웨어 설계 은유를 하는 부분이 생소한 분을 위해 가벼운 글을 쓴다. 핵심가치가 무엇이냐? 혹은 너 기능이 뭐야? 가장 중요한 질문이다. '당신은 뭐하는 사람이냐?'라는 질문이
DDD의 Bounded Context와 객체 지향의 객체
내용이 빈약했는데, 2019년 1월 18일자로 사례를 섞은 다른 글을 올려 낡은 내용은 지웁니다. https://bit.ly/2sBaDxP
진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글 (2)
앞서 올린 글, 진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글이 (popit 운영자가) 상당한 조회수를 올렸다고 한다. 원래는 작년 6월 개인 블로그에 썼던 글을 다시 쓰기 한 것이다. 그러나, 목표는 조회수가 아니라 소통을 끌어내려 했는데 성공했다. (중국에선 읽기 어려운) 페이스북 댓글이 달렸음을 운영자를 통해 들었다. 반가운 마음에 어렵게 댓글을 읽을
아키텍처
진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글
이 글은 작년 6월 뉴스피드로 받는 기사 제목 Architects Don’t Decide만 보고 내가 중요하다 생각하는 어떤 것(모호한 것은 모호한 상태라고 명확하게 해두고 개발하는 노하우)과 비슷한 글이라 짐작하고 클릭한 행동에서 비롯한 글이다. 원문 기사는 보다 지루해서 그만뒀고, 결과적으로 한동안 잊고 살던 '아키텍트'에 대한 생각을 끄집어내게
두레이 서비스를 참조하여 계정관리 개선하기
또 다시 지난 글에 이어서 두 개발자와 대화한 내용을 공유한다. 세번째 설계 시리즈다. 우리는 2월초부터 두레이라는 훌륭한 협업 소통 도구를 쓰고 있다. 우리가 두레이에서 참조한 부분은 조직과 사용자 그리고 권한 관리 기능이다. 우리가 일종의 설계 개선 모임을 하는 2월 현재 우리는 Account라는 마이크로 서비스를 운영하고 있다. 사용자가 특별히 인지할 필요가
코드가 아닌 개념 레이어링과 폴리몰피즘
지난 글에 이어서 또 두 명의 개발자와 함께한 설계 개선이야기다. 어쩌다 보니 시리즈물이 되고 있다. 우리 팀은 새로운 도전으로 SaaS를 릴리즈 한 후, 비즈니스 속도를 맞추느라 개발 품질이 낮아지는 부담을 안고 있다. 비즈니스 속도를 늦추지 않는 선에서 틈틈이 이를 복구하는 상황이다. SW 본토인 미국(?) 표현으로 바꾸면 Technical Debt이 쌓여 있고,
함께 그리고 가볍게 하는 소프트웨어 설계의 즐거움
어느날 2층 사무실로 들어오는데 친한 두 개발자가 열띤 이야기를 하고 있었다. 흥미 있어 보여 안그래도 끼여들려는 찰나에 그들도 마침 내 의견을 물었다. 벽에 붙은 화이트보드에 아래 그림과 같은 것을 이제 막 쓰면서 새로 개발에 참여한 개발자 김형준님이 기존 개발자 장재휴님에게 JSON 형식 데이터 필드의 현재 뜻을 묻다가 '모호한 용어&
클라우드 비즈니스 - 사업자 관점에서 본 SaaS
중국에서 리테일 기업용 SaaS 서비스를 공급하며 겪은 일을 토대로 클라우드와 SaaS가 기업의 IT 의사결정에 어떤 의미를 가지는지 독자들의 생각이 더 발전되길 기대하며 글을 쓴다. 올해 5월경에 시범 서비스를 공급하고, 11월에 매출과 연동한 수수료 계약을 체결했다. 개인적으로는 한국에서 배운 노하우를 낯선 중국에 와서야 활용할 수 있던 묘한 상황이다. 일단 이 글에서는
중국 모바일 현황에 놀라다
SSOT(Single Source of Truth) 실천을 위해 <이미 10년 전, 중국 모바일 현황에 놀라다>로 옮깁니다.