멀리 보기의 필요성
나라는 사람은 정말 DFS형 인간이구나 하고 생각 들곤 한다. DFS란 컴퓨터에서 깊이 우선 탐색(Depth First Search)라고 불리는 알고리즘의 약자인데, 문제를 해결하기 위해 탐색해나갈 때 이전 상태에서 바로 연결된 다음 상태를 탐색해나가는 알고리즘을 말한다. 설명만 봤을 땐 나쁘지 않은 방법 같지만 눈 앞의 문제만을 해결해나가는 것은 여러모로 한계가 있는 것 같다. 그 한계를 느꼈던 이야기를 잠깐 끄적여본다.
나는 DFS 방식으로 학습해나가는 편이다. JVM 최적화를 할 일이 있어서 찾아보다 보니 G1GC Garbage Collector가 좋다는 말을 보고 G1GC가 뭔지 찾아보다가 Mark and Sweep 알고리즘을 갑자기 발견하고, 그 알고리즘이 정확히 뭔지를 모르니 이번엔 Mark and Sweep 알고리즘에 대해 찾아보는 하는 식이다. 학습할 때뿐만 아니라 일을 할 때도 비슷하다. 어떤 문제를 디버깅하다가 다른 문제를 마주치고, 그 다른 문제를 파헤치기 시작한다.
이 방식의 단점은 쉽게 끝이 안 날 수 있다는 점이다. 자꾸 모르는 게 튀어나오다 보면 그걸 계속 쫒아나가다 보니 원래의 문제와 너무 멀어질 때가 종종 있다. 이런 현상을 야크 털 깎기라고 부르는데, 야크 털 깎기의 예시는 이렇다. 애플파이를 하기 위해 주방을 가던 길에 복도의 페인트가 벗겨진 것을 발견한다. 페인트를 사러 가는 길에 빵집을 발견하여 컵케잌을 사 먹다가 치통을 느낀다. 치통이 있으니 의사에게 연락을 하고, 그러다 보면 점점 원래의 애플파이와는 멀어지는 것이다.
장기적인 관점에서 봤을 때 DFS 방식으로 학습해나가는 것은 꽤 나쁘지 않을 수도 있다. 어쨌든 그렇게 끝없이 파헤쳐 들어가는 과정에서 많이 학습을 하게 되지 않겠는가. 나 같은 경우에도 이제는 새로운 것을 배울 때 새로 알게 된 개념 때문에 원래 학습하던 것에서 멀어지는 일이 많이 줄어들었다는 것을 느낀다. 하지만 당장 급한 문제가 있을 때는 급한 불을 먼저 꺼야만 하기 때문에 이 방식은 좋지 못하다.
다른 관점을 생각해보자. airbridge에는 고객사로부터 수집한 이벤트를 잘 모아서 AWS S3에 전달해주는 기능이 있다. 이 기능은 참 말썽이 많은 친구였었는데, 기존 개발된 스펙이 여러모로 확장성을 가지기 어려운 구조였기 때문이다. 스펙 자체가 문제를 일으키기 쉬운 스펙이다 보니 이미 개발되어 있던 것을 아무리 더 최적화하려 노력해봤자 큰 성과를 거두기 어려웠다. 결국 온갖 문제들로 오랫동안 고통받은 뒤에야 새로운 스펙으로 다시금 개발하여 서비스를 시작했고, 평화가 찾아왔다.
또 다른 예시를 생각해본다. AWS에는 Spot Instance라는 기능을 제공하는데, 일시적으로 저렴한 비용으로 EC2 instance를 사용할 수 있는 대신 언제 instance가 종료될지 알기 어려운 문제가 있는 기능이다. 운영을 할 때 신경 써야 할 것들이 좀 있다는 단점을 제외하면 비용상 정말 큰 이점이 있기 때문에 서버비를 절감하려고 할 때 반드시 고려해야 한다. airbridge에서도 비용 절감을 위해 Spot Instance를 이용하곤 했는데 termination notification을 받아서 처리해줄 수 있도록 별도 component를 운영하는 등 다양한 노력들을 기울였었다.
어떻게 하면 Spot Instance를 잘 활용할 수 있을지 정말 많이 고민하던 중 최근 다시 Spotinst라는 서비스에 대해 알아보면서 많은 생각이 들었다. Spotinst는 Spot Instance 관리 자체를 어느 정도 대행해주는 서비스라고 볼 수 있는데, 다양한 고객사들의 cloud computing 자원 현황 데이터를 이용하여 spot instance를 좀 더 효율적으로 배치하여 원치 않게 종료되는 상황을 훨씬 완화해준다고 한다.
만약 당장 현재 구축해둔 시스템에서 Spot Instance의 종료 문제를 해결하기 위한 노력들을 기울이던 것을 잠깐 접어두고, 더 넓은 관점에서 시스템을 개선하는 생각을 해보는 시간을 가졌더라면 어땠을까? Spotinst가 정말 똑똑하게 Spot Instance를 잘 배치해준다는 가정 하에 당장 눈 앞의 문제를 해결하기 위한 노력들을 다른 가치 있는 일에 쓸 수도 있었지 않을까 하는 생각이 들었다.
이런 일들은 일하는 과정에서 자주 나타난다. 어떤 때에는 그렇게 미리 큰 관점에서 행동을 취해 득을 본 적도 있다. 예를 들어, terraform을 도입했던 일이 그렇다. terraform을 처음 도입할 때만 해도 당장 AWS 콘솔에서 손으로 직접 작업하던 것보다 시간이 오래 걸리고, 또 학습 비용도 어느 정도 있어 비효율적이라 느끼기도 했지만 결국 지금 회사에서는 매우 유용하게 쓰고 있다.
하지만 당장 바쁜 상태가 계속되는 상황에서는 멀리 보기가 어려운 것 같다. 처음 Spotinst를 알았을 때 Spotinst라는 서비스에 대해 더 알아보기엔 당장의 문제를 해결하는 것이 너무 급했기 때문에 더 알아보지 않고 무시했었다. 그리고 그 존재를 오랫동안 잊고 있다가 최근 소식을 접하면서 다시 인지하게 된 것이다.
이런 사례들을 생각해보면 너무 바쁘게만 살아서도 안 되는 것 같다는 생각이 든다. 마음이 급하더라도 가끔은 손에 잡힌 일을 내려놓고 잠깐 한 발 물러서서 다시 생각해봐야 하지 않을까? 그럼 어떤 주기로 한 발 물러서기를 해야 하는가, 어디까지 멀리 보기를 시도해야 하는가, 의문들이 떠오른다. 이건 이제 앞으로 살아가면서 차차 느껴봐야겠다.
