"'슬레이브' 등 차별적 IT 용어, 꼭 쓸 이유 있나요"

송주영 비엔엑스 엔지니어 인터뷰

"시스템 속에 반영된 IT 용어를 바꾼다는 게, 어떻게 보면 리스크만 있고 도움되는 바가 없다고 볼 수 있다. 하지만 대체 용어가 있는데, 굳이 차별적 용어를 쓸 필요가 있나."

최근 미국 실리콘밸리에서는 IT 업계에 숨어 있는 차별적 용어들을 걷어내려 하는 움직임이 나타나고 있다. 주로 문제가 된 표현들은 주요 시스템과 보조 시스템을 지칭할 때 쓰이는 '마스터-슬레이브', 방화벽 등 보안 체계에서 안전한 것으로 증명된 것과 그렇지 않은 것을 정리한 목록인 '화이트리스트-블랙리스트' 등이다.

이같은 용어들은 차별적 인식을 심화시킨다는 비판 하에 대체 용어로 바뀌고 있다. 소스코드 저장소인 깃허브의 경우 저장소의 기본 브랜치 이름을 마스터에서 '메인'으로 바꾸기로 했다. 애플도 마스터를 프라이머리 또는 메인으로, 슬레이브는 레플리카, 세컨드리 등으로 전환하는 내용을 프로그래밍 코드 작성용 가이드에 담았다. 트위터도 이런 예시들을 포함한 차별적 용어들과, 교체될 대체 단어를 정리해 발표한 바 있다.

트위터 엔지니어팀이 중립적인 단어로 교체예정인 개발용어 목록을 발표했다(표=트위터 엔지니어팀)

이같은 소식이 전해짐에 따라 국내 기업에서도 그 동안 '불편함'을 느끼며 억지로 써온 용어들을 걷어내자는 움직임이 나타났다. 빅히트의 IT 자회사인 비엔엑스가 그런 사례다.

송주영 비엔엑스 엔지니어는 사내에서 이를 주도해 추진했다. 조직 내 바람직한 개발 문화를 주도하는 데브옵스 엔지니어로서도 시도해 볼 만한 변화라고 생각했다는 설명이다.

이같은 움직임에 대해 긍정적인 반응만 있는 것은 아니다. 기존 용어를 일괄적으로 시스템에서 걷어내는 일이 만만치 않고, 자칫하면 시스템의 오류를 늘릴 수 있다는 관점도 존재한다. 냉정하게 볼 때 위험 부담만 생기는 일을 꼭 해야 할 필요가 있냐는 주장이다.

이에 대해 송주영 엔지니어는 반대로 "IT 차별적 용어야말로 꼭 쓸 필요가 있냐"고 반박했다. 이런 용어들에 불편함을 느끼는 것이 일반적인데, 현 상황을 그대로 놔둘 필요성이야말로 존재하지 않는다는 것이다.

송 엔지니어는 직접 시스템을 살펴 차별적 IT 용어들을 걷어내본 경험담을 공유했다.

송주영 비엔엑스 매니저

-차별적 IT 용어에 대해 관심을 갖게 된 이유는?

"데브옵스 엔지니어로 일하고 있다. 보통 클라우드 관리 및 자동화, 어플리케이션 신뢰성, 모니터링 업무, 운영 업무 등을 많이 하고 있다. 오픈소스도 저희 팀에서 다룬다.

올초 깃허브가 마스터와 슬레이브를 대체 용어로 변경한다는 기사를 보고 이 이슈를 접하게 됐다. 주장에 공감이 됐다. 엄청 오랫동안 써왔던 용어인데, 슬레이브 같은 경우 부정적인 이미지가 강하니까. 우리나라 사람으로서도 충분히 그렇게 느낄 수 있는 단어이기도 하고. 그렇다고 바꿔 써야겠다는 생각까지는 없던 차에 기사를 읽게 됐다."

-팀원들 반응은 어땠나

