한화시스템 BEYOND SW 10주차 회고록

김채우·2025년 11월 24일

이번 주 내용

배운 것 중 가장 중요하다고 생각한 Servlet에 대해 정리하고 이번 주에 끝난 토이 프로젝트에 대해 느낀 점을 작성한다. 그 중 협업을 처음 함에 있어서 가장 부담으로 다가왔던 Git, Github의 사용법에 대해 중점적으로 작성할 것이다.

새롭게 배운 것

Topic: #Servlet

1. Servlet 개요

1.1. 네트워크 통신

1.1.1. Server Client Model

  • 서버는 특정 서비스를 제공하는 컴퓨터
  • 클라이언트는 해당 서비스를 이용하는 사용자

1.1.2. Server 종류

  • Web Server: 웹 브라우저와 HTTP 프로토콜을 사용해 사용자의 요구에 따른 특정 서비스 제공
  • Mail Server: 인터넷을 통해 사용자 간의 전자 우편을 주고 받는 서비스 제공
  • FTP Server: 서버 내에 파일을 업로드, 다운로드 할 수 있는 파일 관리 기능 제공
  • Talnet Server: Terminal, 텍스트로만 이루어진 창에서 특정 명령어 통해 원격지 서버 접속 및 관리
  • Database Server: 데이터 저장, 원격지에 접속할 경우 권한에 따라 해당 데이터를 열람, 추가, 수정, 삭제하는 기능 처리

1.2. Web 통신

1.2.1. Web 통신 구조

Untitled 3.png

1.2.2. Web Server란

사용자에게 HTML 페이지나 이미지들을 HTTP 프로토콜을 통해 웹 브라우저에 제공하는 서버

  • 내부의 내용이 이미 만들어져 있는 정적인 요소들을 화면에 보여주는 역할

1.2.3. 로컬 프로그램과 서버 프로그램의 특징

  • 로컬의 특단점
    1. 프로그램 업데이트 발생 시 각각 다시 다운로드 해야함
    2. 각 프로그램에서 생성된 데이터가 개별 저장되므로 공유 불가
  • 서버 프로그램 특징
    1. 프로그램 업데이트 발생 시 서버가 상관하지 않아도 클라이언트가 서버에서 다운받아 업데이트를 개별적으로 진행
    2. 데이터는 서버에 일괄 저장

1.2.4. Web Server 종류

  • Apache
  • Microsoft IIS
  • NGINX

1.2.5. WAS

Web Application Server

  • 사용자가 요청한 서비스의 결과를 스크립트 언어 등으로 가공해 생성한 동적인 페이지를 사용자에게 보여주는 역할
  • 종류
    - Apache Tomcat
    - Jboss
    - JEUS

1.2.6. Web & WAS

  • 구조: Web Browser <-> Web (html) <-> WAS
  • Web(Html)은 사전에 작성된 화면으로 정적인 페이지를 의미
    - 서버는 따로 두고 일단 클라이언트 요청에 대해 Web에서 응답
    - 처리할 동적 요청 등 필요에 따라 WAS에 요청해 응답
  • WAS는 Servlet을 보관하다가 서블릿 라이프사이클에 따라 생성, 소멸 등을 주관
    - 다른 말로는 Servlet Container

1.3. CGI & WAS

1.3.1. CGI

Common Gateway Interface

  • 웹 서버가 직접적으로 웹 프로그램을 실행하는 것
  • 동일 프로그램에 대한 요청이 있을 때마다 각 프로그램 실행
  • 요청과 프로그램이 1:1 매칭되어 실행

1.3.2. WAS

Web Application Server

  • 웹 서버가 웹 애플리케이션 서버에 요청하면 웹 어플리케이션 서버가 해당 프로그램 실행
  • 동일 프로그램에 여러 요청이 있으면 한 개의 프로그램을 실행해 다수 요청 처리

1.3.3. Container

  • Servlet-Container
    - Servlet의 생명 주기를 관리
    - HttpServletRequest, HttpServletResponse 객체 생성
    - 요청에 따라 멀티스레딩 구성 가능
    - 전송 방식에 따라 동적으로 페이지 구성하는 작업 진행
    - 정적 로딩 처리
  • JSP-Container
    - Servlet화
    - JSp 파일을 JAVA 코드로 변환
    - class팡리로 전환해 메모리 공간에 로드
    - 실행 가능하게 만드는 작업
    - 처리 결과를 HTML 파일로 만들어주는 작업 진행
    - 동적 로딩 처리

2. Servelt LifeCycle

2.1. Servlet 개요

