brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Sep 06. 2024

설계를 번역이라 한다면...

설계: 생각을 ‘차려’ 물질로 만드는 힘

이 글은 <설계란 결국 번역인가?>의 후속글로 '계산의 차원과 분별을 구조화하는 관점'에 대해 풀어 봅니다.


계산의 차원과 분별을 구조화하는 관점

먼저 지난 글에도 공유했던 이순석 님의 글을 다시 봅니다.

동일한 대상에 대한 분별할 수 있는 서로 다른 생각(인식)들의 가짓수로 정량화할 수 있다. 그런 분별은 세상을 읽는 차원을 기반으로 계산 가능하다.

저는 이를 두고 View model을 떠올렸습니다. 여기까지가 <설계란 결국 번역인가?>와 이 글을 이어주는 최소한의 줄거리입니다.

일단 추상적인 용어들에 대해 언급하겠습니다. 이순석 님이 쓴 글의 매듭말(=어구) 중에서 '분별할 수 있는 서로 다른 생각'은 그대로 View model의 View라고 할 수 있습니다. 그런데 사실 '분별할 수 있는 서로 다른 생각'을 Perspective에 대입해도 틀렸다고 할 수 없습니다.


챗GPT 말고도 퍼플랙서티에게도 묻다

인공지능들에게 둘 사이 차이점을 물었습니다.[1] 무료인 탓인지 제미나이는 답 대신 시스템 오류를 냈습니다. 병렬화 하니 좋네요. 왼쪽은 퍼플렉서티[2]의 답이고 오른쪽은 챗GPT 답입니다. 눈에 띄는 표현들은 표기를 해 보았는데, 독자님들도 감이 오셨나요?


Modeling perspectives란 무엇인가?

위키피디아 페이지를 들어가서 보니 perspective는 다시 Modeling perspectives라고 표기하고 있습니다.

Modeling perspectives is a set of different ways to represent pre-selected aspects of a system. Each perspective has a different focus, conceptualization, dedication and visualization of what the model is representing.

퍼플렉서티가 상대적으로 잘 요약했다고 할 수 있네요. 나도 모르게 둘 간의 평가를 하게 되었습니다. 다시 주제로 돌아가서 Modeling perspectives에 대해 정의한 별도 페이지에도 가 봅니다.

A modeling perspective in information systems is a particular way to represent pre-selected aspects of a system. Any perspective has a different focus, conceptualization, dedication and visualization of what the model is representing.

추상적인 설명 만으로는 감이 오지 않을 듯한데, 과거 한때 썼던 개발도구(IDE)인 이클립스에서 Perspective가 했던 기능에 대한 기억이 몸에 남아 있음을 느낍니다. 간단히 설명하면 Perspective 마다 다른 메뉴나 도구 상자를 제공하는 방식으로 Perspective를 구현했다 하겠습니다.


한국말 관점과 입장으로 일단락

지나치게 이론적으로 빠질 우려가 있어서 다시 앞서 인용한 그림으로 돌아가 보겠습니다. View는 관심사를 주제로 구분했다고 할 수 있습니다. 한국말로 바꾼다면 '관점'이 적당할 듯한데, 앞선 인공지능과 번역기가 모두 Perspective에 대해 관점이라고 하여 주저하게 됩니다. 반면 Perspective는 '추상화 수준'으로 표기하거나 추상화 수준을 역할에 대응시킨 것으로 '입장'이라고 부르는 편이 더 직관적이라 하겠습니다.

그러고 나서 각각의 칸 내용들이 계산 가능하게 표기될 수 있다면 다양한 차원의 번역 결과가 그려진다 하겠습니다. 참고로 '계산'이라는 말은 앞선 인용문에서 나온 것입니다.

동일한 대상에 대한 분별할 수 있는 서로 다른 생각(인식)들의 가짓수로 정량화할 수 있다. 그런 분별은 세상을 읽는 차원을 기반으로 계산 가능하다.


고객의 진짜 문제를 다룬 고객의 언어가 구현으로 흐르게 하는 설계

