<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>hoch.io</title>
  <subtitle>Hongchan Choi - Audio Software Engineer &amp; Researcher</subtitle>
  <link href="https://hoch.io/feed.xml" rel="self"/>
  <link href="https://hoch.io/"/>
  <updated>2026-08-01T00:00:00.000Z</updated>
  <id>https://hoch.io/</id>
  <author>
    <name>Hongchan Choi</name>
  </author>
  
  
  <entry xml:lang="ko">
    <title>조용한 리더십</title>
    <link href="https://hoch.io/ko/writing/2026-08-01-introverted-silicon-valley-manager/"/>
    <updated>2026-08-01T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-08-01-introverted-silicon-valley-manager/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-08-01-introverted-silicon-valley-manager/hero.png&quot; alt=&quot;내향적인 사람이 리더가 될 수 있을까?&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;내향적인 사람이 리더가 될 수 있을까?&lt;/p&gt;
&lt;h2&gt;&amp;quot;망설임은 곧 패배다&amp;quot;&lt;/h2&gt;
&lt;p&gt;가끔씩 잊을 만하면 그날의 기억이 떠올라 마음이 불편해지곤 한다. 10여 년 전, 입사 후 처음으로 합류했던 다국적 웹 표준 워킹그룹 회의였다. 대화의 주제는 내가 오랫동안 깊이 연구하고 다뤄온 영역이었기에 나는 문제의 해답을 알고 있었다.&lt;/p&gt;
&lt;p&gt;하지만 높은 언어의 장벽과 낯선 공기 앞에서 내 입은 굳어버렸다. 그 틈을 타 회의는 도메인 지식의 깊이는 가장 얕지만 목소리가 가장 컸던 사람의 손에 휘둘려 엉뚱한 방향으로 흘러가기 시작했다. 정답을 손에 쥐고도 몇 마디 얹지 못한 채 침묵해야 했던 그날, 회의실 문을 나서며 나는 자괴감을 삼켜야 했다.&lt;/p&gt;
&lt;p&gt;돌이켜보면 이는 비단 언어가 다른 다국적 회의만의 문제가 아니었다. 동일한 언어를 쓰는 조직의 회의실 안에서도 이러한 불평등은 쉽게 생겨난다.&lt;/p&gt;
&lt;p&gt;어떤 이들은 타고난 화려한 말솜씨와 자신감으로 논의의 흐름을 빠르게 장악한다. 그들의 순발력과 언변은 때로 지식의 깊이와 무관하게 그 자체로 &#39;유능함&#39;처럼 비치는 착시를 만든다. 또 다른 이들은 언변은 좀 투박할지언정 끊임없이 마이크를 잡으며 자기 지분을 챙긴다. 반면, 머릿속에서 신중한 검토와 사유를 거쳐 정제된 해답을 품고 있는 내향형 인간들은 빠른 즉흥 논쟁의 템포에 가로막혀 발언의 타이밍을 번번이 놓치고 만다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;망설임은 곧 패배다 (Hesitation is Defeat)&amp;quot;&lt;/p&gt;
&lt;p&gt;— 아시나 잇신, 《세키로: 섀도우 다이 트와이스》&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;당시 나를 짓눌렀던 것은 지극히 현실적인 공포였다. &lt;strong&gt;&amp;quot;화려한 언변의 네이티브 스피커와 정면으로 맞붙었을 때, 과연 내가 그 즉흥적인 말싸움에서 살아남을 수 있을 것인가?&amp;quot;&lt;/strong&gt; 홈그라운드 언어와 외향적 성향을 무기로 휘두르는 그들 앞에서, 비네이티브이자 내향형인 내가 맞붙는 것은 계란으로 바위를 치는 격처럼 느껴졌다.&lt;/p&gt;
&lt;p&gt;아무도 대놓고 말하지 않지만, 회의실에는 늘 막힘없는 유창함을 실력으로 착각하는 &lt;strong&gt;&lt;a href=&quot;https://en.wikipedia.org/wiki/Fluency_heuristic&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;유창성 편견(Fluency Heuristic)&lt;/a&gt;&lt;/strong&gt;이라는 야박한 법칙이 작동한다. 사람들은 서툰 표현과 머뭇거리는 침묵을 순식간에 &#39;무지&#39;나 &#39;자신감 부족&#39;으로 단정 지었고, 무시해도 좋을 신호로 치부하곤 했다.&lt;/p&gt;
&lt;p&gt;어색한 영어로라도 일단 큰 목소리를 내며 제 몫을 챙기려는 외향적 비네이티브까지 난립할 때, 이 혼란은 극에 달한다. &lt;strong&gt;&amp;quot;나도 저들처럼 뻔뻔해져야 하는가? 여기에서 살아남으려면 내 본연의 성격과 정체성마저 송두리째 바꿔야 하는가?&amp;quot;&lt;/strong&gt; 목소리의 크기가 유능함으로 포장되는 광경을 바라보며, 나 자신의 성격을 향한 깊은 회의감은 점점 짙어져 갔다.&lt;/p&gt;
&lt;h2&gt;내향적 리더가 성과를 내는 이유&lt;/h2&gt;
&lt;p&gt;조직심리학자 아담 그랜트(Adam Grant) 교수의 &lt;a href=&quot;https://hbr.org/2010/12/the-hidden-advantages-of-quiet-bosses&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;연구&lt;/a&gt;에 따르면, &lt;strong&gt;기업 임원과 매니저의 무려 96%가 외향적 성향&lt;/strong&gt;을 띤다고 한다. 리더십 포지션의 절대 다수를 외향형이 독식하고 있는 것이 엄연한 현실이다.&lt;/p&gt;
&lt;p&gt;하지만 아이러니하게도 실리콘밸리 테크 현장에서 실제로 코드를 작성하고 시스템을 설계하는 엔지니어의 대다수는 내향형 인재들이다. 그렇다면 외향형 리더들이 지배하는 세계에서, 조용하고 신중한 내향형 엔지니어들은 그저 소외된 채 외향적 가면을 강요받아야만 하는 것일까?&lt;/p&gt;
&lt;p&gt;그러나 학술적 데이터와 연구 결과는 뜻밖의 반전을 보여준다.&lt;/p&gt;
&lt;p&gt;같은 연구에 발표된 실험에 따르면, 팀원들이 수동적일 때는 외향형 리더가 높은 성과를 냈지만, &lt;strong&gt;팀원들이 주도적이고 자율적으로 아이디어를 제안할 때는 오히려 내향형 리더가 이끄는 팀의 수익과 성과가 14% 이상 더 높았다.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;이유는 명확했다. 외향형 리더는 주도적인 팀원의 제안을 자신의 권위에 대한 위협이나 간섭으로 받아들이기 쉬운 반면, 내향형 리더는 팀원의 의견을 편견 없이 경청하고 지원하는 데 탁월했기 때문이다. 스스로 빛나려 하기보다 팀원의 주도성을 살려주는 내향적 리더십이, 자율성과 전문성이 핵심인 테크 조직에서 강력한 시너지를 발휘할 수 있음을 증명한 것이다.&lt;/p&gt;
&lt;h2&gt;전장을 바꾸는 지혜&lt;/h2&gt;
&lt;p&gt;청산유수 같은 달변가들과 맞상대하기 위해 뒤늦게 임기응변 능력을 훈련하는 것은 애당초 승산이 없는 게임이었다. 이미 수십 년간 외향적인 언변을 갈고닦아온 이들의 홈그라운드에서 겨루는 것은 불리할 수밖에 없다. 약점을 메우려 애쓰기보다 &lt;strong&gt;내가 가진 강점에 집중하는 것&lt;/strong&gt;이 훨씬 현명했다.&lt;/p&gt;
&lt;p&gt;내가 찾은 첫 번째 해답은 &lt;strong&gt;&amp;quot;전장을 바꾸는 것&amp;quot;&lt;/strong&gt;이었다. 소음과 즉흥이 난무하는 회의실 안이 아니라, 회의실 밖의 시간과 차분한 통찰의 영역으로 승부처를 옮겼다.&lt;/p&gt;
&lt;p&gt;첫째는 &lt;strong&gt;미팅 전, 꼼꼼한 아젠다로 &#39;구조&#39;를 선점하는 것&lt;/strong&gt;이었다. 아무런 준비 없이 모인 빈 회의실에서는 목소리 큰 사람의 임기응변이 판을 친다. 하지만 사전에 아젠다를 배포하고 논의의 뼈대를 세워두면, 회의는 즉흥적인 말싸움이 아니라 준비된 구조 안에서 정리된다. 이는 내향적인 나 자신뿐 아니라 회의 참여자 모두가 소음에 휘둘리지 않고 본질적인 논의에 집중하도록 돕는 강력한 가드레일이 되었다.&lt;/p&gt;
&lt;p&gt;둘째는 &lt;strong&gt;미팅 후, &#39;미팅 노트&#39;를 통해 맥락과 방향을 정리하는 것&lt;/strong&gt;이었다. 나는 미팅이 끝난 뒤 논의된 내용을 정돈하여 공유하는 역할을 자처했다. 이 작업에는 보기보다 커다란 힘이 숨어 있었다. 회의실 안에서 오간 수많은 말 중 무엇이 본질이고 어떤 결정이 내려졌는지, 그 뉘앙스와 우선순위를 최종 정돈하는 &#39;편집장&#39;의 파워를 쥐게 되었기 때문이다. 차분히 정리하고 공유하는 사후 작업은 나 같은 내향형 인간에게 보이지 않는 곳에서 협업의 흐름을 이끌며 다음 단계를 더 치밀하게 준비할 수 있는 발판이 되었다.&lt;/p&gt;
&lt;p&gt;마지막으로, 나 스스로부터 &lt;strong&gt;&#39;유창함&#39;과 &#39;지식의 깊이&#39;를 동일시하는 편견&lt;/strong&gt;에서 벗어나고자 했다. 화려한 언변에 휘둘리지 않고, 중요한 결정일수록 팩트와 데이터를 차분히 검토하며 회의실의 소음 속에서도 나만의 페이스를 지키려 노력했다. (나중에 알게 되었지만, 이건 일상생활에서도 꽤 쓸 만한 스킬이다.)&lt;/p&gt;
&lt;h2&gt;의도적인 에너지 안배와 &#39;깊은 경청&#39;의 힘&lt;/h2&gt;
&lt;p&gt;내향형 인간이라고 해서 큰 발표를 못 하거나 사람들 앞에 서지 못하는 것은 아니다. 다만 이를 위해 &lt;strong&gt;의도적인 노력과 철저한 에너지 안배&lt;/strong&gt;가 필요할 뿐이다.&lt;/p&gt;
&lt;p&gt;외향적인 행동은 내향형 인간에게 막대한 배터리 소모를 요구한다. 나는 중요한 발표나 대형 미팅이 있는 날이면, 그 전후로 반드시 혼자만의 시간이나 캘린더 블록을 확보해 소진된 에너지를 충전하는 루틴을 만들었다. 잠시 조용히 사색하거나 가벼운 파워 냅(Power nap)을 통해 에너지를 채워 넣는 이 번거로운 과정이 반복되면서, 내 마음에도 조금씩 굳은살이 생겨났다. 타고난 기질을 바꾸지는 못해도, 외향적 액션을 취할 때 소모되는 에너지의 비용을 점점 줄여나갈 수 있었다.&lt;/p&gt;
&lt;p&gt;또한 이 과정에서 결정적인 전환점이 되어준 것은 &lt;strong&gt;나의 등을 떠밀어준 멘토와의 만남&lt;/strong&gt;이었다. 내가 두려움에 주저하고 있을 때, 멘토는 나를 안전지대 밖의 불편한 무대로 밀어붙였다. 큰 무대 위에서의 발표를 맡기며 판을 깔아주었고, 무대 뒤에서는 든든한 스폰서가 되어주었다. 컴포트 존(Comfort Zone)을 깨뜨리려는 나의 의도적 노력에 멘토의 강력한 지지가 더해지자, 스스로 한계라고 여겼던 경계가 비로소 허물어졌다.&lt;/p&gt;
&lt;p&gt;그리고 내가 매니저가 되었을 때, 그동안 겪었던 모든 결핍과 고통은 놀랍게도 소중한 리더십의 자산으로 바뀌었다.&lt;/p&gt;
&lt;p&gt;나는 회의실 한구석에서 정답을 알고도 말문을 떼지 못해 자괴감을 삼키던 내향적인 엔지니어들의 침묵을 누구보다 뼈저리게 이해하고 있었다. 그 불안을 직접 겪어보았기에, 팀원들이 미팅에서 말을 아끼거나 머뭇거릴 때 그 침묵의 뉘앙스를 가장 빠르게 포착할 수 있었다.&lt;/p&gt;
&lt;p&gt;나는 팀원들을 시끄러운 회의실로 몰아넣는 대신, 1:1 미팅이나 개인 채팅 같은 안전한 소통의 공간을 열어두고 그들의 목소리를 깊이 경청했다. 그들이 주저하며 삼켰던 숨은 통찰과 아이디어들이 세상 밖으로 나올 수 있도록 조용히 다리를 놓아주었다. 진정한 리더십은 무대 위에서 카리스마를 뽐내는 것이 아니라, &lt;strong&gt;함께하는 이들의 불안을 보듬고 그들의 잠재력을 온전히 끄집어내는 공감과 경청&lt;/strong&gt;에 있다고 생각한다.&lt;/p&gt;
&lt;h2&gt;내향형 인간과 서번트 리더십&lt;/h2&gt;
&lt;p&gt;돌이켜보면, 살아남기 위해 굳이 내가 아닌 다른 누군가를 흉내 낼 필요는 없었다.&lt;/p&gt;
&lt;p&gt;미팅룸 밖으로 전장을 옮겨 준비와 팔로우업에 노력을 기울이고, 의도적인 에너지 안배로 나만의 페이스를 지키며, 깊은 경청으로 팀원들의 숨은 포텐셜을 이끌어내는 것. 이 작은 답들이 모여, 나는 비로소 내향형 인간으로서 나다운 단단한 중심을 지켜낼 수 있었다.&lt;/p&gt;
&lt;p&gt;리더가 반드시 무대 위의 &#39;락스타&#39;가 되어 조명을 독식할 필요는 없다. 스스로 무대 중앙에 서기보다, 팀원들이 주인공으로 빛날 수 있도록 무대 뒤에서 조명을 밝혀주는 사람. 이러한 &lt;strong&gt;서번트 리더십(Servant Leadership)&lt;/strong&gt;이야말로 내향적 리더가 가장 진정성 있게 실천할 수 있는 형태의 리더십이다.&lt;/p&gt;
&lt;p&gt;10여 년 전 다국적 웹 표준 회의실 한구석에서 자괴감을 삼키며 침묵해야 했던 나는, 사실 지금도 여전히 크고 시끄러운 회의실이나 프레젠테이션 무대가 그다지 편안하지만은 않다.&lt;/p&gt;
&lt;p&gt;다만 이제는 안다. 순간의 화려한 언변이나 순발력보다 오래 남는 것은 매일 쌓아 올리는 신뢰와 팀원들을 위한 조용한 존재감이라는 사실을. 늘 시끌벅적한 이곳에서 지켜낸 &amp;quot;나다운&amp;quot; 고요함과 진정성이, 나 자신과 내 주변 사람들을 보다 단단하게 지탱하는 힘이 되었음을 믿는다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>AI 네이티브 팀으로 체질 개선하기</title>
    <link href="https://hoch.io/ko/writing/2026-07-27-building-an-ai-native-team/"/>
    <updated>2026-07-27T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-07-27-building-an-ai-native-team/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-07-27-building-an-ai-native-team/hero.png&quot; alt=&quot;오피스에 감도는 묘한 온도차&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;오피스에 감도는 묘한 온도차&lt;/p&gt;
