"IT문화" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

어제 누가 "심링크가 뭐예요?"라고 물었고, 옆에서 누가 "symbolic link 줄임말이에요."라고 답했어요. 질문자가 잠시 멈췄어요. "아, 그래서 ln -s의 s 그 symbolic 을 말하는거군요. 근데 외국애들도 줄여쓰는군요 ?"

13글자가 7글자가 됐습니다. 그게 이상할까요? 우리는 매일 그러고 삽니다. 스타벅스에서 커피를 마시고, 점심메뉴추천을 점메추라고 부르고, 별걸 다 줄인다는 말을 별다줄이라고 줄여 씁니다. 이 글은 그 본능에 대한 짧은 메모입니다. 사실 저는 회사 후배들 말을 잘 못 알아듣고 배우는 편이에요.

유닉스가 짧게 쓰기 시작했을 때​

ls, cp, mv, rm, ln, cd. 유닉스 명령어가 이렇게 짧은 이유는 1970년대엔 짧은 게 곧 비용이었기 때문입니다. 텔레타이프 단말기는 글자 하나마다 물리적으로 키를 눌러야 했고, 300 baud 모뎀 시대엔 글자 하나가 회선을 따라 굼뜨게 흘러갔습니다. 디스크도 비쌌습니다. "list"보다 ls가 미덕이었던 시대입니다.

지금은 어떨까요. 키보드는 가볍고 회선은 빠릅니다. 타이핑 비용은 거의 0입니다. 그런데 줄임말은 사라지기는커녕 더 늘어났습니다. repository는 repo, configuration은 config, directory는 dir, environment는 env, application은 app. 더 짧아져만 갑니다.

이유는 단순합니다. 자주 쓰는 단어일수록 짧아집니다. 언어학자 Zipf가 1940년대에 정리한 규칙인데, 사용 빈도 상위로 올라갈수록 음절이 깎여나갑니다. "automobile"이 "car"가 되고, "telephone"이 "phone"이 되는 것과 같은 원리입니다. 개발자에게 repository는 너무 자주 등장하는 단어라 결국 repo가 됐습니다. 여기서는 효율이 비용을 정의합니다.

한국 사회는 이미 줄임말의 나라였다​

이런 본능은 한국어에서 더 강하게 나타납니다. 외래어가 들어오면 거의 자동으로 줄여집니다.

스타벅스는 스벅, 베스킨라빈스는 베라, 맥도날드는 맥날, 김밥, 떡볶이, 순대 세트는 김떡순입니다. 두 단어를 합치는 혼성어도 활발합니다. work-life balance가 워라밸로 들어왔고, 혼자 밥은 혼밥, 혼자 술은 혼술, 모디파이어 + 컨슈머는 모디슈머가 됐습니다. 첫 글자만 따는 패턴도 자연스럽습니다. 자만추(자연스러운 만남 추구), 노찾사(노래를 찾는 사람들), 인싸/아싸(인사이더/아웃사이더의 한국식 절단형)가 그 예입니다.

한국 IT에서만 통하는 콩글리시에서 살펴봤던 "리얼", "오픈", "커밋 때리다" 같은 표현도 사실 이 흐름의 한 갈래입니다. 영어 어휘를 빌려 와서 음절을 깎고, 한국어 문법에 녹여 넣습니다. 줄임말은 한국어 사용자의 기본 동작에 가깝습니다.

그런데 요즘은 더 짧아졌다​

알 수 없는 신조어의 시대입니다. 문제는 줄임말이 어느 시점부터 세대를 가르는 장벽이 됐다는 점입니다. 회사 톡방에서 신입이 던진 한 줄을 부장이 못 알아듣는 순간, 모두가 어색해집니다. (근데 사실 알아들어도 어색해합니다. 저만 흥미로울 뿐이에요.)

