.jpg)
IT 업계 내에서는 차별적인 용어들이 난무한다. 그런 상태로 IT는 다가오는 디지털 시대에 가장 영향을 많이 줄 수 있는 분야로 자리를 잡아가고 있다. 우리도 모르게 차별과 불용을 퍼트리고 있는지도 모른다. IT에서부터 바로잡아야 한다.
[보안뉴스 문정후 기자] IT/보안 업계에서 자주 사용되는 용어들 중 최근 몇 년 동안 “문제가 있다”고 지적되어 온 것들이 있다. 주인과 노예를 뜻하는 ‘마스터’와 ‘슬레이브’, 흑과 백에 옳고 그름이라는 느낌을 부여하는 ‘블랙리스트’와 ‘화이트리스트’, 지나치게 과격한 용어인 ‘종료(kill : 살해하다)’, ‘비활성화(disable : 장애인으로 만들다)’, ‘중단(abort : 낙태시키다)’ 등이 바로 그것이다(역주 : 한국말로 번역했을 때는 조금 순화되는 감이 있다).
이런 용어들은 여러 차례 지적을 받아왔지만 실제 변화를 도입하려는 노력은 거의 없었다. 게다가 이런 용어들이 문제라는 데에 모두가 동의하는 것도 아니며, 각종 코드베이스, 문서, 리포지터리 등에서 이런 용어들을 전부 찾아내 삭제하거나 대체시키는 것은 무척이나 복잡하고 어려운 일이 될 것도 사실이다. 찾아냈다손 치더라도, 모두가 동의할 ‘대체 용어’가 업계 내에서 합의된 것도 아니다. 익숙한 용어를 바꾸라는 것 자체에도 이미 거부 반응이 나오고 있는데, 그 과정이 쉽지 않으니 다들 시큰둥할 수밖에 없다.
보다 포용적이며 다양성을 추구하는 용어가 필요하다는 지적은 어느 분야에서나 늘 있어 왔다. 하지만 정치적 혹은 사회적 운동이 대규모 일어나고, 전 세계적인 의식 수준 향상이 일어나지 않으면 좀처럼 바뀌지 않는 것이 용어이기도 하다. IT 내부에서 아무리 용어에 대한 연구를 해봐야 외부적인 압박이 있지 않으면 변화는 요원할 수밖에 없다. 다행히 최근 몇 년 동안 다양성과 평등, 포용에 대한 변화의 목소리가 전 세계적으로 커지고 있고, 여기에 기업 CEO들도 반응하기 시작했다. 어쩌면 IT 업계 내 문제시 됐던 용어들을 바꿀 기회가 지금인지도 모른다.
그렇다는 건 CIO들이 움직이기 시작해야 한다는 뜻이 된다. 기업 내에 사용되는 각종 IT 서비스들에 보다 포괄적인 용어, 비차별적인 용어를 활용한 이름을 붙이는 것부터 시작해 산업 전체로 서서히 확장시켜나가는 것이 자연스러울 것으로 예상된다. 사실 우리가 원하는 건 용어 그 자체가 아니다. 말 하나 바꿈으로써 야기되는 파장이다. IT 업계를 넘어서는 긍정적인 변화의 파장을 우리는 기대하고 있다. 차별의 뉘앙스가 없고, 좀 더 포괄적인 뜻을 가진 단어들을 좀 더 많이, 좀 더 자주 사용하다 보면 생각과 행동이 바뀔 수밖에 없기 때문이다.
포용적인 언어를 IT 업무 중에 활성화시키기 위해 CIO들이 할 수 있는 다섯 단계의 일을 다음과 같이 추천한다.
1단계 : CIO와 함께 언어 바꾸기 프로젝트를 진행할 태스크포스를 모집한다
연구된 바에 의하면 조직 내에서 ‘자원자’를 뽑는 것은 매우 조심스러운 일로, 예를 들어 CEO가 CIO를 통해 IT 팀원들을 ‘언어 바꾸기 프로젝트’에 합류하도록 동원할 경우 참석률은 꽤나 높아질 수 있지만, 이들이 마음을 다해 적극 참여할 가능성은 매우 낮아진다. 해야 하니까 이름은 올리지만 아이디어를 내거나 혁신을 꾀하지는 않을 거라는 뜻이다. 그러니 초기 참여자 수를 높이기 위해 태스크포스를 모집하는 건 장기적으로 도움이 되지 않는 일이다.
하지만 분명한 ‘인센티브’를 걸면 어떨까? 인사고과 점수에 반영한다거나, 특수 조건 달성 시 보너스를 준다거나 하는 등의 분명한 ‘당근’을 걸면 프로젝트에 임하는 참여자들의 태도와 적극성이 달라진다. 예를 들어 CIO가 “IT 서비스 전체에 차별적이지 않은 언어를 도입한다”는 목표를 내걸고 입에 착착 붙는 용어를 고안한 사람에게 인사고과 점수 몇 점을 부여한다고 하면 꽤나 많은 아이디어들이 나올 것이다.
또 하나 기억해야 할 건 태스크포스 팀 구성원들을 다양하게 모집해야 한다는 것이다. IT 용어를 바꾼다고 해서 IT 팀원들로만 구성하는 건 좋지 않고, 각 사업부에서 다양한 사람들을 선택하는 게 더 나은 결과를 나을 것이다. 또한 프로젝트 최소 참여 기간을 상호 간에 약속해 두는 것이 좋다. 최소 12개월을 권한다.
2단계 : IT 용어 평가를 위한 프레임워크를 설계하라
언어는 문화와 매우 비슷하여 복잡하며, 끊임없이 변화한다. 그렇기 때문에 우리는 같은 상황에서 같은 뜻의 같은 단어를 사용하고 있다고 생각하지만, 자세히 들여다보면 우리는 같은 단어 안에 꽤나 다른 뜻과 뉘앙스를 담아 사용할 때가 종종 있다. 비단 IT 업계 내에서만의 이야기가 아니다. 게다가 같은 제스처, 같은 단어, 같은 뜻이더라도 어떤 문화권이냐에 따라 전혀 다른 반응을 이끌어낸다. 그러므로 태스크포스 팀은 다양한 각도로 용어들을 평가할 수 있어야 한다.
이러한 프로젝트를 처음 이끄는 CIO라면 ‘다각도로 용어를 평가하고 정립한다’는 것 자체가 막대한 부담감으로 와 닿을 수 있는데, 그럴 때 차용하면 좋은 것들이 바로 기존 프레임워크들이다. 큐버네티스(Kubernetes)의 네이밍 워킹그룹(Naming Working Group) 혹은 인클루시브 네이밍 이니셔티브(Inclusive Naming Initiative : https://inclusivenaming.org/language/evaluation-framework/)가 바로 그것이다.
이 프레임워크는 용어들을 ‘게이트(Gate)’라는 시스템으로 평가하는데, ‘게이트 1’이 가장 엄격한 기준을 가지고 있다. 블랙리스트나 화이트리스트와 같은 단어는 게이트 1에서 탈락한다. 마스터와 슬레이브와 같은 단어도 게이트 1을 넘어갈 수 없다. 마셜(marshal)과 언마셜(unmarshal) 등은 게이트 2에서 걸린다. 노동 시간을 뜻하는 ‘맨아워(man hour)’는 게이트 3에서 탈락한다.
3단계 : 걸러낼 용어를 찾았으면 대체할 용어를 찾아야 한다
기존 용어를 평가할 프레임워크가 완성 혹은 선정되었다면 현재 IT 부서 내 혹은 업계 내에서 사용되는 용어들을 목록화 하여 평가할 차례다. 프레임워크에 따라 평가도 하고, 회사 전체를 대상으로 설문을 실시해도 괜찮다. 다양한 배경을 가진 다양한 사람들의 다양한 의견을 들어가며 무심코 썼던 단어들이 어떤 감정을 불러일으켰는지 혹은 어떠한 문제도 일으키지 않고 있는지를 알아내야 한다.
그렇게 문제가 될 만한 단어들을 골라낼 때, 아리송한 것들이 나타날 것이다. 문제가 될 것도 같고 안 될 것도 같고, 명확히 판단하기가 어려운 그런 용어들 말이다. 그럴 때는 ‘의심이 된다면 일단 교체’라는 생각으로 작업에 임하는 것이 좋다. 지금은 작은 씨앗에 불과해 문제가 느껴지지 않을지 몰라도 나중에 어떤 형태로든 그 용어의 부정적인 면모가 자라 악영향을 줄 수도 있기 때문이다. 너무 늦지 않게 짚어내 고치는 편이 언제나 바람직하다.
고쳐야 할 용어들을 파악하는 것도 쉽지 않았을 텐데, 그 용어들을 대체할 단어들을 찾는 것도 문제다. 여기서부터는 태스크포스 팀의 불꽃 튀는 브레인스토밍이 필요하다. 블랙리스트를 ‘블록리스트(blocklist)’로, 화이트리스트를 ‘얼라우리스트(allowlist)’로 바꾸는 과정은 순탄치 않았던 것으로 알려져 있다. 반짝하며 순간 떠오르는 아이디어가 있을 수도 있지만 보통은 격렬한 회의를 통해 수많은 아이디어와 고민들이 쓰레기통에 들어가야 겨우 쓸만한 것 하나가 나온다.
이 때 인터넷 엔지니어링 태스크포스(Internet Engineering Task Force)가 제안한 ‘차별적 의미가 없는 용어들(https://github.com/ietf/terminology)’이나 미국심리학협회에서 만든 편견 없는 언어 가이드라인들(https://apastyle.apa.org/style-grammar-guidelines/bias-free-language)을 참고하는 것도 큰 도움이 될 수 있다. 그 외에 태스크포스 팀 바깥의 인원들에게서 아이디어를 구하는 것도 나쁘지 않은 방법이다. 가끔 의외의 인물에게서 의외의 해결책이 나올 때가 있다.
4단계 : 대체 용어들을 제대로 도입하라
이제 재료는 준비됐고, 용어들을 실제로 현장에 심어야 할 차례다. 여태까지도 그렇지만 이 번 과정도 대단히 복잡해질 수 있다. 전략적으로 접근해야 한다. 제일 먼저는 이미 사용되어 왔고, 그래서 코드베이스와 API와 각종 문건에 방대하게 남아 있는 용어들을 다 찾아내 대체할 것인지, 아니면 앞으로 만들어질 문서와 코드베이스와 API들부터 새 용어를 적용할 것인지를 결정해야 한다. 전자는 엄청난 노력을 들여야 하겠지만 큰 효과를 볼 수 있고 후자는 좀 더 자연스럽고 거부감이 덜하지만 변화가 조금 느리게 일어난다.
하지만 이런 전략은 일괄적으로 정하기 힘들 수 있다. 조직의 상황이 어떠하며, 어떤 성격을 가졌고, 바꾸려는 용어가 무엇인지에 따라 도입이 복잡해질 수도 있고 의외로 간단해질 수도 있다. 예를 들어 웹사이트나 문서에서 사용된 용어라면 ‘찾아 바꾸기’로 간단히 해결할 수 있다. 하지만 API 내 함수의 이름이라든가 설정 디렉토리 이름을 바꾸기로 했다면 문제가 꽤나 복잡해진다. 이는 기능 오류 및 취약점 발생의 리스크까지 떠안게 되는 작업이다. 그럴 때는 실험 환경을 마련하여 이름을 바꾼 후 일어날 수 있는 일들을 꼼꼼하게 점검하는 것부터 해야 한다. 또한 이런 변경에 대하여 사내 개발자들이나 IT 인력들과 외부 파트너사 및 서드파티 벤더들에게도 충분히 알려야 한다.
5단계 : 널리 알리기 위해 캠페인을 시작하라
차별적인 용어들은 IT 업계 내에서 수십 년 동안 사용되어 왔다. 그러므로 변화를 설득시키는 일은 이메일 몇 장으로 완수되기 힘들다. 유려한 문장과 단단한 논리로 읽는 사람들의 고개를 끄덕이게는 할 수 있을지는 모른다. 하지만 실제로 입 밖으로 튀어나오는 단어를 바꾸게 한다는 건 차원이 다른 노력을 필요로 한다. 사고방식과 행동양식 모두에 영향을 깊이 주는 일이란, 몇 마디 말이 아니라 장시간의 꾸준한 ‘본 보이기’를 통해서만 이뤄진다.
먼저는 ‘언어를 새롭게 하자’는 내용으로 캠페인을 꾸리고, 새 언어의 도입을 감독할 고문단을 공식적으로 마련할 것을 권장한다. 이전 단계들에서 태스크포스를 새롭게 꾸렸던 것처럼, IT 언어의 변화를 꾸준하게 주도적으로 이끌어갈 단체를 만들어야 실질적인 도입 과정을 뚝심 있게 이끌어갈 수 있다. 그렇다고 윗사람들로 고문단을 꾸려서 단어 하나하나 꼬투리 잡아가며 잔소리만 하게 하면 아무런 효과가 나타나지 않는다. 편견 없는 단어, 차별성 없는 용어가 변화를 이끈다는 것을 진정으로 믿는 사람들이 주도해야 한다. CIO라면 IT 회의 때마다 새로운 용어들을 설명하고 설득하고 제안할 수 있다. 이 때 ‘왜’를 중점적으로 설명하는 것이 중요하다.
이 모든 과정들은 전혀 순탄하지 않을 것이다. 원래 자기가 잘 사용하던 말에 문제가 있다고 하면 누구나 ‘버럭’할 수밖에 없다. 게다가 단어 하나 바꾸려고 하는 이 모든 노력들을 두고 헛수고라고 비웃는 사람도 분명히 나타날 것이다. 언어를 통해 이뤄지는 변화란 대부분 느리고 점진적으로 일어나기 때문이다. 이것이 정치적인 캠페인이라는 저항도 있을 수 있다. 이런 난관들을 극복하려면 ‘예상 반박 시나리오’를 잔뜩 마련하는 것이 좋다. 이런 저런 말이나 행동이 나올 것이라고 예상하고 있으면 실제 상황에서 덜 당황하게 된다. 그리고 최대한 상세하게 들어주고 답하는 자세가 필요하다. 교조적으로 접근하면 실패한다.
언어는 매우 강력한 도구다. IT는 최근, 그리고 앞으로 몇 년 간 인간의 모든 생활에 지대한 영향을 끼칠 분야다. 우리가 여기서부터 말을 바꾸기 시작하면 IT 기술 이상의 좋은 영향을 줄 수 있게 된다. 우리는 기술공으로 남을 것인가, 아니면 기술과 함께 좋은 문화까지도 함께 전달한 개척자 혹은 선구자가 될 것인가?
글 : 롭 오도노휴(Rob O'Donohue), 수석 분석가, 가트너
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] IT/보안 업계에서 자주 사용되는 용어들 중 최근 몇 년 동안 “문제가 있다”고 지적되어 온 것들이 있다. 주인과 노예를 뜻하는 ‘마스터’와 ‘슬레이브’, 흑과 백에 옳고 그름이라는 느낌을 부여하는 ‘블랙리스트’와 ‘화이트리스트’, 지나치게 과격한 용어인 ‘종료(kill : 살해하다)’, ‘비활성화(disable : 장애인으로 만들다)’, ‘중단(abort : 낙태시키다)’ 등이 바로 그것이다(역주 : 한국말로 번역했을 때는 조금 순화되는 감이 있다).
[이미지 = utoimage]
이런 용어들은 여러 차례 지적을 받아왔지만 실제 변화를 도입하려는 노력은 거의 없었다. 게다가 이런 용어들이 문제라는 데에 모두가 동의하는 것도 아니며, 각종 코드베이스, 문서, 리포지터리 등에서 이런 용어들을 전부 찾아내 삭제하거나 대체시키는 것은 무척이나 복잡하고 어려운 일이 될 것도 사실이다. 찾아냈다손 치더라도, 모두가 동의할 ‘대체 용어’가 업계 내에서 합의된 것도 아니다. 익숙한 용어를 바꾸라는 것 자체에도 이미 거부 반응이 나오고 있는데, 그 과정이 쉽지 않으니 다들 시큰둥할 수밖에 없다.
보다 포용적이며 다양성을 추구하는 용어가 필요하다는 지적은 어느 분야에서나 늘 있어 왔다. 하지만 정치적 혹은 사회적 운동이 대규모 일어나고, 전 세계적인 의식 수준 향상이 일어나지 않으면 좀처럼 바뀌지 않는 것이 용어이기도 하다. IT 내부에서 아무리 용어에 대한 연구를 해봐야 외부적인 압박이 있지 않으면 변화는 요원할 수밖에 없다. 다행히 최근 몇 년 동안 다양성과 평등, 포용에 대한 변화의 목소리가 전 세계적으로 커지고 있고, 여기에 기업 CEO들도 반응하기 시작했다. 어쩌면 IT 업계 내 문제시 됐던 용어들을 바꿀 기회가 지금인지도 모른다.
그렇다는 건 CIO들이 움직이기 시작해야 한다는 뜻이 된다. 기업 내에 사용되는 각종 IT 서비스들에 보다 포괄적인 용어, 비차별적인 용어를 활용한 이름을 붙이는 것부터 시작해 산업 전체로 서서히 확장시켜나가는 것이 자연스러울 것으로 예상된다. 사실 우리가 원하는 건 용어 그 자체가 아니다. 말 하나 바꿈으로써 야기되는 파장이다. IT 업계를 넘어서는 긍정적인 변화의 파장을 우리는 기대하고 있다. 차별의 뉘앙스가 없고, 좀 더 포괄적인 뜻을 가진 단어들을 좀 더 많이, 좀 더 자주 사용하다 보면 생각과 행동이 바뀔 수밖에 없기 때문이다.
포용적인 언어를 IT 업무 중에 활성화시키기 위해 CIO들이 할 수 있는 다섯 단계의 일을 다음과 같이 추천한다.
1단계 : CIO와 함께 언어 바꾸기 프로젝트를 진행할 태스크포스를 모집한다
연구된 바에 의하면 조직 내에서 ‘자원자’를 뽑는 것은 매우 조심스러운 일로, 예를 들어 CEO가 CIO를 통해 IT 팀원들을 ‘언어 바꾸기 프로젝트’에 합류하도록 동원할 경우 참석률은 꽤나 높아질 수 있지만, 이들이 마음을 다해 적극 참여할 가능성은 매우 낮아진다. 해야 하니까 이름은 올리지만 아이디어를 내거나 혁신을 꾀하지는 않을 거라는 뜻이다. 그러니 초기 참여자 수를 높이기 위해 태스크포스를 모집하는 건 장기적으로 도움이 되지 않는 일이다.
하지만 분명한 ‘인센티브’를 걸면 어떨까? 인사고과 점수에 반영한다거나, 특수 조건 달성 시 보너스를 준다거나 하는 등의 분명한 ‘당근’을 걸면 프로젝트에 임하는 참여자들의 태도와 적극성이 달라진다. 예를 들어 CIO가 “IT 서비스 전체에 차별적이지 않은 언어를 도입한다”는 목표를 내걸고 입에 착착 붙는 용어를 고안한 사람에게 인사고과 점수 몇 점을 부여한다고 하면 꽤나 많은 아이디어들이 나올 것이다.
또 하나 기억해야 할 건 태스크포스 팀 구성원들을 다양하게 모집해야 한다는 것이다. IT 용어를 바꾼다고 해서 IT 팀원들로만 구성하는 건 좋지 않고, 각 사업부에서 다양한 사람들을 선택하는 게 더 나은 결과를 나을 것이다. 또한 프로젝트 최소 참여 기간을 상호 간에 약속해 두는 것이 좋다. 최소 12개월을 권한다.
2단계 : IT 용어 평가를 위한 프레임워크를 설계하라
언어는 문화와 매우 비슷하여 복잡하며, 끊임없이 변화한다. 그렇기 때문에 우리는 같은 상황에서 같은 뜻의 같은 단어를 사용하고 있다고 생각하지만, 자세히 들여다보면 우리는 같은 단어 안에 꽤나 다른 뜻과 뉘앙스를 담아 사용할 때가 종종 있다. 비단 IT 업계 내에서만의 이야기가 아니다. 게다가 같은 제스처, 같은 단어, 같은 뜻이더라도 어떤 문화권이냐에 따라 전혀 다른 반응을 이끌어낸다. 그러므로 태스크포스 팀은 다양한 각도로 용어들을 평가할 수 있어야 한다.
이러한 프로젝트를 처음 이끄는 CIO라면 ‘다각도로 용어를 평가하고 정립한다’는 것 자체가 막대한 부담감으로 와 닿을 수 있는데, 그럴 때 차용하면 좋은 것들이 바로 기존 프레임워크들이다. 큐버네티스(Kubernetes)의 네이밍 워킹그룹(Naming Working Group) 혹은 인클루시브 네이밍 이니셔티브(Inclusive Naming Initiative : https://inclusivenaming.org/language/evaluation-framework/)가 바로 그것이다.
이 프레임워크는 용어들을 ‘게이트(Gate)’라는 시스템으로 평가하는데, ‘게이트 1’이 가장 엄격한 기준을 가지고 있다. 블랙리스트나 화이트리스트와 같은 단어는 게이트 1에서 탈락한다. 마스터와 슬레이브와 같은 단어도 게이트 1을 넘어갈 수 없다. 마셜(marshal)과 언마셜(unmarshal) 등은 게이트 2에서 걸린다. 노동 시간을 뜻하는 ‘맨아워(man hour)’는 게이트 3에서 탈락한다.
3단계 : 걸러낼 용어를 찾았으면 대체할 용어를 찾아야 한다
기존 용어를 평가할 프레임워크가 완성 혹은 선정되었다면 현재 IT 부서 내 혹은 업계 내에서 사용되는 용어들을 목록화 하여 평가할 차례다. 프레임워크에 따라 평가도 하고, 회사 전체를 대상으로 설문을 실시해도 괜찮다. 다양한 배경을 가진 다양한 사람들의 다양한 의견을 들어가며 무심코 썼던 단어들이 어떤 감정을 불러일으켰는지 혹은 어떠한 문제도 일으키지 않고 있는지를 알아내야 한다.
그렇게 문제가 될 만한 단어들을 골라낼 때, 아리송한 것들이 나타날 것이다. 문제가 될 것도 같고 안 될 것도 같고, 명확히 판단하기가 어려운 그런 용어들 말이다. 그럴 때는 ‘의심이 된다면 일단 교체’라는 생각으로 작업에 임하는 것이 좋다. 지금은 작은 씨앗에 불과해 문제가 느껴지지 않을지 몰라도 나중에 어떤 형태로든 그 용어의 부정적인 면모가 자라 악영향을 줄 수도 있기 때문이다. 너무 늦지 않게 짚어내 고치는 편이 언제나 바람직하다.
고쳐야 할 용어들을 파악하는 것도 쉽지 않았을 텐데, 그 용어들을 대체할 단어들을 찾는 것도 문제다. 여기서부터는 태스크포스 팀의 불꽃 튀는 브레인스토밍이 필요하다. 블랙리스트를 ‘블록리스트(blocklist)’로, 화이트리스트를 ‘얼라우리스트(allowlist)’로 바꾸는 과정은 순탄치 않았던 것으로 알려져 있다. 반짝하며 순간 떠오르는 아이디어가 있을 수도 있지만 보통은 격렬한 회의를 통해 수많은 아이디어와 고민들이 쓰레기통에 들어가야 겨우 쓸만한 것 하나가 나온다.
이 때 인터넷 엔지니어링 태스크포스(Internet Engineering Task Force)가 제안한 ‘차별적 의미가 없는 용어들(https://github.com/ietf/terminology)’이나 미국심리학협회에서 만든 편견 없는 언어 가이드라인들(https://apastyle.apa.org/style-grammar-guidelines/bias-free-language)을 참고하는 것도 큰 도움이 될 수 있다. 그 외에 태스크포스 팀 바깥의 인원들에게서 아이디어를 구하는 것도 나쁘지 않은 방법이다. 가끔 의외의 인물에게서 의외의 해결책이 나올 때가 있다.
4단계 : 대체 용어들을 제대로 도입하라
이제 재료는 준비됐고, 용어들을 실제로 현장에 심어야 할 차례다. 여태까지도 그렇지만 이 번 과정도 대단히 복잡해질 수 있다. 전략적으로 접근해야 한다. 제일 먼저는 이미 사용되어 왔고, 그래서 코드베이스와 API와 각종 문건에 방대하게 남아 있는 용어들을 다 찾아내 대체할 것인지, 아니면 앞으로 만들어질 문서와 코드베이스와 API들부터 새 용어를 적용할 것인지를 결정해야 한다. 전자는 엄청난 노력을 들여야 하겠지만 큰 효과를 볼 수 있고 후자는 좀 더 자연스럽고 거부감이 덜하지만 변화가 조금 느리게 일어난다.
하지만 이런 전략은 일괄적으로 정하기 힘들 수 있다. 조직의 상황이 어떠하며, 어떤 성격을 가졌고, 바꾸려는 용어가 무엇인지에 따라 도입이 복잡해질 수도 있고 의외로 간단해질 수도 있다. 예를 들어 웹사이트나 문서에서 사용된 용어라면 ‘찾아 바꾸기’로 간단히 해결할 수 있다. 하지만 API 내 함수의 이름이라든가 설정 디렉토리 이름을 바꾸기로 했다면 문제가 꽤나 복잡해진다. 이는 기능 오류 및 취약점 발생의 리스크까지 떠안게 되는 작업이다. 그럴 때는 실험 환경을 마련하여 이름을 바꾼 후 일어날 수 있는 일들을 꼼꼼하게 점검하는 것부터 해야 한다. 또한 이런 변경에 대하여 사내 개발자들이나 IT 인력들과 외부 파트너사 및 서드파티 벤더들에게도 충분히 알려야 한다.
5단계 : 널리 알리기 위해 캠페인을 시작하라
차별적인 용어들은 IT 업계 내에서 수십 년 동안 사용되어 왔다. 그러므로 변화를 설득시키는 일은 이메일 몇 장으로 완수되기 힘들다. 유려한 문장과 단단한 논리로 읽는 사람들의 고개를 끄덕이게는 할 수 있을지는 모른다. 하지만 실제로 입 밖으로 튀어나오는 단어를 바꾸게 한다는 건 차원이 다른 노력을 필요로 한다. 사고방식과 행동양식 모두에 영향을 깊이 주는 일이란, 몇 마디 말이 아니라 장시간의 꾸준한 ‘본 보이기’를 통해서만 이뤄진다.
먼저는 ‘언어를 새롭게 하자’는 내용으로 캠페인을 꾸리고, 새 언어의 도입을 감독할 고문단을 공식적으로 마련할 것을 권장한다. 이전 단계들에서 태스크포스를 새롭게 꾸렸던 것처럼, IT 언어의 변화를 꾸준하게 주도적으로 이끌어갈 단체를 만들어야 실질적인 도입 과정을 뚝심 있게 이끌어갈 수 있다. 그렇다고 윗사람들로 고문단을 꾸려서 단어 하나하나 꼬투리 잡아가며 잔소리만 하게 하면 아무런 효과가 나타나지 않는다. 편견 없는 단어, 차별성 없는 용어가 변화를 이끈다는 것을 진정으로 믿는 사람들이 주도해야 한다. CIO라면 IT 회의 때마다 새로운 용어들을 설명하고 설득하고 제안할 수 있다. 이 때 ‘왜’를 중점적으로 설명하는 것이 중요하다.
이 모든 과정들은 전혀 순탄하지 않을 것이다. 원래 자기가 잘 사용하던 말에 문제가 있다고 하면 누구나 ‘버럭’할 수밖에 없다. 게다가 단어 하나 바꾸려고 하는 이 모든 노력들을 두고 헛수고라고 비웃는 사람도 분명히 나타날 것이다. 언어를 통해 이뤄지는 변화란 대부분 느리고 점진적으로 일어나기 때문이다. 이것이 정치적인 캠페인이라는 저항도 있을 수 있다. 이런 난관들을 극복하려면 ‘예상 반박 시나리오’를 잔뜩 마련하는 것이 좋다. 이런 저런 말이나 행동이 나올 것이라고 예상하고 있으면 실제 상황에서 덜 당황하게 된다. 그리고 최대한 상세하게 들어주고 답하는 자세가 필요하다. 교조적으로 접근하면 실패한다.
언어는 매우 강력한 도구다. IT는 최근, 그리고 앞으로 몇 년 간 인간의 모든 생활에 지대한 영향을 끼칠 분야다. 우리가 여기서부터 말을 바꾸기 시작하면 IT 기술 이상의 좋은 영향을 줄 수 있게 된다. 우리는 기술공으로 남을 것인가, 아니면 기술과 함께 좋은 문화까지도 함께 전달한 개척자 혹은 선구자가 될 것인가?
글 : 롭 오도노휴(Rob O'Donohue), 수석 분석가, 가트너
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-16] .jpg)
.jpg)
