슬기로운 PD

AI가 준 답, 어디까지 믿어야 하나 - 좋은 초안을 받는 것과, 그걸 그대로 쓰는 것은 다른 문제다.

2026-06-19T00:00:10Z

지난 강에서 좋은 프롬프트로 좋은 초안을 받는 법을 다뤘다. 그런데 초안은 초안일 뿐이다. 그 답을 그대로 내보내도 되는지, 어디를 다시 봐야 하는지 — 진짜 실력은 여기서 갈린다. 1. 같은 말투로 진실과 거짓을 말한다 AI의 가장 위험한 특성을 한 문장으로 요약하면 이렇다. AI는 맞는 답과 틀린 답을 똑같은 말투로 내놓는다. 사람은 다르

[17강] 국내외 협력사 조율 — 같은 단어를 다르게 - 시차와 언어보다 더 큰 벽

2026-06-17T00:00:11Z

협력사가 국내에 있는지 해외에 있는지에 따라 PD/PM의 역할은 완전히 달라진다. 필자는 한국 협력사와 일할 때는 안 보이던 벽이, 글로벌 본사와 일하면서 처음 보이기 시작했다. 이번 강에서는 국내외 협력사를 조율할 때 PD/PM이 마주하는 진짜 벽과 그것을 넘는 방법을 다룬다. 1. 국내 협력사 조율 — 거리가 가까운 만큼 경계가 흐려진다 국내 협력

작년과 같은 단가는 사실 깎인 단가다 - 가만히 있으면 매년 손해를 보는 구조

2026-06-15T00:00:12Z

클라이언트가 "작년과 똑같이 해주세요"라고 하면, 많은 PM이 그게 공정한 제안이라고 느낀다. 작년과 같은 금액이니까. 하지만 그렇지 않다. 작년과 같은 금액은 올해 기준으로는 깎인 금액이다. 비용은 가만히 있지 않는다 인건비는 매년 오른다. 2026년 SW기술자 평균임금은 전년 대비 4.7% 올랐고, 최저임금도 올랐고, 물가도 올랐다. 이 모든 게

[16강] 외주 관리 실전 — 납기, 품질, 관계 - 발주서를 보낸 순간이 시작이다

2026-06-02T00:00:11Z

발주서에 서명을 받고 나면 일이 끝난 것 같은 기분이 든다. 필자도 그랬다. 그 착각 때문에 납기 일주일 전에 모든 게 무너지는 걸 두 번 겪고 나서야 알았다. 이번 강에서는 발주서를 보낸 다음부터 납품까지, 외주를 어떻게 관리해야 그 일주일 전이 무너지지 않는지를 다룬다. 1. 납기 관리 — 마감일을 믿지 않는다 외주 업체가 "납기 문제없습니다"라고

[07강] 같은 도구로 다른 결과를 내는 사람들 - AI는 같은데, 결과는 사람마다 다르다.

2026-06-01T00:00:17Z

회사에서 같은 ChatGPT를 쓰는데, 한 명은 "제안서 1차 초안을 30분에 받았다"고 하고, 다른 한 명은 "쓸 만한 답이 안 나와 결국 손으로 다시 썼다"고 한다. 도구가 같다면, 차이는 어디서 오는가. 1. 차이는 도구가 아니다 같은 사람에게 같은 일을 부탁해도, 부탁하는 방식에 따라 결과가 달라진다. 막연하게 "보고서 좀 써줘"라고 던지면 그

인건비만 받으면 회사는 망한다 - 보이지 않는 비용이 회사를 갉아먹는다

2026-05-31T00:00:21Z

견적이 통과되면 기분이 좋다. 클라이언트가 사인했고, 프로젝트가 시작되고, 팀이 움직인다. 그런데 프로젝트가 끝나고 정산을 해보면 이상하게 남는 게 없다. 많은 PM이 이 지점에서 처음으로 깨닫는다. 인건비만 계산해서는 안 된다는 걸. 보이지 않아서 잊어버리는 비용 직원 월급은 눈에 보인다. 그래서 견적에 넣는다. 그런데 그 직원이 쓰는 사무실, 컴퓨

[10강] WBS 설계 실전 - WBS는 형식이 아니다, 잘못 짜면 6개월 뒤 야근이 시작된다

2026-05-30T08:20:05Z

프로젝트 정의서가 완성된 다음 날 아침, 필자는 빈 엑셀 시트를 열었다. WBS를 짜기 시작하는 순간이었다. 처음 PD/PM 일을 시작했을 때 필자는 WBS를 단순한 일정표라고 생각했다. 큰 일을 작은 일로 쪼개서 나열하는 것. 그게 전부인 줄 알았다. 그 결과 6개월짜리 자동차 컨피규레이터 프로젝트의 마지막 한 달은 매일 야근으로 채워졌다. 그 경험 이후

