성장하지 않아도 잘 살아가는 방법 1

여우·2024년 12월 5일

105

이 포스팅은 LINE ABC Studio의 기술 임원으로 재직 중이신 김영재 님의
시야가 넓은 개발자는 무엇이 다를까, 성장하지 않아도 괜찮습니다
발표를 바탕으로 재구성한 포스팅입니다. 감사드립니다.

김영재 님 Linkedin

함께 부트캠프를 졸업한 친구와 카페에서 공부하던 어느 여름날이었습니다.

유튜브에 올라온 컨퍼런스 영상을 넋 나간 눈으로 보고 있던 친구는
갑자기 이렇게 말했습니다.

'난 이제 성장이라는 단어만 봐도 토가 쏠린다'

그 말을 듣는 순간 오묘한 기분이 들었습니다.
'성장'은 원래 자연스럽고 기분 좋은 느낌을 주는 단어였을 텐데,
어느샌가 우리에게 성장이란
'무엇인지는 모르는데 하지 않으면 뒤처지게 만들고 인생을 고꾸라뜨리는 무언가'가 되어 있었습니다.

우리는 왜 이렇게 된 걸까요?
요새 '성장'이라는 단어가 왜 이렇게 듣기 싫을까요?

성장이라는 키워드는 왜 별로인가?

⋯ 생각을 해보면 문법적으로 맞는 건지 의문이 드는 거죠.
우리가 “성장”이라는 말을 쓸 때는 예를 들어,
어떤 사람을 보며 “아, 저 사람이 정말 많이 성장했네”라고 할 때 보통 사용하죠.
그러니까 이 “성장”이라는 것은, 시간이 한참 지난 뒤에 돌아봤을 때
“내가 그때보다 성장했지”, “그때보다는 좀 나아졌지” 정도로만 보통 말하는 경우가 많다는 거죠.
- 성장하지 않아도 괜찮습니다 中

여러분은 어릴 때 사촌댁에서
'우리 조카, 키가 커지고 있네' 또는 '키가 앞으로 더 크겠네'라는 말을 들으신 적이 있나요?

그보다는 '우리 조카, 키 많이 컸네'라는 과거시제를 훨씬 많이 들으셨을 것으로 생각합니다.

'성장하다'라는 동사는
'미래에서 과거를 회상할 때' 더 자연스러운 맥락을 가집니다.

과거에서 현재로 이어지는 경과를 관찰할 때 사용하는 '성장하다'라는 단어의 시제를 강제로 꺾어
현재에서 미래를 예측하는 '성장할 것이다'라는 방식으로 사용하기 시작하면,
'10년 후의 내 모습 그려보기'처럼 두루뭉술하고 추상적인 목표가 나올 수밖에 없습니다.

이렇게 두루뭉술해진 목표를 어떻게든 잡아보려 악을 쓰는 순간
다양한 문제가 일기 시작하는데,

잘하고 있던 공부에도 자꾸만 브레이크를 걸면서 '잘하고 있는 게 맞나?'하며 스스로를 의심하고,
요즘 화젯거리인 키워드를 나도 공부하지 않으면 성장하는 게 아닌 것 같다는 압박감을 느끼고,
옆 사람과 비교하며 뭐라도 해야 한다는 불안을 느끼고,
무엇을 해야 하는지 모르겠지만 아무튼 성장을 해야만 한다는 부담을 느낍니다.

무엇보다 위와 같은 정서 아래에선
'늘 하던 것을 계속하는 것'을 마치 현실에 안주하는 행위인 것처럼
부정적으로 여기는 인식이 퍼지게 됩니다.

자신이 계속해 오던 일을 꾸준히, 깊이 해나가는 것은 매우 가치 있는 일이며
우량한 회사들이 원하는 인재가 주로
'자신이 하는 일을 꾸준하고 깊이 파고드는 Deep Dive 경험이 있는 사람'임에도,

사회에는 깊이보다 양을 우선하는 사람들이 더 많아지는 모순이 생깁니다.

