본문으로 건너뛰기

"용어" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

모든 태그 보기

Slop과 fallback

· 약 4분

요즘 SNS 피드를 내리다 보면 AI가 만든 게 분명한 어색한 이미지와 영상, 이를테면 손가락이 여섯 개인 사진이나 표정이 이상한 동물, 맥락 없이 감동만 강요하는 그림이 줄줄이 지나가요. 이걸 가리키는 단어가 따로 있다는 걸 최근에야 알았어요. 슬롭(Slop) — 2025년 영국 이코노미스트, 미국 메리엄웹스터, 호주 매쿼리 사전이 모두 올해의 단어로 뽑은 신조어입니다.

세 군데가 같은 해에 같은 단어를 골랐다는 사실은 좀 무섭습니다. 단어 하나로 한 해를 요약해 버린 셈이기 때문입니다.

원래 뜻은 음식물 찌꺼기

영어 slop은 본래 음식물 쓰레기, 진창, 돼지에게 주는 먹이 찌꺼기를 가리킵니다. 1700년대에는 무른 진흙을 부르는 말이었고, 1800년대에 들어 음식 찌꺼기, 그리고 "값싸고 가치 없는 것" 일반으로 의미가 번졌습니다.

말 그대로 흘려보내는 더러운 액체에 가까운 어감입니다. 그 단어를 2025년 들어 AI 시대의 콘텐츠를 가리키는 비유로 다시 꺼내 든 것입니다. 비유가 너무 적나라해서 한 번 들으면 잘 잊히지 않습니다.

AI 슬롭이 뭔가

이코노미스트는 슬롭을 생성형 AI가 사용자가 요청하지도 않았는데 대량으로 찍어내는 저품질 콘텐츠로 정리했습니다. 조건은 세 가지가 함께 맞아야 합니다. 우선 사람이 만들었다면 들어갔을 시간/노력 없이 한 번에 수천 장이 쏟아집니다. 그렇게 나온 결과물은 손가락이 여섯 개거나, 사실관계가 틀렸거나, 맥락이 이상합니다. 결정적으로 정성이 없습니다. 제 글도 정성이 없기는 마찬가지지만 저는 적어도 글을 쓰고 한 번 읽어는 봅니다. 마지막으로 이런 것들이 검색 결과 상단이나 SNS 피드, 자동 생성 기사 같은 곳에서 원치 않아도 눈에 밟힙니다.

세 조건이 다 맞아야 슬롭입니다. AI로 만들었다고 다 슬롭은 아닙니다. 누가 의도를 가지고 편집한 결과물은 다른 이야기입니다.

스팸의 21세기 버전

슬롭은 자주 스팸과 비교됩니다. 둘 다 받는 사람 동의 없이 정보 채널을 점거한다는 점에서 닮았습니다.

다만 스팸은 무차별 광고였고, 슬롭은 콘텐츠 그 자체입니다. 더 교묘합니다. 스팸은 광고라는 걸 숨기지 않지만, 슬롭은 정상 글, 사진, 영상인 척 피드에 섞여 듭니다. 영어권에서는 둘을 합쳐 슬롬(Slop + Spam) 이라는 파생어까지 만들어 씁니다.

왜 하필 2025년이었나

이코노미스트, 메리엄웹스터, 매쿼리가 같은 해에 같은 단어를 골랐습니다. 평소에는 사전사마다 색깔이 다른데, 2025년만큼은 합의를 본 셈입니다.

이코노미스트의 진단은 분명합니다. AI 콘텐츠 생산자는 거의 비용 없이 찍어내지만, 이용자 쪽에는 진짜 정보를 가려내는 인지 비용 이 새로 붙습니다. 검색 한 번에 진짜 후기와 AI가 짜깁기(짜집기는 잘못된 표현)한 가짜 후기를 가려야 하고, 친구가 공유한 사진이 실사인지 합성인지 의심해야 합니다. 사회 전체로 보면 거대한 외부 비용입니다.

흥미로운 건 그다음입니다. 슬롭이 넘쳐날수록 신문/방송 같은 검증된 전통 매체에 대한 신뢰가 오히려 올라갈 수 있습니다. 이코노미스트는 그렇게 짚습니다. AI 사진과 실제 작가 사진을 구분하는 어떤 실험에서 사람들은 신뢰할 만한 매체가 만든 콘텐츠라면 더 큰 비용을 낼 수 있다고 답했다고 합니다. 정보가 넘칠수록 큐레이션 자체에 값이 매겨지는 구조입니다.

