<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Sungjoo Ha</title>
  <subtitle>Blog</subtitle>
  <link href="https://shurain.net/blog/" rel="alternate"/>
  <link href="https://shurain.net/blog/feed.xml" rel="self"/>
  <id>https://shurain.net/blog/feed.xml</id>
  <updated>2025-09-07T00:00:00Z</updated>
  <author><name>Sungjoo Ha</name></author>
  <entry xml:lang="ko">
    <title>Aim High</title>
    <link href="https://shurain.net/blog/aim-high/" rel="alternate"/>
    <id>https://shurain.net/blog/aim-high/</id>
    <published>2025-09-07T00:00:00Z</published>
    <updated>2025-09-07T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>Aim high는 말 그대로 더 높은 수준을 추구하는 것을 의미합니다. 이 또한 마인드셋입니다. 흔히 move fast 와 aim high는 서로 tradeoff 관계에 있는 것이 아닌가 하는 생각을 합니다. 빨리 결과를 내면 퀄리티가 낮아질 수밖에 없고 퀄리티를 내려면 빨리 결과를 낼 수 없는 것이 아닌가 하는 생각이 들죠. 어떤 측면에서 보면 맞는 말이지만 이 또한 본질을 생각해볼 필요가 있습니다. Move fast가 latency와 throughput에 대한 이야기인 것처럼 aim high도 문제를 바라보는 시각에 대한…</summary>
    <content type="html">&lt;p&gt;Aim high는 말 그대로 더 높은 수준을 추구하는 것을 의미합니다. 이 또한 마인드셋입니다. 흔히 &lt;a href="https://shurain.net/blog/move-fast/"&gt;move fast&lt;/a&gt;와 aim high는 서로 tradeoff 관계에 있는 것이 아닌가 하는 생각을 합니다. 빨리 결과를 내면 퀄리티가 낮아질 수밖에 없고 퀄리티를 내려면 빨리 결과를 낼 수 없는 것이 아닌가 하는 생각이 들죠. 어떤 측면에서 보면 맞는 말이지만 이 또한 본질을 생각해볼 필요가 있습니다. Move fast가 latency와 throughput에 대한 이야기인 것처럼 aim high도 문제를 바라보는 시각에 대한 이야기입니다. Aim high는 스스로에게 더 높은 수준의 결과물을 기대하는 것을 의미합니다. 본인 스스로 얼마나 높은 수준의 기준을 가져다 대는가? 그리고 그러한 기준을 계속해서 올리고 있는가?를 aim high의 본질로 생각할 수 있습니다.&lt;/p&gt;
&lt;p&gt;최고의 성과를 내는 직원들은 무엇이 다른가를 서베이 해봤을 때 도전적인 목표를 잡고 스스로에게 높은 기준을 요구하는 것이 가장 중요한 요소였습니다. 조직이 OKR을 사용하면서 도전적인 목표를 잡는 것을 이와 같은 맥락에서 생각할 수 있습니다.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;Set stretch goals and adopt high standards for themselves. This was the single most powerful differentiator. The best individual contributors set — and met — stretch goals that went beyond what others thought were possible. They also encouraged others to achieve exceptional results.  And yet when we asked raters to select the four skills they thought were most important for an individual contributor to have, less than one in 10 chose high goals. It appears that setting stretch goals, since it’s not necessarily expected, is a behavior that separates top performers from average.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://hbr.org/2014/04/what-a-players-do"&gt;The Behavior that Defines A-Players&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;높은 성취를 내는 가장 효과적인 방법은 스스로에게 높은 잣대를 요구하고 도전적인 목표를 잡는 것입니다. 이에 대해 더 알고 싶다면 &lt;a href="https://en.wikipedia.org/wiki/Goal_setting"&gt;Goal Setting&lt;/a&gt;에 대해 더 알아보시길 권합니다.&lt;/p&gt;
&lt;p&gt;Aim high가 스스로에게 높은 수준의 잣대를 가져다 대는 것이라면 그 수준의 위치에 의해 많은 것이 달라질 수 있습니다. 그렇기 때문에 내가 평소에 가지고 있는 &lt;strong&gt;틀을 깨어줄 수 있는 환경&lt;/strong&gt; 을 갖추는 것이 중요합니다. 이는 좋은 동료일 수도 있고 나를 한게까지 밀어줄 수 있는 코치일 수도 있으며 대회와 같은 경쟁적인 상황일 수도 있습니다. 좋은 환경에 기를 쓰고 가는 것은 signaling의 의미도 있지만 그보다 그 환경에서 나의 틀을 부숴줄 경험을 더 많이 할 수 있기 때문이기도 합니다. 저는 학부 1학년 때부터 LaTeX을 사용해서 모든 과제를 제출했었는데 이건 주변에 그렇게 하는 친구들을 보고 자연스레 그렇게 할 수 있다고 생각했기 때문입니다. 비슷하게 학부 때 시스템 프로그래밍 수업 들은 동기가 바이너리만 주어진 게임의 동작 방식을 어셈블리 코드 인젝션을 통해 바꾸는 것을 보며 저런 것이 아예 손에 닿지 않는 곳에 위치한 것이 아니라 나도 할 수 있는 것이라는 자극을 받았던 기억이 납니다.&lt;/p&gt;
&lt;p&gt;우리가 운동 할 때에 코치를 두는 이유는 이러한 틀을 체계적으로 부숴줄 수 있기 때문입니다. 조직은 그렇기 때문에 이러한 틀을 부숴주는 높은 기준을 요구하는 환경을 제공할 수 있도록 노력해야 합니다. 저희가 늘 리터러쳐 서베이를 100편씩 일주일이면 할 수 있어야 한다고 이야기하는 이유는 이를 해본 적이 없는 사람은 상상조차 하지 못하지만 막상해보고 숙달되면 실제로 할 수 있는 그런 종류의 작업이기 때문입니다.&lt;/p&gt;
&lt;p&gt;팀과 무관하게 개인의 레벨에서도 더 도전적인 목표를 잡고 나 스스로의 기준을 더 높일 수 있는 방법은 무엇인지를 꼭 고민해보길 바랍니다. 내가 평소에 하던 것보다 한 단계 더 나아간다면 어떨까? 이런 질문을 던지고 그 답을 찾아보길 권합니다. 평소에 업무의 완료라고 생각한 시점에 조금 더 품질을 높인다면 무엇을 할 수 있는지 한 번 더 생각해보시길 바랍니다. &lt;strong&gt;“이렇게까지 해야 돼?”라는 생각이 들 때까지 한계를 밀어붙이고 그러한 한계에 도달했을 때 한 발 더 나아가는 방법을 다시금 생각하는 것이 핵심&lt;/strong&gt; 중 하나라 생각합니다. 모르는 사람이 생각하기에는 그렇게까지 해야해?로 보일 수 있는 정도의 높은 기준을 스스로에게 요구해야만 그 정도 경지에 오를 수 있는 것이라고 생각합니다.&lt;/p&gt;
&lt;p&gt;제가 활용했던 몇 가지 테크닉을 공유드립니다.&lt;/p&gt;
&lt;p&gt;제가 늘 하는 이야기 중 추상화 단계를 넘나들어야 한다는 것이 있습니다. 문제에 대한 고민을 할 때 내가 친숙한 추상화 단계 아래와 위에서 어떤 일이 일어나고 있는지 궁금해하고 알아보도록 하세요. 뉴럴넷 밑바닥에 돌아가는 GPU는 어떤 방식으로 동작하고 커널을 어떻게 활용하는지 공부해보세요. 내가 만든 소프트웨어 컴포넌트가 보다 큰 그림에서 어떤 방식으로 다른 컴포넌트와 연결되어 회사에 기여하고 있는지 알아보세요.&lt;/p&gt;
&lt;p&gt;Pre-mortem을 진행하세요. 나의 과업이 실패했다고 가정하고 그 원인이 무엇인지 생각해보고 가장 값싸게 이러한 리스크를 관리할 수 있는 방법에 대해 고민하세요. 리스크 요소가 될 수 있는 것들을 내 생각보다 조금 더 쥐어짜는 노력을 해보세요. 저는 과거 논문을 쓰다가 제출 직전이 되어 도무지 더 고칠 곳이 없다는 생각이 드는 시점에 한 번 더 마음을 가다듬고 논문 제출 후에 리젝되어 타임머신을 타고 다시 이 시점으로 돌아왔다는 생각을 하며 한 번 더 논문을 수정하는 작업을 했었습니다.&lt;/p&gt;
&lt;p&gt;본인이 업무하는 것을 기록하세요. 저는 심지어 제가 연구실에서 일 하던 화면을 모두 &lt;a href="https://dotd.shurain.net/2013-10-23/"&gt;녹화한 뒤에 이를 다시 살펴&lt;/a&gt;보며 도구 사용이나 업무 습관에서 개선할 수 있는 부분이 있는지 살펴보곤 했습니다.&lt;/p&gt;
&lt;p&gt;문제 풀이 기법을 완전히 내 것으로 만들기 위해 노력하세요. 문제를 다 풀어낸 뒤에 이를 다시 푼다면 어떻게 할지가 명확하게 보이도록 노력하세요. 조금 더 일반화된 문제 셋팅이나 풀이를 고민해보세요.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;In my own experience of designing difficult algorithms, I find a certain technique most helpful in expanding my own capabilities. After solving a challenging problem, I solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for. Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value.&lt;/p&gt;
&lt;p&gt;Robert Floyd&lt;/p&gt;
&lt;p&gt;Another mental gimmick for aid in research work, I think, is the idea of generalization. This is very powerful in mathematical research. The typical mathematical theory developed in the following way to prove a very isolated, special result, particular theorem – someone always will come along and start generalization it. He will leave it where it was in two dimensions before he will do it in N dimensions; or if it was in some kind of algebra, he will work in a general algebraic field; if it was in the field of real numbers, he will change it to a general algebraic field or something of that sort. This is actually quite easy to do if you only remember to do it. If the minute you’ve found an answer to something, the next thing to do is to ask yourself if you can generalize this anymore – can I make the same, make a broader statement which includes more – there, I think, in terms of engineering, the same thing should be kept in mind. As you see, if somebody comes along with a clever way of doing something, one should ask oneself, “Can I apply the same principle in more general ways? Can I use this same clever idea represented here to solve a larger class of problems? Is there any place else that I can use this particular thing?”&lt;/p&gt;
&lt;p&gt;Claude Shannon&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;호기심을 따라가세요. 내가 무엇을 좋아하는지, 어떤 것에 관심있는지 알고 호기심이 일어나는 것을 따라가다보면 생산적일 수 있습니다. 새로운 것을 배울 수도 있고, 부족하던 부분을 자연스레 채울 수도 있어요. 그런 방식으로 본인의 행운을 키울 수 있습니다.&lt;/p&gt;
&lt;p&gt;Aim high를 해야 정말 탁월한 수준에 도달할 수 있습니다. 뛰어난 성취를 달성하는 사람들은 상상 이상으로 열심히 일하고 상상 이상으로 그라인딩하고 있습니다. 이를 염두에 두고 한 발 더 나아가는 것을 늘 생각하시길 바랍니다.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;I find these “shorter work weeks are just as effective” articles to be nonsense, at least for knowledge workers with some tactical discretion.&lt;/p&gt;
&lt;p&gt;John Carmack&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;a href="https://shurain.net/core-dumped/high-standard/"&gt;High Standard&lt;/a&gt;&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>Prioritize</title>
    <link href="https://shurain.net/blog/prioritize/" rel="alternate"/>
    <id>https://shurain.net/blog/prioritize/</id>
    <published>2025-06-16T00:00:00Z</published>
    <updated>2025-06-16T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>우선순위를 정한다는 것은 단순히 일의 순서를 정하는 것이 아닙니다. 그것은 불확실성 속에서 최적의 의사결정을 내리는 문제와 같습니다. 우리는 종종 쉬운 것부터 하자low-hanging fruit와 같은 휴리스틱에 의존하지만, 이런 접근은 최적이 아닐 때가 많습니다. AI를 연구하는 우리에게는 이 문제를 해결할 더 강력한 도구가 있습니다. 바로 결정 이론decision theory 이라는 렌즈로 우선순위를 바라보는 것입니다. 이 관점에서, 우선순위를 정하는 행위는 기대 효용expected utility을 극대화하는 선택을 하는 것과…</summary>
    <content type="html">&lt;p&gt;우선순위를 정한다는 것은 단순히 일의 순서를 정하는 것이 아닙니다. 그것은 불확실성 속에서 최적의 의사결정을 내리는 문제와 같습니다. 우리는 종종 쉬운 것부터 하자low-hanging fruit와 같은 휴리스틱에 의존하지만, 이런 접근은 최적이 아닐 때가 많습니다. AI를 연구하는 우리에게는 이 문제를 해결할 더 강력한 도구가 있습니다. 바로 &lt;a href="https://plato.stanford.edu/entries/decision-theory/"&gt;결정 이론decision theory&lt;/a&gt;이라는 렌즈로 우선순위를 바라보는 것입니다. 이 관점에서, 우선순위를 정하는 행위는 기대 효용expected utility을 극대화하는 선택을 하는 것과 같습니다. 우리가 주된 도구로 사용하는 AI/ML/통계학도 결국 이러한 기대효용 극대화를 어떻게 풀 것인가에 대한 답을 베이지안 결정이론이나 강화학습, 온라인 러닝 기법 등의 다양한 모양새로 제시하고 있습니다. 이 글에서는 이 핵심 프레임워크를 바탕으로, 저희 AI 조직이 어떻게 중요한 업무에 집중하고 큰 임팩트를 내는지 공유하고자 합니다.&lt;/p&gt;
