Branching Strategy가 필요한 이유
혼란 방지
- 여러 명이 동시에 작업할 때 발생하는 충돌(Merge Conflict)을 최소화
안정성 확보
- 개발 중인 불안정한 코드가 사용자에게 노출되는 것을 막아줌
효율적 협업
- 코드가 이동하는 교통 신호 체계를 만듦
Branch
- 메인 코드에 영향을 주지 않고 작업을 할 수 있는 '안전한 작업실'
기본 원칙
- 메인(Main)에서 브랜치를 따서 작업함(checkout)
- 작업이 끝나면 다시 메인으로 합침(Merge)
GitHub Flow
가볍고 빠르고 간단함.
대상: 스타트업, 소규모 팀, 지속적인 배포가 필요한 웹 서비스
특징
- 복잡한 규칙이 없음
- Main 브랜치는 항상 배포 가능한 상태를 유지
- Feature 브랜치에서 모든 작업이 이루어짐
Trunk-Based Development(TBD)
트렁크 기반 개발
대상
- 숙련된 시니어 팀, 구글/넷플릭스 등 초고속 배포가 필요한 조직
특징
- 복잡한 브랜치를 없애고 하나의 트렁크(Main)에 집중
- 브랜치 수명을 극도로 짧게 가져감(하루 이내)
TDB 개발 핵심 원칙
1) 작은 단위로 쪼개기(50~100줄), small Batches
2) 빠르게 병합하기(2~4시간), Fast Merge
3) Feature Flag로 안전하게
Safety with Feature Flag
- Dark Launching: 새로운 기능을 실제 사용자에게는 보이지 않게 배포하여 백엔드에서 테스트하는 기법 (feature flag-off 상태)
Feature Flag
-
코드 내부에 조건문을 심어두어,
특정 기능을 실시간으로 켜고 끌 수 있게 만드는 기술 -
1) Deployed Code
코드는 이미 서버에 배포되어 있는 상태 -
2) Feature Flag
Deploy 버튼 하나로 사용자에게 노출할지 말지 결정할 수 있음
문제가 생긴다면 코드 수정 없이 스위치만 끄면 됨 -
3) Release
사용자 출시
핵심 가치는 안전임
배포(Deployment)와 출시(Release)는 같지 않음
4) AI가 먼저 리뷰→사람이 최종 확인
AI First Review→Human Final check
GitHub Flow vs TBD
앞으로의 대세는?
"TBD"
컨텍스트 윈도우
- AI는 한번에 처리할 수 있는 정보의 양, 물리적 한계
Git Flow
정의
- 빈센트 드리센이 제안한 염격한 브랜치 관리 모델
역할이 사전 정의된 주요 브랜치(예) Master, Develop) 사용 규칙 준수
목적
- 구조화된 작업 흐름(work flow)제공
- 기능 개발(Feature), 출시 준비(Release), 긴급 수정(Hotfix)의 병렬 진행
특징
- 브랜치별 명확한 역할 및 수명 주기(Lifecycle) 분리
- Master, Main: 언제나 배포 가능한 상태
- Develop: 개발 중인 코드가 모이는 곳
Main branch와 Develop branch는 개발의 시작부터 끝까지 평행하게 이어짐
Back-merge: Main에 적용된 사항은 Develop에도 적용이 됨
비교분석
prompt Engineering
context Engineering
RAG(Retrieval Augmented Generation)
- AI 기법 LLM(Large Language Model)이 모르는 정보를
외부에서 검색해서 가져온 뒤 답변을 생각하는 방식
Context Rot
- 인지적 붕괴
발생 원인
- 정보 과부화
- Lost in the middle: 가장 처음에 내린 지시나,
가장 최근에 내린 지시를 제외한 중간에 있는 지시를 잊을 가능성이 높음
주요 증상
- hallucination
- 일관성 상실
하네스의 해결책
- 새 칠판 교체: 주기적인 컨텍스트 새로고침
Context Anxiety
- 행동적 포기
발생 원인
- 한계 예측, 기억 고갈 공포
주요 증상
- 상세 구현 생략
하네스의 해결책
- 칠판 지우기: 대화창을 완전히 지우고 새 에이전트 투입
Harness Engineering
"주방 설비 구축 및 품질 검사 시스템"
3개의 sub agent
-
planner(전략가)
-
generator(제작자)
-
evaluator(검증자)
MVP(Minimum Viable Product)
최소 기능 제품 핵심 기능만 갖춘 가장 작은 단위의 작동 가능한 제품
