[{"content":" 🇺🇸 Read in English\nAI 네이티브 채용 시리즈 Part 1입니다. Part 2-1: \u0026ldquo;The Machine\u0026rdquo; | Part 2-2: \u0026ldquo;Under the Hood\u0026rdquo; | Part 3: \u0026ldquo;The Human\u0026rdquo; (준비 중)\n2026년 1월, 무신사에서 AI 네이티브 엔지니어 채용을 진행했습니다. 수백 명의 지원자를 AI 파이프라인으로 처음부터 끝까지 자동 평가했습니다. 문제 설계, 평가 파이프라인, 그 바탕이 되는 철학까지 직접 만들었습니다. 이 시리즈는 그 과정에서 배운 이야기입니다.\n\u0026ldquo;AI 네이티브\u0026quot;란 무엇인가? 모든 기술 시대에는 그 시대의 네이티브가 있습니다.\n인터넷 시대는 \u0026ldquo;디지털 네이티브\u0026quot;를 만들었습니다. 구글 없는 세상을 모르는 세대. 스마트폰 시대는 \u0026ldquo;모바일 네이티브\u0026quot;를 만들었습니다. 클릭이 아니라 탭이 본능인 사람들. 이제 AI 시대가 만들어내는 세대가 있습니다: AI 네이티브.\n이들은 AI의 등장과 함께한 사람들입니다. 대학 입학할 때 ChatGPT가 있었고, 첫 IDE에 Copilot이 깔려 있었고, 첫 프로덕션 버그를 Claude와 함께 잡았습니다. AI는 이들이 도입한 도구가 아니라, 이들에게는 당연한 환경입니다.\n일본에서는 스마트폰 세대 신입사원에게 키보드 사용법을 가르치는 회사가 있다고 합니다. 대부분의 조직은 본능적으로 \u0026ldquo;교정\u0026quot;하려 합니다. 새 세대를 옛 방식으로 되돌리려 합니다. 스마트폰의 경우는 일리가 있습니다. 모바일이 데스크탑을 대체한 건 아니니까요. 하지만 AI는 다릅니다. 이전 도구를 대체하는 게 아니라 넘어서는 도구입니다. 교정이 아니라 이렇게 묻는 게 낫습니다: 우리가 못하는 것 중에 이들이 자연스럽게 잘하는 건 뭘까요?\nAI도 마찬가지입니다. \u0026ldquo;지원자가 AI를 쓰지 못하게 하려면?\u0026ldquo;이 아니라, **\u0026ldquo;AI를 진짜 잘 쓰는 사람을 어떻게 찾을 것인가?\u0026rdquo;**를 물어야 합니다.\n이 질문에서 모든 게 시작되었습니다.\n얼어붙은 신입 채용 AI의 파도는 엔지니어의 업무 방식만 바꾼 게 아닙니다. 기업들이 신입을 바라보는 시선 자체를 흔들어 놓았습니다.\n평가 방법만의 문제가 아닙니다. 더 근본적인 질문들이 있습니다. AI를 쓰는 팀에 엔지니어가 실제로 몇 명이나 필요할까요? AI가 직무를 재편하는 판에, 몇 년 키워야 하는 주니어를 뽑아야 할까요? 경력자만 뽑고 적응을 기대해야 할까요?\n신입 채용 앞에서 기업들의 반응은 대충 세 가지로 갈립니다:\n금지: \u0026ldquo;코딩 테스트 중 AI 도구 사용 금지.\u0026rdquo; (실제 도구 없이 코딩하게 하는 건 목수에게 전동 공구 빼고 일하라는 꼴입니다.) 무시: 똑같은 LeetCode 스타일 면접을 돌리면서 아무것도 안 변한 척. (지원자들은 에이전트로 60초 만에 알고리즘 문제를 풀고 있습니다. 당신이 못 볼 뿐입니다.) 동결: 신입 채용을 중단하고 \u0026ldquo;상황이 안정될 때까지\u0026rdquo; 기다리기. (빅테크의 신입 채용은 2022년 이후 절반 이상 줄었습니다. 국내 IT 업계의 신입 공채 공고는 전년 대비 67% 감소했습니다.) 동결이 가장 눈에 띄는 반응이고, 가장 해로운 반응입니다. 평가가 어려워서가 아닙니다. AI가 주니어 업무 상당 부분을 해치울 수 있는 시대에, 신입의 자리가 뭔지 아무도 모르기 때문입니다. 불확실하니까 안 뽑는 겁니다. 그 사이에 한 세대의 신입 엔지니어들이 어느 때보다 좁아진 문 앞에 서 있습니다.\n먼저 움직이기로 했다 무신사는 다른 선택을 했습니다.\n이 혼란의 시대에 관망하지 않기로 했습니다. \u0026ldquo;AI 네이티브 엔지니어\u0026quot;가 뭔지 우리가 직접 정의하면 어떨까? 거기에 맞는 이론을 세우고, 테스트를 만들고, 평가 파이프라인까지 구축하면? 일회성 실험이 아니라 미래를 향한 의도적인 베팅으로.\n무모함이 아닙니다. 나름의 계산이 있습니다. AI 네이티브 채용을 먼저 해결하는 기업이 이 세대 최고의 인재를 끌어올 것입니다. 나머지는 뒤따라갈 수밖에 없습니다.\nAndrew Ng은 이렇게 말한 적이 있습니다. \u0026ldquo;회사 문을 열고 들어갈 때 느끼는 로고의 설렘에서 배우는 게 아닙니다. 매일 함께 부대끼며 일하는 사람들에게서 배웁니다.\u0026rdquo; 우리가 진짜 신경 쓰는 건 그겁니다. 브랜드 후광도, 헤드카운트도 아닙니다. 서로에게서 배우고 함께 성장할 수 있는 사람들을 모으는 것. \u0026ldquo;좋은 동료\u0026quot;의 기준 자체가 바뀌고 있는 지금이니까요.\n최전선에 서서 직접 길을 만들기로 했습니다. 업계가 정답을 찾아줄 때까지 기다리지 않았습니다. 우리만의 기준을 만들었습니다.\n먼저 버린 건 기존 코딩 테스트였습니다. 새로운 시험을 설계하면서 네 가지 질문과 마주했습니다.\n기존 테스트는 왜 안 되는가? 공정성은 어떻게 확보할 것인가? 문제의 모호함은 어디까지 허용할 것인가? 테스트 가능성과 모호함 사이의 균형은? LeetCode는 죽었다 C나 C++로 짧은 알고리즘 문제? 오늘날 1분이면 끝납니다.\nAI 에이전트는 전형적인 LeetCode medium을 몇 초 만에 풉니다. 많은 hard도 프롬프트 한 번이면 됩니다. 코딩 테스트가 측정하려던 것, 즉 문제를 동작하는 코드로 옮기는 능력이 하룻밤 사이에 범용화되었습니다.\n코딩 테스트만의 이야기가 아닙니다. Andrew Ng이 스탠퍼드 CS 수업에서 이야기한 적이 있습니다. 만드는 일과 결정하는 일 사이의 무게중심이 극적으로 옮겨지고 있다고요:\n과거에는 엔지니어 대 PM 비율이 7:1이나 8:1이었습니다. PM 한 명이 스펙을 쓰면 엔지니어 7~8명이 달라붙어 만들었습니다. AI가 구현을 극적으로 싸고 빠르게 만들면서 이 비율이 2:1, 심지어 1:1까지 무너지고 있습니다. 기획(사용자 이해, 요구사항 정의, 판단)은 같은 속도로 빨라지지 않았습니다. 병목이 이동한 겁니다. Ng은 더 나아갑니다: 역할의 경계가 사라지고 있다고 합니다. 지금 실리콘밸리에서 가장 빠르게 움직이는 사람들은 사용자와 직접 소통하고, 무엇을 만들지 결정하고, AI를 시켜 만드는 제품 감각 있는 엔지니어들입니다. 한 사람이 두 역할을 합니다.\n구현이 싸다면, 비싼 건 뭘까요?\n무엇을 구현할지 아는 것.\n모호한 상황을 보고, 실제 요구사항을 도출하고, 불확실성 속에서 합리적인 결정을 내리고, AI를 올바른 방향으로 이끄는 능력. 이것이 지금 중요한 역량입니다. 기존 코딩 테스트는 이걸 전혀 측정하지 못합니다.\n웹 샌드박스에 가두고 AI 없이 코딩하게 하는 건 완전히 잘못된 방향입니다. 엔지니어링 역량을 테스트하는 게 아닙니다. 2020년처럼 코딩할 수 있는지를 테스트하고 있는 겁니다. 필요한 역량이 바뀌었습니다. 테스트도 바뀌어야 합니다.\n공정성 문제 처음에는 각자 로컬 환경을 쓰게 할까 했습니다. \u0026ldquo;환경 구축도 실력이다\u0026rdquo;, 나름 일리가 있었습니다. 익숙한 도구를 자유롭게 쓰게 하자는 논리였습니다.\n하지만 \u0026ldquo;AI 도구\u0026quot;가 핵심 변수가 되면서, 자유와 공정성 사이의 균형이 깨졌습니다.\n2-3시간 테스트에서 잘 세팅된 AI 에이전트(ChatGPT Pro, Claude Max, 최적화된 IDE 연동, 커스텀 프롬프트)를 가진 사람과 아닌 사람의 차이는 압도적입니다. 실력 차이가 아니라 자본 차이입니다. 좋은 도구를 가졌는지를 테스트하는 거지, 깊이 생각하는지를 테스트하는 게 아닙니다.\n사고력을 테스트하고 싶었지, 구매력을 테스트하고 싶은 게 아니었습니다.\n그래서 모든 지원자에게 동등한 AI 환경을 제공하기로 했습니다. OpenAI와 협업하여 모든 지원자에게 충분한 토큰의 무료 에이전트를 제공했습니다. 도구 조건을 맞추고, 진짜 중요한 사고력을 테스트합니다.\n이 자리를 빌려 OpenAI 팀에 감사를 전합니다. 덕분에 공정한 평가 환경을 만들 수 있었습니다.\n모호함의 스펙트럼 AI 시대 코딩 테스트 설계에서 가장 어려운 문제: 문제가 얼마나 모호해야 하는가?\n별거 아닌 것 같지만, 여기서 모든 게 갈립니다. 보정을 잘못하면 완전히 엉뚱한 걸 테스트하게 됩니다.\n완전 모호: \u0026ldquo;유용한 걸 만들어라\u0026rdquo;. AI 에이전트에게도 여전히 어렵습니다. 의도를 모르니까요. 하지만 지원자에게도 비생산적입니다. 너무 열려 있고, 신호가 너무 적습니다.\n반쪽 모호: \u0026ldquo;이 엔드포인트로 REST API를 만들어라: POST /users, GET /users/{id}\u0026hellip;\u0026rdquo; 이건 너무 쉽습니다. API 엔드포인트, 데이터 모델, UI 레이아웃을 지정하는 순간 구현을 알려준 거나 다름없습니다. AI 에이전트는 반쯤 빈 상자를 추론으로 몇 분 만에 채웁니다.\nSweet spot은 양극단 사이에 있습니다: 모호한 요구사항 + 명확한 결과 기대치. 지원자가 무엇을 만들지 도출해야 합니다. AI는 실행할 수 있지만 무엇을 실행할지 결정할 수는 없습니다.\n모호함의 스펙트럼 graph LR A[\"완전 모호'유용한 걸 만들어라'너무 열려 있음신호 부족\"] B[\"Sweet Spot모호한 요구사항 +명확한 결과 기대치무엇을 만들지 도출해야 함\"] C[\"반쪽 모호'POST /users, GET /users/{id}'너무 구체적AI가 채움\"] A -.- B -.- C style B fill:#16a34a,stroke:#333,color:#fff 가설은 이렇습니다: 실제 이해관계자가 쓰듯이 빈틈 있는 문제를 주면, 깊이 생각하는 사람은 자연스럽게 드러날 것입니다. 그래서 엣지 케이스 처리 방법을 지정하지 않았습니다. NFR을 정의하지 않았습니다. API 엔드포인트를 나열하지 않았습니다. 시스템이 뭘 해야 하는지만 적고, 나머지는 지원자에게 맡겼습니다. 딱 한 줄 덧붙였습니다: \u0026ldquo;명시되지 않은 모든 사항은 자유롭게 결정하세요.\u0026rdquo;\n모호함 자체가 테스트입니다.\n이것이 \u0026ldquo;AI 네이티브\u0026quot;와 \u0026ldquo;AI 의존\u0026quot;의 차이입니다: 스펙이 알려주지 않을 때, 무엇을 해야 하는지 스스로 파악할 수 있는가?\n시간/범위의 딜레마, 그리고 오픈소스라는 해법 AI 시대 테스트 설계에는 패러독스가 있었고, 이걸 풀어내는 데 시간이 걸렸습니다:\n알고리즘 테스트는 죽었다. 짧은 알고리즘 문제는 오늘 1분이면 끝납니다. 신호가 부족합니다. 그러면 풀 서비스를 요구하자. 데이터베이스, API, 비즈니스 로직, 동시성을 갖춘 실제 애플리케이션은 AI가 자동으로 못할 만큼 복잡합니다. 지원자가 생각해야 합니다. 하지만 풀 서비스는 테스트하기 어렵다. 수백 개 제출물을 수작업으로 채점할 수 없습니다. 자동화된 테스트가 필요합니다. 즉 각 제출물을 실행할 방법이 필요한데\u0026hellip; 그러면 Docker를 요구하자? 하지만 Docker를 필수로 하는 건 구현에 대한 큰 힌트입니다. API 엔드포인트, DB 스키마, 테스트 인프라를 지정하는 것도 마찬가지입니다. 힌트를 줄수록 AI가 사고를 건너뛸 수 있습니다. 테스트 가능성을 높일수록 구체성이 높아지고, 구체성이 높아질수록 AI의 일이 쉬워지고 지원자의 사고는 얕아집니다.\n테스트 가능성–모호함의 딜레마 graph TD A[\"1. 알고리즘 테스트는 죽었다짧은 문제 = 오늘 1분이면 끝\"] --\u003e|그러면...| B[\"2. 풀 서비스를 요구하자사고가 필요할 만큼 복잡\"] B --\u003e|하지만...| C[\"3. 풀 서비스는 테스트하기 어렵다자동화된 테스트가 필요\"] C --\u003e|그러면...| D[\"4. 테스트 인프라를 지정하자Docker, 엔드포인트, 스키마...\"] D --\u003e|하지만...| E[\"힌트를 줄수록 AI의 일이 쉬워짐지원자의 사고는 얕아짐\"] E -.-\u003e|원점| A OS[\"오픈소스 접근법OSS처럼 문서화하게 하고AI 에이전트가 읽고 테스트\"] OS ==\u003e|악순환을 끊음| C style OS fill:#16a34a,stroke:#333,color:#fff 해법은 의외의 곳에서 왔습니다: 오픈소스.\n좋은 오픈소스 프로젝트를 떠올려 보세요. 엔드포인트 목록이나 Docker 명령어를 채점표에 적어두지 않아도, README만 읽으면 빌드하고 실행할 수 있습니다. 헬스체크가 있고, 다른 개발자(또는 에이전트)가 바로 쓸 수 있는 API 문서가 갖춰져 있습니다.\n그래서 테스트 인프라를 지정하는 대신, 좋은 오픈소스 프로젝트처럼 문서화하라고 했습니다. 빌드하는 법, 실행하는 법, 테스트하는 법을 적어라. 그러면 우리의 평가 에이전트(역시 AI)가 그 문서를 읽고, 프로젝트를 빌드하고, 기능을 테스트합니다.\n다른 사람이 테스트할 수 있게 신경 쓰는 지원자는 자연스럽게 README도, 빌드 스크립트도, 헬스체크도, API 문서도 잘 씁니다. 지시받지 않아도. 힌트 없이도.\n코드를 포장하는 방식 자체가 평가 대상입니다.\n실제로 무엇을 물었나 이 모든 철학을 바탕으로, 실제 시험은 어떤 모습이었을까요?\n지원자들에게 낸 문제: 대학교 수강신청 시스템을 구축하라.\n기획팀 메모로 시작합니다:\n\u0026ldquo;매 학기 수강신청 기간마다 서버가 다운되어 학생들의 불만이 폭주하고 있습니다. 이번에는 제대로 된 시스템을 만들어주세요.\u0026rdquo;\n메모에는 기본 기능(학생 조회, 강좌 조회, 수강신청, 수강취소, 시간표 조회)이 나열되어 있습니다. 18학점 상한과 시간 충돌도 언급됩니다. 그리고 이 한 줄:\n\u0026ldquo;정원이 1명 남은 강좌에 100명이 동시에 신청해도, 정확히 1명만 성공해야 합니다.\u0026rdquo;\n이것이 전부입니다. 락 메커니즘 지정 없음. 성능 요구사항 없음. NFR 없음. 인증 모델 없음. 취소 정책 없음. 선수과목 규칙 없음.\n그리고 문제에 명시합니다: \u0026ldquo;명시되지 않은 모든 사항은 자유롭게 결정하세요.\u0026rdquo;\n반문할 수 있습니다: \u0026ldquo;수강신청 시스템을 만들라고 했으면 무엇을 만들지 이미 알려준 거 아닌가?\u0026rdquo;\n그럴까요? \u0026ldquo;수강신청 시스템\u0026quot;이 대체 뭘까요? 한 문장으로 완전히 정의할 수 있을까요? 그 네 글자 뒤에 뭐가 숨어 있는지 생각해 보세요: 극한 경쟁 상황의 동시성, 비즈니스 규칙이 엮인 데이터 정합성, 부하 상태의 성능, 실패 모드, 시간표 엣지 케이스, 좌석 배분의 공정성. 네 글자 뒤에 끝없는 복잡성이 숨어 있습니다.\n다행인 건, 우리 지원자들은 이 문제를 겪어봤다는 것입니다. 자기 대학교의 망가진 수강신청을 뚫어봤고, 부하에 뻗어버리는 티켓 예매 사이트에 욕을 해봤습니다. 적어도 당하는 쪽으로서, 경쟁 상황에서 시스템이 터지면 어떻게 되는지 압니다. 그 경험이 씨앗입니다. 문제의 정의는 저 한 문장에서 시작될 뿐이지, 사양서가 아닙니다.\n진짜 질문은 이겁니다: 그 한 문장에서 얼마나 멀리 갈 수 있을까요? 겪어본 불만을 어떻게 체계적인 시스템 설계로 풀어낼까요? 요청한 사람들조차 자기가 원하는 걸 정확히 모르는데, \u0026ldquo;올바른 시스템\u0026quot;이 뭔지를 어떻게 정의할까요? 괜히 과학자와 수학자가 정의로부터 시작하는 게 아닙니다. 정의하는 행위 자체가 진짜 사고이기 때문입니다.\n이건 원래 시니어 IC의 영역이었습니다. 뭉뚱그려진 요구를 명확한 기술 방향으로 바꾸는 능력. AI라는 사고 파트너가 생기면서 그 경계가 허물어지고 있습니다. 에이전트와 함께 문제를 파고들 줄 아는 주니어 엔지니어, 올바른 질문을 던지고 가정을 흔들어보고 엣지 케이스를 찾아내는 주니어 엔지니어가 과거에는 팀이 해야 했던 일을 혼자 할 수 있는 시대입니다. 어떤 엔지니어든 시니어 IC처럼 일할 수 있습니다. 실제로 그렇게 하는 사람이 우리가 찾는 사람입니다.\n앞의 모든 설계 원칙이 이 문제에 수렴합니다. 모호함이 보정되어 있습니다: 무엇을 만들지는 알지만(수강신청 시스템), 어떻게는 도출해야 합니다. 결과 기대치는 명확하지만(100명 동시 신청, 1명만 성공), 메커니즘은 본인이 선택합니다. 문제를 실제 기획팀 메모처럼 쓴 건, 입사 첫날 읽게 될 문서가 바로 그런 것이기 때문입니다.\n의도적인 모호함이 자연스러운 갈림길을 만듭니다. 깊이 생각할수록 다른 답이 나옵니다. 몇 가지를 살펴보겠습니다.\n숨겨진 깊이 데이터 설계 함정 문제는 시작 시 현실적인 테스트 데이터 생성을 요구합니다. 학생 10,000명 이상, 강좌 500개 이상, 교수 100명 이상을 동적으로, 1분 이내에 만들어야 합니다.\n겉으로는 간단해 보입니다. 학생을 만들고, 강좌를 만들고, 교수를 배정한다. 끝.\n하지만 숨겨진 복잡성은 관계에 있습니다. 강좌 시간표를 어떻게 배정할까요? 랜덤으로 시간대를 뿌리면 모든 강좌가 겹쳐버릴 수 있고, 시간 충돌 테스트가 무의미해집니다. 정원을 어떻게 잡을까요? 너무 크면 동시성 테스트가 사소해지고, 너무 작으면 시스템이 못 쓰게 됩니다. 교수-강좌 관계는? 교수 당 강좌 1개? 현실적인 강의 부하?\n미리 생각하는 지원자는 이 데이터로 실제 뭘 할 건지를 염두에 두고 데이터 생성을 설계했습니다. 시간 충돌을 테스트할 수 있을 만큼 다양한 시간표, 동시성을 검증할 수 있을 만큼 타이트한 정원, 엣지 케이스를 드러낼 수 있을 만큼 현실적인 관계. 데이터 설계를 시스템 설계로 다뤘지, 일회용 스크립트로 보지 않았습니다.\n미리 생각하지 않은 지원자는 얕고 연결되지 않은 데이터를 만들었습니다. 기술적으로는 유효하지만, 시스템이 그 데이터를 가지고 뭘 할지까지는 생각하지 못한 겁니다. 시더는 돌아갔지만, 테스트할 가치가 있는 세계를 만들지는 못했습니다.\n데이터 문제 안에 숨어 있는 설계 문제입니다. 이걸 알아차리고, 왜 그렇게 만들었는지까지 적어둔 지원자들이 우리가 찾던 사람입니다.\n동시성 사다리 \u0026ldquo;100명 동시 요청을 처리하라\u0026quot;고 했지만 방법은 지정하지 않았습니다. pessimistic lock, optimistic lock, 큐, 단일 머신 vs 분산. 아무것도. 지원자가 무엇을 선택했는지가 사고 깊이를 드러냅니다:\n수준 접근법 드러나는 것 표면적 synchronized / 인메모리 큐 \u0026ldquo;동시성\u0026quot;이란 단어를 알지만 single-JVM만 생각 유능 DB pessimistic lock (SELECT ... FOR UPDATE) DB 레벨 직렬화를 이해, 실용적 선택 사려깊음 커스텀 optimistic locking + 재시도 트레이드오프를 이해, 성능을 선택 깊음 분산 락 (Redis/ZooKeeper) 단일 머신 너머를 생각, 프로덕션 현실 고려 탁월 분산 트랜잭션 문제 분석 락 자체가 실패하면 어떻게 되는지를 생각 어떤 수준도 \u0026ldquo;틀린\u0026rdquo; 것이 아닙니다. synchronized를 선택하고 이유를 명확히 설명하는 지원자(단일 인스턴스 범위, 주어진 제약에 맞는 단순성, 트레이드오프 정리)가 이유도 모르면서 Redis 락을 쓰는 지원자보다 높은 점수를 받습니다.\n추론이 메커니즘보다 중요합니다. 어떤 락을 골랐느냐가 아니라, 왜 그 락을 골랐느냐가 점수를 가릅니다.\n더 좋은 AI 모델이나 더 날카로운 프롬프트가 이런 인사이트를 대신 찾아줄 수 있지 않냐고요? 당연히 가능합니다. 그리고 괜찮습니다. Duck Typing과 같은 원리입니다. 깊은 사고의 결과가 나오고 깊은 사고의 과정을 거쳤다면, 그건 깊은 사고입니다. 혼자 힘으로 도달했든 에이전트와의 대화를 통해 도달했든, 도달했다는 것 자체가 실력입니다.\n이중 락 인사이트 가장 깊은 분기점입니다. 두 범위의 락을 모두 구현한 명확한 증거를 남긴 지원자는 다섯 명 중 한 명이 채 안 됐습니다. 그중에서도 절반 정도만 프롬프트나 설계 문서에서 이 문제를 스스로 짚어낸 흔적을 남겼습니다. 나머지는 AI 에이전트가 알아서 처리한 경우입니다. (에이전트가 먼저 풀어버려서, 지원자가 생각할 기회 자체가 없었을 수도 있습니다.)\n대부분의 지원자는 동시성을 강좌 레벨 락으로만 생각합니다. 정원이라는 공유 자원을 보호하는 것. 100명이 1자리에 몰리면 1명만 성공해야 한다. 강좌 행에 락을 건다. 끝.\n하지만 그건 문제의 절반일 뿐입니다.\n같은 학생이 동시에 두 개의 수강신청 요청을 보내는 경우를 생각해 보세요. 더블클릭이든, 브라우저 탭 두 개든. 서로 다른 과목에 대한 두 요청이 동시에 도착합니다. 둘 다 확인합니다: \u0026ldquo;이 학생 18학점 미만인가?\u0026rdquo; 둘 다 15학점을 봅니다. 둘 다 통과. 둘 다 등록. 학생은 이제 21학점. 학점 제한이 깨집니다.\n이중 락 문제: 강좌 레벨 락만으로는 부족한 이유 sequenceDiagram actor S as Student (15학점) participant R1 as Request 1Course A (3학점) participant DB as Database participant R2 as Request 2Course B (3학점) S-\u003e\u003eR1: 수강신청 S-\u003e\u003eR2: 수강신청 (동시) Note over R1,R2: 강좌 레벨 락만 있고, 학생 레벨 락은 없음 R1-\u003e\u003eDB: SELECT credits → 15 R2-\u003e\u003eDB: SELECT credits → 15 R1-\u003e\u003eDB: 15 + 3 = 18 ≤ 18 ✓ ENROLL R2-\u003e\u003eDB: 15 + 3 = 18 ≤ 18 ✓ ENROLL Note over DB: 결과: 21학점, 제한 위반 같은 패턴이 시간 충돌 감지와 중복 수강 체크도 깨뜨립니다.\n강좌 레벨 직렬화는 정원(모든 학생에게 공유되는 자원)을 보호합니다.\n학생 레벨 직렬화는 학생별 제약조건(학점 제한, 시간 충돌, 중복 수강)을 보호합니다.\n둘 다 필요합니다. 그리고 둘 다 필요해지는 순간, 새로운 문제가 생깁니다: 락 순서. 어떤 코드 경로는 학생 락을 먼저 잡고, 다른 경로는 강좌 락을 먼저 잡으면 데드락이 걸립니다. 동시성을 깊이 파고들수록 함정은 더 늘어납니다.\n메커니즘은 다를 수 있습니다. pessimistic lock, optimistic lock + 재시도, application-level lock, 분산 락, serializable isolation. 하지만 요구사항은 같습니다: 같은 학생의 동시 요청은 직렬화해야 합니다. 그래야 제약조건이 깨지지 않습니다.\n여기에 도달한 지원자들이 우리가 원하는 엔지니어입니다. 혼자 알아냈든, 에이전트와의 대화를 통해 도달했든. 그리고 그중에서도 더 나아간 사람들이 있습니다. 문제를 풀고 끝낸 게 아니라, 왜 이렇게 풀어야 하는지를 문서로 남기고, 다음에 비슷한 문제를 만났을 때 스스로 판단할 수 있는 사람. 우리 평가 모델은 바로 그 차이를 드러내도록 설계되어 있습니다.\n철학을 실전으로 철학만으로는 부족합니다. 측정할 수 있어야 합니다. 그래서 3-Tier 평가 모델을 만들었고, 각 Tier는 점점 더 깊은 질문을 던지도록 설계했습니다. Part 2와 3에서 다루겠지만, 제출물에서 기계가 실제로 읽어낼 수 있는 신호는 예상보다 까다로운 문제였습니다. 다만 프레임워크 자체는 유효했습니다.\n3-Tier 평가 모델 graph BT T1[\"Tier 1: 동작하게 만들기빌드 · 시작 · 헬스체크동작하는 서비스를 배포할 수 있는가?\"] T2[\"Tier 2: 기본 기능API · 비즈니스 규칙 · 동시성부하 상태에서 올바르게 동작하는가?\"] T3[\"Tier 3: 깊은 사고프롬프트 이력 · 설계 문서 · Git 이력 · 코드 품질배포한 것을 이해하는가?\"] T1 --\u003e T2 --\u003e T3 DT[\"Duck Typing외부 행동이 곧 검증\"] BDT[\"Duck Typing 너머내부 이해가 성장 가능성을 보여줌\"] T1 ~~~ DT T2 ~~~ DT T3 ~~~ BDT style DT fill:#2563eb,stroke:#333,color:#fff style BDT fill:#16a34a,stroke:#333,color:#fff Tier 1 — Make it Work. 빌드되는가? 시작되는가? 헬스체크에 응답하는가? 동작하는 서비스를 배포할 수 없다면, 나머지는 의미 없습니다.\nTier 2 — Basic Features. API가 동작하는가? 비즈니스 규칙이 시행되는가? 동시성 제어가 부하 상태에서 버티는가? 카테고리별 자동화 테스트를 Docker 컨테이너 안에서 돌립니다. 사람 손 안 탑니다.\nTier 1과 2는 Duck Typing입니다. 동작하는 시스템처럼 행동하면 동작하는 시스템입니다. 어떻게 거기 도달했는지는 묻지 않습니다. 외부 행동이 곧 검증입니다.\nTier 3 — Deep Thought. 여기서 Duck Typing 너머로 갑니다. Duck Typing은 동작한다는 건 알려주지만, 이 엔지니어가 이 수준을 유지할 수 있는지, 더 성장할 수 있는지는 알려주지 않습니다. 그래서 내부를 들여다봅니다: 프롬프트 이력, 에이전트 지침, 요구사항 도출 문서, 데이터 설계, 코드 품질, 테스트 커버리지, git 이력, 추가 구현사항. 이걸 AI가 평가합니다. 모든 점수에 파일 경로와 라인 번호가 근거로 붙습니다.\nTier 3에서 가르려는 건 맡기기만 한 건지, 이해하면서 쓴 건지입니다. 이 구분은 생각보다 중요합니다.\nAnthropic의 최근 연구(\u0026ldquo;How AI assistance impacts the formation of coding skills,\u0026rdquo; Shen \u0026amp; Tamkin, 2026)가 이 두 모드 사이에 분명한 선을 긋습니다. AI에게 맡기기만 하는 엔지니어는 당장은 빠릅니다. 하지만 이해하면서 쓰는 엔지니어, AI를 같이 생각하는 파트너로 쓰는 엔지니어는 시간이 지날수록 역량이 복리로 쌓입니다. Anthropic 내부 데이터에 따르면 최고 성과 엔지니어들이 1.2~2배 더 생산적이었던 건, AI를 사고의 대체재가 아니라 사고의 파트너로 썼기 때문입니다.\n우리 채점의 핵심은 이겁니다: 사고의 깊이가 기능적 완성도보다 무겁다. Tier 1은 \u0026ldquo;배포 가능하며 실행되는가?\u0026ldquo;를 묻습니다. Tier 2는 \u0026ldquo;의도대로 작동하는가?\u0026ldquo;를 묻습니다. Tier 3는 \u0026ldquo;배포한 것을 이해하는가? 여기서 더 성장할 수 있는가?\u0026ldquo;를 묻습니다.\n구체적인 예를 들어 보겠습니다. 두 지원자 모두 이중 락을 정확히 구현했습니다. Duck Typing으로 보면 동등합니다. 겉으로 보이는 행동이 같으니까요. 하지만 안을 들여다보면: 한 명은 점점 더 깊은 프롬프트를 통해 문제를 파고들었고, 왜 두 가지 락이 필요한지 문서로 남기고, git 이력에 이해한 흔적이 남아 있습니다. 다른 한 명은 범용적인 프롬프트로 답을 얻고 넘어갔습니다. 결과물은 같지만, 그 안에 담긴 이해의 깊이는 전혀 다릅니다.\n기능 점수는 높은데 깊이가 얕으면 AI 과의존 신호입니다. 빠르게 배포하지만 왜 그렇게 했는지 설명 못 합니다. 빌드는 실패했는데 설계 사고가 탁월하면 다른 이야기입니다. 기술적으로 삐끗했어도 면접은 볼 만합니다. 정답에 도달한 사람만 찾는 게 아닙니다. 질문을 이해한 사람을 찾고 있습니다.\n철학이 실전이 되는 과정입니다. 다음 글에서는 우리가 만든 실제 머신, 약 400명의 지원자를 AI가 채점하는 자동화된 파이프라인을 뜯어보겠습니다. 우리가 부딪힌 자동 평가의 한계와, 거기서 사람의 판단이 왜 필요했는지를 데이터로 보여드리겠습니다.\nAI 네이티브 채용 시리즈 3부작 중 Part 1. 다음: \u0026ldquo;The Machine: AI가 AI 활용 코드를 평가하다\u0026rdquo;. 자동화된 평가 파이프라인의 기술적 심층 분석.\n","permalink":"http://taokim.dev/posts/2026-02-24-ai-native-hiring-philosophy.ko/","summary":"\u003cblockquote\u003e\n\u003cp\u003e🇺🇸 \u003ca href=\"/posts/2026-02-24-ai-native-hiring-philosophy/\"\u003eRead in English\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eAI 네이티브 채용 시리즈 Part 1입니다.\n\u003cstrong\u003ePart 2-1\u003c/strong\u003e: \u003ca href=\"/posts/2026-02-24-ai-native-hiring-machine.ko/\"\u003e\u0026ldquo;The Machine\u0026rdquo;\u003c/a\u003e | \u003cstrong\u003ePart 2-2\u003c/strong\u003e: \u003ca href=\"/posts/2026-02-24-ai-native-hiring-under-the-hood.ko/\"\u003e\u0026ldquo;Under the Hood\u0026rdquo;\u003c/a\u003e | \u003cstrong\u003ePart 3\u003c/strong\u003e: \u0026ldquo;The Human\u0026rdquo; (준비 중)\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cimg alt=\"AI Rookie #1 — AI Native Engineering Track\" loading=\"lazy\" src=\"/images/musinsa-rookies/ai-rookie-1-banner.png\"\u003e\u003c/p\u003e\n\u003cp\u003e2026년 1월, 무신사에서 AI 네이티브 엔지니어 채용을 진행했습니다. 수백 명의 지원자를 AI 파이프라인으로 처음부터 끝까지 자동 평가했습니다. 문제 설계, 평가 파이프라인, 그 바탕이 되는 철학까지 직접 만들었습니다. 이 시리즈는 그 과정에서 배운 이야기입니다.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ai-네이티브란-무엇인가\"\u003e\u0026ldquo;AI 네이티브\u0026quot;란 무엇인가?\u003c/h2\u003e\n\u003cp\u003e모든 기술 시대에는 그 시대의 네이티브가 있습니다.\u003c/p\u003e","title":"The Philosophy: AI 네이티브 채용"},{"content":" 🇰🇷 한국어 버전 읽기\nThis is Part 1 of the AI-native hiring series. Part 2-1: \u0026ldquo;The Machine\u0026rdquo; | Part 2-2: \u0026ldquo;Under the Hood\u0026rdquo; | Part 3: \u0026ldquo;The Human\u0026rdquo; (coming soon)\nIn January 2026, we ran an AI-native engineering hiring round at Musinsa — hundreds of candidates, evaluated end-to-end by an automated AI pipeline. We defined the problem, built the automated evaluation pipeline, and shaped the philosophy behind it all. This series is about what we learned.\nWhat Is \u0026ldquo;AI Native\u0026rdquo;? Every technology era produces its natives.\nThe internet era gave us \u0026ldquo;digital natives\u0026rdquo; — a generation that never knew life without Google. The smartphone era gave us \u0026ldquo;mobile natives\u0026rdquo; — people whose first instinct is to tap, not click. Now the AI era is producing its own generation: AI natives.\nThese aren\u0026rsquo;t people who learned to use AI. They grew up with it. ChatGPT was there when they started college. Copilot was in their first IDE. Claude helped them debug their first production bug. AI isn\u0026rsquo;t a tool they adopted — it\u0026rsquo;s the air they breathe when they code.\nI heard about companies in Japan that now teach new hires how to use a physical keyboard, because the incoming generation grew up on smartphones. In that case, the \u0026ldquo;fix it\u0026rdquo; instinct somewhat made sense — smartphones never replaced desktops for serious work. But AI is different. It doesn\u0026rsquo;t fall short of existing tools — it surpasses them. The better instinct is to ask: what are they naturally good at that we aren\u0026rsquo;t?\nThe same applies to AI. Instead of asking \u0026ldquo;how do we prevent candidates from using AI?\u0026rdquo;, we should ask: \u0026ldquo;how do we find the ones who are genuinely great at working with AI?\u0026rdquo;\nThat question led to everything in this series.\nThe Fear and the Freeze The AI wave hasn\u0026rsquo;t just changed how engineers work. It\u0026rsquo;s upended how companies think about junior hiring.\nThe questions go beyond evaluation methods. How many engineers does an AI-augmented team actually need? Should we bring in fresh juniors who\u0026rsquo;ll need years of mentoring, when AI might reshape the job before they\u0026rsquo;re ramped up? Or do we double down on experienced seniors and hope they adapt?\nWhen it comes to entry-level hiring, the responses range from denial to paralysis:\nBan it: \u0026ldquo;No AI tools allowed during the coding test.\u0026rdquo; (You\u0026rsquo;re testing who can code without their actual tools — like testing a carpenter without power tools.) Ignore it: Run the same LeetCode-style interviews and pretend nothing changed. (Candidates solve your algorithm problems in 60 seconds with an agent. You just don\u0026rsquo;t see it.) Freeze: Stop hiring juniors until \u0026ldquo;things stabilize.\u0026rdquo; (Entry-level hiring at major tech companies has dropped by more than half since 2022. In Korean IT, new grad postings fell 67% year-over-year.) The freeze is the most visible response — and the most damaging. It\u0026rsquo;s not really about evaluation difficulty. It\u0026rsquo;s about uncertainty: nobody knows what a junior engineer\u0026rsquo;s role looks like when AI can handle much of what juniors used to do. And in that uncertainty, the default is to not hire them at all. Meanwhile, a generation of new graduates — including the best AI-native engineers — enters the market to find fewer doors open than any cohort before them.\nPioneer, Not Bystander At Musinsa, we chose differently.\nWe decided not to sit out this chaotic era. Instead, we asked ourselves: what if we defined what \u0026ldquo;AI native engineer\u0026rdquo; means? What if we built a theory, a test, and an evaluation pipeline around it — not as a one-off experiment, but as a deliberate bet on the future?\nThis isn\u0026rsquo;t recklessness. It\u0026rsquo;s a calculated position: the companies that figure out AI-native hiring first will attract the best of this generation. Everyone else will be playing catch-up.\nAs Andrew Ng put it: \u0026ldquo;We don\u0026rsquo;t learn from the excitement of the company logo when you walk through the door — you learn from the people you deal with day-to-day.\u0026rdquo; That\u0026rsquo;s what we\u0026rsquo;re optimizing for. Not brand prestige. Not headcount. The right people, working alongside each other, growing together — in a moment when what \u0026ldquo;the right people\u0026rdquo; means is being redefined.\nWe moved first. We didn\u0026rsquo;t wait for the industry to converge on a standard. We built our own.\nThe first thing we threw out was the traditional coding test. Designing its replacement forced us to confront four questions: Why don\u0026rsquo;t existing tests work anymore? How do we level the playing field when AI tools are the key variable? How vague should the problem be? And how do we keep submissions testable without giving away the answer?\nLeetCode Is Dead Let me say it plainly: a short algorithm problem in C or C++ is a 1-minute problem today.\nAn AI agent can solve a typical LeetCode medium in seconds. It can handle many hards with a single prompt. The thing that coding tests were designed to measure — the ability to translate a problem into working code — has been commoditized overnight.\nThis shift is bigger than just coding tests. Andrew Ng pointed out in a Stanford CS class how dramatically the balance between building and deciding has shifted:\n▶ Andrew Ng — What AI Means for Computer Science (Stanford CS) The engineer-to-PM ratio used to be 7:1 or 8:1 — one person writing a spec could keep seven or eight engineers busy building it. With AI making implementation dramatically cheaper and faster, that ratio is collapsing to 2:1, even 1:1. Product management — understanding users, defining requirements, making judgment calls — hasn\u0026rsquo;t sped up the same way. The bottleneck has moved. And Ng goes further: he\u0026rsquo;s seeing the roles merge entirely. The fastest-moving people in Silicon Valley right now are product-minded engineers who talk to users directly, decide what to build, and direct AI to build it. One person, both roles.\nIf implementation is cheap, what\u0026rsquo;s expensive?\nKnowing what to implement.\nThe ability to look at an ambiguous situation, derive the actual requirements, make reasonable decisions under uncertainty, and direct AI to build the right thing — that is the skill that matters now. And traditional coding tests don\u0026rsquo;t measure any of it.\nThe constrained-environment response — forcing candidates into a web sandbox with no AI tools — is the wrong direction entirely. You\u0026rsquo;re not testing engineering skill. You\u0026rsquo;re testing who can code like it\u0026rsquo;s 2020. The skill has shifted, and the tests need to shift with it.\nThe Fairness Problem We initially considered letting candidates use their own local environments. The hypothesis was compelling: \u0026ldquo;환경 구축도 실력이다\u0026rdquo; — setting up your own development environment is itself a skill. Let people use whatever tools they\u0026rsquo;re comfortable with.\nBut once \u0026ldquo;AI tools\u0026rdquo; became the key variable, the freedom-vs-fairness equation broke down.\nIn a 2-3 hour test, the difference between someone with a well-configured AI agent (ChatGPT Pro, Claude Max, optimized IDE integration, custom prompts) and someone without is enormous. It\u0026rsquo;s not a difference in skill — it\u0026rsquo;s a difference in capital. We\u0026rsquo;d be testing who has access to better tools, not who thinks more deeply about problems.\nWe wanted to test problem-solving thinking, not purchasing power.\nThe decision: provide all candidates with an equal AI environment. We partnered with OpenAI, who provided free agent access with sufficient tokens for every candidate. Level the playing field on tools, then test what actually matters — the thinking.\nShout-out to the OpenAI team — their support made a fair evaluation environment possible.\nThe Vagueness Spectrum Here\u0026rsquo;s the hardest problem in designing an AI-era coding test: how vague should the problem be?\nThis might sound like a minor design detail, but it\u0026rsquo;s actually the crux of everything. Get the calibration wrong, and you\u0026rsquo;re testing the wrong thing entirely.\nFull vagueness — \u0026ldquo;Build something useful\u0026rdquo; — is still hard for AI agents because they don\u0026rsquo;t know the intention. But it\u0026rsquo;s also unproductive for candidates. Too open-ended, too little signal.\nHalf vagueness — \u0026ldquo;Build a REST API with these endpoints: POST /users, GET /users/{id}\u0026hellip;\u0026rdquo; — is too easy. When you specify the API endpoints, the data model, or the UI layout, you\u0026rsquo;ve given away the implementation. An AI agent can fill a half-empty box with inferences in minutes.\nThe sweet spot sits between these extremes: vague requirements with a clear outcome expectation. The candidate must derive what to build. The AI can execute but can\u0026rsquo;t decide what to execute.\nThe Vagueness Spectrum graph LR A[\"Full Vagueness'Build something useful'Too open — no signal\"] B[\"Sweet SpotVague requirements +clear outcomeCandidate derives WHAT to build\"] C[\"Half Vagueness'POST /users, GET /users/{id}'Too specific — AI fills gaps\"] A -.- B -.- C style B fill:#16a34a,stroke:#333,color:#fff The hypothesis: if you write the problem the way a real stakeholder would — with gaps and unstated assumptions — candidates who think deeply will naturally differentiate themselves. So we didn\u0026rsquo;t specify how to handle edge cases. Didn\u0026rsquo;t define NFRs. Didn\u0026rsquo;t list API endpoints. Just described what the system should do, left the rest to the candidate, and told them: \u0026ldquo;anything not specified is yours to decide.\u0026rdquo;\nThe ambiguity IS the test.\nThis is what separates \u0026ldquo;AI native\u0026rdquo; from \u0026ldquo;AI dependent\u0026rdquo;: can you figure out what to do when the spec doesn\u0026rsquo;t tell you?\nThe Time/Scope Paradox There\u0026rsquo;s a paradox in designing tests for the AI era, and it took us a while to reason through it:\nAlgorithm tests are dead. A short algorithm problem is a 1-minute problem today. Not enough signal. So ask for a full service. A real application — with a database, APIs, business logic, concurrency — is complex enough that AI can\u0026rsquo;t do it on autopilot. The candidate has to think. But full services are hard to test. You can\u0026rsquo;t grade hundreds of submissions by hand. You need automated testing. Which means you need a way to run each submission\u0026hellip; So ask candidates to dockerize? But requiring Docker is a huge implementation hint. Same for specifying API endpoints, database schemas, or any test infrastructure. Every hint you give is a hint the AI can use to skip the thinking. Every step toward testability pushes you toward specificity. And every step toward specificity makes the AI\u0026rsquo;s job easier and the candidate\u0026rsquo;s thinking shallower.\nThe Testability–Vagueness Paradox graph TD A[\"1. Algorithm tests are deadShort problem = 1 minute today\"] --\u003e|So...| B[\"2. Ask for a full serviceComplex enough to require thinking\"] B --\u003e|But...| C[\"3. Full services are hard to testNeed automated testing at scale\"] C --\u003e|So...| D[\"4. Specify test infrastructureDocker, endpoints, schemas...\"] D --\u003e|But...| E[\"Every hint makes AI's job easierCandidate's thinking gets shallower\"] E -.-\u003e|Back to square one| A OS[\"Open SourceCandidates document like OSSAI agent reads docs and tests\"] OS ==\u003e|Breaks the cycle| C style OS fill:#16a34a,stroke:#333,color:#fff The resolution came from an unexpected place: open source.\nOpen source projects don\u0026rsquo;t tell you how to test them by specifying exact endpoints or Docker commands in a grading rubric. They tell you by documenting themselves well. A good open source project has a README that explains how to build and run it. It has a health check. It has API documentation that another developer — or an agent — can read and use.\nSo instead of specifying test infrastructure, we asked candidates to document their work the way a good open source project would. Document how to build it. Document how to run it. Document how to test it. Then our evaluation agent — an AI itself — reads their documentation, builds their project, and tests their features.\nThe candidate who thinks about testability-for-others naturally writes a better README, better build scripts, better health checks, better API docs. Without being told to. Without hints.\nThe way they package their code IS part of what we evaluate.\nWhat We Actually Asked With all that philosophy in place, what did the test actually look like?\nWe gave candidates a problem: build a university course registration system.\nIt starts with a memo from the product team:\n\u0026ldquo;매 학기 수강신청 기간마다 서버가 다운되어 학생들의 불만이 폭주하고 있습니다. 이번에는 제대로 된 시스템을 만들어주세요.\u0026rdquo;\n\u0026ldquo;Every semester the server crashes during course registration and students are furious. This time, please build a proper system.\u0026rdquo;\nThe memo lists basic features — student listing, course listing, enrollment, cancellation, timetable view. It mentions an 18-credit cap and time conflicts. And then this line:\n\u0026ldquo;정원이 1명 남은 강좌에 100명이 동시에 신청해도, 정확히 1명만 성공해야 합니다.\u0026rdquo;\n\u0026ldquo;Even if 100 people simultaneously apply for a course with 1 seat remaining, exactly 1 must succeed.\u0026rdquo;\nThat\u0026rsquo;s it. No lock mechanism specified. No performance requirements. No NFRs. No authentication model. No cancellation policies. No prerequisite rules.\nAnd the problem says explicitly: \u0026ldquo;명시되지 않은 모든 사항은 자유롭게 결정하세요\u0026rdquo; — \u0026ldquo;For anything not specified, decide freely.\u0026rdquo;\nSome might push back here: \u0026ldquo;But you told them what to build — a course registration system. That\u0026rsquo;s not vague at all.\u0026rdquo;\nIs it? What is a course registration system? Can you fully define one from a single sentence? Think about what\u0026rsquo;s hiding behind those words: concurrency under extreme contention, data integrity across multiple business rules, performance under load, failure modes, edge cases in scheduling, fairness in seat allocation. A \u0026ldquo;course registration system\u0026rdquo; is a universe of unstated complexity compressed into four words.\nBut here\u0026rsquo;s the thing — our candidates have lived this problem. They\u0026rsquo;ve fought through broken registration systems at their own universities, cursed at ticket booking sites that crashed under load. They know, at least from the customer\u0026rsquo;s perspective, what happens when these systems fail under competition. That shared experience is the seed. The problem definition starts from that sentence, but it\u0026rsquo;s a starting point — not a specification.\nThe real question is: from that one sentence, how far can you go? How do you expand a lived frustration into a structured system design? How do you define what \u0026ldquo;the right system\u0026rdquo; even means when the people asking for it don\u0026rsquo;t fully know themselves? There\u0026rsquo;s a reason scientists and mathematicians start from definitions — because the act of defining is where the real thinking happens.\nThis used to be the domain of senior ICs — the ability to take an ambiguous mandate and turn it into a clear technical direction. With AI as a thinking partner, that boundary is dissolving. A junior engineer who knows how to explore a problem space with their agent — asking the right questions, stress-testing assumptions, surfacing edge cases — can now do work that used to require a team. Any engineer can operate like a senior IC. The ones who actually do are the ones we\u0026rsquo;re looking for.\nEvery design principle from the previous sections converges in this problem. The vagueness is calibrated: you know what to build (a registration system), but you must derive how. The outcome expectation is clear (100 concurrent requests, 1 winner), but the mechanism is yours to choose. The problem reads like a real product team memo — because that\u0026rsquo;s what you\u0026rsquo;ll be reading on day one of the job.\nThe intentional ambiguity creates natural divergence points — places where different depths of thinking lead to meaningfully different solutions. Let\u0026rsquo;s walk through a few.\nHidden Depths The Data Design Trap The problem requires generating realistic test data at startup: 10,000+ students, 500+ courses, 100+ professors — dynamically, within 1 minute.\nOn the surface, this seems straightforward. Generate some students, generate some courses, assign professors. Done.\nBut the hidden complexity is in the relationships. How do you assign course schedules? If you generate random time slots, you might end up with courses that all overlap — making meaningful enrollment testing impossible. How do you set capacities? Too large, and your concurrency test is trivial. Too small, and your system is unusable. How do you structure professor-course relationships? One professor per course, or realistic loads?\nThe candidates who thought ahead designed their data generation with the downstream use case in mind — creating schedules diverse enough to test time conflicts, capacities tight enough to exercise concurrency, and relationships realistic enough to surface edge cases. They treated data design as system design, not as a throwaway script.\nThe candidates who didn\u0026rsquo;t think ahead generated flat, disconnected data — technically valid, but revealing a shallow understanding of what the system needed to do with that data. Their seeder worked, but it didn\u0026rsquo;t create a world worth testing.\nThis is a design problem hiding inside a data problem. And candidates who recognized it — who documented their data generation strategy and explained why they made specific choices — showed exactly the kind of thinking we\u0026rsquo;re looking for.\nThe Concurrency Ladder We said \u0026ldquo;handle 100 concurrent requests\u0026rdquo; but never specified how. No mention of pessimistic locks, optimistic locks, queues, single-machine vs. distributed. What candidates chose reveals their depth of thinking:\nLevel Approach What it reveals Surface synchronized / in-memory queue Knows the word \u0026ldquo;concurrency,\u0026rdquo; thinks single-JVM Competent DB pessimistic lock (SELECT ... FOR UPDATE) Understands DB-level serialization Thoughtful Custom optimistic locking with retry Understands trade-offs, chose performance Deep Distributed lock (Redis/ZooKeeper) Thinks beyond single machine Exceptional Distributed transaction analysis Considers what happens when the lock itself fails No level is \u0026ldquo;wrong.\u0026rdquo; A candidate who chooses synchronized and clearly explains why — single-instance scope, simplicity for the stated constraints, documented trade-offs — scores better than one who throws in Redis without understanding why.\nThe reasoning matters more than the mechanism. It\u0026rsquo;s not which lock you picked — it\u0026rsquo;s why you picked it.\nCould a sharper AI or a better prompt surface these insights for the candidate? Of course. And that\u0026rsquo;s fine — duck typing applies here. If it walks like deep thinking and quacks like deep thinking, it\u0026rsquo;s deep thinking. The skill isn\u0026rsquo;t arriving at the insight unaided. It\u0026rsquo;s arriving at the insight, period — whether through your own reasoning or through a well-directed conversation with your agent.\nThe Dual-Lock Insight This is the deepest divergence point. Fewer than one in five candidates showed clear evidence of implementing both locking scopes — and of those, only about half left traces of recognizing the problem themselves in their prompts or design documents, rather than having their AI agent silently handle it. (There\u0026rsquo;s also the possibility that the agent solved it before the candidate ever encountered the problem — removing the opportunity to think about it at all.)\nMost candidates think about concurrency purely in terms of course-level locking — protecting the capacity invariant. If 100 people rush for 1 seat, only 1 should succeed. Lock the course row. Done.\nBut that\u0026rsquo;s only half the problem.\nConsider what happens when the same student sends two concurrent registration requests — maybe they double-clicked, maybe they had two browser tabs. Two requests arrive simultaneously for different courses. Both check: \u0026ldquo;Is this student under 18 credits?\u0026rdquo; Both see 15 credits. Both pass. Both enroll. The student now has 21 credits. The credit limit is violated.\nThe Dual-Lock Problem: Why Course-Level Locking Isn\u0026#39;t Enough sequenceDiagram actor S as Student (15 credits) participant R1 as Request 1Course A (3cr) participant DB as Database participant R2 as Request 2Course B (3cr) S-\u003e\u003eR1: Register S-\u003e\u003eR2: Register (concurrent) Note over R1,R2: Course-level lock only — no student-level lock R1-\u003e\u003eDB: SELECT credits → 15 R2-\u003e\u003eDB: SELECT credits → 15 R1-\u003e\u003eDB: 15 + 3 = 18 ≤ 18 ✓ ENROLL R2-\u003e\u003eDB: 15 + 3 = 18 ≤ 18 ✓ ENROLL Note over DB: Result: 21 credits — limit violated The same pattern breaks time conflict detection and duplicate enrollment checks.\nCourse-level serialization protects the capacity invariant — the shared resource across all students.\nStudent-level serialization protects per-student constraints — credit limits, time conflicts, duplicate enrollment.\nYou need both. And once you need both, a new problem appears: lock ordering. If one code path acquires the student lock first and another acquires the course lock first, you get deadlock. The deeper the concurrency thinking, the more traps open up.\nThe mechanism can differ — pessimistic lock, optimistic lock with retry, application-level lock, distributed lock, serializable isolation. But the requirement is the same: concurrent requests from the same student must be serialized to prevent invariant violations.\nThe candidates who got here are the engineers we want — whether they reasoned it out themselves or through a well-directed conversation with their agent. And among them, some went further: not just solving the problem but documenting why it needed to be solved this way, building the kind of understanding that transfers to the next problem they\u0026rsquo;ll face. Our evaluation model is designed to surface exactly that difference.\nFrom Philosophy to Practice All of this philosophy is meaningless without a way to measure it. We built a 3-tier evaluation model — and the structure isn\u0026rsquo;t arbitrary. Each tier asks a progressively deeper question. As we\u0026rsquo;ll see in Parts 2 and 3, the signals a machine could actually read from submitted artifacts turned out to be more nuanced than we expected — but the framework itself held.\n3-Tier Evaluation Model graph BT T1[\"Tier 1 — Make it WorkBuild · Start · Health checkCan you ship a running service?\"] T2[\"Tier 2 — Basic FeaturesAPIs · Business rules · ConcurrencyDoes it work correctly under load?\"] T3[\"Tier 3 — Deep ThoughtPrompts · Design docs · Git history · Code qualityDo you understand what you shipped?\"] T1 --\u003e T2 --\u003e T3 DT[\"Duck TypingExternal behavior is the test\"] BDT[\"Beyond Duck TypingInternal understanding reveals growth\"] T1 ~~~ DT T2 ~~~ DT T3 ~~~ BDT style DT fill:#2563eb,stroke:#333,color:#fff style BDT fill:#16a34a,stroke:#333,color:#fff Tier 1 — Make it Work. Does the application build? Does it start? Does the health check respond? If you can\u0026rsquo;t ship a running service, nothing else matters.\nTier 2 — Basic Features. Do the APIs work? Are business rules enforced? Does concurrency control actually hold under load? Automated test cases across multiple categories, run inside Docker containers, no human in the loop.\nTiers 1 and 2 are duck typing. Does it behave like a working system? Then it\u0026rsquo;s a working system. We don\u0026rsquo;t care how the candidate got there — the external behavior is the test.\nTier 3 — Deep Thought. This is where we go beyond duck typing. Duck typing tells you it works — it doesn\u0026rsquo;t tell you whether the engineer will keep working at this level, or whether they\u0026rsquo;ll grow. So we look inside: the candidate\u0026rsquo;s prompt history, agent instructions, requirement derivation documents, data design choices, code quality, test coverage, git history, and additional implementations. An AI evaluates these dimensions — with every score backed by specific file paths and line numbers.\nTier 3 is where we distinguish delegation from engagement — and this distinction matters more than it might seem.\nAnthropic\u0026rsquo;s recent research on AI-assisted coding (\u0026ldquo;How AI assistance impacts the formation of coding skills,\u0026rdquo; Shen \u0026amp; Tamkin, 2026) draws a sharp line between these two modes. Engineers who delegate to AI are faster on any single task. But engineers who engage with understanding — who use AI as a collaborator to learn and verify, not just to produce — build skills that compound over time. Anthropic\u0026rsquo;s own internal data shows their top performers achieve 1.2–2x throughput gains precisely because they treat AI as a thinking partner, not a replacement for thought.\nThat\u0026rsquo;s the bet behind our scoring: depth of thinking outweighs functional completeness. Tier 1 answers \u0026ldquo;can you build and run it?\u0026rdquo; Tier 2 answers \u0026ldquo;does it work as intended?\u0026rdquo; Tier 3 answers \u0026ldquo;do you understand what you shipped — and can you grow from here?\u0026rdquo;\nHere\u0026rsquo;s a concrete example. Two candidates both implement dual-lock correctly. Duck typing says they\u0026rsquo;re equivalent — the behavior is the same. But look beyond the interface: one explored the problem through progressively deeper prompts, documented why each serialization scope exists, and left evidence of genuine understanding in their git history. The other landed on it through a generic prompt and moved on. Same output. Very different internals.\nHigh functional scores with shallow depth signals AI over-dependency — ships fast but can\u0026rsquo;t explain why. A failed build with exceptional design thinking tells a different story — someone worth interviewing despite the technical stumble. We\u0026rsquo;re not just finding who got to the right answer. We\u0026rsquo;re finding who understood the question.\nThis is how philosophy becomes practice. In the next post, I\u0026rsquo;ll walk through the actual machine we built — the automated pipeline that evaluates about 400 candidates with AI judging AI-assisted code. And the limits of automated evaluation we ran into — and why human judgment turned out to be necessary.\nThis is Part 1 of a 3-part series. Next: \u0026ldquo;The Machine: AI Evaluating AI-Assisted Code\u0026rdquo; — the technical deep-dive into our automated evaluation pipeline.\n","permalink":"http://taokim.dev/posts/2026-02-24-ai-native-hiring-philosophy/","summary":"\u003cblockquote\u003e\n\u003cp\u003e🇰🇷 \u003ca href=\"/posts/2026-02-24-ai-native-hiring-philosophy.ko/\"\u003e한국어 버전 읽기\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThis is Part 1 of the AI-native hiring series.\n\u003cstrong\u003ePart 2-1\u003c/strong\u003e: \u003ca href=\"/posts/2026-02-24-ai-native-hiring-machine/\"\u003e\u0026ldquo;The Machine\u0026rdquo;\u003c/a\u003e | \u003cstrong\u003ePart 2-2\u003c/strong\u003e: \u003ca href=\"/posts/2026-02-24-ai-native-hiring-under-the-hood/\"\u003e\u0026ldquo;Under the Hood\u0026rdquo;\u003c/a\u003e | \u003cstrong\u003ePart 3\u003c/strong\u003e: \u0026ldquo;The Human\u0026rdquo; (coming soon)\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cimg alt=\"AI Rookie #1 — AI Native Engineering Track\" loading=\"lazy\" src=\"/images/musinsa-rookies/ai-rookie-1-banner.png\"\u003e\u003c/p\u003e\n\u003cp\u003eIn January 2026, we ran an AI-native engineering hiring round at Musinsa — hundreds of candidates, evaluated end-to-end by an automated AI pipeline. We defined the problem, built the automated evaluation pipeline, and shaped the philosophy behind it all. This series is about what we learned.\u003c/p\u003e","title":"The Philosophy: AI-Native Hiring"},{"content":" 이 블로그의 첫 테스트 포스트입니다. 예전에 직접 겪고 해결했던 내용을 정리한 글이며, 내용은 여전히 유효합니다.\n1. 시작하며: \u0026lsquo;dkssud\u0026rsquo;와 \u0026lsquo;gksrmf\u0026rsquo;의 고통 맥(Mac)으로 문서를 작성할 때, 한영 전환키로 Caps Lock 키를 사용하고 계신다면 한영 전환 시 의도와 달리 키를 눌렀음에도 키가 씹히는 현상을 겪어보셨을 겁니다.\n분명 한영 키(Caps Lock)를 눌렀다고 생각했는데, 화면에는 dkssud (안녕하세요) 또는 gksrmf (한글)이 찍히는 순간입니다. 특히 빠르게 타이핑할 때 이 \u0026lsquo;한영 전환 딜레이\u0026rsquo; 또는 **\u0026lsquo;씹힘 현상\u0026rsquo;**은 더욱 심해지며, 사소하지만 업무 효율을 떨어트리는 큰 스트레스 요인이 됩니다.\n이 문서는 이 고질적인 문제의 정확한 원인을 진단하고, 딜레이 없는 즉각적인 한영 전환을 설정하는 가장 확실한 해결책을 단계별로 안내합니다.\n2. 딜레이(씹힘) 현상의 정확한 원인 이 딜레이는 버그가 아니라, 맥OS가 Caps Lock 키 하나에 두 가지 기능을 부여했기 때문에 발생하는 **\u0026lsquo;의도된 대기 시간\u0026rsquo;**입니다.\n기능 1 (짧게 누름): 한영 전환 기능 2 (길게 누름): 대문자 고정 (Caps Lock) 사용자가 Caps Lock 키를 눌렀을 때, 맥OS는 \u0026ldquo;이 사람이 한영 전환을 하려는 걸까, 대문자 고정을 하려는 걸까?\u0026ldquo;를 판단하기 위해 아주 짧은 시간(약 0.x초) 동안 기다립니다.\n바로 이 \u0026lsquo;판단 시간\u0026rsquo;이 우리가 타이핑 속도를 따라잡지 못하고 \u0026lsquo;씹힌다\u0026rsquo;고 느끼는 딜레이의 정체입니다.\n3. (참고) iOS와 macOS의 차이점 아이러니하게도, 우리가 이 \u0026lsquo;수동 전환\u0026rsquo; 딜레이로 고통받는 동안 아이폰(iOS)의 한글 입력 시스템은 훨씬 더 진화해 있습니다.\niOS에서는 gksrmf를 입력해도 \u0026lsquo;한글\u0026rsquo;로 자동 변환해 주거나, 문맥을 파악해 키보드 언어를 스스로 바꿔주는 인공지능 기반의 입력기를 제공합니다. 하지만 현재, 이 편리한 iOS의 지능형 입력 시스템은 아직 macOS에는 공식적으로 지원되지 않습니다.\n따라서, 미래의 업데이트를 기다리기보다 현재 우리가 겪는 \u0026lsquo;수동 전환 딜레이\u0026rsquo; 문제부터 즉각 해결하는 것이 중요합니다.\n4. 해결 전략: \u0026lsquo;판단\u0026rsquo;을 없애고 \u0026lsquo;즉시 명령\u0026rsquo;을 내린다 해결 방법은 간단합니다. 맥OS의 \u0026lsquo;판단\u0026rsquo; 과정을 아예 생략하게 만들면 됩니다.\nCaps Lock 키를 \u0026lsquo;한영 전환\u0026rsquo;이나 \u0026lsquo;대문자 고정\u0026rsquo;이 아닌, **아무 기능도 없는 가짜 키(예: F18)**로 바꿉니다. (이 신호는 딜레이 없이 즉시 발생합니다.) 맥 시스템에는 \u0026ldquo;F18 신호가 들어오면, 딜레이 없이 즉시 한영을 전환하라\u0026quot;고 명령을 설정합니다. Caps Lock 누름 → F18 신호 즉시 발생 → 시스템이 즉시 한영 전환.\n이렇게 \u0026lsquo;판단 시간\u0026rsquo;이 0이 됩니다.\n5. 완벽 해결 가이드 (Step-by-Step) 이 설정에는 무료 오픈소스 프로그램인 Karabiner-Elements가 필요합니다.\n1단계: Karabiner-Elements 설치 및 권한 설정 karabiner-elements.pqrs.org 공식 사이트에서 최신 버전을 다운로드하여 설치합니다. 🚨 [매우 중요] 설치 후 시스템 설정 \u0026gt; 개인정보 보호 및 보안으로 이동합니다. 손쉬운 사용과 입력 모니터링 두 곳에서 Karabiner 앱들(karabiner_grabber, karabiner_observer 등)의 권한을 [허용] 해야 합니다. (권한이 없으면 키 변경이 절대 작동하지 않습니다.) 2단계: Karabiner에서 키 매핑하기 (Caps Lock → F18) Karabiner-Elements 앱을 실행합니다. 왼쪽 메뉴에서 **[Simple Modifications]**를 선택합니다. [Add item] 버튼을 클릭합니다. From key (좌측): caps_lock을 선택합니다. To key (우측): 키보드에 없는 가상 키인 f18을 찾아 선택합니다. Tip: 윈도우 키보드처럼 스페이스바 우측의 Right Command 키를 한영 전환으로 쓰고 싶다면, From key에서 right_command를 선택해도 동일하게 작동합니다.\n3단계: 맥 시스템 설정에서 단축키 변경하기 (F18 → 한영 전환) 이제 맥OS에게 \u0026ldquo;F18이 한영 전환 키다\u0026quot;라고 알려줄 차례입니다.\n시스템 설정 \u0026gt; 키보드로 이동합니다. [키보드 단축키\u0026hellip;] 버튼을 클릭합니다. 왼쪽 목록에서 **[입력 소스]**를 선택합니다. 오른쪽의 \u0026lsquo;이전 입력 소스 선택\u0026rsquo; 항목을 더블 클릭하여 편집 상태로 만듭니다. (기존 ^ Space 등) 편집 대기 상태에서, 방금 2단계에서 설정한 Caps Lock 키를 한 번 누릅니다. 단축키가 F18로 바뀌는 것을 확인하고 [완료]를 누릅니다. 4단계: (필수) 기존 Caps Lock 기능 충돌 방지 마지막으로, 맥OS의 기본 한영 전환 기능과 충돌하지 않도록 해당 기능을 꺼야 합니다.\n시스템 설정 \u0026gt; 키보드로 다시 돌아옵니다. 텍스트 입력 항목 우측의 [편집\u0026hellip;] 버튼을 누릅니다. \u0026lsquo;Caps Lock 키로 [마지막으로 사용한\u0026hellip;] 입력 소스 전환\u0026rsquo; 옵션을 **[끔 (OFF)]**으로 변경합니다. 6. 설정 완료 및 보안 Q\u0026amp;A 이제 모든 설정이 끝났습니다. 메모장을 열고 Caps Lock 키를 빠르게 눌러보세요. 딜레이나 씹힘 없이 즉각적으로 한영이 전환되는 쾌적한 타이핑 환경이 완성되었습니다.\nQ. (보안) Karabiner 앱, 믿을 수 있나요? \u0026lsquo;입력 모니터링\u0026rsquo; 권한이 찝찝합니다. 좋은 질문입니다. \u0026lsquo;입력 모니터링\u0026rsquo;은 기술적으로 키로깅(Keylogging)이 가능한 강력한 권한입니다. 하지만 Karabiner는 다음 두 가지 이유로 전 세계 개발자들이 신뢰하고 사용하는 툴입니다.\n오픈 소스 (Open Source): 모든 소스 코드가 공개되어 있어, 악의적인 코드가 숨겨져 있다면 즉시 발각됩니다. 수년간 검증된 가장 투명한 방식입니다. 보안 입력(Secure Input) 보호: 맥OS는 로그인 창, 비밀번호 입력 필드 등 민감한 정보를 입력할 때 \u0026lsquo;보안 입력 모드\u0026rsquo;를 활성화합니다. 이 모드에서는 시스템 차원에서 Karabiner 같은 서드파티 앱의 키 입력을 차단하므로, 비밀번호가 유출될 걱정은 하지 않으셔도 됩니다. Q. 대문자 고정(Caps Lock)은 이제 어떻게 쓰나요? 이 설정으로 Caps Lock의 원래 기능은 사라집니다. 대문자 고정이 필요하다면 Shift 키를 누른 상태로 타이핑해야 합니다. (만약 두 기능을 모두 사용하고 싶다면 Karabiner의 Complex Modifications에서 별도 규칙을 추가해야 합니다.)\n","permalink":"http://taokim.dev/posts/2026-03-04-mac-korean-english-switch-delay-fix/","summary":"\u003cblockquote\u003e\n\u003cp\u003e이 블로그의 첫 테스트 포스트입니다. 예전에 직접 겪고 해결했던 내용을 정리한 글이며, 내용은 여전히 유효합니다.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-시작하며-dkssud와-gksrmf의-고통\"\u003e1. 시작하며: \u0026lsquo;dkssud\u0026rsquo;와 \u0026lsquo;gksrmf\u0026rsquo;의 고통\u003c/h2\u003e\n\u003cp\u003e맥(Mac)으로 문서를 작성할 때, 한영 전환키로 Caps Lock 키를 사용하고 계신다면 한영 전환 시 의도와 달리 키를 눌렀음에도 키가 씹히는 현상을 겪어보셨을 겁니다.\u003c/p\u003e\n\u003cp\u003e분명 한영 키(\u003ccode\u003eCaps Lock\u003c/code\u003e)를 눌렀다고 생각했는데, 화면에는 \u003ccode\u003edkssud\u003c/code\u003e (안녕하세요) 또는 \u003ccode\u003egksrmf\u003c/code\u003e (한글)이 찍히는 순간입니다. 특히 빠르게 타이핑할 때 이 \u003cstrong\u003e\u0026lsquo;한영 전환 딜레이\u0026rsquo;\u003c/strong\u003e 또는 **\u0026lsquo;씹힘 현상\u0026rsquo;**은 더욱 심해지며, 사소하지만 업무 효율을 떨어트리는 큰 스트레스 요인이 됩니다.\u003c/p\u003e","title":"맥(Mac) 한영 전환 딜레이(씹힘) 해결 가이드"},{"content":" 🇰🇷 한국어 버전 읽기\nThis post was originally published on the MUSINSA Tech Blog in Korean. This is the English adaptation.\nA note from 2026: I wrote this when AI-driven change was already well underway — but it has only accelerated since. The progression from \u0026lsquo;How\u0026rsquo; to \u0026lsquo;Why\u0026rsquo; was already underway — but AI has pushed it one step beyond, to \u0026lsquo;What.\u0026rsquo; As implementation costs plummet with AI-assisted coding, the \u0026lsquo;Micro\u0026rsquo; (How) is being commoditized faster than anyone expected. The \u0026lsquo;Macro\u0026rsquo; perspective — asking \u0026lsquo;Why\u0026rsquo; and especially \u0026lsquo;What should we build?\u0026rsquo; — has become not just valuable but essential. Looking back, this framing feels even more relevant now, perhaps even understated at the time. That\u0026rsquo;s why I\u0026rsquo;m resharing it here — as a lens for reading what\u0026rsquo;s happening around us.\nSubtitle: A Senior IC\u0026rsquo;s story of breaking through the \u0026lsquo;wall\u0026rsquo; with \u0026lsquo;Macro Coding\u0026rsquo;\nHi, I\u0026rsquo;m Tao Kim. I work at MUSINSA as a Distinguished Engineer and company-wide tech lead.\nThis is my first post on the MUSINSA tech blog. I plan to share various topics and thoughts going forward. For the first topic, I\u0026rsquo;d like to talk about growth in my role as a Senior IC (Individual Contributor).\nAs a Senior IC, I participate in company-wide key decisions and work as an engineer. Having been in this role for a while, I often get questions about career and growth. With MUSINSA recently formalizing the IC Career Path alongside the manager track, I\u0026rsquo;ve been regularly introducing this \u0026ldquo;new growth ladder\u0026rdquo; to colleagues.\nThe stories I\u0026rsquo;ve shared in tech talks, 1:1 meetings, and various internal channels — I\u0026rsquo;m publishing them here hoping they\u0026rsquo;ll help not just MUSINSA colleagues but engineers more broadly.\n1. To You Who Feel the \u0026lsquo;Wall\u0026rsquo; of Growth This post is for engineers who are shedding the junior title to move into senior roles, or those who already have the senior title but feel stuck about what comes next.\nHave you ever had thoughts like these?\n\u0026ldquo;I\u0026rsquo;m doing my best with clean code, refactoring, TDD\u0026hellip; why does my growth feel stagnant?\u0026rdquo; \u0026ldquo;My code is getting better, but why isn\u0026rsquo;t my impact at the company growing proportionally?\u0026rdquo; \u0026ldquo;I\u0026rsquo;m supposed to be a senior developer, but what I do doesn\u0026rsquo;t feel very different from when I was a junior.\u0026rdquo; \u0026ldquo;Why does my salary feel like it\u0026rsquo;s hit a ceiling?\u0026rdquo; If any of these resonate, you probably need an expansion of perspective. I believe the key to breaking through this growth \u0026lsquo;wall\u0026rsquo; lies in shifting from \u0026lsquo;Micro Coding\u0026rsquo; to \u0026lsquo;Macro Coding\u0026rsquo;.\n2. Is Your Coding \u0026lsquo;Micro\u0026rsquo; or \u0026lsquo;Macro\u0026rsquo;? To discuss growth, let me define two perspectives that I think help engineers understand.\n\u0026lsquo;Micro Coding\u0026rsquo; The perspective of a \u0026lsquo;Point\u0026rsquo;. Focuses on the quality of the code itself and implementing the current feature — variable names, function logic, class design, test coverage, code conventions. This is a fundamental and powerful virtue of a great developer. Clean code, TDD, refactoring all belong here. \u0026lsquo;Macro Coding\u0026rsquo; The perspective of a \u0026lsquo;Flow\u0026rsquo;. Focuses on how this code affects the entire system and business. It\u0026rsquo;s about how \u0026lsquo;points\u0026rsquo; come together to form \u0026rsquo;lines\u0026rsquo; and \u0026lsquo;surfaces\u0026rsquo; — seeing the bigger picture. Many engineers aim to become masters of \u0026lsquo;Micro Coding,\u0026rsquo; but at some point, they hit a \u0026lsquo;wall\u0026rsquo; of problems (or salary negotiations) that can\u0026rsquo;t be solved from that perspective alone.\nEngineer\u0026rsquo;s Job Title and Scope (with Gemini)\n[Self-Assessment] Do I Have a \u0026lsquo;Macro\u0026rsquo; Perspective? Here are some questions to check how much \u0026lsquo;Macro\u0026rsquo; perspective you\u0026rsquo;ve developed:\nIn the past month\u0026rsquo;s code reviews, beyond pointing out variable names, have you pointed out \u0026lsquo;failure flow of this logic\u0026rsquo; or \u0026lsquo;business impact\u0026rsquo;? Can you explain within 30 seconds which business KPI (e.g., purchase conversion rate) the feature you\u0026rsquo;re currently building contributes to? When solving problems, have you ever asked \u0026lsquo;why should we do this?\u0026rsquo; and thought about a better \u0026lsquo;flow\u0026rsquo; before jumping to \u0026lsquo;how to implement it\u0026rsquo;? Are you confident that if traffic grows 10x in a year, the current architecture can handle it? When an API you built fails, can you picture what cascading failures might occur across the calling service (Caller) and the services you call (Callee)? If answering \u0026lsquo;Yes\u0026rsquo; to these questions feels difficult, you\u0026rsquo;re likely still in the \u0026lsquo;Micro\u0026rsquo; perspective.\n3. What Makes \u0026lsquo;Macro Coding\u0026rsquo; Different? So what specifically differs in the \u0026lsquo;Macro Coding\u0026rsquo; perspective?\nPerspective 1: See the \u0026lsquo;Flow,\u0026rsquo; Not the \u0026lsquo;Point\u0026rsquo; While \u0026lsquo;Micro\u0026rsquo; focuses on \u0026ldquo;how can I make this Spark function more efficient?\u0026rdquo;, \u0026lsquo;Macro\u0026rsquo; thinks \u0026ldquo;if this Spark Job fails, the entire data pipeline halts — how do we design the recovery flow on failure?\u0026rdquo;\nIf code is a \u0026lsquo;point,\u0026rsquo; data and requests are a \u0026lsquo;flow.\u0026rsquo; The \u0026lsquo;Macro\u0026rsquo; perspective designs \u0026lsquo;drains and detours\u0026rsquo; for when this flow gets blocked or bursts. (e.g., Retry, Circuit Breaker, Dead Letter Queue)\nPerspective 2: Ask \u0026lsquo;Why\u0026rsquo; Before \u0026lsquo;How\u0026rsquo; The \u0026lsquo;Micro\u0026rsquo; perspective focuses on \u0026lsquo;how\u0026rsquo; to implement the given ticket well. The \u0026lsquo;Macro\u0026rsquo; perspective first asks \u0026lsquo;why\u0026rsquo; this ticket was given to us.\nMicro: \u0026ldquo;When you press this button, make user info pop up in a modal.\u0026rdquo; Macro: \u0026ldquo;Is showing user info in a \u0026lsquo;modal\u0026rsquo; really the best approach? \u0026lsquo;Why\u0026rsquo; do they need to see user info? Wouldn\u0026rsquo;t it serve the business goal better to show just the key info via a Nudge instead of a modal?\u0026rdquo; Asking \u0026lsquo;why\u0026rsquo; isn\u0026rsquo;t encroaching on the PM or planner\u0026rsquo;s territory — it\u0026rsquo;s the core competency of a senior engineer who solves business problems better with technology.\nPerspective 3: Look Beyond \u0026lsquo;Code\u0026rsquo; to Beyond \u0026lsquo;API\u0026rsquo; A real example I experienced: An engineer reported \u0026ldquo;I keep getting HTTP timeouts calling Service A\u0026rsquo;s API. My logic has no issues — seems like Service A\u0026rsquo;s problem.\u0026rdquo;\nThe \u0026lsquo;Micro\u0026rsquo; perspective stops at \u0026lsquo;my code\u0026rsquo;s\u0026rsquo; boundary. \u0026ldquo;My code is fine. Service A isn\u0026rsquo;t responding. My responsibility ends here.\u0026rdquo; The \u0026lsquo;Macro\u0026rsquo; perspective looks beyond \u0026rsquo;the API.\u0026rsquo; \u0026ldquo;Why is Service A timing out? Should I look at Service A\u0026rsquo;s logs too? Maybe Service A depends on Service B, and B is dying? Oh, Service A is making too many synchronous calls. I should propose switching this to an async queue architecture.\u0026rdquo; The \u0026lsquo;Macro\u0026rsquo; perspective aims for the success of the \u0026rsquo;entire flow,\u0026rsquo; not just \u0026lsquo;my code.\u0026rsquo; Systems are organically connected, and the thread to solving problems often lies beyond \u0026lsquo;my code\u0026rsquo;s boundary.\u0026rsquo;\n4. Design \u0026lsquo;Factories,\u0026rsquo; Not \u0026lsquo;Stamps\u0026rsquo; To draw an analogy between \u0026lsquo;Micro\u0026rsquo; and \u0026lsquo;Macro\u0026rsquo; — it\u0026rsquo;s the difference between a \u0026lsquo;stamp\u0026rsquo; and a \u0026lsquo;factory.\u0026rsquo;\nThe \u0026lsquo;Micro\u0026rsquo; perspective is close to a \u0026lsquo;craftsman\u0026rsquo; who carves a stamp with exquisite precision. The focus is on how beautiful and error-free the stamp is. The \u0026lsquo;Macro\u0026rsquo; perspective is close to an \u0026lsquo;architect\u0026rsquo; who designs a \u0026lsquo;factory\u0026rsquo; that stamps out 10,000 of those stamps per second. The quality of the stamp itself is baseline; they design \u0026lsquo;what flow\u0026rsquo; the stamp goes through, \u0026lsquo;how to mass-produce\u0026rsquo; it, and \u0026lsquo;how to recover when the factory stops.\u0026rsquo; This is, in addition to beautiful craftsmanship, the reality of \u0026lsquo;industrialization\u0026rsquo; that cannot be refused — a matter of scale and impact. A few years ago in Japan, an automated robot for stamping \u0026lsquo;Hanko\u0026rsquo; (personal seals) became a hot topic. How should we view this phenomenon?\nAutomated stamp robot factory line (with Gemini)\nThis symbolically shows what can happen when you\u0026rsquo;re too immersed in the \u0026lsquo;Micro\u0026rsquo; perspective alone. No matter how exquisitely you hone the \u0026lsquo;stamp-carving skill\u0026rsquo; (Micro), if \u0026lsquo;machines\u0026rsquo; that automate the process appear, an individual\u0026rsquo;s craftsmanship can become meaningless.\nBut we need to go one step further.\nIs the true \u0026lsquo;Macro\u0026rsquo; perspective about efficiently making \u0026lsquo;stamp-carving robots\u0026rsquo;? Or is it, like the \u0026lsquo;factory\u0026rsquo; analogy suggests, asking \u0026ldquo;why are we stamping at all? Can we replace this flow with e-Signatures?\u0026rdquo;\nThe \u0026lsquo;stamp robot\u0026rsquo; may be an extreme automation of \u0026lsquo;How,\u0026rsquo; but it\u0026rsquo;s missing the fundamental question of \u0026lsquo;Why\u0026rsquo; — it might be a sophisticated example of automating the wrong flow. The \u0026lsquo;Macro\u0026rsquo; perspective means not staying at \u0026lsquo;craftsmanship\u0026rsquo; or \u0026lsquo;machines (automation),\u0026rsquo; but constantly questioning whether \u0026rsquo;the current flow itself\u0026rsquo; is right and leading the larger \u0026lsquo;industrialization\u0026rsquo; change.\nThe Stamp Carver vs The Factory Builder (with Gemini)\n5. In Closing: Where Should Your Growth (and Salary) Be Bet? \u0026lsquo;Micro Coding\u0026rsquo; is the solid foundation of an engineer. Without this foundation, \u0026lsquo;Macro\u0026rsquo; is nothing but a castle in the sky.\nBut most organizations and education focus on \u0026lsquo;Micro.\u0026rsquo; Everyone preaches \u0026lsquo;clean code,\u0026rsquo; but nobody teaches how to design \u0026lsquo;business flows.\u0026rsquo;\nFrom the enterprise perspective, the leaders they need are engineers who can evolve from \u0026lsquo;Micro\u0026rsquo; to \u0026lsquo;Macro.\u0026rsquo; By the law of supply and demand, the scarcity of engineers with a \u0026lsquo;Macro\u0026rsquo; perspective inevitably leads to higher valuation.\nIf your growth feels stagnant, or your salary feels like it\u0026rsquo;s hit a \u0026lsquo;wall,\u0026rsquo; it\u0026rsquo;s time to reflect on whether your efforts are only focused on carving \u0026lsquo;stamps,\u0026rsquo; and whether you should be betting on building the bigger picture — \u0026lsquo;factories.\u0026rsquo;\nLastly, I\u0026rsquo;d like to close by thanking my Team MUSINSA Senior IC colleagues who helped greatly in writing this post.\nPostscript 1: \u0026lsquo;Micro\u0026rsquo; and \u0026lsquo;Macro\u0026rsquo; Are Simply Different Levels, Not a Matter of Superiority Please don\u0026rsquo;t misread this as \u0026ldquo;so Micro coding isn\u0026rsquo;t important?\u0026rdquo; Just as both macro and micro economics are important, both perspectives matter. Imagining only \u0026lsquo;Macro\u0026rsquo; while neglecting \u0026lsquo;Micro\u0026rsquo; is building a castle on sand. The \u0026lsquo;Macro\u0026rsquo; perspective becomes truly powerful when it\u0026rsquo;s built on the solid foundation of \u0026lsquo;Micro.\u0026rsquo; Don\u0026rsquo;t let your focus on Micro let you lose sight of Macro — and vice versa.\nThis post also isn\u0026rsquo;t about arguing who is the better engineer. It\u0026rsquo;s simply that most engineering organizations and education are concentrated on \u0026lsquo;Micro,\u0026rsquo; so the importance of \u0026lsquo;Macro\u0026rsquo; tends to be overlooked. From the enterprise perspective, the leaders they need are engineers who can build \u0026lsquo;Macro\u0026rsquo; on top of \u0026lsquo;Micro.\u0026rsquo; Since the supply of engineers with a \u0026lsquo;Macro\u0026rsquo; perspective is scarce relative to demand, I wanted to share the practical reality that they can be valued higher (in salary negotiations).\nPostscript 2: This Post Is Not for Every Senior Engineer The role of a senior engineer varies by organization and individual inclination. Some create irreplaceable value by diving to the extremes of \u0026lsquo;Micro\u0026rsquo; to become a \u0026lsquo;Specialist\u0026rsquo; in a specific domain. (e.g., kernel tuning, compilers, 3D rendering engines)\nThis post is not about domain specialists — it\u0026rsquo;s focused on growth for \u0026lsquo;Product Engineers\u0026rsquo; like myself, who solve business problems with technology.\nPostscript 3: On \u0026lsquo;Engineering Surface\u0026rsquo; In the main text, I used the metaphor of a stamp\u0026rsquo;s \u0026lsquo;surface.\u0026rsquo; This aligns with the concept commonly called \u0026lsquo;Engineering Surface\u0026rsquo; or \u0026lsquo;Surface Area\u0026rsquo; in engineering.\n\u0026lsquo;Engineering Surface\u0026rsquo; refers to all the \u0026lsquo;contact points\u0026rsquo; where a system communicates with the outside world.\nAPI specs: Endpoint and JSON structure like POST /users. Function signatures: Input and output of calculatePrice(user, item). Class interfaces: Externally callable Public Methods. The \u0026lsquo;Micro\u0026rsquo; craftsman focuses on how elegantly, cleanly, and precisely to polish this \u0026lsquo;Surface.\u0026rsquo;\nBut the \u0026lsquo;Macro\u0026rsquo; perspective sees this \u0026lsquo;Surface\u0026rsquo; differently. In a Microservice Architecture, if one service\u0026rsquo;s \u0026lsquo;Surface\u0026rsquo; becomes too large and complex (e.g., over 100 APIs and unmanageable), that\u0026rsquo;s a signal that the \u0026lsquo;Surface\u0026rsquo; is too bloated — grounds for service separation. In other words, the \u0026lsquo;Macro\u0026rsquo; perspective designs not just the beauty of the \u0026lsquo;Surface\u0026rsquo; itself, but the appropriate \u0026lsquo;size\u0026rsquo; and \u0026lsquo;boundaries\u0026rsquo; of that \u0026lsquo;Surface.\u0026rsquo;\n","permalink":"http://taokim.dev/posts/2026-02-24-stamp-carver-vs-factory-builder/","summary":"\u003cblockquote\u003e\n\u003cp\u003e🇰🇷 \u003ca href=\"/posts/2026-02-24-stamp-carver-vs-factory-builder-ko/\"\u003e한국어 버전 읽기\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThis post was originally published on the \u003ca href=\"https://techblog.musinsa.com/%EB%8F%84%EC%9E%A5-%ED%8C%8C%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90-vs-%EA%B3%B5%EC%9E%A5-%EC%A7%93%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90-b33dddf5daef\"\u003eMUSINSA Tech Blog\u003c/a\u003e in Korean. This is the English adaptation.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eA note from 2026:\u003c/strong\u003e I wrote this when AI-driven change was already well underway — but it has only accelerated since. The progression from \u0026lsquo;How\u0026rsquo; to \u0026lsquo;Why\u0026rsquo; was already underway — but AI has pushed it one step beyond, to \u003cstrong\u003e\u0026lsquo;What.\u0026rsquo;\u003c/strong\u003e As implementation costs plummet with AI-assisted coding, the \u0026lsquo;Micro\u0026rsquo; (How) is being commoditized faster than anyone expected. The \u0026lsquo;Macro\u0026rsquo; perspective — asking \u0026lsquo;Why\u0026rsquo; and especially \u0026lsquo;What should we build?\u0026rsquo; — has become not just valuable but essential. Looking back, this framing feels even more relevant now, perhaps even understated at the time. That\u0026rsquo;s why I\u0026rsquo;m resharing it here — as a lens for reading what\u0026rsquo;s happening around us.\u003c/p\u003e","title":"The Stamp Carver vs. The Factory Builder"},{"content":" 🇺🇸 Read in English\n이 글은 무신사 테크 블로그에 게시된 원문입니다.\n2026년 노트: 이 글을 쓸 당시에도 AI로 인한 변화는 이미 진행 중이었지만, 그 이후로 변화는 더욱 가속되고 있습니다. \u0026lsquo;How(어떻게)\u0026lsquo;에서 \u0026lsquo;Why(왜)\u0026lsquo;로의 전환은 이미 시작됐지만, AI는 그 너머 — \u0026lsquo;What(무엇을 만들 것인가)\u0026rsquo; 까지 밀어붙이고 있습니다. AI 코딩의 등장으로 구현 비용이 급격히 낮아지면서, \u0026lsquo;마이크로(How)\u0026lsquo;는 예상보다 훨씬 빠르게 범용화되고 있습니다. \u0026lsquo;Why\u0026rsquo;를, 그리고 특히 \u0026lsquo;What should we build?\u0026lsquo;를 묻는 \u0026lsquo;매크로\u0026rsquo; 관점은 이제 단순히 가치 있는 것을 넘어 필수가 되었습니다. 돌아보면 이 글의 시각이 오히려 지금 더 유효하고, 어쩌면 당시엔 충분히 강하게 이야기하지 못했을 수도 있습니다. 지금 벌어지고 있는 변화를 읽는 하나의 렌즈로서 다시 공유합니다.\n부제: 시니어의 \u0026lsquo;벽\u0026rsquo;을 넘는 \u0026lsquo;매크로 코딩\u0026rsquo; 이야기\n안녕하세요, 무신사에서 Distinguished Engineer이자 전사 테크리드 로 일하고 있는 김상범(Tao)입니다.\n무신사 테크 블로그에 처음으로 글을 쓰게 되었습니다. 앞으로 다양한 주제와 생각을 공유드리고자 하며, 첫 번째 주제로 현재 제가 무신사에서 수행하고 있는 저의 역할인 \u0026lsquo;Senior IC(Individual Contributor)\u0026rsquo; 로의 성장에 대해 이야기해 보려 합니다.\n저는 소위 Senior IC 로서 무신사 전사 관점에서의 주요 의사 결정에 참여하고 있는 엔지니어 로 일하고 있습니다. 제가 이 역할을 오래 수행하다 보니, 커리어와 성장에 대한 질문을 자주 받습니다. 마침 무신사에서도 매니저가 아닌 IC 역할이 공식적인 커리어 패스(Career Path)로 자리 잡으면서, 저는 이 \u0026lsquo;새로운 성장의 사다리\u0026rsquo;를 동료들에게 소개하는 일을 꾸준히 하고 있습니다.\n테크톡, 1:1 미팅 등 다양한 사내 채널에서 나눈 이 이야기가, 무신사 동료뿐만 아니라 더 많은 엔지니어분들께도 도움이 되길 바라는 마음으로 블로그의 첫 주제로 선정했습니다.\n1. 성장의 \u0026lsquo;벽\u0026rsquo;을 느끼는 당신에게 이 글은 주니어 딱지를 떼고 시니어로 나아가려는, 혹은 이미 시니어 타이틀을 달고 있지만 다음 스텝이 막막한 엔지니어들을 위한 글입니다.\n혹시 이런 고민을 하고 있지 않나요?\n\u0026ldquo;클린 코드, 리팩토링, TDD… 나를 열심히 하는데 왜 성장이 정체된 것 같지?\u0026rdquo; \u0026ldquo;내 코드는 분명 좋아지고 있는데, 왜 회사에서의 영향력(Impact)은 그만큼 커지지 않을까?\u0026rdquo; \u0026ldquo;시니어 개발자라는데, 주니어 때와 하는 일이 크게 다르지 않은 것 같다.\u0026rdquo; \u0026ldquo;내 연봉은 왜 \u0026lsquo;벽\u0026rsquo;에 부딪힌 것처럼 더 이상 오르지 않을까?\u0026rdquo; 만약 위 질문 중 하나라도 해당된다면, 아마도 당신은 \u0026lsquo;관점의 확장\u0026rsquo;이 필요한 시점일 수 있습니다. 저는 이 성장의 \u0026lsquo;벽\u0026rsquo;을 넘는 열쇠가 \u0026lsquo;마이크로(Micro) 코딩\u0026rsquo; 에서 \u0026lsquo;매크로(Macro) 코딩\u0026rsquo; 으로 관점을 확장하는 데 있다고 생각합니다.\n2. 당신의 코딩은 \u0026lsquo;마이크로\u0026rsquo;인가요, \u0026lsquo;매크로\u0026rsquo;인가요? 성장이라는 주제를 이야기하고 엔지니어 여러분의 이해를 돕기 위해 제가 정의한 두 가지 관점입니다.\n\u0026lsquo;마이크로(Micro) 코딩\u0026rsquo; \u0026lsquo;점(Point)\u0026lsquo;의 관점입니다. 변수명, 함수 로직, 클래스 설계, 테스트 커버리지, 코드 컨벤션 등 \u0026lsquo;코드 자체\u0026rsquo;의 품질과 \u0026lsquo;지금 이 기능\u0026rsquo;의 구현에 집중합니다. 훌륭한 개발자의 기본기이자 강력한 미덕입니다. 클린 코드, TDD, 리팩토링 등이 모두 이 영역에 속합니다. \u0026lsquo;매크로(Macro) 코딩\u0026rsquo; \u0026lsquo;흐름(Flow)\u0026lsquo;의 관점입니다. 이 코드가 전체 시스템과 비즈니스에 어떤 영향을 미치는지에 집중합니다. \u0026lsquo;점\u0026rsquo;들이 모여 어떻게 \u0026lsquo;선\u0026rsquo;과 \u0026lsquo;면\u0026rsquo;을 이루는지, 더 큰 그림을 보는 것입니다. 많은 엔지니어가 \u0026lsquo;마이크로 코딩\u0026rsquo;의 달인이 되는 것을 목표로 하지만, 어느 순간 그 관점만으로는 해결할 수 없는 문제(혹은 연봉 테이블)의 \u0026lsquo;벽\u0026rsquo;을 만나게 됩니다.\nEngineer\u0026rsquo;s Job Title and Scope (with Gemini)\n[자가 진단] 나는 \u0026lsquo;매크로\u0026rsquo; 관점을 가지고 있을까? 스스로 \u0026lsquo;매크로\u0026rsquo; 관점을 얼마나 가졌는지 점검해 볼 수 있는 몇 가지 질문을 던져봅니다.\n최근 한 달간의 코드 리뷰에서, 변수명 지적 외에 \u0026lsquo;이 로직의 실패 흐름(Failure flow)\u0026lsquo;이나 \u0026lsquo;비즈니스 임팩트\u0026rsquo;를 지적한 적이 있는가? 현재 개발 중인 기능이 어떤 비즈니스 KPI(e.g., 구매 전환율)에 기여하는지 30초 안에 설명할 수 있는가? 문제를 해결할 때, \u0026lsquo;일단 구현(How)\u0026lsquo;하는 것보다 \u0026lsquo;왜(Why) 이걸 해야 하는지\u0026rsquo;를 먼저 질문하고 더 나은 \u0026lsquo;흐름\u0026rsquo;을 역제안한 경험이 있는가? 1년 뒤 트래픽이 10배가 되어도 지금의 아키텍처가 버틸 수 있다고 확신하는가? 내가 만든 API가 실패했을 때, 나를 호출한 서비스(Caller)와 내가 호출하는 서비스(Callee)에 어떤 연쇄 장애가 일어날지 그려지는가? 만약 위 질문에 \u0026lsquo;Yes\u0026rsquo;라고 답하기 어렵다면, 당신은 \u0026lsquo;마이크로\u0026rsquo; 관점에 머물러 있을 가능성이 높습니다.\n3. \u0026lsquo;매크로 코딩\u0026rsquo;은 무엇이 다른가? 그렇다면 \u0026lsquo;매크로 코딩\u0026rsquo;의 관점은 구체적으로 무엇이 다를까요?\n관점 1: \u0026lsquo;점\u0026rsquo;이 아닌 \u0026lsquo;흐름(Flow)\u0026lsquo;을 봅니다. \u0026lsquo;마이크로\u0026rsquo; 관점이 \u0026lsquo;이 함수는 스파크(Spark) 코드를 어떻게 짜야 더 효율적일까?\u0026lsquo;에 집중한다면, \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;이 스파크 잡(Job)이 실패하면 데이터 파이프라인 전체가 멈추는데, 실패 시 복구(Recovery) 흐름은 어떻게 설계할 것인가?\u0026lsquo;를 함께 고민합니다.\n코드가 \u0026lsquo;점\u0026rsquo;이라면, 데이터와 요청은 \u0026lsquo;흐름\u0026rsquo;입니다. \u0026lsquo;매크로\u0026rsquo; 관점은 이 \u0026lsquo;흐름\u0026rsquo;이 막히거나 터졌을 때를 대비한 \u0026lsquo;배수로나 우회로\u0026rsquo;를 설계하는 것입니다. (e.g., 재시도(Retry), 서킷 브레이커(Circuit Breaker), 데드 레터 큐(DLQ))\n관점 2: \u0026lsquo;어떻게(How)\u0026lsquo;보다 \u0026lsquo;왜(Why)\u0026lsquo;를 묻습니다. \u0026lsquo;마이크로\u0026rsquo; 관점은 주어진 티켓(Task)을 \u0026lsquo;어떻게\u0026rsquo; 잘 구현할지에 집중합니다. 반면 \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;왜\u0026rsquo; 이 티켓이 지금 우리에게 주어졌는지를 먼저 질문합니다.\nMicro: \u0026ldquo;이 버튼을 누르면 유저 정보가 팝업으로 뜨게 만들어야지.\u0026rdquo; Macro: \u0026ldquo;유저 정보를 \u0026lsquo;팝업\u0026rsquo;으로 띄우는 게 최선인가? \u0026lsquo;왜\u0026rsquo; 유저 정보를 봐야 하지? 차라리 팝업 없이 더 중요한 정보만 넛지(Nudge)로 보여주는 게 비즈니스 목표(e.g., 구매 전환)에 더 도움 되지 않을까?\u0026rdquo; \u0026lsquo;왜\u0026rsquo;를 묻는 것은 PM이나 기획자의 영역을 침범하는 것이 아니라, \u0026lsquo;기술로 비즈니스 문제를 더 잘 해결하려는\u0026rsquo; 시니어 엔지니어의 핵심역량 입니다.\n관점 3: \u0026lsquo;코드\u0026rsquo;가 아니라 \u0026lsquo;API 너머\u0026rsquo;를 봅니다. 제가 경험한 실례입니다. 한 엔지니어가 \u0026ldquo;A 서비스에 API를 호출하는데 자꾸 HTTP 타임아웃이 나요. 저의 로직은 문제가 없는데 A 서비스가 문제인 것 같아요\u0026quot;라고 보고했습니다.\n\u0026lsquo;마이크로\u0026rsquo; 관점은 \u0026lsquo;내 코드\u0026rsquo;의 경계에서 멈춥니다. \u0026ldquo;내 코드는 이상 없다. 호출한 A 서비스가 응답을 안 준다. 내 책임은 여기까지다.\u0026rdquo; \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;API 너머\u0026rsquo;를 봅니다. \u0026ldquo;A 서비스는 \u0026lsquo;왜\u0026rsquo; 타임아웃이 날까? A 서비스의 로그를 같이 볼까? 혹시 A 서비스가 의존하는 B 서비스가 죽은 건 아닐까? 아, A 서비스가 동기(Sync) 호출을 너무 많이 물고 있구나. 이걸 비동기(Async) 큐 구조로 바꾸자고 제안해야겠다.\u0026rdquo; \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;내 코드\u0026rsquo;의 성공이 아니라 \u0026lsquo;전체 흐름\u0026rsquo;의 성공을 목표로 합니다. 시스템은 유기적으로 연결되어 있으며, 문제 해결의 실마리는 종종 내 코드의 \u0026lsquo;경계 너머\u0026rsquo;에 있습니다.\n4. \u0026lsquo;도장\u0026rsquo;이 아닌 \u0026lsquo;공장\u0026rsquo;을 설계합니다. \u0026lsquo;마이크로\u0026rsquo;와 \u0026lsquo;매크로\u0026rsquo;의 차이를 비유하자면, \u0026lsquo;도장\u0026rsquo;과 \u0026lsquo;공장\u0026rsquo;의 차이입니다.\n\u0026lsquo;마이크로\u0026rsquo; 관점은 \u0026lsquo;도장\u0026rsquo;을 정교하게 파는 \u0026lsquo;장인\u0026rsquo; 에 가깝습니다. 얼마나 아름답고 오류 없는 도장을 만드느냐에 집중합니다. \u0026lsquo;매크로\u0026rsquo; 관점은 그 도장을 1초에 1만 개씩 찍어내는 \u0026lsquo;공장\u0026rsquo; 을 설계하는 \u0026lsquo;아키텍트\u0026rsquo; 에 가깝습니다. 도장 자체의 품질은 기본이고, 이 도장을 \u0026lsquo;어떤 흐름\u0026rsquo;으로, \u0026lsquo;어떻게 대량 생산\u0026rsquo;하며, \u0026lsquo;공장이 멈췄을 때 어떻게 복구\u0026rsquo;할지를 설계합니다. 이것은 아름다운 장인 정신에 더해, 거스를 수 없는 \u0026lsquo;산업화\u0026rsquo;의 현실이자, 스케일과 임팩트의 문제입니다. 몇년전 일본에서 \u0026lsquo;도장(Hanko)\u0026lsquo;을 찍어주는 자동화 로봇이 도입되어 화제가 되었습니다. 이 현상을 어떻게 바라봐야 할까요?\n도장 로봇을 기반으로 상상해본 공정 라인 (with Gemini)\n이는 \u0026lsquo;마이크로\u0026rsquo; 관점에만 너무 매몰되었을 때 발생할 수 있는 현상을 상징적으로 보여줍니다. 아무리 정교하게 \u0026lsquo;도장 찍는 기술(마이크로)\u0026lsquo;을 연마해도, 그 프로세스 자체를 자동화하는 \u0026lsquo;기계\u0026rsquo;가 등장하면 개인의 장인 정신은 무의미해질 수 있습니다.\n하지만 여기서 한 걸음 더 나아가야 합니다.\n진정한 \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;도장 찍는 로봇\u0026rsquo;을 효율적으로 만드는 것일까요? 아니면, 앞서 \u0026lsquo;공장\u0026rsquo;의 비유처럼 \u0026ldquo;왜 지금 도장을 찍고 있지? 이 흐름을 전자 서명(e-Signature)으로 대체할 순 없을까?\u0026rdquo; 라고 질문하는 것일까요?\n\u0026lsquo;도장 로봇\u0026rsquo;은 어쩌면 \u0026lsquo;어떻게(How)\u0026lsquo;를 극단적으로 자동화했지만, \u0026lsquo;왜(Why)\u0026lsquo;라는 근본적인 질문이 빠진, \u0026lsquo;잘못된 흐름\u0026rsquo;을 고도화한 예시일 수 있습니다. \u0026lsquo;매크로\u0026rsquo;한 관점은 이처럼 \u0026lsquo;장인 정신\u0026rsquo;이나 \u0026lsquo;기계(자동화)\u0026lsquo;에 머무르는 것이 아니라, \u0026lsquo;현재의 흐름 자체\u0026rsquo;가 올바른지 끊임없이 의심하고 더 큰 \u0026lsquo;산업화\u0026rsquo;의 변화를 읽고 주도하는 것을 의미합니다.\n도장 파는 개발자 vs 공장 짓는 개발자 (with Gemini)\n5. 글을 마치며: 당신의 성장(연봉)은 어디에 베팅되어야 할까요? \u0026lsquo;마이크로 코딩\u0026rsquo;은 엔지니어의 단단한 반석입니다. 이 반석이 없다면 \u0026lsquo;매크로\u0026rsquo;는 사상누각에 불과합니다.\n하지만 대부분의 조직과 교육은 \u0026lsquo;마이크로\u0026rsquo;에 집중되어 있습니다. \u0026lsquo;클린 코드\u0026rsquo;는 모두가 외치지만, \u0026lsquo;비즈니스 흐름\u0026rsquo;을 설계하는 법은 아무도 알려주지 않습니다.\n기업의 입장에서 필요한 리더는 \u0026lsquo;마이크로\u0026rsquo;를 기반으로 \u0026lsquo;매크로\u0026rsquo;를 상상할 수 있는 엔지니어입니다. 수요와 공급의 법칙에 따라, \u0026lsquo;매크로\u0026rsquo; 관점을 가진 엔지니어의 희소성은 높게 평가받을 수밖에 없습니다.\n당신의 성장이 정체되어 있다고 느낀다면, 어쩌면 당신의 연봉이 \u0026lsquo;벽\u0026rsquo;에 부딪혔다고 느낀다면, 지금 당신의 노력이 \u0026lsquo;도장\u0026rsquo;을 파는 데만 집중되어 있지는 않은지, \u0026lsquo;공장\u0026rsquo;을 짓는 더 큰 그림에 베팅해야 할 때는 아닌지 되돌아볼 시간입니다.\n마지막으로 이글을 작성하는데 큰 도움을 주신 팀무신사의 Senior IC 분들께 감사하다는 말 드리며 마무리하겠습니다.\n감사합니다.\n사족 1: \u0026lsquo;마이크로\u0026rsquo;와 \u0026lsquo;매크로\u0026rsquo;는 층위일 뿐, 우열의 문제가 아닙니다. 이 글을 읽고 \u0026ldquo;아, 그럼 마이크로 코딩은 중요하지 않다는 건가?\u0026ldquo;라고 오해하지 않으셨으면 합니다. 마치 거시 경제와 미시 경제적 관점이 모두 중요하듯이 둘 다 모두 중요한 관점입니다. \u0026lsquo;매크로\u0026rsquo;만 상상하고 \u0026lsquo;마이크로\u0026rsquo;가 부실하면 그것은 \u0026lsquo;사상누각\u0026rsquo;에 불과합니다. 단단한 \u0026lsquo;마이크로\u0026rsquo;라는 반석 위에 \u0026lsquo;매크로\u0026rsquo; 관점이 더해질 때 비로소 강력한 시너지가 납니다. 마이크로에 너무 신경쓰다가 매크로를 놓지지 말자가 포인트일뿐 합니다.\n또한 이 글은 누가 더 뛰어난 엔지니어인지를 논쟁하고자 하는 글이 아닙니다. 단지, 대부분의 엔지니어링 조직과 교육이 \u0026lsquo;마이크로\u0026rsquo;에 집중되어 있어 상대적으로 \u0026lsquo;매크로\u0026rsquo;의 중요성이 간과되기 쉬우며, 기업의 입장에서 필요한 리더는 마이크로를 기반으로 매크로를 상상할 수 있는 엔지니어를 필요로 하니, 수요와 공급의 관점에서 \u0026lsquo;매크로\u0026rsquo; 관점을 가진 엔지니어의 희소성이 (연봉 협상에서) 더 높게 평가받을 수 있다는 현실적인 이야기를 하고 싶었습니다.\n사족 2: 이 글은 모든 시니어 엔지니어를 위한 글이 아닙니다. 시니어 엔지니어의 역할은 조직마다, 개인의 성향마다 다릅니다. 누군가는 \u0026lsquo;마이크로\u0026rsquo;의 끝을 파고들어 특정 분야의 \u0026lsquo;장인(Specialist)\u0026lsquo;이 되어 독보적인 가치를 만들 수 있습니다. (e.g., 커널 튜닝, 컴파일러, 3D 렌더링 엔진 등)\n이 글은 특정 도메인의 스페셜리스트가 아닌, 저와 같이 \u0026lsquo;비즈니스 문제를 기술로 해결하는\u0026rsquo; Product Engineer 의 성장에 초점을 맞춘 글임을 밝힙니다.\n사족 3: \u0026lsquo;Engineering Surface\u0026rsquo;에 대하여 본문에서 \u0026lsquo;도장\u0026rsquo;의 표면을 비유로 들었습니다. 이는 엔지니어링에서 흔히 말하는 \u0026lsquo;Engineering Surface\u0026rsquo; 혹은 \u0026lsquo;Surface Area\u0026rsquo; 개념과 맞닿아 있습니다.\n\u0026lsquo;Engineering Surface\u0026rsquo;란 시스템이 외부 세계와 소통하는 모든 \u0026lsquo;접점\u0026rsquo;을 의미합니다.\nAPI 명세: POST /users 같은 엔드포인트와 JSON 구조. 함수 시그니처: calculatePrice(user, item)의 입력과 출력. 클래스 인터페이스: 외부에서 호출 가능한 Public Method. \u0026lsquo;마이크로\u0026rsquo; 관점의 장인은 이 \u0026lsquo;Surface\u0026rsquo;를 얼마나 정교하고 깔끔하게 깎아내는가에 집중합니다.\n하지만 \u0026lsquo;매크로\u0026rsquo; 관점은 이 \u0026lsquo;Surface\u0026rsquo;를 다르게 봅니다. MSA(Microservice Architecture) 관점에서, 하나의 서비스가 책임지는 \u0026lsquo;Surface\u0026rsquo;가 너무 거대하고 복잡해진다면(e.g., API가 100개가 넘어가고 관리가 안 된다면), 이는 \u0026lsquo;Surface\u0026rsquo;가 너무 비대하다는 신호이며 곧 서비스 분리의 근거가 됩니다. 즉, \u0026lsquo;매크로\u0026rsquo; 관점은 \u0026lsquo;Surface\u0026rsquo; 자체의 아름다움뿐만 아니라, 이 \u0026lsquo;Surface\u0026rsquo;의 적절한 \u0026lsquo;크기\u0026rsquo;와 \u0026lsquo;경계\u0026rsquo; 를 설계하는 것입니다.\n","permalink":"http://taokim.dev/posts/2026-02-24-stamp-carver-vs-factory-builder-ko/","summary":"\u003cblockquote\u003e\n\u003cp\u003e🇺🇸 \u003ca href=\"/posts/2026-02-24-stamp-carver-vs-factory-builder/\"\u003eRead in English\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e이 글은 \u003ca href=\"https://techblog.musinsa.com/%EB%8F%84%EC%9E%A5-%ED%8C%8C%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90-vs-%EA%B3%B5%EC%9E%A5-%EC%A7%93%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90-b33dddf5daef\"\u003e무신사 테크 블로그\u003c/a\u003e에 게시된 원문입니다.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e2026년 노트:\u003c/strong\u003e 이 글을 쓸 당시에도 AI로 인한 변화는 이미 진행 중이었지만, 그 이후로 변화는 더욱 가속되고 있습니다. \u0026lsquo;How(어떻게)\u0026lsquo;에서 \u0026lsquo;Why(왜)\u0026lsquo;로의 전환은 이미 시작됐지만, AI는 그 너머 — \u003cstrong\u003e\u0026lsquo;What(무엇을 만들 것인가)\u0026rsquo;\u003c/strong\u003e 까지 밀어붙이고 있습니다. AI 코딩의 등장으로 구현 비용이 급격히 낮아지면서, \u0026lsquo;마이크로(How)\u0026lsquo;는 예상보다 훨씬 빠르게 범용화되고 있습니다. \u0026lsquo;Why\u0026rsquo;를, 그리고 특히 \u0026lsquo;What should we build?\u0026lsquo;를 묻는 \u0026lsquo;매크로\u0026rsquo; 관점은 이제 단순히 가치 있는 것을 넘어 필수가 되었습니다. 돌아보면 이 글의 시각이 오히려 지금 더 유효하고, 어쩌면 당시엔 충분히 강하게 이야기하지 못했을 수도 있습니다. 지금 벌어지고 있는 변화를 읽는 하나의 렌즈로서 다시 공유합니다.\u003c/p\u003e","title":"도장 파는 개발자 vs 공장 짓는 개발자"},{"content":"I\u0026rsquo;ve been wanting to write things down for a while.\nOver the years, I\u0026rsquo;ve accumulated thoughts and experiences — things I figured out through work, side projects, and everyday problem-solving. Useful stuff, but easy to forget if I don\u0026rsquo;t write it down somewhere proper.\nSo I made this blog. It serves two purposes:\nSharing engineering decisions and strategic thinking. As an engineer working at scale, I regularly face decisions that affect systems, teams, and business outcomes — technology choices, architectural trade-offs, migration strategies, organizational patterns. Writing about them helps me think more clearly, and I hope it helps others navigating similar problems.\nSharing practical, everyday knowledge. Not everything has to be a deep architectural essay. Sometimes the most useful thing is a 5-minute guide that saves someone an hour of frustration.\nWriting with AI — doable, but not \u0026ldquo;just ask it to write.\u0026rdquo; I use Claude Code to help with this blog, but it\u0026rsquo;s not as simple as prompting an LLM and hitting publish. Getting decent output requires a real pipeline. Mine looks roughly like this:\nDump — throw a raw idea into a private ideas/ folder, auto-tagged and dedup-checked Refine — develop the angles, connect it to existing ideas, decide if it\u0026rsquo;s worth writing Polish — turn it into a bilingual draft (draft: true), with a style guide (CLAUDE.md) enforcing tone, structure, and natural Korean (not translation-sounding) Publish — final review, flip the flag, push Each step is a custom slash command backed by the repo\u0026rsquo;s own conventions. The AI follows the rules because they\u0026rsquo;re codified in the project — not because I ask nicely each time. The whole thing lives in this repo if you\u0026rsquo;re curious. (The ideas/ folder is .gitignore\u0026rsquo;d — some of those raw dumps are too embarrassing to share.)\nI\u0026rsquo;ll write in both English and Korean. Let\u0026rsquo;s see where this goes.\n예전부터 뭔가 글로 정리해두고 싶었다.\n몇 년간 일하고, 사이드 프로젝트 하고, 이것저것 부딪히면서 쌓인 경험이 있는데, 제대로 적어두지 않으면 결국 잊어버리게 된다.\n그래서 블로그를 만들었다. 목적은 두 가지다.\n엔지니어링 의사결정과 전략적 사고를 공유하는 것. 규모 있는 시스템을 다루다 보면 기술 선택, 아키텍처 트레이드오프, 마이그레이션 전략 같은 결정을 자주 하게 된다. 글로 정리하면 생각이 명확해지고, 비슷한 고민을 하는 사람들에게도 도움이 되지 않을까 한다.\n실용적이고 일상적인 지식을 공유하는 것. 모든 글이 깊은 아키텍처 에세이일 필요는 없다. 때로는 5분짜리 가이드가 누군가의 1시간을 아껴주기도 한다.\nAI로 글쓰기 — 가능하지만, \u0026ldquo;그냥 써달라고 하면 되는\u0026rdquo; 건 아니다. 이 블로그는 Claude Code를 활용해서 쓰고 있다. 다만 LLM에 프롬프트 한 번 던져서 바로 발행하는 방식은 아니다. 쓸 만한 글이 나오려면 나름의 파이프라인이 필요하다.\nDump — 떠오른 아이디어를 ideas/ 폴더에 자동 태깅과 중복 체크를 거쳐 저장 Refine — 어떤 각도로 쓸지 다듬고, 기존 아이디어와 연결하고, 쓸 가치가 있는지 판단 Polish — 영/한 초안으로 작성 (draft: true). 스타일 가이드(CLAUDE.md)가 톤, 구조, 번역투 방지까지 관리 Publish — 최종 검토 후 발행 각 단계는 이 레포의 컨벤션에 맞춰 만든 커스텀 슬래시 커맨드로 동작한다. AI가 규칙을 따르는 건 매번 부탁해서가 아니라, 프로젝트에 규칙이 코드화되어 있기 때문이다. 궁금하면 레포를 직접 보면 된다. (ideas/ 폴더는 .gitignore 처리해뒀다 — 날것의 덤프는 좀 부끄러워서.)\n영어와 한국어 섞어서 쓸 예정이다. 어디까지 갈지 한번 보자.\n","permalink":"http://taokim.dev/posts/2026-02-10-starting-this-blog/","summary":"\u003cp\u003eI\u0026rsquo;ve been wanting to write things down for a while.\u003c/p\u003e\n\u003cp\u003eOver the years, I\u0026rsquo;ve accumulated thoughts and experiences — things I figured out through work, side projects, and everyday problem-solving. Useful stuff, but easy to forget if I don\u0026rsquo;t write it down somewhere proper.\u003c/p\u003e\n\u003cp\u003eSo I made this blog. It serves two purposes:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSharing engineering decisions and strategic thinking.\u003c/strong\u003e As an engineer working at scale, I regularly face decisions that affect systems, teams, and business outcomes — technology choices, architectural trade-offs, migration strategies, organizational patterns. Writing about them helps me think more clearly, and I hope it helps others navigating similar problems.\u003c/p\u003e","title":"Starting This Blog / 블로그를 시작하며"},{"content":"소프트웨어 엔지니어 Tao Kim입니다.\n개발하면서 알게 된 것들, 엔지니어링 결정, 문제 해결 과정, 유용한 팁 등을 기록합니다. 기술적인 이야기부터 사소한 생산성 팁까지 — 누군가에게 도움이 되길 바라며.\n","permalink":"http://taokim.dev/about/","summary":"\u003cp\u003e소프트웨어 엔지니어 \u003ca href=\"https://www.linkedin.com/in/tao-kim-4286543a/\"\u003eTao Kim\u003c/a\u003e입니다.\u003c/p\u003e\n\u003cp\u003e개발하면서 알게 된 것들, 엔지니어링 결정, 문제 해결 과정, 유용한 팁 등을 기록합니다.\n기술적인 이야기부터 사소한 생산성 팁까지 — 누군가에게 도움이 되길 바라며.\u003c/p\u003e","title":"About"}]