<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>박민정</title>
    <link>https://brunch.co.kr/@@9Hgy</link>
    <description>26년차 IT쟁이 박민정입니다. 기술을 만드는 사람의 시선으로, 현장의 이야기를 기록합니다</description>
    <language>ko</language>
    <pubDate>Sun, 11 Oct 2026 08:53:47 GMT</pubDate>
    <generator>Kakao Brunch</generator>
    <image>
      <title>26년차 IT쟁이 박민정입니다. 기술을 만드는 사람의 시선으로, 현장의 이야기를 기록합니다</title>
      <url>//img1.kakaocdn.net/thumb/C100x100/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F9Hgy%2Fimage%2FcuxRyuVin3NqhtXWmyrLCFwkCxk.png</url>
      <link>https://brunch.co.kr/@@9Hgy</link>
      <width>100</width>
      <height>100</height>
    </image>
    <item>
      <title>서로 다른 기준으로 같은 숫자를 바라본다 - 가격 인식의 차이</title>
      <link>https://brunch.co.kr/@@9Hgy/24</link>
      <description>같은 금액을 보고도 누군가는 비싸다고 말하고,  누군가는생각보다 괜찮다고 말합니다.  숫자는 분명 같은데  그 숫자를 받아들이는 마음은서로 다릅니다. 우리는 가격에  어느 정도 객관적인 기준이있다고 생각합니다.  하지만 막상 가격을 판단할 때는 숫자만 보고 결정하지 않습니다.  내가 예상했던 금액, 전에 지불했던 금액, 다른 곳에서 들었던 금액,  그리고</description>
      <pubDate>Wed, 16 Sep 2026 00:46:49 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/24</guid>
    </item>
    <item>
      <title>기대는 언제나 계약보다 크다 - 요구사항의 확장</title>
      <link>https://brunch.co.kr/@@9Hgy/25</link>
      <description>우리는 살아가면서  생각보다 많은 것을말하지 않고 기대합니다. 가족에게도, 함께 일하는 사람에게도, 오래 알고 지낸 사람에게도  &amp;ldquo;이 정도는 알겠지.&amp;rdquo; &amp;ldquo;굳이 말하지 않아도 이해하겠지.&amp;rdquo;  라는 마음을 갖습니다. 그래서 때로는 상대가 하지 않은 일보다  &amp;lsquo;당연히 해줄 것이라고 생각했던 일&amp;rsquo;을하지 않았을 때  더 서운해지기도 합니다.  상대는 약속한 적이 없</description>
      <pubDate>Wed, 02 Sep 2026 08:02:32 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/25</guid>
    </item>
    <item>
      <title>같은 말을 해도 서로 다른 마음으로 듣는 이유 - 커뮤니케이션의 오류</title>
      <link>https://brunch.co.kr/@@9Hgy/22</link>
      <description>회의는 분명 잘 끝난 것 같았습니다.  서로 고개를 끄덕였고, 이해했다고 생각했고, 다음 단계도 정했습니다.  그런데 며칠 뒤 다시 이야기를 나누면  각자가 생각한 결론이 조금씩 달라져 있습니다. 처음에는 누군가 잘못 이해했다고 생각합니다.  설명이 부족했거나, 전달이 잘못되었거나, 기억이 달라졌다고 생각합니다.  하지만 대부분의 경우 문제는 기억보다 해석</description>
      <pubDate>Fri, 07 Aug 2026 02:19:05 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/22</guid>
    </item>
    <item>
      <title>무조건적인 수용보다 진심 어린 제동이 필요한 순간 - 책임의 무게</title>
      <link>https://brunch.co.kr/@@9Hgy/21</link>
      <description>프로젝트를 시작하면 의뢰자는 자신의 생각을 이야기하고,  개발사는 그 이야기를 바탕으로 시스템을 만들어 갑니다.  그래서 처음에는 이렇게 생각하기 쉽습니다.  &amp;quot;고객이 원하는 대로 만들어 드리면 되는 것 아닐까.&amp;quot; 틀린 말은 아닙니다.  의뢰자의 의견은 프로젝트의 출발점이기 때문입니다.  하지만 프로젝트를 오래 하다 보면 조금 다른 순간들을 만나게 됩니다.</description>
      <pubDate>Tue, 28 Jul 2026 01:05:24 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/21</guid>
    </item>
    <item>
      <title>일을 맡기는 관계와 함께 만드는 관계의 차이 - 협업의 거리</title>
      <link>https://brunch.co.kr/@@9Hgy/20</link>
      <description>시스템 개발을 시작하면 자연스럽게 역할이 나뉩니다.  한 사람은 일을 맡기고, 한 사람은 일을 만듭니다.  계약서에도 그렇게 적혀 있습니다.  의뢰자와 개발사. 발주자와 수행사.  처음에는 그 관계가 당연하게 느껴집니다. 그래서 종종 이렇게 생각하게 됩니다.  &amp;quot;필요한 내용을 전달하면 개발사가 만들어 줄 것이다.&amp;quot;  틀린 말은 아닙니다.  하지만 프로젝트를</description>
      <pubDate>Mon, 13 Jul 2026 01:15:58 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/20</guid>
    </item>
    <item>
      <title>이해하려는 태도가 이해시키는 기술보다 먼저다 - 이해의 자세</title>
      <link>https://brunch.co.kr/@@9Hgy/19</link>
      <description>프로젝트를 하다 보면 의외로 많이 듣는 말이 있습니다.  &amp;ldquo;제가 설명을 잘 못해서 그런 것 같습니다.&amp;rdquo; &amp;ldquo;제가 전달을 제대로 못한 것 같습니다.&amp;rdquo; 문제가 생기면 우리는 종종 설명이 부족했다고 생각합니다.  더 자세히 말했어야 했고, 더 많이 이야기했어야 했고, 더 정확하게 표현했어야 했다고 생각합니다. 물론 그것도 중요합니다.  하지만 프로젝트를 오래 하다</description>
      <pubDate>Fri, 26 Jun 2026 02:49:02 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/19</guid>
    </item>
    <item>
      <title>싸게 시작한 선택이 결국 더 큰 비용이 되는 순간 - 비용의 진실</title>
      <link>https://brunch.co.kr/@@9Hgy/18</link>
      <description>시스템 개발을 준비하다 보면가장 먼저 비교하게 되는 것은대부분 비용입니다.  &amp;ldquo;기능은 비슷한 것 같은데 왜 가격 차이가 이렇게 날까요?&amp;rdquo;  누구나 한 번쯤은 하게 되는 질문입니다.  예산은 한정되어 있고,처음부터 큰 비용을 결정하는 일은부담스럽기 때문입니다.  그래서 자연스럽게조금 더 저렴한 선택에 눈길이 갑니다. 처음에는그 선택이 꽤 합리적으로 보입니다.</description>
      <pubDate>Fri, 12 Jun 2026 04:58:44 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/18</guid>
    </item>
    <item>
      <title>프로젝트는 왜 항상 예상보다 늦어질까 - 시간의 문제</title>
      <link>https://brunch.co.kr/@@9Hgy/17</link>
      <description>프로젝트를 시작할 때&amp;nbsp;우리는 늘 일정을 이야기합니다.  &amp;ldquo;두 달 정도면 가능할 것 같습니다.&amp;rdquo;&amp;nbsp;&amp;ldquo;이 시점에는 오픈할 수 있을 것 같습니다.&amp;rdquo;  처음의 일정은언제나 꽤 현실적으로 보입니다.  할 일도 정리되어 있고,기능도 정해져 있고,방향도 명확해 보입니다.  그래서 대부분이 정도면 충분하다고 생각하게 됩니다. 하지만 이상하게도프로젝트는 자주 늦어집니다.</description>
      <pubDate>Fri, 29 May 2026 00:52:54 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/17</guid>
    </item>
    <item>
      <title>책상 위의 완성과 현실 속의 사용은 다릅니다 - 테스트의 착각</title>
      <link>https://brunch.co.kr/@@9Hgy/16</link>
      <description>시스템 개발을 하다 보면 자주 듣는 말이 있습니다.  &amp;ldquo;테스트까지 다 끝났습니다.&amp;rdquo;  오류도 없고, &amp;nbsp;기능도 정상적으로 동작하고,시나리오대로도 잘 움직입니다.  그 순간만 보면시스템은 완성된 것처럼 느껴집니다. 하지만현장은 조금 다릅니다.  책상 위에서는 완벽했던 기능이실제 사용이 시작되는 순간부터전혀 다른 모습으로 움직이기 시작합니다. 테스트에서는사용자가</description>
      <pubDate>Thu, 07 May 2026 02:43:29 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/16</guid>
    </item>
    <item>
      <title>좋은 개발사는 기술을 설명할 줄 아는 사람이다 - 소통의 기술</title>
      <link>https://brunch.co.kr/@@9Hgy/14</link>
      <description>시스템 개발은 기술로 이루어집니다.  코드로 만들고, 구조로 설계하고, 데이터로 움직입니다.  그래서 처음에는 기술이 전부인 것처럼 느껴집니다.  어떤 언어를 쓰는지, 얼마나 빠르게 만드는지, 얼마나 복잡한 구조를 다룰 수 있는지.  그 기준으로 개발사를 보게 됩니다. 하지만 프로젝트를 진행하다 보면 한 번쯤은 이런 순간을 겪게 됩니다.  분명 문제는 아닌</description>
      <pubDate>Tue, 28 Apr 2026 06:35:06 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/14</guid>
    </item>
    <item>
      <title>남의 성공이 나의 성공이 되지 않는 이유 - 레퍼런스의 함정</title>
      <link>https://brunch.co.kr/@@9Hgy/13</link>
      <description>시스템을 이야기할 때자주 등장하는 말이 있습니다.  &amp;ldquo;이 서비스처럼 만들어 주세요.&amp;rdquo;  레퍼런스는언제나 출발점이 됩니다.  이미 만들어진 것,이미 검증된 것,이미 성공한 것. 그래서 우리는조금 더 안심하게 됩니다.  이 길은누군가 한 번지나간 길이기 때문입니다. 처음에는그 선택이꽤 합리적으로 느껴집니다.  보이는 것이 있고,비교할 수 있는 기준이 있고,설명</description>
      <pubDate>Mon, 20 Apr 2026 06:29:50 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/13</guid>
    </item>
    <item>
      <title>결과를 바꾸는 것은 기술이 아니라 질문이다 - 질문과 기술</title>
      <link>https://brunch.co.kr/@@9Hgy/15</link>
      <description>무언가를 만든다는 것은 결국 이해에서 시작됩니다.  같은 말을 듣고도 다르게 받아들이고, 같은 장면을 보면서도 조금씩 다른 생각을 하게 됩니다.  그래서 우리는 종종 이렇게 느끼게 됩니다.  분명 이야기했는데어딘가 다르게 전달된 것 같은 순간. 시스템 개발도 그 안에서 크게 다르지 않습니다.  의뢰자는&amp;nbsp;자신이 원하는 것을 설명하고 개발사는 그 이야기를 바탕</description>
      <pubDate>Thu, 09 Apr 2026 03:12:47 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/15</guid>
    </item>
    <item>
      <title>기술보다 사람을 선택하는 일이 더 어려운 이유 - 개발사 선택</title>
      <link>https://brunch.co.kr/@@9Hgy/12</link>
      <description>시스템 개발은 기술로 시작되는 것처럼 보입니다.  어떤 언어를 사용할지, 어떤 구조로 설계할지, 어떤 아키텍처를 선택할지.  기술은 비교적 분명합니다. 기준이 있고, 검증이 가능하며, 좋고 나쁨을 설명할 수 있습니다.  그래서 우리는 종종 이렇게 생각합니다.  &amp;ldquo;기술만 좋으면&amp;nbsp;프로젝트는 잘 될 것이다.&amp;rdquo;  몇 번의 프로젝트를 지나고 나면 조금 다른 기준이</description>
      <pubDate>Mon, 30 Mar 2026 01:50:27 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/12</guid>
    </item>
    <item>
      <title>왜 고객의 요구는 자꾸 달라질까? - 요구사항의 끝없는 변화</title>
      <link>https://brunch.co.kr/@@9Hgy/11</link>
      <description>프로젝트는 요구사항으로 시작됩니다  시스템 개발은요구사항에서 시작됩니다.  무엇을 만들 것인지,어떤 기능이 필요한지,어떤 화면으로 구성할지. 회의를 거쳐 정리되고문서가 만들어집니다.  그 문서는&amp;nbsp;프로젝트의 기준이 됩니다.  그래서 개발 현장에서는&amp;nbsp;이 말을 자주 합니다.  &amp;ldquo;요구사항이 확정되었습니다.&amp;rdquo;  하지만수많은 프로젝트를 지나며한 가지 사실을 알게 됩니</description>
      <pubDate>Mon, 09 Mar 2026 08:35:35 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/11</guid>
    </item>
    <item>
      <title>의뢰자와 개발사는 계약자인가, 동반자인가? - 관계의 철학</title>
      <link>https://brunch.co.kr/@@9Hgy/10</link>
      <description>시스템 개발은 계약서에서 시작됩니다.  견적이 오가고, 범위가 정해지고, 일정이 확정됩니다. 서명하는 순간 우리는 발주자와 수행사, 즉 계약 관계가 됩니다.  형식은 분명합니다.책임도 구분되어 있습니다. 그러나 수많은 현장을 지나며 분명히 느낀 점이 있습니다.  프로젝트의 성패는 계약 조항이 아니라사람과 사람 사이의 방향에서 갈린다는 사실입니다. 계약은 출</description>
      <pubDate>Tue, 24 Feb 2026 06:04:39 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/10</guid>
    </item>
    <item>
      <title>싸게 빨리 vs 값지게 오래, 무엇을 선택해야 할까요? - 비용의 진실</title>
      <link>https://brunch.co.kr/@@9Hgy/9</link>
      <description>시스템 구축 상담을 하다 보면거의 빠지지 않고 듣게 되는 말이 있습니다.  &amp;ldquo;조금만 더 싸게, 가능하면 빨리 만들 수는 없을까요?&amp;rdquo;  이 질문은 틀린 말이 아닙니다. 사업을 하는 입장에서 비용과 시간은 늘 현실적인 고민이기 때문입니다.  다만 이 질문 뒤에 따라오는 선택이생각보다 큰 차이를 만들어냅니다. 처음에는 대부분 이렇게 시작합니다. 지금 당장 필요한</description>
      <pubDate>Fri, 30 Jan 2026 02:41:46 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/9</guid>
    </item>
    <item>
      <title>시스템을 오래 쓰는 회사들의 공통점(2편) - 운영의 태도</title>
      <link>https://brunch.co.kr/@@9Hgy/8</link>
      <description>기술보다 먼저 보는 것이 있다  &amp;ldquo;우리는 이 시스템을&amp;nbsp;꽤 오래 쓰고 있습니다.&amp;rdquo;  현장에서 이 말을 듣는 순간, 대개 그 회사의 분위기가어느 정도는 그려집니다.  최신 기술을 가장 먼저 도입한 회사라기보다,시스템을 자기 일처럼 다뤄온 회사일 가능성이 큽니다. 시스템을 오래 쓰는 회사들은공통적으로 한 가지를먼저 묻습니다.  &amp;ldquo;이게 지금 우리 일에&amp;nbsp;어떻게 쓰일</description>
      <pubDate>Mon, 19 Jan 2026 08:01:40 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/8</guid>
    </item>
    <item>
      <title>시스템은 완성되는 순간부터 구식이 되는 걸까? (1편) - 변화의 수용</title>
      <link>https://brunch.co.kr/@@9Hgy/7</link>
      <description>&amp;ldquo;이거, 얼마나 오래 쓸 수 있을까요?&amp;rdquo;  시스템을 하나 만들고 나면 이런 질문을 자주 듣는다.  이 질문에는 기대보다 걱정이 먼저 담겨 있다. 금방 또 바꿔야 하는 건 아닐지, 조금 지나면 쓸모없어지는 건 아닐지 말이다.  특히 한 번 시스템을 바꾸는 일이 얼마나 큰 결정인지 알고 있는 사람일수록 이 질문은 더 조심스러워진다. 하지만 시스템이 금방 낡아지</description>
      <pubDate>Mon, 05 Jan 2026 07:00:08 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/7</guid>
    </item>
    <item>
      <title>서로의 간극 속에서 배운 것들 - 관계의 철학</title>
      <link>https://brunch.co.kr/@@9Hgy/5</link>
      <description>프로젝트라는 일을 오래 하다 보면 &amp;nbsp;일 자체보다 사람 사이의 미묘한 거리에서 더 많은 고민을 하게 됩니다. 기능은 문서로 정리할 수 있지만, &amp;nbsp;사람의 기대와 감정은 문서 어디에도 적히지 않기 때문입니다.  회의실에서 모두가 같은 방향을 보고 있다고 믿었는데 &amp;nbsp;막상 일을 시작하면 각자의 해석이 조금씩 다른 경우가 많습니다. &amp;nbsp;똑같은 말을 나눴는데도 서로 다르</description>
      <pubDate>Thu, 18 Dec 2025 02:39:54 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/5</guid>
    </item>
    <item>
      <title>데이터는 자산일까, 책임일까? - 데이터의 윤리</title>
      <link>https://brunch.co.kr/@@9Hgy/6</link>
      <description>요즘 일을 하다 보면 문득 그런 순간이 있다. 한 사람의 말보다, 책상 위에 놓인 숫자 하나가 &amp;nbsp;결정의 방향을 더 선명하게 바꾸는 순간!  예전에는 감각과 경험이 먼저였는데&amp;nbsp;어느새 우리는 데이터라는 기준에 기대어 조심스레 다음 걸음을 내딛고 있다.  그래서 사람들은 말한다.&amp;nbsp;데이터는 자산이라고! &amp;nbsp;많이 쌓을수록 힘이 된다고! 틀린 말은 아니다. 하지만 나는</description>
      <pubDate>Mon, 01 Dec 2025 06:35:11 GMT</pubDate>
      <author>박민정</author>
      <guid>https://brunch.co.kr/@@9Hgy/6</guid>
    </item>
  </channel>
</rss>