[06강] 어떤 AI를 어디에 쓸 것인가 - 도구가 네 개인데, 사람들은 보통 하나만 쓴다.

2026-05-24T02:47:18Z

지난 강에서 AI가 어디서 빛나고 어디서 무너지는지를 봤다. 이번엔 더 현실적인 질문이다. 그 일을 어떤 AI에게 맡길 것인가. 1. 망치 하나로 모든 걸 하려는 사람들 대부분의 사람은 AI를 하나만 쓴다. 보통 ChatGPT다. 가장 먼저 유명해졌고, 가장 익숙하기 때문이다. 그런데 이건 망치 하나로 못도 박고 나사도 조이고 페인트도 칠하려는 것과 비

나는 그 프로젝트를 왜 받았을까 - BEP를 몰랐던 PM은 열심히 일하고도 손해를 봤다

2026-05-23T13:32:55Z

신입 PM들이 처음 견적을 낼 때 거의 예외 없이 같은 실수를 한다. 인건비를 계산하고, 거기에 "적당히" 마진을 더해서 수주 금액을 정한다. "이 정도면 되겠지"라는 감으로. 그렇게 수주한 프로젝트가 끝나고 나면 남는 게 없다. 간접비까지 따지면 오히려 마이너스인 경우도 있다. 그리고 그때 가서야 묻는다. 이거 왜 받았지? 그 질문을 프로젝트 전에

[15강] 외주 업체 선정과 발주 - 단가가 아니라 책임이다

2026-05-19T06:50:30Z

외주 업체 중에 단가가 가장 낮은 곳을 고른 적이 있다. 그 결정 하나로 그 분기 전체가 무너졌다. 이번 강에서는 외주 업체를 어떻게 선정하고 어떻게 발주해야 그 분기가 무너지지 않는지를 다룬다. 1. 외주 업체 풀(Pool) 만들기 킥오프 사흘 전, 필자에게 갑작스러운 요청이 들어왔다. 클라이언트가 특정 시퀀스를 추가하기로 결정했고, 내부 인력으로는

나는 왜 이 프로젝트가 남는지 몰랐는가 - 인건비만 받으면 제작사는 항상 손해다

2026-05-17T23:17:15Z

간혹 신입 PM들의 흔한 장면이 반복된다. 견적서 초안을 들고 오면서 이렇게 말한다. MM 계산하고 등급별 단가 곱해서 합산했는데, 이렇게 하면 될까요? 안 된다. 그 금액으로 넘기면 회사가 손해다. 인건비는 시작일 뿐이다 프로젝트 인건비 외에 사무실 임대료, 소프트웨어 라이선스, 회계·총무 인력 인건비, 장비 감가상각이 있다. 이것들은 특정 프로

견적서에서 MM이 계속 보이는 이유 - 인원이 아니라 작업량이다 — 이 차이를 알면 견적이 읽힌다

2026-05-17T13:40:04Z

클라이언트에게 견적서를 넘기면 항상 비슷한 질문이 나온다. 디자이너 MM 2.0이면 디자이너가 2명 투입된다는 거죠? 아니다. MM 2.0은 1명이 2개월, 또는 2명이 1개월, 또는 4명이 0.5개월이다. 인원수가 아니라 총 작업량이다. 이 질문이 나올 때마다 설명을 해야 한다. 그런데 설명을 잘못하면 역효과가 난다. "그러면 인원을 더 투입해서 기

WBS를 제대로 쓴다는 것 - 서랍 속에 넣어두는 문서가 아니라, 매일 열어보게 되는 문서

2026-05-17T03:47:31Z

킥오프 미팅이 끝나고 나면 WBS는 대부분 서랍 속으로 들어간다. 누군가에게 보여줄 때 한 번, 일정 논의할 때 한 번. 그다음부터는 아무도 열지 않는다. 프로젝트는 계속 흘러가는데 WBS는 처음 만든 상태로 멈춰 있다. 현실과 완전히 다른 문서가 된다. 업데이트되지 않는 WBS의 대가 범위가 달라졌는데 기록이 없다. 납품 이후 "그게 포함된 거였나요

견적서 한 장이 범위를 정한다 - 구두로 합의한 것은 반드시 무너진다

2026-05-17T07:53:54Z