줄임말	원형
알잘딱깔센	알아서 잘 딱 깔끔하게 센스있게
군싹	군침이 싹 도노
갑통알	갑자기 통장 보니 알바해야겠다
점메추	점심 메뉴 추천
좋댓구알	좋아요, 댓글, 구독, 알림설정
별다줄	별걸 다 줄인다
만반잘부	만나서 반갑고 잘 부탁해
이생망	이번 생은 망했어
갑분싸	갑자기 분위기 싸해짐

특히 "별다줄"은 의미가 재미있습니다. 별걸 다 줄인다는 푸념을 다시 줄여서 별다줄이라고 합니다. 자기 지시적인, 메타 줄임말입니다. 더 줄일 게 없을 것 같은데도 줄이는 본능을 스스로 풍자하고 있습니다.

이 표를 처음 보는 어른이 흔히 보이는 반응이 있습니다. "왜 이렇게까지 줄이지?" 그런데 자세히 보면 음절수가 5글자 안팎입니다. 스벅이나 워라밸과 비슷합니다. 단어가 어려워서가 아니라 노출 빈도가 다를 뿐입니다. 매일 카톡과 짧은 영상에서 보면 익숙해지고, 안 보면 영원히 모릅니다. Zipf의 법칙은 사회 전체가 아니라 화자 단위로 작동합니다.

줄임말이 만들어지는 4가지 패턴​

영어든 한국어든, IT든 일상이든, 줄임말은 같은 메커니즘으로 만들어집니다.

패턴	영어/IT 예	한국어 예
혼성어 (portmanteau)	symlink, modem(modulator+demodulator), smog(smoke+fog), pixel	워라밸, 모디슈머, 혼밥, 김떡순
두문자어 (initialism)	TLDR, ASAP, JMT, FYI, CWD, WIP	자만추, 별다줄, 만반잘부, 좋댓구알
음절 절단 (clipping)	repo, config, dir, app, sudo	스벅, 베라, 맥날, 알바
메타/자기지시	"TLDR이 길다"는 농담	별다줄(별걸 다 줄인다를 줄임)

같은 칸에 IT 줄임말과 한국어 신조어가 나란히 떨어집니다. 발음 체계가 달라도 압축 본능은 똑같습니다. 알잘딱깔센은 자만추의 친척이고, 자만추는 JMT의 친척이고, JMT는 sudo의 친척이고, sudo는 결국 심링크의 친척입니다.

공식과 일상은 갈라진다​

흥미로운 건 줄임말이 정식 표현을 밀어내지 않는다는 점입니다. 둘은 평행하게 공존합니다.

man page와 POSIX 표준은 여전히 "symbolic link"라고 적습니다. 개발자끼리의 채팅창에서는 누가 봐도 symlink입니다. 9시 뉴스 앵커는 "스타벅스 코리아"라고 또렷이 발음하고, 친구끼리는 "스벅에서 봐"라고 합니다. 회사 공식 문서엔 "근로시간 단축을 위한 워크-라이프 밸런스 정책"이라 적혀 있고, 동료끼리는 "워라밸 챙기자"라고 합니다.

언어학에선 이걸 레지스터(register)라고 부릅니다. 같은 의미를 두고 격식과 친밀도에 따라 다른 표현을 골라 쓰는 것. 줄임말은 정확성을 잃은 표현이 아니라, 친밀함이라는 다른 차원이 추가된 표현입니다. 어느 한쪽이 이기는 게 아니라 둘 다 살아남습니다.

가끔은 어원이 잊힌다​

가끔은 줄임말이 너무 굳어서 원형이 통째로 잊히기도 합니다. 이메일을 매일 쓰는 사람이라도 CC와 BCC가 정확히 무엇의 줄임말인지 답하기는 쉽지 않습니다.