성장을 대체하는 새로운 키워드

정신을 괴롭히지 않아도 멋진 개발자로 살아가려면 어떻게 해야 할까요?

일본에서 가장 큰 배달 플랫폼 데마에칸出前館의 CPO로 재직 중이신 김영재 님은

2024년 2월에 진행한 re:COMMIT의 '시야가 넓은 개발자는 무엇이 다를까',
그리고 해당 발표를 더 가볍게 재해석하여 인프콘 2024에서 발표하신
성장하지 않아도 괜찮습니다에서

성장과는 다른 결을 가지고
하던 일을 계속하는 꾸준함이 갖는 가치를 극대화하면서 일하는 방법을 공유하셨습니다.

발표에서는 지금 하고 있는 일을 어떻게 하면
더 많이, 더 함께, 더 크게 그리고 더 오래 할 수 있을까에 대한
세 키워드(인터페이스, 프로세스, 캐퍼시티)를 제시합니다.

이 발표는 성장이라는 것에 불편함과 불안함을 경험한 0~2년 차의 많은 분께서 인상깊게 보셨고,
저 또한 깊은 감명을 받았습니다.

제 글솜씨가 좋지 않아 내용을 오롯이 담지 못할 수 있는데,
정말 좋은 내용이 꽉꽉 담긴 발표이니 영상으로도 꼭 봐주셨으면 좋겠습니다.

그럼
각 키워드의 내용을 하나씩 살펴보겠습니다.

인터페이스 Interface

인터페이스란 무엇인가?
'나의 모든 아웃풋에는 상대방이 있다' 라는 인식을 가지고 일을 하는 거예요.
숨 쉬듯 자연스럽게
'내가 지금 하는 일에 있어 상대방은 뭐지?'라는 생각을 하는 거예요.

'서로'를 의미하는 라틴어 접두사인 'inter-'와 '얼굴'을 뜻하는 'facies'를 합하여,
서로를 마주 보는 표면을 뜻하는 'interface'가 되었다고 합니다.
컴퓨터가 탄생하기 한참 전부터 존재했던 단어인 만큼,
인터페이스라는 것은 반드시 나와 '상대방'이 있어야 생명력을 갖는 개념입니다.

조직에서 무언가를 만들어내는 모든 과정에서
나의 산출물을 사용하게 될 상대방, 즉 사용자(User)를 생각하고 배려하는 것이
인터페이스라는 개념입니다.

나의 사용자는 누구일까

우리는 회사에서 다양한 결과물들을 만드는데,
그 중엔 숨 쉬듯 자연스럽게 사용자를 생각하는 것도 있고, 아닌 것도 있습니다.

개발자로서 일상에서 만들어내는 것 중 사용자를 생각해 볼만한 것으로 어떤 게 있을지 알아봅시다.

내 서비스의 사용자는 누구일까?
간단하게 떠올릴 수 있습니다. 아이폰의 사용자, 네이버의 회원과 비회원, 관리자 페이지를 사용하는 사내 직원들.
회사원으로서 언제나 생각할 수밖에 없는 사용자 그룹입니다.
내 코드의 사용자는 누구일까?
함께 일하는 동료 아닐까요?

동료 또한 하나의 답이 될 수 있습니다.
제가 보통 하는 말은,
내 코드의 사용자는 '내일의 나'에요.
또는 한 달, 석 달 후의 나.
심지어는 삼 년 전에 짠 코드에 대해서도 질문을 받으면
'내가 그때 무슨 생각으로 짰지?'라는 걸 저 자신이 빨리 파악할 수 있을수록 좋아요.
- 성장하지 않아도 괜찮습니다 中

시간과 관계없이 자신이 만든 코드를 빠르게 파악하려면
자연스럽게 처음 코드를 작성할 때 '가독성'을 생각할 수밖에 없습니다.