2.1.1. Servlet이란?

  • Server + Applet의 합성어
  • JAVA 언어를 이용해 사용자의 요청을 받아 처리하고 처리 결과를 다시 사용자에게 전송하는 역할의 class 파일
  • 웹에서 동적인 페이지를 java로 구현한 서버측 프로그램

2.1.2. Servlet 설계 규약

  1. 모든 Servlet은 javax.servlet.Servlet interface를 상속받아 구현
  2. Servlet 구현 시 Servlet Interface와 ServletConfig interface를 javax.servlet.GenericServlet에 구현
  3. HTTP 프로토콜을 사용하는 Servelt은 httpServlet Class를 상속받음
    • javax.servlet.http.HttpServlet Class는 javax.servlet.GenericServlet를 상속받은 Class
  4. Servlet의 Exception을 처리하기 위해서는 javax.servlet.ServletException을 상속받아야 함

2.2. Servlet 동작 구조

2.2.1. Servlet Container란?

  • 웹서버 또는 응용 프로그램 서버의 일부
  • 웹 서버에서 온 요청을 받아 Servlet class를 관리하는 역할
    - 생명주기 관리
  • Servlet에 대한 Container 설정은 Deployment Descriptor(web.xml) 파일을 이용

2.3. Deployment Descriptor(DD)

2.3.1. 배포서술자

  • Application에 대한 전체 설정 정보를 가지고 있는 파일
  • xml 파일 형식이며 요소(태그)로 이루어져 있음
  • 파일 내 설정 정보를 가지고 웹 컨테이너가 Servlet을 구동
    - 설정 정보
    - Servlet 정의 및 Servlet 초기화 파라미터
    - Session 설정 파라미터
    - Servlet-jsp mapping 및 MIME type Mapping
    - 보안 설정
    - Welcome file list 설정
    - Error page list, resources, 환경변수
    - 위치
    - webapp > WEB-INF > web.xml

2.4. Servlet Mapping

2.4.1. Servlet Mapping 방법

  • client가 servlet에 접근할 때 원본 클래스명이 아닌 다른 명칭으로 접근 가능
  • 별칭 사용 설정 방법은 web.xml을 이용한 적용과 @annotation으로 두 가지

2.4.2. Servlet Mapping 구조

  • 클라이언트가 서블릿의 url로 요청을 보내면 톰캣이 이를 해석해 매핑된 서블릿으로 연결
  • ![[스크린샷 2025-11-18 오후 6.41.43.png]]
  • mapping 경로가 잘못되면 tomcat 자체가 실행되지 않음
  • 정의되지 않은 경로이거나 중복된 경로를 사용하면 톰캣 서버 실행 오류 발생

2.4.3. web.xml 이용

  • xml 파일로 매핑된 정보를 관리하면 한 눈에 확인과 관리 가능
  • 새로운 서블릿을 추가할 때마다 파일을 이동해 매핑하고 일일이 확인해야 함
  • <servlet>과 <servlet-mapping>은 묶어서 함께 설정
  • 사용법
<servlet>
	<servlet-name>mapping명칭</servlet-name>
	<servlet-class>실제 클래스명</servlet-class>
</servlet>

<servlet-mapping>
	<servlet-name>mapping명칭</servlet-name>
	<url-pattern>사용자 접근명칭</url-pattern>
</servlet-mapping>
  • 사용 예시
<servlet>
    <servlet-name>xmlmapping</servlet-name>
    <servlet-class>com.section01.xml.LifeCycleTestServlet</servlet-class>
    <load-on-startup>100</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>xmlmapping</servlet-name>
    <url-pattern>/xml-lifecycle</url-pattern>
</servlet-mapping>

2.4.4. @annotation 이용

  • 어노테이션이란
    - 사전적 의미로는 주석
    - 실제로 주석처럼 쓰이며 특별한 의미, 기능을 수행하도록 하는 기술
    - 프로그램에 추가 정보를 제공해주는 메타데이터
  • 서블릿을 새로 개발할 때 클래스 바로 윗쪽에 어노테이션만 추가하면 되므로 간편하다는 장점
  • 별도의 문서 등으로 관리하지 않으면 시스템의 모든 서블릿 매핑 정보를 한 눈에 볼 수 없음
  • 사용법
@WebServlet(“/mapping명칭”)
public class Servlet명 extends HttpServlet {
	(Servlet code)
}
  • 사용 예시
@WebServlet(value = "/annotation-lifecycle", loadOnStartup = 1)
public class LifeCycleTestServlet extends HttpServlet {
	(Servlet code)
}

토이 프로젝트

개요

토이 프로젝트는 Java와 DB를 사용해 CRUD를 구현해 보이는 것이었다. 총 3명으로 구성된 우리 팀은 콘솔로 확인할 수 있는 텍스트 기반 게임을 만들었다.

