마이크로서비스
마이크로 서비스 못 다한 이야기
지난 해 썼던 마이크로 서비스 구축 경험 공유 그리고, 김 형준님 시각으로 쓰여진 Micro Service, Docker로 할 수 밖에 없었던 사연에 빠진 내용을 써서 공유하고 싶다. 쓰기에 앞서 독자 입장에서 어떤 효용이 있을까 의심스러워 몇 가지 질문을 해본다. * 다른 이의 경험은 얼마나 전달될까? 또, 전달 여부는 무엇으로 확인할 수 있을까?
팝잇 글쓰기 경험 회고
2017년 popit 회고에 자극받아 그간 팝잇에 썼던 글을 훑어보고, 그 경험을 한번 되짚어보려고 한다. 그 과정에서 쓰는 욕구에 충실했던 입장에서 한발 떨어져 스스로 회고해보려고 한다. (그래서 뭘 얻을지는 아직 모르지만) 마지막으로 올린 글이 컴퓨터과학이 여는 세계인데 처음 글을 올린 시점은 2016년 11월 6일이다. 1년이 조금 넘는 14개월동안 올린 글은 45개로,
컴퓨터과학이 여는 세계
이 글은 이광근교수님께서 쓴 동명의 책에 대한 소개이자 독후감이다. 서점 가판대에 놓인 책을 보자마자 신기하고 반가웠다. 그 느낌은 '드디어 우리에게도 이런 책이 나온단 말인가?' 였다. 당시 옆에서 지켜본 지인께서 책을 사서 선물하셨다. 딱히 읽고 싶어서 집어든 것은 아니었고, 앞서 말한 반가움의 표현이었는데, 마치 내가 읽어야 할 사람이라는 듯이
사용자 스토리, 사용자 이야기 혹은 우리들 이야기
개발을 여러 층의 케익으로 나누기 번역 검토를 할 때 임춘봉님이 User Story를 사용자 이야기라고 번역하면 안되느냐고 물었다. 이런 견해의 배경에는 애자일에 대한 배경 지식이 부족한 점과 모국어로 소화하지 않으면 의미를 제대로 이해하기 어렵다는 그의 신념이 있다. 이를 아는 나는 잠깐 생각해봤다. 머리속에서는 '딱히 안될 것은 없지'라고 떠올랐는데,
복잡한 기술 스택이 경영진에게 주는 시사점
당신이 경영진의 일원이나 관리자 심지어 대표이사로서 기술스택 문제를 다뤄야 하는 이유는 무엇인가? 기술스택 문제는 기술자들이 다루면 될 일 아닌가? 그렇지 않다! 소프트웨어와 소프트웨어 개발은 디지털 미래를 여는 열쇠이다. 따라서, 구체적인 사항까지는 아니더라도 전반적 추이가 여러분 조직에 의미하는 바를 반드시 이해해야 한다. 기술은 다양한 형태로 차별화와 혁신을 주도한다. 경영진과 관리자는 다양한 기술이 시사하는 바를 반드시 이해해야 한다. 그래야만 올바른 의사결정을 할 수 있다.
Spring Boot에서 Spring MVC 활용
* 이 글은 2016년 1월 개인 위키에 올렸던 글을 옮긴 것임을 알려드립니다. 공식 참조 문서를 토대로 Spring Boot에서 JPA와 Spring Data 활용에서 코드 바꿔가기 기존 코드 변경하기 Spring Boot에서 JPA와 Spring Data 활용에서 작성한 Example 클래스를 수정하여 활용하자. 기존 코드에서 cities와 makeCollection 메소드만 제거한다. package city; import org.springframework.boot.SpringApplication;
Spring Boot에서 JPA와 Spring Data 활용
* 이 글은 2016년 1월 개인 위키에 올렸던 글을 옮긴 것임을 알려드립니다. 공식 참조 문서 29.3. JPA and ‘Spring Data’ 내용 설명 라이브러리 추가 빌드 스크립트에 아래와 같이 두 줄을 추가한다. dependencies { ... compile("org.springframework.boot:spring-boot-starter-data-jpa") compile("com.h2database:h2") ... } 첫
Gradle을 이용한 Spring Boot 설치 빌드 스크립트
* 이 글은 2016년 1월 개인 위키에 올렸던 글을 옮긴 것임을 알려드립니다. 공식 참조 문서의 10.1.2. Gradle installation 내용에 쓰인 빌드 스크립트(build.gradle)에 대한 설명 빌드 스크립트 build.gradle buildscript { repositories { jcenter() maven { url "http://repo.spring.io/snapshot" } maven { url "http://repo.spring.
UML 모델 그릴 필요가 있을까?
설계에 최소한의 노력만 하라고 말하면서 UML 모델을 남용할 수는 없다. 그렇지만, 가끔 그리고 싶은 충동을 느낄 때가 있다. 대부분은 대화과정에서 즉흥적으로 매직으로 그린 경험이다. 대화할 때 흔히 쓰는 UML 도해 popit에 올려둔 글만 보아도 대화하며 설명을 위해 그린 흔적이 있다. 대략 쓰임새를 요약해보면 다음과 같다. * 어떤 개념(예: 판매처가 다양할
오픈소스에 대한 미신과 배움의 비밀
* 이 글은 개발자를 대상으로 쓴 글은 아닙니다. 경영자나 IT기획하시는 분들의 보편적이 오해를 풀 수 있을까 하는 마음, 더욱 솔직하게는 그냥 지켜보고만 있기가 답답해서 쓴 글입니다. 유명한 회사가 오픈소스 솔루션을 썼다 무슨 의미가 있을까? 한 5, 6년 전에 '아마존처럼 하고 싶다'는 컨설팅 의뢰가 꽤 있었다. 지금 누군가 오픈소스
어느 중국 개발자의 모델링 시작하기
사람마다 자기만의 이야기가 있다. 이제 공유할 이야기는 이제 막 모델링을 시작한 개발자 이야기다. 그는 북경에서 무려 특급 열차高铁로 7시간 떨어진 곳에 근무하는 원격 개발자이고, 내가 매우 좋아하는 중국 개발자[1]다. 얼마 전 그는 새로운 서비스 개발 착수 미팅을 하려고, 북경에 방문했다. 그 때, 한 시니어 개발자가 그에게 작년처럼 그냥
아키텍처
이제 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐
팝잇에 예전에 썼던 글의 댓글을 한참 후에 발견했다. 그러던 중, 하나의 글에 달린 댓글에 답변을 달고 있는데 데자뷰가 느껴졌다. 언젠가 이런 일을 했던 느낌... 다시 아키텍트란 개념를 만나다 올 봄, 그러니 무려 7개월 전에 댓글 중 일부에 대한 답으로 다음 글을 썼다. 어이없었다. 까맣게 잊고 다시 똑같은 댓글을 길게 쓸뻔했다.