[Book Reviews] 2019 11 03, 고명진 - 그들은 과연 알고리즘을 알았을까?(2018년)

[rayleighko]

Read this book from: 2019. 11. 03 ~

전반적으로 생소한 접근에 당황했다. 실제로 알고리즘을 공부할 때 무작정 알고리즘을 외우고 바로 문제를 풀었기 때문이다. 이 책에서 말하는 문제 풀이는 우선 문제를 정의하는 것부터 시작한다. 정의된 문제를 작은 단위로 쪼개서 다시 여러 개의 문제로 만들어 각각의 문제를 해결한다.

PART 01 알고리즘

• Chapter 01 계산 및 알고리즘: 헨젤과 그레텔

  • 01 계산을 이해하는 길
  • 02 정말로 가 보기: 계산이 실제로 벌어질 때

  이번 챕터에서는 2번의 당황을 경험했다. 1. 헨젤의 행동을 이렇게도 해석할 수 있구나.. 2. 표상을 꼭 정해야 하는 거니..

  물론 이런 당황은 부정적인 게 아니었기에 색다른 충격이라고도 할 수 있겠다. 한 가지 문제라고 생각했던 것들이 사실은 한 가지 문제가 아닌 여러 문제의 덩어리였음을 생각할 수 있게 되었고, 한편으로는 알고리즘 공부를 할 때 시간이 들더라도 이런식으로 접근을 해보는 게 좋을 것 같다고 생각했다. 이런 접근 방식이 익숙해지고 어느정도 궤도에 올라 빠른 속도로 문제를 풀어낼 수 있을 거라고 생각했기 때문이다. 나중에 사내 프로젝트나 AUSG 멤버들과 방학을 이용한 알고리즘 공부를 해보는 것도 좋을 것 같다.

• Chapter 02 표상과 데이터 구조: 셜록 홈즈(읽는 중)

  • 03 기호의 신비
  • 04 탐정의 수첩: 사실을 좇는 소품

• Chapter 03 문제 해결과 한계: 인디아나 존스

  • 05 완벽한 데이터 구조를 찾아서
  • 06 좋은 정렬 방식을 골라내기
  • 07 풀기 어려운 과제

PART 02 언어

• Chapter 04 언어와 의미: 오버 더 레인보우

  • 08 언어의 프리즘
  • 09 딱 맞는 음 찾기: 소리의 의미

• Chapter 05 제어 구조 및 순환문: 사랑의 블랙홀

  • 10 날씨 다시 반복
  • 11 해피엔딩은 필연이 아니다

• Chapter 06 재귀: 백 투 더 퓨처

  • 12 제때에 해 두면 제대로 풀린다
  • 13 해석하기 나름

• Chapter 07 유형과 추상화: 해리 포터

  • 14 마법의 유형
  • 15 조감도: 세부 사항에서 추상화하기

[roeniss]

"방학을 이용한 알고리즘 공부를 해보는 것도 좋을 것 같다"라니 후덜덜.... 이런 접근을 익숙하게 할 수 있으면 분명 큰 도움이 될 것 같아요

[rayleighko]

이번 주는 Chapter 02 표상과 데이터 구조: 셜록 홈즈와 Chapter 03 문제 해결과 한계: 인디아나 존스, Chapter 04 언어와 의미: 오버 더 레인보우를 읽었다.

지난 주에 잠깐 적을 여유가 없었는데, 2주만에 읽은 내용을 쓰려니 당시의 감흥이 살아있지 않은 것 같아 앞으로는 매 주 빼먹지 말아야겠다는 생각을 했다.

더불어 이번에 읽은 내용은 초반에 읽었던 어려움과는 달리 술술 읽을 수 있어 재미있었다. 가끔 영화의 한 장면을 이야기하면서 비유하는데, 실제로 본 영화의 경우는 몰입에 도움을 주었다(안 본 영화는 살짝 방해하는 느낌이긴 했음).

