SRE는 구글에서 비롯되었다. 대규모 서비스를 하는 회사 특성상 안정성이 매우 중요한데, 이 부분을 체계적으로 발전시키면서 나온 부산물이 이제는 업계의 표준 용어같이 쓰이는 상황이다. IT 인프라가 국가의 중요한 부분이 되면서(최근 러시아의 우크라이나 침략을 보면 정말 극명하게 드러난다) 서비스 안정성과 관련된 법안도 생길 정도이니 말이 필요없다. Microservice 역시 말이 필요없는 표준 용어나 마찬가지이다. 많은 개발자들이 MSA 하고 싶다고 이야기하지만, 사실 규모 면에서 필요한지도 생각해야 하고, 그냥 여러 개의 서비스로 나누면 microservice라고 착각/오해하는 사람들도 있어서 monolithic으로 하면 괜찮았을 걸 굳이 나눠서 문제가 생기는 경우도 있다. 당연히 “R”eliabil..

https://nymets.medium.com/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%A7%88%EC%8A%A4%ED%84%B0-71565c2b6bfc 맘에 안 드는 건 책 제목(원서)과 표지에 사무라이가 들어간다는 점. 일본 문화가 얼마나 영향력이 있는지 보여주는 일례인 듯 내가 생각하는 방향이 틀리지 않았음을 알게 되었다. 다만 당연히 세부사항에 대해서는 나도 더 발전해야 한다. 오래된 책이지만 역시 좋은 책은 시간과 무관하게 가치가 있다. 애자일에 대한 책이 앞으로 얼마나 가치가 있을지 모르겠으나(당연히 고전과 같은 가치가 있진 않겠지만) 그래도 상당히 오래 가지 않을까? 하는 생각이 들었다. 언젠가는 누구나 다 이런 방식으로 일하는 것을 좋아하게 될 거라고 생각하느냐고? 천만의 ..

프로그래머의 리더십 "직접 나서서 일일이 코딩하지 말고, 팀원을 시키란 말이야!" 10년이 지나 프로그램이 무엇인지 알 때쯤 되니 회사에서 또 다른 임무를 준다. 더 이상 혼자서 키보드와 모니터에 빠져있지 말고, 뒤따라오는 후배들을…www.hanbit.co.kr 조금 시간이 지난 책(2015년 출간)이라 시대와 맞지 않는 이야기도 있고(회식을 커뮤니케이션의 장으로 활용하자, 1:1 술자리 활용을 권하는 등) management에 대해 좀 주제가 흩어져 있고 약간 전문적인 활용은 부족해 보이긴 하지만 전반적으로 여러가지 주제를 모아 읽기 쉽게 특히 프로그래머의 입장에서 이해하기 쉽게 좀 더 직접적으로 썼다는 장점이 있음

쿠브플로를 쓰기위해선 쿠버네티스를 알아야하고, 그러기 위해서는 왜 쿠버네티스가 인기를 얻는지 약간 배경지식이 필요하다. 이 책을 선택하는 사람이라면 대부분 알고 있겠지만 간단히 정리해보면, 2010년대 vision 기술의 발전을 필두로, ML/DL의 부흥기가 찾아왔고, 이번에야말로 실용적으로 쓰일 수 있겠다는 기대감과 함께(특히 알파고 같은 이벤트가 합쳐지면서) 분야에 관계없이 많은 기업들이 이 시장에 참여했고, 관련 기술을 가진 사람들은 황금기를 맞았다. 그러나 기대와는 달리 AI 프로젝트는 시장에서 성공을 하는 경우는 드물었고 — AI는 아직 좌충우돌 단계…90%가 POC에서 끝나 — hype cycle의 3단계(환멸)에 진입하거나 AI의 겨울이 다시 온다는 성급한 이야기까지 나왔다. 대부분의 프로젝..

크게 봐서는 좋지만, 뭔가 좀 애매한 부분이 있다. ‘프로그래밍 심리학’을 기반으로 우리나라에 없다시피 한 프로그래밍 + 심리 분야를 개척하다시피 하는 (걸로 보이는) 분이 쓴 책이다. 심리학을 통해 (직급 무관하게) 종사자들의 심리적인 문제 해결을 위해 여러가지 도구들을 통해 해결할 수 있는 방법들을 제시하는 부분들이 좋다. 요즘은 누구나 아는 MBTI를 바탕으로 유명한 리더들이 어떤 스타일인지 이야기하며 어떤 업무에는 맞고 또 다른 경우는 좀 부족할지를 논하는 등 심리적인 부분과 업무의 방향을 정하는 데 있어 도움을 얻거나, 최소한 재미있게 읽을 만한 내용이 포함되어 있다. pair programming 등의 실질적인 기법에 대해서도, 어느 정도 설명이 있기 때문에 이런 부분에 관심을 갖는 경우 도움..