&lt;p&gt;&amp;quot;AI 도구들이 나왔네요. 다 같이 한 번 잘 활용해 봐요!&amp;quot;&lt;/p&gt;
&lt;p&gt;2025년 여름, 열 명 남짓의 엔지니어링 팀에 AI를 처음 도입하려던 내 계획은 지나치리만큼 순진했다. 현장에서는 곧바로 미묘한 마찰음이 들려왔다. 한쪽에는 쏟아지는 AI 도구들 앞에서 &#39;내 커리어가 도태될지 모른다&#39;며 침묵하는 팀원들이 있었고, 다른 한쪽에는 &#39;당장 모든 개발을 AI로 대체할 수 있다&#39;며 들떠있는 이들이 있었다. 이 극과 극의 불안과 흥분을 탈 없이 아우르는 일, 그것이 지난 1년간 풀어내야 했던 숙제였다.&lt;/p&gt;
&lt;p&gt;이 과정에서 깨달은 것은, AI 도입의 본질은 기술이나 생산성 숫자가 아니라는 점이다. 정작 중요한 것은 새로운 기술 앞에서 감도는 긴장감을 호기심으로 바꾸고, 도구를 장난감처럼 쥐고 흔드는 &#39;놀이&#39; 같은 유연함을 팀에 이식하는 일이었다.&lt;/p&gt;
&lt;p&gt;소셜 미디어에 넘쳐나는 &amp;quot;이것만 알면 끝납니다&amp;quot; 식의 단순한 팁과 테크닉에 피로감을 느끼는 것은 비단 나뿐만이 아닐 것이다. 매뉴얼, 팁과 트릭만으로는 사람이 움직이지 않기 때문이다. 이 글에서 진짜 나누고 싶은 것은 망설이는 이들의 마음을 어떻게 움직이고, 어떤 실질적인 툴링과 가이드라인으로 팀에 AI를 안착시킬 수 있었는지에 대한 고민과 통찰이다.&lt;/p&gt;
&lt;h2&gt;운전석과 조수석&lt;/h2&gt;
&lt;p&gt;AI를 팀의 워크플로우에 도입할 때 가장 먼저 목격하게 되는 현상은 바로 &lt;a href=&quot;https://www.weforum.org/stories/leadership/why-ai-performance-depends-on-how-we-think-talk-and-lead/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&#39;운전석과 조수석&#39;의 양극화&lt;/a&gt;다. AI Hype을 온몸으로 받아들이며 앞으로 치고 나가는 소수와, 그들을 관망하며 조용히 따라가는 다수로 팀이 쪼개지는 현상이다.&lt;/p&gt;
&lt;p&gt;AI 툴링에 대한 담론이 대세로 떠오르던 2025년 중반, 큐비클 사이로 오가는 수군거림과 채팅방에 번지는 팀원들의 소외감, 그리고 실체 없는 불안을 걷어내는 것이 시급하다고 생각했다. 나는 이 두려움을 공식적인 토론 테이블 위로 끌어올리기 위해 팀 내에서 AI 세미나를 시작했다.&lt;/p&gt;
&lt;p&gt;세미나의 목적은 거창한 지식 전달이 아니라, AI 삽질과 웃긴 실패담을 편하게 나누며 심리적 문턱을 낮추는 것이었다. 주간 보고서를 쓰려다 AI의 황당한 환각에 속았던 나 자신의 실수부터 솔직하게 고백하자, 팀원들의 경계심이 슬슬 풀리기 시작했다. 불안한 공기가 사라지자 논의는 자연스럽게 실질적인 생산성으로 이동했고, 세미나는 팀의 AI 도입을 이끄는 든든한 런치패드가 되었다.&lt;/p&gt;
&lt;p&gt;그러나 숙련도 격차가 벌어지면서 세미나는 이내 차갑게 식어갔다. &#39;운전대를 잡은 이들&#39;은 세미나를 지루해했고, &#39;조수석에서 관망하는 이들&#39;은 그들의 속도에 위화감을 느끼며 입을 닫았다. 모두를 위해 만든 &#39;심리적 안전 지대&#39;가 도리어 비교와 박탈감의 무대로 변해버린 것이다.&lt;/p&gt;
&lt;p&gt;나는 팀원들을 조용히 &lt;strong&gt;투 트랙&lt;/strong&gt;으로 분리했다. 기존 세미나는 실패와 시도를 자유롭게 나누는 안전지대로 남겨두고, 앞서가는 이들은 별도의 &lt;strong&gt;AI TF&lt;/strong&gt;로 조직했다. 그리고 TF의 미션을 개인의 생산성을 뽐내는 것이 아니라 &lt;strong&gt;팀 전체의 병목과 번거로운 루틴을 해결할 도구를 개발하는 것&lt;/strong&gt;으로 재정의했다.&lt;/p&gt;
&lt;p&gt;TF가 성과를 낼 때마다 세미나에서 15분 라이트닝 토크로 공유했다. 그들이 만든 툴링이 실제로 다른 팀원들의 번거로움을 줄여주자 어색한 긴장감이 녹아내리기 시작했다. TF는 팀의 생산성에 기여하고 있다는 자부심을, 나머지 팀원들은 발 빠른 정보 공유를 통해 우리 팀이 앞서나가고 있다는 안도감을 얻었다. 모두가 만족할 수 있는 긍정적인 패턴이 만들어진 것이다.&lt;/p&gt;
&lt;h2&gt;버스에 올라타지 않은 자들&lt;/h2&gt;
&lt;p&gt;여기서 한 가지 빼먹은 것이 있다. 운전석과 조수석의 비유를 이어가자면 - 아예 차에 탑승하길 거부하는 이들도 있다는 사실이다.&lt;/p&gt;
&lt;p&gt;모두가 AI를 말할 때 조용히 방관하며 기존의 일 방식을 고수하는 이들, 소위 &amp;quot;토큰 사용량 하위 10%&amp;quot;다. 대시보드는 보통 누가 더 많은 토큰을 사용했는지에 초점을 맞추지만, 정작 나중에 폭탄처럼 터질 문제는 대시보드 아래 사각지대에 숨어 있다.&lt;/p&gt;
&lt;p&gt;평균은 전체적인 상황을 모니터링하기에는 훌륭하지만, 문제를 진단하는 데는 최악이다. 팀 전체의 활용도를 토큰 사용량의 평균치로 계산한다면 이 하위 10%는 표면에 절대 드러나지 않는다. 토큰을 얼마나 많이 썼는가는 AI 도입 초기의 단순한 메트릭일 뿐, 실제 조직의 ROI나 생산성을 증명해주지 못한다. 진짜 문제는 의식적이든 무의식적이든 AI를 아예 사용하지 않으려는 이들이다.&lt;/p&gt;
&lt;p&gt;그들의 실력이나 아웃풋이 부족하다는 뜻이 아니다. 핵심은 그들이 &amp;quot;팀과 전혀 다른 방식으로 일하기 때문에&amp;quot; 결국 마찰을 야기하고 프로세스의 병목이 된다는 점이다. 모든 팀원이 Hype에 휩싸일 필요는 없다. 아무도 바이브 코딩으로 뽑아낸 천 줄짜리 패치를 하루에 수십 개씩 보고 싶어 하지 않는다. 다만 적어도 팀의 새로운 프랙티스와 프로세스에서 너무 멀어지지 않도록 리더가 균형을 잡아주어야 한다.&lt;/p&gt;
&lt;p&gt;그렇다면 리더는 어떻게 그들을 거부감 없이 버스에 태워야 하는가? 몇 번의 시행착오 끝에 얻은 답은 의외로 단순했다. 그들이 일하는 루틴을 가만히 관찰하고, 일상에서 가장 귀찮아하는 페인 포인트(Pain Point)를 끄집어내는 것이다.&lt;/p&gt;
&lt;p&gt;일례로 우리 팀 엔지니어들에게 가장 번거로운 시간 낭비는 보고된 버그를 정리·분석하여 트리아지 미팅에서 발표하는 일이었다. 미팅 전의 단순 복사-붙여넣기 수작업부터, 미팅 후 논의된 내용을 버그 트래커에 일일이 업데이트하는 과정까지 오버헤드가 꽤 컸다.&lt;/p&gt;
&lt;p&gt;나는 이 업무를 TF와 함께 AI 툴링으로 자동화했다. 사전에 미팅 노트를 자동으로 생성하여 미팅 시간에는 100% 기술적 논의에만 집중하게 만들었고, 회의가 끝난 뒤에는 음성인식 회의록과 수기 작성된 노트를 합성해 버그 트래커까지 자동으로 업데이트하도록 만들었다. 이 툴링을 직접 경험해 본 팀원들은 좋은 반응을 보였고, 심지어 가장 보수적이었던 시니어 엔지니어들조차 &amp;quot;이건 꽤 괜찮은데?&amp;quot;라며 마음을 열기 시작했다. 반복된 잔소리보다 직관적인 효용가치를 보여주는 것. 그것이 가장 확실한 유인책이었다.&lt;/p&gt;
&lt;h2&gt;Move Faster Without Breaking Things&lt;/h2&gt;
&lt;p&gt;AI 엔지니어링 시대가 본격적으로 도래하며 툴링의 판도가 급변했다. MCP, 스킬(Skill)과 하네스(Harness)가 화두로 떠오르고, 각 팀이 자신들만의 맞춤형 도구를 자발적으로 만들기 시작했다. 과거 같았으면 &amp;quot;중구난방의 파편화&amp;quot;라고 손가락질 받을 상황이었겠지만, 이번에는 달랐다. 빠른 툴링 제작이 곧바로 실질적인 생산성 향상으로 연결되었기 때문이다.&lt;/p&gt;
&lt;p&gt;엔지니어링 스탠다드가 높은 조직일수록 전통적으로 &#39;표준화&#39;와 &#39;스케일&#39;을 신봉한다. &amp;quot;어딘가에서 훌륭한 AI 팀이 완벽한 툴링과 표준 프레임워크를 만들 때까지 기다리자&amp;quot;라는 수동적 태도가 당연하게 받아들여졌다. 실제로 전통적인 소프트웨어 엔지니어링 관점에서는 지극히 타당한 접근이었다. 섣불리 개별 툴을 난립시키면 시스템 복잡도가 늘어나고 결국 기술 부채가 불어나기 때문이다.&lt;/p&gt;
&lt;p&gt;하지만 이러한 통념이 지금에도 과연 유효할까? 나는 그 통념에 도전하는 쪽에 한 표를 던진다. 예전에는 파편화된 복잡도를 재설계하고 리팩터링하는 것 자체가 또 다른 거대한 프로젝트가 되곤 했지만, 이제는 복잡도와 파편화조차 AI 코딩 기술이 빠르게 해결해주는 시대다. 중앙 통제, 표준화, 스케일에 대한 고려는 오랫동안 소프트웨어 엔지니어링의 근본이었지만, AI 엔지니어링 시대에서는 역설적으로 실행 속도의 발목을 잡는 가장 큰 장애물이 되고 있다.&lt;/p&gt;
&lt;p&gt;한때 실리콘밸리의 구호였던 &amp;quot;빠르게 움직이고 시스템을 부숴라(Move fast and break things)&amp;quot;가 몇 년 전의 쿨한 스타일이었다면, AI 코딩 시대의 새로운 패러다임은 &lt;strong&gt;&amp;quot;부수지 않으면서 더 빠르게 달려라(Move faster without breaking things)&amp;quot;&lt;/strong&gt;에 가깝다.&lt;/p&gt;
&lt;p&gt;AI가 복잡도와 테스팅을 빠르게 정리해주기 때문에, 이제는 시스템을 부술 위험을 최소화하면서도 실행 속도를 최대로 끌어올릴 수 있다. 특정 프로젝트의 마찰을 해결하기 위해 엔지니어가 직접 만드는 일회성 맞춤 도구인 &lt;strong&gt;&#39;지그(Jig)&#39;&lt;/strong&gt;는 바로 이러한 변화를 증명하는 눈여겨볼 만한 트렌드이다.&lt;/p&gt;
&lt;p&gt;하지만, 진짜 관건은 엔지니어들의 마인드셋 전환이다. &amp;quot;딱 하나만 정해서 그것만 잘 쓰자&amp;quot;라는 수동적 자세를 버려야 한다. 대신 &lt;strong&gt;&amp;quot;빠르게 취사선택하고 내일 또 반복한다&amp;quot;&lt;/strong&gt;는 진화형 마인드셋을 가져야 한다. 끊임없이 변하는 툴을 마스터하려 애쓰기보다, 변화에 유연하게 적응하는 &#39;AI 리터러시&#39; 자체를 기르는 것이 훨씬 효과적이다.&lt;/p&gt;
&lt;p&gt;그렇다면 데드라인에 시달리는 엔지니어들에게 어떻게 툴링을 만들고 학습할 여백을 줄 것인가? 나는 팀원들에게 &lt;strong&gt;시간의 10%를 AI 툴링 학습과 개발에 쓰라&lt;/strong&gt;고 권장하고, 세미나를 통해 배운 점을 공유하게 했다. 특히, 개발된 툴링이 팀의 수고를 크게 줄여준 경우에는 스팟 보너스를 지급했다. 예산이나 보상 체계가 넉넉하지 않은 환경이라도 팀 미팅 때 &#39;이주의 베스트&#39;를 선정해 5분간 라이브 데모를 진행하고 다 같이 칭찬하는 소소한 이벤트도 생각해 볼 만하다.&lt;/p&gt;
&lt;p&gt;그리고 이러한 활동을 단순한 자원봉사가 아닌 &#39;팀 AI 컬처 기여&#39;라는 목표로 정의해 연말 평가와 연결했다. 여기서 평가는 토큰 사용량이나 패치 개수로 줄을 세우는 것이 아니다. &#39;팀의 병목을 줄이려 노력했는가&#39;, &#39;새로운 방식을 배우려는 시도를 했는가&#39;와 같은 &lt;strong&gt;정성적 기여와 성장&lt;/strong&gt;을 조직이 공식 인정해 줌으로써, 10%의 시간이 눈치 보이는 딴짓이 아니라 엔지니어로서 마땅히 보장받아야 할 성과의 일부임을 명시한 것이다.&lt;/p&gt;
&lt;h2&gt;당신이 잠든 사이에&lt;/h2&gt;
&lt;p&gt;AI 도입이 고도화될수록 엔지니어에게 요구되는 가장 중요한 마인드셋 중 하나는 &amp;quot;AI가 언제 나를 보조(Assistive)하고, 언제 자율적(Autonomous)으로 움직일 것인가&amp;quot;를 구별하는 감각이다. 당연한 이야기겠지만, 아무리 훌륭한 스킬이 있다 해도 그것을 무차별적으로 적용하는 것은 현명하지 않다.&lt;/p&gt;
&lt;p&gt;엔지니어가 모니터 앞에 앉아 있는 시간(ON)에는 AI를 &lt;strong&gt;어시스트 모드&lt;/strong&gt;로 활용한다. 아키텍처 구상, 리서치, 브레인스토밍처럼 사람의 직관과 실시간 인터랙션이 필요한 영역이다. 반대로 모니터를 끄고 집으로 향하는 시간(OFF)에는 &lt;strong&gt;자동화 모드&lt;/strong&gt; 스킬을 발동시킨다. 자리에 없는 동안 에이전트가 알아서 수행할 태스크를 분리하여 관리하는 것이다.&lt;/p&gt;
&lt;p&gt;하지만 이렇게 에이전트로 아웃풋을 극대화하려는 시도에는 잘 드러나지 않는 코스트가 따른다. 낮 동안 여러 개의 터미널과 채팅 윈도우 사이를 넘나들며 에이전트들과 실시간 멀티태스킹을 하다 보면 두뇌는 금세 과부하가 걸려 번아웃된다. 퇴근 후에도 쉴 새 없이 쏟아지는 알림에 밤새 반응하다 보면 지나친 멘탈 에너지 소비로 소위 &lt;a href=&quot;https://www.npr.org/2026/04/13/nx-s1-5780867/you-might-be-suffering-from-ai-brain-fry&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&lt;strong&gt;브레인 프라이(Brain Fry)&lt;/strong&gt;&lt;/a&gt; 현상을 겪기 일쑤다.&lt;/p&gt;
&lt;p&gt;나는 이 문제를 해결하기 위해 인간의 두뇌 에너지와 주의력을 RPG 게임의 한정된 &lt;strong&gt;&#39;마나(Mana)&#39;&lt;/strong&gt;처럼 다루기 시작했다. 마나가 바닥나면 캐릭터가 아무 스킬도 쓸 수 없듯, 정신력이 고갈되면 아무리 좋은 도구도 무용지물이 된다. 에이전트의 수행력은 무한할지 몰라도, 인간의 정신력은 지극히 유한한 자원이기 때문이다.&lt;/p&gt;
&lt;p&gt;그래서 팀을 위해 두 가지 핵심 원칙을 세웠다.&lt;/p&gt;
&lt;p&gt;첫째, &lt;strong&gt;퇴근 후에는 알림을 100% 차단하고 완전히 디스커넥트한다.&lt;/strong&gt; 퇴근길이나 주말에 에이전트의 알림이 울리는 순간, 자동화는 또 다른 디지털 감옥이 되기 때문이다. 야간 에이전트는 무소음으로 조용히 돌아가야 하며, 인간의 휴식 시간과 멘탈 에너지는 보호받아야 한다.&lt;/p&gt;
&lt;p&gt;둘째, &lt;strong&gt;야간에 가동되는 자동모드 에이전트는 하루에 딱 1개, 저난이도의 버그만 다룬다.&lt;/strong&gt; 특히 에이전트가 메인 코드베이스를 직접 건드리지 못하도록 테두리를 긋고, &lt;a href=&quot;https://executive.mit.edu/blog/beyond-the-algorithm-bridging-the-last-mile-of-ai-adoption.html&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&lt;strong&gt;라스트 마일(Last Mile)&lt;/strong&gt; 문제&lt;/a&gt;가 거의 없는 안전한 작업만 맡기는 것이다.&lt;/p&gt;
&lt;p&gt;이렇게 셋업해 두면 엔지니어는 아침에 출근해 차 한 잔을 마시며 자동모드 에이전트가 밤새 작성해 둔 초안의 CI 결과, 테스트 결과를 확인하고, 10분 정도 리뷰 후 승인 혹은 반려하고, 보조모드의 에이전트와 함께 하루 일과를 시작하면 된다.&lt;/p&gt;
&lt;p&gt;수십 개의 태스크를 동시에 수행할 수 있는 시대에 위와 같은 전술적 팁보다 훨씬 더 중요한 것은 &lt;strong&gt;&amp;quot;어떤 것을 골라내고 맡길 것인가&amp;quot;에 대한 엔지니어의 의도(Intent)와 우선순위 감각(Taste)&lt;/strong&gt;이다. 고차원적 의사결정에 정신력을 집중하고, 낮은 우선순위의 업무는 에이전트에게 위임하며, OFF일 때는 완전한 디스커넥트를 통해 정신력을 회복해야 한다. 자신을 AI로 무장한 &#39;수퍼 플레이어&#39;로 인식하고 정신력의 안배를 꼼꼼히 설계하는 것. 이것이 지속 가능한 AI 엔지니어링의 열쇠다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>구글에서의 10년, 그리고 미지의 10년</title>
    <link href="https://hoch.io/ko/writing/2026-05-13-10-years-at-google/"/>
    <updated>2026-05-13T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-05-13-10-years-at-google/</id>
    <content type="html">&lt;h3&gt;무용지물이 된 2년 전의 초안&lt;/h3&gt;