챕터 2부터 언어에 대해 설명하는데, 언어에 대한 또다른 접근 방식이 견문을 넓혀주었고, 프로그래밍 언어 전반에 걸친 공통적인 특성을 고민해볼 수 있었다.

요즘 인터넷 밈을 인용하면, 알고리즘 마렵다!

[rayleighko]

Chapter 05 제어 구조 및 순환문: 사랑의 블랙홀

Chapter 06 재귀: 백 투 더 퓨처

Chapter 07 유형과 추상화: 해리 포터

각 챕터에 대한 리뷰보다는 전반적인 리뷰를 하는 게 낫다고 생각했다. 현실적으로 구현을 하면서 알고리즘을 적용할 기회는 많이 있었다. 다만, 그럴 때마다 학습이 부족해 많은 고민(가령 페이지네이션)을 해서 자신만의 결과물을 얻었던 것같다.

한편으로는 현대의 개발자 대부분이 성능보다는 생산성 혹은 개발 속도, 가독성 등에 초점을 맞춰 개발하고 있는 상황에서 1차 생산자가 아닌 2차 생산자의 입장에서 "알고리즘을 배워야 할 시기는 언제인가?"라는 고민을 하지 않을 수 없을 것이다.

시스템을 공부 할 때는 내가 짠 테스크의 로직은 하나라도 줄이면 유의미하게 성능을 개선한 사례로 취급되었다. 동료들이나 구루들도 그것을 목표로 개발하고 최대한 짧은 코드로 좋은 성능을 갖추는 것을 미덕으로 삼고 있는 것도 사실이다. 게임을 공부할 때는 내가 짠 코드를 최대한 개선해서 성능을 높여 원하는 속도로 유저에게 제공하는 것이 목표였다. 그러기 위해서는 성능에 대해 고민했어야 했고, 당연하게도 성능이 보장되지 않는 로직을 프로덕션 코드에 추가할 수 없었다. 알고리즘은 이럴 때 힘을 발휘했다.

그러다 웹으로 넘어온 지금 시점에서 알고리즘의 중요성은 앞선 두 케이스보다 높지 않다. 프로덕션을 수정할 수 있는 주기도 앞선 것보다 짧아 사용자가 알아채지 못하게 개선할 수도 있으며, 우선적으로 서비스를 제공하고 추후에 필요할 때 성능을 개선해도 그다지 혹평을 받지 않는다.

물론 적시적소에 코드를 작성에 항상 성능을 보장하며, 협업자가 보기에도 이해하기 쉬운 코드를 짜고 정기적으로 코드 리뷰를 하며 코드를 공유하는 시간을 갖는 것도 소중하며 중요하다. 하지만, 실제로 '일정'을 맞추지 못하는 개발자는 아무리 코드를 유려하게 짠다고 해도 볼품없고 쓸모없는 게 현실이다. 그래서 이 책을 읽는 기준, 그러니까 알고리즘이나 자료구조를 바라보는 시점이 성능이어서는 안된다고 생각했다. 그래서 우선적으로 '좋은 코드'를 기준으로 생각했다.

그래서 마지막으로 내가 생각하는 좋은 코드를 네 가지를 기준 정의할 수 있었다. 최우선적으로 일정에 맞춰 구현하는 것을 목표로 하고, 최대한 결합도를 낮추고 응집도를 높여 적절한 모듈화와 추상화가 되어있어야 하는 코드, 그와 동시에 동료들이 읽기에도 편하고 이해하기 쉽고 적절한 코드 컨벤션을 지키는 코드, 테스트 코드를 짜고 사이드 이펙트를 최대한 줄여 기능이 보장되는 코드, 동료들에게 인사이트를 주며 신입 개발자가 들어와도 이해할 수 있는 코드까지. 아직은 경험이 적어 이정도까지 하는 코드가 가장 바람직한 것 같다.