[도서] 개발 함정을 탈출하라

소프트웨어 회사들이 흔히 하는 실수를 다 써 놨다.
이 업계에서 일하는 누가 읽어도 이거 우리회사 얘긴데.. 싶을거다.
(진짜 잘되는 회사 제외)

프로덕트 매니저의 업무 프레임워크

프레임워크라는 것은 베이스가 부족한 경우에도 필요하고
능숙하더라도 간혹 실수를 방지 해 주는 장치로 작용한다.

프로덕트 매니저로써 능숙하게 일을 하는 사람도
지금 프로덕트 매니저로 취업하거나
프로덕트 매니저 업무를 떠맡게 된 누구에게나 도움이 되지 않을까

인상깊은 내용

  • 프로덕트 매니저란?
    • 번뜩이는 아이디어, 최첨단 기술이 아닌 프로덕트를 통해 해결해야 하는 문제에 주목
  • 아무도 쓰지 않는 쓰레기를 만드는 것 = 개발함정
  • 성과물 vs 산출물
    • 기능의 실제 가치를 확인하지 않고 개발하는것은 산출물… 뭔가가 나왔다
    • 성과물은 핵심 목표를 달성할 수 있는 것
  • 이해관계자별 다른 목표(동상이몽) [목표]-[이유]
    • CEO 매년 30% 성장을 해야돼 – 그래야 다음라운드 투자를 받아
    • CTO 모바일 전략이 중요해 – 그래야 성과급을 받지
    • COO 비지니스 회원을 늘려야 해 – 그러면 수입이 늘어날거야
    • 그런데 이런식으로 각자 목표를 세우는게 문제라면… 이 문제의 해결책은 OKR이 아닐까

OKR과 마찬가지로 읽으면서 씁쓸하다
이건 상당히 센스의 영역이다.
읽고나서도 여기서 뭔가 느끼고 바꿀 수 있는 경영진이 얼마나 되려나

그리고 이 책이 프로덕트매니저의 시각에서 자기중심적으로 쓰여져서 그렇긴한데…
그 직무를 맡은 사람이 없어도 모든 구성원이 이렇게 사고해야한다.
우리나라 보통 IT회사에서는 개발팀장, 기획자, 디자이너, 그냥PM등 다양한 사람이 사실상 이 책에서의 프로덕트 매니저 포지션이기도 하고
프로젝트에 따라 누구나 프로덕트 매니저가 되기도 하니까

빗썸 API를 보면 형기증이 나…

어지럽다.. 아니 형기증은 어지러운게 아니지

이거보고 이상한게 안 느껴지는 사람은 API싸개에 적합하지 않으니
진로를 바꾸기 바랍니다

  • https://api.bithumb.com/public/ticker/all_btc
  • https://api.bithumb.com/public/assetsstatus/BTC

나머지는 취향차이로 둘 수 있는데
참을 수 없는게 딱 2가지 있다

네이버 클라우드 사용후기

네이버 클라우드는
중소 벤처기업에 요금지원을 1~2년씩 해주면서
사용자를 모으고 있는 것 같다

IaC

먼저… 사용하기 매우 싫었다

왜냐면 코드화가 불가능한 인프라라서
https://github.com/NaverCloudPlatform/terraform-provider-ncloud
7개월 째 업데이트가 안 되고 있다
API지원이 미약하거나 테라폼의 중요성을 모르거나 둘 중 하나겠지…
API를 이용해서 직접 코드화를 할까도 생각 해 봤지만…
AWS, GCP, Azure, DOcean, Heroku …. 선택지가 이렇게 많은데 그렇게까지???

비용

그리고 가격만 생각할 것 같으면 통큰아이 서버 쓰는게 낫지 않을까
IDC에 렉 하나 임대해서 서버 들여놓던가

AWS에서 비용 최적화 해서 사용하면 가격이 비슷할 것 같기도 하다
AWS는 BestPractice도 많고 Terraform코드화가 쉬워서

