2026년판 Struts 면접 질문 및 답변 Top 30

Struts 면접을 준비 중이신가요? 레거시 Struts 1 애플리케이션을 유지보수하든 Struts 2를 사용하든, 이 가이드는 아키텍처, 설정, 검증, 마이그레이션, 고급 패턴을 다루는 30가지 핵심 기술 질문과 10가지 행동/시나리오 질문 및 전략적 모범 답변을 제공합니다.
👉 무료 PDF 다운로드: Struts 면접 질문 및 답변
핵심 프레임워크 지식
1. Struts 아키텍처 및 수명 주기
Struts는 MVC를 구현: ActionServlet(컨트롤러)가 요청을 가로채고, struts-config.xml을 참조하여 Action 클래스(모델 상호작용)에 위임, ActionForward를 JSP(뷰)로 반환.
| 단계 | 설명 |
| 1 | 클라이언트 요청 → ActionServlet |
| 2 | 서블릿이 설정 읽고 Action 위치 파악 |
| 3 | Action이 비즈니스 로직 실행 |
| 4 | ActionForward 반환 |
| 5 | JSP가 응답 렌더링 |
예시: 이커머스 체크아웃: Action이 장바구니 검증, 결제 서비스 호출, 성공/에러 JSP로 포워드.
2. Action 클래스 유형 (Struts 1)
| 유형 | 특성 | 용도 |
| Action | 기본 요청 처리 | 단순 흐름 |
| DispatchAction | 파라미터로 여러 메서드 매핑 | 단일 페이지 CRUD |
| LookupDispatchAction | 키-메서드 맵 (i18n 친화적) | 다국어 UI |
| MappingDispatchAction | 액션 매핑으로 라우팅 | 복잡한 라우팅 |
예시: DispatchAction이 한 클래스에서 add/edit/delete 처리.
3. Struts 1 vs Struts 2: 마이그레이션 트레이드오프
| 측면 | Struts 1 | Struts 2 |
| Action 클래스 | 프레임워크 기반 클래스 확장 | 일반 POJO |
| 데이터 바인딩 | ActionForm 빈 | OGNL로 직접 POJO |
| 확장성 | 제한적 | 인터셉터 기반, 높은 커스터마이징 |
| 마이그레이션 영향 | 없음 | 상당한 리팩토링 |
업그레이드 이점: 보일러플레이트 감소, 현대적 기능. 비용: 설정 변경, 사용 중단된 컴포넌트.
4. Struts 설정 시스템
struts-config.xml (Struts 1) 또는 struts.xml (Struts 2)이 정의: 폼 빈, 액션 매핑, 전역 포워드, 플러그인, 메시지 리소스. Struts 2는 패키지별 모듈식 struts.xml과 어노테이션 지원.
5. Struts 2 인터셉터: 수명 주기 및 역할
모듈식 사전/사후 처리 단위 (검증, 로깅, 인증, 파라미터). 스택이 Action 전 실행, 후 역순 실행. params 인터셉터가 프로퍼티 채움; validation이 정확성 보장. 보일러플레이트 감소, 일관된 횡단 로직.
6. 검증 접근 방식
| 유형 | 장점 | 단점 |
선언적 (validation.xml) | 중앙화, 재사용, 유지보수 용이 | 동적 규칙에 덜 유연 |
| 프로그래밍 방식 (Action/폼) | 높은 커스터마이징 | 클래스 복잡도 증가 |
예시: 이메일 형식은 선언적; DB 체크로 고유 사용자명은 프로그래밍 방식.
7. ActionForm vs POJO 폼 (Struts 2)
Struts 1: 별도 ActionForm이 도메인 모델 중복. Struts 2: OGNL로 직접 POJO 바인딩—더 깔끔, 덜 중복, 테스트 용이.
// Struts 1: UserForm extends ActionForm
// Struts 2: User POJO 직접 사용
8. Struts 2 결과 유형
| 결과 유형 | 목적 |
| dispatcher | JSP로 포워드 (기본값) |
| redirect | 새 요청 사이클 (재제출 방지) |
| redirectAction | 다른 액션으로 리다이렉트 |
| chain | 다른 액션 직접 호출 |
| stream | 바이너리 출력 (파일, 리포트) |
9. ActionServlet / FilterDispatcher 역할
중앙 컨트롤러: 설정 해석, Action 선택, 수명 주기 관리, 로직 호출, 뷰 결정. 없으면 예측 가능한 라우팅이나 MVC 강제 불가.
10. 국제화 (i18n)
로케일별 자동 선택되는 프로퍼티 파일을 메시지 리소스로 사용. 태그: <bean:message> (Struts 1), <s:text> (Struts 2). 특징: 구조화된 리소스, 자동 로케일 감지, 재사용 가능한 키.
예시: "Username" → 로케일 전환으로 "Nombre de usuario".
11. 예외 처리
선언적: 설정에서 <exception>으로 예외 유형을 결과 페이지에 매핑. 프로그래밍 방식: Action에서 try-catch. 선언적 = 일관성; 프로그래밍 방식 = 맥락적 응답 (인증 에러 → 경고 페이지, 시스템 에러 → 유지보수 페이지).
12. Struts 태그 라이브러리
Struts 1: <html:form>, <bean:write>, <logic:iterate>. Struts 2: <s:form>, <s:textfield>, <s:iterator>. 폼 필드 직접 바인딩: <html:text property="username"/>.
13. Struts 2의 OGNL
객체 그래프 네비게이션 언어: 표현식 평가, 요청 파라미터-POJO 바인딩, 깊은 그래프 네비게이션. address.street, address.city가 중첩 객체 자동 채움.
14. RequestProcessor (Struts 1) vs 인터셉터 스택 (Struts 2)
| 특성 | RequestProcessor | 인터셉터 스택 |
| 확장성 | 제한적 (서브클래싱) | 높은 유연성 (설정 가능) |
| 동작 | 단일체 | 모듈식, 분산 |
| 이점 | 단순성 | 관심사 분리 |
15. 파일 업로드 구현
Struts 1: Apache Commons FileUpload. Struts 2: 내장 <s:file> 태그. 고려사항: 크기 제한, MIME 검증, 안전한 저장, 악성 업로드 방지.
16. Struts 2 유연성 기능
인터셉터 아키텍처, POJO 액션, DI 지원 (Spring 플러그인), 커스텀 결과 유형, 플러그인 (JSON, REST, Spring). 예: 전역 인증/로깅 인터셉터로 중복 제거.
17. Struts vs Spring MVC
| 측면 | Struts | Spring MVC |
| 컨트롤러 | 액션 기반 | 어노테이션 기반 |
| 설정 | XML 위주 | 경량 |
| 테스트 | 보통 | 매우 쉬움 |
| 통합 | 제한적 | 전체 Spring 생태계 |
| 적합 대상 | 레거시 유지보수 | 신규 프로젝트 |
18. Tiles 통합
tiles-defs.xml로 템플릿: 레이아웃(헤더, 푸터, 바디) 정의, 액션 포워드에 매핑. 재사용 가능한 레이아웃, 일관된 룩, 쉬운 UI 업데이트.
19. Struts에서의 의존성 주입
Struts 1: 네이티브 DI 없음. Struts 2: struts2-spring-plugin으로 Action에 의존성 주입. OrderService가 OrderAction에 주입 → 더 깔끔, 테스트 가능.
20. Struts 1 → 2 마이그레이션 단계 및 과제
- Action을 POJO로 재작성
- ActionForm을 도메인 객체로 교체
- 검증 재설계 (XML → 어노테이션/인터셉터)
- 설정 업데이트 (
struts-config.xml → struts.xml 패키지)
- JSP 태그 마이그레이션 (Struts 1 → Struts 2 UI 태그)
- OGNL & 인터셉터 모델에 적응
과제: 사용 중단된 기능, 커스텀 RequestProcessor 로직, 폼 바인딩 변경. 보상: 더 깔끔한 아키텍처, 확장성, 낮은 유지보수.
21. 설정 파일 구조 및 유지보수성
Struts 1: 단일 대용량 struts-config.xml → 유지보수 어려움. Struts 2: 패키지/모듈별 모듈식 struts.xml (예: inventory-struts.xml, finance-struts.xml) + 어노테이션.
22. 검증 프레임워크
XML 정의 규칙 (필수, 이메일, 길이) + 자동 JavaScript 생성. 듀얼 클라이언트/서버 검증. 보일러플레이트 감소, 일관성 보장.
23. Struts 2의 ValueStack
요청별 데이터 스택: Action 프로퍼티, 임시 객체, OGNL 접근 가능. 계층 구조로 올바른 값 해결 보장. <s:iterator value="products">가 리스트 직접 조회—뷰와 컨트롤러 분리.
24. 세션 관리: Struts vs 서블릿 API
Struts 1: 세션 스코프 ActionForm. Struts 2: 인터셉터로 세션 맵 주입하는 SessionAware 인터페이스. 타입 안전, 원시 HttpSession보다 덜한 보일러플레이트.
25. 횡단 관심사를 위한 인터셉터 스택
패키지/액션별 구성 가능한 인터셉터 컬렉션. 금융 모듈: 엄격한 스택 (감사, 인증, 암호화). 공개 카탈로그: 경량 스택. 모듈식, 유지보수 용이.
26. ActionErrors & ActionMessages (Struts 1)
여러 에러/성공 메시지 수집; <html:errors>/<html:messages>로 표시. 로직/표현 분리 깔끔.
27. 멀티 모듈 설정
Struts 1: URL 접두사별 별도 설정 (admin, user, reporting). Struts 2: 패키지. 이점: 격리, 병렬 개발, 독립적 배포/테스트.
28. DispatchAction 변형 및 코드 최적화
| 클래스 | 메서드 선택 | 적합 대상 |
| DispatchAction | 요청 파라미터 | CRUD |
| LookupDispatchAction | 리소스 키 → 메서드 맵 | i18n 폼 |
| MappingDispatchAction | 액션 매핑 | 복잡한 라우팅 |
관련 연산을 한 클래스로 통합.
29. 결과 유형 및 네비게이션 유연성
선택 요소: 흐름, 성능, 보안, 콘텐츠 유형. redirect는 재제출 방지; dispatcher는 내부적으로 빠름; stream은 PDF/다운로드용.
30. Struts 2 Action 수명 주기 vs Struts 1
Struts 2: FilterDispatcher → ValueStack 초기화 → 인터셉터 스택 (params, validation 등) → Action 실행 → 인터셉터 사후 처리 → 결과 렌더링. 주요 차이: POJO Action, ActionForm 없음, 인터셉터가 단일체 RequestProcessor 대체.
예시: PurchaseAction: 인증 인터셉터 → 검증 인터셉터 → 로깅 인터셉터 → Action → 결과.
🔍 실전 시나리오 질문 (행동 및 상황 기반)
축약어 없음; 필수 문구 각각 정확히 한 번씩 사용.
1. Struts 프레임워크와 엔터프라이즈 용도 설명.
기대: MVC, 관심사 분리, 엔터프라이즈 이점.
답변: "Struts는 모델-뷰-컨트롤러 아키텍처를 따르는 자바 기반 웹 애플리케이션 프레임워크입니다. 중앙화된 설정, 재사용 가능한 컴포넌트, 명확한 관심사 분리를 제공하기 때문에 엔터프라이즈 애플리케이션에서 사용됩니다. 이러한 기능은 팀이 대규모 애플리케이션을 더 효율적으로 유지보수하는 데 도움이 됩니다."
2. Struts 내의 MVC?
기대: ActionServlet, Action, JSP 역할.
답변: "Struts에서 컨트롤러는 ActionServlet이 관리하며, 사용자 요청을 수신하고 적절한 Action 클래스로 라우팅합니다. 모델은 비즈니스 로직과 데이터 처리를 포함하며, 뷰는 JSP를 사용하여 처리된 정보를 표시합니다. 이 구조는 유지보수성을 향상시키고 결합도를 줄입니다."
3. struts-config.xml의 목적?
기대: 설정 중심 지식.
답변: "struts-config.xml 파일은 폼 빈, 전역 포워드, 액션 매핑, 컨트롤러 설정을 포함한 핵심 애플리케이션 설정을 보관합니다. 개발자가 단일 중앙화된 파일에서 요청 흐름과 컴포넌트 상호작용을 관리할 수 있게 합니다."
4. ActionForm의 역할 및 사용 시기?
기대: 폼 처리, 검증.
답변: "ActionForm은 Action 클래스에 도달하기 전에 사용자 입력을 캡처하고 검증하는 데 사용되는 JavaBean입니다. 애플리케이션이 컨트롤러가 요청을 처리하기 전에 구조화된 폼 데이터와 입력 검증을 필요로 할 때 사용됩니다."
5. Struts 앱에서 해결한 까다로운 이슈?
기대: 기술적 장애물 해결.
답변: "이전 직장에서 struts-config.xml 파일의 잘못된 매핑으로 인해 폼 검증이 올바르게 트리거되지 않는 문제가 발생했습니다. 상세 로깅을 사용하여 문제를 추적하고 매핑을 수정했으며 유사한 문제가 재발하지 않도록 검증 로직을 강화했습니다."
6. 레거시 Struts에서 코드 품질 & 유지보수성 확보?
기대: 구형 프레임워크 모범 사례.
답변: "Action 클래스 모듈화, 중복 로직 제거, 명확한 문서화 추가에 집중합니다. 또한 비즈니스 로직을 검증하기 위해 단위 테스트를 도입합니다. 이러한 관행은 레거시 환경에서 안정성을 개선하고 위험을 줄이는 데 도움이 됩니다."
7. 폼 데이터가 올바르게 제출되지 않을 때 트러블슈팅.
기대: 논리적 디버깅 단계.
답변: "먼저 폼 필드가 ActionForm 프로퍼티 이름과 일치하는지 확인하겠습니다. 그런 다음 struts-config.xml의 액션 매핑을 확인하여 폼 빈이 올바르게 연결되었는지 확인하겠습니다. 필요하다면 디버깅 로그를 활성화하여 요청 파라미터를 추적하고 데이터 흐름이 어디서 끊기는지 식별하겠습니다."
8. 빡빡한 마감일, 여러 Struts 모듈.
기대: 압박 하 우선순위, 조직.
답변: "이전 직장에서 작업을 더 작은 산출물로 나누고 비즈니스 영향에 따라 우선순위를 정하며 이해관계자에게 상태 업데이트를 전달함으로써 이 상황을 처리했습니다. 이 접근 방식은 품질을 저하시키지 않으면서 모든 모듈이 관심을 받도록 보장했습니다."
9. Struts를 Spring MVC로 마이그레이션?
기대: 마이그레이션 전략, 위험 완화.
답변: "먼저 기존 모듈을 평가하여 의존성과 복잡성을 식별하겠습니다. 그런 다음 애플리케이션을 기능적으로 유지하면서 Struts 컨트롤러를 Spring 컴포넌트로 점진적으로 교체하는 단계적 마이그레이션 전략을 설계하겠습니다. 적절한 문서화와 테스트로 원활한 전환을 보장하겠습니다."
10. 교차 기능 협업으로 Struts 앱 개선?
기대: 커뮤니케이션, 팀워크, 조정.
답변: "이전 직장에서 QA, UI 디자이너, 백엔드 개발자와 협력하여 Struts 모듈의 요청 처리를 최적화했습니다. 우리의 조정으로 응답 시간이 개선되고 UI 흐름이 향상되었으며 후속 릴리스에서 결함이 감소했습니다."