프로젝트 생애주기 도구 (수정중)

1. 왜 devtools 인가 — 각자 자기 계정에서 굴린다

팀원은 이전부터 자기 홈($HOME)에서 프로젝트를 만들어 왔다. 달라진 건 sudo 권한 수준이다.

2026-04-24~06-20 동안 devteam 은 화이트리스트(apt·apache·certbot·서비스 재시작)만 허용하는 제한 sudo 였다. 그래서 dev 도메인 노출·프로젝트 삭제 같은 정상 작업에 마찰이 있었다.

2026-06-20부터 devteam 전원이 풀 sudo(NOPASSWD:ALL) — ubuntu 와 동등 으로 통일됐다(+postgres superuser). 그 마찰이 사라져, 이제 각 팀원이 자기 홈에서 프로젝트 생성·노출·삭제까지 막힘 없이 직접 한다.

적용 범위는 dev/공유 박스(43.200.38.93) 한정이다. prod 박스(52.79.132.206)는 이 정책을 적용하지 않는다(공유 ubuntu 계정 운영).

이걸 가능하게 하는 게 프로젝트 생애주기 에이전트 3종이다. 이들은 별도 repo에 들어 있다:

• repo: popupstudio-ai/standarda-devtools — 1회 셋업(§2)을 하면 자기 홈에 ~/standarda-devtools 로 받아진다.
• 에이전트: create-project(생성) · delete-project(삭제) · clone-repo(기존 repo 올리기)

원문 운영 문서는 팀 wiki의 onboarding/devtools-setup.md 다(자습용). 이 강의노트는 그 문서를 따라 "실제로 손으로 해보는" 데 초점을 둔다.

2. 1회 환경 셋업 — setup_devtools_env.sh

자기 계정으로 로그인한 뒤 한 번만 실행한다. 스크립트는 멱등(여러 번 돌려도 안전)이다.

bash /home/ubuntu/wiki/scripts/setup_devtools_env.sh
source ~/.bashrc   # PATH·AWS 환경변수 반영

source ~/.bashrc 는 스크립트가 방금 ~/.bashrc 에 추가한 PATH(cookiecutter)·AWS 환경변수를 지금 이 셸에 즉시 반영하려는 것이다(필수는 아니며, 새 터미널을 열면 자동 반영된다 — .bashrc 는 셸 시작 시 한 번 읽히므로).

스크립트가 처리하는 4가지:

이미 충족된 것(dev 박스): sudo(devteam 전원 풀 admin)·postgres(전원 superuser)는 별도 셋업이 필요 없다.

devtools 업데이트는 각자 git pull — ~/standarda-devtools 는 각 유저 홈에 clone된 독립 사본이라, 누군가 에이전트를 고쳐 push해도 자동 반영되지 않는다. 최신 에이전트를 쓰려면 cd ~/standarda-devtools && git pull(또는 위 셋업 스크립트 재실행 — 3번이 git pull 을 겸한다). "에이전트가 업데이트됐다는데 내 건 옛날 그대로"면 pull을 안 한 것이다.

3. GitHub repo 삭제 권한만 수동 — delete_repo scope

팀원 전원이 이미 gh 인증이 돼 있고 repo scope가 있어 push·clone·repo 생성은 그대로 된다. 다만 delete-project 로 GitHub repo 삭제까지 하려면 delete_repo scope가 추가로 필요하다. 기기 코드 인증이라 본인이 직접 실행한다:

gh auth refresh -h github.com -s delete_repo

repo 삭제를 안 쓸 거면 생략해도 된다 — delete-project 가 그 단계만 건너뛴다.

4. 사용 — 항상 devtools 디렉토리에서 켠다 (공통)

생성이든 삭제든 항상 ~/standarda-devtools 에서 Claude Code를 켜고 자연어로 요청한다.

cd ~/standarda-devtools
claude

⚠️ 헷갈리기 쉬운 점: 결과물(새 프로젝트)은 devtools 디렉토리 안이 아니라 실행한 유저의 홈($HOME)에 생성된다. 예를 들어 gildong 이 실행하면 /home/gildong/<project> 에 만들어진다.

5. 🟢 프로젝트 생성 — create-project

devtools에서 Claude Code를 켠 뒤:

