"데이터 기반으로 소통"의 의미 - 통제, 방임, 그리고 시스템화

최근 AI의 발달로, OpenClaw와 같은 새로운 프로젝트들이 속속들이 등장하고,
대단한 천재들이 새로운 규칙을 정의하기 위해 개발에 앞다투어 참여하고 있다.

 

그야말로, 프로그래밍에 대한 모든 규칙이 새로 쓰여지고 있는 시점이다.

 

다양한 매체에서 AI가 개발자를 대체한다고 대서특필하고 있고, 시대에 따라가지 못하는 것에 대한 불안함이 커지고 있다.
이에 대한 나의 생각을 정리해둔다.

---

하나가 되는 것과, 다름을 받아들이는 것

본 주제에 들어가기 앞서, 내 이야기를 조금만 해보려 한다.

 

나는 나에게 의미있는 일에만 시간을 투자하고 싶다.
이는 누구에게나 같은 욕망일 것이다.

 

아무래도 나이가 있어 자연스레 팀장 역할을 많이 받게 된 나는, 타인에게 내 주장을 강요하는 경우가 없잖아 있었다.
그 과정 내에서 최대한 데이터 기반으로 소통하기 위해 근거를 제시하지만, 어딘가 관계에 거리감이 발생하게 되는 것은 피할 수 없었다.

 

아마 그 원인은 둘 중 하나일 것이다.

• 상대방이 "데이터 기반 소통"에 익숙치 않아, 이것이 내 의견을 강요하는 것처럼 들렸거나,
• 내가 충분히 납득가능한 데이터를 제공해주지 못했거나.

우리는 자신에게 강제로 맞춰서 하나가 될 것을 강요받는 상황을 혐오한다.

"데이터 기반으로 소통"의 의미

책임의 할당 관점에서, 실무자와 관리자의 입장을 다뤄보려 한다.
책임의 부여는 "데이터에 기반"하여 동작한다.

• 지배
  • 실무자에게 충분한 데이터가 제공되지 않는다.
  • 그 대신, 모든 책임을 관리자가 지는 형태로 동작한다.
  • 실무자는 "자유"와 "아이디어"를 소거당한다.
• 방임
  • 겉으로는 "모든 역량을 자유롭게!"라는 좋은 의미처럼 들린다.
  • 그 과정에서, 관리자와의 충분한 상의 없이 실무자가 가진 데이터의 영역을 넘는 결정을 수행해야 한다.
  • 이는 "실무자"에게 과한 책임이 부여됨을 의미한다.

우리가 누군가에게 지배받고 싶지 않아 하지만, 그와 반대로 "방임"상태로 존재하는 것 또한 그리 좋아하지는않는다.
이는 혼자서 프로젝트의 모든 영역을 담당했을 때, 좋은 기억이 없는 우리의 경험에 기반할 수도 있고, 수학적 근거에 기반할 수도 있다.

 

하지만, 이 모두 직렬화된 책임이다.

 

참고로, 공학적으로 책임이 직렬화 되어 있는 형태는 프로젝트의 실패 확률을 높인다.
비정상 상태의 단일 지연은 프로젝트의 전체 실패 확률을 기하급수적으로 올리고, 만약 손실이 지연에 비례해 증가할 경우 손실 또한 기하급수적으로 증가하게 된다.
관련 내용은 대기행렬 이론 부분에서 확인 가능하다.

만약 이와 같이 책임 분배가 데이터 기반으로 이루어지지 않고 있다면, 피해야 하는 관계라고 생각한다.
물론 이를 상쇄할 만큼의 물리적 보상(돈/명예)이 충분히 이루어지고 있다면, 사람마다 선택은 다를 수 있겠다.

 

결국, 누구 한명에게 모든 책임을 부여하는 방법밖에 없을까?

 

하나의 조직이 되기 위해선, 다름을 받아들여야 한다.
각자가 일하는 방식이 다름을 알고, 알고 있는 지식/정보가 다름을 알며, 책임을 병렬로 분배해야 한다.

 

이는 이 글에서 내가 주장하는 사람 중심 직렬 책임에서 데이터 포함 병렬 책임으로의 변화를 의미한다.

 