&lt;p&gt;결정 이론의 핵심은 기대 효용을 극대화하는 것입니다. 그렇다면 실제 업무에서 기대 효용이 높은 선택이란 무엇일까요? 이것이 바로 High Output Management에서 강조한 레버리지leverage의 개념입니다. 레버리지가 높은 업무에 집중하라는 원칙은, 결국 기대 효용을 극대화하라는 이론을 현실에 적용한 훌륭한 휴리스틱인 셈입니다. 매니저의 아웃풋은 본인 조직의 아웃풋과 본인이 영향을 끼칠 수 있는 모든 조직의 아웃풋의 총합이라고 하였습니다. 아웃풋의 크기는 결국 수행하는 행동과 그 행동의 레버리지의 곱으로 구성됩니다. 그렇다면 아웃풋의 크기를 늘리기 위해서는 수행하는 행동의 수를 늘리거나 레버리지 자체를 늘리거나 혹은 레버리지가 낮은 업무의 비중을 줄이고 레버리지가 높은 업무를 많이 수행해야 합니다. 이러한 단순한 프레임워크를 머릿속에 넣고 업무를 대하는 것이 우선순위를 잘 설정하고 의사결정을 잘 하는 기본적인 방법입니다. 해당 책에서 매니저가 수행하는 업무 중 레버리지가 큰 업무로 한 명의 매니저가 여러 사람에게 영향을 주거나, 매니저의 짧은 인풋으로 한 사람의 퍼포먼스가 긴 시간 향상될 수 있거나, 한 사람이 큰 그룹의 업무에 영향을 줄 수 있는 지식이나 정보를 제공할 수 있는 경우 등을 꼽고 있습니다.&lt;/p&gt;
&lt;p&gt;레버리지 높은 업무에 집중하라는 것은 뻔해 보이지만 이를 잘 지키면서 행동하면 얼핏 드는 생각보다 훨씬 큰 성과 차이를 만들어 낼 수 있습니다. 그 이유는 여러 측면에서 생각해볼 수 있습니다. 일단 파레토 법칙을 생각해볼 수 있습니다. 흔히 80:20 법칙이라고도 불리는데, 80%의 성과가 20%의 업무에서 나옴을 의미합니다. 만약 이 법칙이 사실이라면 20%의 중요한 업무가 아닌 곳에 집중되는 거의 대부분의 노력은 기회비용을 생각해보면 버려지는 것과 크게 다르지 않습니다. Proactive에 대한 이야기를 할 때에도 언급이 되었지만 나 혼자 최선을 다 하는 것이 아니라 실제 성과를 달성하기 위해 조직 전체를 활용하는 것이 레버리지가 높은 행동입니다. 당연하게도 나 혼자 열심히 하는 것과 회사 전체를 활용할 수 있는 것은 인풋 대비 그 결과의 크기가 훨씬 커질 여력이 많이 있겠죠.&lt;/p&gt;
&lt;p&gt;이처럼 레버리지는 기대 효용을 극대화하는 강력한 지침입니다. 하지만 현실의 문제는 더 복잡하며, 이론적 최적을 늘 계산할 수는 없습니다. 따라서 우리는 더 넓은 의사결정을 돕는 도구를 갖추어야 합니다. 이 도구는 크게 두 가지, 즉 행동 규칙인 휴리스틱과 상황을 이해하는 틀인 멘탈 모델로 나뉩니다.&lt;/p&gt;
&lt;p&gt;휴리스틱(원칙/규칙)은 복잡한 계산을 하는 대신 보통 잘 통하는 미리 정해둔 규칙을 따라가는 것을 의미합니다. 의사결정을 빠르면서도 효과적으로 잘 수행하는 분들은 잘 동작하는 여러 휴리스틱과 해당 휴리스틱의 약점을 알고 있기 때문에 그렇게 행동할 수 있다고 생각합니다. 이러한 휴리스틱에 대한 생각을 해보기에 가장 좋은 소개 자료는 Ray Dalio의 원칙이라는 책을 살펴보시길 권합니다. 만약 내가 어떠한 의사결정을 해야 하는 순간이 왔을 때 잘 모르겠다 혼란스럽다와 같은 생각이 든다면 내가 이러한 원칙/휴리스틱이 없는 것은 아닌지 생각해보고 만약 그렇다면 해당 상황에 적용 가능한 휴리스틱을 만드는 것을 고려하길 바랍니다.&lt;/p&gt;
&lt;p&gt;몇 가지 휴리스틱을 예시로 들어보자면 Jeff Bezos는 의사결정은 두 가지 종류로 나뉜다고 하였습니다. 양방향의 의사결정이 가능한 경우에는, 그러니까 결정을 되돌리는 것이 비싸지 않다면 빠르게 현재 있는 정보만을 바탕으로 의사결정을 합니다. 반면 단방향의 의사결정만 가능한 경우에는, 그러니까 결정을 되돌리는 것이 비싸거나 불가능하다면 최대한 천천히 의사결정을 내립니다. 번복할 수 있는 종류의 결정은 고민을 더 하기보다는 최대한 빠르게 행동을 하여 불확실성을 명확하게 줄이도록 하자는 휴리스틱입니다. Ray Dalio는 동료들의 전문성에 기반한 가중 평균 투표 제도를 활용하여 의사결정을 하는 것으로 유명합니다. 이는 앞서 잠깐 언급한 ML 분야의 하나인 온라인 러닝 분야에서 활용하는 최적 의사결정 알고리즘의 열화판으로 볼 수 있습니다. Online learning에서 어떤 방식으로 최적 포뮬레이션을 하는지에 대해 알고 싶다면 &lt;a href="https://www.goodreads.com/book/show/1226146.Prediction_Learning_and_Games"&gt;Prediction, Learning, and Games&lt;/a&gt;를 살펴 보시길 권합니다.&lt;/p&gt;
&lt;p&gt;멘탈 모델은 현재 상황을 정확하게 파악하고 어떤 휴리스틱을 적용할지 판단하게 돕는 생각의 틀입니다. 멘탈 모델에 대한 기본적인 시각은 Charlie Munger의 &lt;a href="https://press.stripe.com/poor-charlies-almanack"&gt;Poor Chalie's Almanack&lt;/a&gt;을 살펴보시길 권합니다. Charlie Munger의 제안대로 세상의 다양한 분야에 존재하는 기본적인 생각의 도구를 숙지하고 이를 렌즈 삼아 현상을 바라보는 습관이 중요합니다. 제가 AI 조직에서 자주 언급하는 멘탈 모델을 예시로 들어보자면 프로그래밍을 통한 조직 구조의 이해(&lt;a href="https://martinfowler.com/bliki/ConwaysLaw.html"&gt;콘웨이의 법칙&lt;/a&gt;), &lt;a href="https://en.wikipedia.org/wiki/Shapley_value"&gt;Shapley value&lt;/a&gt;를 비롯한 게임이론의 다양한 아이디어, &lt;a href="https://en.wikipedia.org/wiki/Thinking_In_Systems:_A_Primer"&gt;시스템적 사고&lt;/a&gt; 등이 떠오릅니다.&lt;/p&gt;
&lt;p&gt;하이퍼커넥트 AI 조직에서는 늘상 이러한 원칙과 멘탈 모델의 활용이 일어납니다. 예를 들어, 데이터를 더 깊게 분석하는 것과 빠르게 행동하여 데이터를 얻는 것 사이에서 고민을 할 때 이 결정이 대부분 쉽게 되돌릴 수 있는 양방향 문이기에 해당 휴리스틱을 적용하는 경우가 많습니다. 이런 경우 긴 분석을 통해 완벽을 기하기보다 빠르게 행동하여 불확실성을 줄이는 선택을 합니다. 이처럼 의사결정에 있어서 명확한 원칙이 존재하면 팀은 왜 특정 선택을 하는지 이해하게 되며 매우 효과적으로 행동할 수 있습니다.&lt;/p&gt;
&lt;p&gt;물론 언제나 수학적으로 최적인 계산을 수행하는 것은 무리입니다. 하지만 이론적으로 탄탄한 도구를 갖추고 있는 것은 무척이나 유용합니다. 필요에 따라 문제를 바라보는 해상도를 달리할 수 있기 때문입니다. 내가 어떤 것을 가정하고 있는지, 그 가정의 불확실성은 얼마인지, 이를 얼마나 쉽게 줄일 수 있는지 등에 대한 감을 얻기에 매우 유용합니다.&lt;/p&gt;
&lt;p&gt;이러한 접근 방법을 더 깊이 알고 싶으시다면 Douglas Hubbard의 &lt;a href="https://www.goodreads.com/book/show/444653.How_to_Measure_Anything"&gt;How To Measure Anything&lt;/a&gt;이라는 책을 읽어보시길 권합니다. 별다른 수학적인 훈련 없이 베이지안 결정이론을 어떻게 현실 세계에서 사용할 수 있는지에 대한 설명을 책 한권으로 알려주는 책입니다. 본인이 AI를 진지하게 공부하시는 분이라면 &lt;a href="https://probml.github.io/pml-book/book0.html"&gt;Kevin Murphy의 0번째 책&lt;/a&gt;의 챕터 5, 6과 함께 &lt;a href="https://www.youtube.com/playlist?list=PLD0F06AA0D2E8FFBA"&gt;Mathematicalmonk의 ML 강의&lt;/a&gt; 챕터 11을 살펴보시고 체화하시길 권합니다.&lt;/p&gt;
&lt;p&gt;우선순위를 잘 설정하자는 뻔한 문구 아래에는 AI를 공부하는 사람으로서 반드시 이해하고 있어야만하는 합리적 의사결정 이론이 깔려있습니다. 의사결정의 근본이 되는 결정 이론의 프레임워크를 이해하고, 그에 대한 현실적인 접근법으로서 행동 규칙인 휴리스틱을 활용하며, 다양한 상황을 꿰뚫어 보기 위해 여러 종류의 멘탈 모델을 갖추는 것. 이처럼 구조적으로 문제를 바라보고 불확실성을 고려한 의사결정을 하는 방법의 이해와 이를 배경삼아 만들어낸 다양한 종류의 멘탈 모델 및 의사결정 원칙이 하이퍼커넥트 AI 조직이 중요한 업무에 집중하여 큰 임팩트를 내는 방법입니다.&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>Move Fast</title>
    <link href="https://shurain.net/blog/move-fast/" rel="alternate"/>
    <id>https://shurain.net/blog/move-fast/</id>
    <published>2025-06-09T00:00:00Z</published>
    <updated>2025-06-09T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>앞서 소개한 하이퍼커넥트의 일곱 가지 핵심가치 proactive 에 이어 move fast를 소개합니다. 하이퍼커넥트를 가장 강하게 대표하는 가치임과 동시에 move fast가 가장 오해를 많이 사는 가치이기도 하다고 생각합니다. 이에 제가 이해하고 있는 move fast에 대해 설명 드립니다. 적어도 저희 조직에서는 다음과 같은 방식으로 move fast를 해석하고 업무에 임하고 있습니다.</summary>
    <content type="html">&lt;p&gt;앞서 소개한 하이퍼커넥트의 일곱 가지 핵심가치 &lt;a href="https://shurain.net/blog/proactive/"&gt;proactive&lt;/a&gt;에 이어 move fast를 소개합니다. 하이퍼커넥트를 가장 강하게 대표하는 가치임과 동시에 move fast가 가장 오해를 많이 사는 가치이기도 하다고 생각합니다. 이에 제가 이해하고 있는 move fast에 대해 설명 드립니다. 적어도 저희 조직에서는 다음과 같은 방식으로 move fast를 해석하고 업무에 임하고 있습니다.&lt;/p&gt;