"create-project 로 'Skyrocket Agent' 만들어줘"

에이전트가 자동으로 하는 일:

1. slug 도출 (Skyrocket Agent → skyrocket_agent)
2. 포트 할당 (위키 포트 표 갱신)
3. cookiecutter 실행 → $HOME/skyrocket_agent 생성 (GitHub repo는 post-hook이 생성)
4. .memory symlink 연결
5. CLAUDE.md 의 포트 치환

이어서 본인이 직접 (전 과정이 대화형이라 에이전트가 대신 못 한다):

cd ~/skyrocket_agent
./setup.sh          # DB 비밀번호 · .env 편집 · createsuperuser (대화형)

setup.sh 가 makemigrations 로 초기 마이그레이션을 만든 뒤 초기 commit/push까지 진행한다.

dev 도메인으로 노출하려면: 새 프로젝트(~/skyrocket_agent/src)에서 Claude Code를 켜고 /dev 를 실행한다 → 포트 + Apache vhost + 인증서까지 자동(devteam 풀 sudo라 비밀번호 없이 진행).

6. 🔴 프로젝트 삭제 — delete-project (3단계 안전장치)

devtools에서 Claude Code를 켠 뒤:

"delete-project 로 skyrocket_agent 지워줘"

삭제는 3단계로 안전하게 진행된다 — 한 번에 지우지 않는다:

1. Phase 1 — 조회 (read-only): 디렉토리·DB·포트·Apache vhost·인증서·Route53·GitHub repo·메모리 중 존재하는 자원만 스캔한다. 이 단계에선 아무것도 삭제하지 않는다.
2. Phase 2 — 확인: 삭제 대상 목록을 보여주고 yes 입력을 기다린다.
3. Phase 3 — 삭제: 순서대로 정리 — DB drop → vhost/인증서/Route53 → repo → 디렉토리 → 메모리.

삭제 후 본인이 직접 해야 하는 것 2가지:

• 위키 포트 표 commit — 에이전트는 위키 행만 지우고 commit은 하지 않는다: bash cd /home/ubuntu/wiki && git add -A && git commit -m "포트 회수: skyrocket_agent" && git push
• GitHub repo 삭제 — delete_repo scope(§3)가 없으면 그 단계만 건너뛴다. scope를 추가한 뒤 재시도하거나, 수동으로: bash gh repo delete popupstudio-ai/<slug> --yes

7. 📥 기존 repo를 서버에 올리기 — clone-repo

이미 GitHub에 있는 repo를 표준 레이아웃으로 가져올 때:

"clone-repo 로 https://github.com/popupstudio-ai/foo.git 셋업해줘"

표준 레이아웃($HOME/foo/src)으로 clone + .memory symlink + (Django면) venv·패키지 설치까지 자동으로 한다.

오늘 정리 + 다음

• 정리: 프로젝트 생애주기(생성·삭제·clone)는 devtools repo의 에이전트 3종이 담당한다. 항상 ~/standarda-devtools 에서 Claude Code를 켜고 자연어로 요청하되, 결과물은 자기 홈($HOME)에 생긴다. 환경은 setup_devtools_env.sh 한 번으로 끝나고, repo 삭제 권한(delete_repo scope)만 본인이 수동으로 붙인다.
• 흔한 함정:
• devtools 디렉토리 안에 프로젝트가 생긴 줄 알고 그 안을 뒤진다 → 실제로는 $HOME/<project> 다.
• delete-project 를 돌렸는데 GitHub repo가 그대로 남아 있다 → delete_repo scope가 없어 그 단계만 건너뛴 것. §3으로 scope 추가 후 재시도하거나 gh repo delete 수동 실행.
• 프로젝트를 지웠는데 포트 표에 행이 남아 있다 → 에이전트는 위키 행만 지우고 commit은 안 한다. wiki 에서 직접 commit·push 해야 회수가 반영된다.
• 다음 시간: 생성한 프로젝트의 속을 들여다본다 — L01 프로젝트 구조와 settings 환경 분리 로 이어진다.
• 자습 권장: 팀 wiki의 onboarding/devtools-setup.md(원문 운영 문서)와 onboarding/new-project.md(cookiecutter 상세). sudo 정책은 infrastructure/sudo-policy.md.