<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>우주문과</title>
  <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj" />
  <author>
    <name>jang91</name>
  </author>
  <subtitle>문과생이 우주산업에서 경험한 현실적이고 솔직한 이야기</subtitle>
  <id>https://brunch.co.kr/@@aEOj</id>
  <updated>2020-07-27T02:44:21Z</updated>
  <entry>
    <title>한국에서 로켓을 쏘기 힘든 이유 - 브라질 발사장과 제주 바다로 간 한국 로켓들</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/26" />
    <id>https://brunch.co.kr/@@aEOj/26</id>
    <updated>2026-05-01T02:09:01Z</updated>
    <published>2026-05-01T02:09:01Z</published>
    <summary type="html">우주산업계에서 10년 가까이 일하면서 느낀 점을 이야기해보려 한다. 우주산업이 어떻게 성장해야 하는지, 올드스페이스에서 뉴스페이스로의 전환이 왜 중요한지에 대한 이야기는 전문가들의 분석 자료나 인터뷰를 찾아보면 된다. 나는 그런 전문가적인 이야기 대신, 비이공계 출신으로서 현장에서 직접 겪은 현실에 대해 써보려 한다.  로켓 쏠 땅이 없다 SpaceX의 텍</summary>
  </entry>
  <entry>
    <title>#20. 문과생도 우주 스타트업 갈 수 있나요? - 경영학과에서 우주산업 PM까지 할 수 있어요, 하지만 쉽진 않아요</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/25" />
    <id>https://brunch.co.kr/@@aEOj/25</id>
    <updated>2026-04-11T08:04:46Z</updated>
    <published>2026-04-11T08:04:46Z</published>
    <summary type="html">첫 과제 선정 통보를 받았을 때 발표 평가가 끝나고 2주 뒤, 메일이 왔다. &amp;quot;축하드립니다. 귀사의 제안과제가 최종 선정되었습니다.&amp;quot; 이 문장을 읽는 순간, 지난 몇 달이 주마등처럼 스쳐 지나갔다. 공고문을 찾아 헤매던 날들. 컨소시엄 구성하면서 여러 기관에 전화하던 기억. 제안서 쓰면서 밤을 새우던 시간. 예산표를 검산하고 또 검산하던 순간. 발표 연습을</summary>
  </entry>
  <entry>
    <title>#19. 발표 평가는 제안서의 두 번째 관문이다 - 발표 평가는 결국 준비의 결과다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/24" />
    <id>https://brunch.co.kr/@@aEOj/24</id>
    <updated>2026-04-30T12:51:54Z</updated>
    <published>2026-04-04T05:12:13Z</published>
    <summary type="html">발표 중 주의할 점 발표가 시작되면, 시간을 지키는 게 가장 중요하다. 20분이 주어졌으면, 19분 30초 안에 끝낸다. 시간 초과로 끊기면, 하고 싶은 말을 못 하게 된다. 발표 시간은 보통 5분 남았을 때, 평가기관에서 알려준다. 평가위원 중 한 명이 &amp;quot;5분 남았습니다&amp;quot;라고 알려주거나, 팻말을 들어 보여준다. 이때부터 시간을 고려해서 발표를 조정해야 한</summary>
  </entry>
  <entry>
    <title>#18. 제안서 제출 전 최종 검토가 당락을 가른다 - 검토, 최종 검토, 최최종 검토, 최최최종 검토, 최최최최종 검토...</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/23" />
    <id>https://brunch.co.kr/@@aEOj/23</id>
    <updated>2026-03-30T13:37:54Z</updated>
    <published>2026-03-30T13:37:54Z</published>
    <summary type="html">공고문 요구사항을 다시 확인한다 가장 먼저 할 일은 공고문을 다시 펼쳐보는 거다. 제안서를 쓰는 동안 공고문을 수없이 봤지만, 마지막에 한 번 더 본다. 공고문에는 제안서 작성 양식과 제출 서류 목록이 명시되어 있다. &amp;quot;제안서는 50페이지 이내로 작성&amp;quot; &amp;quot;연구개발계획서, 참여연구원 명단, 기관 인증서류 첨부&amp;quot; &amp;quot;PDF 파일로 제출, 파일명은 '과제명_기관명</summary>
  </entry>
  <entry>
    <title>#17. 연구개발 목표는 측정 가능해야 한다 - 성과지표가 과제의 성공을 증명한다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/22" />
    <id>https://brunch.co.kr/@@aEOj/22</id>
    <updated>2026-03-19T13:07:26Z</updated>
    <published>2026-03-19T13:07:26Z</published>
    <summary type="html">목표를 처음 계획할 때 제안서를 쓰다 보면 '연구개발 목표'를 작성하는 항목이 나온다. 처음에는 이걸 거창하게 쓰면 되는 줄 알았다. '세계 최고 수준의 기술 개발', '글로벌 경쟁력 확보' 목표는 거창함이 아니라 측정 가능성이 핵심이라는 걸 알게 되었다.  목표와 성과지표는 다르다 연구개발 목표와 성과지표를 혼동하기 쉽다. 처음에는 나도 이 둘을 구분하지</summary>
  </entry>
  <entry>
    <title>#16. 정부과제 예산은 숫자가 아니라 스토리다. - 연구개발 계획의 스토리를 비목으로 번역한다.</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/21" />
    <id>https://brunch.co.kr/@@aEOj/21</id>
    <updated>2026-03-18T14:39:31Z</updated>
    <published>2026-03-18T14:39:31Z</published>
    <summary type="html">예산을 처음 짤 때 제안서 작성 중 가장 까다로운 부분이 예산 설계다. 공고문을 보면 총 연구비 규모가 나온다. '총 5억원' 처음에는 이 금액을 어떻게든 채우기만 하면 되는 줄 알았다. 하지만 예산은 금액을 맞추는 게 아니라, 과제 수행 계획을 숫자로 증명하는 작업이란 걸 알게되었다.  규정부터 알아야 한다 정부과제 예산을 짜려면 가장 먼저 규정을 알아야</summary>
  </entry>
  <entry>
    <title>#15. 기술을 '언어'로 번역하는 법 - 제안서는 기술 나열이 아니라 명분을 쓰는 것</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/20" />
    <id>https://brunch.co.kr/@@aEOj/20</id>
    <updated>2026-03-14T22:43:56Z</updated>
    <published>2026-03-14T22:43:56Z</published>
    <summary type="html">제안서를 처음 쓸 때 컨소시엄 구성이 끝나면, 이제 제안서를 쓸 차례다. 제안서는 단순히 공고문 요구사항에 맞춰 빈칸을 채우는 작업이 아니다. 제안서는 '우리가 무엇을 할 수 있다'는 답변서가 아니라, '왜 우리에게 이 과제를 맡겨야 하는가'를 설득하는 전략서이다.  심사위원은 우리 기술의 전문가가 아니다 제안서 평가위원은 다양한 분야에서 구성된다. 우주</summary>
  </entry>
  <entry>
    <title>#14. 정부과제 컨소시엄 구성 실전 가이드 - 산학연 협력기관 찾고 역할 나누는 법</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/19" />
    <id>https://brunch.co.kr/@@aEOj/19</id>
    <updated>2026-04-22T14:52:15Z</updated>
    <published>2026-03-07T00:54:21Z</published>
    <summary type="html">혼자서는 안 되는 과제들 공고문을 분석하다 보면 이런 문구를 자주 본다. &amp;quot;본 과제는 컨소시엄 구성을 권장합니다.&amp;quot; &amp;quot;주관기관과 참여기관의 역할 분담을 명확히 제시하시기 바랍니다.&amp;quot; '우리 회사가 기술 있으면 되는 거 아닌가? 왜 다른 기관이 필요하지?' 하지만 과제를 몇 번 해보니 알게 됐다. 정부과제는 대부분 한 회사가 혼자서 다 하기 어려운 구조로 설</summary>
  </entry>
  <entry>
    <title>#13. 정부과제는 공고를 찾는 것부터가 전략이다. - 하루 10개씩 뒤지며 배운 기술 확장성 전략</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/18" />
    <id>https://brunch.co.kr/@@aEOj/18</id>
    <updated>2026-04-22T14:51:50Z</updated>
    <published>2026-03-04T13:35:29Z</published>
    <summary type="html">우주 기업이라고 우주 공고만 보면 안 된다 과제를 수주하려면 공고를 찾아야 하는데, 당연히 우주 관련 공고만 보면 되는 줄 알았다. '우리는 우주 기업이니까 우주 관련 공고만 보면 되겠지?' 그렇게 생각하고 한동안은 우주 키워드가 들어간 공고만 주로 봤다. 하지만 시간이 지나면서 알게 됐다. 우리 기술이 꼭 '우주' 공고에만 나오는 건 아니라는 걸.  부처</summary>
  </entry>
  <entry>
    <title>#12.&amp;nbsp;정부과제는 공고가 뜨기 전에 시작된다 - 정책 흐름을 읽는 게 사업관리의 시작이다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/17" />
    <id>https://brunch.co.kr/@@aEOj/17</id>
    <updated>2026-02-19T02:17:58Z</updated>
    <published>2026-02-19T02:17:58Z</published>
    <summary type="html">예산이 흐르는 방향을 먼저 봐야 한다 사업관리를 처음 시작했을 때, 나는 정부과제 공고가 올라오면 그때부터 움직이면 되는 줄 알았다. 공고를 보고, RFP를 분석하고, 제안서를 쓰면 되는 거 아닌가? 하지만 일을 하다 보니 알게 됐다. 정부 예산은 갑자기 튀어나오지 않는다는 걸. 공고가 뜨기 전에 이미 방향은 정해져 있었고, 그 방향을 먼저 읽는 것이 사업</summary>
  </entry>
  <entry>
    <title>#11.PM의 본질은 연결자다  - 기술-정책-예산-사람을 연결하는 일</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/16" />
    <id>https://brunch.co.kr/@@aEOj/16</id>
    <updated>2026-04-22T14:51:28Z</updated>
    <published>2026-02-15T00:58:05Z</published>
    <summary type="html">회사 밖 사람을 만나면 종종 이런 질문을 받는다.  &amp;ldquo;그래서 정확히 무슨 일을 하세요?&amp;rdquo;  처음에는 &amp;ldquo;정부과제 사업관리 합니다.&amp;rdquo;라고 답했다. 그러면 대부분 이렇게 묻는다. &amp;ldquo;그게 뭐예요?&amp;rdquo; &amp;ldquo;회계랑 다른 건가요?&amp;rdquo; &amp;ldquo;PM이에요?&amp;rdquo;  설명하려고 하면 생각보다 길어진다.  정부과제 사업관리는 일반적인 사업관리와 다르다. 단순히 일정&amp;middot;비용&amp;middot;위험을 관리하는 것만</summary>
  </entry>
  <entry>
    <title>#10. PM(사업관리자)이란 무엇인가  - 기술과 사람을 연결하는 사람</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/15" />
    <id>https://brunch.co.kr/@@aEOj/15</id>
    <updated>2026-04-22T14:50:54Z</updated>
    <published>2026-02-11T13:42:00Z</published>
    <summary type="html">사업관리이든, 기획이든 문과생이라는 우물에 갇혀있으면 안 된다. '나는 문과생이니까 몰라도 돼', '내가 사업관리인데 왜 알아야 해.', '문과생이니까 기술 이해 못 해도 이해해 주겠지.' 이런 변명, 딱 학생 때까지, 좀 더 넓게 본다면 인턴까지만 할 수 있는 변명이다.  회사에서 월급을 받는 직원이라면, 내가 가치를 증명해야 하고, 나를 성장시켜야 한다</summary>
  </entry>
  <entry>
    <title>#9. &amp;quot;문과생이라서요&amp;quot; 핑계 그만둔 날  - 전공보다 역할이 중요하다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/14" />
    <id>https://brunch.co.kr/@@aEOj/14</id>
    <updated>2026-04-22T14:50:32Z</updated>
    <published>2026-02-10T14:04:40Z</published>
    <summary type="html">처음에는 항상 나를 이렇게 소개했다. &amp;ldquo;문과생인데, 우주산업에서 일하고 있습니다.&amp;rdquo;  이 말을 하면, 대부분 비슷한 반응이 돌아왔다. &amp;ldquo;문과인데요?&amp;rdquo; &amp;ldquo;그럼 무슨 일을 하세요?&amp;rdquo; &amp;ldquo;기술은 많이 아셔야 하지 않나요?&amp;rdquo;  그 질문들이 싫지는 않았다. &amp;nbsp;오히려 그게 당연하다고 생각했다. 나 스스로도 문과생이라는 말로 내 위치를 설명하고 있었기 때문이다.  입사</summary>
  </entry>
  <entry>
    <title>#8. PM은 왜 항상 개발과 경영 사이에 설까  - 중간 역할이 필요한 이유</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/13" />
    <id>https://brunch.co.kr/@@aEOj/13</id>
    <updated>2026-04-22T14:50:01Z</updated>
    <published>2026-02-09T13:18:34Z</published>
    <summary type="html">회사에 들어와서 한동안은 내가 어디에 속한 사람인지 잘 알 수 없었다. 개발팀도 아니고, 그렇다고 경영 쪽도 아니었다. 어떤 회의에서는 엔지니어 옆에 앉아 있었고, 다른 회의에서는 임원 옆자리에 앉아 있었다. 회사 안에서도 늘 중간에 서 있는 느낌이었다.  처음에는 그게 어색했다. 어디에도 완전히 속하지 못한 것 같았고, 내 자리가 애매하다는 생각이 들었다</summary>
  </entry>
  <entry>
    <title>#7.&amp;quot;기술적으로 안 됩니다&amp;quot; 라는 말의 진실  - 정말 안 되는 건지, 지금 안 되는 건지</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/12" />
    <id>https://brunch.co.kr/@@aEOj/12</id>
    <updated>2026-04-22T14:49:34Z</updated>
    <published>2026-02-07T05:40:42Z</published>
    <summary type="html">회사에서 일하다 보면 종종 이런 말을 듣는다. &amp;ldquo;이건 기술적으로 안 됩니다.&amp;rdquo;  이 말이 나오면 회의는 잠시 멈춘다. 누군가는 고개를 끄덕이고, 누군가는 다음 안건으로 넘어갈 준비를 한다. 예전의 나도 그랬다. 기술적으로 안 된다고 하니, 더 이상 이야기할 수 있는 게 없다고 생각했다.  하지만 시간이 지나면서 알게 됐다. &amp;lsquo;안 된다&amp;rsquo;는 말이 항상 같은 의</summary>
  </entry>
  <entry>
    <title>#6. 문과생은 기술 전부 몰라도 된다 - 수식 이해 못해도 PM 할 수 있다.</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/11" />
    <id>https://brunch.co.kr/@@aEOj/11</id>
    <updated>2026-04-22T14:49:06Z</updated>
    <published>2026-02-03T13:02:59Z</published>
    <summary type="html">회사에 들어온 지 시간이 꽤 흘렀을 때였다. 회의에서 나오는 말들이 어느 정도 이해가 되었고, 질문도 어느 정도는 정리해서 할 수 있게 됐다. 그런데도 마음 한편은 계속 불편했다. 아직도 잘 모르겠다는 느낌이 계속 남아 있었기 때문이다.  그래서 더 공부하려고 했다. 회의에서 나온 기술을 찾아보고, 관련 논문도 읽어봤다. 그런데 논문을 펼치면 가장 먼저 눈</summary>
  </entry>
  <entry>
    <title>#5.기술 회의에서 똑똑하게 질문하는 법 - 용어 질문 &amp;rarr; 맥락 질문 &amp;rarr; 영향 질문</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/10" />
    <id>https://brunch.co.kr/@@aEOj/10</id>
    <updated>2026-04-22T14:48:24Z</updated>
    <published>2026-02-01T14:06:43Z</published>
    <summary type="html">어느 순간부터였다. 회의에서 질문을 던지는 게 예전만큼 부담스럽지 않게 느껴졌다. 처음에는 질문 하나를 던지기까지 머릿속에서 수십 번을 돌려봤다면, 이제는 그 정도는 아니었다. 그렇다고 질문이 쉬워진 건 아니었다. 오히려 질문의 무게가 다르게 느껴지기 시작했다.  질문을 많이 던진다고 해서 회의가 좋아지는 건 아니었다. 어떤 질문은 회의를 앞으로 나아가게</summary>
  </entry>
  <entry>
    <title>#4. 문과생이 기술 회의에서 살아남는 방법 - X밴드? SAR? 몰라도 괜찮은 이유</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/9" />
    <id>https://brunch.co.kr/@@aEOj/9</id>
    <updated>2026-04-22T14:46:35Z</updated>
    <published>2026-01-20T14:54:21Z</published>
    <summary type="html">입사 후 몇 달이 지나자, 회의가 점점 늘어났다. 처음에는 일주일에 한두 번 정도였는데, 어느새 거의 매일 회의실에 앉아 있었다. 그리고 회의 때마다 나는 멍하니 앉아 있었다.  &amp;ldquo;이번 프로젝트는 X밴드 SAR 영상 처리가 메인이니까, 기하보정 알고리즘부터 최적화하고 정사보정은 그다음에 붙이죠.&amp;rdquo; &amp;ldquo;다중분광 스펙트럼 분석은 밴드 조합을 어떻게 가져갈 건가요</summary>
  </entry>
  <entry>
    <title>&amp;ldquo;이거 해도 되나요?&amp;rdquo;라는 질문이 위험한 이유 - &amp;mdash; 정부과제 PM의 판단 기준 이야기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/8" />
    <id>https://brunch.co.kr/@@aEOj/8</id>
    <updated>2026-01-19T13:04:08Z</updated>
    <published>2026-01-19T13:01:55Z</published>
    <summary type="html">&amp;ldquo;별일 없어서 다행이네요.&amp;rdquo;  정부과제가 무사히 끝났을 때 가장 많이 듣는 말입니다.  하지만 그 &amp;lsquo;별일 없는 상태&amp;rsquo;를 만들기 위해 누군가는 매일 판단하고, 조정하고, 확인하고, 기록합니다.  그 역할을 맡아온 사람이 바로, 제가 말하는 정부과제 PM입니다.   그런데, 왜 &amp;lsquo;정부과제 PM&amp;rsquo;일까  사실 현장에서는 &amp;lsquo;정부과제 PM&amp;rsquo;이라는 표현을 거의 쓰지 않</summary>
  </entry>
  <entry>
    <title>#3. 우주 스타트업에서 드라마와 현실 &amp;nbsp; - 드라마 미생처럼 회의만 하는 줄 알았다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@aEOj/7" />
    <id>https://brunch.co.kr/@@aEOj/7</id>
    <updated>2026-04-22T14:46:12Z</updated>
    <published>2025-08-03T12:04:32Z</published>
    <summary type="html">우주산업이라고 하면 많은 사람들이 로켓, 우주비행사, 혹은 SF영화 속의 장면을 떠올린다. 그리고 대부분은 그 산업에 종사하는 사람들도 공학을 전공한 이공계 출신일 것이라 생각하고, 실제로도 우주를 직접 설계하고, 조립하고, 분석하는 핵심 기술 분야는 분명히 이공계의 영역이다. 하지만 그게 전부는 아닙니다. 저 역시 문과생으로서 우주산업에 첫발을 디뎠고,</summary>
  </entry>
</feed>
