brunch

You can make anything
by writing

C.S.Lewis

by 정주홍 Dec 15. 2019

멀리 보기의 필요성

나라는 사람은 정말 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라는 서비스에 대해 더 알아보기엔 당장의 문제를 해결하는 것이 너무 급했기 때문에 더 알아보지 않고 무시했었다. 그리고 그 존재를 오랫동안 잊고 있다가 최근 소식을 접하면서 다시 인지하게 된 것이다.

이런 사례들을 생각해보면 너무 바쁘게만 살아서도 안 되는 것 같다는 생각이 든다. 마음이 급하더라도 가끔은 손에 잡힌 일을 내려놓고 잠깐 한 발 물러서서 다시 생각해봐야 하지 않을까? 그럼 어떤 주기로 한 발 물러서기를 해야 하는가, 어디까지 멀리 보기를 시도해야 하는가, 의문들이 떠오른다. 이건 이제 앞으로 살아가면서 차차 느껴봐야겠다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari