본문으로 건너뛰기
AIPida
검증됨중급AI 코딩

어디까지 vibe coding으로 하고 어디서부터 직접 짜야 하나요? 결제 붙이는 서비스 기준 경계가 궁금합니다

스타트업에서 혼자 풀스택을 맡고 있습니다. Claude Code / Cursor로 자연어 지시만 하고 diff를 꼼꼼히 안 읽는 "진짜 vibe coding"으로 속도를 많이 냈는데, 최근에 멀쩡히 돌던 결제 콜백이 조용히 깨진 걸 배포 후에야 발견했습니다.

생산성은 포기하기 싫은데, 어디까지 vibe로 맡기고 어디서부터 diff를 직접 읽으며 엔지니어링해야 할지 판단 기준이 흔들립니다. "상황에 따라 다르다" 말고, 코드 종류별로 어디에 선을 그어야 하는지 구체적인 기준이 있을까요? 한국에서 이니시스/토스 결제 붙이는 서비스 기준으로요.

답변 1

  • 채택된 답변에디터 검증

    결론부터: 선을 긋는 축은 "코드 난이도"가 아니라 **blast radius(망가졌을 때 피해 반경)**입니다. 피해가 작고 즉시 되돌릴 수 있으면 vibe, 돈·PII·인증·외부에 영구적으로 노출되면 엔지니어링(=diff를 읽는다)입니다. vibe coding이라는 말 자체가 처음 나왔을 때의 대상도 "주말 프로젝트, 버리는 코드"였지 유지보수할 프로덕션이 아니었습니다.

    판단 테이블 (blast radius 기준)

    코드 종류방식이유
    UI 레이아웃·애니메이션·랜딩vibe OK깨져도 눈에 보이고 즉시 롤백
    내부 어드민·일회성 스크립트·시드vibe OK피해 반경 작고 외부 비노출
    DB 스키마·마이그레이션diff 읽기무음 데이터 손상은 롤백 불가
    인증/세션/RLS·권한엔지니어링우회 한 줄이 전체 유출(위 RLS Q&A 참고)
    결제(이니시스/토스) 콜백·웹훅·금액 계산엔지니어링 + 테스트로 고정돈은 무음 실패가 가장 비쌈
    입력 검증·외부 API 신뢰 경계diff 읽기vibe 코드는 입력 검증을 잘 안 넣음

    당신이 겪은 "결제 콜백이 조용히 깨진" 사고가 정확히 이 표의 아래 두 줄입니다. 결제는 vibe로 맡기면 안 되는 1순위입니다.

    "되는 것 같지만 아님"이 vibe coding의 핵심 실패 모드

    LLM은 SQLi·XSS·RLS·서명 검증이 뭔지 알지만 매번 일관되게 적용하지는 않습니다. 데모 계정으로는 통과하는데 코어 플로우(빈 상태의 신규 유저, 환불, 위조 콜백)는 미검증으로 남는 게 전형적입니다. 그래서 vibe 영역이라도 테스트를 계약으로 박는 것이 속도를 유지하면서 회귀를 막는 거의 유일한 가드레일입니다.

    // 결제 금액 로직은 vibe가 짜도, 이 테스트는 사람이 박는다 (무음 회귀 차단)
    // 함정: 한국 원화는 소수점 없는 정수. /\D/g 정규화가 음수 부호를 삼켜
    //       환불(-) 금액을 양수로 둔갑시키는 사고가 흔하다
    test('환불 금액 부호 보존', () => {
      expect(parseWon('-15000')).toBe(-15000); // \D 정규화면 15000으로 깨짐
    });
    test('토스 웹훅 서명 검증 없으면 거부', async () => {
      const res = await POST('/api/webhook/toss', { body: forgedPayload });
      expect(res.status).toBe(401); // 서명 없는 콜백을 200으로 처리하면 결제 위조가 뚫림
    });
    

    운영 가드레일 4개 (vibe 속도 유지하면서)

    1. 좁은 스코프: 한 번에 한 파일/한 함수만 vibe. 대형 코드베이스를 통째로 맡기면 컨텍스트 한계로 멀쩡하던 코드를 무음으로 바꿔치기합니다(당신의 콜백 사고 메커니즘이 이것일 가능성이 큽니다).
    2. 작은 diff + 커밋 분리: 결제/인증 변경을 UI 변경과 같은 커밋에 섞지 마세요. 그래야 그 부분만 롤백됩니다.
    3. 코어 플로우는 빈 상태에서 직접 검증: 데모 계정 통과는 검증이 아닙니다. 신규 유저로 가입→로그인→결제→환불을 끝까지 한 번 돌리세요.
    4. diff 읽기 트리거: 변경 파일 경로에 auth, payment, webhook, migration, rls, /api/가 들어가면 자동으로 "vibe 종료, 읽기 모드"로 전환.

    when-NOT-to-vibe (한국 맥락)

    • 이니시스/토스의 MID·signKey·시크릿이 닿는 코드: vibe 금지. 서명 검증을 빠뜨리면 결제 위조가 그대로 뚫립니다.
    • 개인정보 처리 코드: 개인정보보호법 대상이라 유출은 버그가 아니라 신고 사안.
    • 한국어 텍스트는 같은 의미라도 영어보다 토큰을 더 먹습니다. 큰 코드베이스를 통째로 프롬프트에 밀어넣는 vibe는 비용·컨텍스트 양쪽에서 더 빨리 무너지므로, 스코프를 좁히는 게 한국어 사용자에겐 비용 절감이기도 합니다.

    한 줄 규칙: "프로토타입은 vibe, 프로덕션은 엔지니어링" — 같은 기능이라도 버리는 데모면 vibe, 유지보수·과금되는 순간 diff를 읽습니다.