"처음엔 시큰둥해하겠지만 지지해줄거라 예상하면서 얘기를 꺼냈다. 공감을 얻기 위해 팀원들한테 관련 기사를 보여줬는데 반대하는 사람이 없었다. 사실 팀워크가 좋아야 이런 얘기도 할 수 있다. 

시스템 고치는 건 혼자 다 했다. 이후엔 팀원들이 새 시스템을 만들 때 대체 용어를 사용하는 식으로 협조를 해준다. 엄청난 변화는 아닐지라도 뿌듯하단 생각이 든다. 외부 발표자로 나설 때 이 일을 얘기할 때도 있는데, 굉장히 공감하는 사람들이 있다."

-쓰던 용어를 걷어낸다는 건, 구체적으로 시스템 내에서 어떤 변화가 필요한건가.

"자동화된 시스템 속 여기저기에 그런 용어들이 박혀 있다. 문제되는 단어들을 찾아내야 하고, 또 시스템이 유기적으로 연결돼 있기 때문에 한 군데를 바꾸면 연결된 곳도 고쳐줘야 한다. 

가령 깃허브에서 '마스터의 코드를 다운로드 받는다'는 명령어를 짜서 넣었는데, 마스터란 용어를 바꾸려면 이런 코드들도 고쳐줘야 하는 거다. 소스코드가 저장돼 있는 리포지토리(코드 저장소)마다 각각의 용어를 바꿔줘야 하는 것인데, 단순 계산해도 리포지토리 개수만큼이다. 제가 이번에 바꾼 건 70개 정도 된다. 일주일 가까이 걸렸고, 이 기간 동안 이 작업만 붙잡고 했다."

-용어를 걷어내면서 어려웠던 점은?

"시스템을 만들었을 때 설정한 이름을 바꾸지 못하는 경우도 있다. 그러면 시스템을 새로 만들어야 한다. 보통 '하드코디드' 됐다고 표현한다. 'AWS 엘라스틱 캐시' 같은 서비스를 이용해 만든 시스템 같은 게 그렇다. 시스템에 있는 데이터를 새로 만든 시스템에 이관하고, 이 시스템 속 데이터와 연계된 시스템도 수정이 필요하다. 올해 2분기 쯤에 이런 작업을 진행했다. 일단 저희 팀에서 다루는 시스템부터 먼저 진행했고, 진척률이 90% 정도 된다. 사내 다른 시스템은 여유가 좀 생길 때 작업을 진행할 수 있지 않을까 싶다. 

새로 구축하는 시스템에선 처음부터 문제 용어를 대체 용어로 바꾼다는 인식을 갖고 시작하면 되기 때문에 어려운 일이 절대 아니다. 다만 IT 대기업 정도의 시스템 규모라면 이런 작업을 전사적으로 추진한다 하면 전쟁일 것이다."

-차별 용어를 걷어내기 쉽지 않은 대규모 IT 인프라를 가진 기업도, 이런 용어 변경을 시도해야 할 이유가 있다고 보나.

"쉽게 할 수 있는 일은 아니다. 그런데 이런 작업을 하다 보면 우리 시스템이 얼마나 자동화가 잘 돼 있는지 점검하는 계기가 되기도 한다. 전체 시스템을 훑어보고, 오류가 나는지 점검해야 하니깐.

예를 들면, 깃허브에 소스코드가 저장돼 있는데 이 소스코드를 다운로드하는 명령어를 설정했다고 치자. 깃허브의 디폴트 브랜치 이름은 마스터고. 명령어가 '깃허브의 마스터 브랜치를 다운로드하라'고 돼 있으면 마스터라는 이름이 필요한 명령어인거다. 그런데 이렇게 하는 대신, '깃허브에서 디폴트로 설정돼 있는 코드를 다운로드하라'고 바꾸게 되면 특정 브랜치를 지정해 수행되는 명령어가 아닌, 현 시스템 설정을 반영해 명령을 수행하도록 만들 수 있다. 더 자동화된 시스템이 되는 것이다.

기존 시스템을 고치는 게 어렵다면, 새 시스템에만 차별 용어를 걷어내는 것도 시도해 볼 만한 가치가 있다. 충분히 대체 용어가 있으니깐."