문맥
범주 사이에서 일어나는 상호 작용에 관한 인지적 표상. 예를 들어 ‘소년’, ‘양동이’, ‘모래성, ‘삽’ 따위의 사물로 “소년이 삽과 양동이로 모래성을 만든다.”라는 문장을 생각할 때, ‘모래성 쌓기’가 이것에 해당한다.

맥락
사물 따위가 서로 이어져 있는 관계나 연관.

- 우리말샘


콘텍스트(Context)를 우리말로 변환하면 문맥 또는 맥락이다. 하지만 실질적으로는 언어적인 부분으로만 한정짓지 않는다. 언어적인 부분 뿐만 아니라 사람, 물건, 장소, 시간 등 각종 환경 요소들을 고려한 현재 상황이라고 이해하는게 좋겠다. 그리고 그 현재 상황이 앞으로의 상황을 만들기도 한다. 즉, 어떻게 본다면 시간에 따라 계속 흘러가며 상태를 계속 변경시키는 것이라고 볼수도 있다. 이해가 되는 듯 하면서도 이해가 잘 안되는 듯한 느낌이다.

이 콘텍스트라는 개념은 여러 분야에서 활용되고 있다. 기본적으로는 각종 글, 광고가 속해 있는 마케팅, 제품, UX, 그리고 각종 IT 분야 등이다. 심지어 각 개개인에도 100% 활용되고 있다.

나는 이 콘텍스트에 대해 무엇을 말하고 싶은 것일까? 나의 목적은 단순하다. 이 콘텍스트를 이해함으로서 내가 하고 있는 일이나 다른 사람과 상호작용하는 것에 대해 더 올바르게 접근할 수 있다는 것을 말하고 싶다.

개발자로서 코드를 작성할 때, 타 팀과 협업을 할 때, 나와 생각이 다른 멤버나 상위 조직장과 이야기 할 때, 그리고 심지어 면접관으로서 면접자와 대화시 또는 그 반대의 상황에서도 이 콘텍스트를 이해하는가 아닌가에 따라 앞으로의 상황이 많이 달라진다.


먼저 개발할때를 예를 들어보자. 여기서의 개발자는 매우 단순한 개발자임을 가정해 본다. 그리고 극단적인 상황임을 더 가정한다.

이 개발자가 개발을 하다가 역사가 오래된 코드를 접했다. 이 개발자는 아래와 같이 생각한다.

“이런 엉터리 같은 코드는 왜 있지?”

개발자는 이런 엉터리 같은 코드를 보고 난 뒤 개발자로서의 자존심이 허락하지 않아 자신있게 수정하였고 그리고 역시 자신있게 운영환경에 배포하였다. 그런 후 몇일 뒤 이로인한 몇가지 장애를 경험했다. 결과론적으로 겉으로는 엉터리 코드 같지만 구동에는 엉터리 코드가 아닌 것이다. 이런 경험을 한 개발자는 커밋 로그를 뒤집기 시작한다. 커밋 로그를 훑어보다 보니 왜 이런 코드가 만들어졌는지를 이해했다. 그런 후 이 개발자는 다른 개발자들도 이 이유를 명확히 알 수 있도록 하기 위한 방법을 고심하였다. 개발자는 그 여러가지 방법 중 하나인 코멘트를 활용하는 방법을 선택했고, 그 역사에 대한 것과 전면적으로 수정하지 않을 것이라면 이 코드를 보존해야 하는 이유를 코멘트로 작성한 후 커밋하였다.

이 부분이 개발 하는 과정에서 쉽게 겪을 수 있는 콘텍스트 누락의 예이다. 위 사례에서는 개발자가 피상적인 코드의 단면만을 보았고 그 코드가 만들어진 전체적인 맥락을 이해하려고 하지 않았다. 만약 그 맥락을 이해했다면 안좋은 상황을 피했을 것이다. 아무튼 그 상황을 겪은 후 그 코드의 콘텍스트를 이해하였고 결국 그 콘텍스트를 지속적으로 유지하기 위해 여러가지 방법 중 하나인 코멘트를 남기는 것을 선택했다. 결국 이 코멘트를 통해 코드가 가지고 있는 콘텍스트는 미래의 특정 시간까지 어느정도 유지 될 것이다.

커뮤니케이션할 때도 중요하다. 협업하는 상대방과 이야기할 때 논의가 잘 진행 되지 않고 오히려 상호간 오해가 쌓여 감정이 격해지는 경우를 경험 할 수 있다. 또는 상대방이 내 상식으로는 전혀 용납될 수 없는 이야기만 계속 할 수도 있다. 이런 경우 자신이 경험한 것 기반으로만 대화를 계속 지속한다면 그 논의는 종료될 수 없다. 적어도 한 명은 상대방이 “왜 이런 이야기를 하는지”에 대해 먼저 이해하는 것이 필요하다. 그 기반에 따라 대화를 이어간다면 논의의 종착점은 더 가까워 질 수도 있다.

