간만의 휴식에 한일들

 3월 1일부터 새로운 회사에 입사하게 되어서 2월은 약 한달 정도 쉬게 되었다. 쉬기 전 까지는 이것도 하고 저것도 하고 계획도 많았지만 막상 쉬게 되면 이런 저런 제약 때문에 생각대로 되지 않는다. 특히 꼬맹이 학교에서 돌아오는 시간이 있으니 그에 맞춰 집에 있으려면 할 수 있는 것도 그렇게 많지 않은 것 같다. 그나마 한 것 들이라고는 영화본 것 밖에 없는 듯. 슬램덩크, 아바타2, 앤트맨&와스프 퀀텀 매니아. 요렇게 3개의 영화를 보고 왔다. 슬램덩크 추억의 만화책을 애니화 한 만화 영화. 뭐 나쁘지 않은 영화 였다. 전체적으로는 약간 루즈한 느낌이 들지만 마지막 클라이막스 부분에서는 음악과 함께 좋은 연출을 본 듯 한 느낌이다. 두번 본 사람도 있다고 하는데 그 정도 까지는 아닌 듯. 아바타2 볼까 말까 고민한 영화. 이미 뒷편 들까지 어느정도 촬영이 끝났다는 이야기를 듣고 보기로 결정. 처음으로 4dx 영화관에서 보았는데 의자의 흔들림 등 그 외 효과들이 그렇게 효과가 있다고는 생각을 못하겠다. 가~끔씩 타이밍이 딱 맞을 때도 있지만 오히려 신경이 쓰여서 영화에 집중 못하는 경우도 꽤 있었던 듯 하다.  화면에 집중하고 싶어서 더빙판으로 관람 했는데 더빙 판은 4dx밖에 없드라.. 내용도 괜찮고 그래픽도 괜찮고 눈도 즐거웠다. 다음 편이 나오면 또 보러 가고 싶다. 앤트맨&와스프 퀀텀 매니아 인터넷의 평가는 좋은편이 아닌 듯 하다. 이것도 4dx로 관람 하고 왔는데 나쁘지는 않은 듯 하다. 딱 거기까지. 양자 세계에 또하나의 우주가 존재한다는 가설은 이전부터 있었던 이야기. 결국 우리가 살고 있는 지구도 누군가의 양자 세계 일 수도 있다는 것.  하지만 양자 세계의 묘사가 뭐랄까 스타워즈 짝퉁이라는 느낌이 강하게 든다. 스타워즈를 본 적 없는 사람에게는 신선한 충격으로 다가 올지도 모르겠다. 영화를 볼때는 개연성같은걸 신경 쓰면 지는 거다. 그냥 무지성으로 생각하지 말고 시간 때우기로만 본다면 나쁘진 않은 듯 하지만 하나씩 따지기 시작

aws ec2 접속시 개인유저를 할당

 aws 는 기본적으로 amazon linux 가 시작될떄 ec2-user 가 설정되고, 지정한 keypair 의 public key를 cloud-init가 ec2-user의 .ssh 디렉토리에 배치한다. 이로서 ec2-user 의 private key를 가지고 있는 모든 유저가 ec2-user로서 ssh 접속이 가능해진다. 하지만 ISMS나 PCI DSS등 여러 시큐리티 규약에서 공용계정을 배제해야 한다는 요구사항이 들어 있다. 여러 솔루션을 조사 했지만 비용이 많이 들어가거나 유지보수가 어려운 등 적절한 게 없어서 고민하다가 aws-ec2-ssh 라는 패키지를 이용해서 스크립트를 조금 수정하는 것으로 어느정도 원하는 유저관리 시스템을 구축 할 수 있게 되었기 때문에 여기에 메모형식으로 남긴다. aws-ec2-ssh https://github.com/widdix/aws-ec2-ssh IAM user를 추가하여 그룹을 지정 IAM user는 code commit 용 public key를 upload sshd_config를 수정하여 지정한 유저의 public key로 인증 import_user.sh 를 실행하면 지정한 IAM group의 유저리스트를 이용하여 user를 추가 특별한 문제 없이 잘 작동하는 것 까지 확인은 했지만 문제는 한 유저에 지정가능한 그룹수에 제한이 있기 때문에 한 유저에 대해 지정가능한 어카운트 지정이 한계가 있다는 거다. 확인해 본 결과 iam user를 등록할 수 있는 group수는 변경할 수 없는 항목이니 이걸로는 좀 부족하다 느꼈다. import_user.sh 를 뜯어 보니 아래와 같이 그냥 group의 유저리스트를 확인 하는 것 뿐이다. for group in $(echo ${IAM_AUTHORIZED_GROUPS} | tr "," " "); do   aws iam get-group \   --group-name "${group}" \   --query &q

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것" (twitter.com/jasoncwarner)

 geeknews에서 가져온 내용. 원본 링크는 아래에 기재. https://news.hada.io/topic?id=7839 지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것 "Monolith > apps > services > microservices" 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음 둘째, 단계가 중요함 5-50인 회사라면 그냥 Monolith로 가세요 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면.. 먼저 정의(Definition) 부터 monolith - xyz.com apps - abc.xyz.com services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리) microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함 Why ? : 기본적으로 "Speed & Risk" 때문 #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움 #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움 #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함 #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함 이론적으로는 이게 맞고, 일이십개