&lt;p&gt;하이퍼커넥트의 7가지 일하는 방식 중 하이퍼커넥트를 가장 강하게 대표하는 것이 move fast라 생각합니다. 과거 제가 처음 디렉터가 되었을 때에도 여러 디렉터들께 여쭈어 보았을 때에 모든 디렉터들이 입을 모아 이야기했던 하이퍼커넥트의 가장 중요한 가치는 move fast였습니다. 저는 move fast가 우리의 가장 중요한 가치 중 하나라고 생각합니다.&lt;/p&gt;
&lt;p&gt;하지만 하이퍼커넥트를 가장 강하게 대표하는 가치임과 동시에 move fast가 가장 오해를 많이 사는 가치이기도 하다고 생각합니다. 문자 그대로 해석하면 빠르게 일하라는 것이며 너무나도 당연한 이야기이기 때문입니다. 특히 하이퍼커넥트의 다른 가치인 aim high와 서로 모순적이지 않느냐는 질문도 종종 받았습니다. 이에 제가 이해하고 있는 move fast에 대해 설명 드립니다. 적어도 저희 조직에서는 다음과 같은 방식으로 move fast를 해석하고 업무에 임하고 있습니다.&lt;/p&gt;
&lt;p&gt;제가 생각하는 move fast는 "짧은 레이턴시latency를 높은 쓰루풋throughput보다 선호한다" 입니다. 레이턴시는 지연속도/지연시간을 의미하죠. 어떤 액션을 하고 결과를 다시 받아보기까지 걸리는 시간이라고 해석하면 됩니다. 쓰루풋은 처리량을 의미하는데, 단위 시간 당 얼마나 많은 결과를 만들어 냈느냐를 의미합니다. 짧은 지연과 많은 결과는 둘 다 중요한 가치입니다. 가능하면 두 마리 토끼를 다 잡는 것이 좋겠죠. 그러나 둘 중 하나를 선택해야 하는 상황이 만약 생긴다면, 더 짧은 레이턴시를 먼저 선택하라고 이야기하는 것이 move fast입니다. 물론 밸런스가 중요합니다. 극단적인 레이턴시의 선택으로 쓰루풋이 터무니 없이 낮아진다면 이는 올바른 선택이 아닐 것입니다. 다만 쓰루풋을 높일 방법을 고민하기에 앞서 먼저 레이턴시를 줄일 방법을 먼저 고려하자는 것이 move fast라 생각하면 좋을 것 같습니다.&lt;/p&gt;
&lt;p&gt;우리가 이렇게 레이턴시를 줄이고자 하는데에는 이유가 있습니다.&lt;/p&gt;
&lt;p&gt;기본적으로 우리 하는 모든 행위는 회사가 사용자에게 더 많은 가치를 전달하고 이로인해 돈을 더 많이 벌기 위함입니다. 이 과정 전체는 생각보다 느리고 그렇기 때문에 불확실성이 높은 상황에서 미래를 예측하며 여러 행동을 해야 합니다. 문제는 특히 이러한 불확실한 상황에서 미래 예측을 하는 것은 대단히 어렵다는 것입니다. 그렇기 때문에 불확실성을 다루기 위한 다양한 수단을 활용합니다. 그 중 한 가지가 행동으로부터 결과까지의 레이턴시를 줄이는 것입니다. 이러한 원칙 하에 많은 조직이 기능 조직보다 목적 조직을 선택하게 되는 것입니다. 기능 조직이 레버리지의 측면에서 목적 조직보다 많은 면에서 우월하지만 레이턴시의 측면에서 불리하며, 그 한가지 불리함이 너무나도 중요한 역할을 하기 때문에 목적 조직을 선택하는 것이죠. 그렇기 때문에 언제나 쓰루풋을 높이는 것보다 레이턴시를 줄이는 것을 먼저 고민하시길 권합니다. 불확실성을 줄이기까지의 레이턴시, 가치를 창출하고 이를 전달하기까지의 레이턴시, 학습의 레이턴시, 피드백을 받는 레이턴시, 이러한 모든 종류의 유의미한 레이턴시를 줄이는 것을 고민해야 합니다.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://shurain.net/blog/compiling.png" alt="XKCD 303, Compiling: two programmers sword-fighting on office chairs while their code compiles"&gt;&lt;/p&gt;
&lt;p&gt;몇 가지 예시를 들어볼까요? XKCD의 아주 유명한 컴파일러 코믹이 있습니다. 당연하게도 이런 상황에서 칼싸움하며 시간을 보내는 것은 이상적이지 않습니다. 보통 다들 먼저 생각하시는 것이 그 시간에 다른 중요한 업무를 하면서 시간을 보내는 것입니다. 그것도 물론 의미있지만 저는 더 좋은 방법은 컴파일 시간을 줄일 수 있는 더 나은 도구를 사용하거나 컴파일링을 아예 안 해도 되는 도구를 사용할 수는 없는지 고민해보고 선택하는 것이라 생각합니다.&lt;/p&gt;
&lt;p&gt;특히 ML 모델의 관점에서 생각해보면 모델 학습에 긴 시간이 걸리니 그 사이에 다른 것을 하자는 것도 좋은 접근이지만 더 move fast할 수 있는 접근은 학습을 통해서 우리가 확인하고자 하는 것을 더 빠르게 볼 수 있는 방법을 선택하는 것입니다. 더 적은 데이터로 최대한 feasibility를 본다든지, 공격적인 분산 학습을 통해 모델 학습 완료까지의 시간을 줄이는 선택 등을 언제든 권장합니다.&lt;/p&gt;
&lt;p&gt;타 부서와 협업을 할 때에 자주 있는 일로, 어떤 요청 처리에 일주일이 걸린다는 답변을 들을 수 있습니다. 물론 다들 바쁘고 해야 할 일이 많기 때문에 그럴 수 있습니다. 이 때에 그 시간 동안 다른 업무를 수행하겠다고 생각하는 것도 좋지만, 더 빠르게 할 수 있는 방법은 없을지, 도와드릴 수 있는 것은 없는지, 정말 방법이 없는지 여쭤보는 것이 보다 능동적인 접근이며 이로인해 업무가 더 빨라지는 경우가 깜짝 놀랄 정도로 자주 있는 접근 방법입니다.&lt;/p&gt;
&lt;p&gt;코드의 리팩토링에 대해서도 비슷한 시각을 적용할 수 있습니다. 우리가 리팩토링을 하는 이유는 기술 부채를 갚기 위함입니다. 기술 부채를 갚는다는 것은 미래에 있을 변화에 사용될 비용을 줄이기 위해 지금 비용을 들여서 기술 부채를 갚아버리는 것을 의미합니다. 이런 접근의 어려움은 우리가 미래 예측을 잘 못한다는데에 있습니다. 지금 갚아버린 비용이 미래에 ROI가 나오는 선택이 아닐 수도 있다는 것이지요. 그렇기 때문에 저는 한 번에 큰 규모로 리팩토링을 수행하는 것보다 기능을 구현하면서 필요한 작은 수정을 그때그때 하는 것을 훨씬 선호합니다. 캐싱의 원리를 생각해보면 최근에 바뀐 코드와 자주 바뀐 코드가 다음 번에도 다시 바뀔 가능성이 높으리라 생각할 수 있습니다. 그러므로 이번에 수정하는 부분의 작은 부채를 그리 크지 않은 비용을 들여서 갚아버리는 것은 현명한 부채 청산이라고 볼 수 있는 것이죠. 이 또한 투자의 가치를 보기까지의 레이턴시를 줄이는 선택이라 할 수 있겠습니다.&lt;/p&gt;
&lt;p&gt;어떤 종류의 업무는 아주 복잡해서 대단히 다양한 각도로 고려하고 깊은 생각이 필요한 경우가 있습니다. 이런 경우에도 한 번에 생각을 다 끝내서 완벽하게 정리된 내용을 공유하려고 하기 보다는 데드라인을 정해놓고 그 기간 안에 할 수 있는 정리를 최대한 한 뒤에 한 번 공유하고 이후 팔로우업 아이템을 추적하는 것이 좋은 방법이라고 생각합니다. 애초에 얼라인이 잘 안되어 있는 상황이었다면 잘못된 문제에 대한 고민을 하고 있었을 수도 있고, 얼라인이 잘 되어 있는 상황이었다 하더라도 완벽하게 생각을 마치는 사이에 환경이 변해서 문제가 변해버렸을 수도 있습니다. 피드백의 레이턴시를 줄이면 이러한 문제를 빠르게 대응할 수 있습니다.&lt;/p&gt;
&lt;p&gt;큰 프로젝트를 수행할 때에 끝 그림을 생각해보는 것은 반드시 필요합니다. 이런 경우에도 여러 접근이 있을 수 있겠죠. 가령 일 두 번 하지 않을 수 있도록 한 번에 완성도가 높은 것을 만들겠다는 방식으로 진행할 수도 있고, 두 번 작업 하더라도 빠르게 이터레이션을 돌면서 불확실성을 줄이는 접근을 택할 수도 있습니다. 제가 생각하는 move fast란, 두 가지 선택지 중 후자를 선택하는 것을 의미합니다. 물론 항상 그렇게 하는 것이 옳지는 않을 수 있습니다. 개발자들은 APIs are forever라는 이야기를 합니다. 즉, 어떤 결정은 무르기가 어렵기 때문에 깊게 고민해서 결정해야 한다는 것이죠. 보통 불특정 다수에게 제공하는 플랫폼 선택이 이러한 특징을 갖는 경우들이 있습니다. 이런 것은 깊게 고민하기는 해야 합니다. 그러나 저는 이러한 문제들 조차도 사람들이 생각하는 것보다 이터레이션을 통한 접근이 더 우월한 경우가 많다고 생각합니다. 구글의 Jeff Dean도 구글 내부 크롤러를 세 번은 넘게 만들었던 걸로 알고 있습니다. 한 번 만들고 완성하자마자 문제가 생겨서 다시 만들고 또 다시 만드는 경험을 몇 번 한 뒤에야 이 문제를 제대로 풀어냈다는거죠. 단순히 생각만 깊게 해서 인프라를 만든다는 아이디어는 신화에 가깝다고 생각합니다.&lt;/p&gt;
&lt;p&gt;Move fast 정신은 빠르게 움직여서 빠르게 불확실성을 줄이고 빠르게 피드백을 받고 빠르게 성장하는 것을 의미합니다. 서두에 이야기했다시피 move fast는 하이퍼커넥트의 가장 핵심적인 가치라 생각합니다. 저희 AI 팀에게 이 원칙은 단순한 슬로건이 아니라, 급변하는 기술 환경 속에서 꾸준히 사용자의 문제를 해결하고 임팩트를 만들어내는 핵심적인 운영 체제입니다. 이와 관련된 글귀 몇 개를 공유드립니다.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;What are some of the advantages of organizing much of a company in a mission-oriented form? There is only one. It is that the individual units can stay in touch with the needs of their business or product areas and initiate changes rapidly when those needs change. That is it. All other considerations favor the functional-type of organization. But the business of any business is to respond to the demands and needs of its environment, and the need to be responsive is so important that it always leads to much of any organization being grouped in mission-oriented units.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Andy Grove&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;When someone says "Let's have a follow up conversation", what is the implicit unspoken understanding of when that should happen? What will be considered early, appropriate and late in a way that violates cultural norms? In companies I've been at, that has ranged from a few hours to the next day to the next week to …perhaps never. This little test usually tells me a lot about how fast your organization/company works.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Sriram Krishnan&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;All systems are created incrementally, one character typed at a time. The choice is length and scope of feedback loops.&lt;/p&gt;
&lt;p&gt;Big changes are an illusion. All changes are small. There are only longer and shorter feedback cycles.&lt;/p&gt;
&lt;p&gt;When you try to make fewer mistakes by making fewer mistakes you slow feedback, learn less, and make more mistakes. When you speed feedback you learn more and make fewer mistakes.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Kent Beck&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>Proactive</title>
    <link href="https://shurain.net/blog/proactive/" rel="alternate"/>
    <id>https://shurain.net/blog/proactive/</id>
    <published>2025-06-04T00:00:00Z</published>
    <updated>2025-06-04T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>하이퍼커넥트에서 AI 팀을 맡으면서 지난 몇년간 수십편의 내부 뉴스레터를 작성했습니다. 이러한 뉴스레터는 회사가 돌아가는 상황을 팀원 모두에게 공유하기 위한 플랫폼이기도 하였고 현재 저의 관심이 집중된 것들이 어떤 것인지 팀 모두에게 알릴 수 있는 정렬(alignment)을 위한 장치이기도 하였습니다. 앞으로 때때로 이러한 내용을 모두와 공유하고자 합니다.</summary>
    <content type="html">&lt;p&gt;하이퍼커넥트에서 AI 팀을 맡으면서 지난 몇년간 수십편의 내부 뉴스레터를 작성했습니다. 이러한 뉴스레터는 회사가 돌아가는 상황을 팀원 모두에게 공유하기 위한 플랫폼이기도 하였고 현재 저의 관심이 집중된 것들이 어떤 것인지 팀 모두에게 알릴 수 있는 정렬(alignment)을 위한 장치이기도 하였습니다. 앞으로 때때로 이러한 내용을 모두와 공유하고자 합니다.&lt;/p&gt;