그리고 또 일하다 보면 상급자가 지시하는 사항들이 도통 이해가 되지 않을 때가 있을 것이다. 그때도 그 사람의 콘텍스트를 봐야 한다. 왜 그런 지시를 하는 것인지를 이해해야 한다. 이해가 안 되면 물어봐야 한다. 내가 느끼기에 정말 최악의 지시 사항들을 받았는데 이게 어떤 맥락에서 나왔는지를 이해하느냐 안 하느냐에 따라 내가 하는 업무의 퀄리티가 달라진다.

잘 아는 동료와의 대화가 아닌 상호간 전혀 모르는 사람과 대화할 때도 콘텍스트를 이애하기 위한 노력은 필요하다. 특히 그 중에서 면접 같은 경우가 가장 중요하다고 생각한다. 면접은 상호간 잘 알지 못하는 상태에서 그리고 정해진 시간내에서 그 동안 경험해왔던 그리고 각자 보유하고 있는 지식들을 최대한 공유하면서 상호간 확인하는 자리이다.

내가 경험하고 있는 이 소프트웨어 기술이라는 것은 100% 옳은 방향은 없지만 대다수 또는 대부분의 상황에 포용될 수 있는 옳은 방법은 있다. 기술 면접시 면접자가 과거 특정 기술에 대해 활용한 경험이 있는데 면접관 본인이 생각하는 100% 좋은 방향으로 활용하지 않았다고 과연 그 사람이 기술적으로 뛰어나지 않은 사람이라고 할 수 있을까? 그것에 대한 대답은 그 사람이 당시 어떤 상황에 놓여있는지를 봐야 한다. 그 상황에서 사용할 수 있는 최선의 방법일 수도 있기 때문이다. 그렇다면 그런 콘텍스트를 이해한 상황에서 다른 질문을 해볼 수 있다.

“만약 그때 당시 A가 구축되어 있었고 B도 사용한 시점이라면 어떻게 다시 해보시겠습니까?”

위 질문이 아니라 다음과 같은 질문을 한다면 콘텍스트 이해 없이 단순히 피상적인 답을 찾고 있다고 생각한다.

“그때 이렇게 했어야 하는거 아닐까요? 이렇게 진행했다면 더 좋은 결과가 있었을텐데요.”

그리고 “A를 사용한 경험이 있으시네요. B라는 것이 무엇인지 설명해 주시겠어요?” 라는 질문도 콘텍스트를 배제하는 질문이다. A를 사용했더라도 B는 사용하지 않을 수 있다. B를 확인해야겠다면 B를 사용했는지는 물어보는게 우선이고, B를 모른다면 그 사람이 보유하고 있는 콘텍스트 안에서 B를 쉽게 이해시키고 이를 활용한 다른 것을 설명할 수 있는지를 봐야 한다. 이는 상대방의 콘텍스트를 존중하고 이해하면서 그 사람의 능력을 추가로 확인할 수 있는 접근법이라고 생각한다.


다른 무엇보다도 콘텍스트를 이해하려 하고 그 자세를 지속해서 유지한다면 그 이후에 얻는 결과물은 기존과는 다를 것이다. 하지만 이게 쉽지가 않다. 위에서 말한 사람, 물건, 시간, 장소 등에 따라 조금씩 구축되고 있었던 그런 데이터들을 얻어야 이해하기 쉬울 텐데, 쉽게 얻을 수 있는 부분이 아니며 얻는 부분도 적다.

내가 느끼기엔 다행히도 개발과 관련된 부분은 다른 분야에 비해 쉽다고 생각한다. 하지만 다른 부분, 예로 커뮤니케이션 부분에서는 어렵다고 생각한다. 예로 상대방의 콘텍스트를 얻기 위해 여러 가지 질문들, 특히 상대방 입장으로서는 바보 같은 질문들을 할 수도 있는데 만약 상대방이 그런 의도를 이해하지 못할 경우 대화가 어긋나기 쉬울 것이다. 상대방은 “이건 너무나 당연한데 왜 이 사람은 계속 이런 질문들을 하는 것이지?”라고 생각할 것이고 결국 그 사람은 이후에는 나를 멍청하고 답답한 사람이라고 여겨 커뮤니케이션을 거부할 수도 있다.

하지만 위의 예는 결국 극단적인 예시일 뿐이다. 콘텍스트를 이해하려고 노력한다면, 다양한 관점으로 정보를 파악할 수 있는 능력을 길러 줄 것이고 그에 따른 다양한 해결책과 앞으로 나아갈 방향성을 잡아줄 것으로 생각한다. 모든 부분에 대해 콘텍스트를 이해하려는 자세를 견지하는 게 좋지 않을까?

나와 가장 가까운 사람이 공부하느라 집에 늦게 오는데 그것을 알지 못하는 내가 “왜 늦게 다녀, 좀 일찍 좀 다녀”라고 말하기보다 “요새 왜 늦게 와? 무슨 일이 있어?”라는 질문으로 상대방의 콘텍스트를 먼저 이해하는 게 좋지 않을까.