How-To와 Why의 중간에 서서...

IT 기술에서 엔지니어 생활을 하다보면, 항상 어느 것을 먼저해야 할지에 대해서 의문을 가졌던 경우가 많습니다. A를 하려고 하다보면, B를 조금 해야할 것 같고, B를 하다보면, C를 해야 할 것 같고... 이것저것 많이 부딪혀는 보지만, 빠른 시일안에 어떤 스킬 레벨을 얻는 것은 매우 어려운 일이라고 생각합니다.

엔지니어 분들을 만나뵈면, 크게 2가지의 성향을 볼 수 있습니다.

1. How-To에 능숙하신 분..
2. Why에 능숙하신 분..

물론 2가지를 다 잘하시는 분들도 많이 계십니다. 현업에서 만나는 많은 문제들은 How-To로 많이 해결할 수 있습니다. Why에 대한 비중보다는 How-To에 더 집중할 수밖에 없는 것도 이러한 이유입니다.

"Exchange Server를 설치해서, 메시징 시스템을 구축해주세요." 라는 요청 사항이 "Exchange Server의 SMTP가 어떠한 방식으로 동작하나요?"라는 질문보다는 분명히 많을 것입니다. 예전보다 지금은 그렇지 않다라고 말씀하실 수 있습니다. 네. 맞습니다. 옛날보다, 고객이나 엔지니어 분들께서 방법론 - Why -에 많이 옮겨져가고 있습니다.

어떠한 기술을 자기 자신이 만든다고 가정하면... 분명히 이유가 있어서 만들 것이고, 이러한 이유를 해결하기 위한 구조를 설계할 것입니다. 이 구조에 따라.. 동작 방식이 결정되겠죠.. Why, What, How-To로 이어지는 구조입니다. 기술을 습득할 때도 가장 이상적인 접근 방식이라고 봅니다. 왜 이런 기술이 나왔을까, 어떻게 작동할까, 어떻게 사용할 수 있을까...

IT 업무의 상당 수는 트러블슈팅 업무입니다. 트러블슈팅의 기본 원칙 중 하나는 기본에 충실하자는 것입니다. 당연히 그렇지 않을 것이다라고 가정하는 것들이.. 결론에 도달해보면.. 원인인 경우도 많습니다. 그 중 우스개 소리로 잘 나오는 것이 전원 빠진 장비를 고치려고 했다..입니다.

어제 한 엔지니어 분을 만났습니다. 그분은 본인만의 처리 방식을 가지고 계시더군요.. 그분은 누가 뭐라고 해도, 시간이 부족하더라도.. 최대한 본인만의 방법에 충실하려고 한다라는 말씀을 하셨습니다.

IT 기술에 접근하는 방식에는 정답이 없다고 생각합니다. 본인만의 방식을 만들되, 분명한건 왜?라는 것부터 생각해보는 것이 좋을 듯 싶습니다.

Windows Server 2008, Office Communicaion Server 2007, SQL 2008등.. 많은 새로운 제품이 출시를 앞두고 있습니다. 새로운 기술이 나올 때마다, 엔지니어, 강사, 전문가 분들의 공통된 말씀은 또 공부해야 하나라는 것입니다. 그렇지만, 이들이 이러한 기술을 습득하는 속도는 많은 차이를 보입니다. 이 때 중요한 요소가 바로.. 원리에 대한 충실한 이해...를 하신 상태였느냐, 아니냐라는 것입니다. 분명히 업그레이드된 이유가 있을 것이고, 이를 통해 어떠한 가치을 얻으려고 했는가 라는 생각을 한번 해보면, 조금은 밝게 해당 기술이 이해되기 시작할 것입니다.

Why, What, How-To에 적절한 문서가 바로 해당 기술의 ReadMe나 Release Note에 잘 나와 있습니다. 결국 기술을 개발한 팀에서 이걸 왜 개발했는지에 대해 명확한 이유를 제시해주기 때문이죠.

오후 들어 문득, 어제 만나뵌 엔지니어 분의 이야기가 생각나서, 블로그에 제 나름의 생각을 적어보았습니다.

여러분들께선 어떻게 생각하시나요?

시간이 되면 T자형 엔지니어에 대해서도.. 한번 이야기를 나눠볼까요?