<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DEVELOPHO Decision Journal</title>
    <link>https://developho.com/journal/</link>
    <description>부동산 개발·투자·금융·사업 시스템에 관한 DEVELOPHO의 실무 관점과 의사결정 기록입니다.</description>
    <language>ko-KR</language>
    <atom:link href="https://developho.com/rss.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>사업은 결국 숫자로 설득된다</title>
      <link>https://developho.com/journal/business-is-persuaded-by-numbers/</link>
      <guid isPermaLink="true">https://developho.com/journal/business-is-persuaded-by-numbers/</guid>
      <pubDate>Fri, 17 Jul 2026 00:00:00 +0900</pubDate>
      <description>사업 아이디어를 매출 구조, 비용, 현금흐름과 검증 가능한 가정으로 바꾸어 의사결정 기준을 세우는 방법을 다룹니다.</description>
      <content:encoded><![CDATA[
<p>새로운 사업을 설명할 때 아이디어의 매력은 대화를 시작하게 한다. 하지만 실제 의사결정은 그 아이디어가 어떤 방식으로 고객을 만들고, 얼마의 비용으로 운영되며, 언제 현금을 회수하는지 설명할 수 있을 때 비로소 움직인다. 숫자는 사업의 가능성을 과장하기 위한 장식이 아니라 서로 다른 관점을 같은 기준 위에 놓는 언어다.</p>
<h2>매출보다 먼저 구조를 설명한다</h2><p>예상 매출만 크게 제시하면 계획은 쉽게 흔들린다. 고객 한 명을 확보하는 비용, 한 번의 거래에서 남는 금액, 반복 구매 가능성과 고정비를 함께 봐야 한다. 매출은 가격과 수량의 결과이며, 수량은 채널과 운영 역량의 제약을 받는다. 각 숫자의 앞뒤 관계가 보여야 가정이 현실적인지 판단할 수 있다.</p>
<p>좋은 사업계획은 정답처럼 보이는 단일 수치를 제시하지 않는다. 기준, 낙관, 하락 시나리오를 나누고 어떤 변수가 손익에 가장 큰 영향을 주는지 드러낸다. 가격이 조금 낮아졌을 때, 일정이 늦어졌을 때, 고객 확보 비용이 높아졌을 때 필요한 현금이 어떻게 달라지는지 확인하면 토론은 감상에서 의사결정으로 바뀐다.</p>
<h2>현금의 시간을 함께 본다</h2><p>손익계산서에 이익이 있어도 현금이 부족할 수 있다. 매출이 발생하는 시점과 대금이 들어오는 시점, 비용을 먼저 지급해야 하는 시점이 다르기 때문이다. 초기 투자와 운전자금, 세금과 금융비용을 일정에 연결하면 얼마의 자금이 언제 필요한지 보인다.</p>
<p>이 과정은 투자자나 금융기관만을 위한 것이 아니다. 대표와 운영팀이 채용, 마케팅, 설비 투자의 우선순위를 정하는 기준이 된다. 목표를 매출 한 줄로 두는 대신 거래 수, 전환율, 객단가, 공헌이익과 현금 잔액으로 나누면 실행 단계에서 무엇을 관리해야 하는지도 선명해진다.</p>
<h2>숫자의 근거를 기록한다</h2><p>숫자가 있다고 해서 모두 설득력이 있는 것은 아니다. 출처와 산식, 적용 기간이 분명해야 한다. 아직 확인되지 않은 값은 사실처럼 포장하지 않고 가정으로 표시해야 한다. 실제 결과가 나오면 가정과 비교해 차이의 원인을 기록하는 과정도 필요하다.</p>
<p>의사결정 기준도 사전에 정해 둘 필요가 있다. 어느 수준의 매출이면 계속 투자할지, 손실이 어느 범위를 넘으면 계획을 조정할지, 추가 자금이 필요할 때 무엇을 먼저 줄일지를 미리 합의하면 결과가 나쁜 순간에도 일관된 판단을 할 수 있다. 숫자는 미래를 정확히 맞히기보다 선택의 조건과 책임을 분명하게 만드는 데 가치가 있다.</p><p>사업은 숫자만으로 결정되지 않는다. 고객의 문제, 팀의 역량과 시장 변화처럼 정량화하기 어려운 요소도 존재한다. 다만 숫자로 표현할 수 있는 부분을 먼저 구조화하면 불확실한 부분이 어디인지 더 정확히 보인다. 결국 설득력은 큰 전망치가 아니라 가정과 결과를 연결하고, 틀렸을 때 수정할 수 있는 구조에서 나온다.</p>]]></content:encoded>
    </item>
    <item>
      <title>호텔 개발은 부지를 찾는 일에서 끝나지 않는다</title>
      <link>https://developho.com/journal/hotel-development-is-not-just-site-selection/</link>
      <guid isPermaLink="true">https://developho.com/journal/hotel-development-is-not-just-site-selection/</guid>
      <pubDate>Fri, 17 Jul 2026 00:00:00 +0900</pubDate>
      <description>호텔 개발의 입지 이후 운영 방식, 사업비, 금융, 인허가와 회수 구조를 하나의 흐름으로 검토하는 관점을 설명합니다.</description>
      <content:encoded><![CDATA[
<p>호텔 개발을 검토할 때 가장 먼저 눈에 들어오는 것은 입지다. 관광 수요가 있는지, 교통이 편리한지, 주변 상권이 성장하는지는 분명 중요하다. 그러나 좋은 부지가 곧 좋은 호텔 사업을 뜻하지는 않는다. 호텔은 부동산인 동시에 매일 판매와 운영이 반복되는 사업이기 때문이다.</p>
<h2>입지 이후의 질문이 사업성을 결정한다</h2><p>같은 지역에서도 객실 구성, 목표 고객, 평균 객실료와 점유율에 따라 결과는 달라진다. 객실 수를 늘리는 선택이 언제나 매출 증가로 이어지는 것도 아니다. 공용부와 부대시설, 인력과 유지관리 비용까지 함께 봐야 한다. 따라서 초기에는 예상 매출 하나보다 수요의 근거와 비용 구조가 어떻게 맞물리는지를 먼저 살펴야 한다.</p>
<p>운영 방식도 핵심 변수다. 직접 운영, 위탁 운영, 임대 등 선택에 따라 수수료와 통제 범위, 손익의 변동성이 달라진다. 브랜드 도입 여부 역시 인지도만으로 판단하기 어렵다. 기대 매출과 비용, 계약 기간, 운영 기준을 같은 표 안에 놓고 비교해야 한다.</p>
<h2>금융과 인허가를 하나의 일정으로 본다</h2><p>개발비는 토지비와 공사비로 끝나지 않는다. 설계 변경, 금융비용, 각종 부담금과 개장 전 비용이 누적된다. 공사와 인허가 일정이 늦어지면 이자 부담과 영업 개시 시점이 함께 흔들린다. 그래서 사업비, 자금 조달, 일정은 별도 문서가 아니라 하나의 흐름으로 관리해야 한다.</p>
<p>대출 규모가 커질수록 자기자본 수익률이 높아질 수 있지만, 현금흐름의 안전 여지는 줄어든다. 예상 NOI가 원리금 상환을 얼마나 감당하는지, 객실료나 점유율이 낮아졌을 때도 버틸 수 있는지를 확인해야 한다. 가장 낙관적인 숫자보다 기준 시나리오와 하락 시나리오의 차이가 의사결정에 더 유용하다.</p>
<h2>회수 구조에서 거꾸로 검토한다</h2><p>호텔의 가치는 완공 시점이 아니라 안정화된 운영 실적에서 드러난다. 장기 보유인지 매각인지에 따라 준비해야 할 자료와 운영 목표도 달라진다. 예상 매각가를 정해 놓고 현재 가정을 맞추기보다, 달성 가능한 NOI와 시장의 가치평가 기준에서 회수 가능성을 거꾸로 계산하는 편이 현실적이다.</p>
<p>검토 결과는 의사결정 표로 남기는 것이 좋다. 확정된 사실과 아직 검증이 필요한 가정을 구분하고, 각 가정의 담당자와 확인 시점을 정한다. 객실료, 점유율, 공사비, 금리처럼 영향이 큰 항목은 변경될 때 사업성 지표가 함께 갱신되도록 관리한다. 그래야 회의 때마다 서로 다른 숫자를 보는 일을 줄이고, 다음 단계로 넘어갈 조건을 명확히 할 수 있다.</p><p>결국 호텔 개발은 좋은 땅을 발견하는 일이 아니라 입지, 상품, 운영, 금융, 인허가와 회수 계획을 연결하는 일이다. 각 요소를 따로 최적화하기보다 하나의 가정이 다른 요소에 미치는 영향을 확인할 때 비로소 실행 가능한 사업 구조가 된다.</p>]]></content:encoded>
    </item>
    <item>
      <title>사업을 운영 시스템으로 만들어야 하는 이유</title>
      <link>https://developho.com/journal/why-business-needs-operating-systems/</link>
      <guid isPermaLink="true">https://developho.com/journal/why-business-needs-operating-systems/</guid>
      <pubDate>Fri, 17 Jul 2026 00:00:00 +0900</pubDate>
      <description>반복 업무와 판단 기준을 구조화하고 기록과 데이터를 다음 행동에 연결하는 운영 시스템의 원칙을 설명합니다.</description>
      <content:encoded><![CDATA[
<p>사업의 초기에는 대표나 몇 사람의 기억과 판단으로도 일이 돌아간다. 고객의 요구를 알고, 다음 일정과 필요한 자료를 머릿속에 담을 수 있기 때문이다. 그러나 거래와 사람이 늘어나면 같은 방식은 빠르게 한계에 닿는다. 누가 무엇을 알고 있는지에 따라 결과가 달라지고, 중요한 업무가 누락되며, 이미 해결한 문제를 다시 푸는 일이 반복된다.</p>
<h2>도구보다 흐름을 먼저 정리한다</h2><p>운영 시스템을 만든다고 하면 새로운 소프트웨어부터 찾기 쉽다. 하지만 도구는 정리되지 않은 업무를 자동으로 정리해 주지 않는다. 고객 문의가 들어온 뒤 누가 확인하고, 어떤 기준으로 분류하며, 언제 다음 단계로 넘기는지부터 정의해야 한다. 입력, 판단, 실행, 확인의 흐름이 보이면 필요한 도구의 범위도 자연스럽게 좁아진다.</p>
<p>모든 업무를 한 번에 표준화할 필요는 없다. 반복 빈도가 높고 누락될 때 손실이 큰 업무부터 시작하는 편이 효과적이다. 일정과 담당자, 상태, 다음 행동처럼 기본 항목을 통일하고 실제 운영에서 불편한 지점을 확인하면서 확장해야 한다.</p>
<h2>기록은 보고가 아니라 다음 행동을 위한 것이다</h2><p>데이터를 많이 모으는 것만으로 시스템이 되지는 않는다. 기록한 정보가 다음 판단에 사용되어야 한다. 고객 정보는 연락처 목록을 넘어 현재 단계와 필요한 조치를 알려줘야 하고, 일정은 날짜만 표시하는 것이 아니라 준비 조건과 책임자를 연결해야 한다. 콘텐츠나 자료 역시 저장 위치보다 검색과 재사용 방식이 중요하다.</p>
<p>입력 기준이 사람마다 다르면 데이터는 금방 신뢰를 잃는다. 필수 항목을 최소화하고 용어를 통일하며, 누가 언제 수정했는지 확인할 수 있어야 한다. 동시에 예외 상황을 기록할 여지도 필요하다. 표준은 판단을 없애는 규칙이 아니라 반복 판단의 비용을 줄이는 공통 기준이다.</p>
<h2>대표의 기억을 조직의 자산으로 바꾼다</h2><p>잘 만든 운영 시스템은 대표를 업무에서 분리하는 것이 아니라 대표의 판단 기준을 조직이 활용할 수 있게 한다. 어떤 요청을 우선하는지, 어느 단계에서 위험을 확인하는지, 결과를 어떤 지표로 보는지를 구조에 담으면 담당자가 달라져도 기본 품질을 유지할 수 있다.</p>
<p>운영 지표는 많기보다 행동과 연결되어야 한다. 처리되지 않은 문의, 지연된 일정, 반복되는 오류처럼 바로 조치할 수 있는 신호를 먼저 본다. 정기적으로 지표를 확인하고 원인을 기록하면 시스템은 단순한 저장소에서 경영 도구로 바뀐다. 자동화 역시 흐름이 안정된 뒤 적용해야 잘못된 절차가 더 빠르게 반복되는 문제를 피할 수 있다.</p><p>시스템은 완성품이 아니라 운영하며 수정하는 구조다. 불필요한 단계는 줄이고, 반복되는 예외는 새로운 기준으로 반영해야 한다. 사람의 경험을 존중하면서도 핵심 정보가 개인에게만 머물지 않게 만드는 것, 그리고 축적된 데이터로 다음 결정을 더 빠르고 정확하게 하는 것이 사업을 운영 시스템으로 만드는 이유다.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
