npm i env-cmd 
yarn add env-cmd 로 설치한다. 

.env.develpoment
.env.production

파일을 루트 폴더에 생성해주고 각각의 환경 변수들을 설정해준다.

Script 를 변경해주어야 하는데
명령어를 입력해서 쉽게 써준다.

  "scripts": {
    "dev": "next dev",
“쓰고 싶은 이름” : “명령어 “ 
    "build:dev": "env-cmd -f .env.development next build",
    "build:prod": "env-cmd -f .env.production next build",
    "start:dev": "env-cmd -f .env.development next start",
    "start:prod": "env-cmd -f .env.production next start",
    "lint": "next lint"
  },

위의 script는 next 일때의 명령어 이다.
Env-cmd -f 는 필수 인것 같다.

그리고 각 파일에서 접근할때는 process.env. 변수명
이렇게 접근을 하였다.

각 빌드마다 미리 설정해둔 환경변수들로 세팅되어서 빌드가 실행된다.

당시 과제 제출때는 이게 정답인줄 알고 이렇게 해서 제출했었는데..
딱봐도 뭔가 찜찜하긴 하였다. 과제가 끝나고 나서 다시 검색을 했을때 모노레포에 대해 개념을 알게 되었다.

모노레포

간단하게 개념에 대해서 정리해본다.
자세한 설명은 네이버 개발자 페이지에서 잘 정리해뒀다.
https://d2.naver.com/helloworld/0923884

등장 배경

처음 모놀로식이라는 방식이 있었다. 이 방식의 비판에서 등장하게 된다.

모놀로식

모놀로식 이란 모듈화 없이 설계된 소프트웨어 애플리케이션을 말한다.
모듈화가 없으면 가져와서 임포트 하는게 없어지고 대량으로 코드가 발생되어서
코드 설계와 배포, 리팩토링에 많은 노력이 필요하다.

그다음 등장하게 된게 멀티레포이다.

멀티레포

모놀로식의 구조에서 모듈화 프로그래밍으로 해결이 되었는데
각각 분리된 모듈은 멀티레포 구조에서 고유한 저장소가 있는 독자적 프로젝트가 되었다.

예시로 각 앱별이 모듈이 되는 것이다.
todoApp,(모듈), 달력앱(모듈)

각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.

현재 대부분의 애플리케이션 개발하는 표준적인 방법이다.

멀티레포에도 문제가 발생하였다.

• 번거로운 프로젝트 생성
  각각의 패키지들은 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish 이 과정을 거쳐야 했다.

• 패키지의 중복코드 가능성

• 관리 포인트 증가

• 일관성 없는 개발자 경험
  각각 프로젝트 마다 테스트 실행, 테스트 등등 실행해야 하고 명령들을 기억해야 한다.

• 다른 패키지의 변경 사항 파악

• 교차저장소의 리펙토링 비용

모노레포 등장

모노레포가 출동했다.
모노레포(monorepo) 구조는 두 개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략이다.
앞선 예시의 분리된 모듈들은 모노레포에서 여전히 독자 프로젝트로 존재하지만 저장소는 같은 곳을 사용한다.

장점

모노레포는 번거로운 프로젝트 생성이 필요없어지고 기존 개발환경 , 빌드, 게시등을 이용할수 있다.

• 더 쉬운 의존성 관리
  의존성 패키지가 같은 저장소에 있다.
• 단일화된 관리 포인트
  각 업데이트를 한번에 반영이 가능하다.
• 일관된 개발자 경험 제공
• 프로젝트들에 걸친 원자적 커밋
  모든 커밋이 함께 작동한다고 한다.
• 서로 의존하는 저장소들의 리팩터링 비용 감소

특징

관리 측면

• 코드 공유: 서로 다른 프로젝트 간에 쉽게 소스 코드를 공유
• 일관성 있는 도구: 서로 다른 프로젝트들(심지어 서로 다른 프레임워크를 사용하더라도)에서 일관된 개발 경험을 제공
• 스케폴딩: 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성
• 프로젝트 제약 및 가시성(visibility): 저장소 내에서 의존 관계를 제한하는 규칙 정의 지원. 예를 들어, 일부 프로젝트를 팀 전용으로 표시하거나 특정 프레임워크을 사용 중임을 기술.

속도 측면

• 로컬 캐싱: 같은 머신에서 같은 것을 두 번 빌드하거나 테스트하지 않음
• 분산 캐싱: 다양한 환경에서 캐시 아티팩트를 공유. 즉, 조직 단위로 여러 CI 환경에 걸쳐 같은 것을 두 번 빌드, 테스트하지 않음
• 로컬 작업 오케스트레이션: 빌드 및 테스트 등의 작업을 순서에 맞게 병렬로 실행
• 분산 작업 실행: 단일 시스템에서 실행되어 여러 시스템에 명령을 전달
• 변화에 영향을 받는 프로젝트 감지: 변경의 영향을 받을 수 있는 항목을 결정하여 영향을 받는 프로젝트만 빌드/테스트

구조 파악 측면

• 워크스페이스 분석: 추가 구성 없이 주어진 워크 스페이스의 의존성 관계를 분석
• 의존성 그래프 시각화: 프로젝트 및 작업 간의 종속 관계를 시각화

처음 봤을땐 좋아보였다.
하지만 모노레포가 항상 정답은 아니라고 한다.

모노레포가 적절한 상황

• 유사한 제품의 집합
• 여러 프로젝트의 변화를 한눈에 파악해야 할 때
• 호스트 애플리케이션을 플러그인 등으로 확장할 때
• 공통 기능을 재사용하는 관련된 프로젝트의 집합
• 유사한 DevOps로 구성된 프로젝트의 집합

정리 글

모노레포 ,멀티레포, 모놀로식 많은 용어들이 있다. 처음 글을 읽었을때 어려운 내용이었다.
이렇게 글을 작성하면서 정리를 해보면서 찬찬히 훑어보니 나름 쫌 이해가 되기시작하였다.
업무를 했을때 멀티레포 형식으로 업무를 맡은것 같다.
각각의 장단점은 있었던것 같다. 따로 저장소가 있었는데 규모가 큰 프로젝트에서 딱 그 레포에서만
작업해도 되니 보기에는 편했다.
아쉬운점이 비슷한 함수 기능이 있었는데 만약 모노레포였다면 함수를 통틀어서 사용할수 있지 않을까에 대한 생각이 들었다.
그리고 코드 비교를 할때 듀얼모니터로 봐서 비교를 했었는데 만약 듀얼모니터가 없었다면 비교가 어려웠을것 같기도 하다. 큰 화면이 필요했다.

다음글

모노레포 구축에도 다양한 도구들이 있다. 다음 번에는 그것에 대해 정리해보려고한다.