&lt;p&gt;2024년, 구글에 몸담은 지 10년을 맞아 기획했던 이 포스트 시리즈의 원래 목표는 단순했다. 소프트웨어 엔지니어의 점진적인 성장을 4개의 단계로 그려내는 것이었다. 뛰어난 코딩 실력과 오너십으로 증명하는 &#39;Making it Work&#39;, 팀과 프로세스를 조율하는 &#39;Making it Flow&#39;, 파트너 생태계 속에서 공생하는 &#39;Making it Together&#39;, 그리고 세상에 진정한 가치를 더하는 &#39;Making it Matter&#39;까지. 엔지니어 1인이 임팩트의 규모를 키워가며 성장하는 4개의 동심원이 이 초안의 뼈대였다. 이를 바탕으로 앞선 9개의 포스트를 연재하며 지난 10년의 조각들을 엮어낼 수 있었다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-05-13-10-years-at-google/4-circles.png&quot; alt=&quot;4개의 동심원&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;4개의 동심원&lt;/p&gt;
&lt;p&gt;하지만 대미를 장식할 10번째 포스트를 쓰기 위해 2년 만에 다시 꺼내 본 이 설계도는 이미 처참하게 부서져 있었다. AI라는 거대한 파도가 덮친 지금의 현실과는 도저히 연결 지을 수 없었기 때문이다.&lt;/p&gt;
&lt;p&gt;개인과 팀의 정의부터 뒤집히고 있으며, 생태계라는 거창한 단어는 생존의 위협 앞에 흩어지고 있다. 그 누구도 변화의 명확한 방향을 알지 못하는 혼란 속에서, 엔지니어들이 과거 선배들의 점진적인 성장 곡선을 그대로 밟아가는 것은 이제 불가능해졌다.&lt;/p&gt;
&lt;p&gt;그래서 나는 기존의 마인드맵을 예쁘게 포장하여 글을 마무리하는 것을 과감히 포기했다. 대신 원점으로 돌아가 이 4개의 단계를 새롭게 &lt;strong&gt;재정의&lt;/strong&gt;해 보기로 했다. 지난 10년을 정리하려던 이 글은, 다가올 미지의 10년을 예측하는 단상이 될 것이다.&lt;/p&gt;
&lt;h3&gt;동심원 1 &amp;quot;Making it work&amp;quot;: 개인의 역할&lt;/h3&gt;
&lt;p&gt;과거 시니어급 IC(Individual Contributor)에게 기대하는 이상적인 롤모델은 명확했다. 스스로 문제의 본질을 정의하고 정해진 타임라인 안에 고품질의 결과물을 뽑아내는 독자적인 오너십이었다. 결국 &#39;코드와 기술 문서의 질과 양&#39;이 실력을 증명하는 절대적인 척도였다.&lt;/p&gt;
&lt;p&gt;하지만 AI 시스템이 급속도로 전파되면서 이 견고했던 기준이 송두리째 흔들리고 있다. 웬만한 주니어들도 AI 도구를 잘 쓰기만 하면 그럴싸한 결과물을 순식간에 양산해 내며 업계 전체의 &#39;바닥&#39;을 무섭게 끌어올리고 있다. 기계적 속도와 양이 평준화된 지금, 엔지니어 개인의 업스킬링은 도대체 어디로 향해야 하는가.&lt;/p&gt;
&lt;p&gt;미래의 척도는 단순히 &#39;얼마나 훌륭하게 코딩을 해냈는가&#39;에 머물지 않는다. &#39;&lt;strong&gt;어떠한(What) 일을 왜(Why) 했는가&lt;/strong&gt;&#39;를 훨씬 더 집요하게 들여다보게 될 것이다. 역설적이게도 과거 매니저나 리더십에게 요구되던 거시적인 시야가 개별 엔지니어를 평가하는 기본 척도로 내려왔다. 개개인의 &lt;strong&gt;감각&lt;/strong&gt;(Taste), &lt;strong&gt;의도성&lt;/strong&gt;(Intentionality), 그리고 &lt;strong&gt;비판적 사고&lt;/strong&gt;(Critical Thinking)야말로 이제 엔지니어의 가장 치명적인 무기가 되었다. (이에 대한 구체적인 논의는 바로 이전 포스트인 &amp;lt;&lt;a href=&quot;https://hoch.io/ko/writing/2026-05-04-ai-raised-floor/&quot;&gt;AI가 끌어올린 바닥, 우리의 천장은 어디인가&lt;/a&gt;&amp;gt;에서 자세히 다루었다.)&lt;/p&gt;
&lt;p&gt;기술적 기본기를 내던져도 좋다는 뜻이 아니다. 흔들리지 않는 기본기 위에 &#39;가치를 판별하는 감각&#39;과 &#39;주도성(Agency)&#39;까지 얹어야 살아남는 시대가 되었다는 이야기다. 코딩을 넘어 PM처럼 사고하고 나아가 1인 기업 수준의 기업가 정신을 발휘할 수 있는가 - 이것이 미지의 10년이 던지는 첫 번째 도전이다.&lt;/p&gt;
&lt;h3&gt;동심원 2 &amp;quot;Making it Flow&amp;quot;: 팀과 프로세스의 재정의&lt;/h3&gt;
&lt;p&gt;이전 포스트들에서 나는 &lt;a href=&quot;https://hoch.io/ko/writing/2026-03-02-conflict-translator/&quot;&gt;&amp;quot;갈등 통역기&amp;quot;&lt;/a&gt;나 &lt;a href=&quot;https://hoch.io/ko/writing/2026-04-20-solid-systems-over-shining-heroes/&quot;&gt;&amp;quot;지속 가능한 퍼포먼스&amp;quot;&lt;/a&gt; 등의 개념을 통해, 시스템을 구축하여 실수를 줄이고 성과를 내는 커뮤니케이션 프로세스의 중요성을 다루었다.&lt;/p&gt;
&lt;p&gt;하지만 그 &amp;quot;어쩔 수가 없다&amp;quot;고 여겼던 오버헤드가 서서히 해체되고 있다. AI 필터링 덕분에 갈등의 텍스트가 순화되고, 소모적인 문서 작업의 짐이 사라지고 있다. 더욱 파괴적인 변화는 개인 능력이 AI로 증폭되면서, 과거 작은 팀 전체의 효율을 압도하는 &amp;quot;10X 엔지니어&amp;quot;가 실재하게 되었다는 점이다. AI가 기술 부채 해결이나 단순 구현을 전담하고, 인간은 오직 가장 중요한 &#39;승인 게이트&#39;만을 통제하게 될 것이다.&lt;/p&gt;
&lt;p&gt;코드 품질이 상향 평준화되고 새로운 프로덕트 및 기능의 출시 속도가 비약적으로 빨라지는 &amp;quot;&lt;strong&gt;Ship faster, AI fixes the rest&lt;/strong&gt;&amp;quot;의 시대. 이제 우리는 매우 불편한 질문을 마주할 수 밖에없다. &lt;strong&gt;&amp;quot;1명이 10명분의 일을 할 수 있다면, 나머지 9명이 필요한가?&amp;quot;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;각 회사가 가진 철학(혹은 &amp;quot;숨겨졌던 속내&amp;quot;)에 따라 어떤 곳은 9명을 해고할 것이고, 어떤 곳은 10명을 그대로 유지하며 AI 도입을 통해 아웃풋을 10배로 증폭시킬 것이다. 분명한 것은 사람과 AI 에이전트가 공존하는 하이브리드 팀이 새로운 노멀이 된다는 점이다. 기존에 출시 속도를 조절하고 복잡한 이해관계를 조율하던 TPM 직군이나 매니저들 역시 &amp;quot;어떻게 실질적인 가치를 창출할 것인가&amp;quot;에 집중하게 될 것이며, 모든 것이 예측하지 못한 형태로 재편될 것이다.&lt;/p&gt;
&lt;h3&gt;동심원 3 &amp;quot;Making it Together&amp;quot;: 플라이휠은 어디로?&lt;/h3&gt;
&lt;p&gt;세 번째 동심원 &amp;quot;Making it Together&amp;quot;는 개인, 팀, 프로덕트의 단위를 넘어 엔지니어링 리더십이 전반적인 &lt;strong&gt;생태계&lt;/strong&gt;(Ecosystem)를 어떻게 바라보고 이해할 것인가에 있다.&lt;/p&gt;
&lt;p&gt;이 생태계의 성장을 설명할 때 빠질 수 없는 전략이 바로 &#39;플라이휠(Flywheel)&#39;이다. 우리말로 가장 가까운 표현은 &#39;선순환 구조&#39;일 것이다. 하나의 서비스나 플랫폼이 의미 있는 성장을 이루기 위해서는 단편적인 성능 개선 및 기능 출시에 그치지 않고, 생태계 전체가 스스로 맞물려 돌아가는 이 거대한 선순환을 인식하고 그에 맞게 전략을 세워야 한다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-05-13-10-years-at-google/flywheel.png&quot; alt=&quot;플랫폼의 선순환&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;플랫폼의 선순환&lt;/p&gt;
&lt;p&gt;현존하는 가장 보편적인 컴퓨팅 플랫폼인 웹 브라우저나 모바일 운영체제를 예로 들어보자. 이 &amp;quot;생태계의 선순환&amp;quot;은 다음과 같은 궤적을 그린다. 브라우저 혹은 모바일 운영체제가 성능을 개선하고 새로운 기능을 제공하면, 파트너와 개발자들은 이를 활용해 더 뛰어난 앱과 서비스를 만들어낸다. 훌륭한 콘텐츠는 자연스럽게 더 많은 사용자를 생태계로 끌어들이고, 이렇게 늘어난 사용자 트래픽은 다시 플랫폼이 기술 혁신에 투자할 수 있는 강력한 원동력이 된다.&lt;/p&gt;
&lt;p&gt;이렇듯 플랫폼이라는 거대한 구심점을 통해 개발자와 파트너, 그리고 사용자가 유기적으로 연결되고, 모두가 윈윈(Win-Win)하며 파이를 키워나가는 아름다운 공생 관계. 이것이 많은 실리콘밸리 회사들이 믿어왔던 플랫폼 성장의 정석이었다.&lt;/p&gt;
&lt;p&gt;하지만 영원히 돌아갈 것 같았던 이 플라이휠이 AI라는 거대한 충격파를 만나 요동치고 있다. HTML5, 그리고 모바일 앱 이후로 나름 건강하게 지속되어 온 컴퓨팅 플랫폼 생태계가 불안해보인다. 여러 구성원들이 톱니바퀴처럼 맞물려 돌아가던 기존의 밸류체인이, 이제는 &amp;quot;&lt;strong&gt;AI ➔ 사용자&lt;/strong&gt;&amp;quot;라는 파괴적일 만큼 단순한 직통로로 급변하고 있는 것이다.&lt;/p&gt;
&lt;p&gt;이 붕괴 속에서 선순환의 허리를 받치던 파트너와 개발자들은 실존적 위기를 맞고 있다. 첫째, 비(非)엔지니어 사용자조차 특정 문제를 해결하기 위해 맞춤형 &lt;strong&gt;일회용 도구&lt;/strong&gt;(Jig)를 직접 생성해 쓰고 버리는 시대가 열렸다. 특정 기능으로 사람들의 삶을 편하게 해주던 수많은 크고작은 앱들, 그리고 B2B SaaS들이 경쟁력을 잃고 소멸 혹은 이합집산하고 있다.&lt;/p&gt;
&lt;p&gt;둘째, 살아남은 앱과 서비스들조차 &lt;strong&gt;거대 AI 모델의 껍데기&lt;/strong&gt;(Wrapper)로 전락하고 있다. 규모의 경제를 갖춘 슈퍼 앱을 제외하면, 대부분이 프론티어 AI의 추론 결과를 전달하는 단순 프론트엔드로 획일화될 위기에 처해 있다. 크고 작은 개발자들과 크리에이터들이 자생할 공간 자체가 사라지고 있는 것이다.&lt;/p&gt;
&lt;p&gt;분명한 것은 지금이 단순히 &#39;내 앱에 어떤 AI 기능을 추가할까&#39;에 몰두할 때가 아니라는 점이다. &#39;&lt;strong&gt;내가 딛고 서 있는 땅이 AI 시대에도 꺼지지 않고 버틸 수 있을 것인가?&lt;/strong&gt;&#39;를 냉철하게 묻고, 생태계 재편을 꿰뚫어 보는 통찰력이 어느 때보다 필요하다.&lt;/p&gt;
&lt;h3&gt;동심원 4 &amp;quot;Making it Matter&amp;quot;: 가치와 비전&lt;/h3&gt;
&lt;p&gt;변하지 않을 것 같았던 생태계가 알 수 없는 속도로 재편되는 지금, 이 네 번째 동심원은 하나의 조직이 궁극적으로 세상에 기여하고자 하는 &amp;quot;&lt;strong&gt;가치(Value)와 비전(Vision)&lt;/strong&gt;&amp;quot;을 다룬다.&lt;/p&gt;
&lt;p&gt;과거 불확실성의 안갯속에서, 리더들이 제시하는 비전은 조직이 길을 잃지 않게 해주는 북극성이었다. &amp;quot;우리가 왜 이것을 만들고, 세상에 어떤 가치를 더하는가&amp;quot;를 상기시켜 비즈니스 목표와 코드 사이의 간극을 메우는 것이 그 핵심 역할이었다.&lt;/p&gt;
&lt;p&gt;지금까지는 기술적 혁신과 기능적 우위가 대중을 위한 가치였다. 하지만 누구나 AI로 &#39;기본 이상&#39;의 프로덕트를 찍어내는 지금, 기능적 차이는 큰 의미를 잃어갈 것이다. 기발한 기능을 내놓아도 순식간에 아류작이 쏟아지거나 빅테크 혹은 프론티어 모델 회사들에게 흡수될 것이다. 앱과 서비스의 해자(Moat)가 허물어지는 이 기술적 평준화의 끝에 남는 유일한 차별점은 결국 &#39;&lt;strong&gt;가치와 비전&lt;/strong&gt;&#39; 그 자체가 될 것이다.&lt;/p&gt;
&lt;p&gt;과거에는 조직 말단의 엔지니어에게 리더십의 비전이 깊이 와닿기란 쉽지 않았다. 하지만 1인 기업 형태가 일반화되는 지금, 보드룸(Boardroom)에서나 오가던 무거운 비전에 대한 논의가 엔지니어 개개인의 수준으로 내려왔다. AI가 실행 역량을 저렴하게 만들어주면서, 핵심 병목은 &#39;무엇을 만들 수 있는가&#39;에서 &#39;&lt;strong&gt;무엇을 만들어야 하는지 선택하는 감각(Taste)&lt;/strong&gt;&#39;과 &#39;&lt;strong&gt;실행에 옮기는 주도성(Agency)&lt;/strong&gt;&#39;으로 이동했다.&lt;/p&gt;
&lt;p&gt;수많은 가짜 편리함 속에서 사람들이 진짜 가치 있다고 느끼는 지점을 짚어내는 직관력. 복잡한 시스템 전체를 조망하고 기술과 비즈니스의 교차점에서 판단을 내리는 &#39;총체적 엔지니어(Holistic Engineer)&#39;의 시대가 오고있다. 최근 스타트업 CEO들이 AI 기업의 개별 엔지니어로 합류하는 현상은, &#39;엔지니어&#39;와 &#39;비전을 가진 1인 기업가&#39;의 경계가 무너졌음을 보여주는 가장 명확한 힌트다.&lt;/p&gt;
&lt;h3&gt;에필로그: 불안한 설렘&lt;/h3&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-05-13-10-years-at-google/hero.png&quot; alt=&quot;부서진 낡은 공식들&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;부서진 낡은 공식들&lt;/p&gt;
&lt;p&gt;이 글은 혼돈의 AI 시대를 지나는 소프트웨어 엔지니어들을 위한 에세이다. 그렇기에 이 격변의 현장에서 느끼는 나의 혼란스러움이 고스란히 묻어 있을 것이다. 기존의 낡은 공식들을 예쁘게 포장하는 대신, 깨진 조각들을 발라내고 미래를 향한 4개의 동심원을 다시 그려보았다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Making it Work (개인):&lt;/strong&gt; 기술적 우수함과 디테일을 넘어선, &#39;오너십&#39;과 &#39;주도성(Agency)&#39;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Making it Flow (팀):&lt;/strong&gt; 사람과의 조율을 넘어선, AI 에이전트와의 &#39;하이브리드 협업&#39;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Making it Together (생태계):&lt;/strong&gt; 플랫폼의 격변을 직시하고 생존을 모색하는 &#39;통찰력&#39;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Making it Matter (가치):&lt;/strong&gt; 리더들의 전유물이었던 가치와 비전이 &#39;1인 기업가 정신&#39;으로.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;구글에서 10년. 이제야 거대한 시스템을 웬만큼 이해했다고 자만하려던 찰나, 상상치도 못한 격변기가 내 멱살을 잡고 다시 출발선으로 끌어다 놓았다. 하지만 지난 기세와 에너지로 미지의 10년을 다시 달릴 수 있는 이유가 있다니 오히려 다행일지도 모른다.&lt;/p&gt;
&lt;p&gt;우리는 지금, 낡은 공식이 파괴된 종착점이자 거대한 질문이 시작되는 새로운 출발선, 그 스펙터클의 한가운데 불안한 설렘을 안고 서 있다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>AI가 끌어올린 바닥, 우리의 천장은 어디인가</title>
    <link href="https://hoch.io/ko/writing/2026-05-04-ai-raised-floor/"/>
    <updated>2026-05-04T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-05-04-ai-raised-floor/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-05-04-ai-raised-floor/hero.png&quot; alt=&quot;바닥과 천장의 사이에서&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;바닥과 천장의 사이에서&lt;/p&gt;
&lt;p&gt;1839년, &lt;a href=&quot;https://en.wikipedia.org/wiki/Daguerreotype&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;다게레오타이프&lt;/a&gt;(최초의 상용 사진기)가 세상에 등장했을 때, 당대 최고의 아카데미즘 화가 폴 들라로슈는 &lt;a href=&quot;https://www.barnesfoundation.org/whats-on/early-photography&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&amp;quot;오늘로써 회화는 죽었다&amp;quot;&lt;/a&gt;며 깊은 탄식을 내뱉었다. 현실을 완벽하게 복제해 내는 기계 앞에서, 수십 년간 붓질을 연마해 온 화가들이 느꼈을 혼란과 공포는 과연 어떠했을까?&lt;/p&gt;
&lt;p&gt;최근 다양한 사람들과 깊은 대화를 나눌 기회가 있었다. 소프트웨어 엔지니어, 인문학 전공 학부생, 박사급 연구원, 디자이너, 교수님들, 변호사를 꿈꾸는 이들, 그리고 스타트업 창업자까지. 도메인과 직업은 완벽히 달랐지만, AI의 파도 앞에서 느끼는 불안감과 두려움은 놀라울 정도로 똑같았다. 마치 오래전 폴 들라로슈의 탄식처럼.&lt;/p&gt;
&lt;p&gt;그 대화 속에서 오간 이야기들 중 자주 등장하는 주제들을 하나의 글로 정리해보았다.&lt;/p&gt;
&lt;h3&gt;1. Fear Of Missing Out (FOMO)&lt;/h3&gt;
&lt;p&gt;가장 자주 듣는 질문이자 모든 불안의 시작점은 &#39;나만 뒤처지는 것 아닐까&#39; 하는 생각, 즉 FOMO(Fear Of Missing Out)다. 결론부터 말하자면, 공포는 실재하는 외부의 위협이 아니라 자신이 느끼는, 그렇기에 통제할 수 있는 내면의 감정이다. 빅테크의 최전선에 있는 엔지니어들조차 이 두려움을 원동력으로 삼아 전진하고 있다. 당신만 느끼는 감정이 아니라는 뜻이다.&lt;/p&gt;
&lt;p&gt;이 막연한 공포를 이겨내는 가장 효과적인 방법은 아이러니하게도 기술을 더 깊이 파고드는 것이 아니라, &lt;a href=&quot;https://hbr.org/2025/10/why-ai-at-work-makes-us-so-anxious&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;연대&lt;/a&gt;를 찾는 것이다. 혼자서 쏟아지는 논문과 소셜피드를 따라가며 두려움에 떠는 대신, 팀원들이나 스터디 그룹과 함께 배우며 느끼는 안도감과 재미를 느낄 수 있다. 이 두 가지 감정을 얻는 것만으로도 이미 남는 장사다.&lt;/p&gt;
&lt;p&gt;다만 멘탈 관리 못지않게 중요한 것이 있다. AI와 함께 일하는 환경이 근본적으로 변하고 있다는 사실을 이해하는 것이다. 프롬프트 엔지니어링, MCP, 에이전틱 시스템 같은 요즘 화제가 되는 기술들은 현재의 모델이 완벽하게 제어되지 않거나, 더 높은 효율을 얻기 위해 아직 불완전한 AI에게 덧대어 놓은 목줄(Harness)에 불과하다. 모델의 성능이 진화하면 이런 주변 장치들은 자연스레 불필요해지고 사라지는 과정을 반복할 것이다.&lt;/p&gt;
&lt;p&gt;&amp;quot;이거 아직도 모르시나요?&amp;quot; 혹은 &amp;quot;이거 하나면 끝납니다!&amp;quot; 같은 자극적인 소셜 피드에 휘둘리며, 언제 사라질지 모를 도구들을 마스터하려 진을 뺄 필요가 없다. 거대한 트렌드의 방향만 살피되, 내 앞의 문제를 해결하는 데 필요한 만큼만 취사선택하는 냉정한 마인드가 필요하다.&lt;/p&gt;
&lt;h3&gt;2. &amp;quot;내 커리어는 AI로부터 안전할까요?&amp;quot;&lt;/h3&gt;
&lt;p&gt;&amp;quot;AI가 사람을 대체하는 것이 아니라, AI를 잘 활용하는 사람이 그렇지 못한 사람을 대체할 것이다.&amp;quot;&lt;/p&gt;
&lt;p&gt;이 명제는 2026년 현재 거의 사실처럼 받아들여지고 있다. 하지만 좀 더 깊이 들여다보면, AI가 실제로 높이는 것은 &lt;a href=&quot;https://www.science.org/doi/10.1126/science.adh2586&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;천장이 아니라 &#39;바닥&#39;이다&lt;/a&gt;. 앞으로의 전략은 AI가 끌어올린 바닥과, 인간만이 도달할 수 있는 천장 사이의 간극을 어떻게 메울 것인가에 달려 있다.&lt;/p&gt;
&lt;p&gt;이 간극을 메우는 데 가장 효과적인 인재상은 여전히 &#39;&lt;a href=&quot;https://en.wikipedia.org/wiki/T-shaped_skills&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;T형 인재&lt;/a&gt;&#39;다. T자의 세로축, 즉 &lt;strong&gt;도메인 전문성&lt;/strong&gt;은 AI가 쏟아내는 결과물의 겉치레(Surface-level polish)를 꿰뚫어 보고 AI를 타이트하게 가이드하는 힘이다. 도메인 전문가들은 자기 분야에서 이미 &amp;quot;천장&amp;quot;에 가까운 퍼포먼스를 보여주고 있기에, &amp;quot;바닥의 상승&amp;quot;에 크게 영향받지 않는다. 또한, T자의 가로축, 즉 &lt;strong&gt;넓은 시야&lt;/strong&gt;는 단위 작업을 넘어 전체 시스템과 프로세스의 흐름을 이해하고 AI를 어디에 배치할지 기획하는 역량이다. 이처럼 눈에 잘 보이지 않는 업무의 맥락을 AI가 하루아침에 대체할 수는 없다.&lt;/p&gt;
&lt;p&gt;하지만 이러한 역량을 갖추는 것만으로는 부족하다. 무섭게 상승하는 &#39;바닥&#39; 위에서 대체되지 않고 경쟁력을 유지하기 위해 가장 눈여겨보아야 할 핵심 요소가 있다. 바로 조직과 프로세스 안 곳곳에 존재하는 &lt;strong&gt;책임&lt;/strong&gt;이다. 실행은 AI에게 위임할 수 있지만, 그 결과에 대한 책임은 결코 외주화할 수 없다. 기계가 99.9%를 완벽하게 수행해도, 치명적인 0.1%의 오류는 반드시 발생한다. 그때 최종적으로 책임을 지는 것은 그 도구를 가이드하고 승인한 사람이다. 인격체가 아닌 AI가 이 책임을 떠안는 것은 불가능하다. 변호사, 의사, 디자이너, 그리고 소프트웨어 엔지니어 - 거의 모든 직군에 해당되는 사항이다.&lt;/p&gt;
&lt;p&gt;바닥이 올라올수록, 책임자의 자리에 있는 사람의 가치는 더 높아진다. T형 역량을 무기로 AI를 능숙하게 제어하면서, 자신이 속한 조직의 워크플로우 안에서 &#39;책임&#39;이 발생하는 지점을 찾아 오너십을 쌓아가는 전략이 효과적이다.&lt;/p&gt;
&lt;h3&gt;3. &amp;quot;AI시대에 가장 중요한 스킬은 뭘까요?&amp;quot;&lt;/h3&gt;
&lt;p&gt;AI시대에 가장 중요한 스킬은 비판적·분석적 사고력이다. 가장 뻔한 질문에 가장 원초적인 답변이다. 그러나 이 진부함에는 그럴만한 이유가 있다.&lt;/p&gt;
&lt;p&gt;비판적·분석적 사고력은 다양한 모습으로 나타난다.&lt;/p&gt;
&lt;p&gt;첫째는 AI에게 날카롭고 의미 있는 질문을 던지는 능력이다. 좋은 답은 언제나 좋은 질문에서 출발한다. 질문의 수준은 결국 질문자가 가진 주제에 대한 이해도와 &lt;a href=&quot;https://superagency.ai/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;감각(Taste), 주체성(Agency), 그리고 &#39;내가 무엇을 원하는가&#39;라는 의도성(Intentionality)&lt;/a&gt;에 비례한다. 그렇기 때문에 경험과 지식이 많은 T형 인재들이 유리할 수밖에 없다. 통찰력 있는 좋은 질문이 결국 모든 AI 워크플로우의 출발점이다.&lt;/p&gt;
&lt;p&gt;둘째는 AI가 내놓은 결과를 비판적으로 분석하는 능력이다. AI의 결과물이 기술적, 표면적으로 완벽에 가까워 보일수록, 그 매끄러운 겉치레를 넘어 오류와 빈틈을 꿰뚫어 보는 비판적 판독력이 반드시 필요하다. 내용도 제대로 이해하지 못한 채 결과물만 가져다 쓰다 보면 &#39;&lt;a href=&quot;https://arxiv.org/abs/2506.08872&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;인지 부채(Cognitive Debt)&lt;/a&gt;&#39;가 쌓이게 된다. 이 문제가 증폭되는 것을 막기 위해, 내가 만들어낸 AI 결과물을 온전히 이해한 뒤, 책임감을 가지고 타인의 프로세스에 병목을 만들지 않는 것이 매우 중요하다.&lt;/p&gt;
&lt;p&gt;셋째는 AI 사용자로서 자기 자신을 성찰하는 능력이다. AI의 진정한 위험은 &#39;사유의 마찰(불편하고 느린 숙고의 과정)&#39;을 제거해버리는 데 있다. 자신도 모르게 이러한 패턴에 빠지고 있지 않은지 끊임없이 돌아보아야 한다. 그와 반대로 AI를 너무 단순한 도구처럼 최소한으로 사용하고 있지는 않은지도 생각해봐야 한다. 이 스펙트럼 위에서 적절한 밸런스를 유지하면서, &lt;a href=&quot;https://www.penguinrandomhouse.com/books/743846/co-intelligence-by-ethan-mollick/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;AI 사용을 언제 멈춰야 할지 아는 것&lt;/a&gt;, 즉 사람이 개입하여 마무리 지어야 하는 타이밍을 아는 능력도 중요하다.&lt;/p&gt;
&lt;h3&gt;나가며&lt;/h3&gt;
&lt;p&gt;오래전 폴 들라로슈는 회화의 죽음을 선포했을지언정, 회화는 끝내 죽지 않았다. 사진기가 &#39;현실 모방&#39;이라는 바닥을 높여버리자, 화가들은 인간의 주관적 인상(인상주의)과 무의식(초현실주의)이라는 새로운 천장을 뚫어냈다. 기술이 송두리째 바꿔놓은 환경 속에서 &amp;quot;인간만이 해낼 수 있는 일&amp;quot;을 어떻게든 찾아낸 것이다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-05-04-ai-raised-floor/art.png&quot; alt=&quot;인간만이 해낼 수 있는 일은 무엇일까?&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;인간만이 해낼 수 있는 일은 무엇일까?&lt;/p&gt;
&lt;p&gt;바닥은 앞으로도 계속 높아질 것이다. 중요한 것은 그 속도에 패닉하는 것이 아니라, 우리가 지켜내야 할 &#39;천장&#39;을 명확히 정의하는 일이다.&lt;/p&gt;
&lt;p&gt;천장이란 AI가 구조적으로 넘볼 수 없는 경계선이다. AI는 방대한 패턴을 학습해 최적의 결과물을 내놓지만, 전례 없는 상황에서 나아갈 방향을 판단하고 무엇이 진정 가치 있는 일인지 결정하는 것은 온전히 인간의 몫이다. 무엇보다 실행을 위임하더라도, 그 결과에 자신의 이름을 걸고 책임을 지는 무게감은 결코 기계에게 넘길 수 없다.&lt;/p&gt;
&lt;p&gt;지금의 혼란은 과거 미술계가 진보하며 겪었던 성장통과 무척 닮아 있다. 마침내 도달할 답은 다시 인간 속에 있다. 기계가 닿을 수 없는 비판적 사고, 직관, 그리고 창의성이라는 인간 본연의 영역을 탐구하는 것. 이것이야말로 진정한 &#39;인간성&#39;의 원점으로 되돌아가는 움직임이다. 한동안 외면받았던 인문학이 다시 조명받는 시대가 서서히 열리고 있다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>반짝이는 영웅보다는 단단한 시스템을</title>
    <link href="https://hoch.io/ko/writing/2026-04-20-solid-systems-over-shining-heroes/"/>
    <updated>2026-04-20T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-04-20-solid-systems-over-shining-heroes/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-04-20-solid-systems-over-shining-heroes/hero.png&quot; alt=&quot;팀을 구해내는 영웅&quot; /&gt;&lt;/p&gt;
