책 기본 정보

제목: Go 성능 최적화 가이드

원제: Efficient Go

저자: 바르틀로미에 플로트카(Bartłomiej Płotka)

역자: Golang Korea

출판사: 디코딩

1. 소프트웨어 효율성이 중요한 이유

1.1 성능의 뒷면

성능: (컴퓨터가) 해야 할 일을 얼마나 잘 하고 있는가?

→ 즉 속도에만 국한되는 뜻은 아님. 누군가 쓴다면 그 사람이 어떤 뜻으로 쓰는지 확인하자

graph TD
  Performance[성능 #40;내가 잘 하고 있는가#41;] --> Accuracy[정확도 #40;실수하고 있지 않은가#41;]
	Performance --> Efficiency[효율성 #40;일을 지나치게 많이 혹은 자원을 과하게 쓰진 않는가#41;]
	Performance --> Speed[속도 #40;빠르게 하고 있는가#41;]

1.2 최적화에 대한 오해

1. 최적화 → 가독성 저하?: 뭐 로우 레벨 딴에서까지 하면 그럴 수 있으나 그런 케이스는 일부이며 대다수는 그렇지 않음. ‘지금은 일단 성능 고려하지 않고’ 하는 것 보다 그냥 처음부터 효율을 고려하는게 추후 유지, 보수에도 좋다. 예) 할당/불러오기 횟수는 최소한으로! 또한 시간이 지나면서 가독성에 유리한 것도 바뀐다 예) 옛날에는 변수명에 타입을 썼으나 요새는 IDE가 좋아서 안 씀.
2. 최적화는 결국 필요 없다?: YAGNI(You Aren’t Going to Need It), 즉 기능은 요구가 되었을 때 만들어라. 이걸 준수하는 것은 좋다. 그러나 이거 하나에 목 매고 최적화 무시하는 것을 하지 마라.
3. HW비용 < 개발자 비용이니 굳이 필요한가?: 자원 낭비로 인한 추가적인 유지, 보수 필요성이 생기는데 이 또한 결국 개발자가 해야함. 더군다나 하드웨어가 발전하는 속도보다 소프트웨어가 느려지는 속도가 더 빠름.
4. *수평적 확장하면 된다?: 확장해서 감당 가능한 부하량이 늘어도 이전과 같은 성능을 낼 수도 있다.
5. 효율성보다 출시 시기가 중요하다?: 시간이 늘어지면 수익이 떨어지는 거 맞음. → 애자일 방법론 / 개념증명 / 최소 기능 제품 등이 도입되는 이유 하지만 사이버펑크2077 같은 사례를 본다면? 버그, 최적화 똑바로 안 잡았다가 회사 주가 나락갈 수도 있음.

1.3 코드 성능 끌어올리기

이 책은 ‘속도’에 한정되어 있지 않고 종합적인 성능에 방점을 둠.(1.1 그래프 참조)