개인적으로 시간을 낼 수도 없고, 회사도 기회를 제공하지 않은 상태로 시간만 보내게 되는 겁니다. (지금 이 문제로 내가 싸우고 있어서 정말 와닿는다) 소프트웨어 개발 프로젝트의 복잡도는 크게 두 가지 변수의 영향을 받습니다. 그것은 바로 ‘사용자 요구사항’과 ‘개발기술’인데요. 먼저 ‘사용자 요구사항’ 의 경우를 보죠. 폭포수개발방식은 프로젝트 초기에 요구사항을 고정시킵니다. 사용자와 철저한 인터뷰를 하고 문서를 만들며, 여기에 확인 서명을 받기도 하죠. 이에 반해, 애자일 방식은 요구사항의 변화를 그대로 수용합니다. 다만 반복적인 프로세스를 돌려서, 각 프로세스(이터레이션 또는 스프린트) 안에서는 요구사항이 변하지 않도록 보호하는 조치를 합니다. 그럼 기술의 변화는 어떻게 수용할까요? 프로젝트 초반에..

기술적 요구를 기반으로 경계를 그리는 것은 안티 패턴이다. 제임스 루이스와 마틴 파울러에 따르면 마이크로서비스는 기술적 요구가 아닌 ‘비즈니스 기능을 중심으로 구성’되어야 한다. 마찬가지로 데이비드 파나스 Davial Pumus는 시간에 따른 설계 변경의 모듈식 캡슐화를 기반으로 시스템을 분해할 것을 권장한다. 두 접근 방식 모두 서버리스 함수의 경계와는 일치하지 않는다. 서비스 경계를 정할 때 다음과 같은 설계를 위해 노력해야 한다고 제안했다. 느슨한 결합: 서비스는 서로를 인식하지 않고 독립적이어야 하며, 한 서비스에서 코드를 수정하더라도 다른 서비스에 영향을 주지 않아야 한다. 높은 응집력: 서비스에 있는 기능은 관련성이 높아야 하며 관련 없는 기능은 다른 곳에 캡슐화되어야 한다. 이렇게 하면 기능..

가입 어플리케이션 등록: https://developers.kakao.com/docs/latest/ko/getting-started/app 어플리케이션을 등록하면 위와 같이 key들을 볼 수 있음 3. guide 따라하기: https://developers.kakao.com/docs/latest/ko/vision/dev-guide#ocr curl KakaoAK뒤에 위의 “REST API 키”를 추가 postman 역시 위와 똑같은 값들을 추가하고 Send button을 누르면 결과를 볼 수 있음

프로그래밍과 직접 연관된 부분은 거의 없지만, 여러가지 시사점을 제공하며, 좀 더 나은 프로그래밍을 하는 데 많은 도움을 줄 수 있는 주제들을 다룬다. 프로그래밍, 소프트웨어 공학이 발전하면서 세부적인 주제들, 일견 관련이 없어 보이는 부분들을 다루는 쪽으로도 나아가는데, 이 책 역시 그런 종류의 책이다. 예를 들어, 코드를 작성하는 것만큼, 어쩌면 그보다 더 코드를 읽는 게 중요하다는 사실은 최소한 경력이 있는 개발자들에겐 잘 알려진 사실이다. 하지만 이런 작업이 뇌와 어떻게 연결되고, 어떻게 동작하는지에 대해 쓴 책이 아마 이 책이 최초가 아닐까? 개인적으로는 비개발자들에게 개발자의 작업을 이해시키는데 유용하게 쓸만한 근거 자료들을 찾을 수 있어서 당장 직접적인 도움도 되었고, 프로그래밍을 이해하고 ..

정리를 잘해서 prolog만 읽어도 이 책의 주제를 바로 이해할 수 있다. 30년의 커리어 패스를 쌓기 위해 단계별로 나아가기 위한 정보를 알려주는 게 이 책의 목적이다. 대부분의 junior 개발자들은 평생 개발을 하는 걸 원하는 경우가 많고, 또 좋은 code를 작성하는 게 개발의 대부분이라고 생각하는 경우가 많다(최소한 예전에는 그랬다). 하지만 실제 업무를 하다 보면 우리가 흔히 soft skill이라 부르는 여러 가지 code 이외의 능력도 업무에 큰 영향을 주며(대표적인 게 communication), 또 사람의 앞 일은 알 수 없기에 자의건 타의건 lead를 하고 management를 할 수도 있다. 저자는 크게 엔지니어링, 매니지먼트, 비즈니스 역량이라는 3가지 대주제로 9가지 기술을 익혀..