🚀 로컬 환경 개발 모드 배포

GitHub Actions를 활용한 CICD를 끝내고 한 가지 요청을 받았다.

바로 로컬 환경에서 도커 컴포즈를 통해 한 번에 서버와 클라이언트를 띄우는 일이었다.

이와 동시에, 수정사항이 바로 반영이 되어야 했다.

이 작업을 하는 이유는… 바로바로 클라이언트와 서버의 액션을 확인해볼 수 있기 때문이다.

수정 방안

우선은 기존의 방식에서 어떻게 띄워야 할지 고민을 했다.

백엔드 server는 그대로 3000포트에서 띄우면 될 것이라고 생각했다.

프론트 엔드는 파일 수정사항이 있을 때 마다 빌드하기는 번거롭다고 생각해서,

프론트도 백엔드처럼 vite로 watch를 켜서 실행하기로 결정했다.

문제 해결 과정

백엔드 처리부터

기존 백엔드 Dockerfile이 yarn start로 되어있어서 dev로 바꿔주려고 했으나,

이 Dockerfile이 GitHub Actions에서 배포될 때 사용되기 때문에 수정할 수 없었다.

그래서 찾아본 결과, docker-compose 파일에서 command 를 작성하면 Dockerfile의 CMD가 무시된다는 얘기를 찾았다.

그래서 docker-compose.yml에 command: yarn --cwd ../app/server dev 를 적어줬다.

command not found nest

그런데 여기서 문제가 발생했다.

server가 계속 restarting 되고 있었다….

로그를 확인해보니 command not found nest라는 문구가 떠 있었다….?

