공공기관 고도화 실전

여러 사이트를 동시에 고도화할 때 디렉토리 구조 설계 방법

DDODDO_LAB 2026. 2. 27. 14:06
반응형

공공기관 고도화 프로젝트를 하다 보면 이런 상황이 나온다.

  • 동일한 구조의 사이트 5~9개
  • 공통 소스는 공유
  • 일부는 별도 관리
  • 기존 레거시는 유지
  • 신규 레이아웃은 전면 개편

이때 디렉토리 구조를 잘못 잡으면
중반부터 수정 범위가 통제되지 않는다.

고도화의 핵심은 “코딩”이 아니라
구조 설계다.

 

1. 가장 많이 하는 실수

❌ 기존 폴더 안에 그냥 덮어쓰기

❌ v2, v3를 섞어 쓰기

❌ 사이트별로 공통 파일을 복사해서 관리

이렇게 되면:

  • 공통 수정 시 9번 수정
  • QA 반영 누락
  • 배포 충돌
  • 유지보수 지옥

 

2. 기본 전략: “공통과 개별을 분리하라”

여러 사이트 고도화 시
폴더는 크게 3단계로 나누는 것이 안전하다.

/common
/site-a
/site-b
/site-c

 

추천 구조 예시

/assets
    /common
        /css
        /scss
        /js
        /img
    /site-a
       /css
       /js
       /img
    /site-b
    /site-c

 

핵심 원칙

  • 공통 컴포넌트는 common에만 존재
  • 사이트 전용 수정은 site 폴더에서만 처리
  • 공통을 복사하지 않는다

 

3. 병행 운영(v2) 구조 설계

고도화는 보통 병행 운영이 많다.

이 경우:

/v1 (기존)
/v2 (고도화)
/common

권장 방식

  • v1은 건드리지 않는다
  • v2는 새 구조로 설계
  • 공통은 점진적 통합

 

4. CSS/SCSS 구조 통일 전략

공통 SCSS 구조 예시:

/common/scss
    _variables.scss
    _mixins.scss
    /components
        _button.scss
        _table.scss
        _form.scss
    main.scss

 

사이트 전용은:

/site-a/scss
    _override.scss

 

중요 포인트

  • 공통은 설계
  • 사이트는 override
  • 공통을 직접 수정하지 않음 (원칙)

5. 배포 전략까지 고려해야 한다

고도화 구조는
“운영 환경”까지 고려해야 한다.

확인해야 할 것:

  • 배포 단위는 사이트별인가?
  • 공통 배포 시 영향 범위는?
  • CDN 사용 여부?
  • 캐시 무효화 전략?

디렉토리 구조는
운영 전략과 연결되어야 한다.

 

6. 여러 사이트 동시 작업 시 규칙

1) 네이밍 규칙 통일

  • class 네이밍
  • 파일명 규칙
  • 버전 표기 방식

2) 공통 수정은 문서화

  • 변경 로그 기록
  • 영향 사이트 체크

3) 사이트별 override 최소화

  • 복사 금지
  • 중복 정의 금지

 

7. 실무 루틴 (추천 작업 순서)

  1. 공통 컴포넌트 설계
  2. 공통 SCSS 구조 확정
  3. 사이트별 override 설계
  4. 1개 사이트로 파일럿 적용
  5. 나머지 사이트 확장

처음부터 전체에 적용하면 위험하다.

 

8. ChatGPT 활용 포인트

구조 설계 요청 예시 프롬프트:

동일 구조의 7개 사이트를 병행 고도화해야 한다.
공통과 개별을 분리한 디렉토리 구조를 제안해줘.
배포와 유지보수를 고려해서 설명해줘.

 


정리

여러 사이트를 동시에 고도화할 때
디렉토리는 단순한 폴더 구성이 아니다.

수정 범위를 통제하는 장치

다.

 

공통은 중앙집중
개별은 최소 override
기존은 보호

이 세 가지만 지켜도
고도화 프로젝트는 안정된다.

 

반응형