Intro

이 글은 스프링 요소의 대략적인 개념에 대해서 정리한 글입니다.


1. 빌드와 배포

  • 빌드: 라이브러리와 개발 코드를 통합하여 실행 가능한 형태로 만드는 과정.
  • 배포: 빌드된 파일을 실제 서버에 올려 실행하는 과정.
  • 클래스 패스(classpath)를 통해 라이브러리가 코드에 적용되도록 설정.
  • 잭슨(Jackson) 같은 라이브러리 예시:
    • 의존성을 명시하면 빌드 툴이 자동으로 의존성을 가져와 적용.
  • 빌드 툴은 의존성과 호환성을 자동으로 관리.

2. 아카이브 형식

  • WAR (Web Application Archive): 웹 애플리케이션용 배포 형식.
  • JAR (Java Archive): 자바 애플리케이션용 배포 형식.
  • 스프링 레거시: WAR 형식 사용.
  • 스프링 부트: JAR 형식 사용.
    • 스프링 부트는 자체적으로 실행 가능한 내장 웹 서버를 포함하므로 WAR 필요 없음.

3. 스프링 프로젝트 디렉토리 구조 (Maven 기준)

  • src/main/resources: 자바 관련 설정 파일 저장.
  • webapp/resources: 웹 관련 설정 파일 저장.
  • 빌드 시: 두 영역의 정보가 통합되어 패키징.

예시

  • src/test/java: 테스트 코드를 작성하는 위치.
  • target 폴더: Maven 빌드 결과물이 생성되는 위치 (e.g., WAR 파일).

4. 테스트와 자동화

  • JUnit: 유닛 테스트 프레임워크.
    • 기존에는 수동으로 테스트를 진행했지만, JUnit을 통해 원하는 흐름과 지점을 지정하여 자동화된 테스트 가능.
  • DAO 테스트: 데이터 접근 계층의 메서드 테스트를 JUnit으로 간편하게 진행.

5. 스프링 설정과 관리 방식

  • 초기 스프링:
    • 설정 파일(XML) 중심으로 모든 코드를 중앙에서 관리.
    • XML 이해는 스프링 전반의 이해에 중요.
  • 이후 스프링(3.0~):
    • 어노테이션 기반 설정 도입 (XML과 동등한 역할).
    • 코드 내에서 설정을 분산 관리 가능.
  • 스프링은 중앙집권적 방식에서 지방분권적 방식으로 발전.

6. 스프링 레거시 vs 스프링 부트

  • 스프링 레거시:
    • WAR 형식으로 배포.
    • JSP와 JSTL 사용.
    • 설정 복잡 (e.g., 메서드 접근 제어자까지 설정 가능).
    • 서블릿 주소 등 세부 사항 설계자가 직접 설정.
  • 스프링 부트:
    • JAR 형식으로 배포.
    • JSP 대신 Thymeleaf 사용.
    • 내장 서버 포함 (Tomcat 등).
    • 간소화된 설정.

7. 스프링 버전의 변화

  • 3.x: 어노테이션 기반 설정 본격 도입.
  • 4.x: 스프링 부트와 호환 시작.
  • 5.x: 클라우드 환경 지원.
  • 현업에서 주로 사용하는 버전: 스프링 부트 3.0.

8. 빌드 도구

  • Maven:
    • 프로젝트 의존성 관리 (pom.xml).
    • 기존의 수동 라이브러리 관리 필요 없음.
  • Gradle:
    • Maven보다 간결한 의존성 설정.
  • YAML:
    • 설정 파일 형식으로 간단하고 가독성이 좋음.

9. 프레임워크의 특징

  • 스프링은 모듈 단위로 기능을 조합하여 프로그램을 생성 (e.g., JAR, 라이브러리).
  • 일반 자바 웹 프로젝트에 스프링 라이브러리를 추가하면 스프링 프로젝트로 전환 가능.
  • 프로젝트 내 주요 설정 파일:
    • web.xml: 웹 애플리케이션 설정 파일.
    • root-context.xml: 다수의 스프링 프로젝트를 한 서버에 구동할 때 공통 설정 저장.
    • servlet-context.xml: 개별 프로젝트에 대한 설정 저장.

태그:

카테고리:

업데이트:

댓글남기기