납품 직전 클라이언트가 이런 말을 한 적이 있다. 이게 원래 포함된 거 아니었나요? 나는 당연히 아니라고 했다. 클라이언트는 당연히 맞다고 했다. 둘 다 진심이었다. 악의가 없었다. 그냥 다르게 기억하고 있었다. 구두로 합의한 것은 이렇게 된다. 시간이 지나면 각자가 원하는 방향으로 기억이 재구성된다. 이게 범위 분쟁의 본질이다. 견적서 없이 시작

[05강] AI는 어디서 빛나고 어디서 무너지나 - AI를 쓰면 빨라지는 줄 알았는데, 실제로는 느려진 사람들이 있다.

2026-05-16T01:00:04Z

지금까지 우리는 AI의 본질을 살펴봤다. 이제 가장 실용적인 질문으로 넘어간다. 어떤 일에 AI를 쓰고, 어떤 일에는 안 쓰는 게 맞는가. 1. 개발자들이 빨라진 줄 알았다가 알게 된 것 2025년 7월, 미국의 한 연구기관 METR이 흥미로운 실험 결과를 발표했다. 숙련된 개발자 16명에게 AI 코딩 도구를 쥐어주고 실제 업무를 시켰다. 사용 전

[14강] PRE/MID/POST — 단계별 제작 관리 - 단계가 다르면 PD/PM이 해야 할 일도 완전히 다르다

2026-05-14T01:00:04Z

킥오프가 끝난 후 한 달째 되던 날, 필자는 부서원으로부터 같은 질문을 두 번 받았다. "이거 지금 어느 단계인가요?" 처음 PD/PM 일을 시작했을 때 필자는 이 질문을 우습게 생각했다. 일정표만 보면 알 수 있는 거 아닌가. 하지만 곧 깨달았다. 일정표가 알려주는 건 시간이지 단계가 아니다. 시간은 흐르지만 단계는 명확한 의도를 가지고 전환되어야 하는

[13강] 킥오프 미팅과 팀 세팅 - 의례라고 생각하면 의례로 끝난다.

2026-05-12T01:00:04Z

의례라고 생각하면 의례로 끝난다, 그 한 시간이 6개월의 분위기를 결정한다. 킥오프 미팅 30분 전, 필자는 회의실에 가장 먼저 들어가 자리를 점검했다. 좌석 배치를 다시 확인했고, 화면에 띄울 자료의 첫 페이지를 미리 띄워두었다. 누가 어디에 앉을지, 첫 5분에 무엇을 말할지, 누구에게 먼저 발언권을 줄지 — 이 모든 것이 이미 결정되어 있었다. 처음

[04강] AI는 정말 이해하는 걸까 - 그럴듯한 답이 곧 이해는 아니다.

2026-05-09T01:00:03Z

AI에게 어려운 질문을 했더니 막힘없이 답이 나왔다. 그 순간 우리는 보통 이렇게 생각한다. "오, 이해하고 있네." 정말 그럴까. 1. 사람보다 40% 뒤처지는 시험 2025년 초, 흥미로운 실험 하나가 발표됐다. 연구자들이 만든 시험의 이름은 "피지코(PhysiCo)"였다. 물리 현상을 그림으로 보여주고, AI가 그것을 이해하는지 보는 시험이다

[12강] 예산 배분과 리소스 플래닝 - 견적이 끝났다고 예산이 끝난 게 아니다

2026-05-07T07:02:46Z

"견적이 끝났다고 예산이 끝난 게 아니다, 진짜 싸움은 그 돈을 어디에 쓸 것인가에서 시작된다" 견적이 통과되고 계약서에 사인이 끝난 다음 날, 필자는 통과된 견적서를 다시 펼쳤다. 클라이언트와의 싸움은 끝났지만, 진짜 싸움은 이제부터였다. 이 돈을 어디에 어떻게 배분할 것인가. 어디에 더 쓰고 어디에 덜 쓸 것인가. 어떤 리소스를 언제 투입할 것인가.

Claude Code로 macOS 앱 만들기 (2) - 비개발자의 RX Converter — 사용법과 시행착오, 다운로드

2026-05-13T03:49:20Z

비개발자가 Claude Code 만으로 약 10일간 macOS 앱을 만들었다. 지난 글에서는 왜 만들기 시작했는지, 무엇을 만들었는지를 풀어 보았다. 이번 글은 그 다음 이야기다. 만들면서 실제로 어떤 일이 있었는지, 그리고 어떻게 사용하는지 — 도움말 성격을 좀 가미해서 정리해 보려고 한다. 마지막에는 다운로드 링크도 함께. (1편을 못 보신 분은 여기