코드화가 가능하면 안쓰는 인프라를 그 때 그 때 껐다가 다시 켜고 재설정이 가능해서

설치편의성

ElasticSearch를 설치했는데
ManagerNode가 두개인데
별개로 접할수가 없어서 찾다보니
LoadBalancer를 설치해야한다고??? 18000원이라고????

가입 편의성

금융클라우드는 Console에 VPN없이 접속이 안된다. 경고는 따로 없고 타임아웃

VPN을 통해야 접속이 가능한데 동시접속이 안된다

VPN을 만들려면 SubAccount가 필요하다
2차인증이 필수라길래 구글 OTP를 등록했더니
VPN을 등록하려면 이메일 인증을 해야한다고 한다
이메일 안오는데?????
스팸인가?? 네이버 메일로만 전송을 해주나???
SubAccount를 다시 생성해볼까??
네이버 서버 병신이네!!! 라고 생각하다가 문득
아니!!
구글OTP를 등록하고 나면 이메일 인증을 할 수 없다.
설마했지만 맞았다.
병신은 서버가 아니라 소프트웨어였다
클라우드도 기획자가 있나? 기획자가 보내준거 리뷰 후에 변경안하고 바로 개발 해 버나?
개발자가 이따위로 했을리가…
이따위로 할 수는 있긴한데 그대로 놔뒀을리가…
구글OTP를 안되는거 지웠으면 지웠지…

~

쓰고 나니까 좋은 소리가 하나도 없네
잘좀 하시라구요

  • 점점 나아지겠지만 아직은 아니다
  • 네이버클라우드 직원들 고생좀 하겠다

[도서] 도메인 주도 설계로 시작하는 마이크로서비스 개발, 핵심 개념과 패턴, 설계, 구현으로 배우는 DDD와 MSA

깊은 지식을 얻는다기보다는 그냥 관련기술을 훑어보기 좋다

DDD 이론서 보고 어떻게 할지 모르겠는 사람들을 위한 책이라고 봐야하려나

기존에 좀 하고 있던 사람들에게는 별로 얻을건 없고

다른 사람도 같은 고민을 하고 있었구나 하는걸 알 수 있다

주요내용

아키텍처

  • 레이어드 아키텍처
  • 헥사고날 아키텍처
  • 클린 아키텍처

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

이벤트 스토밍

도메인 이벤트Orange발생한 사건 pp로 표현
커맨드Blue도메인 이벤트 트리거
외부시스템Pink도메인 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템
액터Yellow개인 또는 조직의 역할
애그리거트Yellow도메인 이ㄴ트와 커맨드가 처리하는 데이터
상태가 변경되는 데이터
정책Lilac이벤트 조건에 따라 진행되는 결정
when, then
읽기모델Green도메인 이벤트 엑터에게 제공되는 데이터
사용자 인터페이스White스케치 형태의 화면 레이아웃
핫스팟Purple의문, 질문, 미결정 사항

jhipster

추천도서

아키텍처

  • 마이크로 서비스 패턴
  • 클린 아키텍처
  • 엔터프라이즈 애플리케이션 아키텍처 패턴

개발 프로세스

  • 소프트웨어 장인

설계

  • UML 패턴의 적용
  • 도메인 주도 설계, 위키북스 2011
  • 도메인 주도 설계 핵심 이론, 에이콘 2017
  • 도메인 주도 설계 철저 입문, 위키북스 2020
  • Introducing Event Storming, Leanpub 2019

개발영역

  • 자바 ORM 표준 JPA 프로그래밍, 에이콘 2015

데이터 아키텍처 전문가가 되는 방법 – 최수진

DA(데이터 아키텍처) 컨설턴트에 관한 얇은 책

2021년 이후에는 조금 맞지 않을
그리고 DA편향적인 생각이 많이 적혀있다.
개발자 다음단계를 준비한다던가…

DBA,DevOps,DA,Frontend,Backend…는 직군이 되서는 안되고 직책이 되야한다.
SoftwareEngineer는 보통 이 교집합을 수행한다.
DA만 하는 IT컨설턴트가 존재 하지 않는게 최선이다.

