⚽️ 목표
(내가 속한)조직내 올바른 단어 사용 및 통일을 중요하게 생각하는 이유에 대해 글로 풀어본다.
•
이 글은 “어떻게 조직내 올바른 단어 사용을 유도할까?”를 이야기하는 글이 아니다. 조직내 올바른 단어 사용의 필요성을 이야기 하는 글이다.
TL;DR
언어는 프로토콜(규약)다. 올바른 단어를 사용하자.
•
간단한 지식, 노가다 정리가 아니다. 글을 꼭 읽어보자
1. 언어는 protocol 이다.
•
protocol은 한국어로 번역될 때 주로 규약이라는 단어로 번역된다.
•
좀 더 우리에게 친근하게 말하자면 언어는 약속이다. tag란걸 tag라고 부르기로, element를 element로 부르기로 한 일련의 약속인 셈이다.
2. 의사소통의 병목현상
•
“언어는 규약이다”라는 관점에서 본인은 의사소통의 병목현상을 야기하는 문제점은 크게 두가지로 본다.
통일되지 못한 단어들
<img src="x"/>
TypeScript
복사
•
언어는 규약임에도 불구하고 사람마다, 조직마다 어떤것을 부르는 단어가 크게 다른 경우가 있다. 아래 예시로 말해보자. 위에 예시로 존재하는 img tag에 src를 attribute, props 또는 한글로 속성 이라고 부르는 사람들이 있다.
•
물론 서로다른 명칭으로 부르는건 이해 된다. 특히 한국어 또는 영어로 최소 2개의 케이스가 존재하는 건 자국어로 되지않는 학문을 배울때 항상 있는 문제라 생각한다. 이런 내용들이 한글로 시작된 학문이였다면 “이걸 번역 해야하나, 말아야 하나”와 같은 쓸데없는 걱정도 없었겠지.
◦
e.g. flatten → 평탄화, deprecated → 사용 중단된(? - 이건 아직도 모르겠다 단어임에도 불구하고 한글로 표현하자니 속에 불이끓는다. 제대로 번역하자면 “더 이상 유지보수 되지 않는, 대체 될 예정인”이라 번역하고 싶지만… 으아악)
잘못된 단어 사용
길게 설명하지 않고 실생활 예시를 사용하겠다.
ISR을 ISR이라 부르지 않고 SSR 또는 SSG 라 부르는 상황을 상상해보자.
•
페이지01에는 ISR이 적용되어있다. 지금 해당 조직의 프로덕트에 페이지 01에 이슈가 생겼고 해당 이슈는 ISR에서 비롯되고 있다.
•
조직원 A씨는 ISR을 항상 SSG라고 부르고 어쩔 때는 SSR이라고 부른다.
•
주로 대화는 이런식으로 이루어진다. 분명 ISR이 수행되고있는 페이지인데 ”아 이거 SSG 문제에요~” 라며 대화를 한다. 불행하게도 현재 프로덕트에는 분명 SSG, SSR도 수행되고 있다. 물론 다른페이지에서. 여기서 부터 대화의 병목현상이 시작된다.
•
간단한 예시지만 여기서 A와 대화하는 상대는 두가지 생각이 든다.
1.
“SSG?아 지금 SSG로 생성하는 페이지를 말하는거구나?”
2.
“SSG? 이 페이지는 SSG가 이루어지고 있지 않은데… 잘못 알고계시나?”
•
1이 됐던 2가 됐던 대화 상대는 질문을 한다. - 병목현상 발생
1.
“지금 페이지01 말씀하시는거 맞죠?”
2.
“SSG가 아니라 ISR 수행되고 있는 페이지 인데요… ISR 말씀하시는거 맞죠?”
2. 우리를 해치는 “눈치와 이해”
•
잘못된 단어를 들었을때 우리는 아래와 같은 생각들로 대부분의 의사소통의 병목현상을 합리화한다.
◦
앞의 이해들과 함께 “아 이거 말하는거겠지~”와 같은 생각으로 눈치를 활용한 문맥상 추론
◦
“이사람은 원래 이렇구나”라는 불필요한 이해 또는 배려
•
두개 다 비슷하지만 문맥상 추론과 불필요한 이해 또는 배려는 분명한 차이가 존재한다.
◦
문맥상 추론은 주로 무의식적일 수 있는 행위다.
◦
불필요한 이해 또는 배려는 의식적 행위다.
컴퓨터 통신과 인간 의사소통의 차이점 - 문맥상 추론
•
컴퓨터와 컴퓨터간에 통신에서는 protocol이 지켜지지 않을 경우 작동하지 않는다. → IP protocol에 규약이 존재하는데 해당 규약(명세)에 맞지않은 데이터가 전달될 경우 단말간, 또는 라우터간 통신은 불가능하다.
“인간은 잘못된 데이터가 들어왔을때 대화나 의사소통의 문맥을 이용해 잘못된 데이터를 자체적으로 수정하여 이해한다.”
•
하지만 인간과 인간간의 의사소통에선 protocol이 맞지 않아도 의사 소통이 가능하다, 열등한 컴퓨터와는 다르게 눈치라는걸 이용하여 문맥상 추론하기 때문이다.
•
ISR을 SSG로 부르는 조직원의 케이스에서 문맥상 추론은 “아 SSG가 아니라 ISR을 말하는 거겠지?”라는 자세로 대화에 임하는 것
이 사람은 원래 이래 - 불필요한 이해 또는 배려
•
잘못된 단어를 사용하거나 약속되지 않은 단어를 사용하는 사용자에게 “그러려니”, “이사람은 원래 그렇게 부르는구나~”와 같은 수동적인 자세는 불필요한 이해 또는 배려라 생각한다.
•
이런 불필요한 이해와 배려는 결과적으로 팀의 생산성을 떨어뜨린다. 조직원들간 의사소통의 여러 단계 중 재처리단계가 하나 더 추가되며, 서로 다른 의미가 전달되어 잘못된 의사소통으로 이루어 질 수 있기 때문이다.
3. 올바른 단어 선택
•
올바른 단어 선택의 중요성은 예시를 이용하여 설명하겠다.
<img src="x"/>
TypeScript
복사
예시코드
•
위에서 한번 봤던 코드를 재활용했다. HTML일 경우 attribute가 맞는 말일 것 이다. 근데 리액트 코드(JSX, TSX) 내부에서 사용되는 경우에도 attribute가 맞는걸까?
예시) 리액트에서의 props
부모 컴포넌트가 자식 컴포넌트에게 값을 전달해주는게 props아니야? → 정확히 말하자면 반쯤 맞고 반쯤 틀린말이다.
•
“Props are the information that you pass to a JSX tag.”
◦
props란 JSX 태그에 정보를 전달해주는 정보다. JSX 태그이기 때문에 부모가 자식 컴포넌트에 전달해주는 값, 그리고 컴포넌트가 아닌 일반 태그에 전달해주는 정보들 모두 props라고 불리는게 맞다.
•
리액트에서 개발자들이 JSX, TSX 상 에서 조작하는 코드들은 실제 DOM요소를 조작하는게 아니라 VDOM을 조작하며, 우리 모두가 아는 컴포넌트 render, commit, paint는 리액트 DOM이 수행해준다.
•
이대로라면 “src”는 리액트에서는 attribute가 아닌 props라는 단어로 부르는게 맞다.
올바른 단어선택 왜 중요할까?
1.
올바르지 않은, 정확하지 않은 단어 선택은 해당 개념을 제대로 이해하지 못했기 때문에 발생한다. 정작 본인만 해도 위 예시 코드의 src를 attribute라고 불렀기 때문이다. 이를 정확히 찾으려는 노력은 당연히 없었다. “누가봐도 HTML 코드인데 이거 당연히 attribute 아니야?”와 같은 자세였기 때문. 본인이 리액트 hook component 작성하는 TSX 코드들은 실제 DOM이 아닌 Vitual DOM을 조작하는 사실을 정확히 인지하고 props는 부모 컴포넌트가 자식 컴포넌트에게만 전달하는 정보가 아닌 JSX 태그에게 전달하는 정보라는걸 알고 있는 이상 JSX, TSX 코드 상 src와 같은 것들을 attribute라고 부르진 않을 것 이다.
a.
내가 알고있는 개념의 이해가 선 수행 되어야한다. 아무것도 모르고 “CSR을 제외한 다른건 SSR, ISR, SSG아닌가?” 와 같은 자세는 개발하며 마주치는 문제해결 능력에도 영향을 끼친다. 항상 하는 말은 똑같은거 같지만… 정확히 이해하고 사용하고 부르자.
2.
지금껏 여러번 반복하여 한 말이지만 언어는 규약이기 때문이다. 공식문서 또는 사전적 의미 또는 프론트엔드 개발자의 경우 MDN과 같은 공신력있는 곳의 단어를 확인하여 사용하는게 의사소통의 병목현상을 없앨 수 있다.
4. 중요성 타당 검토
•
올바른 단어 사용은 간단하고 작은 일, 또는 무의미한 일이라 생각할 수 있지만 본인은 “이런 사소한것 들이 모여서 내가 속한 조직의 생산성을 결정짓는다.”라는 생각은 믿어 의심치 않는다.
생산성(완벽) 바라기
•
물론 조직의 생산성만을 쫓는 자세는 위험하다 생각한다. 하지만 조직의 구성원인 이상 우리는 “생산성만을 쫓는 자세를 경계함과 동시에 최고의 생산성을 쫓아야한다.”
•
마치 완벽의 존재를 믿지 않지만 완벽을 향해 달려가는 것 과 같은 자세라 생각한다.
◦
“완벽의 존재를 믿지 않지만” → 완벽이란 개념은 달성하기 매우 어려운 개념이다. 우린 이 자세로 완벽주의로 빠지는 걸 경계할 수 있다.
▪
eg) 완벽한 프로덕트를 만들기 위해서 모든 utill 함수에 unit 테스트를 추가하고, unit 테스트에 실제 일어날 확률이 0에 수렴하는 모든 케이스의 테스트를 다짜며 개발한다 → 완벽주의라고 생각한다. 나쁘진 않다. 하지만, 우린 결과물을 만들어 내야하는 사람이다. 선택과 집중을 잊지 말자.
◦
“완벽을 향해 달려가는 것” → 완벽이란 달성하기 힘든(어쩌면 불가능한) 개념이란 것을 자각하고 우린 완벽을 향해 달려가야한다. 그래야 우리는 (완벽에 그나마 가까운)좋은 결과물에 발끝이라도 다가갈 수 있기 때문이다.
5. 조직내 단어 통일
“우리 조직은 이걸 modal이라 부르기로 했다”
•
조직 뿐 아니라 개인을 위해서라도 올바른 단어 사용은 백번 옳다고 생각한다. 하지만 조직내 단어 통일은 무조건적인 동의 보단 긍정적으로 생각하는 바 이다.
단어 통일의 예시
•
조금 극단적으로 말하자면 개인을 위해서라도, 조직을 위해서라도. 올바른 단어 사용은 당연히 해야할 mandatory라고 생각한다.
•
modal, dialog와 같이 경계가 모호한 단어들은 오히려 통일하는게 조직에게 좋은 영향을 끼친다. 적어도 내가 겪었던 바로는 사람마다 다르게 부르던 modal/ dialog, confirm/ browser confirm/ system confirm와 같은 애매한 단어들을 통일 하면서 의사소통에 병목현상이 사라졌다.
•
실제로 필자 속했던 조직에서 도입했었다. “모달이 로그인 할때 그 모달 말씀하시는거 맞죠?”와 같은 질문이 사라졌다. 간단한 하나의 질문이지만 10명의 조직원이 하루에 두번씩(대충 200일이라 치자) 1년동안만 불러도 4000번의 의미없는 질문이 사라진다. 그에 추가로 의사소통 혼선으로 인한 잘못된 개발/ 디자인의 경우 까지 합친다면…?
6. 결론
“항상 올바른 단어사용의 중요성과 필요성을 깨닫고 의사소통 하는 자세를 가져야 한다.”
•
“모든 의사소통에서 grammer police와 같이 “이건 이렇게 부르기로 했는데요?”라며 조직원들을 불편하게 만들자!”는 본인이 하고싶은 말이 절대 아니다.
•
조직마다 너무 다른 분위기, 조직원간 특성이 있기 때문에 “이런 방법으로 시도해봐~”와 같은 정답은 존재하지 않는다. 내가 시도했던 방법들이 옳다고도 할 수 없다. 알아서 잘해 보자
다른 두가지 지만 하나의 결론
올바른 단어를 조직내에서 통일하여 사용하자
•
필자가 하고 싶은 말이다. 올바른 단어를 조직내에서 통일하여 사용하면 의사소통의 병목현상도 사라지며 올바른 단어를 선택하기 위한 연구 및 조사로 인하여 해당 대상에 대한 근본적인 이해도도 높아진다. → Why not? 한번 시도해보자.
•
하지만 올바른 단어 사용, 단어 통일에 감정이입하지 말자. 다시 한번 말하지만 우린 결과물을 내야하는 조직의 구성원이다. 필요성을 느낀 당신, 필요성을 느끼지 못한 타인을 이해하도록 노력해보자.
단어 통일 및 올바른 언어 사용은 조직에서 필수적 일까?
•
필자는 (당연하게도)중요하다 느꼈으므로 조직내 단어통일 및 올바른 단어사용을 위해 변화를 시도했으며 다행히도 기대하던 결과를 얻었다. 의미없는 의사소통의 병목현상이 많이 줄어들었다.
•
하지만 단어통일의 필요성을 못느끼고 개선의 의지가 없다는것이 그 사람을 평가하는 기준이 되어선 안된다. 내가 중요하다 생각하는 것들이 남에게는 티끌보다 작게 보일 수 있다.
말해도 말해도 안고쳐지는 사람들은 어떻게 할까?
“단어 통일하자! 올바른 단어를 사용하자!”로 조직내에서 결정됐음에도 불구하고 자신만의 길을 걷는 사람들이 존재할 가능성은 높다.
•
물론… 아무리 말해도 안고쳐지는 사람들은 어딜가나 존재한다. 정작 본인도 많이 만나봤고 많은 스트레스를 받아봤다. 하지만 이미 질문에 “말해도 말해도 안고쳐지는” 이라는 답이 존재한다.
•
답은 이 글을 읽고 있는 당신도 알고있다. 말해도 말해도 안고쳐진다는것은 뭘해도 안고쳐지는 사람들이란 것이다. 이미 이 질문이 머리속에 자리를 차지했다는 것 자체가 당신은 모든 시도를 다 해본 것 이다.
•
분명 당신도 노력을 했을것이다. 수십번이나. 하지만 그들은 안고쳐지는 사람들 일 뿐이다. 서로 감정 상하지말자. 오히려 여기서부터 “그러려니~”하는 자세가 필요하다. 이런 말 하기 싫지만 더 말해봐야 입만 아프다. 이런 조직원들 사이에선 grammer police, wording police가 되는 순간 그 조직에서는 바로 내가 악당이다. → “악당이 되지말자.”
“아 진짜 못참겠다” 까지 나왔으면 필자가 해줄말은 하나밖에 없다.