전자정부 표준프레임워크 구조, Spring MyBatis 기반 실무 기준 정리

전자정부 표준프레임워크 프로젝트에서 URL은 보이는데 어떤 Controller, Service, Mapper, JSP로 이어지는지 막힌다면 먼저 Spring MVC와 MyBatis 기반 요청 흐름부터 잡아야 한다.

실무에서 막히는 지점은 이름이 어렵기 때문이 아니다. 패키지 구조, XML 설정, Controller와 Service 역할, DAO 또는 Mapper 호출 흐름, 공통 유틸과 컴포넌트가 한꺼번에 보이기 때문에 어디부터 봐야 할지 애매해진다.

핵심 결론: 전자정부 표준프레임워크는 공공 Java 웹 프로젝트에서 자주 쓰는 Spring 기반 개발 표준이다. 구조를 볼 때는 Controller, Service, DAO, Mapper, JSP 흐름을 먼저 잡아야 한다.

확인 순서: 프로젝트 구조 확인 → web.xml과 Spring 설정 확인 → Controller 진입점 확인 → Service/DAO 호출 확인 → MyBatis Mapper와 DB 흐름 확인.

전자정부 표준프레임워크를 어떻게 봐야 할까

전자정부 표준프레임워크는 공공 정보화 사업에서 Java 웹 애플리케이션을 일정한 방식으로 만들기 위해 사용되는 표준 개발 기반이다. 실무에서는 eGovFrame, 전자정부프레임워크, 표준프레임워크처럼 줄여 부른다.

처음 보면 별도의 거대한 기술처럼 느껴지지만, 많은 프로젝트는 Spring MVC, MyBatis, JSP, Tomcat, Maven 구조 위에서 동작한다. 즉 핵심은 완전히 새로운 문법이 아니라 기존 Java 웹 기술을 공공 프로젝트 방식으로 정리한 구조를 읽는 것이다.

공공 SI에서 자주 만나는 이유

공공 프로젝트에서는 개발 방식, 패키지 구조, 공통 기능, 보안 기준, 산출물 관리가 중요하다. 전자정부 표준프레임워크는 이런 요구를 맞추기 위해 자주 선택된다. 특히 레거시 Spring MVC 기반 시스템을 유지보수하는 현장에서는 아직도 자주 만난다.

신입이나 초급 개발자가 이 프로젝트를 맡으면 먼저 “전자정부라서 어렵다”고 생각하기 쉽다. 하지만 실제 장애나 수정 업무는 대부분 Controller URL, Service 로직, MyBatis SQL, JSP 화면, 설정 파일에서 발생한다.

기본 기술 스택 이해

Spring MVC 기반으로 요청을 처리한다

전자정부 표준프레임워크 기반 웹 프로젝트도 요청 처리 흐름은 Spring MVC와 크게 다르지 않다. 브라우저 요청이 들어오면 DispatcherServlet을 거쳐 Controller가 실행되고, Service와 DAO를 거쳐 DB에 접근한다.

Browser
  -> DispatcherServlet
  -> Controller
  -> Service
  -> DAO 또는 Mapper
  -> Database
  -> JSP 또는 JSON 응답

따라서 화면이 안 열리거나 URL이 맞지 않는 문제를 볼 때는 먼저 Spring MVC 매핑을 확인한다. 정적 리소스나 URL 매핑 문제는 resources 경로를 확인하던 방식과 같은 흐름으로 접근하면 된다.

MyBatis를 같이 쓰는 경우가 많다

공공 Java 웹 프로젝트에서는 MyBatis를 사용하는 경우가 많다. 복잡한 SQL, 기존 Oracle 스키마, 보고서성 조회, 동적 조건 검색이 많기 때문이다. 전자정부 표준프레임워크 프로젝트에서도 Mapper XML과 DAO 구조를 자주 본다.

MyBatis가 낯설다면 프레임워크 이름보다 먼저 Mapper XML과 resultMap, parameterType, SQL id를 읽는 연습이 필요하다. 기본 개념은 MyBatis 개요를 이해한 뒤 프로젝트 구조에 대입하면 된다.

프로젝트 구조에서 먼저 볼 폴더

src/main/java와 src/main/resources

Maven 기반 프로젝트라면 Java 소스와 설정 파일이 보통 아래처럼 나뉜다.