&lt;h3&gt;반짝하는 타이밍&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;You&#39;ll achieve much more by being consistently reliable than by being occasionally extraordinary.&amp;quot;&lt;/p&gt;
&lt;p&gt;— Sahil Bloom, &amp;lt;The 5 Types of Wealth&amp;gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;나에게 2019년은 여러모로 흥미로운 한 해였다. 그중에서도 가장 기억에 남는 것은 구글 개발자 컨퍼런스인 &amp;quot;Google I/O&amp;quot; &lt;a href=&quot;https://www.youtube.com/watch?v=-GaD0RCp-Q0&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;무대에 연사로 섰던 순간&lt;/a&gt;이다. 수많은 관문을 거치고 리허설을 마친 뒤 무대에 섰을 때, 나는 구글 입사 후 5년 동안 미친 듯이 쏟아부었던 프로젝트들을 전 세계 개발자들에게 마음껏 자랑할 수 있었다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-04-20-solid-systems-over-shining-heroes/google-io.png&quot; alt=&quot;2019년, 구글 I/O 무대에서&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;2019년, 구글 I/O 무대에서&lt;/p&gt;
&lt;p&gt;사내에서도 꽤 큰 업적이었기에, 당시 매니저의 지지를 업고 조금 이른 타이밍에 과감히 승진을 신청했다. 결과는 실패였다.&lt;/p&gt;
&lt;p&gt;당시 승진 심의 위원회로부터 받은 피드백은 충격적이었다. &amp;quot;&lt;strong&gt;지속 가능한 퍼포먼스(Sustainable Performance)인지 알 수 없기 때문에 더 지켜봐야 한다.&lt;/strong&gt;&amp;quot;&lt;/p&gt;
&lt;p&gt;화려한 무대, 성공적인 발표, 쏟아지는 박수... 이 모든 것이 &#39;반짝 성과&#39;일 수도 있다는 지적이었다. 당시의 어린 마음으로는 그 결정을 도저히 이해할 수도, 공감할 수도 없었다. 하지만 매니저가 되고 리더십을 공부하며 깨달았다. 구글이 왜 그토록 &#39;지속가능성&#39;에 집착하는지를.&lt;/p&gt;
&lt;h3&gt;영웅을 경계하는 이유&lt;/h3&gt;
&lt;p&gt;이 사고의 출발점은 &#39;팀워크&#39;다. 아무리 출중한 개인이라도 혼자서는 거대한 성공을 만들 수 없다. 우리가 말하는 괄목할 만한 성과란, 팀이 준비한 타임라인과 사회경제적 타이밍이 맞아떨어졌을 때, 마침 그 자리에 있었던 사람들에 의해 발현되는 경우가 많다. 그렇기에 구글은 &lt;strong&gt;잠깐 반짝하고 빛나는 실적보다는 팀의 일원으로서 얼마나 지속적으로 공헌하는가&lt;/strong&gt;에 훨씬 더 높은 점수를 준다.&lt;/p&gt;
&lt;p&gt;구글의 승진 시스템이 독특한 또 다른 이유는 &#39;자격 요건&#39;에 있다. 승진해서 리더가 되는 것이 아니라, &amp;quot;&lt;strong&gt;이미 리더의 역할을 수행하고 있는 사람&lt;/strong&gt;&amp;quot;을 승진시킨다. 즉, 승진은 신분 상승이 아니라 &lt;strong&gt;역량에 대한 사후 인정&lt;/strong&gt;이다.&lt;/p&gt;
&lt;p&gt;이러한 시스템은 여러 가지 장점이 있다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;승진 후에도 본연의 업무가 크게 달라지지 않아 혼란이 적다.&lt;/li&gt;
&lt;li&gt;동료들의 긍정적인 피드백(Peer Review) 없이는 승진이 불가능하므로, 동료들의 전폭적인 지지와 신뢰를 받는 리더가 자연스럽게 탄생한다.&lt;/li&gt;
&lt;li&gt;능력이나 리더십이 검증되지 않은 사람이 &#39;정치&#39;로 올라가는 것을 매우 어렵게 만든다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;이러한 정책들은 자연스럽게 팀워크와 지속성에 집중하는 문화를 만든다. 하지만 &amp;quot;아름다운 문화&amp;quot;만으로는 부족하다. 문화가 공감대를 만든다면, 또 다른 한 편에는 실용적인 시스템과 기계적인 프로세스가 마련되어 있어야 한다. 그렇지 않으면 문화는 허황된 이상에 불과할 뿐이다.&lt;/p&gt;
&lt;h3&gt;시스템이 무너진 곳에서 영웅이 태어난다&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;You do not rise to the level of your goals. You fall to the level of your systems.&amp;quot;&lt;/p&gt;
&lt;p&gt;– James Clear, &amp;lt;Atomic Habit&amp;gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;지속 가능한 퍼포먼스를 위해서 반드시 필요한 것은 팀이 효율적으로 운영될 수 있는 시스템과 프로세스를 만드는 것이다. 팀 구성원들이 프로젝트를 수행하며 새로운 상황을 마주칠 때마다 매번 원점으로 돌아가 의사결정을 내려야 한다면 효율이 떨어질 수밖에 없다. 물론 이런 혼란스러운 상황을 타개해 나갈 때마다 배우는 것들이 있겠지만, 이러한 혼란과 극복을 되풀이할 때마다 소비하게 되는 시간과 에너지의 낭비는 결코 만만치 않다. 예측 불가능한 돌발 상황은 지속 가능한 퍼포먼스의 최대의 적이다.&lt;/p&gt;
&lt;p&gt;시스템과 프로세스가 가져다주는 가장 큰 가치는 &lt;strong&gt;빠른 의사결정, 집중된 실행, 그리고 팀의 안정&lt;/strong&gt;이다. 예측하지 못한 난관을 맞닥뜨렸을 때 팀 전체가 패닉 모드로 돌입하여 퇴근 시간 이후에도 그룹 챗이 가동되고, 십수 개의 이메일 스레드가 동시다발적으로 오고 간다면, 이는 시스템이 없거나 제대로 동작하고 있지 않다는 것이다. 예를 들어, 엔지니어링 팀이 하루의 절반을 넘는 시간을 비상 상황의 타개를 위한 의사소통과 결정에만 사용한다면, 그만큼 엔지니어링 프로젝트의 속도와 질은 낮아질 수밖에 없다. 눈코 뜰 새 없이 사건 사고를 처리하는 그 바쁜 느낌이 언뜻 생산적으로 느껴질 수 있으나, 이러한 &amp;quot;바쁨을 위한 바쁨&amp;quot;은 의미 있는 임팩트로 이어지기 힘들고, 결코 지속 가능하지도 않다.&lt;/p&gt;
&lt;p&gt;예측하지 못한 사건을 팀이 어떻게 해결하는지 그 과정을 유심히 지켜보는 것은 꽤 많은 힌트를 준다. 왜 예측하지 못했는지, 그리고 해결하는 데 가장 큰 장애물이 무엇이었는지부터 질문을 던져보면 좋다. 전자에 대해서는 팀 내에서 해결책을 찾아야 하고, 후자에 대해서는 리더십에게 제대로 된 문제 제기를 하는 것이 필요하다. 시스템이 무너진 곳에서 비로소 영웅이 등장한다. 하지만 그 등장이 과연 반가운 일일까?&lt;/p&gt;
&lt;h3&gt;나이트 라이더와 맥가이버&lt;/h3&gt;
&lt;p&gt;나이트 라이더와 맥가이버 - 필자가 어릴 때 밤마다 즐겨보던 해결사가 등장하는 심야 드라마들이다. 플롯은 늘 한결같다. 엄청난 사건 사고와 혼란을 헤쳐나가며 결국에는 주인공이 초인적인 능력을 발휘하여 모든 사건을 한 방에 처리한다. 시청자들은 여기서 간접적인 안도감과 통쾌함을 느낀다. &amp;quot;영웅은 멋진 것&amp;quot;이라는 위험한 동경이 8세 아이의 마음에 각인되는 순간이다.&lt;/p&gt;
&lt;p&gt;영웅은 난세에 나타난다. 그들이 칭송받는 이유는 남들이 못하는 &#39;초인적인 기여&#39;를 했기 때문이다. 하지만 초인적인 기여는 본질적으로 지속 가능하지 않다. 그것은 누군가의 &lt;strong&gt;희생&lt;/strong&gt;을 담보로 하기 때문이다. 어떤 문제 해결에 있어서 누군가의 초인적인 기여가 필요했다면, 이는 칭송하고 끝날 일이 아니라 팀의 시스템과 프로세스에 대해 전반적으로 검토가 필요하다는 뜻이다.&lt;/p&gt;
&lt;p&gt;계속된 희생을 강요받는 탑 탤런트들은 결국 번아웃되어 떠난다. 영웅에게 의존하던 팀은 그가 떠나는 순간 와르르 무너진다. 이 지점에서 리더인 우리는 스스로에게 물을 필요가 있다. &amp;quot;우리 팀은 영웅 없이도 돌아가는가?&amp;quot;&lt;/p&gt;
&lt;h3&gt;영웅 없는 승리&lt;/h3&gt;
&lt;p&gt;물론 위기 상황에서 앞장서 몸을 던진 영웅들의 헌신을 깎아내려서는 안 된다. 그들의 헌신은 칭송받아야 하고 보상받아야 한다. 하지만 위기를 넘긴 후, 우리의 시선이 향해야 할 곳은 다음과 같을 것이다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;지식의 분배&lt;/strong&gt;: 영웅의 노하우가 팀 전체로 퍼지도록 코칭과 멘토링 세션을 만든다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;기회의 재분배&lt;/strong&gt;: 특정 팀원에게 업무가 몰리지 않도록 프로젝트를 재할당한다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;시스템 재건&lt;/strong&gt;: 앞으로 그런 &#39;초인적인 노력&#39;이 필요 없도록 프로세스를 고친다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;효율적인 매니지먼트란, 쉴 새 없이 몰아치는 난세에도 &lt;strong&gt;누군가의 영웅적인 희생 없이, 평범한 사람들이 모여 계획된 성과를 지속적으로 달성해 내는 것&lt;/strong&gt;이다.&lt;/p&gt;
&lt;p&gt;순간적이고 영웅적인 기여는 &#39;보너스&#39;로 축하하더라도, 팀원의 꾸준한 성장이 &#39;승진&#39;이라는 결과로 이어질 수 있도록 돕는 것이 더 바람직하다. 모두가 지속 가능한 속도로 함께 달릴 수 있는 트랙을 만드는 것. 결국 그것이야말로 리더가 집중해야 할 가장 중요한 역할 아닐까.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>일 잘하는 팀을 만드는 다섯 가지 아이디어 (2)</title>
    <link href="https://hoch.io/ko/writing/2026-04-13-5-ideas-for-high-performing-teams-part-2/"/>
    <updated>2026-04-13T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-04-13-5-ideas-for-high-performing-teams-part-2/</id>
    <content type="html">&lt;p&gt;&lt;em&gt;이 글은 &lt;a href=&quot;https://hoch.io/ko/writing/2026-03-30-5-ideas-for-high-performing-teams-part-1/&quot;&gt;일 잘하는 팀을 만드는 다섯 가지 아이디어 (1)&lt;/a&gt;에서 이어집니다.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-30-5-ideas-for-high-performing-teams/hero-part-2.png&quot; alt=&quot;실패를 배움의 기회로&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;실패를 배움의 기회로&lt;/p&gt;
