Warz's Studying

이걸 왜 그동안 몰랐을까? 사실 이걸 알고 있었다면 전작과 같이 start:local 하나 때문에 대대적인 패키지 스크립트 수정 따위 하지 않아도 되었다. 

경위는 이러하다. 내가 git clone 받아 온 브랜치는 main 브랜치이고, 이 브랜치는 정상적으로 작동이 되지 않는(...) 브랜치이다. 실제 개발 환경 테스트가 가능한 브랜치는 develope 브랜치라고 따로 존재하였다. 

애시당초 develope 브랜치에서 서버 가동을 했더라면 아까 스크립트 변경 삽질기는 없었을 것인데.... 뭐 그래도 하나 배워갔다고 생각하겠다. 그리고 그동안 git은 clone, add, commit, push, PR, merge 이런 것 밖에 안 해봐서 브랜치를 딱히 변경할 필요성을 느끼지 못했는데, 이번 기회에 새로 배웠다. 

내가 있는 현재 브랜치 (main) 에서 (develope) 브랜치로 이동하려면 먼저 git status 명령어로 현재 디렉토리의 상태를 확인한다.

다음으로 git checkout <branch-name> 명령어를 입력한다. 나의 경우는 <>란의 develope가 되겠다. 이러면 main -> develope로 브랜치가 변경되었다. 파일들도 상당히 달라졌고 무엇보다 서버 가동이 전혀 문제없이 잘 되었다

...가 아니라, 아까 삽질했던 것 때문에 파일의 내용들이 상당히 달라졌고 이를 위해서는 변경 사항을 commit 하거나 stash해야 한다는 것이다. commit할 이유가 전혀 없으니 git stash 명령어를 사용하여 현재 작업 트리의 변경 사항을 stash했다.

브랜치 변경도 이번이 처음이고 당연히 stash도 처음 사용해봤는데 이 stash가 브랜치를 이동할 때 숱하게 쓰인다고 한다. stash의 의미는 티스토리로 따지면 임시저장과 비슷한 기능을 수행한다. 글을 쓰다가 싫증나서 글 쓰기 페이지를 벗어나려고 할 때 그냥 쓰던 글을 날리거나, 임시저장을 해야 나갈 수 있는 것처럼, git은 날리는건(...) 안되고 커밋해서 변경사항을 확실하게 저장하거나, stash로 임시저장을 하고 나중에 git stash pop로 변경 사항을 복원하든 해야 한다. 

보통 NestJS는 서버 가동 시 npm (run) start나 npm run dev를 쓰는 게 일반적이라고 알고 있다.

그런데 우리 프로젝트는 특이하게도 npm run start:local이라는 스트립트로 서버를 가동한다. 

코드를 입력하고 가동을 하려는데? 

npm ERR! Missing script: "start:local"
npm ERR!
npm ERR! To see a list of scripts, run:
npm ERR!   npm run
npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\LG\AppData\Local\npm-cache_logs\2023-10-16T03_47_01_257Z-debug-0.log

npm ERR! Missing script: "start:local" 오류는 "start:local"이라는 스크립트가 package.json 파일에 정의되지 않았기 때문에 발생한다. 따라서  package.json 파일의 "scripts" 섹션 내에 "start:local" 스크립트를 추가해야 한다.

"scripts": {
    // 이전 스크립트들...
    // ...
    
    // 여기에 start:local 스크립트 추가
    // index.js 파일을 직접 실행합니다.
    
   	"start:local": "node index.js"
}

이런식으로 수정해주면 된다. 개발 환경에서 로컬 서버를 실행하기 위해 이렇게 실행하는 것이다.

그런데 문제는 이것 뿐이 아니었다. 

package.json 파일을 살펴보니 "dependencies" 섹션에서 "-" 패키지를 썼는데 이는 유효하지 않다. "g"패키지도 마찬가지. 또한, "devDependencies" 섹션에서 "@nestjs/cli", "@nestjs/schematics", 그리고 "@typescript-eslint/eslint-plugin"과 관련된 버전들은 최신 버전으로 업데이트되지 않았다. 마지막으로 제일 중요한 cross-env 패키지를 설치해야 하는데 하지 않았다. 이는 "start:local" 스크립트에서 사용되므로 꼭 필요하다.