삼 년 후의 나 자신이 보아도 알아볼 수 있는 코드를 쓰겠다!
라는 마음가짐으로 코드를 가독성 있게 써둔다면
삼 년 후에 입사한 동료도 단번에 이해할 수 있을 것입니다.
내 모듈의 사용자는 누구일까?
한 단위의 프로젝트 또는 서비스별로 모듈 또는 Repository를 나누어 관리하는 회사가 많습니다.
이때 각 모듈의 사용자는 당연히 해당 프로젝트 또는 서비스에 참여하는 동료 또는 나 자신입니다.
하지만 정말 많은 회사에서 여러 개의 모듈을 관리하면서도
각 모듈의 README 파일에 아무것도 쓰지 않거나, 기본 템플릿으로만 둔 채 방치하곤 합니다.

아무리 나 혼자 쓰고 나 혼자만을 위한 모듈이라고 할지라도
'이 모듈은 누구를 위한 것이고 어떤 기능을 한다'라는 것을
정교하고 정확한 언어로 README 파일에 쓰는 습관을 들여보시기를 영상에서는 추천하고 있습니다.
내 문서의 사용자는 누구일까?
문서를 읽고 도움을 받을 사용자는 글의 내용에 따라 천차만별입니다.
그 때문에 문서를 읽는 사람은 '이 글에 내가 필요로 하는 내용이 있나?'를 빠르게 알 수 있어야 합니다.
만약 문서를 읽을 필요 없는 사람이 문서를 읽느라 시간을 낭비한다면 슬픈 일이 되겠죠.
사람들로 하여금 자신이 이 문서의 사용자인지 아닌지 빠르게 알 수 있게 하려면 어떻게 해야 할까요?

잘 쓴 책이나 문서는 항상 제일 처음에
'이 문서는 무엇을 위한 거고 어떤 독자를 위한 글이다'라고 명시가 되어 있어요.
- 성장하지 않아도 괜찮습니다 中

학교에 다닐 때 쓰는 교과서의 매 단원 첫 장에는 항상
이렇게 '학습 목표'가 쓰여 있습니다.

학습 목표의 내용은 교과서의 본문만큼이나 중요한 역할을 합니다.

문서의 본론을 시작하기 전 이렇게
'이 글을 어떤 내용이고 누굴 위한 거야'를 적어주는 것만으로도
읽는 사람의 이해 능력을 크게 높일 수 있고,

문서를 쓰는 우리 또한 예상 독자를 미리 정해두고 그 사람들을 위한 문서를 쓰게 되니
더 정갈하고 영양가 있는 문서를 쓸 수 있게 됩니다.

이렇게 상대방을 명확히 정의하는 것을 첫걸음으로,
'상대방이 원하는 것을 주자'라는 마음으로 일하는 사람이
좋은 인터페이스를 가진 사람이라고 할 수 있습니다.

그렇게 되면 내가 하는 일을 나 자신이 설명하는 것도 쉬워지고,
상대방이 이해하기도 쉬워지겠죠.

그렇다면 내 직장에서 좋은 인터페이스를 가진 사람이 되기 위해
회사에서 구체적으로 무엇을 해보면 좋을까요?

좋은 인터페이스를 기르기 위해
강의에서는 크게 '기획', '개발', '대화' 세 영역에서 훈련법을 제시합니다.

'기획'에서의 인터페이스 훈련 - BANEX

BANEX 템플릿 - 사업부터 개발까지 모든 스테이크홀더의 눈높이를 맞추는 프로덕트 플래닝

팀 프로젝트를 할 때, 나와 팀원들이 프로젝트를 바라보는 눈높이가 맞지 않아 곤란했던 경험이 한 번쯤 있을 것으로 생각합니다.

노션과 피그마 같은 도구를 이용하면서
'이번 스프린트에선 A를 만들자, 다음엔 B, C, D를 만들자' 하며 나름대로 기획을 잘한 것 같지만,
사실 팀원 각자의 마음속엔 A, B, C, D 각각에 대한 우선순위나, 변경 또는 확장 가능성을 생각하는 기준이 다르게 자리 잡고 있을 것입니다.

