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

 

 

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

---

The Frugal Architecture - 알뜰한 아키텍처를 위한 7가지 원칙(아마존 CTO Werner Vogels)

• 알뜰한 아키텍처를 이야기한 이유
  • 아이러니하게도 클라우드 컴퓨팅이 기존 온프레미스 시대의 하드웨어 제약을 없앴음
  • 원래 창의성과 혁신은 바로 기술의 제약에서 옴
  • 클라우드 시대에 해당하는 새로운 제약 조건은 비용이며, 이를 통해 새로운 창의성을 발휘하고자 함
• 알뜰한 아키텍처의 원칙과 사례 요약
  • 비용을 (비기능적) 요구사항으로 설정하라
    • 비기능 요구사항은 특정 기능보다는 시스템 작동을 판단하는 기준임
    • 개발 및 운영 과정의 모든 단계에서 비용을 고려해야 함
  • 시스템을 비즈니스 운영 비용에 맞춰라
    • 시스템을 설계/구축할 때는 수익을 고려해야 함. 돈을 버는 방법을 찾고, 아키텍처가 수익을 내는지 확인해야 함
    • 비용이 더 많은 성장은 결국 파멸의 길로 이어지게 됨
  • 아키텍처는 타협(Trade-off)의 연속이다
    • 기술과 비즈니스 요구 사항 사이의 적절한 균형을 찾는 것이 중요함
    • 예를 들어 장애 방지를 위해 회복력에 투자하면, 성능에 대해서는 포기해야 할 수 있음
  • 측정되지 않은 시스템은 알 수 없는 비용을 만든다
    • 주의 깊은 관찰과 측정 없이는 시스템 운영에 드는 실제 비용을 알 수 없음. 모든 부분에서 관찰하고 적절한 모니터링을 구현해야 함
    • 관찰 가능성(observability)에 대한 투자 수익은 일반적으로 비용보다 훨씬 큼
  • 비용을 인식하는 아키텍처는 비용을 통제할 수 있다
    • 알뜰한 아키텍처의 핵심은 비용 최적화 기능과 결합된 강력한 모니터링임
    • 잘 설계된 아키텍처를 통해 쉽게 개선 조치를 취할 수 있음
    • 이를 위해 애플리케이션을 쉽게 바꿀 수 있는 작은 빌딩 블록으로 나누면 좋음
  • 비용 최적화는 누적되어야 한다
    • 비용 효율성 추구는 지속적인 여정이어야 하며, 배포 후에 다시 최적화하여 점진적 개선해야 함
    • 아주 작은 최적화처럼 보일 수 있지만 규모에 따라 큰 절감 효과가 축적될 수 있음
  • 성공은 안주하는 경향이 있다
    • 대개 큰 실패나 장애물없이 성공을 거두면 현실에 안주하게 되고, 예전에 성공한 방법, 도구 및 방식에 대해 과신하는 위험한 경향이 있음
    • 이는 현 상태에 대한 의문을 제기하거나 보다 비용 효율적이거나 확장 가능한 새로운 옵션을 탐색하는 것을 방해할 수 있음

출처: https://twitter.com/channyun/status/1739417269342716246?t=UC1rKTfgX6AT79MkFHQmBQ&s=09

 

 

 

겸손함인가? 자기 검열인가? 자기 자신에 대한 평가를 멈추자

• 승진
  • Bad: 윗선에서 요구한 일을 완벽하게 처리한 후에야 승진에 대해 조심스럽게 언급한다.
  • Good: 적극적으로 승진에 대한 관심을 표현하고, 준비 방법에 대한 피드백을 요청하여 자신의 의지를 분명히 하고 구체적인 성장 방향을 얻는다.
• 이직
  • Bad: 회사를 떠날 결심을 한 후에야, 정말 이직할 마음이 있는 회사들의 채용 공고에 명시된 요구 사항을 100% 충족시키기 위해 준비하고 이력서를 제출한다.
  • Good: 자신의 경험이 적합해 보이는 회사에 (요구 사항의 약 50%에 해당하는 지원자격을 갖춘 경우) 적극적으로 지원하고, 면접과 실전 준비를 통해 다양한 회사의 인재상을 이해하며, 실제 오퍼를 받았을 때 고려한다.
• 입사 후 적응
  • Bad: 처음 팀에 조인했더니 사수가 바빠 보여서 혹은 바보같아 보일까봐 질문을 못함. 그들의 의도를 파악하지 못하고 일을 하여 잘못된 혹은 불필요한 방향으로 진행함
  • Good: 본인이 맡은 업무가 어떻게 끝나야 성공인지 실패인지 그들의 의견을 직접 듣고 파악해야 함

출처:

https://twitter.com/dylayed/status/1740179367395991711?t=5AvQ9nPGfJvkTR48tgEqLw&s=09

https://www.youtube.com/watch?v=cjWpryKRGts

 

 

 

회고의 필요성

“연구 결과에 따르면 직접 경험에 따른 학습은 회고, 다시 말해 경험으로 얻은 소중한 교훈을 결합하고, 요약하고, 이해하려는 의식적인 노력과 함께할 때 더 효과적이다. 철학자이자 교육자였던 존 듀이도 비슷한 말을 했다. "우리는 경험으로부터 배우는 것이 아니다. 경험에 대한 회고로부터 배우는 것이다.”

 

출처: 존 도어 OKR

 

 

 

왜 프로그래머는 문이 달린 개인 사무실이 필요할까?

• 프로그래머이자 YC를 만든 폴 그레이엄이 처음으로 두 가지 유형의 작업을 구분함
  • 중단해도 문제가 없는 작업으로, 언제든지 멈추고 다시 시작할 수 있음
  • '방해 금지(Do Not Disturb)' 작업으로, 집중을 요구하며 중단하면 생산성에 큰 손실이 발생함
• '방해 금지' 작업의 생산성은 선형적이지 않으며, 시간의 제곱에 비례하여 증가할 수 있음.
  • 예를 들어, 2시간 동안의 작업은 4단위의 생산성을, 1시간씩 두 번의 작업은 2단위의 생산성을 낼 수 있음.
  • 이러한 작업에서는 30초의 방해가 생산성을 크게 저하시킬 수 있음.
• ‘방해 금지’ 작업을 해야하는 경우
  • 개인 사무실이 필수적임
  • 이메일 확인 등의 일정에 구애받지 않고 작업에 몰입할 수 있어야 함
  • 이에 대한 양해를 먼저 구하고, 관리자들 역시 이를 지원해주어야 함

 

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