2026년 7월 20일 노드 15개 #Framework#FirstPrinciples#Reasoning#DecisionMaking
제1원리 사고
관성 가정을 드러내고, 사실 단위로 분해하고, 백지에서 재조립하는 제1원리 사고의 실무 절차. 비용 구조와 기술 선택 두 가지 적용 예시, 유추 사고와의 역할 분담, 남용을 막는 경계선까지.
브리프 전문
제1원리 사고는 더 이상 부술 수 없는 사실까지 문제를 분해한 뒤 그 위에서 해법을 다시 쌓는 방식이다. 유추(남들이 하는 방식의 변형)보다 수십 배 느리고 비싸다, 그래서 아무 데나 쓰는 도구가 아니라 관행의 가격이 유난히 비싸 보이는 지점에 쓰는 정밀 도구다. 절차는 셋이다: 관성 가정을 드러내고, 사실 단위로 분해하고, 재조립한다.
1단계: 관성 가정 식별 #
'원래 그렇게 한다'를 전부 문장으로
현재 방식에 깔린 전제를 남김없이 문장으로 적는다, '이 기능엔 서버가 필요하다', '이 가격 밑으로는 못 판다'. 적기 전까지 가정은 공기처럼 보이지 않는다. 가장 좋은 채집 도구는 신참과 외부인의 질문이다. '왜 이렇게 해요?'에 '원래 그래요'로 답하게 되는 지점이 전부 후보다.
가정 분류 질문 #
물리 법칙인가, 규제인가, 그냥 관행인가
적어낸 가정을 세 등급으로 나눈다. 자연법칙과 수학은 못 건드린다, 규제와 계약은 비싸지만 바꿀 수 있다, 관행과 업계 통념은 그냥 아무도 다시 안 물어본 것이다. 대부분의 조직에서 세 번째가 압도적으로 많다는 사실 자체가 이 단계의 수확이다. 등급을 매길 때는 '누가 이것을 어긴 사례가 있는가'가 가장 빠른 리트머스다.
2단계: 분해 #
더 못 쪼개는 사실 단위까지 내려간다
문제를 구성 요소로 쪼개되, 각 조각이 검증 가능한 사실이 될 때까지 쪼갠다. '클라우드 비용이 비싸다'는 분해가 아니고, '요청당 평균 연산량, 단위 연산의 시장가, 트래픽 분포'까지 내려가야 분해다. 쪼개다 보면 문제 정의 자체가 틀렸음을 발견하는 경우가 많고, 그것이 이 단계의 흔한 보너스다.
분해의 단위 #
비용이면 BOM, 프로세스면 필요조건
어디까지 내려가야 하는지는 대상에 따라 다르다. 물건이면 자재명세서(BOM)와 시장 단가, 소프트웨어 비용이면 연산·저장·전송의 원단위, 프로세스면 각 단계가 진짜로 충족해야 하는 요구조건이다. 판별법은 하나다, 그 조각의 값을 제3자가 독립적으로 확인할 수 있으면 사실 단위에 도달한 것이다.
3단계: 재조립 #
사실 위에서 최적 해법을 다시 쌓는다
분해로 얻은 사실들만 갖고 백지에서 해법을 조립한다. 기존 해법은 참고가 아니라 비교 대상이다. 재조립의 결과가 기존 방식과 같아도 실패가 아니다. 이제 그 방식을 '남들이 해서'가 아니라 '사실이 지지해서' 쓰는 것이므로 방어력이 다르다. 다르게 나왔다면 어느 가정을 버렸기에 달라졌는지 지목할 수 있어야 한다.
재조립 규율 #
달라진 지점마다 버린 가정을 지목한다
새 해법이 기존과 갈라지는 지점마다 '버린 가정 몇 번 때문'이라는 표를 달아 둔다. 이 표가 없으면 재조립은 그냥 참신한 아이디어와 구분되지 않고, 반대자와의 논쟁도 취향 싸움이 된다. 버린 가정이 사실은 규제였음이 나중에 드러나는 경우가 최악이므로, 1단계의 분류가 여기서 다시 소환된다.
함정: 분해에서 멈추기 #
비판만 있고 재조립이 없으면 반쪽
가정을 부수는 데서 쾌감이 끝나는 세션이 많다, 기존 방식의 허점 목록만 남고 대안은 없다. 분해는 중간 산출물일 뿐이고 결과물은 언제나 '그래서 무엇을 다르게 한다'는 재조립안이다. 세션 시작 전에 산출물 형식(새 구성안 + 버린 가정 목록)을 못 박아 두면 이 함정을 대부분 피할 수 있다.
유추 사고와의 대비 #
적이 아니라 용도가 다른 도구
유추는 검증된 방식을 빌려 오는 것으로, 빠르고 싸고 대체로 옳다. 일상 결정의 9할은 유추로 처리하는 것이 맞다. 제1원리는 유추가 막혔을 때, 즉 기존 방식의 비용이 구조적으로 이상해 보이거나 모두가 같은 벽 앞에 서 있을 때 꺼내는 도구다. 전부 제1원리로 하겠다는 선언은 대개 아무것도 끝내지 못하는 상태로 이어진다.
언제 무엇을 쓰나 #
되돌리기 비용과 관행의 가격으로 판단
결정을 되돌리기 쉬우면 유추로 빨리 가고 틀리면 고친다. 되돌리기 어렵고(아키텍처, 장기 계약), 그 영역의 관행 가격이 유난히 비싸다는 냄새가 나면 제1원리 구간이다. 좋은 신호는 '모두가 그 비용을 불평하면서 아무도 구조를 다시 계산해 본 적 없는' 항목이다.
실무 예시: 비용 구조 #
견적이 아니라 원단위에서 다시 계산
'업체 견적이 이 정도'는 유추다. 제1원리로는 그 서비스가 소비하는 원자재(연산, 스토리지, 인건비 시간)를 시장 단가로 다시 곱해 이론상 바닥 가격을 만든다. 견적과 바닥의 격차가 곧 협상 여지이거나 내재화 기회다. 로켓 재료비가 완성품 가격의 한 자릿수 퍼센트라는 계산에서 재사용 로켓이 나온 것이 이 패턴의 교과서 사례다.
원가의 바닥 찾기 #
격차의 정체를 세 가지로 해부한다
이론상 바닥과 실제 가격의 격차는 보통 세 가지로 분해된다: 공급자의 마진, 비효율(내가 안 쓰는 기능의 끼워팔기), 그리고 리스크 프리미엄. 셋 중 무엇이 큰지에 따라 대응이 다르다. 마진이면 협상과 경쟁 입찰, 끼워팔기면 요구사항 재정의, 리스크 프리미엄이면 그 리스크를 내가 흡수할지 계산한다.
실무 예시: 기술 선택 #
'다들 쓰니까' 스택에서 요구사항 스택으로
'요즘은 다 이 프레임워크 쓴다'는 유추이고, 대부분의 경우 그것으로 충분하다. 제1원리가 필요한 순간은 그 선택이 비용이나 제약으로 되돌아올 때다. 이때는 실제 요구량(트래픽, 지연 한도, 데이터 크기, 팀의 운영 역량)을 숫자로 놓고 최소로 충족하는 구성을 역산한다. 유행 스택의 상당수는 우리에게 없는 규모 문제를 푸는 도구라는 결론이 자주 나온다.
요구사항을 물리량으로 #
형용사를 숫자로 바꾸면 선택지가 줄어든다
'대용량', '실시간', '확장 가능' 같은 형용사를 초당 요청 수, 허용 지연 ms, 연간 데이터 증가량으로 바꾼다. 숫자가 나오면 후보 기술의 절반 이상이 저절로 탈락하거나 과잉으로 판명된다. 숫자를 못 구하겠다면 그것은 기술 선택의 문제가 아니라 제품 정의가 덜 된 것이니, 선택을 미루는 쪽이 옳은 결정이다.
남용 주의 #
모든 회의를 백지에서 시작하면 망한다
제1원리는 세션당 비용이 크다, 팀 전체가 가정을 캐고 검증하는 데 며칠이 든다. 그래서 분기에 한두 개의 구조적 질문에만 쓰고 나머지는 관행으로 빠르게 처리하는 것이 건강한 배분이다. '왜요?'를 모든 안건에 던지는 사람은 제1원리 사고가가 아니라 회의를 마비시키는 사람이 되기 쉽다.