Dev Process Tracker: CLI와 TUI를 활용한 로컬 서비스 관리
I’m happy to translate the article for you, but I’ll need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.
What I Built
I built Dev Process Tracker (devpt), a local development service manager with both CLI and TUI workflows.
It is built for a common reality: multiple local services, mixed startup methods, and failures that are hard to diagnose quickly.
With devpt, I can:
- register known services (
add) - run lifecycle actions (
start,stop,restart) - inspect runtime state (
ls,status) - check logs (
logs) - switch to an interactive workflow (
devpt)
Managed vs. Discovered (왜 두 가지가 모두 중요한가)
This is a core design choice.
- Managed –
devpt에 명시적으로 정의한 서비스(이름, cwd, 명령, 예상 포트) - Discovered –
devpt외부에서 시작되었더라도 현재 로컬 TCP 포트를 듣고 있는 모든 것
Example
devpt에 프론트엔드를npm run dev로 포트 3100에 등록합니다.- 다른 터미널에서 실행 중인 오래된
npm run dev프로세스가 아직 3100 포트에서 실행되고 있습니다.
devpt ls --details는 두 개를 모두 표시하므로 중복을 발견하고 오래된 프로세스를 빠르게 중지할 수 있습니다.
왜 PM2, Docker Compose, 혹은 make 타깃만 사용하지 않을까요?
그 도구들은 유용하지만, 문제의 다른 부분을 해결합니다.
| 도구 | 강점 | devpt가 메우는 격차 |
|---|---|---|
| PM2 | 관리되는 Node 프로세스에 적합 | 혼합 스택 전반에 걸친 광범위한 로컬 프로세스 탐지가 없음 |
| Docker Compose | 컨테이너화된 서비스에 탁월 | 많은 팀이 하이브리드 로컬 스택(호스트 + 컨테이너)을 사용 |
| make targets | 편리한 단축키 | 런타임 인벤토리나 진단 인터페이스가 아님 |
devpt는 크로스‑스택 로컬 런타임 가시성 + 라이프사이클 제어 + 충돌 진단을 하나의 인터페이스에서 제공하는 데 초점을 맞춥니다.
데모
저장소:
하루 일과
하루 시작: 이미 실행 중인 것은?
./devpt ls --details
이 명령은 현재 머신에서 청취 중인 모든 항목을 한눈에 보여줍니다. devpt에 명시적으로 등록한 서비스와 다른 곳에서 시작되어 잊혀진 프로세스 모두 포함됩니다.
로컬 스택 올리기
./devpt add frontend ./sandbox/servers/node-basic "npm run dev" 3100
./devpt add api ./sandbox/servers/python-basic "python3 server.py" 3300
./devpt start frontend
./devpt start api
여기서 devpt는 개발자들이 매일 실제로 실행하는 명령들을 관리합니다. 단순화된 예시가 아니라 실제 사용되는 커맨드입니다.
문제 조사 및 복구
./devpt status frontend
./devpt logs frontend --lines 60
./devpt restart frontend
./devpt stop api
문제가 발생했을 때, 제어와 진단이 한 곳에 모여 있습니다. 충돌 상태를 확인하고, 최근 로그를 살펴보며, 도구나 터미널을 전환하지 않고 바로 조치를 취할 수 있습니다.
인터랙티브 모드 전환
./devpt
동일한 워크플로우를 TUI에서도 사용할 수 있어, 하루 종일 실행 상태를 유지하면서 로컬 환경 변화에 따라 즉시 상호작용할 수 있습니다.
Source:
GitHub Copilot CLI 사용 경험
저는 Copilot CLI를 고속 초안 작성 및 사고 파트너로 활용한 뒤, 프로젝트 요구사항에 맞게 동작을 수동으로 제한했습니다.
예시 1: 명령 검증
프롬프트
gh copilot suggest "add command validation for managed service commands and include tests for blocked patterns"최종 제품에 미친 영향
- 초기 검증/테스트 스캐폴드를 빠르게 만들 수 있었습니다.
- 최종 로직은 프로젝트에 안전한 패턴과 더 명확한 CLI 오류 메시지로 수동으로 다듬었습니다.
예시 2: 크래시 진단 설계
프롬프트
gh copilot suggest "show crash reason and recent log tail in status command for crashed services"최종 제품에 미친 영향
- CRASH DETAILS 섹션 설계에 큰 도움이 되었습니다.
- 최종 출력 및 휴리스틱은 잡음은 줄이고 신호는 강화하도록 편집했습니다.
예시 3: 작동하지 않은 경우
초기 제안 중 하나가 필요 이상으로 광범위한 TUI 리팩터링을 제안했습니다. 저는 그 방향을 거부하고 CLI‑first 설계를 유지했습니다.
전체 상태 재작성(Full‑State Rewrite)을 포기한 이유
상호작용 회귀 위험이 챌린지 범위에 비해 너무 높았기 때문에 다음에 집중했습니다.
- 집중된 UI 동작 개선
- 파괴적인 상태 모델 재작성 금지
이 트레이드오프 덕분에 도구는 안정성을 유지하면서도 사용성을 개선할 수 있었습니다.
워크플로우에 미친 총 효과
- 구현 초안이 더 빨라짐
- 초기 엣지 케이스를 더 잘 발견
- 테스트 작성 시 피드백 루프가 짧아짐
- 최종 동작은 의도적으로 인간이 검토함
프롬프트 수준의 상세 증거는 다음에 문서화되어 있습니다.
대상 독자
devpt는 혼합 로컬 스택(Node, Python, Go, 컨테이너)을 운영하면서 신뢰할 수 있는 런타임 가시성과 빠른 실패 진단이 필요한 개발자를 위한 도구입니다.
핵심 질문: 실제로 무엇이 실행 중이며, 다음에 무엇을 해야 할까?