이해어휘와 활용어휘 - 소프트웨어 아키텍트가 시스템을 바라보는 입장

눈으로 스쳐지나가는 어휘를 시각적 어휘(Sight Vocabulary)라고 한다. 이 시각적 어휘들은 읽는 순간 머릿속을 스쳐지나가며, 반복적인 단어가 나올 때마다 점차 머릿속에 이해가 되는데 이런 이해된 어휘들을 우리는 비로소 활용할 수 있는 것이다. 다시 말해서, 읽으면서 문맥 속에서 어렴풋이 이해할 수 있는 어휘를 '이해어휘'라고 할 수 있고, 몸에 체득이 되어 이를 자유자재로 쓸 수 있는 어휘를 '활용어휘'라고 할 수 있다. (신규철, 한국인을 위한 자동화 영어학습법, 경진문화사)

위의 글에서 보듯이 이해어휘는 단어를 보면 명확하게 정의를 내릴 수는 없지만, 앞 뒤 문맥상으로 전체적으로 이해하는데 큰 무리가 없는 것을 의미합니다. 예를 들어, '스마트폰'이라는 단어를 접했을 때, 처음에는 무슨 의미인지, 혹은 어떤 기능을 하는 전화기인지를 모르다가, (아마 기사나 책에서 이 단어를 처음 접했을 때에는 사전을 찾기도, 인터넷을 검색하기도 어려웠을 것이고, 정의가 되어 있다고 하더라도 그 내용 역시 파악하기 힘들 것입니다.) 대략적으로 '스마트폰'이 가지는 여러가지 기능과 활용에 대한 글을 읽고 나서야 '스마트폰'이 무엇인지를 알게 됩니다. 이 단어를 다음에 또 접하게 되면 이전에 이해했던 수준보다는 좀 더 깊이 이해를 하게 됩니다. 만일 '스마트폰'이라는 단어를 전문적으로 사용하는 입장에 놓이게 되면, 이제는 '스마트폰'에 대한 정의를 나름대로 할 수 있게 될 것입니다.

소프트웨어 아키텍트 역시 시스템을 구성하는 수많은 요소들을 파악하고 식별하게 되는데, 때로는 아키텍트가 직접 경험하지 못했거나 잘 모르게 되는 요소(애플리케이션, 패키지, 솔루션 등등)를 접할 수도 있습니다. 처음에는 이러한 요소가 무엇을 하고 어떤 기능을 하는지를 잘 모릅니다. 다만, 전체적인 시스템 구성 중에서 어디에 위치하고 어떤 역할을 한다 정도만을 이해할 뿐입니다. 이 수준의 요소를 소프트웨어 아키텍트의 입장에서 '이해어휘'라고 할 수 있습니다. 이해어휘는 그러한 단어를 많이 접하면 접할수록 그만큼 이해도가 높아집니다. 소프트웨어 아키텍트가 시스템을 구성하는 요소를 이해하는 수준은 굳이 아키텍트가 아니더라도 경험이 많은 사람도 충분히 이해를 하게 됩니다.

그럼, 이와 같이 경험이 많아서 이해하는 사람과 소프트웨어 아키텍트의 차이는 무엇일까요? 바로 '활용어휘'입니다. 활용어휘는그 단어에 대해서 보편적으로 타당한 정의를 내릴 수가 있어야 합니다. 즉, 자신만의 정의가 아닌 누구나가 공감하고 이해할 수 있는 수준으로 정의를 하고, 적절한 시점과 위치에서 이를 사용할 수 있어야 합니다. 소프트웨어 아키텍트는 시스템을 구성하는 요소들을 이해하는 수준을 넘어서 활용할 수 있는 수준까지 도달해야 합니다. 자신이 직접 경험하지 못했으면, 간접 경험을 통해서라도 (서적이나 참고 자료 등을 통해) 그 본질을 이해하고 해당 시스템 내에서 어떻게 활용할지를 정의해야 합니다.

'스마트폰'에 대한 구조나 아키텍처, 관련 기술을 잘 모르는 상태에서 단순히 이해한다고 소프트웨어 아키텍처에 적용해서는 큰 낭패를 당할 수도 있습니다. 한번 결정된 설계는 (특히, 소프트웨어 아키텍처라면) 나중에 바꾸는 것이 새로 만드는 것보다 더 어려워질 수도 있습니다. '스마트폰' 프로그램은 짜본 경험은 없지만, 간단하게나마 직접 돌려보고, 관련 참고 자료 등을 조사해보고, 다양한 대안 기술들을 찾아본 후에 실제 아키텍처에 적용했을 때 영향을 받는 부분과 효과를 볼 수 있는 측면들을 면밀히 알아야 합니다. 이는 '스마트폰' 기술을 활용하는 차원입니다. 그냥 단순히 그림 몇장에 그려서는 맛볼 수 없는 영역입니다. 아무리 '스마트폰'에 대한 이해도가 깊다고 이에 대한 활용을 잘 한다고 볼 수 없습니다. 코드 한줄 만들지 않는 아키텍트에게는 시스템을 이해하기만 한다면 된다는 논리로 경험과 이력을 내세우지만, 이러한 부분이 실제 운영되는 시스템의 소프트웨어 아키텍처를 보장하지 못합니다.

정말 소프트웨어 아키텍트가 되고 싶다면, 지금 즉시 시스템의 요소들을 하나 하나씩 정의를 내리고, 이들의 역할과 책임을 규정하십시오. 그리고, 이들 간의 관계가 어떻게 맺어지고, 어떠한 원칙이 발견 혹은 적용할 수 있는지를 고민하고 정리해보십시오. 소프트웨어 아키텍트가 이러한 부분들을 결정하지 못한다면, 그 어느 누구도 결정하지 못합니다. 아니, 이를 정의하고 정리할 수 있는 사람이 소프트웨어 아키텍트가 될 자격이 충분합니다. 소프트웨어 아키텍트에게 목표 시스템은 '활용어휘'이지 '이해어휘'로 만족해서는 안됩니다.