CC는 carbon copy의 줄임말입니다. 1960년대까지 사무실에서 같은 문서를 여러 부 만들 때 종이 사이에 먹지(carbon paper)를 끼우고 타자기로 한 번에 찍었습니다. 받는 사람 아래에 적힌 "CC: 김부장"은 "이 먹지 복사본도 김부장한테 갔다"는 표시였습니다. BCC는 blind carbon copy, 받는 사람 모르게 먹지를 한 장 더 끼운 셈입니다. 이메일이 종이 시대 동작을 그대로 옮겨오면서 이름까지 따라왔고, 카본지를 본 적 없는 세대가 매일 그 버튼을 누르고 있습니다.

이런 줄임말은 약자라는 사실 자체가 흐려집니다. symlink는 누가 봐도 줄어든 형태가 보이지만, CC는 그냥 CC입니다. 어원을 알아도 일상에서 쓰이는 의미는 달라지지 않습니다. 효율이 너무 잘 작동해서 원형이 떨어져 나간 뒤에도 단어만 혼자 살아남았습니다.

우리만 그런 게 아니다​

가끔 한국 신조어를 보고 "한국어가 너무 망가진다"고 하는 사람이 있습니다. 영어권을 보면 그 말이 머쓱해집니다.

채팅창의 lol, brb, idk, tldr, ngl, fwiw, irl, omw 같은 두문자어는 매년 옥스퍼드 사전이 정식 표제어로 추가하고 있습니다. portmanteau라는 단어 자체가 영어에 있는 것도 그쪽에서 단어를 합쳐 줄이는 일이 워낙 잦았기 때문입니다. brunch(breakfast+lunch), motel(motor+hotel), bromance(bro+romance) 같은 말은 사전에 안착한 지 오래입니다.

일본어도 못지않습니다. アルバイト는 バイト가 됐고(독일어 Arbeit가 두 단계 짧아졌다), personal computer는 パソコン이 됐습니다. KY는 空気を読めない(분위기 못 읽음)의 두문자입니다. 한자, 가나, 알파벳을 모두 동원해서 줄입니다.

그러니까 별다줄은 인류 보편 현상입니다. 한국어가 자음/모음 자모 결합형이라 음절 단위로 잘라 붙이기 좋고, 사회가 빠르고 모바일 위주라 더 활발하게 작동할 뿐입니다. 이런 본능은 어디서나 나타납니다.

그렇게 보면 심링크와 알잘딱깔센은 결국 같은 자리에서 나왔고, 그 본능은 게으름이 아니라 효율이며, 효율은 자주 줄여 쓰는 사람의 눈에만 보여요.

하루에 몇 번이나 "이슈"를 말하는가​

IT 업계에서 일하다 보면 하루에도 수십 번 "이슈"라는 단어를 들어요.

"프로덕션에 이슈가 있어요", "이슈 하나 만들어주세요", "그 이슈 어떻게 됐어요?", "고객 이슈 확인 부탁드립니다."

전부 "이슈"인데, 의미는 전부 다릅니다. 어느 순간부터 이 단어 하나가 버그, 장애, 작업 항목, 안건, 관심사, 고객 문의를 전부 커버하게 됐습니다.

같은 단어, 전혀 다른 의미​

IT 현장에서 "이슈"가 쓰이는 맥락을 나열해 보면 그 폭이 꽤 넓습니다. "프로덕션에 이슈가 있습니다"는 서비스에 실제 문제가 터졌다는 뜻으로, 가장 긴장되는 용법입니다. "이슈 하나 생성해주세요"의 이슈는 버그일 수도, 기능 요청일 수도, 단순 작업일 수도 있습니다. Jira가 모든 작업 단위를 "Issue"라고 부르기 때문에 생긴 용법입니다. GitHub도 마찬가지여서 "이슈 올렸습니다"의 이슈에는 버그 리포트와 질문, 기능 제안, 토론 주제가 전부 들어갑니다. 회의에서 "그 이슈 진행 상황이 어떻게 됐죠?"라고 하면 추적 중인 관심사나 논의 사항을 가리키고, "고객 이슈 처리해주세요"의 이슈는 문의와 불만, 장애 신고, 기능 요청까지 포괄합니다.

