[TechNews] 유용한 개발 관련 아티클 및 영상 #24

 

 

1. 유용한 개발 관련 아티클 및 영상 #24

---

HTTP Query Method의 필요성에 대한 논의

• HTTP는 본래 웹 페이지 렌더링을 위한 리소스를 가져오기 위해 만들어졌음
• GET, HEAD, POST는 HTTP/1.0, PUT, DELETE는 HTTP/1.1부터 사용되고 있음
• 하지만 데이터 중심의 세상이 도래함에 따라 데이터 질의를 위한 새로운 HTTP Method(Query)가 필요해짐
• 참고로 해당 내용은 2022년에 발행된 것으로, 현재 공식 스펙 지정까지 되지는 않은 것 같음

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10

 

출처: https://horovits.medium.com/http-s-new-method-for-data-apis-http-query-1ff71e6f73f3

 

 

 

최근 주기적인 1on1에 대한 회의적인 시각들

• Jensen Huang (Nvidia CEO)
  • "저는 직원들과 1on1을 하지 않습니다. 제가 말하는 모든 것은 모든 사람에게 동시에 말해요. 제가 다루는 정보 중에 한두 사람만 들어야 할 정보는 없다고 믿기 때문입니다.
  • 개인의 피드백 역시 모두 앞에서 말합니다. 이는 사소한 일이 아닙니다. 우선, 피드백은 학습입니다. 왜 1on1 상대만 이걸 배워야 하나요? 개인의 실수로부터 얻는 경험은 모두가 배울 수 있는 좋은 기회입니다.
  • Nvidia에서 1on1을 하지 말라고 하는 건 아니지만, 저는 하지 않는 문화를 지향합니다."
• Aditya Agarwal (전 Dropbox CTO)
  • "저는 이제 정기적인 1on1 미팅이 오히려 해가 된다고 확신합니다. 정기적인 1on1은 사람들의 행복을 과하게 점검하고 평범한 일상을 끊임없이 비판하게 만듭니다. 결국 1on1은 '트집 잡는 세션'으로 전락하고 맙니다.
  • 저는 직원들이 회복탄력성을 갖추길 바랍니다. 매주, 매달이 항상 행복하고 즐겁지 않을 수 있다는 것을 이해하고 이를 받아들이며 성장하길 기대합니다. 하지만 주간 1:1 미팅은 이러한 회복탄력성의 발달을 저해합니다.
  • 피드백이 쓸모없다는 뜻은 아닙니다. 하지만 피드백은 주간이 아닌 3-6개월마다 주어지는 것이 더 효과적이라고 봅니다. 이러한 주기에서는 관리자가 패턴을 파악하고 전체적인 조언을 제공할 수 있으며, 매주 미세한 점검을 하는 것보다 더 알맞은 지침을 줄 수 있습니다.
  • 저는 매주 진행하는 1on1 미팅의 의도는 좋지만 역효과를 낳고 있다고 믿습니다. 이제 이 잘못된 실리콘밸리 관리 '모범 사례'에서 벗어날 때가 아닐까요?"
• Claire Vo (LaunchDarkly CPO)
  • 얼마 전 저는 80%의 정기적 1on1을 취소했습니다. 제 스케줄은 하루 종일 미팅으로 가득 차 완전히 감당할 수 없는 상황이었습니다. 1on1 취소는 임시로만 하려고 했지만, 결국 정기적 1on1 일정을 다시 등록하지 않았습니다. 대신 필요할 때마다 1on1 일정을 잡기 시작했습니다.
  • 덕분에 글쓰기, 피드백, 조직 관련 업무 등 실무를 할 시간이 몇 시간씩 더 생겼습니다. 1:1 미팅을 통해 간접적으로 진행하려던 일들을 직접 깊이 있게 다룰 시간이 생겼습니다.
  • 또한 1on1을 대신해 매일 누구나 참여할 수 있는 'hang' 미팅을 개설했습니다. 한자리에 모여 이런 업무 이야기를 나눕니다. 조직 내 다른 리더들도 자체적으로 'hang'을 주최하기 시작했습니다. 유일한 규칙은 회의가 끝날 때 논의된 내용(업무 및 사회적 내용)을 요약해서 게시하는 것입니다.

 

출처: https://x.com/dylayed/status/1799462406718177371?t=YL3djx1zoYVoL6JpJhVjBA&s=31

 

 

 

PID 0에 대하여

• PID 0의 역할에 대한 개요
  • 스케줄링과 전원 관리에 관여하며, 페이징과는 관련이 없음.
  • CPU 코어가 할 일이 없을 때 실행되는 스케줄러 역할을 함.
  • 초기 Unix에서는 PID 0이 메모리 관리와 관련된 작업을 했으나, 현대 Unix에서는 그렇지 않음
• PID의 실제 역할
  • PID 0은 커널을 시작하고, 이후에는 CPU 코어를 관리하는 역할을 함.
  • Linux 커널에서 PID 0은 do_idle 함수로 구현되어 있음