&lt;p&gt;앞선 글에서는 완벽함보다는 &lt;strong&gt;빠른 실행(Bias toward action)&lt;/strong&gt;, 멀티태스킹 대신 &lt;strong&gt;무자비한 집중(Ruthless Prioritization)&lt;/strong&gt;, 그리고 불확실성을 없애기 위한 &lt;strong&gt;지나칠 만큼의 소통(Overcommunication)&lt;/strong&gt; 이라는 세 가지 아이디어를 살펴보았다. 이번 글에서는 팀워크를 더욱 단단하게 만드는 두 가지 아이디어에 대해 다룬다.&lt;/p&gt;
&lt;h3&gt;4. 비난 없는 실패와 명확한 오너십 (Blameless Culture &amp;amp; Clear Accountability)&lt;/h3&gt;
&lt;p&gt;일 잘하는 팀은 실패했을 때 개인을 희생양으로 삼지 않고, 그 안에서 배울 점을 찾아 시스템을 고치는 데 집중한다.&lt;/p&gt;
&lt;p&gt;이를 가장 잘 보여주는 것이 구글의 &#39;포스트모텀(Post-mortem)&#39; 문화다. 대형 사고가 터져도 패닉 없이 엔지니어와 리더십이 합심해 사태를 수습한 뒤, 과정을 낱낱이 기록해 공유한다. 이 문서의 목적은 &amp;quot;누가 잘못했는가&amp;quot;를 찾아 밝히는 것이 아니라 &amp;quot;왜 문제가 발생했고, 어떻게 재발을 막을 것인가&amp;quot;를 논의하는 데 있다. 수습하고 문서화하되, 그 누구도 비난하지 않는다.&lt;/p&gt;
&lt;p&gt;하지만 비난이 없다고 책임마저 사라지는 것은 아니다. 이럴 때일수록 &#39;명확한 오너십&#39;이 필수적이다. 책임이 불분명하면 아무도 나서지 않는 &#39;&lt;a href=&quot;https://en.wikipedia.org/wiki/Tragedy_of_the_commons&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;공유지의 비극(Tragedy of the Commons)&lt;/a&gt;&#39;으로 이어지기 십상이다. 이를 막기 위해, 건강한 팀은 본인의 과실이 아니더라도 포스트모텀 작성에 자원하는 것을 오너십의 발현으로 인정한다.&lt;/p&gt;
&lt;p&gt;이러한 문화가 팀에 가져다주는 장점은 결코 무시할 수 없다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;심리적 안전감&lt;/strong&gt;: 실패의 책임을 서로에게 떠넘기는 비생산적인 소모전이 사라진다. 이는 누구나 징벌에 대한 두려움 없이 &lt;strong&gt;계산된 리스크&lt;/strong&gt;를 기꺼이 감수하고, 새로운 아이디어로 도전할 수 있는 공간을 만들어 준다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;책임에 대한 재정의&lt;/strong&gt;: 자신의 실수를 인정하고 적극적으로 수습하는 태도(&amp;quot;owning your mistake&amp;quot;)가 멋진 행동으로 재평가 받는다. 스스로 포스트모텀을 주도하는 모습이 &#39;무능력의 낙인&#39;이 아니라 반복된 실패를 끊어내려는 &lt;strong&gt;용기 있는 리더십&lt;/strong&gt;으로 인정받게 되는 것이다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;지식의 투명한 공유&lt;/strong&gt;: 뼈아픈 수습의 기록은 부끄러운 반성문으로 남기보다는, 팀 전체의 도메인 지식을 한 단계 끌어올리는 귀중한 자산이 된다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;절대로 실패하지 않는 방법은 아무것도 하지 않는 것이다.&lt;/strong&gt; 혁신에는 때때로 실패가 따름을 인정하고, 예기치 않은 사고에 성숙하게 대처하는 팀을 만드는 것이 중요하다.&lt;/p&gt;
&lt;h3&gt;5. 못된 천재는 필요없다. (&amp;quot;No Jerks&amp;quot; Policy)&lt;/h3&gt;
&lt;p&gt;단도직입적으로 말해, &#39;못된 천재&#39;를 팀에 남겨두어야 할 이유는 단 하나도 없다.&lt;/p&gt;
&lt;p&gt;뛰어난 실력을 가졌다는 이유로 &#39;무례한 능력자&#39;를 은연중에 용인하기 시작하면, 팀워크에는 서서히 보이지 않는 금이 간다. 은근한 무시와 편 가르기, 정보 독점, 나아가 동료의 실패를 유도하는 병적인 행위가 만연해진다. 이런 &#39;못된 천재&#39;들은 앞서 강조한 스워밍 협업 모델을 혐오한다. 철저히 고립되어 혼자 일하는 것을 즐기며, 스스로를 거대한 정보의 병목 한가운데에 둔다. 전체적인 업무 흐름과 과정을 자기 입맛대로 통제하고 자신의 업적을 과장하려 하기 때문이다.&lt;/p&gt;
&lt;p&gt;당장의 성과가 급하다는 이유로 이런 치명적인 독성을 방관했을 때, 결국 조직이 나중에 치르게 되는 대가는 생각보다 훨씬 크다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;팀의 성과를 예측하는 것이 불가능해진다.&lt;/strong&gt; &#39;못된 천재&#39;의 기분과 컨디션에 따라 150%와 50%를 오가는 아웃풋을 내는 팀보다 80%의 퀄리티를 약속된 시간에 안정적으로 딜리버리하는 팀이 파트너 입장에서는 훨씬 가치 있다. 불필요한 &#39;서프라이즈&#39;가 없기 때문이다. 예측할 수 없는 팀은 곧 신뢰를 잃고 파트너의 자리에서 밀려난다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;사람들은 떠나고 매니저는 지쳐간다.&lt;/strong&gt; 잘 돌아가는 팀의 근간에는 누구나 안심하고 의견을 낼 수 있는 &#39;심리적 안전감&#39;이 있다. &#39;못된 천재&#39;가 지배하는 환경에서 상처받은 사람들은 팀을 떠나기 시작한다. 매니저는 팀원들 간의 갈등 수습에 시간과 에너지를 소진하고, 또 빈자리를 새로 채우는 데 막대한 비용을 치르게 된다. (관련 포스트: &lt;a href=&quot;https://hoch.io/ko/writing/2026-03-02-conflict-translator/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;갈등통역기&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&#39;못된 천재&#39;들에게 과도하게 의존했던 만큼, 이들이 떠날 때 심각한 타격을 입는다.&lt;/strong&gt; 그러나 아이러니하게도, 이들이 어떻게든 떠나는 결말이 가장 긍정적인 시나리오다. 단기적인 타격을 감수하고서라도 독소를 빠르게 제거한 후 팀의 문화를 정상화하는 것이 최선이다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;만약 그 천재의 코딩 실력이나 도메인 지식이 감히 업계 최고 수준이라 할지라도, 그 1인 때문에 팀 전체가 서서히 병들며 상위 조직 전체의 성과에 까지 큰 타격을 입히는 경우를 심심치 않게 보았다. 걷잡을 수 없는 미움과 증오가 뿌리내리기 전에 빠르게 도려내는 것이 건강한 팀워크를 지켜내는 정답이다.&lt;/p&gt;
&lt;h3&gt;마치며&lt;/h3&gt;
&lt;p&gt;실행에 방점을 두고, 무자비하게 집중하며, 투명하게 소통하는 것. 실패를 비난의 대상이 아닌 배움의 기회로 여기고, 팀을 망가뜨리는 독소에는 단호하게 선을 긋는 것.&lt;/p&gt;
&lt;p&gt;이 다섯 가지의 아이디어들이 한국의 기업 환경에 얼마나 현실적으로 적용될 수 있을 지는 확실히 논의가 더 필요한 부분이라 생각한다. 하지만 이 아이디어들을 꿰뚫는 본질은 실무와 동떨어진 거창하고 추상적인 &amp;quot;실리콘밸리에서 온 초미래 경영 전략&amp;quot; 따위가 아니라, 그저 &#39;&lt;strong&gt;오직 성과의 속도와 품질에만 몰두할 수 있도록 팀원들을 보호하는 문화의 정립&lt;/strong&gt;&#39;이라 생각한다.&lt;/p&gt;
&lt;p&gt;AI가 모든 것을 무서운 속도로 먹어치우는 오늘날. 그럼에도 불구하고, 이 아날로그적인 팀워크의 본질과 가치는 결코 변하지 않을 것이다. 오히려 서로 등을 맞대고 단단하게 뭉친 팀만이, 갈수록 예측하기 힘들어지는 디지털 정글에서 살아남게 될 것이라 믿는다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>일 잘하는 팀을 만드는 다섯 가지 아이디어 (1)</title>
    <link href="https://hoch.io/ko/writing/2026-03-30-5-ideas-for-high-performing-teams-part-1/"/>
    <updated>2026-03-30T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-03-30-5-ideas-for-high-performing-teams-part-1/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-30-5-ideas-for-high-performing-teams/hero-part-1.png&quot; alt=&quot;1, 2, 3, Go Team!&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;&quot;1, 2, 3, Go Team!&quot;&lt;/p&gt;
&lt;h3&gt;들어가며&lt;/h3&gt;
&lt;p&gt;지금까지 다양한 형태의 크고 작은 팀을 이끌며 끊임없이 마주했던 질문이 하나 있다. &amp;quot;도대체 일 잘하는 팀과 그렇지 못한 팀의 차이는 무엇일까?&amp;quot; 지속적으로 훌륭한 결과를 내는 팀들을 유심히 관찰해 보며, 그들을 관통하는 몇 가지 패턴을 발견할 수 있었다. 이 패턴들은 어찌보면 리더십과 매니지먼트 도서에 흔히 등장하는 평범한 원칙들이지만, 실제 현업에서 이 광경을 목격할 때마다 남몰래 감탄하고는 했다.&lt;/p&gt;
&lt;p&gt;물론, 이 글에 담긴 관찰의 기록들은 한국의 보편적 기업 문화와는 그 결이 상당히 다를 수 있다. 당장 내일 적용하기엔 비현실적인 유토피아처럼 들릴지도 모른다. 하지만 오늘날 실리콘밸리에서 엔지니어링 팀들이 어떤 문화와 원칙을 바탕으로 움직이고 있는지 살펴보는 것만으로도 훌륭한 영감이 될 수 있다고 믿는다. 여기 두 편의 포스트에 걸쳐 지난 몇 년간의 생각과 관찰의 기록을 풀어 본다.&lt;/p&gt;
&lt;h3&gt;1. 실행 우선주의 (Bias toward Action)&lt;/h3&gt;
&lt;p&gt;잘 돌아가는 팀은 가능하면 우선 실행하고 빠르게 고쳐나가는 것에 익숙하다.&lt;/p&gt;
&lt;p&gt;우리가 흔히 빠지는 함정 중 하나는 &#39;완벽하게 준비된 상태에서 움직여야 안전하다&#39;는 착각이다. 하지만 통제 불가한 변수가 넘쳐나는 실제 환경에서 100% 완벽한 계획이란 애초에 불가능하다. 진짜 쓸모 있는 피드백은 추측과 상상이 아니라, 프로덕트가 사용자와 만나는 필드에서 나온다. &#39;완벽한 정답은 없다&#39;는 사실을 담담히 인정하고, &lt;strong&gt;작게 실패하며(Fail fast) 점진적으로 방향을 고쳐 나가는(Course correction) 전략&lt;/strong&gt;이 오히려 팀의 속도를 끌어올리는 것을 자주 목격했다.&lt;/p&gt;
&lt;p&gt;넘쳐나는 데이터와 수많은 파트너들의 요청 사이에서 가장 경계해야 할 현상은 이른바 &#39;&lt;strong&gt;분석 마비(Analysis Paralysis)&lt;/strong&gt;&#39;일 것이다. 수량과 지표, 상반된 의견들 사이에서 결단을 미루는 동안 팀의 모멘텀과 에너지는 조용히 증발해 버린다. 한 &lt;a href=&quot;https://www.bain.com/consulting-services/organization/decision-effectiveness/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;연구결과&lt;/a&gt;에 따르면, 의사결정 속도와 질이 상위 20% 안에 드는 조직은 그렇지 않은 곳보다 성장률이 5.5배나 높았다고 한다. 고민의 길이가 늘어난다고 결과의 퀄리티가 비례하는 것은 아님을 체감할 수 있는 대목이다.&lt;/p&gt;
&lt;p&gt;잘 돌아가는 팀들은 완벽한 정답이 나올 때까지 기다리지 않는다. 대신 결정을 위한 타임박스(Timeboxing)를 정해두고, 그 시간이 지나면 어찌 되었든 결론을 짓고 다음 스텝으로 넘어간다. 또한, 팀의 최종 결정이 내 의견과 다소 다르더라도 일단 컨센서스가 만들어지면 팀원 모두가 그 방향으로 힘을 싣는 성숙한 태도(Disagree and commit)를 보여주었다. 제자리에서 머리를 쥐어뜯는 것보다, 조금 빗나가더라도 일단 실행하고 빠르게 고쳐나가는 것이 낫다는 계산이다.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://www.theuncertaintyproject.org/tools/decision-types&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;모든 결정&lt;/a&gt;이 벼랑 끝의 돌이킬 수 없는 결과(1-way door)를 낳는 것은 아닐 것이다. 언제든 되돌아가 궤도를 수정할 수 있는 성격의 프로젝트(2-way door)라면, 100%의 정보가 모일 때까지 기다리기보다는 &lt;a href=&quot;https://www.theuncertaintyproject.org/threads/improving-strategy-development-with-a-strategy-5x5&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;70% 정도의 확신&lt;/a&gt;만으로도 방아쇠를 당길 줄 아는 결단력이 팀의 진짜 속도를 만들어 내는 경우를 많이 볼 수 있었다.&lt;/p&gt;
&lt;h3&gt;2. 무자비한 집중 (Prioritize Ruthlessly)&lt;/h3&gt;
&lt;p&gt;잘 돌아가는 팀은 &amp;quot;가장 중요한 단 한 가지&amp;quot;에 팀의 역량을 무자비하게 집중한다.&lt;/p&gt;
&lt;p&gt;팀이 사방으로부터의 요청에 끌려다니다 보면 그 성과는 필연적으로 분산될 수밖에 없다. 잘 돌아가는 팀은 쏟아지는 잡다한 질문과 요청들을 온몸으로 막아내는 대신, 철저히 우선순위를 매기고 과감하게 덜어내는(Filter and queue) 방어벽을 세운다. 진정한 속도는 멀티태스킹이 아니라 무자비한 집중력에서 나오는 경우가 많았다.&lt;/p&gt;
&lt;p&gt;얼핏 보면 여러 프로젝트를 동시에 쳐내는 병렬화가 효율적인 것처럼 보일 수 있다. 하지만 사일로(Silo)에 갇힌 개인은 느릴 수밖에 없다. 당사자들은 개개인이 120%의 효율을 발산하는 &#39;병렬화&#39;라고 생각하겠지만, 팀의 전체적인 효율 관점에서는 그저 에너지를 흩뿌리는 &#39;파편화&#39;일 뿐이다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-30-5-ideas-for-high-performing-teams/swarming.png&quot; alt=&quot;스워밍&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;스워밍(Swarming): 집중 VS 파편화&lt;/p&gt;
&lt;p&gt;진정한 성과는 팀 전체가 하나의 목표에 달려들어 집중하는 &#39;스워밍(Swarming)&#39;에서 나온다. 주어진 공사기간 내에 다리를 건설하는 상황을 떠올려 보자. 네 사람이 한 다리에 집중하면 100% 완성된 튼튼한 다리를 만들어 즉시 강을 건널 수 있다. 하지만 네 사람이 각자 다른 위치에서 다른 다리를 짓는다면, 네 개의 완성되지 않은 다리만 남게 된다. 25% 완성된 네 개의 다리로는 아무도 강을 건너지 못한다. 고독의 벽을 허물고 팀이 뭉쳐서 집중할 때, 실질적인 임팩트는 물론이고 도메인 지식 공유까지 복리로 팽창한다.&lt;/p&gt;
&lt;p&gt;잘 돌아가는 팀들은 무리한 요청이 들어왔을 때 무작정 &amp;quot;너무 바빠서 안 됩니다&amp;quot;라고 응대하지 않았다. 대신 &amp;quot;&lt;em&gt;현재 우리는 프로젝트 A에 전력을 다하고 있으며(스워밍), 요청하신 B 프로젝트는 대략 3주 후에 시작할 수 있을 것 같습니다.&lt;/em&gt;&amp;quot;라고 투명하게 타임라인을 공유했다. 이러한 &#39;예측 가능성&#39;이 부서 간 협업에서는 무척 중요한데, 투명한 정보 공유와 프로세스를 통해 &amp;quot;이 팀은 믿고 일할 수 있는 든든한 파트너&amp;quot;라는 강한 신뢰를 만들어내기 때문이다.&lt;/p&gt;
&lt;h3&gt;3. 지나칠 만큼의 소통 (When in doubt, Overcommunicate)&lt;/h3&gt;
&lt;p&gt;잘 돌아가는 팀은 지나칠 지언정 끊임없이 소통하고 확인한다.&lt;/p&gt;
&lt;p&gt;실행 우선주의에 입각하여 무자비한 집중을 한다고 해도, 그 방향 자체가 잘못되었다면 고스란히 시간과 자원의 낭비일 뿐이다. &amp;quot;잘못된 것에 집중&amp;quot;하는 사태를 막으려면, 선제적이고 지속적인 의사소통을 통해 우리가 올바른 궤도에 있는지 끊임없이 동기화해야 한다.&lt;/p&gt;
&lt;p&gt;대규모 협업 환경에서 조금이라도 불확실한 부분이 발견된다면, 지나치다 싶을 정도로 소통하여 불확실성을 제거해야 한다. 가정과 추측은 결국 프로젝트의 실패와 협업 당사자 간의 불신으로 이어진다. 이를 막는 가장 단순하고 저렴한 방법은, 혼자 넘겨짚는 대신 &amp;quot;내가 이해한 것이 맞는지&amp;quot; 끊임없이 묻고 정보를 공유하는 것이다.&lt;/p&gt;
&lt;p&gt;이러한 맥락에서 &#39;정보 독점&#39;은 조직의 효율을 갉아먹는 가장 치명적인 문제점 중 하나다. 누군가 정보를 독점하는 순간, 그 사람 자체가 전체 프로젝트의 병목이 된다. 정보가 투명하게 흐르지 않으면 팀원들은 불완전한 정보만으로 성급한 판단을 내리게 된다. 결국 어긋난 결과를 바로잡기 위해 배 이상의 노력을 쏟게 되며, 책임 소재를 따지는 과정에서 구성원들은 심리적으로 위축되고 리스크를 회피하게 된다. 뭐든 지나쳐서 좋을 것은 없지만, 지나친 의사소통이 낳는 피로감보다 정보를 숨겨서 발생하는 부작용이 훨씬 더 크다는 사실을 명심해야 한다.&lt;/p&gt;
&lt;p&gt;결국 &#39;과대 소통&#39;의 목적은 단순히 의사소통의 양을 늘리는 것이 아니라, 투명한 정보를 바탕으로 팀원의 &lt;strong&gt;자율성과 주도권&lt;/strong&gt;(Agency)을 이끌어내는 것이다. 필요한 정보가 채워지면 구성원들은 누군가의 지시를 기다리지 않고 현재 상황에서 가장 중요한 일이 무엇인지 스스로 판단하고 자율적으로 움직이기 시작한다. 이것이 바로 성공적인 기술 기업들이 작은 규모의 팀으로도 밀도 높은 성과를 내는 비결이라고 생각한다.&lt;/p&gt;
&lt;p&gt;이 모든 것은 눈치 보지 않고 질문할 수 있는 심리적 안전감이 전제되어야 한다. &#39;오버커뮤니케이션&#39;이 업무를 방해하는 유난스러운 행동이 아니라, 잠재적 리스크의 발견을 위한 프로페셔널한 태도로 인정받는 문화를 만들어야 한다.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;(이어지는 &lt;a href=&quot;https://hoch.io/ko/writing/2026-04-13-5-ideas-for-high-performing-teams-part-2/&quot;&gt;2편&lt;/a&gt;에서는 &lt;strong&gt;비난 없는 실패의 문화&lt;/strong&gt;와, 팀의 독소를 걷어내는 &lt;strong&gt;단호한 원칙&lt;/strong&gt;에 대해 이야기합니다.)&lt;/em&gt;&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>우리는 왜 서로의 빌런이 되었나</title>
    <link href="https://hoch.io/ko/writing/2026-03-16-why-we-become-each-others-villains/"/>
    <updated>2026-03-16T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-03-16-why-we-become-each-others-villains/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-16-why-we-become-each-others-villains/hero.png&quot; alt=&quot;세대차이와 소통 단절로 인한 직장 내 갈등을 표현한 수채화 이미지&quot; /&gt;&lt;/p&gt;