같은 해 옥스포드 사전 후보에는 vibe coding (AI에게 자연어로 시켜 코드 짜기), glazing (LLM이 사용자에게 과도하게 아부하는 현상, 썩 싫지만은 않습니다.), clanker (로봇/AI를 비하해 부르는 호칭) 같은 단어가 나란히 올랐습니다. 슬롭 하나만 도드라진 게 아니라 한 해 어휘 자체를 AI가 점령했던 셈입니다.

슬롭 폴백, 모르면 그럴듯하게 메우는 회로

엔지니어 입장에서 슬롭이 더 매서워지는 지점이 따로 있습니다. 슬롭 폴백(slop fallback) 이라는 표현입니다. LLM이 잘 모르거나 답이 막혔을 때, "모르겠다"고 말하는 대신 그럴듯한 문장으로 빈칸을 채워 넘기는 동작을 가리키는 말입니다. 사전 등재어는 아니고 영어권 엔지니어 사이에서 농담 반 진담 반으로 굳어진 쓰임입니다.

흔히 말하는 환각(hallucination)과는 결이 살짝 다릅니다. 환각이 "사실관계가 틀린 출력"이라는 결과론에 가깝다면, 슬롭 폴백은 "막히면 슬롭으로 떨어지는" 시스템 동작 패턴 자체를 짚습니다. 모델이 모르겠다고 답하면 사용자 만족도가 떨어지니까, 학습/튜닝 과정에서 자신감 있는 헛소리 쪽으로 슬며시 기울게 된다는 진단입니다. Antislop 같은 연구가 LLM 출력의 반복 패턴을 억제하려 하는 것도 결국 이 악순환의 고리를 끊으려는 시도입니다.

문제는 이 폴백이 사람한테도 그대로 옮겨붙는다는 데 있습니다. AI 어시스턴트로 일하다 보면, 자료를 충분히 찾기 싫을 때 "AI한테 한 번 시켜보고 그럴듯한 게 나오면 그대로 가자"는 유혹이 생깁니다. 본인이 직접 슬롭 폴백 회로의 한 부품이 되는 셈입니다. 저는 도구의 결함보다 이쪽이 더 신경 쓰여요.

도구를 쓰는 입장에서

매일 Claude Code로 문서 초안을 잡고, 이미지 도구를 쓰고, 검색 결과를 참고하는 사람으로서 이 단어를 가볍게 넘기기 어렵고, 제가 만들고 있는 게 슬롭이 아닌지 자꾸 자문하게 돼요.

기준이 있다고 봅니다. AI를 써서 뽑은 결과물에 누가 읽을지, 어떤 가치를 줄지 한 번이라도 생각이 들어갔다면 슬롭이 아닙니다. 사람이 손을 댄 흔적, 의도와 편집이 묻은 흔적이 있으면 결 자체가 다릅니다. 반대로 광고 수익이나 SEO를 위해 양만 찍어내는 자동 생성물은 그대로 슬롭에 가깝습니다.

같은 도구를 써도 결과물의 격은 도구를 쥔 사람의 태도에서 갈립니다. 무엇을 남기고 무엇을 버릴지 결정하는 편집 감각이 AI 시대 글쓰기에서 정작 가장 비싼 자원인지도 모릅니다.

단어가 생기면 비로소 보인다

매년 사전이 발표하는 올해의 단어는 그해의 정서를 한 단어로 압축해 놓은 결과입니다. 2024년이 brain rot이었다면, 2025년은 슬롭입니다.

저질 콘텐츠 자체가 새로 생긴 현상은 아닙니다. 다만 AI가 그 생산 단가를 0에 수렴시켰다는 것, 그리고 그걸 부르는 이름이 생겼다는 게 2025년의 차입니다. 이름이 붙으면 비로소 보이고, 보이면 거를 수 있습니다. 슬롭이라는 단어를 알게 된 것만으로 의외로 쓸 만한 정신 도구가 하나 늘었습니다.

피드를 내리다 보면 이게 슬롭인가 싶어 멈칫하는 순간이 있고, 그 멈칫이 한 번 생기고 나면 그다음부터는 시간을 덜 빼앗겨요.

IT 만능어 '이슈'

· 약 3분

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

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에서만 통하는 콩글리시 모음

· 약 5분

한국에서 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으로, 처음 접하는 신입 앞에서는 풀어 쓴 한국어로 바꿀 여지가 생겨요.