이슈화, 이름 붙이기 그리고 개념과 설계의 관계

설계라는 묘한 활동, 드러나지 않는 결정 대상

지난 글 <설계라는 묘한 활동, 드러나지 않는 결정 대상>은 ‘이제 와서 화백의 중요성을 이해하다‘라는 이름으로 마쳤습니다.

독자님들 입장에서는 여전히 모호한 말이리라 생각합니다. 소화를 위해서 자르고 씹는 듯이 표현을 요리조리 바꿔 보기로 합니다. 일단, ‘화백’이 만들어내는 결과는 ‘이슈’라고 할 수도 있고 ‘개념’이라고 볼 수도 있고, 한편으로는 ‘작명’이라고 볼 수도 있습니다.

숨겨진 내용을 꺼내어 화제로 만드는 이슈화

최봉영 선생님께 배운 ‘낱말의 뜻을 깊고 넓게 묻고 따지는 일의 소중함‘을 실천하여 하나씩 꺼내 따져 보겠습니다. 먼저, 이슈Issue의 콜린스 사전 뜻입니다.

An issue is an important subject that people are arguing about or discussing.

한국말로 하면 ‘화제’에 해당할까요?

이어서 콜린스나 위키피디아 내용을 살펴보면 이야기꺼리를 잡지나 신문이 꺼내며 화제를 만드는 역할을 해 왔던 역사나 관행을 찾을 수 있습니다.

화백의 가치 중에 중요한 부분이 바로 이러한 ‘이슈화’자체입니다. 일부는 중요하게 생각하지만 어떤 이들을 쉬쉬할 수도 있습니다. 그러한 문제가 공동의 비전이나 프로젝트에서 중요한 문제라면 공론화하기 위해 드러내야 합니다.

이름을 안다는 것 혹은 이름을 붙인다는 것은 어떤 의미인가?

두 번째는 개념인데, 무거운 느낌이 들어서 순서를 바꾸겠습니다. 먼저 ‘작명’ 즉, ‘이름 짓기’를 따져 보겠습니다. 얼마 전에 읽을 책에서 ‘김춘수의 꽃’을 인용하며 이름 짓는 일의 중요성을 다룬 글이 떠오릅니다. 어떤 책이었을까요?

찾았습니다. 김기석 목사님이 쓰신 <고백의 언어들>에 ‘이름을 안다는 것’이란 제목의 내용이었습니다. 제가 책에서 밑줄 친 내용을 살펴보았습니다. 다음 다발말[1]을 읽을 당시는 목사님이 말하는 ‘젊은이들’과 제가 같다고 느꼈습니다.

젊은이들 가운데서 꽃 이름을 아는 이를 찾아보기가 어려웠습니다. 세상에서 명멸하는 정보에는 민감하게 반응하면서 우리 산야에 피어나는 꽃들에 대해 무관심한 것이 참 안타까웠습니다.

하지만, 이 글을 쓰며 인용할 때는 다릅니다. 컨설턴트를 하면 프로젝트 초기 이슈화의 중요성을 누구보다도 잘 아는 제 입장에서 앞서 언급한 화백의 중요성과 연결되어 전혀 다른 맥락에서 쓰인 글이 재해석되었습니다. 이름을 모른다는 말은 존재를 모른다는 말이라는 점입니다. 이슈화는 곧 존재를 알게 이름을 부르는 행위입니다. 이름을 불러주면 관심이 없던 이웃(?)이 고개를 돌려 이름이 불린 대상을 보게 합니다. 책에 나오는 다음 문장은 바로 그러한 점에서 유사한 교훈을 선사합니다.

이름을 붙인다는 것은 또한 그 외적 대상과 관계가 시작되었음을 상징합니다.

개념은 생각과 믿음의 기초가 되는 인지 활동의 주요 재료

자, 이번에는 개념이란 말을 묻고 따져 봅니다.