교과서로 비교하면
팀원 모두가 같은 교과서를 받았지만 학습 목표가 모두 다르게 적힌 것과 같습니다.

이렇게 같은 일을 다르게 바라보는 것은
구성원 사이에서 갈등을 일으키고 프로젝트의 구조를 지저분하게 만들 수 있기 때문에
프로젝트의 각 요소를 바라보는 눈높이를 동일하게 맞추는 활동이 꼭 필요합니다.

그리고 지금 소개해 드릴 BANEX가 여러분께 도움이 될 것입니다.

'사용자 경험을 위한 기본 기능, 부가 기능, 신기능 분류표' 라는 의미를 가진 BANEX(Basic, Additional, New value for an End-user eXperience)는
개발자와 비개발자를 포함한 팀 내의 모든 구성원이
우리의 서비스를 향해 동일한 눈높이를 가질 수 있도록 도와주는 협업 템플릿입니다.

BANEX 템플릿은 세로축과 가로축, 그리고 각 기능을 나타내는 원소로 이루어져 있습니다.

템플릿 안에 있는 블록은 하나의 기능(feature)을 나타냅니다.
팀원들의 머릿속에 담고 있는 기능들을 모두 끌어내어 템플릿에 표시한 것인데,
브레인스토밍의 아이디어와 비슷합니다.

템플릿의 가로축은 우리의 서비스를 이용하는 사용자의 경험 흐름입니다.
그림의 예시는 일반적인 전자 상거래 서비스에서 사용자가 구매하는 과정의 핵심 단계를 나타낸 것입니다.

가로축의 내용은 프로젝트마다 다릅니다.
어떤 내용을 사용자 경험의 핵심 단계로 그릴지 구성원과 대화하는 과정이 필요합니다.

세로축은 각 기능의 우선순위를 나타냅니다.
Basic: 없으면 부끄러운 상식적인 기능
Additional: 있으면 좋거나 경쟁사 제품에 특별하게 있는 기능
New Value: 다음 비즈니스를 바라보는 기능

BANEX 템플릿의 핵심은 세로축입니다.
우리가 만들 기능 하나하나에 대해,
과연 이 기능은 아무리 바빠도 반드시 있어야 하는 것인지
혹은 있으면 좋지만 없어도 무리 없는 것인지
팀원끼리 까다롭게 토론하고 합의해야 합니다.

이 활동을 왜 해야 할까요?
BANEX 템플릿이 주는 이점은 다음과 같습니다.

서로의 상식을 맞출 수 있다
'로그인' 기능을 개발할 때 '구글 로그인'을 제공하는 건 상식일까요, 아닐까요?
세상 사람들 모두 구글을 쓰니 당연히 있어야 하는 것 아니냐는 팀원이 있을 것이고,
기본 뼈대인 이메일 로그인 기능만으로도 충분하고 구글 로그인은 부가 기능일 뿐이라 하는 팀원도 있을 것입니다.

이렇게 서로가 가진 상식의 범위가 다를 때, 요소들 하나하나의 중요도를 정하는 활동을 통해 같은 눈높이를 가질 수 있게 조정할 수 있습니다.
같은 단어로 말할 수 있다
배달 플랫폼에서 '어드민'이라는 용어를 쓸 때, 누군가는 '음식점 업주'님을, 누군가는 '회사 직원'을 떠올린다면 원활한 대화가 오가지 않을 것입니다.
이는 동일한 도메인에 대한 이해가 달라서 일어나는 문제로, 이것을 해결하기 위해 이벤트 스토밍이라는 활동을 따로 진행하기도 합니다.
BANEX 템플릿 또한 같은 기능과 요소를 두고 서로를 이해시키는 활동이기 때문에,
그 과정에서 자연스럽게 동일한 도메인에 대한 동일한 이해를 가지게 됩니다.
우선순위를 가시화한다
애자일 방법론을 실천하는 팀이라면 프로젝트를 여러 스프린트로 나누어 진행할 것입니다.
초기 스프린트에서 핵심적인 기능을 개발한 후
스프린트에서 부가 기능 또는 추가기능을 개발하게 되는 것이 일반적입니다.