듣는 사람은 매번 맥락으로 의미를 추론해야 합니다. 대부분은 자연스럽게 되지만, 가끔 "그 이슈요? 어떤 이슈요?"라는 되물음이 나오는 건 이 때문입니다.

"issue"는 원래 이런 뜻이 아니었다​

영어 "issue"의 본래 의미는 "발행(issuance)"이나 "쟁점(matter in dispute)" 쪽에 가깝습니다. 그런데 어느 시점부터 "problem"을 대체하는 완곡 표현으로 자리 잡았습니다.

"We have a problem"은 심각하게 들립니다. "We have an issue"는 같은 상황인데도 좀 더 관리 가능하고, 덜 위협적인 느낌을 줍니다. 이 미묘한 뉘앙스 차이 때문에 비즈니스와 IT 영역에서 "issue"가 "problem"의 자리를 빠르게 대체했습니다.

영어권에서도 이 남용은 꽤 오래전부터 지적받아 왔습니다. "Call it what it is — it's a problem, not an issue"라는 류의 비판은 IT 커뮤니티에서 흔하게 보입니다.

한국 IT에서 더 두드러지는 이유​

영어권에서는 맥락에 따라 "bug", "ticket", "concern", "topic", "item", "incident" 같은 단어가 자연스럽게 섞여 쓰입니다. 세분화된 대안이 있고, 실제로 구분해서 쓰는 경우가 많습니다.

한국어에도 "문제", "건", "안건", "사안", "장애", "결함" 같은 표현이 있습니다. 그런데 IT 현장에서는 이런 단어들 대신 "이슈"가 거의 전부를 흡수해버렸습니다. 외래어 차용 과정에서 원어가 가진 여러 뉘앙스 중 가장 넓은 의미만 수입된 셈입니다.

Jira와 GitHub의 영향도 큽니다. IT 조직 대부분이 Jira와 GitHub를 쓰고, 둘 다 기본 작업 단위가 "Issue"이기 때문에, 자연스럽게 모든 작업 항목 = 이슈라는 등식이 굳어졌습니다.

문제가 되는 건 아니지만​

솔직히 대부분의 경우 의사소통에 큰 문제는 없어요. 맥락이 충분히 보충해 주기 때문입니다.

하지만 가끔은 의식적으로 단어를 구분해 쓰는 것이 커뮤니케이션 품질을 높여 줍니다. 장애가 발생했으면 "장애"라고 하는 게 긴박감을 전달합니다. 단순 작업 요청이면 "티켓"이나 "작업"이 더 정확합니다. 회의에서 논의할 주제라면 "안건"이 맞습니다.

만능 단어는 편해요. 다만 장애를 "장애"라고 부르는 순간 전달되는 긴박감까지 대신해 주지는 못해요.

한국에서 IT를 하다 보면 콩글리시를 많이 써요. 운영 환경을 "리얼 환경"이라고 하고 서비스 출시를 "오픈"이라고 하는데, 처음에는 어색해도 몇 달 지나면 자연스럽게 입에 붙어요. 그러다 어느 순간 영어권에서는 통하지 않는다는 사실을 잊게 돼요.

환경 이름부터 다르다​

**"리얼(real)"**은 한국 IT에서 가장 널리 쓰이는 콩글리시 중 하나입니다. "리얼 환경에 반영했습니다", "리얼 DB 접속 정보 주세요"처럼 쓰며, 여기서 리얼은 운영(production) 환경을 뜻합니다.

영어권에서는 production, 줄여서 prod라고 합니다. "real"이라는 표현을 쓰면 "진짜?"라는 반응이 돌아올 수 있습니다. 의미는 통할 수 있겠지만, 업계 용어로는 쓰이지 않습니다.