src/main/java
  egovframework/example/sample/web
  egovframework/example/sample/service
  egovframework/example/sample/service/impl

src/main/resources
  egovframework/spring
  mapper
  properties

패키지명은 프로젝트마다 다르지만, 보통 web, service, impl, mapper, config 같은 단어가 역할을 알려준다. 무작정 모든 파일을 열기보다 URL을 처리하는 Controller에서 시작해 호출 흐름을 따라가는 편이 빠르다.

src/main/webapp과 WEB-INF

JSP와 웹 설정은 src/main/webapp 아래에 놓이는 경우가 많다.

src/main/webapp
  index.jsp
  WEB-INF
    jsp
    web.xml
  css
  js
  images

WEB-INF 아래 JSP는 브라우저에서 직접 접근하지 못하고 Controller를 통해 렌더링된다. 화면 URL로 JSP 파일을 직접 찾으려고 하면 구조를 잘못 보는 것이다.

Controller, Service, DAO 역할

Controller는 요청과 응답의 입구다

Controller는 사용자의 요청을 받는 입구다. URL 매핑, 파라미터 수집, 화면 이동, JSON 응답 처리 같은 역할을 맡는다.

@Controller
public class SampleController {

    @Resource(name = "sampleService")
    private SampleService sampleService;

    @RequestMapping("/sample/list.do")
    public String list(SampleVO searchVO, Model model) throws Exception {
        List<SampleVO> resultList = sampleService.selectSampleList(searchVO);
        model.addAttribute("resultList", resultList);
        return "sample/list";
    }
}

초급 개발자는 Controller에서 모든 로직을 처리하려고 하기보다 어떤 Service를 호출하는지, 어떤 모델 값을 JSP로 넘기는지 먼저 봐야 한다.

Service는 업무 로직을 모으는 계층이다

Service는 업무 규칙을 처리하는 계층이다. 조회 조건 보정, 등록 전 검증, 여러 DAO 호출 조합, 트랜잭션 처리 같은 내용이 들어간다.

public interface SampleService {
    List<SampleVO> selectSampleList(SampleVO searchVO) throws Exception;
    void insertSample(SampleVO sampleVO) throws Exception;
}

구현체는 보통 service.impl 패키지에 있다.

@Service("sampleService")
public class SampleServiceImpl implements SampleService {

    @Resource(name = "sampleDAO")
    private SampleDAO sampleDAO;

    public List<SampleVO> selectSampleList(SampleVO searchVO) throws Exception {
        return sampleDAO.selectSampleList(searchVO);
    }
}

간단한 CRUD에서는 Service가 DAO를 그대로 호출하는 것처럼 보일 수 있다. 그래도 Service 계층을 유지하는 이유는 나중에 검증, 권한, 트랜잭션, 외부 연계가 들어갈 수 있기 때문이다.

DAO 또는 Mapper는 DB 접근을 맡는다

DAO는 DB 접근을 담당한다. 프로젝트에 따라 EgovAbstractDAO, EgovAbstractMapper, Mapper 인터페이스, SqlSessionDaoSupport 같은 방식이 섞여 있을 수 있다.

@Repository("sampleDAO")
public class SampleDAO extends EgovAbstractMapper {

    public List<SampleVO> selectSampleList(SampleVO searchVO) {
        return selectList("sampleDAO.selectSampleList", searchVO);
    }
}

여기서 문자열 id는 MyBatis Mapper XML의 SQL id와 연결된다. 이 연결이 틀리면 SQL을 못 찾거나, 파라미터가 맞지 않거나, 결과 매핑 오류가 난다.

MyBatis Mapper XML 읽는 법

namespace와 SQL id 확인

전자정부 표준프레임워크 프로젝트에서 DB 조회를 추적할 때는 DAO의 SQL id와 Mapper XML의 namespace, id를 맞춰 본다.

<mapper namespace="sampleDAO">

  <select id="selectSampleList"
          parameterType="SampleVO"
          resultType="SampleVO">
    SELECT ID, TITLE, REG_DATE
    FROM SAMPLE
    WHERE USE_YN = 'Y'
    ORDER BY REG_DATE DESC
  </select>

</mapper>

