전 회사에서 막바지에 많은 시간을 들여 했던 일이 자동화와 시스템 최적화였다. DevOps 팀에서 준비를 잘 해주어서 여러 서버들의 구석구석에서부터 메트릭과 로그를 긁어 모아 시각화를 할 수 있었기 때문에 그래프를 보며 패턴을 찾고, 모든 패턴에 대해 올바른 설명을 만들어냈다.

이런 작업을 본격적으로 하기 전에도 어느 정도의 모니터링 및 시각화는 하고 있었다. 가끔 예상하지 못한 문제가 생기거나, 뭐라고 설명해야 할지 애매한 장애들이 생기곤 했지만 전반적으로 돌아가는 시스템이었다. 돌아가는 시스템에 손을 대기 위해서는 이유가 필요하다. 다행히도 ELB 가 종종 미쳐 돌아가는게 너무 명백한 그래프가 CloudWatch(AWS 서비스중 하나)에서 튀어나왔기 때문에 이 문제를 잡기 위해 작업이 시작되었다. 그리고 메트릭과 로그를 모아서 뷰를 만들어 갔는데, 그렇게 하다 보니 다른 여러가지 문제들이 보이기 시작했다. 여기서부터 작은 개선과 검증이 한동안 반복되었는데, 시간이 좀 지나면서 시스템의 전체적인 효율, 성능 등이 극적으로 개선되었다. 이렇게 개선될 여지가 있었다는 사실 자체가 놀람의 포인트.

• 숫자를 계속 보고 있어도 시각화를 하기 전까지는 알아채지 못하는 현상들이 있다. 숫자를 모두 확보하는 것은 기본이고, 이를 자유롭게 시각화를 할 수 있는 도구가 있어야 한다
• 모든 컴포넌트의 코드 한줄 한줄까지 알고 있는걸론 부족하다. 사용자가 생기는 순간 시스템은 자체적으로 생명력을 가지고 창조자의 통제를 벗어나려 한다.
• 시스템 설계자로서 나는 안다는 자신감은 방해된다 (ㅜ_ㅠ)

아직 그리지 않은 숫자들이 있다면, 매우 높은 확률로 시스템은 전역 최적 상태가 아니다. 지역 최적 상태에 빠져 있거나, 혹은 그냥 길을 잃고 떠돌고 있을 가능성도 있다. 물론 전역 최적에 꼭 도달할 필요는 없다. 현재 상태가 전역 최적(도달 가능한 최고치)와 비교할 때 어느 정도에 있는지 감을 잡는 것 도 훌륭한 스킬 중 하나로 수련이 필요한 부분이다. 개선 가능성 및 기대치도 데이터를 까놓고 일부만이라도 분석해보면 어느정도 감을 잡을 수 있다. 당연한 얘기인데,

최적화는 어떻게 시작한다? Profiling 코드 레벨의 프로파일러들은 많이 있지만, 좀 더 큰 단위(서비스)의 프로파일링 툴은 아직 초기 단계라 삽질과 조사가 많이 필요하다. newrelic 이 그런 도구용 서비스 중에 하나려나.

이런 프로세스를 진행할 때 주의할 점은 부분을 잘 알고 있는 사람이 오히려 전체를 볼 때 이음새를 놓치기 쉽다는 점이다. 부분의 합이 전체보다 크기 때문인데, 이것은 비과학적인 현상이 아니다. 튼튼한 구조물을 만들려면 접착제 - Glue - 가 무시할 수 없을 만큼 많은 양이 필요하기 때문이다. 요새 주변의 사소한 것들이라도 하나의 계(system)을 만드는 단위가 보이면 뭔가 더 나은 상태로 개선해보고 싶은 생각이 든다. 야크쉐이빙 하다 망하기 딱좋은 상태

사실 이건, 오늘 내 마음에 들었던 일상 최적화에 대해 쓰려다가 옆으로 새어 버린 이야기다. 어쩌다 이런 글이 된거지… 시작은 우리의 일상도 장비도 최적화 대상입니다, 라는 말을 하고 싶었던건데.

나는 코세라/Edx/udacity/ocw 등의 MOOC를 자주 보는데, 카페(내 주된 작업공간…)에서 케이블링 때문에 짜증이 많이 났었다. 좁은 테이블에서 이어폰/헤드폰 케이블에 걸려 커피를 쏟은것도 여러번 … 케이블이 문제라는 사실을 깨닫기 위해서, 커피를 한잔 쏟아버리고 가방 안에 있는 모든 물건에 대해서 “니가 범인이냐?” 를 시전해야만 했다. 여튼 그런 이유로 블루투스 헤드폰을 질렀는데, 이거 신세계가 펼쳐졌다. 갇혀있던 지역 최적해에서 벗어나 바다로 나간 느낌이다. 더불어 서피스 어댑터도 하나 더 구해서 회사/집에 각각 배치하고 평일에는 가방에 어댑터를 넣지 않기로 했다. 카페에서 배터리만 사용. 이것도 꽤 만족스럽다. 야호!

Improvement 와 Optimization 을 잘 구분하지 못한 것 같다. 이건 조금 더 자료를 찾아보고 생각을 정리해 2015년 언젠가의 포스팅 주제로 남겨둔다.