&lt;p&gt;첫 번째로 하이퍼커넥트의 일곱 가지 핵심가치 중 하나인 Proactive에 대해 공유하고자 합니다. 능동성은 어떤 상황에서나 중요한 가치이지만 특히 발전이 빠르고 불확실성이 큰 AI 분야에서 성과를 내기위해 저희 팀이 중시하는 중요한 가치입니다.&lt;/p&gt;
&lt;p&gt;스타트업과 같은 불확실성이 큰 환경에서는 직원에게 모든 것을 지시하는 방식으로 일이 진행되지 않습니다. 그보다는 개인이 적절하게 상황 판단을 하고 업무를 수행하길 기대합니다. 그렇게 해야지만 빠르게 움직이면서 좋은 의사결정을 하는 것이 가능합니다. 이를 설명하는 키워드는 능동성입니다. 하이퍼커넥트의 핵심가치 중 하나인 proactive가 이러한 행동양식을 설명합니다.&lt;/p&gt;
&lt;p&gt;저는 저희 팀 사람들에게 proactive함에 대한 이야기를 할 때 극한의 오너십(extreme ownership)과 높은 주체성(high agency)을 자주 언급합니다. 본질적으로 상황에 대해 능동적이기 위해서는 일종의 주인의식이 있어야 합니다. 그렇지 않으면 일이 흘러가는대로 두고 수동적인 자세로 대응하기 십상입니다. 주인의식이란, 이 문제가 정말 '나의 문제'라면, '나밖에 이 문제를 해결할 수 있는 사람이 없다'면, 이 게임에 사람이 조종하는 캐릭터(PC, player character)가 '나 하나뿐'이라면 어떻게 해야 하는가 하는 질문을 스스로에게 계속 던지며 해결책을 찾아가는 자세라고 생각합니다.&lt;/p&gt;
&lt;p&gt;내가 어떤 문제의 오너라면 진짜로 풀고 싶은 문제가 무엇인지 정확히 이해하려고 할 것입니다. 아무리 내가 일을 빠르고 완벽하게 처리하더라도 원래 풀고자 했던 문제를 해결해주는 것이 아니라면 큰 의미가 없습니다. 문제가 무엇인지 정말 이해하기 위해서는 문제를 둘러싸고 있는 문맥, 배경이나 구조 등을 고려해야만 합니다. 그렇기 때문에 나는 주어진 일만 잘 처리하면 내 할 일은 다 했다는 생각은 전혀 오너십이 없는 생각입니다. 오너십을 갖고 업무를 살펴봐야 숨겨진 문제를 표면으로 드러낼 수도 있습니다. 결국 세부적인 내용은 실제 업무를 수행하는 분들이 가장 잘 알고 있으므로 이러한 현장의 구체적인 상황을 리더에게 전달할 의무도 있습니다. 나의 리더가 잘못된 결정을 내린다면 그것 또한 나의 책임입니다.&lt;/p&gt;
&lt;p&gt;극한의 오너십에 대한 이야기를 하면 자주 듣는 반박 중 하나가 내가 회사의 주인이 아닌데 어떻게 극한의 오너십을 발휘할 수 있는가입니다. 어떤 관점에서는 맞는 말이기도 합니다. 그러나 저는 이러한 시각이 생산적인 시각은 아니라고 생각합니다. 일차적으로 나를 제외한 요소에 책임을 묻는 것은 보통의 경우 큰 의미가 없습니다. 내가 절벽 아래로 떨어지고 중력을 탓해봤자 아무 의미가 없습니다. 내가 바꿀 수 있는 것은 나 자신의 행동뿐이며 결국 나의 행동을 바꿔서 성공을 이끌어내야 합니다. 내가 주인이 되어야만 오너십이 발휘된다면 다른 모든 것에 있어서도 오너십을 발휘할 수 있는 것이 지극히 한정적일 것입니다. 즉 나는 거의 항상 오너십이 없는 사람인 셈이죠.&lt;/p&gt;
&lt;p&gt;거기에 그치지 않고 저는 "마인드셋은 습관"이라고 생각합니다. 다른 모든 종류의 마인드셋처럼 오너십이라는 것이 필요할 때 갑자기 생겼다가 필요 없으면 사라지는 것은 아니라고 생각합니다. 마인드셋은 나의 행동 원칙으로 늘 몸에 배어 있어야만 필요할 때에 실행할 수 있습니다. 내가 습관처럼 극한의 오너십을 발휘할 수 있어야만 정말 필요한 때에도 오너십을 발휘할 수 있다고 생각합니다.&lt;/p&gt;
&lt;p&gt;업무 상황에서 능동성을 발휘하는 모습의 예시를 몇 가지 들어보면 다음과 같습니다.&lt;/p&gt;
&lt;p&gt;조직 전체를 활용합니다. 주변 동료들을 활용하고 상사를 활용합니다. 가령 내가 어려움을 겪고 있는 문제가 있으면 혼자 끙끙 앓기보다는 문제가 있음을 적극적으로 주변에 알리고 도움을 요청합니다. 최선을 다하는 것이 목적이 아니라 문제 해결이 우리의 목적임을 기억해야 합니다. 목적 달성을 위해 도움을 받아야 한다면 기꺼이 이를 요청하고 받아야 합니다. 거꾸로 주변 동료와 상사가 나를 활용할 수 있도록 포지셔닝 해주기도 해야 합니다. 가령 나의 보스가 어떤 고민을 하고 있는지, 이를 어떻게 풀어낼 수 있을지 고민을 반드시 해야 합니다.&lt;/p&gt;
&lt;p&gt;주위에서 나를 쉽게 활용할 수 있도록 의사결정을 요청할 때에 거기에 단순히 어떻게 할까요를 매니저에게 묻기 보다는 '이러이러한 이유로 이렇게 진행하려 합니다'라는 구체적인 방안을 만들어 가는 것이 업무를 더 효과적으로 진척시키는 방법입니다. 내가 핸즈온에 더 가까운 사람으로서 전장의 디테일을 더 잘 알고 있기 때문에 이를 고려한 의사결정을 더 잘 내릴 수 있는 위치에 있습니다. 나의 매니저는 정렬을 더 명확하게 해줄 수 있을 것이고 이전에 겪어본 문제라면 관련 정보를 줄 수는 있겠으나 결국 내가 이에 대한 오너라는 생각을 해야 합니다. 해당 문제에 대한 오너십을 내가 갖고 있다면, 이를 대신 풀어줄 사람이 없다면 어떻게 했을지 생각해보면 결국 여러 사항을 고려한 의사결정의 초안을 내가 만들어야 한다는 것을 알 수 있습니다.&lt;/p&gt;
&lt;p&gt;동료들이 수행한 업무에 대해서도 '알아서 잘 했겠지'라고 넘기기보다 '내가 보기에는 좀 이상한데 왜 저런 선택을 했을까?'라는 질문으로 접근하는 것이 바람직합니다. 그 과정에서 나는 해당 내용에 대해 잘 모르고 저 사람이 전문가이니까 어련히 알아서 잘 했겠지는 극한의 오너십이 추구하는 방향이 아닙니다. 조금이라도 도메인이 달라지면 너무도 쉽게 동료의 이상한 의견을 무비판적으로 수용하기 쉽습니다. 특히 AI 도메인의 경우 매일같이 쏟아지는 새로운 테크닉 등으로 인해 내가 모든 것을 알고 있는 상태로 논의를 나누는 것이 무척 어렵습니다. 이런 경우에도 잘 이해가 되지 않는 부분은 반드시 문제를 제기하거나 명확히 확인하고 진행해야 합니다. 인생이라는 게임에 PC가 나밖에 없고 주변 사람들이 전부 NPC라면 어떨지의 가상의 상황을 상상해보세요. 기본적으로 NPC에게 책임을 묻는 것은 큰 의미가 없습니다. 이러한 관점에서 주변 동료들을 탓하는 것은 의미 없는 일입니다. 다만 동료들을 정말 PC로서 대한다면 제대로 된 책임감(accountability)을 요구해야 합니다. 그 의미를 곱씹어보세요. 팀이 더 나은 성과를 내기 위해 서로가 서로에게 책임감을 요구할 필요가 있습니다.&lt;/p&gt;
&lt;p&gt;안된다는 말에서 멈추지 않고 어떻게 하면 안 되던 것이 되게 할 수 있을지 고민하고 행동하는 것을 염두에 두어야 합니다. AI 조직은 필연적으로 데이터 및 모델 개발과 관련된 다양한 개인정보 및 법적 제약을 준수하는 것을 고민해야만 합니다. 이런 경우 단순히 '가능한가요?'라고만 법무팀에 문의하면 매우 위험 회피적인 답변을 듣기 쉽습니다. 능동적이지 못한 경우 매우 쉽게 안된다는 이야기를 들었다는 것만으로 포기하는 경우가 생기곤 합니다. 보다 능동적인 방법은 내가 달성하고자 하는 목표가 무엇인지 법률 담당자들에게 명확히 설명하고 가능과 불가능의 경계가 어디인지 파악하여 '되는 방법'을 함께 모색하는 것입니다. 법률 담당자가 기술을 나만큼 깊게 이해하고 있을 수는 없습니다. 나의 기술적 이해도를 토대로 제약조건을 만족하는 방법을 찾으면 방법이 존재하는 경우가 너무나도 많습니다.&lt;/p&gt;
&lt;p&gt;극한의 오너십과 높은 주체성으로 대표되는 능동성에 대한 강조는 단지 듣기 좋은 말을 반복하는 것에 불과하지 않습니다. 되려 이는 저희 AI 조직이 임팩트있는 솔루션을 제공하는데에 가장 중요한 내재적인 힘이라 할 수 있겠습니다. 저는 이러한 마인드셋이 어떤 영역에서든 개인이 높은 성취를 이루는 데 가장 중요한 가치라고 생각합니다.&lt;/p&gt;
&lt;p&gt;Proactive는 하이퍼커넥트의 일곱 가지 핵심가치 중 하나에 불과합니다. 나머지 다양한 가치에 대한 저의 해석도 앞으로 공유할 수 있도록 해보겠습니다.&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>Logical</title>
    <link href="https://shurain.net/blog/logical/" rel="alternate"/>
    <id>https://shurain.net/blog/logical/</id>
    <published>2024-10-04T00:00:00Z</published>
    <updated>2024-10-04T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>우리가 업무를 수행하며 논리적이어야 한다는 것은 당연하지만 어떻게 실천해야 좋은지 잘 감이 오지 않는 항목입니다. 저는 논리적이라는 항목에 대해 생각을 명확하게 표현 하여 헛점이 없는지 살펴볼 수 있도록 하고 논의 중인 명제에 대한 근거를 제시 하는 것이라 생각합니다.</summary>
    <content type="html">&lt;p&gt;우리가 업무를 수행하며 논리적이어야 한다는 것은 당연하지만 어떻게 실천해야 좋은지 잘 감이 오지 않는 항목입니다. 저는 논리적이라는 항목에 대해 &lt;strong&gt;생각을 명확하게 표현&lt;/strong&gt; 하여 헛점이 없는지 살펴볼 수 있도록 하고 논의 중인 명제에 대한 &lt;strong&gt;근거를 제시&lt;/strong&gt; 하는 것이라 생각합니다.&lt;/p&gt;
&lt;p&gt;우리가 흔히 논리적이라고 이야기하는 논리 전개 구조는 삼단논법을 띄게 마련입니다. "P가 참이고 P이면 Q라는 규칙이 있어서 Q이다." 의 modus ponens와 "P이면 Q의 규칙이 있는데 not Q이므로 not P이다." 의 modus tollens 두 가지가 가장 대표적인 예시입니다. 여기서 조금 더 나아가 단순히 참과 거짓인 명제만을 다루는 것이 아니라 그럴듯함(plausibility)에 대해 제대로 다루며 추론을 하기 위해서는 베이지안 추론 기법을 사용해야 합니다. 전통적인 삼단논법이 되었든 베이지안 추론 기법이 되었든, 시작은 내가 어떤 명제들을 가지고 어떤 규칙을 통해 이야기를 이끌어나가는지, 그 과정에서 잘못이 없는지를 살펴보는 것입니다.&lt;/p&gt;
&lt;p&gt;💡 삼단논법이 아닌 추론 기법에 대한 소개는 E.T. Jaynes의 Probability Theory: The Logic of Science의 전반부에서 잘 다루고 있습니다. 사실 베이지안 추론 기법이 어째서 불확실성을 다루는 가장 좋은 추론 체계인지 소개하는 내용이라 보아도 무방합니다.&lt;/p&gt;
&lt;p&gt;이를 위한 가장 좋은 방법은 &lt;strong&gt;글을, 특히 줄글 형태로 작성&lt;/strong&gt; 하는 것입니다. 글을 쓰는 행위와 명료한 생각의 관계에 대해서는 엄청나게 많은 사람들이 강조하였습니다. Andy Grove는 하이 아웃풋 매니지먼트에서 보고서를 작성하는 가장 중요한 이유는 보고서에서는 명시적으로 정리하며 글을 작성해야 하기 때문에 여러 사안들에 대해 훨씬 더 정밀해질 수 있기 때문이라 했습니다. 심지어 Andy Grove는 보고서의 작성은 중요하지만 읽는 것은 그렇게까지 중요하지 않다고 표현할 정도였죠. Jeff Bezos의 유명한 아마존 6-페이저도 비슷한 목적을 가지고 있습니다. 파워포인트에 불렛포인트로 정리된 내용은 사고의 구멍을 잘 드러내지 못하며 그렇기 때문에 아마존 6-페이저는 반드시 줄글로 작성하여 명료한 사고를 강제한 것이라 하였습니다. Jordan Peterson은 심지어 "Writing is thinking, formalized"라고 표현하였습니다.&lt;/p&gt;
&lt;p&gt;생각을 명시적으로 구체화하는 과정이 나의 생각에 있는 구멍을 없애는 방법입니다. 우리가 프로젝트를 시작하며 테크스펙을 쓰는 이유도, 논문을 실험이 완성되기 전에 미리 작성하라고 하는 이유도 다 마찬가지입니다. 사람들은 자기가 어떤 개념을 알고 있다고 이야기하지만 막상 설명을 해보라 시키면 설명을 어려워하는 것을 볼 수 있습니다. 해당 개념을 아주 친숙하게 알고 있지 않고 아는 것 같은 기분만 갖고 있기 때문입니다. 마찬가지로 사람들은 자기가 명료한 생각을 하고 있다고 생각하지만 막상 글을 써보게 시키면 명료하지 않은 생각의 파편만 머릿속에 들고 있었음을 알게 됩니다. 명확하게 직접적으로 글을 작성하는 것이야 말로 명료한 생각을 갖기 위한 시작점입니다. 비슷한 경험을 프로그래머들은 코드를 작성하면서 느끼게 되는 경우가 많습니다. 실수에 관대하지 않은 컴파일러/인터프리터를 채점자로 두며 그들이 이해할 수 있도록 한치의 빈틈이 없는 생각을 코드라는 구체적인 형태로 구현해야 하기 때문이죠.&lt;/p&gt;
&lt;p&gt;이러한 과정을 통해 명료하게 명제와 그 명제 사이를 잇는 규칙을 명시하였다면 각각의 명제의 가능성에 대해 고려해야 합니다. 이를 우리는 근거 기반의 사고라 부릅니다.&lt;/p&gt;
&lt;p&gt;버그를 만났을 때 어째서 프로그램이 이런 방식으로 동작하는지 시나리오를 상상해보고 문제가 될 것 같은 부분을 추정하는 것은 대단히 흔합니다. 이게 왜 이러지?라는 질문을 스스로에게 던져보고 어떤 기작에 의해 그러한 문제가 발생하는지 상상해보는 것은 대단히 중요한 과정입니다. 하지만 그렇게 만들어낸 가설이 맞는지 확인하는 과정이 없이 무작정 상상한 문제에 대한 해결책을 남발하는 것은 보통 효과적이지 않습니다. 우리는 이러한 디버깅 방법은 산탄처방(shotgun approach)라 부릅니다. 뭐라도 하나 걸려라라는 생각으로 다양한 시도를 하는 것이죠. 물론 이러한 진단적 치료가 의미있는 경우도 종종 있습니다. 하지만 당연하게도 이러한 경우는 진단적 치료의 비용이 원인을 파해치는 것보다 훨씬 쌀 때 뿐입니다.&lt;/p&gt;
&lt;p&gt;지금 구현체가 너무 느린 언어로 짜여져서 어쩔 수 없이 새로운 언어로 완전히 다시 구현을 해야 한다. 모델 학습에서 데이터 가챠가 있어서 특정 시점에 학습했던 모델만 성능이 좋다. 실제로 하이퍼커넥트 AI 조직에서 제가 들었던 문제에 대한 설명 및 제안 받은 해결책들입니다. 실제로는 파이썬이 느린 것이 문제가 아니라 우리가 원하지 않는 시점에 글로벌 GC가 돌아 세상이 멈추는 일이 있는 것이었고 이는 GC를 우리가 명시적으로 관리하면서 해결할 수 있었습니다. 모델은 특정 시점에 데이터와 모델이 잘 맞는 가챠가 있던 것이 아니라 학습 및 배포 전체의 파이프라인 곳곳에 엄청나게 많은 수의 미묘한 버그가 숨어있었고 그로인해 향후 새롭게 만드는 모델의 성능이 안 좋도록 하는 결과를 만들어 냈었습니다. 둘 다 사고의 흐름과 근거에 구멍이 있었으나 이를 명시적으로 이해하지 못하고 있었던 예라고 생각합니다.&lt;/p&gt;
&lt;p&gt;이런 방식의 사고의 함정을 빠져나오는 것이 쉽지는 않습니다. 내재적으로 불확실성이 내포된 명제를 바탕으로 추론을 해야 하기 때문입니다. 다만 여기에서 사용할 수 있는 방법은 앞서 말했다시피 명료하게 가정이 되는 명제와 추론 규칙을 명시하고 각각의 가정에 대한 그럴듯함도 드러내고 서로 이야기를 나눠보는 것입니다. 물론 이를 다루는 방식의 근본은 베이지안 추론 기법입니다.&lt;/p&gt;
&lt;p&gt;명시적으로 줄글을 통해 생각을 나열하고 각 명제에 대해 근거를 제시하는 것으로 보다 논리적으로 생각하는 것이 가능합니다.&lt;/p&gt;
&lt;p&gt;베이지안 추론 방식의 사고를 보여준 Alan Turing의 글로 마치겠습니다.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;The evidence concerning the possibility of an event occurring usually divides into a part about which statistics are available, or some mathematical method can be applied, and a less definite part about which one can only use one’s judgement. Suppose for example that a new kind of traffic has turned up and that only three messages are available. Each message has the letter V in the 17th place and G in the 18th place. We want to know the probability that it is a general rule that we should find V and G in these places. We first have to decide how probable it is that a cipher would have such a rule, and as regards this one can probably only guess, and my guess would be about 1/5,000,000. This judgement is not entirely a guess; some rather insecure mathematical reasoning has gone into it, something like this:-&lt;/p&gt;
&lt;p&gt;The chance of there being a rule that two consecutive letters somewhere after the 10th should have certain fixed values seems to be about 1/500 (this is a complete guess). The chance of the letters being the 17th and 18th is about 1/15 (another guess, but not quite as much in the air). The probability of a letter being V or G is 1/676 (hardly a guess at all, but expressing a judgement that there is no special virtue in the bigramme VG). Hence the chance is 1/(500 × 15 × 676) or about 1/5,000,000. This is however all so vague, that it is more usual to make the judgment “1/5,000,000” without explanation.&lt;/p&gt;
&lt;p&gt;The question as to what is the chance of having a rule of this kind might of course be resolved by statistics of some kind, but there is no point in having this very accurate, and of course the experience of the cryptographer itself forms a kind of statistics.&lt;/p&gt;
&lt;/blockquote&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>One Team</title>
    <link href="https://shurain.net/blog/one-team/" rel="alternate"/>
    <id>https://shurain.net/blog/one-team/</id>
    <published>2024-10-04T00:00:00Z</published>
    <updated>2024-10-04T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>우리는 단순히 개인의 집합으로서 일하기 보다는 함께 협력하여 더 큰 가치를 만들어 낼 수 있도록 하나의 팀으로 일합니다. 하나의 팀이라 하면 구성원 개개인이 하나의 목표를 함께 바라보며 일하는 것을 뜻합니다. 하나의 목표를 함께 바라본다는 말의 의미는 구성원 한 명 한 명이 매일 수행하는 업무가 결국 어떤 방식으로든 전사 목표에 기여해야 한다는 것을 의미합니다. 이를 위해서는 당연히 회사의 목표가 무엇인지 알아야만 합니다. 그리고 이를 아는 것에서 그치지 않고 내가 매일매일 수행하는 업무가 이를 반영하여 진행되도록 해야 합니다…</summary>
    <content type="html">&lt;p&gt;우리는 단순히 개인의 집합으로서 일하기 보다는 함께 협력하여 더 큰 가치를 만들어 낼 수 있도록 하나의 팀으로 일합니다. 하나의 팀이라 하면 구성원 개개인이 하나의 목표를 함께 바라보며 일하는 것을 뜻합니다. 하나의 목표를 함께 바라본다는 말의 의미는 구성원 한 명 한 명이 매일 수행하는 업무가 결국 어떤 방식으로든 전사 목표에 기여해야 한다는 것을 의미합니다. 이를 위해서는 당연히 회사의 목표가 무엇인지 알아야만 합니다. 그리고 이를 아는 것에서 그치지 않고 내가 매일매일 수행하는 업무가 이를 반영하여 진행되도록 해야 합니다. 이처럼 &lt;strong&gt;회사/조직/팀의 목표를 이해하고 이에 맞춰서 업무를 능동적으로 수행하는 것&lt;/strong&gt; 을 정렬(alignment)이라 부릅니다. 그리고 &lt;strong&gt;정렬에 one team의 핵심&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;우선 회사/조직의 목표를 아는 것에 대해 생각해봅시다. 회사는 앞으로의 미래를 그리는 비전(vision)이나 우리는 무엇을 하는 조직인지 나타내주는 미션(mission) 등을 설정하고 이를 어떤 방식으로 달성하는지 여러 업무 원칙(principles)이나 가치(value) 등을 이야기합니다. 일차적인 정렬은 이러한 전사/조직의 비전, 미션, 철학, 원칙, 가치 등을 이해하는 데에서 시작합니다.&lt;/p&gt;
&lt;p&gt;정렬의 관점에서 다음으로 고민해야 하는 것은 내가 매일매일 수행하는 업무가 전사 목표 달성에 어떤 방식으로 연결되는지 이해하는 것입니다. 한 가지 효과적인 방법은 우리가 어떤 제품을 통해 최종 사용자에게 가치를 전달하고 있는지 생각해보고 이에 대한 대가로 회사는 어떻게 돈을 벌고 있는지 알아보는 것입니다. 그리고 그러한 큰 그림이 그려졌을 때 나의 업무는 그 과정과 어떻게 연결되어 있는지 생각해보는 것이 유용합니다. 이를 보다 체계적으로 적어둔 것이 OKR입니다. OKR은 각 조직마다 어떠한 목표를 갖고 있으며 이를 어떤 수단을 통해 달성할 것인지를 명문화 한 것이라 생각할 수 있습니다. 달성 여부를 확실하게 판단할 수 있는 명확한 목표(objective)를 설정한 뒤, 해당 목표 달성을 위해 갖춰져야 하는 핵심 결과(key result)를 계층적으로 두어 구성원 수준에서 수행하는 업무가 어떤 방식으로 상위 목표까지 이어지는지 알 수 있도록 만든 방법입니다. 비록 OKR을 활용하지 않는 조직도 있으나 상위 목표가 하위로 연결되어 개인의 업무와 상위 조직의 정렬을 맞춘다는 핵심적인 생각은 OKR을 사용하지 않더라도 유효합니다.&lt;/p&gt;
&lt;p&gt;리더로서는 OKR이 아니라 하더라도 팀이 집중할 수 있도록 가능하면 뾰족한 목표를 잘 세워주는 것이 중요합니다. 과거 AI 조직에서 "Will it make the boat go faster?" 라는 이야기를 했던 적이 있습니다. 항상 가능하지는 않지만 가능하면 집중할 수 있는 명확한 목표를 제안하려고 부단히 노력해야만 합니다.&lt;/p&gt;
&lt;p&gt;개인의 입장에서 정렬을 보다 명확히 할 수 있는 한 가지 방법은 나의 상위 리더와 내가 공통의 끝 그림을 그리고 있는지 확인하는 것입니다. 이는 단순히 구성원이 현재 수행해야 하는 가장 중요한 업무 다섯 가지를 적어보되 이를 구성원과 리더가 별도로 적은 뒤에 서로 비교하는 것입니다. 이를 수행해보면 놀랍게도 서로 다른 생각을 갖고 있는 경우가 대단히 많습니다. 서로의 생각/우선순위를 직접적으로 확인하므로써 암묵적이던 정렬을 명시적으로 바꿔주는 방법입니다.&lt;/p&gt;
&lt;p&gt;정렬을 잘 맞춘다는 관점에서 모든 종류의 업무 관련 의사소통은 개방성을 강하게 요구합니다. 건설적인 갈등을 통해 무엇을 왜 하는지에 대해 정렬이 잘 된 상태를 만드는 것이 중요하며 결정된 사안에 대해 disagree and commit 할 수 있어야 합니다. 그 어떠한 조직도 완벽한 컨센서스를 달성하는 것은 어렵습니다. 그럼에도 리더는 상황에 맞게 불확실성을 안고 의사결정을 해야만 합니다. 마찬가지로 구성원은 이에 맞춰 본인의 생각과 다르다 하더라도 결정된 사안에 대해서는 믿고 수행할 수도 있어야 합니다.&lt;/p&gt;
&lt;p&gt;이렇게 함께 바라보는 목표로 나아갈 때에 서로 이상한 방향으로 가고 있다는 생각이 든다면 이를 명시적으로 이야기하며 서로에게 accountability를 요구할 수 있어야 합니다. 이러한 문화가 자리 잡아야 개인이나 팀이 본인의 욕심을 부려 회사의 성공에 방해가 되는 행위를 하는 것을 막을 수 있습니다. 하이 아웃풋 매니지먼트에서 이야기가 나왔던, 매니저의 아웃풋은 내 조직의 아웃풋과 내가 영향을 끼칠 수 있는 조직의 아웃풋을 합친 것이라는 것을 잊지 마시길 바랍니다. 내가 조금 더 멋져 보이는 성과를 내기 위해 회사의 목표를 달성하는데에 도움이 안 되는 업무를 굳이 수행하는 것, 우리 조직이 돋보이기 위해 전사적 목표 달성에 필수적인 다른 조직의 아웃풋에 해를 끼치는 것은 용납할 수 없습니다.&lt;/p&gt;
&lt;p&gt;그러므로 매니저로서 개인의 목표를 잘 이해하고 있는 것이 중요합니다. 우리는 협업을 통해 지속적인 컴파운딩을 하여 큰 가치를 만들어냅니다. 협업이 계속되기 위해서는 구성원도 회사도 원하는 것을 얻어가는 게임을 만들어야 합니다. 한 쪽의 착취가 계속된다면 그 협력은 지속될 수 없겠죠. 보상은 구성원이 원하는 것의 일부입니다. 보통 일을 통해 다들 얻고자 하는 것이 다양하게 있습니다. 특정 종류의 경험, 역량의 성장, 책임의 강화 등 여러 목표가 있을 수 있습니다. 매니저는 구성원의 이러한 욕구가 어디에서 기인하는지 잘 이해하고 구성원의 욕구와 회사의 목표를 어떻게 잘 정렬시킬 수 있는지 함께 고민해야 합니다. 컴파운딩을 통한 지수적인 성장을 살펴보면 가장 큰 보상은 마지막 단계에 만들어진다는 것을 기억하시길 바랍니다. 어떻게 영원히 지속되는 게임을 계속할 수 있을지 고민하는 것은 아주 중요하며 올바른 정렬이 핵심 아이디어 중 하나입니다.&lt;/p&gt;
&lt;p&gt;제대로 된 정렬은 목표를 아는 것에 그치지 않고 이에 맞춰 업무를 능동적으로 수행하는 것을 포함합니다. 능동적으로 일 하는 것에 대해서는 proactive 가치에 대해 논할 때에 여러 이야기를 했으니 거기에 더해 정렬이라는 관점에 집중하여 이야기 해보도록 하겠습니다. 우리가 회사에서 하는 업무의 대부분은 꽤 복잡도가 높으며 루틴하기 보다는 새로운 종류인 경우가 많습니다. 그렇기 때문에 모호하거나 불확실성이 높은 경우가 많죠. 실제로 많은 매니저들이 IC들에게 수행해달라고 부탁한 업무를 본인도 해본적이 없기 때문에 본인의 시간을 많이 쓰지 않고서는 가이드를 주기도 어렵고 그렇기 때문에 관리도 어렵다는 한탄을 많이 합니다. 현대적인 조직들이 이에 대응하는 방법은, 정렬이 잘 된 유능한 구성원들에게 최대한 필요한 정보와 권한을 주고 문화적인 가이드만 제공하므로써 개개인이 능동적으로 목표 달성을 할 수 있도록 하는 것입니다. 이러한 방법이 아니고서는 높은 복잡도, 불확실성과 모호함이 혼재하는 환경에서 빠르게 목표를 달성하는 것이 불가능합니다. 이에 대한 보다 자세한 이야기는 하이 아웃풋 매니지먼트의 챕터 10을 참고하시길 바랍니다.&lt;/p&gt;
&lt;p&gt;문제 자체가 복잡하고 이를 둘러싸고 있는 환경의 불확실성이 높으며 기본적으로 모호한 업무를 수행하면서도 상위 목표를 이해하지 않은 채 주어진 업무만을 수행하면 실질적인 목표 달성에 기여하지 못하고 있을 가능성이 매우 큽니다. 업무를 수행하면서 알게 되는 것들로 인해 불확실성이 줄어든다든지 풀어야 하는 문제가 변한다든지 하기 때문입니다. 그렇기 때문에 업무를 수행할 때에 무엇을 해야 하는지를 아는데에서 그치는 것이 아니라 왜 하는지도 반드시 이해하고 있어야 하며, 필요하다면 상황에 맞춰 더 좋은 방법을 제안하고 수행할 수 있어야 합니다. 책 Extreme Ownership에서는 이를 지휘권 분산(decentralized command)이라 표현하며 효과적인 팀의 운영에 반드시 필요하다고 하였습니다. 이러한 맥락에서 단순히 내가 목표를 이해하는 것에서 그치는 것이 아니라 관련 작업을 하는 모든 사람들이 같은 페이지에 있을 수 있도록 충분하게 배경과 정보를 공유/요청하고 업무 진행 상황에 대해 지속적으로 업데이트를 하는 것이 중요합니다.&lt;/p&gt;
&lt;p&gt;명시적으로 끝 그림을 맞춰보는 것을 통해 상위 목표와 나의 목표를 잘 맞추고, 책임감 있고 역량 있는 구성원으로서 상위 목표를 달성하기 위한 방법을 능동적으로 고민하며 일 하는 것이 one team 정신에 맞게 일 하는 것입니다.&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="ko">
    <title>Open</title>
    <link href="https://shurain.net/blog/open/" rel="alternate"/>
    <id>https://shurain.net/blog/open/</id>
    <published>2024-09-10T00:00:00Z</published>
    <updated>2024-09-10T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>하이퍼커넥트의 open이라는 원칙은 솔직하게 더 나은 대안이나 리스크를 공유하고 동료의 의견을 유연하게 경청하고 인정하는 것을 이야기하고 있습니다. 조직의 개방성(openness)은 대단히 중요한 조직의 문화입니다. 개방성이 중요한 이유에 대해서는 여러 매니지먼트 및 리더십 책에서 다루고 있는데, 대표적으로 팀워크의 부활(The Five Dysfunctions of a Team)이라는 책에서는 조직이 망가지는 다섯 가지 단계에 대한 이야기를 하고 있습니다. 해당 책에서는 조직 구성원 사이에 신뢰가 없으면 서로 갈등을 두려워하게…</summary>
    <content type="html">&lt;p&gt;하이퍼커넥트의 open이라는 원칙은 솔직하게 더 나은 대안이나 리스크를 공유하고 동료의 의견을 유연하게 경청하고 인정하는 것을 이야기하고 있습니다. 조직의 개방성(openness)은 대단히 중요한 조직의 문화입니다. 개방성이 중요한 이유에 대해서는 여러 매니지먼트 및 리더십 책에서 다루고 있는데, 대표적으로 팀워크의 부활(The Five Dysfunctions of a Team)이라는 책에서는 조직이 망가지는 다섯 가지 단계에 대한 이야기를 하고 있습니다. 해당 책에서는 조직 구성원 사이에 신뢰가 없으면 서로 갈등을 두려워하게 되고, 그렇게 되면 조직의 의사 결정을 받아들이지 않게 되면서 책임을 회피하게 되고 결과적으로 조직은 성과를 내지 못하게 되는 것을 조직의 다섯 가지 장애라고 불렀습니다. 이러한 프레임워크 하에서 개방적인 조직은 신뢰를 바탕으로 건설적인 갈등을 겪을 수 있는 조직을 말합니다. 거꾸로 이야기하면 &lt;strong&gt;건설적인 갈등이 일어나는 조직인가?&lt;/strong&gt; 라는 질문을 통해 조직의 개방성을 진단할 수 있다고 생각합니다.&lt;/p&gt;