{
  "name": ㅇㅇㅇㅇㅇ
  "version": "0.0.1",
  "description": "",
  "author": "",
  "private": true,
  "license": "MIT",
  "scripts": {
    // 스크립트들...
    // ...
    // 여기에 start:local 스크립트 추가
    // cross-env를 사용하여 NODE_ENV 환경 변수를 설정합니다.
   	"start:local": "cross-env NODE_ENV=local nest start --watch",
    
    // start:local-pm2, start:dev, start:prod 등의 스크립트도 그대로 두세요.
    
  },
  
  	// dependencies와 devDependencies는 여기에 있어야 합니다.
  
  	"dependencies": {
    	"@adminjs/express": "^5.0.1",
    	"@adminjs/nestjs": "^5.0.1",
    	"@adminjs/typeorm": "^4.0.",
        ... (다른 종속성들)
   },
   
   "devDependencies":{
       "@nestjs/cli":"^9.,8,.7,"
       "@nestjs/schematics":"^9.,8,.7,"
       ... (다른 개발 종속성들)
       
       // cross-env 추가
     	"cross-env":"^7.,0,.3"
   },
   
   // jest 설정 등 다른 부분은 그대로 두세요.
}

이렇게 변경해주고,

npm install -g cross-env

로 설치해 줘야 비로소 start:local 스크립트를 쓸 수 있게 된다.

[Nest] 36104 - 2023. 10. 16. 오후 12:44:21 ERROR [TypeOrmModule] Unable to connect to the database. Retrying (5)... Error: connect ECONNREFUSED ::1:3306 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1300:16)

초장부터 이런 오류가... NestJS에서 데이터베이스에 연결 할 수 없고,  "ECONNREFUSED" 오류는 로컬 호스트(localhost)의 3306 포트(MySQL, MariaDB)에 대한 연결이 거부되었음을 의미한다. 처음엔 학교 와이파이에 연결한 상태에서 개발을 진행 중이었기 때문에 학교측에서 와이파이에 포트 제한을 걸어놓은 줄 알고 있었다(실제로 학교 선배도 그렇게 말했었다. 그래서 어찌저찌 우회해서 개발했다고...) 

그래서 별짓 다 했다. 방화벽 문제인가 싶어서 인바운드 편집도 해보고... 프로젝트 DB로 MariaDB를 쓰고 있었기 때문에 3306 포트 접속 허용하고... 암튼 별 걸 다 해봤다. 그런데도 계속 똑같은 오류가 떠서 원인이 뭘까 곰곰히 생각해 보았다.

결국, 다음날에 문제를 해결할 수 있었다. 문제의 원인은 학교 와이파이도, 방화벽도 문제가 아니었다. 문제는 그냥 SSH 터널링이 안 되어서 그런 것이었다. 사실 이를 전혀 간과하지 못했던 것이, 나는 이미 파워쉘을 통해 SSH 터널링 해 놓은 상태였고, 그 상태에서 접속을 시작했는데 안 되었던 거라서(프로젝트가 그냥 일회성 토이프로젝트가 아닌, 실제로 창업팀이 서비스할 프로덕트를 만드는 것이라 보안이 그 무엇보다 중요해서 SSH 서버를 반드시 사용해야 한다) 전혀 터널링이 안 되어서 문제가 되었을 것이라는 생각을 안 해 봤다.

그런데, 내가 쓰고 있는 IDE는 VSCode인데, 여기서 터미널을 제공해주고 있다. 여기서 ssh 접속 코드를 입력해주면 되는 거였는데 따로 윈도우 터미널로 접속하면 그게 IDE까지 연동이 되지는 않는 모양이다.(왜 그런지는 모르겠지만 잠재적으로 내린 결론이다) 결국 윈도우 터미널이 아닌 IDE에 내장된 터미널로 SSH 터널링 했고, 그 후 접속 시도해 봤는데 그동안의 삽질이 무색하게도 바로 성공해버렸다...

결론: 개발 시, SSH 서버에 접속할 때는 반드시 IDE에 내장된 터미널을 통해 터널링을 시도하자.