&lt;p&gt;소셜 미디어를 둘러보다 보면 뒷맛이 씁쓸한 글들이 있다. 우연히 마주친 두 편의 글이 유독 그랬다. 겉보기엔 완전히 다른 이야기였지만, 그 뿌리에는 &#39;남 탓&#39;이라는 서늘한 메시지가 깔려 있었다. 본인이 느끼는 불만을 타인 탓으로 돌리는 것은, 어쩌면 치열한 업무 환경 속에서 멘탈관리를 위해 우리 모두가 가진 무의식의 회피 기제가 작동한 결과일지 모른다. 그렇게 함으로써 관계의 실패로부터 홀가분하게 도망칠 수 있기 때문이다. 하지만 그 달콤한 회피는 결국 건강한 조직문화를 해치고 소통의 단절을 가져올 뿐이다. 서로를 &#39;빌런&#39;으로 낙인찍는 이 현상의 진짜 원인은 무엇일까. 우리는 어떻게 해야 이 소모적인 갈등을 해결할 수 있을까?&lt;/p&gt;
&lt;h3&gt;케이스 1: &amp;quot;40대 꼰대들의 특성&amp;quot;&lt;/h3&gt;
&lt;p&gt;링크드인을 둘러보다 40대 이상 &amp;quot;아재&amp;quot;들의 공통점을 분석해놓은 글이 눈에 들어왔다. 그 글은 함께 일하는 40대 남성들을 단점 투성이이자 자신의 커리어를 방해하는 &#39;빌런&#39;으로 묘사하고 있었다. 진지하게 받아들이기에는 지나치게 두서없고 감정적인 글이었다. 소셜 미디어 특유의, 표현의 자유를 핑계 삼은 흔한 감정 배설이려니 하고 넘기려 했다. 하지만 초반에 느꼈던 씁쓸함은 차분히 글을 읽어 내려가자 이내 측은함으로 바뀌었다.&lt;/p&gt;
&lt;p&gt;첫째, 직장인의 소셜 네트워크에서 누군가를 향한 극단적인 조롱과 비난을 여과 없이 포스팅했다는 사실이 놀라웠다. 그것은 자정 작용이 부족한 개인의 미숙함이기도 하겠지만, 한편으로는 경직된 조직문화 내에서 그들의 목소리가 정상적으로 수용되거나 건강하게 해소될 통로가 완벽히 막혀있다는 증거이기도 하다.&lt;/p&gt;
&lt;p&gt;둘째, 직장 내 세대차이로 인해 발생하는 불편함을 특정 세대의 탓으로만 돌려 규정짓는 순간, 남는 것은 관계의 단절뿐이다. &amp;quot;40대는 모두 꼰대고 말이 안 통한다&amp;quot;는 선언은 결국 &amp;quot;나 역시 그들을 이해하기 위해 더 이상 노력하지 않겠다&amp;quot;는 체념의 또 다른 표현이기 때문이다. 관계의 불편함을 남의 탓으로만 돌리면 속은 홀가분할지 몰라도, &lt;strong&gt;결국 그 자신도 &amp;quot;말이 통하지 않는 꼰대&amp;quot;가 되고 마는 것이다.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;셋째, 자신의 커리어에 미칠 치명적인 부작용을 인식하지 못함이 안타까웠다. 공개적인 커리어 플랫폼에 쏟아낸 날 선 비난을 우연히 마주칠 직장 상사나 잠재적인 리크루터들이 그것을 어떻게 평가할지는 뻔한 일이기 때문이다.&lt;/p&gt;
&lt;h3&gt;케이스 2: &amp;quot;왜 다들 나처럼 목숨 걸고 일하지 않지?&amp;quot;&lt;/h3&gt;
&lt;p&gt;소셜 미디어에서 마주친 한 포스트가 며칠 동안 머릿속을 맴돌았다. 어느 스타트업 창업자로 보이는 글쓴이가 &#39;워라밸&#39;을 중시하는 사람들에 대해 원색적인 비난을 토해낸 글이었다. 회사의 성장보다 개인의 안위를 우선시하는 태도를 한심하게 여기는 논조를 읽으며, 나는 강한 거부감과 함께 한편으로 생각에 잠겼다. 도대체 무엇이 이 사람을 이토록 극단적인 사고로 몰아넣었을까. 그의 글 행간에는 쉽게 따라와 주지 않는 조직원들에 대한 상처와 실망감이 배어 있었다.&lt;/p&gt;
&lt;p&gt;그 글을 읽고 난 뒤, 나는 글쓴이에 대해 더 이상 알고 싶지 않다는 생각이 들었다. 혹여나 비즈니스 현장에서 마주치지 않기를 바랄 정도였다. 이는 기업가로서 치명적인 손실이다. 자신의 소신을 뚜렷하게 밝히는 것은 중요하지만, 그 소신이 자신을 따르는 사람들에 대한 비난을 통해서만 밝힐 수 있는 것이라면 결국 리더가 가진 &#39;사회적 자본&#39;은 치명적으로 훼손될 수밖에 없다. 비즈니스 세계에서 평판은 곧 자산이자 생명줄이기 때문이다.&lt;/p&gt;
&lt;p&gt;사람들이 회사 일보다 자신과 가족을 더 소중히 여긴다고 한탄하기 전에, 리더는 스스로에게 근본적인 질문을 던져야 한다. &amp;quot;내가 제시한 목표와 이상이 정말로 그들에게 가치 있는 것인가?&amp;quot; 단 두 사람만 모여도 서로 다른 이상과 목표를 가지는 것이 자연스러운 이치다. 하물며 수십 명이 모여 일하는 조직에서 구성원마다 생각이 다른 것은 너무나 당연하고 피할 수 없는 현실이다. &lt;strong&gt;조직이 다른 가치관을 인정하지 못하고 오히려 비난의 화살을 그 구성원들에게 돌리게 될 때, 조직은 예상치 못한 대가를 치르게 된다.&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;첫째, 회사의 비전이 구성원들을 충분히 매료시키지 못했다는 아픈 실패를 드러내는 결과가 된다.&lt;/li&gt;
&lt;li&gt;둘째, 뜻을 달리하는 사람들은 조직을 떠나야 한다는 배타적인 메시지를 던지는 것이다. 이렇게 떠난 사람들은 어떤 이야기를 하고 다닐까?&lt;/li&gt;
&lt;li&gt;셋째, 조직에 남은 사람들조차 입을 닫고 마음의 문을 걸어 잠그게 된다. 리더의 극단적인 잣대 앞에서 구성원들은 더 이상 회사의 비전에 자신을 동기화하려 애쓰지 않는다. 그저 리더의 눈에 거슬리지 않는 최소한의 역할만 수행하는 &#39;유령 같은 존재&#39;가 되어버릴 뿐이다.&lt;/li&gt;
&lt;li&gt;넷째, 맹목적인 추종자들은 리더의 잘못된 패턴을 답습한다. 자신들의 의견과 다른 동료들을 리더가 했던 것처럼 비난하고 공격하게 되며, 이는 조직 문화 전체를 병들게 만든다.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;스타트업 특유의 절박함은 충분히 이해가 되지만, 구성원 각자의 삶의 무게와 우선순위를 탓하는 데 에너지를 쏟는 것은 문제 해결에 큰 도움이 되지 않는다. 리더십의 역량은 자신의 방향과 속도에 맞추지 못하는 이들을 다그치는 것이 아니라, 회사의 비전이 어떻게 그들의 삶과 연결될 수 있는지 끈질기게 설득하고 영감을 불어넣는 것이라 생각한다.&lt;/p&gt;
&lt;h3&gt;반응보다는 성찰 후 행동을&lt;/h3&gt;
&lt;p&gt;&amp;quot;꼰대는 답이 없다&amp;quot;거나 &amp;quot;요즘 애들은 열정이 없다&amp;quot;는 불평은 시공간을 초월하는 레퍼토리다. 블로그 포스트 한두 개로 해결될 문제는 애초에 아니었다. 하지만 의외로 해결방법은 간단하다. &lt;strong&gt;결국 답은 그 흔해 빠진 &#39;공감&#39;이다.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;먼저, 40대 동료들을 향해 날 선 비판을 쏟아냈던 첫 번째 글의 저자를 떠올려 본다. 어쩌면 그들은 지금까지의 커리어 동안 자신을 진정으로 아껴주고 소통하려 노력하는 대상, 즉 &#39;기댈 수 있는 어른&#39;을 조직 내에서 마주하지 못했을지도 모른다. 돌이켜 보면 내 커리어에서 얻은 가장 큰 기쁨 역시 예기치 못한 순간에 세대차이를 넘어 나의 미숙함을 기꺼이 품어준 인생 선배들을 알게 되었을 때였다.&lt;/p&gt;
&lt;p&gt;다음으로, 자신과 결이 다른 구성원들을 한심하게 여겼던 두 번째 글의 창업자를 떠올려 본다. 사실 나는 &#39;영웅적 희생&#39;을 미화하는 성공담을 좋아하지 않는다. (그 이유는 다음 글에서 설명할 계획이다) 그 위험한 동경과 신기루가 한국 사회와 조직 문화를 병들게 한 주범 중 하나라고 생각하기 때문이다. 하지만 리더라는 위치는 영웅적인 희생까지는 아니더라도 깊은 인내를 요구한다. 하고 싶은 말이 목 끝까지 차오르더라도 나를 믿고 따르는 사람들을 위해 한 번 더 통찰하고, 한 번 더 공감하며, 기꺼이 인내해 내는 것. 그것이 진짜 리더의 모습이 아닐까.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;우리의 커리어는 누군가를 꼰대라고 선을 긋거나, 자신을 따르지 않는다고 이기적이라고 비난하며 엇나간 증오로 채우기엔 너무 귀하고 짧다.&lt;/strong&gt; 이해할 수 없는 다름을 마주했을 때 즉각적으로 날 선 반응(React)을 보이기보다, 잠시 멈춰 한 번 더 성찰 후 행동(Reflect and Act)할 수 있는 여유와 지혜가 모두에게 조금 더 필요하지 않을까.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>갈등 통역기</title>
    <link href="https://hoch.io/ko/writing/2026-03-02-conflict-translator/"/>
    <updated>2026-03-02T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-03-02-conflict-translator/</id>
    <content type="html">&lt;p class=&quot;footnote&quot;&gt;* 본문에 등장하는 사례는 여러 실제 사례를 바탕으로 재구성된 것입니다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-02-conflict-translator/hero.png&quot; alt=&quot;&amp;quot;드라마없는 오피스는 없다&amp;quot;&quot; /&gt;&lt;/p&gt;
&lt;p class=&quot;caption&quot;&gt;드라마없는 오피스는 없다&lt;/p&gt;
&lt;h3&gt;대나무 숲인가, 트러블슈팅인가&lt;/h3&gt;
&lt;p&gt;어느 나른한 오후, 화상 회의실에 입장하자마자 공기가 무겁다. 화면 너머 팀원의 눈에 잔뜩 힘이 들어가 있다. 얼굴은 붉게 상기되어 있고, 억지로 평정심을 유지하려는 입가에는 미세한 떨림이 감지된다. 마음속 깊은 곳에서 감정의 소용돌이가 치고 올라오고 있음이 직감적으로 느껴진다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;그 사람과 더 이상 일할 수 없을 것 같아요. 이 프로젝트에서 빠지고 싶어요...&amp;quot;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;예상대로다. 봇물 터지듯 쏟아지는 한풀이는 끝날 줄 모르고 이어진다. 매니저로서 팀원의 고충을 들어주는 것은 가장 중요한 책임 중 하나다. 때로는 들어주는 것만으로도 문제가 해결되기에, 일단은 충분히 감정을 쏟아낼 시간을 주는 것이 효과적이다.&lt;/p&gt;
&lt;p&gt;하지만 우리에게 주어진 시간은 보통 30분 남짓이다. 미팅 시간이 절반 정도 남은 즈음 결정을 내려야 한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&amp;quot;오늘의 1:1은 감정을 받아내는 &#39;대나무 숲&#39;인가, 아니면 문제를 해결하는 &#39;트러블슈팅&#39;인가?&amp;quot;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;만약 전자로 결론 내렸다면, 공감하고 위로하는 것만으로 충분하다. 하지만 팀원이 계속되는 갈등 상황을 문제로 보고 해결을 원한다면, 이야기는 달라진다. 이때 매니저는 감정의 소용돌이 속에서 객관적인 팩트를 발라내는 &#39;&lt;strong&gt;통역사&lt;/strong&gt;&#39;가 되어야 한다. 이 얽히고설킨 갈등의 실타래를 어떻게 빠르게 풀 수 있을까?&lt;/p&gt;
&lt;h3&gt;SBI 프레임워크&lt;/h3&gt;
&lt;p&gt;사람들 사이의 갈등을 둘러싼 &amp;quot;네 말 내 말&amp;quot;들은 결코 객관적이지 않다. 자신의 일에는 누구나 주관적이 될 수밖에 없기 때문이다. 이때 감정의 소용돌이 속에서 한 발짝 물러나, 마치 제3자가 CCTV를 판독하듯 냉정하게 갈등을 해체할 때 사용할 수 있는 도구가 바로 &lt;a href=&quot;https://www.ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;SBI 프레임워크&lt;/a&gt;다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-03-02-conflict-translator/sbi-table.png&quot; alt=&quot;SBI 프레임워크&quot; /&gt;&lt;/p&gt;
&lt;p&gt;갈등을 이 세 가지의 레이어로 분해해내는 일은 직장 내 갈등뿐만 아니라, 일상생활의 미세한 마찰을 풀어내는 데에도 효과적으로 쓰일 수 있다. 가족 혹은 친구 간의 다툼을 예로 들면, &amp;quot;너는 내 말은 듣지를 않아!&amp;quot;라고 쏘아붙이는 대신, 이 프레임워크를 통과시키면 이렇게 번역된다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;어제 저녁 먹을때(상황), 내가 말할 때 네가 세 번이나 말을 끊고 핸드폰만 보더라(행동). 그래서 내 말이 무시당하는 것 같아 기분이 많이 상했어(영향).&amp;quot;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;이쯤에서 눈치 빠른 분들은 알아챘겠지만, 이 프레임워크의 결과물에는 상대방에 대한 비난과 요구는 없다. &amp;quot;그래서 니 잘못이야&amp;quot;가 아니라 &amp;quot;내 기분이 상했어&amp;quot;가 메시지의 핵심이다. 이것은 상대를 비난하고 이겨서 대화를 끝내는 것이 목적이 아니라, 문제점을 함께 이야기하고 해결책을 찾기 위한 대화의 문을 여는 도구라는 점을 강조하고 싶다.&lt;/p&gt;
&lt;h3&gt;감정 속에서 팩트 찾기&lt;/h3&gt;
&lt;p&gt;다시 화상 회의실로 돌아와 팀원이 쏟아낸 토로를 정리해본다.&lt;/p&gt;
&lt;p&gt;30분간 팽팽한 감정의 덩어리를 듣고 나면 당장 해줄 수 있는 건 위로뿐인 듯하다. 무엇이 팩트이고, 누가 무슨 행동을 했으며, 어떤 결과가 발생했는지 직관적으로 파악하기 어렵기 때문이다. 하지만 머릿속에 빙빙 도는 말들을 SBI라는 프리즘에 통과시켜 살펴보면 감정의 안개는 좀 더 걷혀나간다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;상황:&lt;/strong&gt; 두 팀이 진행 중인 프로젝트에서, 두 사람이 각 팀을 대표해 수개월째 협업을 해왔음.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&amp;quot;상황&amp;quot;은 객관적일 수밖에 없다. 벌어진 상황은 변하지 않기 때문이다. 여기서 상황에 대한 개인의 의견을 피력하거나 해석을 덧붙인다면 객관성을 잃게 된다.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;행동:&lt;/strong&gt; 빠른 진행을 위해 다른 팀의 팀원이 특정 절차를 무시할 것을 요구했으며, 협업 기간 내내 코드 리뷰 및 공유문서에서 무시 및 폄하하는 언행과 태도를 보임.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&amp;quot;행동&amp;quot;은 상황 안에 등장하는 당사자들의 행위에 대한 면밀한 관찰이다. 이 역시 부정할 수 없는 사실로 구성되어야 그 가치가 있다. 실제로 검증된 근거가 존재하는 사실만 포함시키고, 감정적, 주관적 해석은 배제되어야 한다.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;영향:&lt;/strong&gt; 우리 팀원은 극심한 스트레스로 퇴사까지 고려 중이며, 현재 양 팀의 협업 기능 상실로 프로덕트 출시 일정의 목표 달성이 불가능해짐.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&amp;quot;영향&amp;quot;에서는 위의 행동 때문에 발생한 개인 혹은 조직의 피해에 대해 서술한다. 주관적 감정이나 비즈니스적 파급력은 해석하기 나름이라 여길 수 있지만, &#39;상대방의 행동으로 인해 우리 팀원이 업무 의욕을 상실했다는 것&#39; 자체는 핵심 논제로 다뤄져야 한다.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;이렇게 정제된 상황, 행동, 영향은 양 팀의 매니저들 사이에 공유되고 교정을 거쳐 최종 해결책을 만드는데 사용되었다. 중요한 것은 이 프레임워크가 누군가를 방어하거나 비난하기 위한 것이 아니라, 그저 &#39;비즈니스에 부정적인 영향을 주는 행동 패턴&#39;을 찾아내고 바로잡기 위해 논의를 진전시킬 수 있었다는 점이다.&lt;/p&gt;
&lt;h3&gt;드라마 없는 엔딩&lt;/h3&gt;
&lt;p&gt;조직 내 갈등이 한 편의 휴먼 드라마처럼 눈물겨운 화해로 봉합되는 일은 드물다. 이 사태의 결말 역시 서로를 껴안고 끝나는 극적인 해피엔딩은 아니었다.&lt;/p&gt;
&lt;p&gt;갈등의 당사자들은 각자의 본래 역할로 돌아가 거리를 두었고, 직접적인 마찰의 여지는 시스템과 프로세스를 통해 분리되었다. 누군가가 나서서 악당을 무찌르고 구원하는 식의 영웅주의적 담판은 없었다. 그저 &#39;객관적인 도구&#39;가 갈등의 벽을 허물고 팩트를 직시하게 만들었을 뿐이다.&lt;/p&gt;
&lt;p&gt;이후 해당 팀원의 1:1 미팅에서는 흥미로운 변화가 엿보였다. 그 팀원은 SBI 프레임워크를 통해 분노와 억울함에 매몰되어 있던 자신을 한 걸음 떨어져서 바라보게 되었다고 했다. 갈등 상황을 맞닥뜨려도 무력하게 휩쓸리지 않고, &amp;quot;이 상황(S)에서 저 행동(B)이 나에게 어떤 영향(I)을 미치고 있는가?&amp;quot;를 스스로 묻는 단단함을 갖게 되었다고 했다. 실제로 이전에는 무례한 태도 앞에서 쉽게 흔들리거나 감정적으로 되받아 쳤다면, 이제는 상대의 행동과 자신의 감정을 분리해서 대처하는 여유를 보였다.&lt;/p&gt;
&lt;h3&gt;만병통치약이 아닌 나침반&lt;/h3&gt;
&lt;p&gt;우리가 이 프레임워크를 사용하는 이유는 이것이 갈등 해소를 위한 만병통치약이라서가 아니다. 당사자들이 인내심을 갖고 대처하거나 시간이 충분히 흐르면 웬만한 갈등은 자연스럽게 소멸하기 마련이다. 필자는 이 방법이 주는 가장 큰 가치는 &lt;strong&gt;불필요한 감정 소비와 기회비용을 줄여준다&lt;/strong&gt;는 데 있다고 생각한다.&lt;/p&gt;
&lt;p&gt;&amp;quot;어떡해야 하지?&amp;quot; 하는 막막함 속에 며칠을 속 끓이며 방황하기보다, 정해진 틀에 맞춰 기계적으로 상황을 분해하다 보면 감정에 가려져 있던 본질이 의외로 선명하게 드러난다. 나아가 &amp;quot;니말 내말&amp;quot; 식의 소모적인 공방으로 시간을 낭비하는 대신, SBI를 거쳐 정제된 내용들은 문제 해결을 향한 대화의 나침반이 되어준다.&lt;/p&gt;
&lt;p&gt;이 나침반에 익숙해진다면 직장 내의 팽팽한 신경전은 물론, 일상 속의 크고 작은 오해 앞에서도 한결 여유를 가질 수 있게 된다. 감정의 파도 속에서도 팩트라는 단단한 땅을 디디고 서서, 상대를 향해 칼날을 겨누기보다 문제 해결에 집중하는 것. 그것이 나 자신과 우리의 관계를 보호하는 가장 정교하고 다정한 통역일 것이다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>비욘드 코딩</title>
    <link href="https://hoch.io/ko/writing/2026-02-16-beyond-coding/"/>
    <updated>2026-02-16T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-02-16-beyond-coding/</id>
    <content type="html">&lt;h3&gt;&lt;strong&gt;&amp;quot;스위는 코딩이지&amp;quot;&lt;/strong&gt;&lt;/h3&gt;
