6월, 2022의 게시물 표시

전 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) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함 이론적으로는 이게 맞고, 일이십개

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

이것도 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이 있음에도 요구사항이 변경됨 실패한 프로젝트 관리 방법을