5throck님의 시스템 규모 산정에 대한 글에 튜닝 이야기가 나와서 잠시 트랙백을 통해 튜닝에 대한 기억과 의견을 정리해 볼까 합니다.
우선, 5throck님이 말씀하신데로 운영과 개발 모두에 뛰어난 사람이 궁극적으로 가는 길 중에 하나가 튜닝이라는데 크게 공감합니다. 많이 고민했던 진로이고, 가능성도 있다고 믿어서 이런 저런 공부를 좀 했습니다. 결론은 아직 내 실력으로 부족하다는 것이었지요. 어쨌든, 우연하게 고객사에서 튜닝을 받기 위해 외부 업체와 같이 일을 한 적이 있는데, SAP의 튜닝은 일반적인 웹의 jsp나 sql 튜닝과는 좀 다른 느낌으로 다가 왔습니다.
일단, SAP의 특성상 매우 많은 table의 연관관계를 정확히 알고 있어야 하고, 모르는 경우에는 정말 꼼꼼하게 index 등을 생성할 경우 발생하는 영향성을 살펴야 한다는 점입니다. BC 분께 듣기로는 jsp 등에는 index나 sql의 수정이 다른 프로그램 들에 어떤 영향을 미칠지 검증해 주는 툴이 있다고 들었는데, 저희가 일한 곳에는 그런 기능을 사람이 수작업으로 대응하고 있었습니다. 노하우를 숨기기 위한 것인지는 모르겠습니다만, 특정 테이블에 소스나 sql의 수정만으로 대응이 안될 경우 index를 추가해야 했는데 이 때 관련된 모든 프로그램과 쿼리를 일일이 분석하고 그 영향성에 대해 예측한 다음, 문제가 없다고 판단될 때 적용하는 꼼꼼함을 보였습니다. 물론 그렇게 해도 어느 정도는 다른 프로그램이 느려진다든지 하는 문제가 있었습니다만 그런 경우가 매우 적었습니다.
같이 일을 한 업체가 직원 규모로는 그다지 많지 않았던 것으로 알고 있어서, 앞서 이야기한 영향성 분석 툴을 만들어내기엔 역량이 부족할 것으로 판단되어서, 그런 툴만 하나 잘 만들어도 장사가 되겠다는 생각을 한 적이 있습니다. 어쩌면 외산 툴은 이미 존재할지도 모르겠습니다.
튜닝 프로젝트의 마지막에는 개발자들에 대한 교육도 있었습니다. 하지만, 짧은 시간에 해야하는 교육이어서 깊은 이해를 돕기엔 어려움이 많았고, 일정 수준만 되는 개발자들은 이미 다 알고 있는 내용이라 좀 아쉬웠습니다. 하지만, 튜닝 프로젝트라고 한다면 제 생각에는 이런 교육이 깊이 이뤄지는 것 까지 포함하는 것이 좋다고 봅니다. 일회성으로 튜닝을 받는다 하더라도, 지속적으로 생겨나는 프로그램들의 수준이 성숙되지 않는다면 결국 다시 돈을 들여서 튜닝 프로젝트를 할 수 밖에 없기 때문입니다. 물론, 아무리 뛰어난 프로그래머들만 구성되었다 해도 시간이 지나면 전체적인 튜닝이 필요하겠습니다만, 그런 튜닝에 대한 비용을 최소화 하기 위해선 일상적인 운영을 하는 사람들의 역량이 바탕이 되어야 한다고 봅니다.
그리고, 튜닝을 프로그래머가 하는게 맞는지 BC가 하는게 맞는지도 제가 일하는 부서에서는 약간 논란이 있었는데요. 제 생각에는 BC가 모니터링을 하고 관리자로서 튜닝 가이드를 내려주면 그에 맞게 프로그래머가 수정하는게 맞다고 봅니다. 따라서 BC는 매우 뛰어난 튜닝 능력을 프로그래머는 그 스펙을 만족할 수 있는 기술을 가지는게 좋은 분업이라고 보입니다. 다시 말하자면 BC는 전략을 프로그래머는 전술을 수행한다고 할 수 있겠습니다.
우선, 5throck님이 말씀하신데로 운영과 개발 모두에 뛰어난 사람이 궁극적으로 가는 길 중에 하나가 튜닝이라는데 크게 공감합니다. 많이 고민했던 진로이고, 가능성도 있다고 믿어서 이런 저런 공부를 좀 했습니다. 결론은 아직 내 실력으로 부족하다는 것이었지요. 어쨌든, 우연하게 고객사에서 튜닝을 받기 위해 외부 업체와 같이 일을 한 적이 있는데, SAP의 튜닝은 일반적인 웹의 jsp나 sql 튜닝과는 좀 다른 느낌으로 다가 왔습니다.
일단, SAP의 특성상 매우 많은 table의 연관관계를 정확히 알고 있어야 하고, 모르는 경우에는 정말 꼼꼼하게 index 등을 생성할 경우 발생하는 영향성을 살펴야 한다는 점입니다. BC 분께 듣기로는 jsp 등에는 index나 sql의 수정이 다른 프로그램 들에 어떤 영향을 미칠지 검증해 주는 툴이 있다고 들었는데, 저희가 일한 곳에는 그런 기능을 사람이 수작업으로 대응하고 있었습니다. 노하우를 숨기기 위한 것인지는 모르겠습니다만, 특정 테이블에 소스나 sql의 수정만으로 대응이 안될 경우 index를 추가해야 했는데 이 때 관련된 모든 프로그램과 쿼리를 일일이 분석하고 그 영향성에 대해 예측한 다음, 문제가 없다고 판단될 때 적용하는 꼼꼼함을 보였습니다. 물론 그렇게 해도 어느 정도는 다른 프로그램이 느려진다든지 하는 문제가 있었습니다만 그런 경우가 매우 적었습니다.
같이 일을 한 업체가 직원 규모로는 그다지 많지 않았던 것으로 알고 있어서, 앞서 이야기한 영향성 분석 툴을 만들어내기엔 역량이 부족할 것으로 판단되어서, 그런 툴만 하나 잘 만들어도 장사가 되겠다는 생각을 한 적이 있습니다. 어쩌면 외산 툴은 이미 존재할지도 모르겠습니다.
튜닝 프로젝트의 마지막에는 개발자들에 대한 교육도 있었습니다. 하지만, 짧은 시간에 해야하는 교육이어서 깊은 이해를 돕기엔 어려움이 많았고, 일정 수준만 되는 개발자들은 이미 다 알고 있는 내용이라 좀 아쉬웠습니다. 하지만, 튜닝 프로젝트라고 한다면 제 생각에는 이런 교육이 깊이 이뤄지는 것 까지 포함하는 것이 좋다고 봅니다. 일회성으로 튜닝을 받는다 하더라도, 지속적으로 생겨나는 프로그램들의 수준이 성숙되지 않는다면 결국 다시 돈을 들여서 튜닝 프로젝트를 할 수 밖에 없기 때문입니다. 물론, 아무리 뛰어난 프로그래머들만 구성되었다 해도 시간이 지나면 전체적인 튜닝이 필요하겠습니다만, 그런 튜닝에 대한 비용을 최소화 하기 위해선 일상적인 운영을 하는 사람들의 역량이 바탕이 되어야 한다고 봅니다.
그리고, 튜닝을 프로그래머가 하는게 맞는지 BC가 하는게 맞는지도 제가 일하는 부서에서는 약간 논란이 있었는데요. 제 생각에는 BC가 모니터링을 하고 관리자로서 튜닝 가이드를 내려주면 그에 맞게 프로그래머가 수정하는게 맞다고 봅니다. 따라서 BC는 매우 뛰어난 튜닝 능력을 프로그래머는 그 스펙을 만족할 수 있는 기술을 가지는게 좋은 분업이라고 보입니다. 다시 말하자면 BC는 전략을 프로그래머는 전술을 수행한다고 할 수 있겠습니다.
