번역서를 읽을 때는 원제를 확인하는 습관이 있다. 원제와 부제목이 책의 핵심을 가장 잘 설명하는 경우가 많았기 때문이다. 가끔 원서 제목을 뛰어넘는 한글 제목이 있긴 하지만 대부분은 그렇지 못하다.
이 책의 원래 제목은 How to make things faster이다. 번역서의 제목과는 느낌이 사뭇 다르다. 실제로 생각 기법을 나열해서 설명해주지 않는다.
저자는 오라클(관계형 데이터베이스의 일종) 컨설턴트이다. 오라클 컨설턴트로서 고객을 만나 문제를 해결한 사례들을 소개하며 교훈을 준다. 저자가 만난 대부분의 고객이 겪는 문제는 속도였다. 오라클 고객이 컨설턴트를 필요로 할 문제가 속도말고 또 뭐가 있겠는가.
책을 읽으며 가장 인상적이었던 건 애플리케이션을 고치지 않고도 속도를 빠르게 만드는 방법이 많이 있다는 점이었다. 애플리케이션을 오랫동안 만들어 오다 보니 ‘성능 문제’가 생기면 ‘애플리케이션 어디를 고쳐야 되지?’라는 생각을 당연시했던 것 같다. 책에는 단지 사용 방법을 몰라서, 설정을 잘못해서 성능이 느려진 여러 사례를 소개한다.
여기서 나오는 큰 교훈 중 하나가 ‘관찰을 잘 하자’이다. 아래는 막상 읽어보면 별것 없어 보이는 저자의 R방법론이다.
핵심은
- 비즈니스 영향도가 가장 큰 것 부터
- 관찰해서
- 해결한다
이다. 원래 중요한건 별것 없는 거 같다. 사람들은 마법같은 기법을 기대하지만 단순하고 따라하기 쉬운게 더 좋은 방법론이다.
예를 들어, 할 일을 결정할 때 무엇을 기준으로 하고 있는가? 나는 가끔 중요해서가 아니라 하기 쉬워 보여서 어떤 일을 먼저 하기도 한다.
관찰하기도 마찬가지다. 내 개발 실력을 한 단계 올려준 건 사수가 로그를 보며 디버깅 하는 장면을 어깨 너머로 봤던 게 첫 번째 큰 일이었고, 디버거 사용법을 익힌게 두 번째 큰 일이었다. 순서는 발생 순서 순이다. 문제가 발생한 지점을 정확히 찾고 어떤 일이 발생하는지 관찰하면 문제 해결 시간을 단축할 수 있다.
로그와 디버거에 익숙한 분들은 그걸 누가 안 쓰냐라고 하실 수 있는데 의외로 그런 사람을 많이 봤다. 나도 그런 사람이었고. 예전에 입사 지원자들 코딩 테스트에서 에러 메시지를 안 보고 상상 디버깅 하시는 분들은 아쉽게도 모두 집으로 돌려보낼 수 밖에 없었다.
그리고 책에 나오는 많은 사례들 처럼 관찰을 잘 해보면 굳이 애플리케이션을 고치지 않고도 쉽게 문제가 해결될 수도 있다. 이 책에 부록처럼 첨부된 마지막 장이 책 전체의 주제를 관통한다고 생각하는데, 간단히 소개하면 이렇다. 아빠가 아이들에게 이렇게 묻는다. “아빠가 장을 보고 왔는데, 30분 이면 끝낼 만한 간단한 장보기가 네 시간이나 걸렸어. 장보기 시간을 줄이려면 어떻게 해야했을까?” 그러자 아이들이 저마다 장보기 시간을 줄일 수 있는 다양한 아이디어를 냈다. 하지만 어떤 아이도 아빠에게 왜 30분이면 됐을 장보기가 4시간이 걸리게 됐는지, 무슨 일이 있어났었는지 묻지 않았다.
예측 수련
이 책에서 비중있게 다루진 않지만 예측을 수련하라는 말이 나온다. 지금 다니는 회사 입사한 후 CTO 님이 굉장히 강조했던 내용과 비슷해서 한 번 더 상기하는 계기가 됐다. 아직도 익숙지 않고 잘 못하지만 역시 꾸준히 수련해봐야겠다.
CTO님은 이를 가추법이라고 소개해줬다. 가추법은 어떤 사실이나 현상을 보고 왜 그렇게 됐을지 가정해보는 방법이라고 한다. 가추법을 디버깅에 활용한다면 그냥 이렇게 저렇게 시도해 보는 게 아니고, 무언가 해결책을 시도해보기 전에 ‘이건 이러이러한 이유로 이렇게 됐을 것이다’라고 가정을 한 뒤에 그게 맞았는지 확인해 가는 식이다.
책에 나온 내용과 비교해보면 거의 같음을 알 수 있다.
아래 영상을 보고 디버깅을 좀 더 잘하게 되었다고 생각하는데, 이제보니 이 영상에서도 관찰하기와 예측 수련이 핵심이었던거 같다.
그 외
앞서 언급한 내용들 외에는 아래 내용들이 기억에 남는다.
- 총 실행 시간에 영향을 줄 수 있는 요인은 이벤트 수와 평균 처리 시간 단 두 개 밖에 없다.
- 필터링은 일찍 할 수록 좋다.
- 비율의 함정에 빠지지 말라. “예금을 비율로 받는 은행은 본 적이 없다”
마치며
성능 문제가 생기면 반사적으로 코드부터 열게 되는 개발자라면 읽어볼 만하다. 오라클 중심의 사례가 많지만 관찰하고 원인을 찾아가는 사고방식 자체는 어떤 기술 스택에서든 통한다. 짧은 책이니 부담 없이 읽을 수 있다.