조금은 다른 측면에서 지금까지의 주장을 돌아보겠습니다. 우연히 발견한 페벗 님의 글이 있습니다.

문제해결의 첫 단계는 #진짜 문제를 #고객의언어로 정의하는 것입니다. (생각보다 제대로 하는 곳 많지 않습니다). 문제가 잘 정의되면 어쩌면 해결책은 빠르게 진행됩니다.

이 역시 추상화 수준이나 입장에 따라 다양한 차원에서 받아들일 수 있습니다. 다만, 과거 <도메인 스토리텔링 연구>에 담았던 내용을 떠올려 보면 고객이나 사용자의 언어를 쓰고 기록을 통해 확산하는 일은 번역의 일환이고 설계의 역할 범위에 들어간다고 하겠습니다.

고객의 진짜 문제가 고객의 언어 형태로 흘러들어 가서 상세 구현 수준에 제대로 도달할 수 있게 그 흐름을 만들어 주는 일이 설계라고 묘사한다면 꽤 유용하게 들립니다.


설계는 인간관계 속의 활동

비슷한 방식으로 글을 전개해 보겠습니다. 하지만, 전혀 다른 맥락으로 갑니다. 그의 책 <Tidy First?>에서 켄트 벡은 설계를 '인간관계 속의 활동'이라 말합니다. 최근 '한국 Tidy First 모임' 질문 중에 그 맥락에서의 논의가 있었습니다.

나의 행동이 다른 사람들에게 전달되고 그들은 모방하고 그렇게 전체적으로 퍼져가는 모습이겠지요. 저는 그런데 왜, 이런 밈화는 적어도 구성원들이 이 프로젝트에 애정을 가지고 있을 때라는 전제가 있어야만 한다는 생각이 들까요? 아니면 이런 경우에 어쩔 수 없이 설득이 들어가야 될까요.

이에 대한 저의 답변이 바로 설계가 '인간관계 속의 활동'이란 점에 대한 제 생각을 쓴 것에 가깝다고 생각합니다.

아주 좋은 질문이네요. 그런데 누군가를 애정이 있다 혹은 없다로 나누는 이분법은 많은 경우 해로운 판단인 경우가 많습니다. 일단 나와 그 사람을 실력 대결이나 승패 게임으로 몰아갈 수 있는 생각의 바탕이 만들어집니다.

그래서 이를 피하고 하는 방법으로 두 가지 방향이 가능하다 싶습니다. 하나는 코드나 프로덕트가 온전히 내 꺼라 느낄 때 취하는 방법인데… 바로 ‘농부의 마음’으로 상대를 바라보는 일입니다.
참고로 제가 '농부의 마음'에 대해 인터넷에 쓴 글이 4개 있습니다.

두 번째로 이와 달리 상대와 내가 조직 구성원일 뿐이라 전제할 때 접근이라면…
제가 ‘협상론적 세계관’이라 부르는 방법인데, 내가 원하는 대로 하기 위해 그에게 무엇을 해 줘야 하는지를 생각하며 해법을 찾는 방식이죠. 대개 사람들은 옳고 그름으로 문제를 풀려하는데 ‘가치’와 ‘신념’은 주관의 영역이라 그런 식의 설득은 대개 효과가 없다고 믿습니다. 하지만, 협상론적 세계관 실천은 저도 잘 못해서 배우는 중입니다. 익히면서 남긴 기록이 지금까지 8개 정도 있네요.

제가 하고픈 말이 전달이 되려나요? 늪으로 빠질 듯한 우려도 있습니다. 저는 인간관계 활동은 논리나 말로 작동하는 않는 부분이 있다는 점과 함께 그럼에도 불구하고 같은 것을 보고 논의할 수 있는 방법을 마련하는 일은 매우 중요하다는 사실을 주장하는 것입니다. 앞서 View model을 떠올린 것도 구체적인 방법론으로써가 아니라 입장과 관점별로 모두 비슷하게 볼 수 있는 상태에서 각자의 이해관계와 가치를 논의할 수 있어야 한다는 것이죠.


