"기능이 늘어날수록 대체할지 확장할지보다 역할이 뭔지부터 물어야 한다"
빌드로그에 쌓아온 STAR 스토리, 공개 케이스 스터디, 일상 기록(now feed)이 각자 흩어져 있었습니다. 채용 공고 하나에 지원하려면 어떤 경험을 어떤 문장으로 엮을지 매번 처음부터 고민해야 했습니다. 특히 PM, 기획, 데이터 엔지니어링을 오간 이종 도메인 경험을 하나의 서사로 연결하는 작업 자체가 병목이었습니다.
채용 공고 텍스트를 붙여넣으면, STAR 초안·공개 케이스 스터디·일상 기록 세 소스를 AI가 한 번에 훑어 이 공고에 맞는 경험을 근거와 함께 골라줍니다. 이 매칭 결과를 그대로 재사용해 경력기술서 초안과 자기소개서(문항 커스텀 또는 범용 항목 자동 대응)까지 이어서 생성합니다. 지원 이력은 저장·재조회·삭제가 가능합니다.
빌드로그에 쌓아온 STAR 스토리, 공개 케이스 스터디, 일상 기록(now feed)이 각자 흩어져 있었습니다. 채용 공고 하나에 지원하려면 어떤 경험을 어떤 문장으로 엮을지 매번 처음부터 고민해야 했습니다. 특히 PM, 기획, 데이터 엔지니어링을 오간 이종 도메인 경험을 하나의 서사로 연결하는 작업 자체가 병목이었습니다.
처음엔 "커리어 로그 대신 log/now를 매칭 대상으로 바꿀지"를 고민했습니다. 하지만 설계 전에 실제 데이터부터 조사해보니, 이건 대체 관계가 아니라 역할이 다른 파이프라인이라는 게 드러났습니다.
STAR 추출 스튜디오는 원석(career_logs)을 가공하는 단계이고, Job 스튜디오는 이미 가공된 재료(STAR 초안 + 공개 포스트 + 근황)를 채용 공고라는 기준으로 큐레이션하는 다음 단계입니다. 그래서 기존 STAR 스튜디오는 손대지 않고 완전히 별도 기능(job_applications 테이블, 별도 서버 액션)으로 분리했습니다.
구현 중에는 "AI 산출물을 검증 없이 신뢰하지 않는다"는 원칙이 세 번 실제로 작동했습니다.
매번 "빌드가 성공했다", "정상 반영됐다"는 보고를 그대로 받아들이지 않고, git diff와 파일 원문을 직접 확인한 뒤에만 다음 단계로 넘어갔습니다.
비슷한 구조를 다른 곳에 적용하려면, 먼저 "합칠지 나눌지"를 정하기 전에 각 데이터 소스의 실제 성격(구조화 정도, 입력 경로, 갱신 빈도)부터 확인하는 순서를 권합니다. 그리고 AI 생성 코드는 "타입 체크 통과"와 "빌드 성공"이 곧 정상 동작을 의미하지 않는다는 전제 하에, 최소한 신규/수정 파일 전체 원문을 사람이 한 번은 읽고 커밋하는 절차를 표준으로 두는 것이 재발 방지에 효과적이었습니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용