컨설턴트의 강점은 실력이 아니다.
권한이다.
검찰이 경찰보다 뛰어난건 지능이나 개개인의 능력이 아니라
지역의 이해관계에 얽히지 않은 벽을 뛰어넘는 권한이다.
컨설턴트도 마찬가지
대기업의 특정 부서나 직급에 상관없이
궁금한 것을 물어보고 잘못된 것을 지적할 수 있는 권한이다
제 3자이고 곧 떠날 사람이기 때문에 가능한 부분이다.

LG에서 휴대폰 사업이 잘못나가고 있는것을 누가 지적할 수 있었을까
구성원 하나하나다 다 개붕신이라 문제점을 인식하지 못하고 있었을리는 없다
좆지 직원들도 갤럭시,아이폰을 좋아하니까

  • DA
  • DBA
  • BA
  • AA
  • TA
  • ISP : Information Strategy Planning

고객의 업무에 맞는 데이터 모델
vs
개발하기 쉬운 데이터 모델

보통은 개발하기 어려운 데이터 모델은 잘못된 설계의 결과물이다
기존에 잘못된 업무를 그대로 따라서 모델링을 하면 이런 결과가 나온다
1 보통은 업무 자체가 변경되어야 하는 경우
2 상태값 설계가 제대로 안 된 경우

프로젝트 시작전에 처리되서 문서화되어야 할 것들

  • 일정
  • 설계
  • 용어정의

보통 이런것들은 무시되고 바로 프로젝트가 시작된다
프로젝트 진행과정에서 지속적으로 오버헤드를 발생시키는 문제들

개발자: SI-SM
DA: 모델링-튜닝

맨먼스 미신The Mythical Man-Month, 프레더릭 브룩스

내용

  • Prototype – 두 번째 시스템
    : 첫번째 시스템은 프로토타입이다
  • 1:10 업무효율
    : 같은 조직내에서 비슷한 급여를 받는 살마들 사이에도 업무능력 차이는 10배
  • 일정 늘어짐
    : 일정은 항상 늘어진다. 일정을 너무 루즈하게 잡은게 아니라면. 돌발상황에 대비해 조금 타이트하게 업무처리
  • 문서화
    : 워크북. 요즘은 위키를 주로 사용
  • 급하다고 많은 인원 투입
    : 의사소통 비용 증가
  • 소수정예
    : 큰 프로젝트 불가
  • 핵심개발인력과 보조인력 구조
    : 아키텍트와 모듈분할
  • 구체적인 마일스톤의 정의
  • 프로젝트 관리자는 의사 결정이 아닌 의사 소통

대상

오히려 개발자보다
한국에서의 특이직군인 기획자, PM
그리고 스타트업 대표, PO, 원청업체담당자가 봐야 할 책

읽고나서

소프트웨어 공학을 모를 때도
개발 업무를 하면서 맞딱뜨리게 되는 불편한 점들과 개선점을 생각했었는데
내가 찾아낸 최선의 방법의 핵심은 빠른 프로토타이핑과 작은 개선의 반복이었다.

이 책에서는 이것을 포함해서 그리고 더 다양한 상황에서의 대응법이 잘 정리가 되어 있다. 현업을 겪어보지 못했다면 그렇구나.. 하면서 감흥없이 넘어갔을 것 같다. 어차피 한번 겪어보고 다시 읽어야 됐었겠지
소프트웨어 개발 싸이클틀 겪어 본 사람이라면 이 책을 읽으면서 자기가 겪었던 문제점이 그대로 다 써 있다는데 놀라지 않을까

1975년 초판이라는데
아직도 그대로라니

카프카 기술서 두권 비교

아파치 카프카로 데이터 스트리밍 애플리케이션 제작 – 에이콘

카프카에 대해서 개괄적으로 나와 있기는 한데 정리가 깔끔하지는 않다

