개요
개발을 하면서 ‘오류’를 만나는 일은 마냥 반갑지만은 않은 일이다. 업무 시간을 더 길게 잡아먹는 데다가 시간을 많이 들인다고 무조건 해결된다는 보장도 없기 때문이다. 하지만, 가장 빠르면서도 확실한 성장방법인 것은 분명하다. “백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다” 라는 말도 있다. 오류를 만날 때 좌절하지 않고 더 나은 개발자로 성장할 수 있는지 두 가지 원칙을 알아보자.
첫 번째 원칙 : 오류가 발생하면 소스 코드 레벨에서 이해하자
코드가 한 번에 의도한 대로 동작해주면 정말 행복하지만, 그런 일은 잘 일어나지 않는다. 어디가 잘못된 것인지 찾기 위한 가장 쉬운 방법은 단연 구글링이다. 관련 코드나 로그를 검색하면 손쉽게 해결책들을 찾을 수 있지만, 이 장의 저자는 그보다도 소스 코드 레벨을 확인해보자고 한다.
그리고 그 예로 레디스 오픈소스에 실제로 버그를 수정해 컨트리뷰터가 될 수 있던 일화를 소개한다. 문제가 되었던 상황은 개발을 하다보면 흔히 겪게 되는 두 가지 툴을 같이 사용하려다 컴파일이 되지 않는 문제였는데, 의외로 해결책은 소스 코드 안에 있었다고 한다. 이런 경우 대부분 스택 오버플로우에 검색해 같은 문제를 겪은 다른 사람들의 해결책을 따라가기 마련인데, 이 분은 직접 컴파일이 되지 않는 부분의 소스를 찾아 리눅스 버전이 잘못 작성되어있던 버그를 발견하고 직접 오픈 소스에 패치 PR을 작성해 문제를 해결할 수 있었다고 한다.
서비스를 운영하다 보면, 다양한 오류를 마주하게 되는데 이럴 때마다 구글링을 통해 손쉽게 해결하게 되면 실제로 깊은 지식을 얻기는 힘들다. 해당 툴의 소스 코드를 확인해보는 것만으로도 깊은 지식을 얻어 파생되거나 비슷한 문제를 예방할 수 있게 된다.
두 번째 원칙 : 알아낸 지식을 글로 공개하자
이렇게 문제를 마주치고 해결까지 했다면 결과물을 남기는 것이 중요하다. 기록을 하면 더 오래 기억에 남게 되고, 또 미처 이해하지 못했던 부분까지 다시 한 번 되짚어 볼 수 있다. 이러한 기록은 되도록 혼자 보는 것보다 블로그나 오픈 소스에 기여하는 방법을 통해 공개해보는 것이 좋다. 글을 작성하는 것도 중요하지만 여러 사람에게 확인받는 과정도 굉장히 중요하다. 아예 모르는 것보다 잘못 아는 것이 더 위험하다.
가급적이면 결과물을 공개해 다른 사람의 조언을 들을 기회를 얻어보자.
한 걸음 더 나아가기
소스 코드도 확인해보고 기록까지 마쳤다면, 한 걸음 더 나아가서 해당 기술이 왜 생겨났는지도 생각해보자. 기술의 동작 방식이나 특징을 분석해보면, 좀 더 깊은 지식을 채울 수 있다.
이 기술은 어떻게 동작하길래 내가 짠 프로그램에서만 이런 문제가 발생한 걸까? 두 가지가 결합되었을 때 어떤 부분이 문제를 일으키게 되는 걸까? 이런 식으로 장애를 해결할 때 원인을 깊게 공부해두면, 잊지 않고 더 오래 기억할 수 있게 된다.
마지막으로, 어떤 정보에 대해 그대로 납득하기 보단 정말인지 확인해보는 과정도 가끔은 도움이 될 수 있다. 하나의 예시로, 자바 7 버전에서 8 버전으로 업그레이드 되었을 당시, CPU 사용량이 줄어든다는 말이 있었다. 대부분의 개발자라면 ‘그런가보다’ 하고 버전업을 진행했을텐데, 이 장의 저자는 실제로 그런지 확인하는 작업을 했다고 한다.
확인해보니 CPU 사용률 50~60%에서 버전업을 한 뒤 20~30% 로 현저히 줄어드는 것을 확인할 수 있었다. 버전업을 하기 위해서는 꽤 많은 코드 수정이 필요했지만, 이렇게 실제로 수치를 확인하니 업그레이드를 안 할 수 없었다고 한다. 여기서 멈추지 않고 어떻게 성능을 이렇게 끌어올릴 수 있었는지도 확인하기 위해 자바 8에서 개선된 사항들을 확인해봤다.
그 중 HashMap의 성능 개선이 있었고 선형 리스트 형태를 트리 구조로 바꾼 덕분에 그렇게 되었다는데, 정말 그런지 코드 레벨에서 확인해 보자. 트리 구조로 바뀐다면 리스트보다 검색은 빠를 수 있지만, 추가/삭제는 훨씬 더 느려질 것이다. 그렇다면 데이터가 몇 개 없는 상황에서는 오히려 트리 구조가 비용이 더 많이 드는 것 아닐까? 자바 8의 HashMap 구현 부분을 확인해보니 내부의 원소가 8개가 넘어가면 그 때부터 트리 구조로 바뀌게 된다. 즉, 매번 트리 구조로 생성되는 것이 아니라 데이터의 개수에 따라 가장 효율적인 형태를 선택하는 하이브리드 형태라는 것이다. 대부분 블로그나 자료를 찾아보면 자바 8 이후 HashMap 은 트리를 사용한다고만 나와있기 때문에 직접 소스 코드를 보기 전까지는 알기 어렵다. 때문에 코드 레벨에서 깊게 학습해보는 과정이 중요한 것이다.
위에서 언급한 학습 방법들은 사람에 따라 잘 맞을 수도 있고 안 맞을 수도 있을 것이다. 이 원칙들의 기반이 되는 것은 바로 호기심이다. 이제는 밈처럼 자리잡은 ‘왜 안 되지?’ 혹은 ‘왜 되지?’ 를 끊임없이 생각하며 질문을 던지는 습관을 들이면 이 방법들이 아니더라도 자신에게 맞는 학습 방법을 찾을 수 있을 것이고 더 기본기가 탄탄한 개발자로 성장할 수 있을 것이다.
이 질문들은 던지기 가장 좋은 시점은 바로 오류를 만났을 때이다.
이제 오류를 마주치게 되면 우와, 성장할 수 있는 기회다! 라고 생각해보자.