"차이는 딱 두 글자인데, 결과가 완전히 달랐어요"
develop 브랜치를 추가하고 싶었어요. 검색해서 나온 명령어를 그대로 입력했어요. git branch -M develop. 입력하고 나서 GitHub을 확인해보니 main 브랜치가 보이지 않았어요. develop만 있었어요. 브랜치가 추가된 게 아니라 이름이 바뀐 거였어요. -M 옵션이 뭘 하는지 모르고 썼던 거예요.
git checkout -b develop 명령어로 다시 시도했어요. main은 그대로 유지되고 develop이 새로 생겼어요. GitHub에서 브랜치가 두 개인 걸 확인했어요. 이후로는 명령어 옵션이 뭘 하는지 확인하고 나서 입력하는 습관이 생겼어요.
develop 브랜치를 새로 만들려고 명령어를 찾아서 입력했는데 main이 사라졌어요. git branch -M develop을 썼거든요. -M은 현재 브랜치 이름을 변경하는 옵션이에요. main이 develop으로 이름이 바뀐 거예요. 새 브랜치를 만들려면 git checkout -b develop이었어요. 차이는 딱 두 글자지만 결과가 완전히 달랐어요.
git 명령어는 옵션 하나 차이로 결과가 완전히 달라져요. 검색해서 나온 명령어를 그대로 복붙하면 위험한 이유예요. 특히 브랜치 관련 명령어는 되돌리기 어려운 경우가 있어요. 명령어를 입력하기 전에 각 옵션이 뭘 하는지 한 줄이라도 확인하는 습관이 필요해요. 모르면 AI한테 "이 명령어 입력하면 어떻게 되냐"고 먼저 물어보는 게 맞아요.
git을 처음 배우는 모든 사람에게 동일하게 발생할 수 있어요. 특히 브랜치 전략을 처음 잡을 때 검색 결과를 그대로 따라 하면 같은 실수를 할 수 있어요. 새 브랜치 생성은 git checkout -b 브랜치명, 브랜치 이름 변경은 git branch -M 새이름 — 이 두 가지만 구분해두면 돼요.
관련 프로젝트
프로젝트 개요 기획자(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 스토리텔링 소재로 활용