비슷한 맥락에서 스테이징(staging)은 그대로 쓰이고, 개발 환경은 데브(dev)라고 부릅니다. 그런데 유독 운영 환경만 "리얼"이 된 점은 재미있습니다.

동사로 쓰이는 영어 명사들​

한국 IT 현장에서는 영어 명사를 한국어 동사처럼 활용하는 패턴이 많습니다.

"커밋 때리다"는 git commit을 한다는 말입니다. "때리다"가 붙으면서 묘한 역동성이 생깁니다. "머지 태우다"는 merge를 수행한다는 뜻인데, "태우다"가 왜 붙었는지는 아무도 모르지만 다들 자연스럽게 씁니다.

빌드를 실행할 때는 "빌드 돌리다"라고 합니다. 그나마 직관적인 표현입니다. deploy한다는 뜻의 "배포 나가다"도 있습니다. "이번 주말에 배포 나갑니다"처럼 쓰며, 배포가 어딘가로 출타하는 느낌을 줍니다.

이런 표현들은 영어 단어를 쓰고 있지만 영어권에서는 통하지 않습니다. "I hit a commit"이라고 하면 상대방이 멈칫할 것입니다.

의미가 미묘하게 비틀린 단어들​

어떤 콩글리시는 영어 원어와 의미가 살짝 다르게 정착했습니다.

영어에서 spec은 specification, 즉 기술 명세를 뜻합니다. 한국 IT에서도 **"스펙(spec)"**을 그 의미로 쓰지만, "이번 스펙 좀 큰데요?"처럼 작업 범위(scope)나 난이도를 가리키기도 합니다.

**"컨펌(confirm)"**은 조금 다릅니다. "컨펌 받았어요?"는 승인(approval)을 받았느냐는 뜻입니다. 영어의 confirm은 "확인하다"에 가깝고 승인의 뉘앙스는 약하니, approve와 confirm이 하나로 합쳐진 셈입니다.

"레퍼런스(reference) 있어요?"라고 하면 참고 사례나 선례를 묻는 것입니다. 영어에서도 비슷하게 쓰이지만, 한국에서는 거의 "벤치마크 대상" 수준으로 의미가 확장되었습니다. **"피드백(feedback)"**은 영어와 크게 다르지 않지만, 한국에서는 "피드백 주세요"가 사실상 "검토 후 의견 주세요"와 "수정 요청"을 함께 의미하는 경우가 많습니다. 칭찬이 섞인 피드백을 기대했다가 수정 사항 목록을 받는 일도 흔합니다.

아예 영어권에 존재하지 않는 표현들​

"서비스 오픈했습니다"의 **"오픈(open)"**은 서비스를 출시(launch)했다는 뜻입니다. 영어에서 "We opened the service"라고 하면 어딘가의 문을 열었다는 느낌을 줍니다. 영어권에서는 launch, release, go live 등을 씁니다. 반대말로 쓰이는 "클로즈(close)"는 서비스 종료를 뜻하며, 영어에서는 shut down, sunset, deprecate 등이 자연스럽습니다.

"사인 부탁드립니다"의 **"사인(sign)"**은 결재 승인을 의미하기도 합니다. sign-off에서 온 듯하지만, 한국에서는 그냥 "사인"으로 줄었습니다. "이 건 핸들링 잘 해주세요"라는 말도 자주 들립니다. 영어에서도 handle은 "처리하다"라는 뜻으로 쓰이지만, 한국의 "핸들링(handling)"에는 특히 민감한 상황을 조심스럽게 다룬다는 뉘앙스가 강하게 실립니다.

협업에서 튀어나오는 영어 동사형​

회의나 협업 맥락에서는 또 다른 결의 콩글리시가 쏟아집니다. IT뿐 아니라 대기업 사무실 전반에서 공유되는 어휘라 "판교 사투리"라는 별명으로 유명하기도 합니다.