우리는 기획 단계에서
BANEX 템플릿을 통해 우선순위에 따라 기능들을 분류해 두었기 때문에,
이번 스프린트에는 어떤 일을 해야 하지? 를 정하기 훨씬 수월합니다.
아키텍처를 장기적인 관점으로 설계할 수 있다
'로그인' 흐름의 핵심 우선순위(BASIC)로 이메일 로그인 기능을 넣었다고 합시다.
그런데 부가(ADDITIONAL) 또는 추가 비즈니스(NEW VALUE) 우선순위로
SNS 로그인, 심지어 지문인식 로그인까지 채택하였다면
개발단계에서 우리는 무슨 고민을 하게 될까요?

기본 기능인 이메일 로그인 기능을 만들면서도,
'나중에 SNS랑 지문인식 기능도 감당하려면 코드 구조를 어떻게 설계해야 하지?'
라는 고민을 자기도 모르게 하게 됩니다.

결과적으로 BANEX 템플릿을 사용함으로써 구조를 장기적인 시야로 설계하는 것을
아주 자연스러운 방식으로 유도할 수 있게 됩니다.

링크로 남겨둔 블로그에서 더 자세한 실행 방법을 설명하고 있으므로
BANEX 템플릿에 관심이 생기셨다면 꼭 보시기를 추천해 드립니다.

TMI : 지금 작성하고 있는 이 글을 기획할 때도, BANEX 템플릿을 활용하여 목차를 짰습니다!

개발에서의 인터페이스 훈련 - CDD(설정파일 주도개발)

다른 사람을 배려하면서 코드를 작성하는 방법에 대한 이야기는 이미 오랫동안 많은 곳에서 공유되고 있습니다.

관심사의 분리, 재사용성, 디자인 패턴과 객체지향 등 다양한 방법론을 우리는 이미 알고 있지만,
막상 회사에서 운영하는 코드를 들여다보면
마치 스파게티를 연상케 하는 못난 코드를 많이 만납니다.

심지어 한국에서 가장 똑똑한 개발자를 선별해 가는 대기업의 코드도
못난이 코드의 저주를 피해 갈 수는 없습니다.
좋은 코드를 작성하는 방법을 취준생 때 다 배웠으면서,
우린 왜 적용하지 못하는 걸까요?

한 회사원의 이야기를 예시로 들어보겠습니다.

한 동료가 직장인 A에게 말합니다.
"있잖아, 앱스토어에 올라와 있는 우리 후기들을 좀 가져와서 데이터로 저장하는 기능을 만들면 어때?"

직장인 A는 자신 있게 "쉽지!" 라고 말한 뒤,
인터넷에서 앱스토어 크롤링 예제 코드를 그대로 가져와 후루룩 완성합니다.

몇 주 뒤, 동료가 또다시 직장인 A에게 말합니다.
"있지, 생각해 보니 우리 서비스는 안드로이드에서도 쓸 수 있잖아. 그래서 앱스토어 후기뿐만 아니라 플레이스토어 리뷰도 가져와 주어야 할 것 같아."

직장인 A는 자신 있게 "그것도 쉽지!" 라고 말한 뒤,
인터넷에서 플레이스토어 크롤링 예제 코드를 그대로 가져와 후루룩 완성합니다.

이후 갤럭시 스토어, 원스토어, 빌리빌리 등 스토어 종류가 늘어날수록
직장인 A의 코드는 여기저기서 가져다 붙인 낙서처럼 꼬이기 시작합니다.

직장인 A씨는 일을 못 하는 사람이 아닙니다. 개발을 못 하는 사람도 아닙니다.
그럼에도 코드가 스파게티처럼 꼬이는 가장 큰 이유는
요구사항이 한 번에 들어오지 않고 시간차를 두며 들어오기 때문입니다.