의사소통은 돌봄을 포함하는 행위

마지막으로 언어의 함정에 대한 전문가의 건해를 인용하는 것으로 글을 마치겠습니다. 페이스북에서 <미괄식이 '나쁜 구조'가 된 이유(?)>라는 글을 보고 깊은 인상을 받았습니다.

인간의 언어는 모호함으로 가득합니다. 상황 전체를 포착하지도, 화자의 의도를 완벽하게 전달하지도 못합니다. 의미는 항상 의도한 것과 이해한 것 사이 어딘가에서 표류합니다.

언어의 이러한 특성은 본질적으로 나쁜가요? 저는 그렇게 생각하지 않습니다. 해석의 여지를 남겨두는 것은 오해의 가능성을 포용하고 추가적인 협상의 여지를 열어두는 일을 수반합니다. 오해받을 수 있음으로 향해 있는 취약성을 지니고 있다는 것, 공동의 작업을 통한 의미를 부여하는 노동에 열려 있다는 것은 코드의 모든 줄을 정확하게 읽어내는 컴퓨터나 네트워크와 달리 인간을 인간답게 만듭니다. (물론 그렇다고 해서 일부러 오해의 여지를 남겨둘 필요는 없겠지만요.)

이런 의미에서 언어 교육자들은 효과적인 의사소통에 대한 강조와 오해에 대한 관용, 그리고 확장된 의사소통로 향하는 행위들 사이에서 균형을 잡아야 합니다. '쉬운 의사소통'이나 '완벽한 이해'와 같은 것은 존재하지 않습니다. 커뮤니케이터는 정보를 포장하여 상대방에게 전달하는 전달자가 아니라, 실수를 하고, 협상하고, 합의하고, 때로는 '함께 잊고 앞으로 나아가는' 의미의 공동 저자이면서 끊임없이 미끄러지는 신호를 공동으로 해석하는 협력자입니다.

따라서 정확성만을 지나치게 강조하는 것은 커뮤니케이션이 갖는 근본적인 한계로부터 벗어나려는 헛된 욕망의 징후입니다: 또한 '정확하고 생산적인 소통'이라는 신자유주의적 이상에 대한 무비판적인 지지를 나타냅니다. 깊은 소통, 즉 '꾜뮤-니-케이션'은 작디작은 용서들과 자신의 정체성을 실시간으로 재창조하는 고된 돌봄의 노동 없이는 이루어질 수 없습니다.

실수하는 것도 인간이고, '용서'하는 것도 인간입니다. 언어의 작동원리에 대한 무지와 인간의 일에 대한 방기의 축적은 자신의 기준에 맞추어 '정확하고' '논리적이게' 이야기하지 않는 사람을 견디지 못하는 사회를 만듭니다.

한편, 보자마자 너무나 공감했던 이미지가 있어 첨부합니다.


주석

[1] 제미나이(무료), 챗GPT, Perplextity Pro(이상 유로)에게 물었고, 사용한 프롬프트는 다음과 같습니다.

다음 URL의 내용을 읽고 View와 Perspective의 결정적 차이에 대해 설명과 예시를 할 수 있나요?

[다음] https://en.wikipedia.org/wiki/View_model[

[2] SKT 사용자에게 1년 무료 행사를 해서 어제부터 쓰고 있습니다.


지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재

1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?

2. 모델링 과정의 효용성과 모델링 결과의 쓰임새

3. 객체지향 분석설계 말고 객체지향 사고법

4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다

5. 프로그래밍의 다면적 특성

6. 비즈니스 소통에서 관심사의 분리와 일반화의 효과

7. Event Driven의 기원과 현실적인 활용 방법

8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법

9. 이제 UML은 극소수 개발자만 쓰는가?

10. 업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것

11. 자기중심에서 팀 중심으로 확대하기

12. 평면적 데이터를 구조화하고 묻따풀로 설계하기

13. 프로그래밍에서는 몰라도 설계에서 작명은 엄청 중요하다

14. 설계란 결국 번역인가?

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari