<div id="readability-page-1" class="page"><article dir="ltr" data-pagefind-body="true"><h2>개발자가 조직을 보기 시작하면 — 답이 없는 문제를 '풀리게' 만드는 법</h2><p><img src="https://feel5ny.github.io/images/2026/06/07/thumb_default.jpg" alt="개발자가 조직을 보기 시작하면 — 답이 없는 문제를 '풀리게' 만드는 법"></p><h2 id="답이-있는-문제에서-답이-없는-문제로">답이 있는 문제에서, 답이 없는 문제로</h2>
<p>개발자로 일하는 동안 내가 풀던 문제는 대부분 “답이 있는 문제”였다. 버그에는 원인이 있고, 스펙에는 구현해야 할 정답이 있고, 막히면 먼저 풀어 둔 누군가의 답이 어딘가에 있었다. 길은 대체로 정의돼 있었고, 나는 그 길을 잘 따라가면 됐다.</p>
<p>그런데 역할이 조금씩 바뀌면서 마주하는 문제의 성격도 달라졌다. 정답이 정해지지 않은, 오래 걸리는 문제들. 누가 모범답안을 주지 않고, 결과가 한참 뒤에야 보이는 문제들이다. 돌이켜보면 이건 연차가 쌓이면서 자연스럽게 겪는 변화 같다. 연차가 얕을 땐 답이 있는 것만 좇아도 편안했다. 누군가 이미 정의해 둔 길을 따라가면 됐으니까. 그런데 연차가 쌓일수록 더 많은 부분이 보이기 시작한다. 그리고 그 보이는 것들이 다 답이 나와 있는 건 아니다. 사람들이 정의해 준 길을 따라가다 막다른 길을, 아직 아무도 정리해 두지 않은 표면을 마주하게 된다.</p>
<p>개발을 넘어 조직을 보기 시작할수록 이런 문제의 비중이 커진다. 그러던 차에 우연히 오스틴 클레온의 『킵고잉(Keep Going)』을 집어 들었다. 기대 없이 펼친 책인데, 답이 없는 문제 앞에서 어떤 태도로 서야 하는지에 대한 말들이 계속 나왔다. 나중에 보니 내가 사진으로 남긴 페이지들이 전부 <em>과정</em>, <em>불확실성</em>, <em>형편없이 시작하기</em>에 관한 것이었다. 손이 이미 지금 필요한 페이지를 골라낸 셈이다.</p>
<p>흥미로운 건, 이 책이 예술가와 창작자를 위한 책이라는 점이다. 창작자의 책이 왜 개발자인 나에게 이렇게 맞물리는지, 처음엔 좀 의아했다. 그 이유는 책을 덮고 나서야 분명해졌다.</p>
<img src="https://feel5ny.github.io/images/2026/06/07/01.jpeg" alt="Keep Going">
<h2 id="속도를-늦추고-사색하기">속도를 늦추고, 사색하기</h2>
<p>답이 없는 문제일수록 오히려 일에 매몰되기 쉽다. 길이 안 보이니 더 붙잡고, 더 몰아붙이게 된다. 책은 그럴 때 속도를 늦추라고 말한다.</p>
<blockquote>
<p>“신경이 반응하는 속도를 늦추어야 한다.” — 존 스타인벡</p>
</blockquote>
<blockquote>
<p>“사진이 즉각적인 반응이라면, 드로잉은 명상이다.” — 앙리 카르티에 브레송</p>
</blockquote>
<p>답이 없는 문제는 책상 앞에서 더 오래 앉아 있는다고 풀리지 않는다. 오히려 한 발 떨어져 천천히 바라보는 시간에서 다른 실마리가 나온다. 그래서 ‘쉼’은 일을 멈추는 게 아니라 일의 일부였다.</p>
<p>읽으면서 나에게도 그런 시간이 필요하다는 걸 인정하게 됐다. 거창할 필요는 없다. 나에게는 육아가 그 역할을 해주기도 한다. 시간이 비면 또 일하거나 딴짓으로 흘러가는 나 같은 사람에게는, 강제로 일에서 끌어내 주는 장치가 오히려 고맙다. 다만 그것과는 별개로, 가끔은 온전히 나에게만 집중하며 사색하는 시간도 필요하다는 걸 알게 됐다.</p>
<h2 id="답이-없는-일의-연료--보상에서-가설로">답이 없는 일의 연료 — 보상에서 가설로</h2>
<p>답이 없는 문제를 하고 있으면 계속 과정 속에 머물게 된다. 그제야 또 다른 문장이 와닿았다.</p>
<blockquote>
<p>“예술가라면 그 결과물을 얻어내기 위한 과정까지도 사랑해야 한다.” — 로버트 파라 카폰</p>
</blockquote>
<blockquote>
<p>“희망은 알지 못하고, 알아낼 방법도 없는 상태를 반긴다.” — 리베카 솔닛</p>
</blockquote>
<p>생각해 보니 답이 없는 일에도 두 종류가 있었다. <strong>짧게 끝나는 일</strong>은 답이 없어도 금방 결과가 나오고, 그 승리감·안도감이 바로 보상으로 돌아온다. 그 보상이 나를 밀어주는 연료였다. 그런데 <strong>오래 걸리는 일</strong>은 그 보상이 한참 동안 오지 않는다. 그러면 다른 연료가 필요하다. 책은 그걸 ‘희망’이라 부르지만, 개발자인 내 식으로 옮기면 <em>가설</em>에 가깝다. “결과는 확정되지 않았지만 이 방향이 맞다고 보고, 나아가며 검증한다”는 태도다.</p>
<p>답이 있는 문제만 풀 땐 즉각적인 보상이 연료였다. 답이 없는 문제로 넘어오면, 연료를 ‘즉각적인 보상’에서 ‘가설’로 갈아끼워야 한다. 잃는 게 아니라, 일종의 졸업이다.</p>
<h2 id="가설이-자기기만이-되지-않으려면">가설이 자기기만이 되지 않으려면</h2>
<p>그런데 가설을 믿고 나아가는 데에는 위험도 있다. 검증을 게을리하면, 나중에 보면 최악으로 가고 있었는데 스스로를 속이고 있던 것일 수도 있다. 그래서 목표와 원칙이 중요하다.</p>
<p>나는 이걸 이렇게 정리했다.</p>
<ul>
<li><strong>가설 = 엔진.</strong> 검증되지 않았어도 일단 나아가게 한다.</li>
<li><strong>목표 = 핸들.</strong> 어디로 갈지 정한다.</li>
<li><strong>원칙 = 가드레일이자 검사기.</strong> 지금 가는 게 진짜 전진인지, 아니면 나를 속이는 중인지 판별해 준다.</li>
</ul>
<p>엔진만 있고 핸들과 가드레일이 없으면, 그대로 최악을 향해 처박힌다.</p>
<p>건강한 가설과 자기기만을 가르는 기준도 분명해졌다. 자기기만은 결과를 미리 단정한다. “잘 될 거야”라고. 이건 답을 안다고 우기며 검증을 거부하는 것이다. 건강한 가설은 결과를 모른다는 걸 인정한 채, 피드백으로 계속 검증받는다. 그래서 판별법은 이렇다 — <strong>믿음을 유지하려고 피드백을 자꾸 무시하거나 기준을 낮춰야 한다면, 그건 자기기만이다.</strong> 원칙이 그대로 서 있고, 피드백이 “반걸음 나아갔다”고 말한다면, 그건 검증되고 있는 가설이다.</p>
<h2 id="매일-조금씩-이어가기--데일리-로그">매일 조금씩 이어가기 — 데일리 로그</h2>
<p>답이 없는 문제의 가장 큰 어려움은 ‘길다’는 것이다. 한 번에 풀리지 않으니 며칠씩, 몇 주씩 끌고 가야 하는데, 그 사이에 맥락이 휘발된다. 며칠만 손을 놓아도 “내가 어디까지 생각했더라”가 사라진다.</p>
<p>그래서 나는 옵시디언에 데일리 로그를 쓴다. 매일 그날 한 일과 떠오른 생각, 막힌 지점을 남긴다. 별것 아닌 습관 같지만, 답이 없는 문제를 다루는 데에는 두 가지로 큰 도움이 된다.</p>
<p>하나는 <strong>연속성</strong>이다. 오래 걸리는 문제도 ‘어제의 내’가 남긴 메모에서 이어받아, ‘오늘의 내’가 반걸음 더 나아간다. 맥락이 머릿속이 아니라 문서에 살아 있으니, 며칠 잊어버려도 다시 이어 붙일 수 있다. 뒤에서 말할 “내가 손 떼도 굴러가게”를, 우선 나 자신에게 적용하는 셈이다.</p>
<p>다른 하나는 <strong>회고</strong>다. 그날의 판단과 감정까지 적어 두면, 시간이 지나 다시 읽었을 때 내 패턴이 보인다. 가설이 건강하게 검증되고 있는지, 아니면 어느새 자기기만으로 새고 있는지 — 그걸 비춰 주는 검사기도 결국 이 기록들이다.</p>
<p>답이 없는 문제는 한 번에 풀 수 없다. 그러니 매일 조금씩 이어가는 도구가 필요하다. 나에게는 데일리 로그가 그 연속성을 만들어 준다.</p>
<h2 id="내가-만들-수-있는-것--풀리게-만들기">내가 만들 수 있는 것 — 풀리게 만들기</h2>
<p>조직을 보기 시작하면서 내가 가장 크게 바꾼 생각은 이것이다. <strong>내 일은 모든 문제를 내가 직접 푸는 게 아니라, 조직이 풀 수 있도록 판을 짜는 것</strong>이라는 점. 답이 없는 문제일수록 더 그렇다. 내가 다 끌어안으면 모든 게 나에게 묶이고, 내가 빠지는 순간 멈춘다.</p>
<p>그래서 목표도 “이 문제를 내가 끝내 푸느냐”가 아니라 “내가 손을 떼도 굴러가느냐”로 옮겼다. 답을 내가 쥐고 있는 게 아니라, 답을 찾아갈 수 있는 구조와 맥락을 남기는 것. 내가 아는 것을 나만 아는 채로 두지 않고, 남이 보고 이어갈 수 있게 만드는 것. 완성이 아니라, ‘내가 없어도 사라지지 않는’ 지점까지.</p>
<p>이렇게 두면, 결과가 늦게 오더라도 적어도 <em>남길 건 남았다</em>는 사실이 확보된다. 그리고 무엇보다, 문제가 한 사람에게 묶이지 않는다.</p>
<p>가끔 이런 일을 하다 보면 ‘나는 이제 개발에서 멀어지는 건가’ 싶을 때가 있다. 그런데 Charity Majors는 엔지니어와 리더(매니저) 역할이 한 방향 사다리가 아니라 진자처럼 오가는 것이라고 말한다(<a href="https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/" target="_blank" rel="noreferrer">The Engineer/Manager Pendulum&nbsp;<svg fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.7" viewBox="0 0 24 24" height="1em"><path d="M7 17L17 7"></path><path d="M7 7h10v10"></path></svg></a>). 조직 쪽으로 가는 건 개발을 졸업하는 게 아니라, 잠시 다른 쪽으로 스윙하는 것에 가깝다. 그는 “최고의 기술 리더는 실무와 리더십 사이를 왔다 갔다 해 본 사람”이라고 했다. 그래서 나도 한 발은 기술에 담가 두려 한다. 조직의 판을 짜는 판단도 결국, 충분히 아는 사람이 내릴 때 제대로 서기 때문이다.</p>
<blockquote>
<p>“형편없는 작업을 해 봐. (…) 무엇보다도 편안한 마음과 망칠까 봐 두려워하지 않는 자세가 가장 중요하다네.” — 솔 르윗이 에바 헤세에게</p>
</blockquote>
<h2 id="답을-아는-사람이-아니라">답을 아는 사람이 아니라</h2>
<p>역할이 넓어진다는 건 답을 다 아는 사람이 되는 게 아니었다. 오히려 답이 없는 문제를 견디고, 가설을 세워 검증하며, 내가 없어도 남을 것을 만들어 두는 — 그런 역량과 마인드셋을 기르는 일에 가깝다.</p>
<p>그제야 창작자의 책이 나에게 맞물린 이유도 분명해졌다. 예술가가 하는 일의 본질은 답이 정해지지 않은 곳에서 무언가를 만들어 내는 것이다. 백지 앞에서 자기 가설을 세우고, 형편없을지언정 시작하고, 결과가 보이지 않는 과정을 견디는 것. 그런데 답이 없는 문제를 마주한 사람이 하는 일도 정확히 그렇다. 정해진 길이 없는 곳에서 방향을 만들고, 사람들과 함께 형태를 잡아 간다. 결국 이 단계의 일은 그 자체로 하나의 창의적인 행위였다. 개발이 정해진 답을 구현하는 일이라면, 답이 없는 문제를 푸는 건 — 직군과 상관없이 — 창작에 가깝다.</p>
<p>물론 ‘창작’이라는 말은 거창하게 들린다. 예술가도 천재도 아닌데 무슨 창작인가 싶었다. 그런데 문화심리학자 김정운은 『에디톨로지』에서 “창조는 편집이다”라고 말한다. 창조는 무에서 유를 만드는 게 아니라, 이미 존재하는 것들을 자기만의 관점으로 새롭게 엮어내는 일이라는 것이다. 그는 오늘날의 지식인을 “정보와 정보의 관계를 잘 엮어내는 사람”이라고 했다.</p>
<img src="https://feel5ny.github.io/images/2026/06/07/02.jpeg" alt="에디톨로지">
<p>그렇게 보면 답이 없는 문제를 풀어 가는 일도 결국 편집이다. 흩어진 맥락과 사람, 조각난 정보들을 모아 하나의 방향으로 엮어내는 것. 그리고 내가 매일 데일리 로그를 쓰고 노트를 연결하는 것도, 작게 보면 그 편집의 연습이다. 창작은 백지에서 솟아나는 재능이라기보다, 모으고 잇는 꾸준함에 가까웠다.</p>
<p>우연히 집어 든 책이, 요즘 내가 하던 가장 어려운 고민에 언어를 붙여줬다. 그래서 더 기억에 남는 책이다. 답이 없는 문제 앞에서 또 흔들릴 때, 다시 꺼내 읽을 것 같다.</p><h2>Related</h2></article></div>

필오의 개발일지

답이 있는 문제만 풀던 개발자가 답이 없는 문제를 마주하며, 오스틴 클레온의 『킵고잉』에서 얻은 태도 — 가설로 나아가기, 데일리 로그로 이어가기, 그리고 창작은 곧 편집이라는 것

개발자가 조직을 보기 시작하면 — 답이 없는 문제를 '풀리게' 만드는 법

댓글