• 커널과 사용자 공간에서 PID의 차이
  • 참고로 Linux 커널과 사용자 공간에서 PID의 의미가 다름
  • 커널에서는 PID가 쓰레드 ID를 의미하고 사용자 공간에서는 PID가 프로세스를 나타내며, 이는 스레드 그룹 ID와 동일함
  • 다중 코어 시스템에서는 각 CPU 코어마다 하나의 idle 스레드가 있으며, 이들은 모두 스레드 그룹 0에 속함. 그리고 사용자 공간에서는 이를 PID 0으로 인식함.

 

출처: https://news.hada.io/topic?id=15239&utm_source=slack&utm_medium=bot&utm_campaign=T03FE7QJV

 

 

 

마이크로소프트 Edge와 멀어지는 React

• MS Edge 팀에서 최근에 공개한 Edge 개선 방법에서 React를 사용하지 않겠다고 발표했음
• Edge는 Google의 오픈 소스 웹 브라우저인 Chromium을 기반으로 구축되었는데, Edge는 MS에서 자체 디자인한 UI 구성 요를 넣기를 원했고, 이들은 React를 사용하여 만들어졌음
• 전체 Edge 브라우저는 React 애플리케이션이 아니고, HTML 페이지를 사용하는 여러 컴포넌트를 React와 결합하였음. 대표적으로 메뉴, 드롭다운, 즐겨찾기 탭은 미니 React 앱임
• 하지만 이러한 비효율로 인해 MS는 React에 대해 의심하기 시작했고, 2024-05-27 이를 개선하여 발표함
  • UI 코드에 모듈화 문제가 있었는데, 서로 다른 컴포넌트를 작업하는 팀들이 공통 번들, 파일을 공유함에 따라 UI의 한 부분이 필요하지 않은 것들을 공유하여 속도가 느려졌음
  • 클라이언트 측 렌더링 기술을 사용하여 UI를 내려주는 자바스크립트 기반 프레임워크를 사용하는데, 이것에 의해 브라우저 속도가 느려졌음
• React 자체의 문제보다는 브라우저의 관점에서 적합하지 않았고, 새로운 프레임워크를 만들어 사용했음

 

출처: https://javascript.plainenglish.io/microsoft-is-ditching-react-f8b952b92b9b

 

 

 

구글에서 약 4000만원을 받았다는 이력서

• 반복하지 말라
  • Java 개발에 대한 글머리 기호가 있다면, 그 글머리 기호를 4개 더 쓰지 말라
  • 대신 자신에 대한 다른 중요한 세부 사항을 위해 사용하라
• 사람에 대해 이야기하라
  • PM 및 UX 디자이너와 함께 일한 경험이 오퍼를 넣게 만들 수 있다
  • 따라서 여러 부서의 팀원들과 함께 일한 경험을 언급하라
• 임팩트에 대해 이야기하라
  • 자신의 업무 임팩트를 명확하게 설명할 수 있다면, 자신이 하는 모든 일이 고객을 위한 것이라는 큰 그림에 대한 시야를 증명할 수 있다
• 깔끔한 서식으로 포매팅하라
  • 보기 어려운 이력서라면 누구든 그냥 다음 이력서로 넘어갈 것이고, 아무리 많은 경력도 소용이 없음
  • 독자가 읽기 쉽게 만들고 여백이 여유 있는 한 줄 글머리 기호를 사용하라
• 경험 > 완료
  • 이력서에 미완성 프로젝트나 작업을 넣어도 100% 괜찮음
  • 완료 여부보다는 지원자가 해당 자료를 알고 있는지가 더 중요함
• 알아볼 수 있는 단어를 사용하라
  • 이름은 다르지만 동일한 직무가 존재할 수 있음
  • “Front-end UX Software Engineer 1.” 같이 전용 네이밍을 사용하여 복잡하게 만들지 말라
• 엔지니어링 용어를 사용하라
  • 단위 테스트, 배포, 버전 관리, JIRA 티켓, 지연 시간, 데이터베이스, API 호출, 분산 시스템에 대해 이야기하라
  • 엔지니어링 어휘를 많이 사용할수록 지원자를 소프트웨어 엔지니어로 신뢰하기가 더 쉬워진다
• 단순하게 작성하라
  • 이력서는 빠르게 읽어야 하며, 단순한 것은 빨리 읽히므로 단순하게 작성하라
  • 이력서는 복잡할수록 오히려 인상적이지 않다
• 중요한 경험 > 모든 경험
  • 누구나 이력서에 쓸 수 있는 것은 많지만, 그렇다고 해서 꼭 써야 한다는 의미는 아니다
  • 지원하는 직무에서 가장 눈에 띄는 내용을 작성하라, 모든 것을 담을 수는 없다

 

 

 

출처: https://levelup.gitconnected.com/the-resume-that-got-a-software-engineer-a-300-000-job-at-google-8c5a1ecff40f