&lt;p&gt;신뢰라는 표현도 업무의 문맥에서 다양한 의미를 지닙니다. 혹자는 상대가 이 업무를 잘 해낼 것이라는 믿음을 신뢰라고 표현하고 누군가에게는 상대가 예측 가능하게 행동할 것이라는 것을 신뢰라 표현합니다. 저에게 있어서는 상대와 건설적인 갈등을 겪어낼 수 있는 상황/조직이 신뢰가 있는 상황/조직입니다. 저는 구성원들이 서로를 너무 신뢰해서 누군가의 실수를 짚어주지 못했다든지 문제를 놓쳤다는 식의 이야기를 여러 번 들어봤습니다. 이는 신뢰가 아니라고 저는 생각합니다. 서로를 정말 너무 신뢰했다면 이상한 부분에 대해 지적하고 서로 피드백을 주고 받는 것이 쉬웠어야 합니다. 누군가를 너무 신뢰해서 이상한 부분을 짚어주지 못했다는 것은 사실 상대방에 대한 신뢰가 없기 때문에 이야기를 하지 못했다를 의미합니다. "저 사람이 어련히 알아서 잘 했겠지"라고 생각하고 넘어가는 것은 이를 뒷받침함 특별한 이유가 없다면 오너십이 없는 행동이고 상대에 대한 신뢰가 없지만 내가 책임지고 싶지 않기 때문에 하는 행동입니다.&lt;/p&gt;
&lt;p&gt;업무 환경에서 상호 신뢰를 구축하기 위해 친해지라는 조언을 많이들 합니다. 흔히들 이러한 조언을 사적으로 친해지라는 이야기로 해석하곤 합니다. 하지만 제 생각에 핵심은 사적으로 친해지는 것이 아닙니다. 어쩌면 사적인 친밀감이 공적인 신뢰로 이어질 수도 있을 수 있으나 이를 혼동해서는 안됩니다. 업무 환경에서 친해졌다는 것은 솔직하게 피드백을 주고 받을 수 있고 논쟁할 수 있음을 의미합니다. 열정적으로 논쟁하고 솔직하게 생각을 주고 받을 수 있기 위해서는 신뢰가 바탕이 되어야 합니다. 이는 여러 중요한 요소가 있는데 심리적 안정감을 갖추고 있는지, 서로 원하는 것이 무엇인지, 어떤 백그라운드를 가지고 있는지 등을 명확하게 아는 것을 의미합니다. 저는 팀원분들과 이야기를 할 때에 각자 인생의 목표가 무엇인지, 회사에서 하고 싶은 경험이 있는지, 그 근원이 어디에 있는지 등을 자주 여쭙습니다. 이는 제가 이를 이해하고 있어야 진정으로 그 사람이 원하는 것을 함께 업무를 통해 달성할 수 있는지 고민할 수 있기 때문입니다. 개인의 입장에서는 상대방이 내가 원하는 것이 무엇인지 알고 있고 이를 기저에 깔고 피드백을 줄 때에만 상대에 대한 신뢰를 가질 수 있습니다. 또한 저는 하얀 거짓말이나 유연하게 진실을 일부 숨기는 방식의 커뮤니케이션을 최대한 지양합니다. 이는 제가 하는 이야기에 대한 신뢰를 위해 반드시 필요합니다. 마찬가지로 단기적으로 저에게 손해가 될 수 있다고 하더라도 내가 상대방의 입장이라면 들어야만 하는 종류의 피드백을 드리려고 합니다. 이 또한 신뢰와 심리적 안전감을 구축하기 위한 저의 원칙입니다.&lt;/p&gt;
&lt;p&gt;보다 구체적으로 서로 의사소통을 하고, 피드백을 주고 받고, 갈등을 경험하는 과정은 질문/피드백을 하는 입장과 질문/피드백을 받는 입장으로 나눠서 생각해볼 수 있습니다. 각각의 경우 쓸모 있는 테크닉이 있으며 이를 숙지하고 계시면 도움이 많이 됩니다.&lt;/p&gt;
&lt;p&gt;질문을 할 때에는 위에서도 이야기 했지만 상대가 원하는 것이 정확히 무엇인지 어디에서 기인한 것인지를 잘 이해하고 있는 것이 중요합니다. 이는 평소에 다양한 대화를 통해 쌓을 수 있을 것입니다. 솔직한 피드백을 한다고 하여 아무 방식으로나 이를 쏟아내도 되는 것을 의미하는 것은 아닙니다. 한 가지 권장하는 대화 방법으로는 &lt;strong&gt;비폭력대화&lt;/strong&gt;(non-violent communication)의 프레임워크를 머릿속에 넣고 이야기를 하는 방법이 있습니다. 비폭력대화 기법은 관찰, 감정, 욕구, 요청의 단계로 이루어지는데 이는 흔히 이야기하는 피드백 기법인 &lt;strong&gt;SBI&lt;/strong&gt;(situation-behavior-impact)와도 무척 닮아있습니다. 비폭력대화의 접근 방식은 상대에 대한 이야기를 하기보다는 나의 상태에 대한 이야기와 그 근원에 대한 이야기를 하므로써 상대를 탓하는 방식의 대화를 피하면서도 솔직하게 상황에 대한 설명과 요청을 전달하는데에 중점을 두고 있습니다. 약간 다르지만 SBI는 어떤 상황에 상대의 어떤 행동으로 인해 어떤 임팩트가 있었는지에 대한 사실 기반의 의사소통을 통해 마찬가지로 가치 판단이나 상대방 자체에 대한 평가를 피하면서도 건설적인 피드백을 주는 것에 방점이 찍혀 있습니다. 이와 같은 대화/피드백 테크닉을 알고 이를 활용할 수 있어야 합니다.&lt;/p&gt;
&lt;p&gt;피드백을 듣는 입장에서 가장 어려운 점 중 하나는 억울함 마음이 드는 부분입니다. 보통 나는 열심히 했는데 못했다든지 틀렸다는 등의 피드백을 받으면 억울해지면서 흥분하기 쉽습니다. 이렇게 되면 피드백을 주는 사람들이 나를 대하는 것을 어려워하며 결과적으로 우리 조직이 건전한 갈등이 일어나지 않는 조직이 되어버리기 쉽습니다. 이는 본인 세상의 모든 것에 대한 책임을 져야한다는 마음가짐의 관점에서 제가 몇 차례 이야기했던 극한의 오너십과도 관련이 많이 있습니다. 저는 부부 관계에 대한 권위자인 가트만(Gottman) 교수의 4명의 기마병(four horsemen)에 대한 이야기를 읽으며 피드백을 차분하게 받는 방법에 대한 생각을 해본적이 많이 있습니다. 어떤 부부가 다툼이 있을 때 높은 확률로 이혼까지 이어지는 대화의 패턴이 있다고 합니다. 이는 각각 비난-방어-경멸-담쌓기라 부르는데, 재미있게도 부부 사이가 아니라고 하더라도 회사에서도 갈등이 심화되는 경우 거의 비슷한 방식의 대화가 오고가는 것을 많이 보았습니다. 스스로 &lt;strong&gt;방어적&lt;/strong&gt;이게 되는 것을 느끼면 이를 인지하고 여기에서 빠져나갈 수 있을 수 있도록 심리적인 장치를 마련해보시길 권합니다.&lt;/p&gt;
&lt;p&gt;개방성에 의거한 예시를 몇 가지 들어보도록 하겠습니다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;저 사람이 전문가이니까 알아서 잘 했겠지 👎&lt;/li&gt;
&lt;li&gt;잘 이해가 안되는 부분이 있는데 왜 그렇게 했는지 알려주실 수 있나요? 😊&lt;/li&gt;
&lt;li&gt;이상해 보이는데 내가 잘 몰라서 그렇겠지 👎&lt;/li&gt;
&lt;li&gt;이상해 보이는데 물어보고 배워야겠다 😊&lt;/li&gt;
&lt;li&gt;왜 내가 한 업무에 대해 의심을 갖지? 👎&lt;/li&gt;
&lt;li&gt;내가 놓친 것이 있나? 내 역량을 더 키울 수 있는 조언을 들을 기회인가? 😊&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;건설적인 갈등&lt;/strong&gt;이 충분히 우리 조직 내에서 일어나고 있는지를 우리 조직의 개방성의 척도로 생각하시길 바랍니다.&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="en">
    <title>Fantasy Walls and GPT-3</title>
    <link href="https://shurain.net/blog/fantasy-wall/" rel="alternate"/>
    <id>https://shurain.net/blog/fantasy-wall/</id>
    <published>2020-08-01T00:00:00Z</published>
    <updated>2020-08-01T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>There is a Korean fantasy fiction called " The bird that drinks tears ." It's a rare example of a fantasy fiction that got rid of many of the cliches in Western fantasies and replaced them with Korean concepts and cultures.</summary>
    <content type="html">&lt;p&gt;There is a Korean fantasy fiction called "&lt;a href="https://en.wikipedia.org/wiki/The_Bird_That_Drinks_Tears"&gt;The bird that drinks tears&lt;/a&gt;."
