마이크로 서비스(MSA)를 어떻게 나눌까? II
* 과거에 메모 수준의 관련 글을 남겼는데 이를 보완할만한 경험이 생겨서 조금 더 읽을 만한 글을 씁니다. 두 가지 사례를 소개합니다. 하나는 해당 업무 자체가 갖는 특성에서 출발한 마이크로 서비스 분리 사례입니다. 이를 도메인 주도라고 부르고 싶은데, 비즈니스에 적합한 모양으로 유연성을 구사하는 전략에 대한 실천 사례입니다. 두번째는 다른 이들이 만든 결과물을
조직 문화를 소프트웨어 개발 조직답게 만들어가기
정확히 이러한 문화를 뭐라 불러야 할지 모르겠다. 기민한 개발조직으로 만들려고 혹은 시장에서 도태되지 않기 위한 간절한 변화의 노력으로 지난 2년간 만들어낸 우리 조직[1]의 개발 문화에 대한 이야기다. 뭉뚱그려 말하면 애자일이라 할 수 있겠으나 애자일이라는 말의 쓰임이 너무나 다양하게 쓰여지고 있어 의미를 얼마나 전달할까 싶다. 아무튼 일을 해나가는 과정속에서
마이크로서비스
마이크로 서비스는 왜 점점 더 각광을 받을 수 밖에 없을까?
예언자처럼 말했다. 확실히 그럴 가능성이 높기 때문이다. 주식처럼 살 수 있다면 마이크로 서비스가 늘어난다에 여유 재산을 다 쏟아 부어도 좋다. 그런 확신이 어디에서 비롯된 것인지 여러분과 공유하는 것이 이 글의 주제다. 마이크로 서비스는 사업 전개 속도의 문제 현재 내 직업 일상은 비즈니스 속도를 높이는 일이다. 단언컨대 소프트웨어를 잘 활용하면 굴뚝
애자일에 대한 질문을 받았습니다
질문을 잘 이해하면, 질문한 사람이 '애자일'을 어떻게 바라보는지 조금이나마 알 수 있다. 그런 경우 보통 즉답을 하기 보다 한 번 더 생각한다. 그의 사고에 맞춰서 내 생각을 답해줄 것인가? 아니면, 그의 생각 자체에 대한 내 의견을 말할 것인가? 특히 그가 정의하는 '애자일'을 내가 포용할
우리은행 차세대 연기 소식을 보는 다른 시각
베이징에서 생활하다가 설을 보내려고 서울에 왔다. 소프트웨어 관련 종사자들이 다수인 필자의 페이스북 친구 글 상당수가 우리은행 차세대 연기 소식을 다루고 있었다. 과거에도 명절을 기해 차세대 시스템 오픈을 했던 터라 그러려니 하고 특별히 관심을 두지 않았다. 그랬는데 아이들 통장이 우리은행이라서인지 아내까지 우리은행에 대한 불평을 이야기했다. 필자가 금융권 프로젝트에 참여 했던 일은
나의 영어 기사 읽기 노하우 공개 - Kent Beck 글을 예시로
모처럼 즉흥 글이다. 아시는 분은 아시겠으나 필자는 팝잇의 다작 기고자이다. 사실 그건 별로 중요하지 않은데, 일상 업무를 올리고 있기에 주변분들에게 피해나 상처를 주지 않아야 하니 조심스럽다. 게다가 팝잇 운영자가 옆자리에 앉아 있기도 해서 (그가 아무런 압력을 행사하지는 않지만) 괜시리 글 품질에 신경을 쓰지 않을 수 없다. 과거에 Younghoe.info 운영할
프로젝트는 정치다
학부 마지막 학년에 배운 수업 중에 최고는 프로젝트 관리자로 잔뼈가 굵은 외부 강사가 강의했던 프로젝트 관리론 수업이었다. 그분 말씀중에 당시는 자주 강조해서 기억에는 남지만, 진짜 의미는 이해하지 못했던 한마디가 있었다. 프로젝트 관리는 정치다 강의를 들은 후 10년 정도가 지나 프로젝트 관리자 역할을 몇 차례 한 뒤에 알게 되었다. 명언이다. 최근
마이크로서비스
마이크로 서비스 공부하게 책 하나 추천해주세요
한 친구가 이렇게 요청했다. 아래와 같이 바꿔보면 개발자들 사이에서 흔히 들을 수 있는 패턴이다. OOO 공부하게 책 하나 추천해주세요. 내 동료 장재휴는 이렇게 말했다. 진짜 공부하고 싶으세요? 그러면 팝잇에 있는 글이 제일 좋아요. (돈 들일 필요도 없는데...) 공교롭게 질문을 받기 직전에장재휴가 나에게 말했다. 사람들이 팝잇에 올라온 마이크로 서비스 글이 정말
소프트웨어 엔지니어링에 작별을 고하는 친구(?)의 글을 읽으며
공감 120%의 글이다. 제목은 Say Goodbye to Software Engineering (And Why Software Projects Never End) 직역하면 소프트웨어 엔지니어링에 작별을 고한다, 그리고 왜 소프트웨어 프로젝트가 끝이 없어야 하는지에 대하여 저자의 이름은 Simon Lee. DZone 기사로 접했을 뿐 모르는 사람이다. 하지만, DZone 게시판에 나눈 필담[1]을 근거로 친구로 칭하기로 했다.
인터넷 기업이 아닌 회사는 왜 IT를 활용하지 못하는가?
왜 시중은행은 카카오뱅크처럼 못하는가? 에 이은 두 번째 연재이다. 그러나, 기획에 의한 것이 아니다. 내 안에 있던 답답함이 계속 쓰도록 자극할 뿐이다. 한편으로는 직업의식이고, 다른 한편으로는 동시대를 살아가는 우리나라의 현실에 대한 오지랖이다. 연속성을 갖고 보기 위해 앞선 글을 다시 읽어 보자. 시장에서 성공했다는 솔루션 도입 자체로 효과가 나길 바라는 태도를
마이크로 서비스 아키텍처: 디지털 시대의 리테일 유연성
* 이 글은 소트웍스의 독일 리테일 책임자 Frank Potozki와 리테일 수석 Marcus Klein이 쓴 Microservices architecture: flexibility for omni-channel retailers라는 제목의 기사를 번역한 것입니다. 쇼핑하는 방식이 빠르게 바뀌고 있다. 변화 속도가 리테일 종사자들의 정확한 예측을 점차 어렵게 한다. 리테일 종사자가 미래 고객 기대를 모르고 있다. 확실한 점은 매력적인 상품구색만으로는 더
개발자
모던 아키텍트에 대해 개념 잡아보기
책을 읽다가 전에 써둔 글이 떠올라 찜찜했다. 이글을 쓰는 현재 시각 무려 328개의 페이스북 좋아요를 기록하고 있는 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐[1]에 대한 것이다. 서울대 공대 교수들이 지적하는 아키텍트 부재 연말부터 축적의 시간이란 책을 다시 펼쳤다. 현재까지 반 정도[2]밖에 읽지 않았지만, 아키텍트 부재를 대한민국의