훑어보기는 괜찮다

그런데… 이 책이 더 좋은 것 같다

~~~

기술만 훑어보려고 하는거면 1~2단원만 보면 될 것 같고 자세히 보려면 좀 오래걸릴 것 같다.
코드랑 기술이 상세하게 설명 돼 있어서 더 그런것같은데..

메시지 전송 기술에서 카프카가 거의 표준으로 자리잡아서 다른걸 생각하기가 힘들 정도다
복잡한 라우팅을 하는 경우에 AMQP를 쓴다고는 하지만… AMQP에서 지원되는 케이스를 생각 해 봐도 카프카에서도 다 할 수가 있을 것 같다

예전에 금융사 SMS처리하는 프로젝트에서 사람들 mysql가지고 개삽푸는거 본 적이 있는데
내가 들어갔으면 메시지 서비스로 하지 않았을까 싶은데…
그 때는 rabbitmq를 선택하지 않았을까?? 카프카의 특성을 제대로 모르고 있어서..
당시에는 문서도 잘 안나와있어서 좀 골치아프기도 했다.
요새는 번역서도 나와있어서 사용하기 좋은 것 같다

끝으로 최근.. 아파치에서 카프카의 경쟁 시스템이 출현했다는 슬픈소식

Apache Pulsar

(예제로 배우는 프로그래밍) 루아

이 책을 다 봤지만 메인함수 작성하는 방법을 아직 모른다.

인터넷의 1시간만에 루아 마스터하기~ 문서같은 느낌이었다

그래도 루아 언어 자체가 간단하기 때문에 그정도면 충분할 것 같다.

메인함수 작성법이나 system.in 하는방법은 따로 찾아보면 되니까

nginx에서 사용할 수 있다고 해서 보게 됐는데 생각보다 간단해서 쉽게 접근해볼 수 있을 것 같다.

[도서] Chef Solo 입문 : 인프라스트럭처 자동화 프레임워크 – 뒤늦은 완독

기술서도 완독이라는 표현을 쓰나? 잘 안쓰는 것 같기도 하고..

클라우드가 나와서 일반 개발자가 직접 인프라를 운영해서 kubernetes, hadoop 등등 클러스터를 대규모로 운영할 일은 잘 없다보니.. 인기가 많이 식었지만

개발피씨, 개발서버, local vagrant 등을 설정할 때는 여전히 유용할 것 같다.

좀 사양기술이기도 하고 책도 옛날거라 예제도 다 오류나서 해서 안보려고 했는데, vagrant 개발환경 구성하다가 왠지 chef를 적용 해 보고 싶어서 다시 보기 시작했다.
보통은 docker를 쓰는데 이번엔 몇개 프로젝트 함께 돌리는거라 프로젝트별로 설정 해 놓은 docker를 쓰기는 좀 껄끄러운 상황…
아닌가? 그냥 vagrant를 쓰고 싶었다.

옛날버전이라 책으로는 개념만 익히고 웹튜토리얼이랑 도큐먼트쪽 명령어 찾아 보면서 공부할 수 밖에 없었는데 그러다 보니 시간이 많이 걸렸다.(이틀정도..)

chef 공부하기 힘든 이유가 몇 가지 있다

  • 개념이 뒤죽박죽… chef-solo chef-client –local-mode 비슷한게 섞여있고
  • 용어는 지맘대로.. 들어도 뭔지 모름 chef, kitchen, knife
  • 버전업하면서 legacy 다 바뀜

이런 난관을 넘고 vagrant 정도는 chef로 설정할 수 있게 되어 버렸다.ㅎ

이제 안쓸수가 없군.

추가로

Chef, 클라우드 서비스 설정관리 자동화 도구.

라는 책도 있는데 이건 되는게 더없고 개념이해도 더 힘들다.
두꺼운 책이 오류나니까 더 답도없다.
(책이 처음 쓰여질때는 오류가 아니었겠지 deprecated책이라)

절대 사서 보지 말기 바람.