일런 머스크의 '미친 생산성을 위한 6가지 법칙' (twitter.com/LiamKircher)

 이 또한 geeknews에 올라온 내용이다. 원문 링크는 아래에 기재하고 개인용도로 관련내용을 이곳에 옮겨적는다. https://news.hada.io/topic?id=7860&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4 #1 대규모 미팅은 피하라 참여자가 많은 미팅은 시간과 에너지의 낭비 토론을 방해 사람들을 방어적으로 만듦 모든 사람이 기여하기엔 시간이 부족 모든 사람에게 가치를 주는게 아니라면 대규모 미팅을 잡지 말 것 #2 미팅에 기여하는게 없다면 중간에라도 나가라 미팅이 당신의 "자료나 정보(Input), 가치, 의사결정"을 필요로 하지 않는다면 미팅에 참여할 이유가 없음 미팅 중간에 나가는 것은 무례한게 아님. 사람들의 시간을 낭비하는게 무례한 짓 #3 명령 체계(Chain of Command)는 잊어라 동료들과 직접 대화할 것 슈퍼바이저나 매니저를 통하지 말 것 빠른 소통이 빠른 의사 결정을 만듦 빠른 의사결정은 곧 경쟁 우위임 #4 똑똑해 보이려 하지말고, 명확히 할 것 기술 용어(Technical Jargon)와 이상한 단어(넌센스)는 피할 것 이런 것들은 의사소통을 느리게함 간결하고(Concise), 요점을 설명하는(To the Point), 이해하기 쉬운 단어를 선택할 것 똑똑해보이려 하지 말고, 효율적으로 일할 것 #5 미팅을 자주하지 말 것 모든 사람의 시간을 낭비하는 데 이것보다 좋은게 없음 미팅은 '협업하고, 직면한 문제를 돌파하고, 긴급한 문제를 해결할 때" 사용할 것 이슈가 해결되었다면, 자주 미팅하는 것은 더 이상 필요없음 대부분의 이슈는 미팅없이도 해결가능. 미팅 대신 '문자나 이메일을 보내거나, 슬랙/디스코드 채널에서 얘기할 것' 필요한게 아니라면 팀의 워크플로우를 방해하지 말 것 #6 상식적으로 해라 만약 회사 규칙이: 말이 안 되거나 일을 진행하는데 도움이 안되거나 당신의 특정 상황에 맞지 않는 다

엔지니어들이 면접에서 물어야 할 질문들

이것도 geeknews에 올라온 글. 내가 보기엔 알짜정보가 많다... https://news.hada.io/topic?id=6862&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4 https://posthog.com/blog/what-to-ask-in-interviews "이 질문들은 매우 직설적이긴 하지만, 이에 대해 좋지 않은 반응을 보이는 회사는 좋은 직장이 아닐 수 있습니다" 이 회사는 Product-Market-Fit 한가요? PMF한지 자신에게 질문한 적이 있나요? PMF를 언제 달성했나요? 어떻게 아나요? PMF를 달성하기 위해 뭘 해야 하나요? 매출은 얼마인가요? 1년전에는 얼마였나요? 일 활성사용자(DAU)는 얼마인가요? 피해야 할 회사들 : Pre-PMF를 설명하는데 시간을 많이 쓰지 않는 창업자들 제품이나 그들이 주는 혜택이 뭔지 이해하기 어려운 회사들 문제를 찾는 해결책들 Runway가 얼마나 남아있나요? 지출이 합리적인 것처럼 보이나요? Default Alive 한가요?→ 지금은 수익성이 없지만, 자금이 바닥나기 전에 수익을 낼 수 있을만큼 빠르게 성장 가능한가 Runway는 얼마인가요? 이걸 계산하기 위한 가정은 뭔가요? 펀드레이징 계획은 어떻게 되나요? 피해야 할 회사들 : Default Alive 한지 모르거나, 신경쓰지 않는 회사 시간이 모자르거나 느려서, Default Alive 해질 것 같지 않은 회사 생존을 위해서 단시간내에 매출의 급격한 증가를 가정하는 회사 곧 자금이 바닥나기 때문에 펀드레이징을 하고 있지만, 라운드 클로징을 하지 않은 회사 문화는 어떤가요? 회사의 가치는 뭐고, 왜 그것인가요? 그 가치를 따르는 구체적인 방법들을 알려주실수 있나요? 뭘 만들지 누가 결정하나요 ? 일반적인 하루(근무일)는 어떤 모습인가요? 어떤 미래를 기대하나요 ? 어떤 것이 당신에게 동기를 부여하나요? 지금까지 가장 자랑스러운 것은 뭔가요? 회