그 때문에 눈앞에 주어진 요구사항 하나만을 해결하는 방식으로 작업을 하는 사람은
요구사항이 추가되거나 변경되었을 때 기존의 코드를 응용하지 못하고,
새로운 코드를 덕지덕지 붙여야만 하는 상황에 놓이게 됩니다.

회사에서 완성된 요구사항을 한 번에 준다면 좋겠지만
대부분의 회사에서는 업무를 그렇게 주지 못하기 때문에,
이 요구사항에서 과연 어떤 요소가 변경되거나 추가될 여지가 있는지
우리가 앞서서 생각한 후 작업을 시작해야 합니다.

지금부터 설명해 드릴
설정파일 한 장을 사용하는 CDD(Configuration Driven Development)는
코드의 변경 가능성과 확장성에 대한 고민의 길이를 아주 과격하게 늘이는 개발 방법입니다.

개요

'앱스토어에 올라온 후기를 보여달라'는 요구사항을 받았다고 해봅시다.
CDD의 핵심은 '코드를 치지 않는 것'입니다.
유일한 준비물은 애플리케이션에서 사용하는 설정파일(yml, properties 등) 하나뿐입니다.

덩그러니 있는 설정 파일을 바라보면서,
'이 기능에서 변경이 일어날 만한 부분은 어디가 있을까?'를 먼저 생각해 봅니다.

그리고 나 자신을, 나의 코드를 다루는 또 다른 사용자에 빙의해봅니다.
사용자의 입장에서, '이 설정 파일의 어느 부분을 수정하면 내가 원하는 설정으로 애플리케이션을 돌릴 수 있을까?'를 생각해 봅니다.

떠올린 생각을 설정 파일에 고스란히 옮겨봅니다.
그럼, 설정 파일에는 변할 가능성이 있는 부분과 변하지 않고 핵심으로써 존재해야 하는 부분이 보입니다.

작성한 설정 파일을 바탕으로, 코드의 구조를 어떻게 만들면 좋을지 고민해 봅니다.
(이 단계에서도 코드에는 절대 손대지 않는 것이 핵심입니다)
'기능이 변경될 여지가 있는 부분을 인터페이스로 선언하는 것이 좋을까?'
'인터페이스의 구현체들은 어떻게 주입해서 어떻게 사용하면 좋을까. 상태 패턴이 좋을까, 어댑터 패턴이 좋을까?'
'의존성이 얕아야 하는 구현체들은 어느 패키지에 두어야 좋을까. 아예 별도의 모듈로 분리하는 것이 좋을까?'

등을 깊이 고민하면서 코드의 구조를 최대한 선명하게 머릿속에 그려봅니다.

코드 구조가 머릿속에 충분히 선명하게 그려졌다면, 머릿속의 코드를 화면에 그대로 옮겨 적습니다. 코드를 작성하다 무언가 막히거나 불만족스러운 구조가 나타난다면, 코딩을 중지하고 다시 고민합니다.
작성한 코드가 설정파일의 내용을 그대로 가져다 쓰도록 구현한다면 가장 좋지만, 그렇지 않더라도 나쁜 것은 아닙니다.
그때는 설정 파일을 그저 코드의 구조를 그리는 메모장이라 생각하고 무시해도 괜찮습니다.

이 훈련을 통해 완성한 코드는 그렇지 않은 코드보다
변경에 훨씬 유연하고 의존성으로부터 훨씬 안전한 구조를 갖게 됩니다.

기능을 완성하는 전체 시간을 동일하게 갖고 있으나,
코드의 구조를 고민하는 시간과 실제 코드를 작성하는 시간의 비율을 극단적으로 기울여
8:2, 심지어 9:1 수준으로 고민의 시간을 늘리는 프로그래밍 방법론이 CDD입니다.

설정 파일을 적극적으로 활용하는 설정 파일 주도 개발의 장점은 다음과 같습니다.