&lt;p&gt;(SWE: Software Engineer. &amp;quot;스위&amp;quot;라고 발음한다.)&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-02-16-beyond-coding/hero.png&quot; alt=&quot;열심히 코딩 중인 &amp;quot;주니어&amp;quot;&quot; /&gt;&lt;/p&gt;
&lt;p&gt;최근 멘토링을 통해 알게 된 주니어 엔지니어 한 명과 캐주얼한 커피챗을 했다. 그는 3년 차로 팀 내 주니어들 중 가장 코딩을 잘하는 유능한 인재였다. 그런데 그는 최근 팀을 지휘하는 테크 리드(Tech Lead)와의 간극에 대해 솔직한 고민을 털어놓았다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;코딩은 자신 있어요. 누구보다 부지런하고 빠르다고 자부합니다. 하지만 테크 리드가 되려면 코딩 이외의 다른 것들도 필요한 것 같은데, 도대체 그걸 어떻게 접근해야 할지 막막해요.&amp;quot;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;그는 이제 정치를 배워야 하는 거냐며 멋쩍은 농담을 건넸다. 그 자리에서 시원한 답을 줄 수 있었으면 좋았겠지만, 내가 생각하는 전부를 쏟아내기에 이십 분 남짓의 커피챗은 너무나 짧았다. 그 질문은 자꾸 머릿속을 맴돌았고, 제대로 정리해 두지 않는다면 다음에 같은 질문을 받았을 때 또다시 공허한 위로로 대화를 마무리하게 될 것 같았다. 그에게, 그리고 비슷한 고민을 하는 이들에게 조금 더 도움이 되는 답변을 남기고 싶어 이 글을 시작했다.&lt;/p&gt;
&lt;p&gt;필자가 직접 경험해 온 소프트웨어 엔지니어링의 세계관은 대략 다음과 같다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-02-16-beyond-coding/diagram.png&quot; alt=&quot;필자의 엔지니어링 세계관&quot; /&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;1. 엔지니어링 스킬 (Engineering Skills)&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;코딩:&lt;/strong&gt; 코드 작성, 코드 리뷰 등.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;비코딩(Non-coding):&lt;/strong&gt; 아키텍처 디자인, 문서화, 플래닝, 프로세스, 메트릭 설계 및 분석 등.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;2. 비엔지니어링 스킬 (Non-engineering Skills)&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;인재관리:&lt;/strong&gt; 매니지먼트, 코칭 및 멘토링 등.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;기획 및 전략:&lt;/strong&gt; 조직 내 조율 및 설득, 프로젝트 기획, 로드맵 수립 등.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;비즈니스 및 소통:&lt;/strong&gt; 파트너십 개발 및 관리, 디벨로퍼 릴레이션 등.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;이렇게 전체적인 구조도를 펼쳐 놓고 보면, 코딩은 엔지니어링이라는 거대한 기계를 움직이는 핵심 부품이지만, 그것이 전부는 아니라는 사실을 알 수 있다.&lt;/p&gt;
&lt;p&gt;소프트웨어 엔지니어 래더(Ladder)가 가진 매력 중 하나는, 이 중 어느 영역에 시간을 쓰든 확실한 결과와 임팩트만 만들어낸다면 그 가치를 인정받는다는 점이다. 팀의 구성과 상황은 늘 유동적이기 때문에, 테크 리드나 엔지니어링 매니저에게 코딩 이상의 업무가 주어지는 상황은 지극히 자연스럽고, 때로는 필수적이다.&lt;/p&gt;
&lt;p&gt;결국 &amp;quot;스위는 코딩이지&amp;quot;라는 말은 절반의 진실일 뿐, 전체를 대변하지는 못한다. 지금까지 그래왔고, 앞으로 펼쳐질 환경에서는 더욱 그럴 것이다.&lt;/p&gt;
&lt;h3&gt;&lt;strong&gt;코딩, 그 이상을 향하여&lt;/strong&gt;&lt;/h3&gt;
&lt;p&gt;앞서 이야기했듯이 소프트웨어 엔지니어의 업무 영역은 연차가 쌓이고 영향력이 커짐에 따라 단순히 코드 작성에 머물지 않게 된다. 엔지니어링 팀에서 두각을 나타내며 동료들을 이끄는 리더들을 보면, 다음과 같은 스킬 셋이 다각도로 발달해 있음을 발견할 수 있다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;1. 비코딩 스킬 (Non-coding Skills)&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;비코딩 업무란 코드 작성을 제외한 모든 엔지니어링 행위를 뜻한다. 구글에서 &#39;시니어&#39; 타이틀을 달기 위해서는 최소한 한 가지 이상의 비코딩 스킬 영역에서 전문가 수준의 역량을 보여주기를 기대한다. 자주 거론되는 비코딩 스킬로는 시스템의 복잡도를 낮추는 &lt;strong&gt;아키텍처 디자인&lt;/strong&gt;, 우선순위를 정해 한정된 자원을 배분하는 &lt;strong&gt;플래닝&lt;/strong&gt;, 고품질 문서화로 협업 효율을 높이는 &lt;strong&gt;테크니컬 라이팅&lt;/strong&gt;, 그리고 &lt;strong&gt;메트릭 설계 및 분석&lt;/strong&gt;을 통한 성과 증명 등이 있다.&lt;/p&gt;
&lt;p&gt;이들이 중요한 이유는 우리가 하는 일이 단순 &#39;프로그래밍&#39;이 아닌 &#39;&lt;strong&gt;엔지니어링&lt;/strong&gt;&#39;이기 때문이다. 단순한 코드 작성과 실행이 아닌, &lt;strong&gt;시간&lt;/strong&gt;과 &lt;strong&gt;규모&lt;/strong&gt;의 축 위에서 지속 가능한 서비스와 프로덕트를 만드는 것. 비코딩 업무를 소홀히 한 대가는 기술 부채(Technical Debt)로 돌아와 팀의 속도를 서서히 잠식한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;2. 비엔지니어링 스킬 (Non-engineering Skills)&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;비엔지니어링 업무는 기술 밖의 영역, 주로 프로젝트의 &#39;&lt;strong&gt;정당성(Why)&lt;/strong&gt;&#39;을 증명하는 일이다. 잘 짜인 &lt;strong&gt;로드맵&lt;/strong&gt;으로 리더십을 설득하고, &lt;strong&gt;자원과 헤드카운트&lt;/strong&gt;를 확보하며, 다른 팀과의 &lt;strong&gt;정치적 조율&lt;/strong&gt;을 통해 협업을 이끌어내는 과정이다.&lt;/p&gt;
&lt;p&gt;이는 기술적 해결책을 찾는 것을 넘어, 해결해야 할 가치 있는 문제를 정의하고 이를 풀기 위한 사람들을 모으는 행위다. 불확실성이 높지만, 이 모호함을 돌파할 때 엔지니어는 기술 이상의 가치를 만드는 사람이라는 대체 불가능한 힘을 갖게 된다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-02-16-beyond-coding/tweet.png&quot; alt=&quot;2019년, 처음으로 비엔지니어링 스킬의 중요성을 깨달은 순간&quot; /&gt;&lt;/p&gt;
&lt;p&gt;과거에는 이러한 비엔지니어링 역량의 확장이 리더로서 성장하기 위한 &amp;quot;추가적인&amp;quot; 선택지였을지도 모른다. 그런 것 없이 코딩만 장인처럼 잘해도 대우받던 시절이 있었으니까. 하지만 2026년 현재, 코딩 이상의 스킬 셋을 만들어가는 것은 선택을 넘어 생존을 위한 필수 조건이 되어가고 있다. 우리가 그토록 자부하던 코딩의 영역을 AI가 놀라운 속도로 대체하고 있기 때문이다.&lt;/p&gt;
&lt;h3&gt;&lt;strong&gt;코딩의 종말과 엔지니어링의 부상&lt;/strong&gt;&lt;/h3&gt;
&lt;p&gt;필자에게 모든 AI 관련 글들은 리스크 가득한 주식과 같다. 어렵게 써 내려간 글이 6개월 뒤에 휴지 조각이 될지, 신통한 예측이 될지 정말 알 수가 없기 때문이다. 그럼에도 이 이야기를 꺼내는 이유는, 변화의 파도가 너무나 거대하기 때문이다. 적어도 구글 내에서, 그리고 실리콘밸리의 많은 엔지니어들이 공감하는 한 가지는, 2026년 이후의 소프트웨어 엔지니어링은 지금과 많이 다를 것이라는 점이다. 나 역시 이 의견에 깊이 동의한다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;코딩은 거의 끝났다. 하지만 엔지니어링은 그 어느 때보다 살아있다.&amp;quot;
(Coding is pretty much dead, but the engineering is very much not.)&lt;/p&gt;
&lt;p&gt;— Martin Casado (a16z)&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;2026년, CS 전공자들이 일자리를 찾는 데 어려움을 겪는 이유도 바로 이 차이 때문일 것이다. 코딩과 엔지니어링은 다르지만, 학교에서는 현장의 진짜 엔지니어링을 가르치기 어렵기 때문이다. (현업과 교육 현장의 차이는 어쩔 수 없는 부분이기도 하다. 아직도 한 발을 학교에 딛고 있는 한 사람으로 그 현실적인 상황을 충분히 이해한다.)&lt;/p&gt;
&lt;p&gt;코드는 문맥이 명확하고 검증이 가능하기에 AI 에이전트들이 활약하기 가장 좋은 영역이다. 그렇다면 비코딩 스킬은 안전할까? 꼭 그렇지는 않다. 테크니컬 라이팅, 프로세스 관리 및 설계 등도 AI가 빠르게 침범하고 있다. 하지만 결정적인 차이는, 비코딩 영역의 결과물은 단순 생성을 넘어 사람 간의 합의와 책임을 필요로 한다는 점이다. 정답이 없는 모호한 문제, 결과에 대한 &amp;quot;책임자&amp;quot;가 필요한 업무. 이는 AI가 독자적으로 수행하기 가장 어려운 영역이자, 우리 인간 엔지니어의 존재 이유가 된다.&lt;/p&gt;
&lt;p&gt;비엔지니어링 스킬은 더 말할 것도 없다. 이는 코드 주변의, 혹은 코드와 동떨어진 &#39;세상만사&#39;의 복잡한 맥락 속에 존재한다. 시니어 엔지니어의 역할은 이제 챗봇의 코드를 복사해 붙이는 것을 넘어, AI가 최적의 결과를 내도록 비즈니스 로직과 프로젝트 정보를 설계하는 &#39;&lt;strong&gt;콘텍스트 엔지니어링(Context Engineering)&lt;/strong&gt;&#39;과 &#39;&lt;strong&gt;어젠틱 시스템 디자인(Agentic System Design)&lt;/strong&gt;&#39;으로 확장되고 있다.&lt;/p&gt;
&lt;p&gt;10년 전에는 주니어 시절 3~4년 정도 코딩에만 몰두하며 성장할 수 있는 시간이 주어졌었다. 하지만 이제 커리어의 출발선 자체가 흔들리고 있다. 마치 모든 엔지니어의 시작점이 &#39;&lt;strong&gt;강제 승진&lt;/strong&gt;&#39;된 시니어 레벨로 바뀐 느낌이다.&lt;/p&gt;
&lt;p&gt;이러한 2026년의 현실에서 취업의 확률을 높일 수 있는 방법은 본인이 이러한 코딩, 비코딩, 비엔지니어링 스킬들을 다양하게 골고루 갖추는 것이다. 하지만, 아이러니하게도 제대로 된 엔지니어링 팀에서 일해보지 않고서 이 다양한 스킬들을 배우기는 결코 쉽지 않다. 이 닭과 달걀의 문제가 바로 현재 취업 시장에서 가장 골치 아픈 부분이다.&lt;/p&gt;
&lt;p&gt;여유가 있는 회사들이야 여전히 주니어들에게 시간을 주고 성장할 수 있는 환경을 어떻게든 만들어 주겠지만, 대부분의 회사들은 이미 주니어 레벨에서부터 AI-네이티브인 엔지니어들을 선호할 수밖에 없을 것이다. 좀 편하게 살자고 만들어 낸 AI가 결국 구직 전선에 뛰어든 주니어 엔지니어들에게 새로운 스킬 셋을 배울 수밖에 없도록 밀어내고 있는 것이다.&lt;/p&gt;
&lt;h3&gt;&lt;strong&gt;나가며: 2026년의 주니어들에게&lt;/strong&gt;&lt;/h3&gt;
&lt;p&gt;내 맘속에 작은 소용돌이를 남겼던 그 짧은 커피챗. 아직도 정리가 더 필요하겠지만, 필자가 조언을 구하는 후배들에게 전하고 싶은 핵심은 소프트웨어 엔지니어로서 진정한 성장을 원한다면 &amp;quot;&lt;strong&gt;코딩 그 이상&lt;/strong&gt;&amp;quot;을 바라보았으면 한다는 것이다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;첫째, 코딩 너머의 영역에 관심을 가져보자.&lt;/strong&gt; &amp;quot;코딩이 아니니까 내 일이 아니야&amp;quot;라로 벽을 쌓기보다, 유연한 마음가짐으로 다양한 영역에 뛰어들어 기회를 찾아보면 어떨까. 그 경험들이 쌓여 당신을 대체 불가능한 존재로 만들어 줄 것이다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;둘째, AI를 진정한 파트너로.&lt;/strong&gt; 새로운 스킬을 익히는 과정은 쉽지 않고, 예전만큼의 여유 시간도 주어지지 않는다. 다행히 우리에겐 AI라는 강력한 조력자가 있다. AI 도구들을 학습과 개발에 적극적으로 활용해 복리 효과(Compounding Effect)를 누렸으면 한다. 모든 업무의 시작과 끝에 AI를 두고, 진정한 &#39;AI 네이티브 엔지니어&#39;를 목표로 삼는다면 위기는 기회가 될 것이다.&lt;/p&gt;
&lt;p&gt;엔지니어링의 본질은 결국 문제 해결과 가치 창출이다. 근사하게 작성된 코드가 실제 사용자가 누릴 수 있는 가치로 연결될 때 비로소 의미를 갖는다. 그리고 코딩 이외의 수많은 스킬들이 바로 그 연결을 가능하게 만든다.&lt;/p&gt;
&lt;p&gt;당신이 그 연결을 만들어내는 엔지니어가 되기를, 그래서 다가올 10년을 당신의 것으로 만들기를 진심으로 응원한다.&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>세상에서 가장 좁은 감옥</title>
    <link href="https://hoch.io/ko/writing/2026-02-03-the-narrowest-prison/"/>
    <updated>2026-02-03T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-02-03-the-narrowest-prison/</id>
    <content type="html">&lt;blockquote&gt;
