B컷전문 | 개발과 인생의 이야기

전자정부 표준프레임워크 프로젝트 생성기로 만들어지는 기본 구조와 생성 코드의 철학을 분석합니다. Controller, Service, DAO 구조의 연결 흐름과 설계 원칙을 이해합니다.

 

---

 

1. 프로젝트를 처음 열었을 때, 혼란부터 온다

 

전자정부 프레임워크 기반의 새 프로젝트를 처음 생성하고 나면,

많은 개발자들이 비슷한 고민에 부딪힙니다.

 

• 디렉토리는 너무 많은데, 어디부터 손대야 하지?
• EgovSampleController, EgovSampleServiceImpl 같은 클래스들이 왜 있는 거지?
• 게시판 샘플이 왜 이 구조로 만들어졌을까?

 

이 질문들은 단순한 ‘코드 사용법’이 아니라,

전자정부 표준프레임워크가 제안하는 아키텍처 설계 철학에 대한 이해가 없으면 답할 수 없습니다.

 

---

 

2. 전자정부프레임워크 프로젝트 생성기란?

 

전자정부 프레임워크에서는 Eclipse 기반의 생성기(Plugin)를 통해 템플릿 프로젝트를 자동 생성할 수 있도록 지원합니다.

이 생성기는 단순한 코드 복사가 아니라, 공공 시스템의 요구사항을 기준으로 정제된 기본 골격을 제공합니다.

 

 

주요 특징

 

• 표준적인 Controller → Service → DAO 흐름을 자동 생성
• MyBatis 기반 SQL Mapper와의 연동 포함
• JSP 뷰 페이지까지 포함한 전체 계층 구조가 기본 구성
• 공통코드 처리, 파일 업로드/다운로드, 페이징 등 샘플 기능 포함

 

이 구조는 단순히 개발을 편하게 하라는 목적이 아니라,

표준화된 시스템 설계를 강제하고 유지보수 리스크를 줄이기 위한 의도로 설계된 것입니다.

 

---

 

3. 디렉토리 구조 이해: 무엇이 자동 생성되고 왜 필요한가

 

프로젝트를 생성하면 아래와 같은 구조가 자동으로 만들어집니다.

src/
 └── main/
     ├── java/
     │   └── egovframework/com/sample/
     │       ├── web/        ← Controller
     │       ├── service/    ← Interface + VO
     │       ├── service/impl/ ← ServiceImpl
     │       └── service/dao/  ← DAO
     ├── resources/
     │   ├── egovframework/sqlmap/
     │   │   └── sample/Sample_SQL.xml
     │   └── message/
     │       └── message-ko.properties
     └── webapp/
         └── jsp/sample/
             └── sampleList.jsp

각 폴더가 의미하는 바는 다음과 같습니다:

 

• web/: Controller 클래스. URL 요청을 받아 Service 호출
• service/: 인터페이스 정의 및 VO 클래스
• impl/: Service 인터페이스 구현부
• dao/: 데이터베이스 접근 객체
• sqlmap/: MyBatis Mapper 정의 (쿼리 명시)
• jsp/: 사용자 인터페이스 출력 화면

 

이 구조는 모든 전자정부 프로젝트의 공통 구조로 사용됩니다.

프로젝트 간 이동, 팀 간 협업, 향후 이관을 위한 표준 스캐폴딩 역할을 하게 됩니다.

 

---

 

4. 자동 생성 코드에 숨겨진 설계 철학

 

생성된 코드들을 보면 중복된 이름과 반복되는 패턴이 많습니다. 예를 들면:

 

• EgovSampleController.java
• EgovSampleService.java
• EgovSampleServiceImpl.java
• SampleVO.java
• Sample_SQL.xml

 

단순히 보기엔 과도한 코드 분리처럼 느껴질 수 있습니다.

하지만 이 구조는 다음 세 가지 목적을 위한 전략입니다:

 

1. 계층 분리를 통한 책임 단위 명확화
2. → 컨트롤러는 요청만 처리하고, 실제 로직은 서비스에서
3. 인터페이스 기반의 구현 추상화
4. → 유지보수나 테스트 시 Mock 서비스 교체 가능
5. Mapper 분리를 통한 쿼리 이력 및 감리 대응 용이성
6. → SQL과 로직이 분리되어 있어 코드 추적이 쉽고, 감리 대응 문서화가 용이함

 

이러한 이유로 모든 전자정부 프로젝트는 과하게 분리된 듯한 구조를 기본으로 채택합니다.

 

---

 

5. 실무에서의 활용 포인트: “왜 그대로 쓰면 안 되는가?”

 

전자정부 프로젝트 생성기는 ‘예시 구조’일 뿐 완성 구조가 아닙니다.

 

실무에서 그대로 쓸 경우 다음과 같은 문제점이 생깁니다:

 

• 샘플 DAO/Service가 실업무와 무관하게 구성되어 있어 재설계 필요
• VO가 고정 필드로 구성되어 있어 실업무와 맞지 않음
• 뷰(JSP)가 너무 단순하여 실업무 화면과 괴리 존재

 

따라서 실무에서는 다음과 같은 절차가 권장됩니다:

 

1. 생성된 기본 구조는 유지한다
2. 샘플 기능은 모두 삭제하거나 별 패키지로 격리한다
3. 실제 업무에 맞게 VO, Mapper, Controller를 설계 후 통합한다

 

---

 

결론 – 생성기는 시작점일 뿐, 실전 구조는 스스로 설계해야 한다

 

전자정부 프레임워크 생성기는 공공 프로젝트 입문자에게 구조를 학습시키고,

실무자에게는 표준화를 위한 출발점을 제공합니다.

하지만 모든 프로젝트가 같은 요구사항을 가지는 것은 아니므로,

자동 생성된 코드를 이해하고 적절히 해체하고 재조립할 수 있는 실력이 핵심입니다.

 

이 시리즈를 통해 자동 생성의 편의성을 넘어서,

설계자의 시선으로 구조를 통제하고 설계할 수 있는 수준까지 다가갈 수 있습니다.

 

---

 

다음 화 예고

 

👉 전자정부 표준프레임워크 시리즈 5화 – 버전별 주요 변화와 특징 정리: 3.0에서 3.10까지 무엇이 달라졌는가?