코드의 의존성을 더 명확히 파악할 수 있다
기능에서 변할 수 있는 부분과 변하지 않는 부분을 설정 파일을 통해 명시하고 구조를 생각하다 보면,
'변할 수 있는 기능이 변하지 않는 기능에 최대한 영향을 덜 주도록 의존성을 분리해야겠구나'라는 생각을
아주 자연스럽게 할 수 있게 됩니다.
의존성을 엄격히 구분하며 작성한 코드는 기능이 추가되거나 변경될 때 아주 효율적인 유지보수성을 보여주며, 개발 생산성을 크게 올릴 수 있습니다.
코드를 전혀 작성하지 않으므로 코드를 더 오래 생각할 수 있다
좋은 구조를 설계하는 것은 원래 많은 시간이 필요합니다.
코드의 추상화와 의존성을 고민하고 상상하는 시간을 많이 가지면 가질수록 코드를 생각하는 힘이 늘어나고,
나중에는 오랜 고민을 하지 않아도 자연스럽게 좋은 구조를 떠올릴 수 있는 능력을 갖추게 됩니다.
실무에서 바쁜 와중에도 구조를 고민할 수 있는 시간을 강제로 늘려준다는 점에서 CDD는 큰 의의가 있습니다.

대화에서의 인터페이스 훈련 - 정갈하게 말하고 글쓰기

사람들과의 대화, 그리고 블로그를 통한 공유와 소통은 인터페이스의 대표적인 예시입니다.
센스 있고 매끄럽게 대화할 줄 아는 사람이 좋은 인상을 주는 것과 똑같이,
매너 없고 불명확하게 대화하는 사람은 나쁜 인상을 줄 수밖에 없습니다.

하지만 일부 회사 또는 사람들 사이에서는
'효율적임'을 이유로 그들만의 언어로 이야기하고 대화를 일부러 어렵게 만드는 경우가 많이 있습니다.
대화의 인터페이스를 어렵게 만드는 예시를 알아보고 어떻게 고쳐야 할지 고민해 봅시다.

판교사투리

대리님, 오전 미팅했을 때 세커티를 디벨롭한거 매리지체크해서 리셀해 주시고 이슈 메컵했을 때 락앤 주세요
(대리님, 오전에 미팅했을 때 개발했던 보안 관련 사항을 업그레이드한 거 다시 한번 검토해 주시고, 검토 후에 이슈가 발생했을 때 해결 방법을 마련해주시면 공유해 주세요)

한국어를 왜 그렇게 하세요?
- 시야가 넓은 개발자는 무엇이 다를까 中

첫 번째는 한국어와 영어를 지나치게 섞어 말하는 대화 습관입니다.
한국어와 영어를 섞어 쓰게 된 데에는 여러 이유가 있겠지만 사실 이유는 중요하지 않습니다.
이러한 언어 습관이 공동체에 불러오는 문제점을 덮어주지 못하기 때문입니다.
어떤 문제가 있을까요?

'오전 미팅했을 때 세커티를 디벨롭한거 매리지체크해서 리셀해주시고 이슈 메컵했을 때 락앤 주세요'라는 말만 우리가 들었다고 해봅시다.

저 말만 남기고 떠나는 팀원을 바라보며 우리는 이런 의문을 가질 것입니다.

'어느 부분의 보안을 업그레이드했단 거야?'
'뭘 중점에 두고 검토하라는 거야?'
'무슨 이슈 말하는 거야? 리팩토링 같은 개선점 얘기하는 거야, 아니면 버그 같은 걸 얘기하는 거야?'
'메컵됐다는 건 직접 해결하지 말고 개선 제안서를 쓰라는 거야, 해결 다 하고 보고서를 쓰라는 거야?'
'어디다 공유하라는 거야?'

분명 어떠한 행동을 지시하는 말이었는데도, 대체 무슨 행동을 해야 하는 건지를 문장으로부터 전혀 알 수 없습니다. 문장이 가진 언어의 정밀도가 떨어지기 때문입니다.
이런 식으로 하고자 하는 말을 외래어로 대충 퉁쳐서 표현하는 습관을 들이게 되면, 서로 이야기하는 내용의 정밀도가 떨어지게 됩니다.
정교하지 않은 말 습관은 엔지니어로 하여금 정교하지 않은 코드를 만들어내는 결과를 낳게 됩니다.