It's a rare example of a fantasy fiction that got rid of many of the cliches in Western fantasies and replaced them with Korean concepts and cultures.&lt;/p&gt;
&lt;p&gt;In the story, there is a particular artifact whose name translates to fantasy steps or illusion steps. They are artifacts that respond to your expectation and materialize your imagination. The catch is that the materialized object can only affect the person that imagined them. Only those who imagined them can see the objects, and only those who conjured them can feel the objects. Some people figured out that they could use the artifact to crystalize their thoughts and discover unrecognized implications. You could write on the wall just by imagination and edit them as needed.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;전체 문장을 자유자재로 변화시킬 수 있게 된다면 그 다음은 행간의 의미들을 보다 뚜렷하게 하고 그 의미들을 이용하여 전체 논리를 체계화하십시오. 예. 아마도 책을 정독하는 것과 비슷하다고 생각하실 겁니다. 저도 그렇게 생각합니다. 다른 방법이 있을지도 모르겠습니다만 제가 터득한 것은 이 방법뿐입니다. 책을 읽는다는 것은 그 책을 그대로 암기하는 것이 아니라 책을 이용하여 자신의 머릿속에 또 한 권의 책을 만들어내는 것과 비슷하다고 생각됩니다. 다만 당신이 만들어낸 구조물은 그 머릿속의 책을 현실로 시각화시켜줍니다. 그러다가 당신이 예상치 못한 문장들이 등장하게 되는 것을 보게 될 겁니다. 그것은 아마도 당신의 직관력이 찾아낸 문장이거나 결론일 겁니다. 그렇잖으면 문장들 자체가 스스로 이끌어낸 결론일 수도 있지요. 그런 문장들을 이용하여 다시 전체의 일을 반복하십시오. 당신은 당신이 알고 있는 것들을 완벽하게 체계화할 수 있을 겁니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;The process is oddly similar to my method of writing. I've used the technique frequently, but I never really gave a lot of thought into how it worked. It just did. After encountering GPT-3, I see some of the essences behind the process.&lt;/p&gt;
&lt;p&gt;For those of you who are not familiar with GPT-3, it is a large language model recently created by OpenAI. They trained to predict the next word given the previous words. This exceedingly simple method produced a "dumb" language model that has demonstrated an astonishing amount of capabilities. People created demos of using GPT-3 to &lt;a href="https://x.com/jsngr/status/1284511080715362304"&gt;create Figma designs&lt;/a&gt;, &lt;a href="https://x.com/plotlygraphs/status/1286079929982095360"&gt;chart generation&lt;/a&gt;, and of course, for &lt;a href="https://x.com/QasimMunye/status/1288912561178640385"&gt;different&lt;/a&gt; &lt;a href="https://www.gwern.net/GPT-3"&gt;kinds&lt;/a&gt; &lt;a href="https://x.com/Anthonyemberley/status/1287560874249474048"&gt;of&lt;/a&gt; &lt;a href="https://x.com/michaeltefula/status/1285505897108832257"&gt;writings&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Albeit impressive results, GPT-3 still is a basic pattern matching model. GPT-3 has no memory, cannot learn anything new, nor does it perform proper reasoning. It just predicts which word should come after the given words. But it is still remarkable that this simple model knows a lot about the world. You see an illusion or, rather, evidence of intelligence.&lt;/p&gt;
&lt;p&gt;It now seems to me that much of my thoughts are basic pattern matching.
One of the core elements of my writing process seems to be sampling sentences conditioned on the growing ingredients.
While I still learn from my writings and perform reasoning, the sampling process is also a significant part of my thinking process.
I can easily imagine a future where people use powerful language models as exploration machines to interrogate themselves for ideas unnoticed within themselves.
Some people even called GPT-3 &lt;a href="https://delian.substack.com/p/quick-thoughts-on-gpt3"&gt;"a racecar for the mind,"&lt;/a&gt; just as Steve Jobs described computers as "bicycles for the mind."
I don't know whether such large language models would become a racecar for the mind, but I strongly agree with the sentiment.&lt;/p&gt;
</content>
  </entry>
  <entry xml:lang="en">
    <title>Beginning</title>
    <link href="https://shurain.net/blog/beginning/" rel="alternate"/>
    <id>https://shurain.net/blog/beginning/</id>
    <published>2020-07-13T00:00:00Z</published>
    <updated>2020-07-13T00:00:00Z</updated>
    <author><name>Sungjoo Ha</name></author>
    <summary>About six years ago, I started writing every day and published them online 1 . When I began writing, I chose to write about things that my former self would have liked to know about. It went on for about 100 days, during which I learned a lot about myself. Some people found the articles helpful…</summary>
    <content type="html">&lt;p&gt;About six years ago, I started writing every day and published them online&lt;sup class="footnote-ref" id="fnref-1"&gt;&lt;a href="#fn-1"&gt;1&lt;/a&gt;&lt;/sup&gt;.
When I began writing, I chose to write about things that my former self would have liked to know about.
It went on for about 100 days, during which I learned a lot about myself.
Some people found the articles helpful, which was a satisfying experience.
But what got me really excited was the realization that writing helps me explore and organize my thoughts.&lt;/p&gt;
&lt;p&gt;I'd jot down random things related to the topic that I wanted to talk about&lt;sup class="footnote-ref" id="fnref-2"&gt;&lt;a href="#fn-2"&gt;2&lt;/a&gt;&lt;/sup&gt;.
After the initial setup, I'd start editing the post, adding and removing ideas as necessary.
It almost felt like I was having a conversation with myself.
I'd posit a question, then answer it. Ask the following question then answer it again.
I'd scribble a bunch of loosely related ideas and talk to myself about them.
Repeat the process over and over again until I have enough material to complete a piece.
Then I'd throw away almost all of the contents, refining them to a few core ideas.&lt;/p&gt;
&lt;p&gt;Now that a few years have passed, I'd like to start writing again to reflect on myself and organize my thoughts.
The process itself will be my prize, but hopefully, the byproducts will help other people as well.&lt;/p&gt;
&lt;div class="footnotes"&gt;
&lt;hr&gt;
&lt;ol&gt;&lt;li id="fn-1"&gt;&lt;p&gt;You can still visit the &lt;a href="https://dotd.shurain.net/"&gt;blog&lt;/a&gt;. Unfortunately, it's written in Korean.&lt;a href="#fnref-1" class="footnote"&gt;&amp;#8617;&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li id="fn-2"&gt;&lt;p&gt;Picking the subject is another fascinating topic worth exploring, which I intend to visit later with another post.&lt;a href="#fnref-2" class="footnote"&gt;&amp;#8617;&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;/div&gt;
</content>
  </entry>
</feed>
