코딩을 하면서 한 번은 변수를 선언할 때 “정의되지 않은 값”이란 말이 들어오면 눈이 찌푸려지는 경험이 있었다. 그때마다 ‘값’이라는 개념이 단순히 메모리 상에 저장된 바이트를 넘어, 의미와 맥락을 갖는 것이 중요하다는 사실을 깨닫게 된다.
최근 DOGE 스태프가 DEI(다양성·공정성·포용성) 자금을 검증하려다 ‘DEI’라는 용어의 정의에 어려움을 겪은 사례를 보며, 같은 맥락이 기술 세계에서도 반복되고 있다는 점을 느꼈다. 개발자는 언어와 프레임워크가 바뀌어도 코드를 이해하고 재사용하는 데 필요한 규칙을 세우는 법을 익히지만, 사회적 개념의 ‘정의’는 정해진 문법이 없기에 혼란스러울 수 있다.
DEI와 같은 용어는 조직 문화나 정책에서 중요한 지표가 되며, 그 정의를 명확히 하려면 다양한 이해관계자의 시각을 반영해야 한다. 그러나 실제로는 ‘다양성’이 인종·성별·연령만을 의미하거나, ‘공정성’이 단순히 자원 배분의 균등으로 축소되는 경우가 많다. 이런 한정된 정의는 오히려 포용성을 저해하고, 소수자들이 진정한 참여를 느끼지 못하게 만든다.
개발자가 겪는 버그처럼, DEI 개념에서도 ‘버그’—즉, 모호함과 충돌이 존재한다. 이를 해결하려면 명세서를 작성하듯, 용어의 범위와 적용 방식을 문서화하고, 정기적으로 재검토하는 프로세스가 필요하다. 또한, 실제 현장에서 데이터와 피드백을 수집해 정의를 조정함으로써 ‘버그’를 최소화할 수 있다.
이러한 과정을 거치면 DEI는 단순한 트렌드 문구가 아니라 조직의 실질적 성장 엔진이 될 수 있다. 마찬가지로, 코드 베이스에서도 잘못 정의된 인터페이스는 시스템 전체를 위험에 빠뜨리지만, 명확하고 재사용 가능한 설계는 장기적인 안정성을 보장한다.
결국 우리는 기술과 사회가 서로 다른 ‘언어’를 쓰더라도, 그 언어의 의미를 끊임없이 다듬고 공유함으로써 더 나은 미래를 구축할 수 있다. 그리고 이 과정에서 가장 중요한 것은 단순히 정의를 만들고 끝내는 것이 아니라, 지속적으로 검증하고 수정해나가는 태도이다.
원문 링크: https://www.youtube.com/watch?v=WpbGF7l-t2w
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
