[{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"AI 코딩 에이전트를 쓰지 않고 하루를 보내기가 점점 어려워진다. IDE를 열면 인라인 추천이 뜨고, 복잡한 작업은 Claude Code나 Cursor에게 맡기는 게 자연스럽다. 속도는 확실히 빨라졌다. 문제는 이 과정에서 조용히 줄어드는 무엇이 있다는 거다.\n\u0026ldquo;AI를 잘 쓰려면 AI 없이도 잘해야 한다\u0026quot;는 역설 # 최근 본 두 편의 글이 같은 지점을 짚고 있었다. 표현은 다른데 결론은 비슷했다.\n하나는 evan-moon의 AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일. 핵심은 한 문장으로 요약된다.\nAI를 가장 잘 활용할 수 있는 개발자는, AI 없이도 코드를 판단할 수 있는 개발자다.\n처음 들으면 당연한 말 같다. 그런데 곱씹어보면 불편한 이야기다. AI 에이전트가 완성된 코드를 바로 뱉어주는 환경에서만 성장한 개발자일수록, 그 출력물이 좋은지 나쁜지를 판단할 근거 지식이 약해진다. \u0026ldquo;AI를 많이 쓸수록 AI를 잘 쓰기 어려워진다\u0026quot;는 역설이 생긴다.\n뇌는 편한 길로 흐른다 # 이 역설은 뇌과학으로도 설명된다. evan-moon의 글은 세 가지 개념을 끌어온다.\n바람직한 어려움(desirable difficulties) — 로버트 비요크의 연구다. 적절한 난이도의 도전이 장기 기억 형성을 촉진한다는 것. 편하게 받아들인 정보는 오래 남지 않는다.\n인출 연습(retrieval practice) — 반복해서 읽는 것보다 스스로 기억을 떠올리는 쪽이 일주일 뒤 기억 보존율을 크게 끌어올린다. 수동적 읽기와 능동적 학습은 전혀 다른 행위다.\n청킹(chunking) — 체스 전문가의 뇌는 초보자와 같은 조각을 보면서도 한 덩어리로 압축해 인지한다. 패턴을 직접 조합해본 경험 없이는 이런 청크가 형성되지 않는다.\nAI가 완성된 코드를 즉시 뱉어주면, 이 세 가지 과정이 전부 건너뛰어진다. 난이도는 사라지고, 기억을 인출할 일도 없고, 패턴을 조합해 청크로 압축할 기회도 없다. 속도는 빨라지는데 숙련은 느려진다.\n그리고 뇌에는 기본값이 하나 있다. 에너지를 아끼는 쪽으로 흐른다는 것. 편한 길이 있으면 그쪽으로 간다. 의식적으로 저항하지 않으면 AI에 의존하는 것은 자연스러운 결과다.\n52명으로 진행한 무작위 대조 시험 # 이론만으로 끝나는 이야기는 아니다. 2026년 2월, Anthropic이 같은 주제로 직접 실험을 했다. Python 경력 1년 이상의 개발자 52명(대부분 주니어)을 무작위로 두 그룹에 배치하고, Trio 비동기 라이브러리를 활용한 과제를 주었다. 한쪽은 AI 어시스턴트를 자유롭게 썼고, 한쪽은 손으로만 작성했다.\n결과는 선명했다.\n과제 완료 속도: AI 그룹이 평균 2분 빠름 (통계적 유의성 없음) 과제 후 개념 퀴즈 점수: AI 그룹 50%, 수동 그룹 67% 가장 큰 격차가 벌어진 영역: 디버깅 속도 차이는 거의 없었는데, 이해도에서 17%p 차이가 났다. Anthropic은 이 현상에 이름을 붙였다. 인지적 오프로딩(cognitive offloading). AI에게 작업을 떠넘기는 만큼 뇌의 개입이 줄고, 그만큼 학습도 줄어든다. Psychology Today의 표현을 빌리면, \u0026ldquo;뇌를 온전히 써서 작업하는 사람보다 정신적 참여도가 낮아지는 현상\u0026quot;이다.\n더 흥미로운 건 AI 그룹 안에서의 편차가 컸다는 점이다. 생성된 코드를 그대로 복사해 넘긴 참가자들은 40% 이하의 점수를 받았지만, AI에게 개념적인 질문을 먼저 던지거나 생성된 코드의 이유를 되짚어본 참가자들은 수동 코딩 그룹과 비슷하거나 더 높은 점수를 기록했다.\n즉, AI 자체가 문제가 아니었다. 어떻게 쓰느냐가 문제였다.\n브루클린의 3개월 코딩 수련 # 같은 시기에 다른 각도에서 쓴 글이 있다. 스페인 바르셀로나의 Aily Labs에서 2년간 AI 에이전트를 개발하던 Miguel Conner가 I\u0026rsquo;m Coding by Hand라는 글을 올렸다. 뉴욕 브루클린 Recurse Center의 6주 리트릿 기록이다.\nAI 에이전트를 만들던 사람이 리트릿에서 하고 있는 건 의외로 복고적이다.\nCS336 과정을 따라 토크나이저와 GPT-2 모델을 직접 작성 1983년산 Apple IIe에서 BASIC으로 FizzBuzz Vim 하나로 단층 퍼셉트론 코딩 CTF 워게임으로 Unix 터미널 손에 익히기 10년 경력 개발자들과 페어 프로그래밍 AI 에이전트로 5분이면 찍어낼 수 있는 것들을 일부러 손으로 만든다. 그의 요지도 결국 같은 자리에 도착한다. 에이전트에 명령만 잘 내리는 것과, 코드베이스를 깊이 이해하는 것은 다른 활동이라는 거다. 손으로 만들어야만 머릿속에 남는 층이 있다.\n일상과 훈련을 분리하기 # 그렇다고 AI를 끄고 살 수는 없다. 마감도 있고, 동료들도 다 쓴다. 현실적인 타협점은 일상 업무와 의도적 훈련을 분리하는 데 있다.\n일상 업무에서는 AI를 적극 쓴다. 대신 습관 두세 가지를 얹는다.\nPR을 올리기 전에 AI가 만든 코드의 의도를 한 번은 스스로 복기한다. 한 줄씩 읽으면서 \u0026ldquo;내가 썼다면 왜 이렇게 썼을까\u0026quot;를 묻는다. 잘 모르는 영역을 처음 만질 때는 AI에게 완성을 맡기기 전에 최소 단위를 직접 작성해본다. 10분짜리 실습이면 충분하다. 주기적으로 AI 없는 시간을 둔다. 하루 중 1시간이든, 주말이든, 새 언어를 익히는 동안이든. 운동과 비슷하다. 엘리베이터를 탄다고 계단을 영영 안 오르면 몸이 굳는다. 일부러 계단을 오르는 시간을 따로 마련해야 한다.\n불편함이 곧 조건 # 편한 도구가 많아질수록, 일부러 불편함을 만드는 게 오히려 전문가의 기술이 된다. AI가 가장 강력한 순간은 한 가지 조건에서만 온다. 판단할 수 있는 사람이 레버리지로 쓸 때. 그리고 그 판단력은 역설적으로 AI가 없을 때 만들어진다.\n결국 질문은 단순하다. 나는 오늘 어디에서 어려움을 우회했고, 어디에서 일부러 계단을 올랐는가.\n참고한 글 / 연구\nevan-moon, AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일 — 뇌과학적 근거로 풀어낸 성찰 Miguel Conner, I\u0026rsquo;m Coding by Hand — Recurse Center 리트릿 기록 Anthropic, How AI assistance impacts the formation of coding skills (2026-02) — 52명 RCT 연구 원문 Shen \u0026amp; Tamkin, How AI Impacts Skill Formation — 위 연구의 논문 버전 Psychology Today, Cognitive Offloading: Using AI Reduces New Skill Formation — 인지적 오프로딩 개념 해설 InfoQ, Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17% — 연구 요약 기사 개인 블로그 두 편은 GeekNews를 통해 접했다. ","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/posts/ai-developer-cognition/","section":"Posts","summary":"AI 코딩 에이전트가 기본값이 된 시대, 정작 AI를 잘 쓰는 핵심은 ‘AI 없이도 코드를 판단하는 힘’이다. 편해질수록 약해지는 것에 대한 메모.","title":"AI와 공존하는 개발자의 사고력","type":"posts"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/","section":"dbalog journal","summary":"","title":"dbalog journal","type":"page"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/%EA%B0%9C%EB%B0%9C/","section":"Tags","summary":"","title":"개발","type":"tags"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/%EB%87%8C%EA%B3%BC%ED%95%99/","section":"Tags","summary":"","title":"뇌과학","type":"tags"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/%EC%82%AC%EA%B3%A0%EB%A0%A5/","section":"Tags","summary":"","title":"사고력","type":"tags"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/categories/%EC%83%9D%EA%B0%81/","section":"Categories","summary":"","title":"생각","type":"categories"},{"content":"","date":"2026년 4월 20일","externalUrl":null,"permalink":"/journal/tags/%ED%95%99%EC%8A%B5/","section":"Tags","summary":"","title":"학습","type":"tags"},{"content":"","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/tags/it%EB%AC%B8%ED%99%94/","section":"Tags","summary":"","title":"IT문화","type":"tags"},{"content":" 하루에 몇 번이나 \u0026ldquo;이슈\u0026quot;를 말하는가 # IT 업계에서 일하다 보면 하루에도 수십 번 \u0026ldquo;이슈\u0026quot;라는 단어를 듣는다.\n\u0026ldquo;프로덕션에 이슈가 있어요\u0026rdquo;, \u0026ldquo;이슈 하나 만들어주세요\u0026rdquo;, \u0026ldquo;그 이슈 어떻게 됐어요?\u0026rdquo;, \u0026ldquo;고객 이슈 확인 부탁드립니다.\u0026rdquo;\n전부 \u0026ldquo;이슈\u0026quot;인데, 의미는 전부 다르다. 어느 순간부터 이 단어 하나가 버그, 장애, 작업 항목, 안건, 관심사, 고객 문의를 전부 커버하게 됐다.\n같은 단어, 전혀 다른 의미 # IT 현장에서 \u0026ldquo;이슈\u0026quot;가 쓰이는 맥락을 나열해 보면 그 폭이 꽤 넓다.\n장애/버그 — \u0026ldquo;프로덕션에 이슈가 있습니다.\u0026rdquo; 서비스에 실제 문제가 발생했다는 뜻이다. 가장 긴장되는 용법.\nJira 티켓 — \u0026ldquo;이슈 하나 생성해주세요.\u0026rdquo; 여기서 이슈는 버그일 수도, 기능 요청일 수도, 단순 작업일 수도 있다. Jira가 모든 작업 단위를 \u0026ldquo;Issue\u0026quot;라고 부르기 때문에 생긴 용법이다.\nGitHub Issue — \u0026ldquo;이슈 올렸습니다.\u0026rdquo; 버그 리포트, 질문, 기능 제안, 토론 주제 — 전부 Issue다.\n회의 안건 — \u0026ldquo;그 이슈 진행 상황이 어떻게 됐죠?\u0026rdquo; 추적 중인 관심사나 논의 사항을 가리킨다.\n고객 대응 — \u0026ldquo;고객 이슈 처리해주세요.\u0026rdquo; 문의, 불만, 장애 신고, 기능 요청 등을 포괄한다.\n듣는 사람은 매번 맥락으로 의미를 추론해야 한다. 대부분은 자연스럽게 되지만, 가끔 \u0026ldquo;그 이슈요? 어떤 이슈요?\u0026ldquo;라는 되물음이 나오는 건 이 때문이다.\n\u0026ldquo;issue\u0026quot;는 원래 이런 뜻이 아니었다 # 영어 \u0026ldquo;issue\u0026quot;의 본래 의미는 \u0026ldquo;발행(issuance)\u0026ldquo;이나 \u0026ldquo;쟁점(matter in dispute)\u0026rdquo; 쪽에 가깝다. 그런데 어느 시점부터 \u0026ldquo;problem\u0026quot;을 대체하는 완곡 표현으로 자리 잡았다.\n\u0026ldquo;We have a problem\u0026quot;은 심각하게 들린다. \u0026ldquo;We have an issue\u0026quot;는 같은 상황인데도 좀 더 관리 가능하고, 덜 위협적인 느낌을 준다. 이 미묘한 뉘앙스 차이 때문에 비즈니스와 IT 영역에서 \u0026ldquo;issue\u0026quot;가 \u0026ldquo;problem\u0026quot;의 자리를 빠르게 대체했다.\n영어권에서도 이 남용은 꽤 오래전부터 지적받아 왔다. \u0026ldquo;Call it what it is — it\u0026rsquo;s a problem, not an issue\u0026quot;라는 류의 비판은 IT 커뮤니티에서 흔하게 보인다.\n한국 IT에서 더 두드러지는 이유 # 영어권에서는 맥락에 따라 \u0026ldquo;bug\u0026rdquo;, \u0026ldquo;ticket\u0026rdquo;, \u0026ldquo;concern\u0026rdquo;, \u0026ldquo;topic\u0026rdquo;, \u0026ldquo;item\u0026rdquo;, \u0026ldquo;incident\u0026rdquo; 같은 단어가 자연스럽게 섞여 쓰인다. 세분화된 대안이 있고, 실제로 구분해서 쓰는 경우가 많다.\n한국어에도 \u0026ldquo;문제\u0026rdquo;, \u0026ldquo;건\u0026rdquo;, \u0026ldquo;안건\u0026rdquo;, \u0026ldquo;사안\u0026rdquo;, \u0026ldquo;장애\u0026rdquo;, \u0026ldquo;결함\u0026rdquo; 같은 표현이 있다. 그런데 IT 현장에서는 이런 단어들 대신 \u0026ldquo;이슈\u0026quot;가 거의 전부를 흡수해버렸다. 외래어 차용 과정에서 원어가 가진 여러 뉘앙스 중 가장 넓은 의미만 수입된 셈이다.\nJira와 GitHub의 영향도 크다. IT 조직 대부분이 Jira와 GitHub를 쓰고, 둘 다 기본 작업 단위가 \u0026ldquo;Issue\u0026quot;이기 때문에, 자연스럽게 모든 작업 항목 = 이슈라는 등식이 굳어졌다.\n문제가 되는 건 아니지만 # 솔직히 대부분의 경우 의사소통에 큰 문제는 없다. 맥락이 충분히 보충해 주기 때문이다.\n하지만 가끔은 의식적으로 단어를 구분해 쓰는 것이 커뮤니케이션 품질을 높여 준다. 장애가 발생했으면 \u0026ldquo;장애\u0026quot;라고 하는 게 긴박감을 전달한다. 단순 작업 요청이면 \u0026ldquo;티켓\u0026quot;이나 \u0026ldquo;작업\u0026quot;이 더 정확하다. 회의에서 논의할 주제라면 \u0026ldquo;안건\u0026quot;이 맞다.\n만능 단어가 편리하긴 하지만, 정확한 단어가 주는 명확함까지 대체하지는 못한다.\n","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/posts/it-issue-word/","section":"Posts","summary":"버그도 이슈, 티켓도 이슈, 안건도 이슈, 고객 문의도 이슈. IT 업계에서 ‘이슈’가 만능 단어가 된 이유를 영어권 맥락까지 포함해서 정리해 본다.","title":"IT에서 '이슈'는 왜 이렇게 만능 단어가 됐을까","type":"posts"},{"content":"","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/tags/%EC%9A%A9%EC%96%B4/","section":"Tags","summary":"","title":"용어","type":"tags"},{"content":"","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/categories/%EC%9E%A1%EB%8B%B4/","section":"Categories","summary":"","title":"잡담","type":"categories"},{"content":"","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/tags/%EC%BB%A4%EB%AE%A4%EB%8B%88%EC%BC%80%EC%9D%B4%EC%85%98/","section":"Tags","summary":"","title":"커뮤니케이션","type":"tags"},{"content":"","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/tags/%EC%BD%A9%EA%B8%80%EB%A6%AC%EC%8B%9C/","section":"Tags","summary":"","title":"콩글리시","type":"tags"},{"content":"한국에서 IT를 하다 보면 콩글리시를 많이 쓴다. 운영 환경을 \u0026ldquo;리얼 환경\u0026quot;이라고 하고, 서비스 출시를 \u0026ldquo;오픈\u0026quot;이라고 한다. 처음 들으면 어색한데, 몇 달 지나면 자연스럽게 입에 붙는다. 그리고 어느 순간 이게 영어권에서는 안 통한다는 사실을 잊게 된다.\n환경 이름부터 다르다 # \u0026ldquo;리얼(real)\u0026rdquo; — 한국 IT에서 가장 널리 쓰이는 콩글리시 중 하나다. \u0026ldquo;리얼 환경에 반영했습니다\u0026rdquo;, \u0026ldquo;리얼 DB 접속 정보 주세요\u0026rdquo; 식으로 쓴다. 여기서 리얼은 운영(production) 환경을 뜻한다.\n영어권에서는 production, 줄여서 prod라고 한다. \u0026ldquo;real\u0026quot;이라는 표현을 쓰면 \u0026ldquo;진짜?\u0026ldquo;라는 반응이 돌아올 수 있다. 의미는 통할 수 있겠지만, 업계 용어로는 쓰이지 않는다.\n비슷한 맥락에서 스테이징(staging)은 그대로 쓰이고, 개발 환경은 데브(dev)라고 부른다. 그런데 유독 운영 환경만 \u0026ldquo;리얼\u0026quot;이 된 건 재미있는 현상이다.\n동사로 쓰이는 영어 명사들 # 한국 IT 현장에서는 영어 명사를 한국어 동사처럼 활용하는 패턴이 많다.\n\u0026ldquo;커밋 때리다\u0026rdquo; — git commit을 하다. \u0026ldquo;때리다\u0026quot;라는 표현이 붙으면서 묘한 역동성이 생긴다.\n\u0026ldquo;머지 태우다\u0026rdquo; — merge를 수행하다. \u0026ldquo;태우다\u0026quot;가 왜 붙었는지는 아무도 모르지만 다들 자연스럽게 쓴다.\n\u0026ldquo;빌드 돌리다\u0026rdquo; — 빌드를 실행하다. 이건 그나마 직관적이다.\n\u0026ldquo;배포 나가다\u0026rdquo; — deploy하다. \u0026ldquo;이번 주말에 배포 나갑니다\u0026rdquo; 같은 식으로 쓴다. 배포가 어딘가로 출타하는 느낌이 있다.\n이런 표현들은 영어 단어를 쓰고 있지만 영어권에서는 통하지 않는다. \u0026ldquo;I hit a commit\u0026quot;이라고 하면 상대방이 멈칫할 것이다.\n의미가 미묘하게 비틀린 단어들 # 어떤 콩글리시는 영어 원어와 의미가 살짝 다르게 정착했다.\n\u0026ldquo;스펙(spec)\u0026rdquo; — 영어에서 spec은 specification, 즉 기술 명세를 뜻한다. 한국 IT에서도 그 의미로 쓰이지만, 동시에 \u0026ldquo;이번 스펙 좀 큰데요?\u0026ldquo;처럼 작업 범위(scope)나 난이도를 가리키는 경우도 많다.\n\u0026ldquo;컨펌(confirm)\u0026rdquo; — \u0026ldquo;컨펌 받았어요?\u0026ldquo;는 승인(approval)을 받았느냐는 뜻이다. 영어에서 confirm은 \u0026ldquo;확인하다\u0026quot;에 가깝고, 승인의 뉘앙스는 약하다. approve와 confirm이 하나로 합쳐진 셈이다.\n\u0026ldquo;레퍼런스(reference)\u0026rdquo; — \u0026ldquo;레퍼런스 있어요?\u0026ldquo;라고 하면 참고 사례나 선례를 묻는 것이다. 영어에서도 비슷하게 쓰일 수 있지만, 한국에서는 거의 \u0026ldquo;벤치마크 대상\u0026rdquo; 수준의 의미로 확장되었다.\n\u0026ldquo;피드백(feedback)\u0026rdquo; — 영어와 크게 다르지 않지만, 한국에서는 \u0026ldquo;피드백 주세요\u0026quot;가 사실상 \u0026ldquo;검토 후 의견 주세요\u0026quot;와 \u0026ldquo;수정 요청\u0026quot;을 동시에 의미하는 경우가 많다. 칭찬이 섞인 피드백을 기대했다가 수정 사항 목록을 받게 되는 건 흔한 일이다.\n아예 영어권에 존재하지 않는 표현들 # \u0026ldquo;오픈(open)\u0026rdquo; — \u0026ldquo;서비스 오픈했습니다\u0026quot;는 서비스를 출시(launch)했다는 뜻이다. 영어에서 \u0026ldquo;We opened the service\u0026quot;라고 하면 어딘가의 문을 열었다는 느낌이다. 영어권에서는 launch, release, go live 등을 쓴다.\n\u0026ldquo;클로즈(close)\u0026rdquo; — 오픈의 반대로, 서비스 종료를 뜻한다. 영어에서는 shut down, sunset, deprecate 등이 자연스럽다.\n\u0026ldquo;사인(sign)\u0026rdquo; — \u0026ldquo;사인 부탁드립니다\u0026quot;가 결재 승인을 의미하는 경우가 있다. sign-off에서 온 것 같지만, 한국에서는 그냥 \u0026ldquo;사인\u0026quot;으로 줄어들었다.\n\u0026ldquo;핸들링(handling)\u0026rdquo; — \u0026ldquo;이 건 핸들링 잘 해주세요\u0026quot;는 \u0026ldquo;잘 처리해 주세요\u0026quot;라는 뜻이다. 영어에서도 handle이 \u0026ldquo;처리하다\u0026quot;로 쓰이긴 하지만, 한국에서의 \u0026ldquo;핸들링\u0026quot;은 특히 민감한 상황을 조심스럽게 다룬다는 뉘앙스가 강하게 실려 있다.\n협업에서 튀어나오는 영어 동사형 # 회의나 협업 맥락에서는 또 다른 결의 콩글리시가 쏟아진다. IT뿐 아니라 대기업 사무실 전반에서 공유되는 어휘라 \u0026ldquo;판교 사투리\u0026quot;라는 별명으로 유명하기도 하다.\n\u0026ldquo;팔로우업(follow-up)하다\u0026rdquo; — \u0026ldquo;이 건 팔로우업 부탁드려요.\u0026rdquo; 끝까지 챙겨 경과를 확인해 달라는 뜻. 영어에서 follow up은 동사구지만, 한국에서는 \u0026ldquo;팔로우업\u0026quot;이라는 명사형으로 굳은 뒤에 \u0026ldquo;하다\u0026quot;가 붙었다.\n\u0026ldquo;인볼브(involve)하다\u0026rdquo; — \u0026ldquo;이 건에 디자인팀도 인볼브시켜주세요.\u0026rdquo; 참여·관여시킨다는 의미. 영어 involve는 주로 수동태로 \u0026ldquo;be involved in\u0026quot;처럼 쓰지만, 한국에서는 능동형으로 자연스럽게 쓴다. 발음이 살짝 꺾여서 \u0026ldquo;인발브\u0026quot;로 들리는 경우도 흔하다.\n\u0026ldquo;어사인(assign)하다\u0026rdquo; — \u0026ldquo;이 티켓 저한테 어사인 해주세요.\u0026rdquo; 배정하다, 할당하다. Jira 티켓을 배정하는 맥락에서 가장 자주 튀어나온다.\n\u0026ldquo;얼라인(align) 맞추다\u0026rdquo; — \u0026ldquo;팀 간 얼라인 좀 맞춰야 해요.\u0026rdquo; 방향이나 의견을 일치시키다. 영어 align 자체에 이미 \u0026ldquo;맞추다\u0026quot;라는 의미가 있는데, 한국어 \u0026ldquo;맞추다\u0026quot;를 한 번 더 붙이는 게 특징이다.\n\u0026ldquo;드라이브(drive)하다\u0026rdquo; — \u0026ldquo;이 프로젝트는 제가 드라이브 하겠습니다.\u0026rdquo; 적극적으로 이끌고 가겠다는 선언. 영어 drive에도 비슷한 의미가 있지만, 한국에서는 프로젝트 소유권을 가져가겠다는 뉘앙스가 강하게 실린다.\n\u0026ldquo;아삽(ASAP)\u0026rdquo; — as soon as possible. \u0026ldquo;이거 아삽으로 부탁드려요.\u0026rdquo; 영어 약어를 그대로 한국어 발음으로 읽어서 명사처럼 쓴다. 영어권에서도 ASAP을 쓰지만, \u0026ldquo;으로\u0026quot;라는 조사가 붙는 건 한국식이다.\n왜 이렇게 됐을까 # 몇 가지 이유가 겹쳐 있다.\n첫째, IT 기술 자체가 영어권에서 왔기 때문에 원어를 그대로 가져오는 게 자연스러웠다. 번역하면 오히려 어색하거나 의미가 달라지는 경우도 많다. \u0026ldquo;커밋\u0026quot;을 \u0026ldquo;확정\u0026quot;이라고 하면 git commit인지 알아보기 어렵다.\n둘째, 영어 원어를 가져오되 한국어 문법에 맞게 변형하는 과정에서 독자적인 표현이 만들어졌다. \u0026ldquo;머지 태우다\u0026quot;나 \u0026ldquo;배포 나가다\u0026quot;는 영어 명사를 한국어 구어 패턴에 녹인 결과다.\n셋째, 빠른 커뮤니케이션이 필요한 환경에서 짧고 함축적인 표현이 살아남았다. \u0026ldquo;운영 환경\u0026quot;보다 \u0026ldquo;리얼\u0026quot;이 한 음절 더 짧고, \u0026ldquo;서비스 출시\u0026quot;보다 \u0026ldquo;오픈\u0026quot;이 빠르다.\n문제라기보다는 특징 # 이런 콩글리시가 나쁘다는 건 아니다. 같은 맥락을 공유하는 사람들 사이에서는 오히려 효율적인 소통 수단이다. 다만 두 가지 상황에서는 주의가 필요하다.\n영어권 동료나 파트너와 소통할 때 — \u0026ldquo;리얼 환경\u0026quot;을 \u0026ldquo;real environment\u0026quot;로 직역하면 의미가 전달되지 않는다. 이때는 production이라고 바꿔 써야 한다.\n신입이나 비개발 직군과 소통할 때 — 이미 IT 콩글리시에 익숙한 사람끼리는 문제가 없지만, 처음 접하는 사람에게 \u0026ldquo;리얼에 배포 나갔는데 터졌어요\u0026quot;는 암호에 가깝다.\n결국 언어는 도구다. 상황에 맞는 도구를 꺼내 쓰면 된다. 다만 내가 쓰는 도구가 콩글리시라는 자각은 있는 게 좋다. 그래야 필요할 때 올바른 영어로, 혹은 명확한 한국어로 전환할 수 있다.\n","date":"2026년 4월 17일","externalUrl":null,"permalink":"/journal/posts/it-konglish/","section":"Posts","summary":"운영 환경을 ‘리얼’이라 부르고, 커밋을 ‘때리고’ 머지를 ‘태우는’ 한국 IT 현장의 콩글리시. 영어권에서는 안 통하는 표현들을 정리해 본다.","title":"한국 IT에서만 통하는 콩글리시 모음","type":"posts"},{"content":"","externalUrl":null,"permalink":"/journal/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/journal/search/","section":"검색","summary":"","title":"검색","type":"search"}]