DAO에서 sampleDAO.selectSampleList를 호출한다면 namespace는 sampleDAO, select id는 selectSampleList여야 한다. 이 기준은 MyBatis 연동을 볼 때도 핵심이다.

VO와 resultType 확인

조회 결과가 비어 있거나 일부 컬럼만 들어오지 않는다면 SQL만 보지 말고 VO 필드명, getter/setter, resultType, resultMap을 함께 확인한다.

확인 대상	볼 내용	자주 나는 문제
DAO 호출 id	namespace.SQL id	SQL id 오타
parameterType	검색 조건 객체	필드명 불일치
resultType	결과 VO	컬럼과 프로퍼티 매핑 실패
Mapper XML 위치	resources 또는 mapper 폴더	설정 파일 누락

설정 파일은 어디부터 볼까

web.xml은 웹 애플리케이션의 시작점이다

레거시 Java 웹 프로젝트에서 web.xml은 매우 중요하다. DispatcherServlet, Spring context loader, encoding filter, security filter, listener 설정이 이 파일에서 시작되는 경우가 많다.

<servlet>
  <servlet-name>action</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
  <servlet-name>action</servlet-name>
  <url-pattern>*.do</url-pattern>
</servlet-mapping>

*.do 패턴을 쓰는 프로젝트라면 URL이 /sample/list.do처럼 끝나는 이유가 여기에 있다. URL을 볼 때 Controller만 보지 말고 servlet mapping도 함께 확인한다.

Spring 설정 파일은 역할별로 나뉜다

전자정부 표준프레임워크 프로젝트에서는 Spring XML 설정이 여러 파일로 나뉘어 있는 경우가 많다. 이름은 다르지만 보통 아래 역할을 가진다.

파일 유형	주요 역할	확인할 상황
context-*.xml	공통 Bean, Service, DAO	Bean 생성 오류
servlet-context.xml	Controller, ViewResolver, resources	URL, JSP, 정적 리소스 문제
sqlmap-*.xml	MyBatis 설정	Mapper XML 인식 문제
properties	DB, 파일 경로, 외부 설정	환경별 값 차이

설정 파일이 많아 보일수록 역할별로 나누어 읽어야 한다. 모든 XML을 한 번에 이해하려고 하면 시간이 오래 걸린다.

JSP 화면과 ViewResolver

Controller return 값이 JSP 경로로 바뀐다

Controller에서 return "sample/list"를 했다고 해서 실제 파일이 프로젝트 루트에 있는 것은 아니다. ViewResolver 설정에 따라 prefix와 suffix가 붙는다.

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  <property name="prefix" value="/WEB-INF/jsp/" />
  <property name="suffix" value=".jsp" />
</bean>

이 설정이라면 sample/list는 /WEB-INF/jsp/sample/list.jsp로 해석된다. JSP 파일을 찾을 때 Controller return 값과 ViewResolver를 같이 봐야 한다.

JSP에서 model 값을 출력한다

Controller가 model에 담은 값은 JSP에서 JSTL이나 EL로 출력한다.

<c:forEach var="item" items="${resultList}">
  <tr>
    <td>${item.id}</td>
    <td>${item.title}</td>
  </tr>
</c:forEach>

화면에 데이터가 나오지 않는다면 SQL 결과, model attribute 이름, JSP의 EL 이름을 순서대로 확인한다. JSP만 보고 데이터가 없다고 판단하면 원인을 놓칠 수 있다.

Tomcat 배포 기준

WAR 배포와 context path

전자정부 표준프레임워크 프로젝트도 전통적인 Spring MVC 웹 프로젝트라면 WAR로 배포하는 경우가 많다. Tomcat에 올릴 때는 WAR 파일명과 context path를 확인해야 한다.

로컬에서는 http://localhost:8080/로 열리던 화면이 운영에서는 /egov 아래에 붙을 수 있다. 이 차이는 context path를 확인하면 빠르게 정리된다.

ROOT.war  ->  /
egov.war  ->  /egov

운영과 로컬 설정 차이

공공 프로젝트에서는 개발, 검증, 운영 환경이 분리되어 있는 경우가 많다. DB URL, 파일 업로드 경로, 로그 경로, 외부 연계 URL이 환경마다 다르다.

로컬에서만 되는 기능은 설정 파일을 먼저 의심한다. 소스 로직이 아니라 properties 값이나 배포 경로가 다른 경우가 많다.

