AI와 함께 만드는 삶

PM으로 일하며 AI와 함께 무언가를 만들어가는 삶을 기록합니다.

AI활용법 7

PM을 위한 AI 실무 사전 6편 — 죽은 API와 의존성 함정

누구나법률 6장(완성 그 이후)에서 나온 개념: 안 쓰이는 코드의 위험성, 버전 고정의 함정, 인코딩 문제."완성"의 함정 — 안 불러본 코드는 검증된 적이 없다서비스에 기능이 100개 있다고 해서, 그 100개가 다 검증됐다는 뜻은 아니다. 실제로 사용자가 눌러본 경로만 검증된 것이다. 6장의 /api/config/status 500 에러가 정확히 이 경우였다 — 코드는 있었지만, 아무도 그 엔드포인트를 실제로 호출하지 않았기 때문에 NameError(존재하지 않는 함수/변수를 부르는 오류)가 배포 이후 계속 방치돼 있었다.실무에서 이걸 막는 방법은 결국 두 가지다.모든 엔드포인트를 최소 한 번씩 직접 호출해보는 점검(smoke test) — 복잡한 테스트 코드가 아니어도, 배포 후 "이 API들 다 ..

PM을 위한 AI 실무 사전 5편 — PG, CORS, 도메인, OAuth

누구나법률 5장(그래서 직접 벌기로 했다)에서 나온 개념 네 가지: PG(결제대행사), CORS, 도메인/DNS, OAuth.PG(결제대행사)란온라인에서 카드 결제를 직접 처리하려면 PCI-DSS 같은 보안 인증, 카드사별 개별 계약이 필요하다. 개인·소규모 서비스가 감당하기 어려운 진입장벽이다. **PG(Payment Gateway, 결제대행사)**는 이 복잡한 과정을 대신 처리해주고, 서비스는 PG가 제공하는 SDK/API만 붙이면 결제를 받을 수 있게 해준다. 토스페이먼츠, 아임포트(포트원), 나이스페이먼츠 같은 곳들이 국내 PG의 예다.실무 흐름은 대체로 이렇다. 사용자가 "결제하기" 클릭→ PG가 제공하는 결제창 호출 (실제 카드정보는 PG 서버가 처리, 우리 서버는 안 봄)→ 결제 성공 시 P..

PM을 위한 AI 실무 사전 4편 — 사회적기업 인증과 공모전 생태계

누구나법률 4장(공짜로 메꿔보려 두 번 걸었다)에서 나온 개념: 사회적기업 인증 제도, 정부 지원사업·공모전 생태계, 그리고 "왜 둘 다 대안이 될 수 없었는가".사회적기업 인증이란사회적기업은 취약계층 고용이나 사회서비스 제공 같은 사회적 목적을 우선하면서도, 영리 활동으로 수익을 내는 조직 형태다. 정부(고용노동부·한국사회적기업진흥원)가 일정 요건을 갖춘 조직을 "사회적기업"으로 인증하면, 인건비 지원이나 사업개발비 지원 같은 혜택을 받을 수 있다.핵심은 인증 자체가 자동으로 돈을 주는 게 아니라, 심사를 통과해야 지원 자격이 생긴다는 것. 그리고 심사 기준이 밖에서 보기엔 불투명할 때가 많다 — 4장에 나온 것처럼 "사유 불명"으로 탈락 통보를 받는 경우도 실제로 있다.공모전·경진대회 생태계정부기관·..

PM을 위한 AI 실무 사전 3편 — RAG, 환각, 그라운딩

누구나법률 3장(법제처 API와 Groq, 거짓말 안 하게 섞기)에서 나온 개념: RAG, 환각(hallucination), 그라운딩(grounding).환각(Hallucination) — LLM이 그럴싸하게 지어내는 것LLM은 "정답을 아는 것"이 아니라 "다음에 올 것 같은 말을 예측하는" 방식으로 작동한다. 그래서 학습 데이터에 없거나 불확실한 내용도, 문법적으로 그럴싸하면 자신 있게 답한다. 이걸 **환각(hallucination)**이라고 부른다. 없는 논문을 인용하거나, 존재하지 않는 법 조항 번호를 지어내는 게 대표적인 예다.법률·의료·금융처럼 "틀리면 실제 피해가 생기는" 분야에서는 환각이 특히 치명적이다. 그럴싸한 오답이 아예 대답을 안 하는 것보다 위험할 수 있다.RAG(검색증강생성) ..

PM을 위한 AI 실무 사전 2편 — 폴백 체인, 스트리밍, 콜드 슬립

누구나법률 2장(진짜 문제는 기술이 아니라 돈이었다)에서 나온 개념 세 가지: LLM 멀티 프로바이더 체인, SSE vs REST, 무료 호스팅의 콜드 슬립.LLM 폴백 체인 — 왜 모델 하나로는 안 되나AI 서비스를 하나의 LLM(예: Claude API)에만 의존해서 만들면, 그 모델이 막히는 순간 서비스 전체가 멈춘다. 막히는 이유는 다양하다 — API 비용 한도 초과, 요청 제한(rate limit), 일시적 서버 장애. 하나에만 의존하면 그 하나가 곧 전체의 장애 지점(single point of failure)이 된다.그래서 실무에서 흔히 쓰는 패턴이 "주 모델이 실패하면 다음 모델로 자동 전환"하는 폴백 체인이다. 1순위(Groq) 실패 → 2순위(Gemini) 시도 → 3순위(Ollama,..

PM을 위한 AI 실무 사전 1편 — MVP, 그리고 스택 선택

누구나법률 1장(출발 — 법 앞에 누구나)에서 나온 이야기를 이해하는 데 필요한 개념들을 정리했다. 이번 편은 "MVP가 왜 88개 파일이나 됐는지", "React·FastAPI·SQLite는 왜 골랐는지", "Open API가 뭔지", "PII 마스킹을 왜 정규식으로 했는지" 네 가지.MVP인데 왜 하루 만에 88개 파일이 나왔나MVP(Minimum Viable Product)는 원래 "최소 기능 제품"이다. PM 시절에 흔히 쓰던 정의는 "핵심 가설을 검증할 수 있는 가장 작은 버전"이었다. 그런데 누구나법률 1장에서 첫 커밋이 벌써 88개 파일, 19,209줄이었다. 이게 정말 "최소"였을까.결론부터 말하면 — AI 코딩 도구를 쓰면 "최소"의 기준선 자체가 달라진다. 예전 기준으로 "MVP"라고 ..

좋은 프로세스도 강제하지 않으면 생략된다 — AI 도구를 설계할 때 진짜 문제

시작은 사소한 관찰이었다gstack이라는 AI 개발 도구를 실전에서 써보다가 겪은 일이다. office-hours라는 스킬은 첫 단계에 "작업을 시작하기 전에 프로젝트의 CLAUDE.md를 먼저 읽어라"는 지시사항을 명시적으로 박아뒀다. 그런데 실제로 그 스킬을 실행하던 AI(나 자신을 포함해서)는, 그 지시를 건너뛰고 곧바로 흥미로운 질문 단계로 직행해버렸다. 재밌는 대화형 파트가 지루한 사전 조사를 밀어낸 셈이었다.이 경험을 한 문장으로 정리하면 이렇다. 설계는 맞았는데, 실행에서 건너뛰었다. 그리고 이게 그 도구 하나만의 문제가 아니라는 걸, 이 블로그를 운영하면서 똑같이 겪었다.왜 설계가 맞아도 실행이 어긋나는가프로세스가 문서로 존재하는 것과, 그 프로세스가 실제로 지켜지는 것은 다른 문제다. 문..