이 문구는 package.json에 정의된 dev 실행 스크립트에서 나는 문제였다. `

"dev": "nest start --watch"

그래서 들었던 생각은 “nestjs가 설치가 안됐나?” 였다.

그렇게 nestjs 를 설치하는 스크립트를 추가했다.

FROM node:22-alpine

WORKDIR /app

COPY package.json yarn.lock .yarnrc.yml tsconfig.json ./
COPY .yarn .yarn
COPY server/ server/

RUN corepack enable && \
    yarn install && \
    yarn add nestjs@cli

WORKDIR /app/server

EXPOSE 3000
CMD ["yarn", "start"]

그런 다음 실행을 했을 때도 똑같은 문제였다.

그렇게 삽질을 열심히 하던 도중 한 가지 트리거를 찾아냈다.

docker-compose에서 아래와 같이 스크립트를 작성했을 때 서로 다른 결과가 나왔던 것이었다.

command:
  - yarn --cwd /app/server dev
      
command: yarn --cwd /app/server dev

검색을 해서 찾아보니, 위에 방식으로 적용했을 때는

/bin/sh -c "yarn --cwd /app/server dev” 를 실행한 것과 같이 실행된다고 한다.

여기서 -c는 뒤의 문자열을 명령어로 해석하는 옵션이다.

위 방식처럼 했을 때, 문제점은 실제 명령어로 입력하는 것이 아니라 문자열을 해석하는 것이기 때문에 예측하지 못한 문제가 생길 수 있다고 한다.

그러면 남은 방법은 두 가지 이다.

command: yarn --cwd /app/server dev

command:
  - yarn
  - --cwd
  - /app/server
  - dev

왜 선택지가 하나 늘었냐면, 위 내용을 학습하면서 이렇게 썼을 때도 동작한다는 사실을 알았기 때문이다.

위 둘의 차이는 우선 command 옆에 바로 명령어를 적었을 때 sh에 직접 실행하는 것과 같은 역할이라고 한다.

즉, yarn --cwd /app/server dev 한 것과 같음

두 번째는 쉘을 빌리지 않고 docker 가 직접 실행하는 방식이라고 한다.

즉, execv("yarn", ["yarn", "--cwd", "/app/server", "dev"]);

sh를 통해 실행하는 구조보다 docker 에서 즉시 실행되는 구조가 도커 내부에서 실행되는 이미지에 어울린다고 판단되어 두 번째 방식을 적용하게 되었다.

---

아마 여기서 궁금증이 하나 있을 것이다. command:

• yarn
• --cwd
• /app/server
• dev

위 방식과

command:

• yarn --cwd /app/server dev

이 둘은 모두 -로 시작하는데 왜 처리 방식이 다르지?

바로 command의 인자가 단일 문자열로 인식된 경우 /bin/sh -c를 쓴다고 한다.

이 문제는 이렇게 해결했다. 이렇게 백엔드를 띄우고 수정이 바로 반영되는지 테스트를 해봤는데….

파일 변경 감지는 외않되

파일이 변경되는 것을 확인하기 위해 적용한 swagger의 api 설명을 바꿔봤다.

/api에 작성된 설명이 변경되지 않았다….

그렇게 백엔드 도커 이미지를 확인했고, COPY /server /server 로 서버 파일을 복사하여 실행하는 것을 알았다.

즉, 이미지 빌드 시에 파일을 한 번 복사해서 가져다 쓰고, 더 이상 건드리지 않는다는 것이다.

그래서 copy 부분을 지우고 docker compose에 volume으로 로컬 서버 파일을 마운트 해줬다.

변경사항을 적용하고 실행한 결과 그래도 해결되지 않았다…

그렇게 삽질을 하다가 tsconfig.json에 감시 옵션을 넣어줘야 한다는 것을 알게되었다.

결국 tsconfig에 아래 옵션을 넣어주게 되었다.

  "watchOptions": {
    "watchFile": "fixedPollingInterval"
  }

api 이름을 바꾸니 서버가 재실행되는 것을 확인해볼 수 있었다!

아까 지웠던 COPY /server /server 부분이 실제 배포 때 GitHub Actions에서 사용되고 있었는데,

이걸 그럼 넣은 상태로 어떻게 마운트를 할 수 있을까? 라는 고민을 했다.

그런데 COPY /server /server를 하고있더라도 compose파일에서 volume으로 마운트하면 크게 상관없이 동작하는 것으로 확인했다.

자 이제 클라이언트

백엔드를 했으니 클라이언트도 잘 될 거라고 생각했다. 큰 오산이었다.

똑같이 작성하고 클라이언트 도커 이미지를 띄웠는데

브라우저로 접속해보니 하얀 화면만 나오고 console에는 아래와 같은 로그만 찍혀있을 뿐이었다..

이 부분을 해결하기 위해 nginx 설정도 해보고 vite.config.ts도 설정해보고

여러 옵션들을 넣어봤으나.. 아무런 도움이 되지 않았다…

그러다가 문득 docker compose 파일을 보는데 nginx에 compose: - 5173 옵션이 있었다…

기겁하며 nginx의 포트 설정을 지웠는데, 아직 해결되지 않았다.

그렇게 삽질을 한 1~2시간 열심히 해보다가…..

nginx의 default.conf 파일을 열었는데 아래 설정이 눈에 들어왔다.

root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html;

그렇다.. 위 설정은 클라이언트 파일을 빌드한 정적 파일을 기본 루트 파일로 처리하는 스크립트이다….

결국 이 스크립트가 있으면 로컬의 client 파일이 nginx의 기본 루트 디렉토리가 되는 것이 아니고

/usr/share/nginx/html 디렉토리에 있는 정적 파일이 기본 루트 디렉토리가 된다.

아마 해당 디렉토리에 아무것도 없어서 하얀 페이지가 나왔던 것이다..

위 옵션을 제거하니 정상적으로 출력이 되었다..!

다만, 여기서 또 문제는 실시간 변경 감지가 안된다는 점이다.

백엔드처럼 tsconfig.json에 같은 설정을 넣어봤으나…안된다…

그래서 또 이것저것 열심히 삽질을 했지만..제대로 되는 건 없었다..

그러다가 docker compose 파일에 두 가지 옵션을 넣어보게 되었는데,

environment:
  - CHOKIDAR_USEPOLLING=true
  - WATCHPACK_POLLING=true

바로 위 두 옵션이다.

• CHOKIDAR_USEPOLLING은 node 환경에서의 파일 시스템 변경을 감지한다.
• WATCHPACK_POLLING은 web pack과 react의 파일 변경을 감지한다.

적용하자마자 프론트 파일을 바꾸니 페이지에 액션이 바로 나왔다.

결말

프론트와 백엔드 모두 nginx 밑에서 동작하게 되었고,

변경에 대해서도 바로바로 적용되는 모습을 확인할 수 있었다.

메인 기능을 구현한 것이 아니라서 소비한 시간에 대해 아쉬운 부분은 있지만

잊지 못할 경험이라고 생각한다…

그래도 계획한대로 구동이 되고, 팀원들 개발 과정에서 시간 단축을 기대할 수 있다면

그것으로 만족한다…