초급 개발자가 자주 헷갈리는 부분

전자정부 전용 코드와 일반 Spring 코드 구분

프로젝트를 보면 Egov로 시작하는 클래스와 일반 Spring 클래스가 섞여 있다. 처음에는 모든 것이 전자정부 전용처럼 보이지만, 실제로는 Spring의 Controller, Service, Bean, MyBatis 흐름이 그대로 쓰인다.

EgovAbstractServiceImpl, EgovAbstractMapper 같은 클래스는 공통 기반 클래스로 보면 된다. 중요한 것은 그 위에서 어떤 메서드를 호출하고 어떤 SQL로 이어지는지다.

생성된 샘플 코드를 그대로 믿지 않기

전자정부 표준프레임워크 예제나 샘플 프로젝트에는 sample이라는 이름이 자주 나온다. 실무 프로젝트에서도 샘플 코드를 복사해 만든 흔적이 남아 있을 수 있다.

sample이라는 이름이 남아 있다고 해서 전부 예제 코드는 아니다. 실제 업무 코드가 샘플 구조를 따라 만들어졌을 수 있으므로 URL, 메뉴, DB 테이블과 연결해 확인해야 한다.

실무에서 바로 쓰는 확인 순서

• URL에서 시작한다. 화면이나 기능을 받으면 먼저 Controller 매핑을 찾는다.
• Controller에서 Service를 따라간다. 어떤 Service 메서드가 호출되는지 확인한다.
• DAO와 Mapper id를 맞춘다. SQL id와 XML namespace가 연결되는지 본다.
• JSP는 ViewResolver 기준으로 찾는다. Controller return 값만 보고 파일 위치를 추측하지 않는다.
• 설정 파일은 역할별로 나누어 본다. web.xml, servlet-context, MyBatis 설정, properties를 구분한다.
• 운영 오류는 환경 차이를 먼저 본다. DB, 파일 경로, context path, 외부 연계 URL이 로컬과 다를 수 있다.

자주 묻는 질문

• Q. 전자정부 표준프레임워크는 Spring과 다른 건가요? A. 완전히 다른 별도 기술이라기보다 Spring 기반 Java 웹 개발 구조에 공공 표준과 공통 컴포넌트가 더해진 형태로 보는 편이 이해하기 쉽습니다.
• Q. 처음 프로젝트를 받으면 어디부터 봐야 하나요? A. URL, Controller, Service, DAO 또는 Mapper, JSP 순서로 요청 흐름을 따라가는 것이 가장 빠릅니다.
• Q. MyBatis Mapper XML은 왜 중요한가요? A. 공공 프로젝트는 SQL 중심 기능이 많아서 실제 조회와 저장 로직이 Mapper XML에 들어 있는 경우가 많습니다.
• Q. *.do URL은 왜 많이 쓰나요? A. web.xml의 DispatcherServlet mapping이 *.do로 잡혀 있는 프로젝트가 많기 때문입니다.
• Q. JSP 파일을 URL로 직접 열 수 없나요? A. WEB-INF 아래 JSP는 직접 접근할 수 없습니다. Controller와 ViewResolver를 통해 렌더링됩니다.
• Q. 운영에서만 안 되는 기능은 어디를 봐야 하나요? A. properties, DB 접속 정보, 파일 경로, context path, 외부 연계 URL처럼 환경별 설정을 먼저 확인합니다.

정리

전자정부 표준프레임워크는 이름 때문에 어렵게 느껴지지만, 실제 실무 흐름은 Spring MVC, MyBatis, JSP, Tomcat 기반 Java 웹 프로젝트를 읽는 방식과 크게 다르지 않다. URL에서 시작해 Controller, Service, DAO, Mapper, JSP 순서로 따라가면 구조가 보인다.

초급 개발자에게 중요한 것은 모든 공통 컴포넌트를 한 번에 외우는 것이 아니다. 내가 수정해야 하는 화면이 어떤 Controller로 들어오고, 어떤 Service와 SQL을 거쳐 어떤 JSP로 나가는지 연결하는 능력이다.

전자정부 표준프레임워크 프로젝트는 프레임워크 이름보다 요청 흐름, 설정 파일, Mapper 연결을 먼저 보면 훨씬 빨리 읽힌다.