&lt;p&gt;The only constant is change.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;이십 대의 나는 &amp;quot;내가 뭘 해야 하지?&amp;quot;라는 생각을 해본 적이 없다.&lt;/p&gt;
&lt;p&gt;얼핏 들으면 주변 시선에 흔들리지 않는 뚝심 있는 사람처럼 보였을지도 모른다. 실제로 당시의 나는 내게 미래를 내다보는 혜안이 있다고 믿었고, 그 확신 하나로 거침없이 나아갔다. 하지만 이제 와서 돌이켜보면 그것은 특별한 혜안이 있어서가 아니었다. 나는 &lt;strong&gt;&#39;자기 확신&#39;이라는 세상에서 가장 좁은 감옥&lt;/strong&gt;에 스스로를 가두고 있었을 뿐이다. 콘크리트처럼 굳어버린 그 마음 탓에 얼마나 많은 기회를 흘려보냈는지, 그때는 미처 알지 못했다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-02-03-the-narrowest-prison/hero.jpg&quot; alt=&quot;언제든 일어나서 나갈 수 있는 &amp;quot;세상에서 가장 좁은 감옥&amp;quot;&quot; /&gt;&lt;/p&gt;
&lt;p&gt;남들과 다른 생각, 다른 인생 경로가 주는 불편함을 견디기 힘들었던 나는 사람들을 멀리했다. 그리고 그 고립을 은근히 즐겼던 것 같다. 고독이 주는 멜랑콜리에 약간의 나르시시즘을 섞어 마시며, 그 불편함을 나의 &#39;우월함&#39;이라고 착각했다. 묵묵히 혼자 실력을 갈고닦으면 언젠가 영화처럼 누군가 나를 알아봐 주리라는 유치한 희망도 품고 있었다.&lt;/p&gt;
&lt;p&gt;하지만 지금 내 이십 대와 같은 삶의 방식을 고수하려는 젊은 친구들을 본다면, 아니 타임머신을 타고 과거의 나에게 돌아갈 수 있다면 도시락을 싸 들고 다니며 이렇게 말해주고 싶다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&amp;quot;제발, 그 무거운 고집 좀 내려놓으라고.&amp;quot;&lt;/strong&gt;&lt;/p&gt;
&lt;h3&gt;깊이보다 넓이를, 독학보다 멘토를&lt;/h3&gt;
&lt;p&gt;너무 이른 나이에 자신의 미래를 확신하고 콘크리트를 붓는 것은 꽤 위험한 도박일 수 있다. 적어도 20대만큼은 깊이(Depth)보다는 &lt;strong&gt;넓이(Breadth)&lt;/strong&gt;를 탐색하는 데 집중하는 것이 더 낫지 않을까?&lt;/p&gt;
&lt;p&gt;David Epstein이 그의 책 &lt;a href=&quot;https://davidepstein.com/range/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&amp;lt;Range&amp;gt;&lt;/a&gt;에서 강조했듯, 커리어 초반에는 다양한 분야를 맛보는 &lt;strong&gt;샘플링 기간(Sampling Period)&lt;/strong&gt;이 필요하다. 스물두 살에 &amp;quot;난 내 목표가 확실해. 내 인생은 이거야&amp;quot;라고 단언한다면, 그건 당신이 천재라서가 아니라 아직 자신이 누구인지, 세상에 무엇이 있는지 충분히 탐색해 보지 못했기 때문일 확률이 높다.&lt;/p&gt;
&lt;p&gt;이 과정에서 가장 가성비 좋은 전략은 혼자가 아닌 &lt;strong&gt;가이드&lt;/strong&gt;와 함께하는 것이다. 무작정 한 분야에 뛰어들어 5년을 허비하고 뒤늦게 방향을 트는 것과, 1년 동안 5명의 멘토를 만나 그들의 경험을 빌려 가능성 높은 분야를 추려낸 뒤 4년을 집중 투자하는 것. 어느 쪽이 더 효율적인 선택일까?&lt;/p&gt;
&lt;p&gt;좋은 멘토는 낯선 여행지의 베테랑 가이드와 같다. 그들이 걸어온 길의 지도를 펼쳐 보이는 순간, 우리는 수많은 시행착오를 건너뛸 수 있다. 멘토라는 거인의 어깨 위에서 세상의 넓이를 충분히 체감해 보자. 비로소 더 좋은 출발점에서, 제대로 된 방향으로 전력 질주할 수 있게 된다. 20대 중반에서 30대 초반, 바로 그때가 질주할 타이밍이다.&lt;/p&gt;
&lt;p&gt;&amp;quot;내 주변에는 그런 사람이 없는데...&amp;quot; 나도 그렇게 생각했다. 하지만 지금은 초연결의 시대다. 마음만 먹으면 누구에게나 닿을 수 있다. 여기서 팁 하나. 다짜고짜 &amp;quot;저의 스승이 되어주십시오&amp;quot;라고 하는 것보다, 대신 구체적인 고민을 들고 &lt;strong&gt;조언&lt;/strong&gt;을 구하는 편이 훨씬 효과적이다. 사람들은 조언을 구하는 이에게 기꺼이 자신의 지혜를 빌려준다.&lt;/p&gt;
&lt;p&gt;거절을 두려워 말고 용기 내어 문을 두드려보자. 그 수많은 문 중에서 하나가 열리는 순간, 당신의 세상은 걷잡을 수 없이 넓어질지도 모른다.&lt;/p&gt;
&lt;h3&gt;파레토의 법칙과 커리어 레버리지&lt;/h3&gt;
&lt;p&gt;고집을 내려놓기로 마음먹었다면, 이제는 &#39;어떻게&#39;가 문제다. 한정된 시간과 에너지를 어떻게 배분해야 가장 효율적일까? 나는 여기서 &lt;strong&gt;&lt;a href=&quot;https://en.wikipedia.org/wiki/Pareto_principle&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;&#39;파레토의 법칙(80/20 Rule)&#39;&lt;/a&gt;&lt;/strong&gt;을 슬쩍 빌려본다.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-02-03-the-narrowest-prison/pareto.png&quot; alt=&quot;20%가 80%이 되는 마법 - 파레토의 법칙&quot; /&gt;&lt;/p&gt;
&lt;p&gt;파레토의 법칙은 20%의 원인이 결과의 80%와 연관이 있다는 관찰에서 출발한다. 이 (아무 데나 적용해도 그럴듯하게 들리는) 원칙을 커리어 개발에 적용하면 이렇게 해석할 수 있다. &lt;strong&gt;본인이 가진 에너지의 20%를 앞으로의 성장을 위해 투자하는 것만으로도 넘치거나 부족하지 않다는 것.&lt;/strong&gt; 즉, 이 20%의 전략적 선택이 80% 만큼의 이득은 아니더라도 투자한 것 이상의 결과를 가져올 수도 있다는 계산이다.&lt;/p&gt;
&lt;p&gt;물론 이 결정적인 20%가 무엇인가는 커리어 영역마다 다를 것이다. 소프트웨어 엔지니어를 예로 들어보자.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;20대라면&lt;/strong&gt;: 이 결정적 20%를 &lt;strong&gt;&#39;경험의 넓이&#39;&lt;/strong&gt;를 확보하는 데 써보는 건 어떨까? 다양한 시도를 통해 &lt;strong&gt;나에게 딱 맞는 도메인&lt;/strong&gt;이 무엇인지 찾아내는 것을 목표로 삼아보자. 여러 사회적 서클에 발을 담그고, 여러 곳을 여행하며, 멘토들을 포함한 다양한 사람들을 만나보는 것이다. 이것저것 찔러보는 것이 낭비 같지만, 사실은 평생을 걸고 파고들 20%의 적성을 발견하기 위한 가장 빠른 지름길일 수 있다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;30대라면:&lt;/strong&gt; 20대에 발견한 그 적성에 에너지를 집중 투자하는 것이 현명하다. 선택과 집중을 통해 자신의 도메인에서 알려진 &amp;quot;능력자&amp;quot;가 되는 것, 바로 &lt;strong&gt;&#39;깊이&#39;&lt;/strong&gt;가 승부처다. 나머지 20%는 전략적인 네트워킹을 통해 이직, 사이드 프로젝트 혹은 새로운 배움으로 이어질 수 있는 기회의 문을 열어두는 데 사용하는 것을 추천한다. 테크 이벤트, 디벨로퍼 밋업, 학술 콘퍼런스 등의 참여가 좋은 예이다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;40대라면:&lt;/strong&gt; 대부분의 에너지는 축적된 실력을 바탕으로 본인의 &lt;strong&gt;영향력(Influence)&lt;/strong&gt;과 임팩트의 &lt;strong&gt;규모(Scale)&lt;/strong&gt;를 키우는 데 집중하게 될 것이다. 그리고 남은 에너지 20%는 후배 양성과 멘토링에 투자해 보자. 내가 가진 노하우를 나눔으로써 타인의 성장을 돕는 것은, 역설적으로 나의 영향력을 극대화하는 가장 강력한 레버리지다. 당신의 코드 한 줄보다, 당신이 유기적으로 엮어낸 팀의 분위기가 조직 전체의 생산성을 끌어올리는 보이지 않는 손이 된다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;내가 코딩 안 하고 이런 엉뚱한 데 시간을 써도 되나?&amp;quot;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;정해진 원칙 없이 맨몸으로 이 과정을 겪으며 가장 힘들었던 건 다름 아닌 &lt;strong&gt;정체성의 혼란&lt;/strong&gt;이었다. 하루가 멀다 하고 수시로 찾아오는 의구심이 나를 괴롭혔다. 당장 괄목할만한 성과가 보이지 않더라도, 이 20%의 투자가 언젠가 나를 더 큰 세상으로 이끌어줄 것이라는 믿음. 그 믿음이 있었다면 불필요한 번뇌 없이 하루하루를 더 알차게 보낼 수 있었을 것이다.&lt;/p&gt;
&lt;hr /&gt;
&lt;h3&gt;다시 생각하기 (Rethinking)&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;Yet in a turbulent world, there’s another set of cognitive skills that might matter more:
the ability to rethink and unlearn.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Adam Grant, &amp;lt;Think Again&amp;gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt;급변하는 세상에서 더욱 중요한 것은 단순한 지식보다 그 지식을 끊임없이 의심하고 업데이트하는 능력이다. 절대적인 진리나 영원히 유효한 아이디어는 없다. 변화만이 유일한 불변의 상수이다. 상황이 바뀌고 새로운 데이터가 손에 쥐어진다면, 지체 없이 피벗(Pivot)할 수 있는 유연함이 필요하다.&lt;/p&gt;
&lt;p&gt;마음에 콘크리트를 붓지 않았으면 한다. 그 콘크리트가 굳어버리는 순간, 우리는 더 이상 성장하지 못하는 &#39;꼰대&#39;가 되고 말 테니까. 자신의 믿음을 절대적 사실이 아닌, 언제든 검증하고 수정할 수 있는 가설로 여기는 &#39;과학자적 사고방식&#39;을 가져보는 건 어떨까? 그러면 실패는 더 이상 끝이 아니라, 유의미한 실험 데이터가 되고 관점은 자연스레 바뀔 것이다.&lt;/p&gt;
&lt;p&gt;성인이 되어 처음으로 실패를 맛봤던 스물두 살의 나는, 그것이 내 인생의 종말인 줄 알았다. 성공을 확신했던 나는 날카로운 실패에 마음을 다쳐 꽤 긴 시간을 방황했다. 만약 그때 내 곁에 좋은 가이드가 있었다면, 그 세상에서 가장 좁은 감옥에서 빠져나오는 일은 훨씬 쉬웠을 것이다.&lt;/p&gt;
&lt;p&gt;그때의 내가 지금의 나를 찾아와 조언을 구한다면, 나는 이렇게 말해주고 싶다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;첫째, 성공과 실패는 관점의 문제다&lt;/strong&gt;: &amp;quot;왜 실패라고 단정해? 단순히 뜻대로 되지 않아서? 애석하게도 앞으로 살면서 네 뜻대로 되는 일은 많지 않을 거야. 벌어진 일을 실패라고 단정하고 확신하면 앞으로 나아갈 수 없어. 모든 확신을 가설로 여기고, 그 가설이 틀렸음을 인정하는 순간, 진짜 배움과 성장이 시작되는 거야.&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;둘째, 취약해질 용기를 가져라&lt;/strong&gt;: &amp;quot;완벽할 수 없다는 것. 나 혼자 모든 것을 해낼 수 없다는 사실을 인정하는 것. 취약해질 용기(vulnerability)를 갖는 것이 마인드 셋 전환의 첫걸음이야. 도움을 구하는 것은 부끄러운 일이 아니라, 더 멀리 가기 위한 가장 지혜로운 전략임을 잊지 마.&amp;quot;&lt;/p&gt;
</content>
  </entry>
  
  
  <entry xml:lang="ko">
    <title>영원한 이방인: 음악과 코드 사이에서</title>
    <link href="https://hoch.io/ko/writing/2026-01-21-eternal-outsider-music-and-code/"/>
    <updated>2026-01-21T00:00:00.000Z</updated>
    <id>https://hoch.io/ko/writing/2026-01-21-eternal-outsider-music-and-code/</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;https://hoch.io/media/posts/2026-01-21-eternal-outsider-music-and-code/hero.jpg&quot; alt=&quot;2011년, 첫째와 함께 거닐던 스탠퍼드의 교정&quot; /&gt;&lt;/p&gt;
&lt;h3&gt;1. Intro: 낯선 행성에서의 인사&lt;/h3&gt;
&lt;p&gt;실리콘밸리의 네트워킹 파티, 맥주잔이 부딪히고 뻔한 탐색전이 오갈 때쯤 어김없이 날아오는 질문이 있다.&lt;/p&gt;
&lt;p&gt;&amp;quot;잠깐, 전공이 컴퓨터 음악이라고요?&amp;quot;&lt;/p&gt;
&lt;p&gt;상대방의 눈동자에 의아함이 스친다. &#39;정통 CS(Computer Science)&#39;의 성골들 틈에 낀 이방인을 보는 시선. 처음엔 좀 곤란하고 난처하기도 했지만, 이제는 그 반응을 즐기는 여유가 생겼다. 많은 이들이 밟아온 매끈한 엘리트 코스와 나의 울퉁불퉁한 이력 사이에는, 쉽게 좁혀질 수 없는 &#39;깊은 골짜기&#39;가 존재한다는 사실을 온전히 받아들였기 때문이다.&lt;/p&gt;
&lt;p&gt;2000년대 초반, 전업 뮤지션이 되기 위해 부단히 노력했지만 현실은 냉혹했다. 한동안 대학 강단과 음향 컨설팅을 전전하며 표류하던 시간들. 그 갈증을 채우려 2009년 늦깎이 유학길에 올랐고, &lt;a href=&quot;https://ccrma.stanford.edu/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;스탠퍼드 CCRMA&lt;/a&gt;(컴퓨터 음악 및 음향 연구소)를 거쳐 2014년 구글 크롬 팀에 조인했다. 그렇게 11년. 어느덧 나는 실리콘밸리의 한복판에서 엔지니어링 팀을 이끄는 매니저가 되었다.&lt;/p&gt;
&lt;p&gt;이쯤 되면 독자들의 머릿속엔 물음표가 하나 떠오를 것이다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;음악 하던 사람이 구글에서 엔지니어링을 한다고?&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;이 첫 번째 포스트는 그 물음에 대한 나의 대답이자 생존 기록의 시작이다. 결론부터 말하자면, 나는 역설적이게도 &#39;코딩만 잘하는 사람&#39;이 아니었기에 이곳에서 살아남을 수 있었던 것 같다.&lt;/p&gt;
&lt;h3&gt;2. 탈바꿈: 뮤지션에서 엔지니어로&lt;/h3&gt;
&lt;p&gt;박사 과정 시절, 나는 방목된 소처럼 오직 음악적 &#39;창의성&#39; 하나에만 몰두했다. 코드가 좀 엉망이어도 음향적 결과가 새롭고 신선하면 그만이었다. 하지만 구글은 달랐다. 그곳에는 거대한 시스템과 프로세스, 그리고 메트릭에 대한 냉정한 평가가 최우선이었다.&lt;/p&gt;
&lt;p&gt;(아마도) 세상에서 가장 큰 C++ 오픈소스 프로젝트인 &lt;a href=&quot;https://www.chromium.org/chromium-projects/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;크로미움(Chromium)&lt;/a&gt;에서 월드 클래스 엔지니어들과 함께 코드를 작성하고 리뷰를 주고받는 일은 매일이 천국이자 지옥이었다. 뮤지션으로서의 자유분방한 창의성을 내려놓고, 엔지니어의 엄격한 규율을 배우는 나날이 계속되었다. 그 경험은 완만한 성장 곡선이 아닌 뼈를 깎는 탈바꿈의 시간이었다. 독창성이 지배하던 세상에서 &#39;유지보수가능성(Maintainability)&#39;과 &#39;확장성(Scalability)&#39;의 세계로 강제 이주당한 기분이었다.&lt;/p&gt;
&lt;p&gt;그 고통을 견디게 해 준 것은 역설적이게도 컴퓨터 음악이었다. 내가 작성한 코드가 전 세계 수억 명의 사용자가 쓰는 브라우저 안의 음악도구가 된다는 것. 그 압도적인 &#39;임팩트&#39;와 &#39;스케일&#39;을 체감하며, 나는 비로소 세상을 바라보는 완전히 새로운 &#39;눈&#39;을 뜨게 되었다.&lt;/p&gt;
&lt;h3&gt;3. 뮤직 테크놀로지가 엔지니어링을 만났을 때&lt;/h3&gt;
&lt;p&gt;그렇다면 음악 박사 학위는 쓸모가 없었을까? 반전은 적응기를 마치고 실무 깊숙이 들어갔을 때 일어났다.&lt;/p&gt;
&lt;h4&gt;도메인 지식(Domain Knowledge)의 힘&lt;/h4&gt;
&lt;p&gt;&amp;quot;오디오 엔지니어는 일 년에 한 번씩 &lt;a href=&quot;https://en.wikipedia.org/wiki/Circular_buffer&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;링 버퍼(Ring Buffer)&lt;/a&gt;를 짠다&amp;quot;는 자조 섞인 농담이 있다. 그만큼 기본적이면서도 까다로운 기술이다. 일반적인 소프트웨어 엔지니어들에게는 생소한 블랙박스일지 몰라도, 나에게는 숨 쉬듯 익숙한 모국어 같은 것이었다.&lt;/p&gt;
&lt;p&gt;그 당시 나의 코딩 실력 자체는 시니어들보다 부족했을지 모른다. 하지만 십 년이 넘는 오디오 전문가로서의 도메인 지식 덕에 나는 이 엔지니어링 프로젝트를 왜 해야 하는가, 또한 그 프로젝트의 성공은 어떻게 정의되는가를 본능적으로 알고 있었다. AI가 코딩을 대신해 주는 시대가 올수록 이러한 도메인 지식의 가치는 더욱 커질 것이다. 복잡도가 높지만 도메인 벨류가 낮은 코드의 작성은 AI가 담당하고, 인간은 더 높은 가치 창출에 포커스를 두고 전체적인 프로젝트의 방향을 설정하는 디렉터가 되어야 하기 때문이다.&lt;/p&gt;
&lt;h4&gt;기술을 지배하는 표준을 만들다&lt;/h4&gt;
&lt;p&gt;현재 필자는 음향 관련 웹 표준을 제정하는 &lt;a href=&quot;https://www.w3.org/groups/wg/audio/participants/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;W3C 오디오 워킹 그룹&lt;/a&gt;의 의장을 맡고 있다. 2014년 실무자로 합류해 표준 문서 편집장(Spec Editor)을 거쳤고, 2021년 의장으로 선출되었다. 취임 직후 가장 먼저 착수한 과제는, 그룹의 방향성을 새롭게 정의하는 것이었다.&lt;/p&gt;
&lt;p&gt;순수 CS 전공자가 주류였던 워킹그룹에서 &lt;a href=&quot;https://www.w3.org/TR/webaudio-1.1/&quot; target=&quot;_blank&quot; rel=&quot;noopener noreferrer&quot;&gt;Web Audio API&lt;/a&gt;는 단지 완수해야 할 하나의 &#39;엔지니어링 과제&#39;였다. 그들이 쌓아 올린 디자인은 기능적으로는 빈틈이 없었으나, 뮤지션의 손끝에서 느껴지는 직관과는 미묘한 괴리가 있었다. 나는 그 틈새를 파고들었다. 오랫동안 소리를 다뤄온 사용자로서, 기능 명세서가 아닌 &#39;경험&#39;의 관점에서 API 디자인에 접근했다. 기술과 예술의 경계에 서 있었기에, 남들이 보지 못하는 &#39;감각의 빈틈&#39;을 메울 수 있었던 것이다.&lt;/p&gt;
&lt;p&gt;많은 오디오 프로그래머들이 다시 웹 플랫폼에 기대를 걸고 새로운 앱을 만들어내는 모습을 볼 때마다 생각한다. 나의 이질적인 배경은 약점이 아니라, 오히려 대체 불가능한 자산이었음을.&lt;/p&gt;
&lt;h3&gt;4. 회복탄력성: 상처를 훈장으로&lt;/h3&gt;
&lt;p&gt;많은 사람이 한 회사에서 11년을 다녔다고 하면 &amp;quot;지루하지 않냐&amp;quot;라고 묻는다. 하지만 주니어에서 시니어, 테크 리드, 그리고 매니저로 역할이 바뀌며 매일 새로운 문제를 마주했기에 지루할 틈이 없었다.&lt;/p&gt;
&lt;p&gt;나를 지탱해 준 것은 엄청난 재능이 아니라, 바닥을 쳐본 자만이 가질 수 있는 굳은살, 바로 &lt;strong&gt;회복탄력성(Resilience)&lt;/strong&gt;이었다. 힘들 때마다 나는 과거의 두 가지 기억을 떠올린다. 음악계에서 몇 번이고 사기를 당해 커리어를 포기하게 되었던 기억, 그리고 또 하나 잊을 수 없는 모멸감 가득한 기억이다.&lt;/p&gt;
&lt;p&gt;한 20년 전쯤 대학 전임 강사 시절, 실용음악과의 홍보를 위해 서울의 한 고등학교를 찾아갔을 때였다. 어느 선생님에게 학교 로고가 박힌 손톱깎이 세트와 음료수 상자를 건네며 잘 부탁드린다고 고개를 숙였다. 그 선생님은 나를 쳐다보지도 않고, 발로 내가 가져온 물건을 툭툭 걷어차며 말했다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;quot;요새 누가 뭐 이런 걸 갖고 오나.&amp;quot;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;그때의 자괴감은 이루 말할 수 없었다. 하지만 갓 태어난 첫째 아이 생각에 당장 그만둘 수도 없었다. 그날의 참담함은 내게 많은 생각을 던져주었고, 그 발길질이 없었다면 지금의 나는 이곳에 없었을지도 모른다.&lt;/p&gt;
&lt;p&gt;지금까지 엘리트코스를 밟아 왔을 실리콘밸리의 지인들 앞에서 &amp;quot;사기당하고 잡상인 취급받던&amp;quot; 이야기를 하면 다들 신기해한다. 하지만 그 아픈 기억들이야말로 내가 번아웃 없이 40대 후반까지 살아남게 한, 가장 단단한 방패이자 갑옷이다.&lt;/p&gt;
&lt;h3&gt;5. Outro: 경계를 잇는 자&lt;/h3&gt;
&lt;p&gt;스티브 잡스는 창의성을 두고 &#39;그저 사물을 연결하는 것(Creativity is just connecting things)&#39;이라 말했다. 하지만 그 연결은 매끄럽고 평탄한 꽃밭 위에서는 좀처럼 일어나지 않는다. 서로 다른 세계가 부딪히고 깎여나가는 그 불편한 경계선 위에서 비로소 혁신은 싹을 틔운다.&lt;/p&gt;
&lt;p&gt;만약 당신이 비전공자라서, 혹은 남들과 다른 배경을 가져서 위축되어 있다면 확신을 가지고 말하고 싶다. &lt;strong&gt;당신의 그 &#39;이질적인 과거&#39;는 실패와 도태의 흔적이 아니다.&lt;/strong&gt; 오히려 남들이 보지 못하는 지점을 짚어낼 미래의 가장 날카로운 무기다.&lt;/p&gt;
&lt;p&gt;앞으로 이 블로그를 통해 실리콘밸리의 엔지니어링 트렌드와 AI 시대의 테크니컬 리더십, 그리고 딴따라 출신 한국인 구글러의 시선으로 본 미국 생활의 단면들을 독자분들과 나누려 한다.&lt;/p&gt;
&lt;p&gt;나의 이 투박한 기록들이 누군가에게는 새로운 길을 개척할 수 있다는 단단한 근거가 되기를 소망한다.&lt;/p&gt;
</content>
  </entry>
  
</feed>
