터미널이 조용해지면 새 명령보다 상태 한 줄부터 적으세요

AI 코딩 도구에게 설치, 빌드, dev 서버 실행을 맡기다 보면 터미널이 조용해지는 순간이 있습니다. 커서만 깜빡이고 새 로그가 없으면 초보자는 보통 두 가지 중 하나를 합니다. 바로 Ctrl+C를 누르거나, 같은 명령을 새 터미널에서 한 번 더 실행합니다. 둘 다 먼저 할 행동은 아닙니다. 지금 필요한 것은 멈춘 명령을 혼내는 것이 아니라 원인 로그를 잃지 않고 종료할 준비입니다.

npm scripts 문서는 package.json의 scripts에 적힌 명령이 npm run <stage>로 실행된다고 설명합니다. 즉 터미널에서 돌아가는 명령은 프로젝트 설정과 연결된 작업입니다. 강제로 끄기 전에 무엇이 실행 중이었는지 남겨야 AI에게도 좁게 물을 수 있습니다. 오늘 목표는 한 가지입니다. 종료 버튼을 누르기 전에 상태, 로그, 변경 파일을 한 번에 묶는 것입니다.

Tap to zoom

먼저 멈춤인지 긴 작업인지 나눕니다

터미널이 조용하다고 해서 모두 멈춘 것은 아닙니다. npm install, next build, 이미지 생성, 테스트 실행은 몇십 초 동안 새 로그가 없을 수 있습니다. 반대로 같은 줄에서 오래 멈추고 CPU나 네트워크 사용도 없으며 로그가 전혀 늘지 않는다면 중단 후보입니다.

초보자는 시간을 감으로 재지 말고 아래처럼 한 줄로 남깁니다.

실행한 명령:
마지막 로그:
기다린 시간:
화면 상태:

예를 들면 이렇게 적습니다.

실행한 명령: npm run build
마지막 로그: Creating an optimized production build ...
기다린 시간: 약 8분
화면 상태: 새 로그 없음, 프롬프트가 돌아오지 않음

이 네 줄이 있으면 AI에게 "멈췄어요"라고만 말하는 것보다 훨씬 안전합니다. AI가 만든 코드가 안 돌아갈 때 30초 오류 프롬프트에서도 원리는 같습니다. 마지막 줄만 던지지 말고 실행한 명령과 멈춘 위치를 함께 줘야 합니다.

마지막 로그 20줄을 먼저 저장합니다

강제 종료 전 가장 많이 잃는 것은 코드가 아니라 로그입니다. 터미널을 닫거나 프로세스를 죽이면 방금 출력된 오류 문맥을 잃을 수 있습니다. 먼저 마지막 로그를 복사해 둡니다. 너무 길면 마지막 20줄이면 충분합니다.

마지막 로그 20줄:
[여기에 복사]

빌드나 설치 로그에서 중요한 것은 보통 세 가지입니다.

여기서 바로 "다시 실행해 줘"라고 하지 않습니다. 먼저 로그를 보관한 뒤 종료 여부를 판단합니다. 로그가 있으면 중단 뒤에도 같은 상황을 재현하거나 AI에게 최소 질문을 할 수 있습니다.

Tap to zoom

프로세스가 아직 살아 있는지 확인합니다

명령이 멈춘 것처럼 보여도 실제로는 아직 실행 중일 수 있습니다. Windows에서는 작업 관리자나 PowerShell에서 프로세스를 볼 수 있습니다. Microsoft Learn의 Get-Process 문서는 로컬 컴퓨터의 프로세스를 가져오는 명령으로 설명합니다.

PowerShell에서는 이렇게 봅니다.

Get-Process node
Get-Process npm -ErrorAction SilentlyContinue

프로세스를 볼 때는 이름만 보지 말고 시작한 터미널과 연결된 작업인지 생각해야 합니다. node가 여러 개 떠 있을 수 있기 때문입니다. 프로젝트 dev 서버, 테스트 러너, 에디터 확장도 Node 프로세스를 쓸 수 있습니다. 그래서 초보자 루틴에서는 바로 모든 node를 죽이지 않습니다. 내가 실행한 명령과 연결된 프로세스인지 먼저 확인합니다.

Git을 쓰고 있다면 현재 작업 트리도 봅니다. git status 문서는 인덱스, 작업 트리, 추적되지 않은 파일의 차이를 보여 준다고 설명합니다.

git status --short

종료 전 상태에서 새 파일이 생겼거나 설정 파일이 바뀌었다면, 그 명령이 중간 결과를 남겼을 수 있습니다. AI가 파일을 너무 많이 고칠 때 수정 범위를 막는 프롬프트처럼 변경 파일을 먼저 봐야 다음 조치가 작아집니다.