이를 위해 "규범과 규칙"을 함께 정하고, 합의된 규칙에 맞춰서 하나가 되도록 만드는 것이다.

• 규율화(시스템화)
  • 결정권자와 실무자 사이에서 규칙을 정의한다.
  • 즉, 이 과정에서 책임은 "공통으로 참고한 데이터"가 병렬로 할당받게 된다.
  • 이 과정은 지식/데이터의 공유 이후, 양자 간의 "규칙으로의 책임 위임" 과정이 존재해야 가능하다.

자신의 똑똑함만 앞세우며 "나에게 맞춰라"라고 규칙을 강제하는 것은 "통제/규율화"가 아닌, "권력/지배"에 가깝다.
서로 필요한 만큼 데이터를 공유하고, 양자 간의 공개된 데이터 내에서, 규칙을 세우는 것이 중요하다.
이게 "방임"도 "지배"도 아닌, 내가 추구하는 "시스템화"이다.

---

팩트와 의견의 구분

자연스레 높은 자리에 있는 사람들은, 더 높은 임금을 받고, 더 많은 데이터를 제공받고, 더 큰 책임을 위임받는다.
따라서, 공개할 수 없는, 더 많은 데이터를 갖고 있기 때문에 "다소 독선적인" 선택을 하는 것처럼 보일 수 있다.
그래서 상사와 부하직원 간의 트러블은 피할 수 없다고 생각한다.

 

우리가 "따르고 싶은 좋은 상급자"는 이러한 데이터를 가능한 많이 공개해주는, 일의 맥락을 알려주는 상급자일 것이다.

 

하지만, 이것만은 분명히 하는 것이 좋다고 생각한다.

해당 발언이 "팩트"인가 "의견"인가?

 

우리는 직장생활을 하면서, 서비스를 더욱 발전시키고, 그와 함께 나 자신에 대한 발전을 도모하기도 한다.
하지만, 타인의 피드백을 무분별하게 받아들이면, 뚜렷한 기준없는 피드백에 방황하다 제대로 발전하지 못할 수 있다.
또한 내가 상급자라도, 나의 의견이 아랫사람에게 팩트로 들린다면, 이는 상당히 부담스러울 것이다.

 

이때 팩트와 의견을 구분할 것을 권장한다.

• 팩트
  • 데이터에 기반한 피드백
  • 합의된 규칙 내에서의 피드백
• 의견
  • 데이터 혹은 합의된 규칙 내에서 기반하지 않은 피드백

만약 팩트라면, 사실 그대로이므로, 논리 구조에 대한 결함을 의심하지 않아도 될 것이다.
하지만 만약 의견이라면, 논리 구조가 합당한지 논리적으로 검토할 것을 추천한다.

---

이렇게 생각을 정리하는 글을 작성하다 보면, 내 개인적으로도 여러 깨달음을 얻을 수 있다.

• 나의 경험을 "나의 경험"으로 두지 말고, 객관적인 수치화 데이터로 표현해, 상대방도 납득 가능하도록 만들 것.
• 항상 수치화된 테스트 기반을 마련할 것.

어떻게 보면 이와 같은 데이터 기반 의사소통은 다른 직종(기획/경영)에선 너무나 당연한 기본기다.

개발자도 거창한 코딩 기술이 아닌 한명의 "직원"인 만큼, 이제 한명의 직장인으로서의 기본기가 중요해진 시점이라고 생각한다.

 

그동안 AI와 같은 도구들이 정량적 분석 데이터가 없어 크게 관심이 없었는데, LLMOps와 같은 기법들의 등장으로 관심도가 올라가고 있다.
LLM에 대한 개발자들의 두려움 또한,"수치화되지 않은 LLM의 발전에 의해, 내가 할 수 있는 부분이 쥐도 새도 모르게 사라지지 않을까" 라는 걱정에 기인한 것이라고 생각하고 있다.
납득 가능한, 수치화된 데이터로 구성하기 위한 방법을 연구하다 보면, LLM의 발전도 두렵지 않을 것이라 생각한다.