"이 건 팔로우업 부탁드려요"의 **"팔로우업(follow-up)하다"**는 끝까지 챙겨 경과를 확인해 달라는 뜻입니다. 영어에서 follow up은 동사구지만, 한국에서는 "팔로우업"이라는 명사형으로 굳은 뒤 "하다"가 붙었습니다.

"이 건에 디자인팀도 인볼브시켜주세요"라고 하면 참여/관여시키라는 의미입니다. 영어 involve는 주로 수동태인 "be involved in"처럼 쓰지만, 한국에서는 **"인볼브(involve)하다"**를 능동형으로 자연스럽게 씁니다. 발음이 살짝 꺾여 "인발브"로 들리는 경우도 흔합니다. **"어사인(assign)하다"**는 배정하다, 할당한다는 뜻이며 "이 티켓 저한테 어사인 해주세요"처럼 Jira 티켓을 배정하는 맥락에서 가장 자주 튀어나옵니다.

"팀 간 얼라인 좀 맞춰야 해요"라는 말은 방향이나 의견을 일치시키자는 뜻입니다. 영어 align 자체에 이미 "맞추다"라는 의미가 있지만, **"얼라인(align) 맞추다"**에는 한국어 "맞추다"가 한 번 더 붙습니다. "이 프로젝트는 제가 드라이브 하겠습니다"의 **"드라이브(drive)하다"**에는 적극적으로 이끌고 가겠다는 선언이 담깁니다. 영어 drive에도 비슷한 의미가 있지만, 한국에서는 프로젝트 소유권을 가져가겠다는 뉘앙스가 강합니다.

"아삽(ASAP)" — as soon as possible을 한국어 발음으로 읽어 명사처럼 쓴 표현입니다. "이거 아삽으로 부탁드려요"처럼 말합니다. 영어권에서도 ASAP을 쓰지만, "으로"라는 조사가 붙는 방식은 한국식입니다.

왜 이렇게 됐을까​

몇 가지 이유가 겹쳐 있습니다.

첫째, IT 기술 자체가 영어권에서 왔기 때문에 원어를 그대로 가져오는 일이 자연스러웠습니다. 번역하면 오히려 어색하거나 의미가 달라지는 경우도 많습니다. "커밋"을 "확정"이라고 하면 git commit인지 알아보기 어렵습니다.

둘째, 영어 원어를 가져오되 한국어 문법에 맞게 변형하는 과정에서 독자적인 표현이 만들어졌습니다. "머지 태우다"나 "배포 나가다"는 영어 명사를 한국어 구어 패턴에 녹인 결과입니다.

셋째, 빠른 커뮤니케이션이 필요한 환경에서 짧고 함축적인 표현이 살아남았습니다. "운영 환경"보다 "리얼"이 한 음절 더 짧고, "서비스 출시"보다 "오픈"이 빠릅니다.

문제라기보다는 특징​

이런 콩글리시가 나쁘다는 건 아닙니다. 같은 맥락을 공유하는 사람들 사이에서는 오히려 효율적인 소통 수단입니다. 다만 두 가지 상황에서는 주의가 필요합니다.

영어권 동료나 파트너와 소통할 때 — "리얼 환경"을 "real environment"로 직역하면 의미가 전달되지 않습니다. 이때는 production이라고 바꿔 써야 합니다.

신입이나 비개발 직군과 소통할 때 — 이미 IT 콩글리시에 익숙한 사람끼리는 문제가 없지만, 처음 접하는 사람에게 "리얼에 배포 나갔는데 터졌어요"는 암호에 가깝습니다.

결국 필요한 건 규칙보다 자각이에요. 제가 지금 콩글리시를 쓰고 있다는 걸 알고만 있으면, 영어권 동료 앞에서는 production으로, 처음 접하는 신입 앞에서는 풀어 쓴 한국어로 바꿀 여지가 생겨요.