중단은 약한 방법부터 시도합니다

중단할 때도 순서가 있습니다. 먼저 터미널에서 Ctrl+C를 누릅니다. Node.js 문서는 SIGINT가 보통 Ctrl+C로 만들어질 수 있고, SIGTERM과 함께 프로세스 종료 신호로 다뤄진다고 설명합니다. 그래서 개발 서버나 npm 명령은 대개 Ctrl+C를 첫 중단 방법으로 씁니다.

1차 중단: Ctrl+C
결과: 프롬프트가 돌아왔는가

프롬프트가 돌아오면 바로 다음 명령을 치지 말고, 종료 직후 나온 로그를 다시 봅니다. "Operation canceled", "terminated", "ELIFECYCLE"처럼 중단 때문에 생긴 메시지와 실제 오류 메시지를 구분해야 합니다.

Ctrl+C가 먹지 않을 때만 더 강한 종료를 검토합니다. Microsoft Learn의 Stop-Process 문서는 프로세스 이름이나 PID로 실행 중인 프로세스를 멈춘다고 설명합니다. 이 명령은 편하지만 범위가 넓으면 위험합니다.

Stop-Process -Id <PID>

초보자에게 중요한 기준은 하나입니다. 프로세스 이름으로 통째로 죽이기보다 PID를 확인하고 종료합니다. Stop-Process -Name node처럼 쓰면 다른 dev 서버까지 같이 꺼질 수 있습니다.

종료 후에는 같은 명령을 바로 반복하지 않습니다

프로세스를 멈춘 뒤 가장 쉬운 실수는 같은 명령을 다시 누르는 것입니다. 멈춘 이유가 포트 충돌, 네트워크 대기, 잘못된 환경변수, 무한 루프라면 반복 실행은 로그만 더 복잡하게 만듭니다.

먼저 아래 네 줄을 채웁니다.

종료 방법:
종료 직후 로그:
바뀐 파일:
다음에 확인할 한 가지:

예시는 이렇습니다.

종료 방법: Ctrl+C 1회
종료 직후 로그: build canceled
바뀐 파일: 없음
다음에 확인할 한 가지: build가 어느 파일에서 멈췄는지

이 상태에서 AI에게 물으면 됩니다.

AI 코딩 중 터미널 명령이 멈춘 것처럼 보여 중단했습니다.

실행한 명령:
[명령]

마지막 로그 20줄:
[로그]

기다린 시간:
[시간]

종료 방법과 결과:
[Ctrl+C, Stop-Process 여부와 결과]

git status --short:
[변경 파일 목록]

요청:
- 새 코드를 바로 만들지 말고, 멈춤 원인 후보를 3개 이하로 좁혀 주세요.
- 다시 실행해도 되는 명령과 먼저 확인할 파일을 나눠 주세요.
- 강제 종료 때문에 생긴 메시지와 원래 오류 메시지를 구분해 주세요.

이 프롬프트의 핵심은 다음 수정을 맡기는 것이 아니라 멈춘 증거를 분류하게 만드는 것입니다. AI에게 "계속 고쳐 줘"라고 하면 파일 변경이 넓어질 수 있습니다. 반대로 명령, 로그, 종료 방법, 변경 파일을 주면 다음 행동은 작아집니다.

다시 실행해도 되는 상태는 세 가지가 맞을 때입니다

명령을 다시 실행하기 전에 아래 세 가지를 확인합니다.

세 가지가 맞으면 다시 실행해 볼 수 있습니다.

npm run build

다만 같은 위치에서 두 번 멈추면 세 번째 반복은 하지 않습니다. 그때는 로그와 상태를 근거로 원인을 좁힙니다. 예를 들어 네트워크 요청에서 멈추면 인터넷, 레지스트리, 프록시를 보고, 특정 파일 처리에서 멈추면 그 파일이나 import를 봅니다. dev 서버가 포트에서 멈춘다면 Next.js dev 서버 포트 충돌을 푸는 순서처럼 포트부터 분리합니다.

오늘 가져갈 기준은 단순합니다. 터미널이 멈춘 듯 보이면 바로 닫지 않습니다. 상태 한 줄, 마지막 로그, 프로세스 확인, 변경 파일을 남깁니다. 그 다음 약한 중단부터 시도하고, 같은 명령을 반복하기 전에 AI에게 멈춘 증거를 분류하게 합니다. 그러면 강제 종료가 다음 오류의 시작이 아니라, 다음 질문을 작게 만드는 단계가 됩니다.

참고 출처

• npm Docs, scripts
• Node.js Docs, process signals
• Microsoft Learn, Get-Process
• Microsoft Learn, Stop-Process
• Git Docs, git status