큰 기술 회사들은 어떻게 프로젝트를 진행할까

 아래 GeekNews에서 본 글 https://news.hada.io/topic?id=6747&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4 https://blog.pragmaticengineer.com/project-management-at-big-tech/ 요즘 들어 조직개편에 대해 많이 고민하면서 많은 도움이 되었다. 모든 것에 대해 이대로 따라할 필요는 없지만 다음 조직 구성이나 운영방식에 참고가 되었다. 100개 이상의 빅 테크 회사들을 설문 조사한 결과 빅 테크의 프로젝트 관리 방식을 정리하면 ⇨ "상황에 따라 다름(It Depends)" 당연한 이야기를... 대부분 정해진 방법론이나 업무 방식은 없고, 팀이 자신에 맞는 것을 선택 상장회사나 투자받은 회사들은 전담 PM이 있는 것에 대해서 만족도가 낮았지만, 투자 받지 않은 경우는 만족도가 높았음 팀의 자율성과 만족도는 상관관계가 높음 자율성과 만족도에 비례해서 결과를 제대로 뽑아주면 전혀 문제 될게 없을 듯 문제가 있는 팀들도 방법론의 문제라기 보다는, 비전을 제대로 보여주지 못하거나, 투명성이나 도구의 부족등이 안 좋게 되는 이유 였음 동감되는 부분들이다. 경영진에서 뚜렷한 비전과 그에 의한 목표, 구체적인 전략등을 보여주지 못하니 팀원들의 분위기는 「한다고 하는데 왜 하는지는 모르겠고, 일단 월급 나오니까 하고는 있는데..」 라는 딱 이정도의 수준밖에 되지 않는 것 같다. JIRA는 대부분 부정적인 응답이었음 jira, asana, monday.com 등 수많은 티켓관리 툴들이 있는데, 40개가 넘는 툴들은 분석한 결과 대부분 비슷비슷 하다는 것이고, 결국 유저들의 숙련도가 중요하다는 것을 크게 느꼈다. 잘 되지 않았던 프로젝트 관리 방법들 엔지니어들이 프로젝트 기간 산정에 참여하지 않음 전담 PM이 있음에도 요구사항이 변경됨 실패한 프로젝트 관리 방법을

맥북 카라비너 영어/한글/일본어 전환하기

이미지
 현재 Intel 맥북과 M1 맥북에서 4종류의 키보드를 사용중이다. HHK RealForce MD770 Keychron K12 마음 가는대로 키보드를 바꿔가며 사용중인데 매번 설정을 바꾸는게 고역이다. 특히 한글/영어/일본어 간의 변환은 스무즈하게 바꿀 수 없다면 타이핑 하는데 꽤나 고역이다. 그래서 카라비너를 이용한 변환키 설정을 기록한다. 기본 컨셉은 일본어 배열 키보드와 영어 배열 키보드에서 간단하게 각 언어 변환이 가능할 것. 일본어 키보드의 경우는 스페이스바 왼쪽의 키를 한번 누르면 영어, 스페이스바 오른쪽의 키를 누르면 일본어, 연속으로 두번 누르면 한글로 바뀌는 설정이고, 영어 배열 키보드에서는 왼쪽쉬프트+스페이스바가 영어, 오른쪽쉬프트+스페이스가 일본어, 오른쪽 커맨드키를 두번 누르면 한글이 되는 설정이다. Keychron K12(영어배열) + Macbook M1 카라비너 설정 / Simple Modificiations   카라비너 설정 / Complex modifications { "title" : "한글전환 커스텀 For M1 " , "rules" : [ { "description" : "영어 키보드 - 좌측Shift+스페이스:영어, 우측Shift+스페이스:히라가나, 우측 커맨드키 더블클릭:한글" , "manipulators" : [ { "type" : "basic" , "from" : { "key_code" : "spacebar" , "modifiers" : { "mandatory" : [