마침 이 글을 쓸 때 읽고 있던 뜻밖의 책에서 개념에 대한 설명을 발견합니다.

쌀가게 주인이 일단 됫박에 쌀을 가득 담습니다. 어떤 도구를 가져와 됫박 위로 솟아오른 부분을 싹 깎아냅니다. 정확히 한 되가 되도록 깎아내는 그 도구를 가리켜 평미레 혹은 평목이라 부르는데 이것을 한자로 옮긴 것이 ‘평미레 개입니다. ‘개념, ‘개론’ 할 때의 그 ‘개’입니다. 개념의 일반적인 의미는 “여러 관념 속에서 공통 요소를 추상하여 종합한 하나의 관념”입니다. 공통 요소를 추리는 것이므로 개별적인 것, 독특한 것은 잘려나가게 마련입니다.

<고백의 언어들> 93쪽에서 만난 내용들입니다.

영어로는 ‘Concept‘입니다.

역시 <고백의 언어들> 93쪽에서 만난 내용을 추가로 인용합니다.

개념을 뜻하는 영어 단어 concept’는 무언가를 꽉 움켜쥐는 것입니다. 독일어로 ‘Begrif’라 하는데 움켜쥔다는 의미의 동사 ‘begreifen’에서 나온 말입니다. 개념은 보편적인 것만 남기고 남은 부분은 깎아내는 것입니다.

시스템 기획/구축 프로젝트에서 아키텍트(?)의 역할

제가 화백의 중요성이라 인정했던 부분은 제가 IT컨설턴트이자 설계자로 일할 때도 가장 중요하게 생각했던 업무였습니다. 프로젝트 초기에 이슈화하여 공론화를 이끌고, 적절한 이해 관계자에게 정보가 흐르게 해서 해결책을 조직적으로 찾게 하는 것이죠.

그리고, 그 결과가 나오는 과정에서 연관이 있는 개념들을 연결합니다. 그러다 보면 구조가 잡히고 ‘컨설턴트 등장 이전에는’ 상관 없어 보이던 것들이 연결되는 모습을 보면, 함께 일하는 분들이 그들의 효능감을 느끼는 것이죠. 그렇게 직업적 생존과 명성을 얻어갔던 과거 경험을 되새김질 합니다. 그걸 자랑(?)하려는 것은 아니고요. 그러한 가치 인정을 어떤 관저에서 보느냐에 따라 ‘시스템 기획자’에 방점이 찍히면 ‘화백’이 됩니다. 반면에 설계와 더불어 구현이 제대로 돌아가도록 가교 역할을 하는 사람들을 대개 ‘아키텍트’라고 불러온 듯합니다.

하지만, 이는 외주 개발을 전제로 한 역할 이름에 가까웠습니다. 아키텍트란 이름이 꼭 외주 개발에서만 쓰이지는 않지만 그간의 이력 때문에 그러한 직무를 맡은 이들의 높은 몸값을 감당하려면 다수 프로젝트에 투입해야 하니 외주 개발에 잘 어울리는 이름입니다. 그런데, 디지털 전환 시대에는 내부 개발 역량이 필수적입니다.

그래서, 2017년에 <이제 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐>이란 글을 쓴 바 있죠. 하지만, 직함이 중요한 것이 아닙니다. 결국 소프트웨어 설계란 일이 조직이 커지는 순간 코드에 바로 대응되지 않을 수도 있고, 다수의 개발자가 코드를 작성한다고 하면 그들 모두가 의사소통에 능한 것은 아니기 때문에 이런 문제를 포착해 이슈화 하고, 이름을 짓고, 개념을 구축해 소통하는 사람이 필요한 것이죠.

어떤 조직이건 그 문제를 우리 조직에서는 누가 하고 있으며 지금 최선인가 물을 필요가 있습니다.

주석

[1] 왜 다발말인지는 <언어에 대한 일반이론>에서 일부 답을 얻을 수 있습니다.