Github는 온라인 원격 저장소이다
- 내 컴퓨터에서 작업한 내역을 온라인에 올리는 공간
- 커밋 : 작업한 내역 저장
- 푸시 : 내 작업 내역 Github에 업로드
- Pull : 새 작업 공간에서 Github 내용 다운로드
브랜치는 수정 업무 시작할 때 생성
- PR은 Pull Request 약자이다
- “사이드바 UI 수정하자. feat/sidebar-ui 브랜치 만들어줘”로
- 작업 시작할 때 브랜치 이름을 같이 말해주고 시작
API 주소는 온라인 어느 공간에 추가하면 안된다
- 채팅창에 API 주소 붙여넣기 한 순간, 해당 주소는 파기해야 함
- Github API 등록창엔 API 주소 붙여넣기해도 글 작성 공간에 내역이 남지 않음
API 연동 시 비용 최적화도 챙겨야 함
- API 연동 시, 특히 스케줄러 통해 정기적 API 사용 시 비용 계산 필요
- 비용 최적화를 위해 복잡한 연산과 리포트 생성을 분리하는 등의 최적화 작업 필요함
에러는 로그로 읽어야
- 에러 메시지는 텍스트 로그가 더 정확한 진단을 만듬. 스크린샷 보다
AI는 시킨 것만 하니, 맥락을 줘야 함
- 고쳐줘와 함께 이렇게 하는 이유는.. 을 말해줘야 결과가 좋아진다. 어떤 문제인지 말해야 좋다.
- 세션이 바뀌면 AI는 대화를 모른다 → 새 세션엔 “어제 작업 이어가자” 배경 설명이 필요한다.
커밋은 자주하면 좋다, 워드에서 저장 Alt-S 하는 것처럼
- 망가졌을 때 git log로 이전 커밋 시점 돌아갈 수 있음
- 작은 단위로 커밋하면 좋고, 이름을 구체적으로 지으면 찾기 쉽다.
- 한 번에 많이 바꾸면 문제 생겼을 때 찾기 어렵다.
- 브랜치 이름도 feat/기능명, fix/버그명 형식이면 히스토리가 읽힘
환경변수와 config 파일을 구분하라
- 코드는 설계도 API는 열쇠. 설계도 안에 열쇠가 있으면 누구나 들어 올 수 있음
- 열쇠는 안전하게 보관해야 함
- API 키처럼 민감한 값은 코드에 직접 쓰지 않는다. AI가 코드에 키를 직접 쓰려 하면 중지시킬 것
- 내 컴퓨터에서 테스트 : .env 또는 config.json
- 서버 자동화에서 실행 : Github Secrets