평소 대화할 때 '어떻게 하면 상대방이 분명하게, 깔끔하게 알아들을 수 있을까?'를 항상 염두에 두면서, 쉽고 직관적인 한국어를 사용하는 노력을 들이는 것이 중요합니다.

블로그에 밈/드립 쓰기

기술 블로그의 제목과 내용에 밈만 쓰는 경우가 있습니다.

벨로그에서 유독 심하게 나타나는데, 추천을 많이 받으면 상위 블로그 랭킹에 올라갈 수 있는 시스템 때문으로 보입니다.

저 또한 옛날 블로그에서 엄준식 같은 밈 용어를 쓴 적이 있어, 저도 스스로 돌아보고 반성해야 할 항목입니다.

물론 인기 있는 유행어나 밈을 활용해 블로그를 쓰면 재밌습니다. 사람들의 유입 또한 더 쉽게 끌어낼 수 있습니다.
하지만 모든 유행은 시간이 지남에 따라 지겨워지고 시들어가기 마련입니다.
여기에서 트렌디한 블로그들의 문제점이 나타나기 시작하는데,
바로 '트렌드의 수명과 블로그의 수명이 같이 따라간다'라는 것입니다.

예를 들어 글을 쓰고 있는 지금 가장 유행하는 노래는 ROSÉ&Bruno Mars의 APT. 이니
기술 블로그를 하나 쓰고 글 제목을 APT의 노래 가사로 썼다고 가정해 보겠습니다.
글을 올릴 당시에는 노래를 모르는 사람이 없으므로 많은 사람이 찾아봅니다.

하지만 시간이 지나면서 노래의 인기는 차츰 줄어들고,
노래를 모르는 세대의 사람들은 APT의 가사로 쓰인 블로그의 내용을 유추하지 못해 글을 클릭하지도 않게 됩니다.
노래의 수명과 기술 블로그의 수명이 같이 가는 것입니다.
제가 글 작성자라면 열심히 썼는데 억울할 것 같습니다.

밈이나 드립으로 글을 쓴다면 억울할 뿐만 아니라 위험할 수도 있습니다.
출처를 제대로 모르고 쓴 유행어가 만약 저속한 커뮤니티에서 발현한 단어라면
나는 의도하지도 않았는데 부정적인 이미지가 씌워질 수도 있습니다.

사전에 있는 단어만 쓰면서도 충분히 재미있고 유익한 글을 쓸 수 있으니
단정한 문장만을 사용하여 수명이 긴 멋진 글을 공유하면 좋겠다고 생각합니다.

불필요한 축약어 쓰기

IBM은 사내에서 사용하는 도메인 용어와 축약어가 너무 많이 용어사전의 분량만 책 한 권이 나온다고 합니다.

업무 용어를 정리한 책이 있다는 것은 IBM에 새로 입사한 직원의 입장에서 썩 좋지 않습니다.
책에 적힌 단어를 모두 숙지하지 않는다면 회사에서 원활하게 소통할 수 없다는 뜻이니까요.

아무리 전문적이고 어려운 도메인을 다룬다고 할지라도, 팀에서 사용하는 용어들을 최대한 간단하고 알기 쉬운 단어로 대체하기 위해 노력하는 것이 필요합니다.

코드에서는 변수를 적극적으로 사용하기 때문에 이것이 더욱 중요합니다.
Certificate of deposit이라는 값을 변수로 작성할 때 'cd'처럼 줄임말로 변수명을 정하는 일이 흔한데,
변수의 길이가 다소 길어지더라도 cd라는 변수명 대신 CertificateOfDeposit 또는
한글명 변수로 양도성예금증서라는 변수명을 썼을 때
코드를 처음 보는 사람들이 코드의 의미를 파악하기에 훨씬 유리합니다.