프로젝트 내용

각자의 집에서 우리가 교육을 받는 플레이데이터 건물까지의 여정을 게임으로 표현하였다. 대중교통에서 서 있는 나를 미는 사람, 건물 앞에서 흡연하는 사람, 정말 착하고 좋으신 매니저님, 창문 없는 강의실이 주는 갑갑한 공기, 열정적이시며 매사에 교육생들에게 관심을 가져주시는 강사님이 각 층의 몬스터였다. 플레이어는 몬스터들을 뚫고 훌륭히 해당 교육과정을 수료하는 것이 목표이다.

협업 툴인 Git, Github

Branch

branch는 말 그대로 가지이다. main 혹은 dev에서 뻗어나가게 만들며 서로 영향을 주지 않고 개발하는데 도움을 준다. 만약 나의 가지, 즉 브랜치가 상해서 더 이상 쓸수 없다면 잘라버려 다른 브랜치에 영향을 주지 않도록 할 수도 있다.

git branch // 생성되어 있는 브랜치 목록 확인
git switch branchName // 생성되어 있는 특정 브랜치로 이동
git checkout -b branchName // 생성되어있지 않은 특정 브랜치로 이동
git branch -d branchName // 특정 브랜치 삭제

push

개인이 로컬에서 작업한 내용을 원격 저장소에 공유하는 방법이다. 이 때 원격 저장소의 주소를 origin이라는 키워드에 저장을 해 두면 편리하다. push를 할 때는 main이나 dev 브랜치에 직접적으로 push하지 않도록 각별히 주의해야 한다. main, dev 브랜치는 병합했을 때 오류가 발생하지 않는다는 검증이 된 상태여야 하기 때문이다. 

git push -u origin branchName 
// origin 원격 저장소의 branchName 브랜치에 현재 브랜치를 push한다.

git push origin -d branchName // 원격 저장소에 있는 특정 브랜치를 삭제한다.

pull

원격 저장소의 변경 내용들을 로컬에 반영한다. 

git pull origin 
// 현재 브랜치와 원격 저장소의 이름이 같은 브랜치의 변경사항을 로컬에 적용한다. 
git pull origin branchName 
// 원격 저장소의 branchName 브랜치의 변경사항을 로컬의 현재 브랜치에 적용한다.

느낀점

툴을 사용하며 느낀점

처음 툴을 사용하며 가장 크게 느낀 점은 '정말 효율적이다' 라는 감정이었다. 각각의 branch를 나눠 서로 영향을 최대한 덜 주며 작업하고 그것을 dev 브랜치에 일차적으로 합친다. 이 때 오류가 나면 해결하고 오류가 나지 않는다면 main 브랜치에 병합한다. 이러한 식으로 우리는 각자의 코드에 영향을 덜 주며 독자적으로, 하지만 효율적으로 개발을 진행할 수 있었다. 특히 issue를 생성하고 그에 따라 commit 메시지를 작성하는 것은 각자의 branch에서 어떤 작업들을 했는지 추적하는 것을 편리하게 해 주어 코드 리뷰에도 속도가 붙었다.

Keep

매주 하는 스터디에 열심히 참여하고 있다. 오늘(11월 24일)에는 내가 발표자로 뽑혀 공부하고 있는 Spring 레거시 중 예외 처리에 대해 발표하였다. 발표와 질의응답을 하면 확실히 내가 잘못 알고 있던 내용들을 바로잡게 되고 애매하던 부분을 정확히 알 수 있다. 특히 말로 발표하는 것이 머리속에서 한 번 더 정리되는 느낌이 들어 정말 많은 도움이 된다.

Problem

마지막까지 토이 프로젝트에 매달려 있는 것이 힘들었다. 사람들이 보는 부분은 콘솔이지만 내부의 코드가 마음에 안 들고 비효율적이라 그것을 리팩토링 하는 데 마지막까지 시간이 꽤나 걸렸었다. 다음부터는 설계 단계에서부터 최대한 시간과 노력을 쏟아 이후를 편안하게 만들어야 할 것으로 생각된다.

Try

이번주는 사이드 프로젝트의 본격적인 시작 주간이다. 다음주까지 엔티티를 구현해야 하는데 일차적으로 생각하지 말고 토이 프로젝트에서 느꼈던 것처럼 내가 지금 구현하는 엔티티를 어떻게, 누가, 왜 사용하는지를 생각하면 이후에 더 편안하고 좋은 결과물이 나오지 않을까 생각한다. 힘들다고 대충 하지 말고 지금 당장 이 시간에 최선을 다하자.

profile
김채우
예비 백엔드 개발자
이전 포스트

한화시스템 BEYOND SW 7주차 회고록

0개의 댓글