메밀이의 공부일기

[26.07.06-26.07.09] TIL 15주차 정리

buckwheat — Mon, 13 Jul 2026 14:10:51 +0900

https://buckwheat0.tistory.com/76

[2026.07.06] - TIL 66일차 (Spring Boot 게시판 보완과 Thymeleaf 시작)

기존 StartBoot02 게시판 프로젝트를 보완하고, StartBoot03에서 Thymeleaf 기본 문법을 학습했다.기존 JSP 기반 흐름에서 Spring Boot 방식의 설정, 필터, 인터셉터, MyBatis Mapper 구조를 조금 더 정리했고, 이후

buckwheat0.tistory.com

https://buckwheat0.tistory.com/77

[2026.07.07] - TIL 67일차 (JSP 게시판을 Thymeleaf로 전환하기)

StartBoot02_Thymeleaf 프로젝트에서 기존 JSP 게시판 화면을 Thymeleaf 템플릿으로 바꾸는 작업을 했다.기존 Controller, Biz, Dao, Mapper 구조는 유지하고, View 영역만 JSP에서 Thymeleaf HTML로 전환하는 흐름이었다

buckwheat0.tistory.com

https://buckwheat0.tistory.com/78

[2026.07.08] - TIL 68일차 (Spring Data JPA로 게시판 CRUD 구현하기)

오늘은 StartBoot04 프로젝트에서 Spring Data JPA를 사용해 기존 게시판 흐름을 다시 구현했다.이전에는 MyBatis Mapper에 SQL을 직접 작성했다면, 오늘은 Entity와 Repository를 중심으로 DB 작업을 처리했다.1. J

buckwheat0.tistory.com

https://buckwheat0.tistory.com/79

[2026.07.09] - TIL 69일차 (Spring Security와 로그인 구현)

1. Spring Security 의존성 추가Spring Boot 프로젝트에 로그인과 접근 권한 기능을 적용하기 위해 Spring Security 의존성을 추가했다. org.springframework.boot spring-boot-starter-security org.thymeleaf.extras thymeleaf-extras-s

buckwheat0.tistory.com

[2026.07.09] - TIL 69일차 (Spring Security와 로그인 구현)

buckwheat — Thu, 9 Jul 2026 17:58:42 +0900

1. Spring Security 의존성 추가

Spring Boot 프로젝트에 로그인과 접근 권한 기능을 적용하기 위해 Spring Security 의존성을 추가했다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

<dependency>
    <groupId>org.thymeleaf.extras</groupId>
    <artifactId>thymeleaf-extras-springsecurity5</artifactId>
</dependency>

spring-boot-starter-security는 인증과 권한 처리를 담당한다.

thymeleaf-extras-springsecurity5는 Thymeleaf 화면에서 로그인 정보와 권한을 사용할 수 있게 해준다.

2. 게시판 Entity와 JPA

게시글 정보를 저장하기 위해 BoardEntity를 작성했다.

@Entity
@Table(name = "board")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class BoardEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;

    @Column(nullable = false, length = 50)
    private String write;

    @Column(nullable = false, length = 100)
    private String title;

    @Column(length = 4000)
    private String content;

    @Column(updatable = false)
    private LocalDate createAt;

    @PrePersist
    public void onPrePersist() {
        this.createAt = LocalDate.now();
    }
}

@Entity: JPA가 관리하는 Entity로 등록
@Table: 연결할 테이블 이름 지정
@Id: 기본키 지정
@GeneratedValue: 기본키 자동 생성
@PrePersist: INSERT 직전에 실행
Lombok: 생성자와 getter, setter 코드 자동 생성

3. Repository와 Service

Repository는 JpaRepository를 상속받아 기본 CRUD 기능을 사용한다.

public interface BoardRepository
        extends JpaRepository<BoardEntity, Integer> {

    List<BoardEntity> findAllByOrderByIdDesc();
}

메서드 이름을 분석해 게시글을 ID 내림차순으로 조회하는 SQL을 자동 생성한다.

Service에서는 Repository를 이용해 게시글 조회와 저장을 처리했다.

@Override
public List<BoardEntity> findAll() {
    return repository.findAllByOrderByIdDesc();
}

@Override
public BoardEntity save(BoardEntity dto) {
    return repository.save(dto);
}

4. 게시글 목록, 등록, 상세 조회

Controller에서 게시글 목록, 등록 화면, 저장, 상세 조회 요청을 처리했다.

@GetMapping("/list")
public String selectList(Model model) {
    model.addAttribute("list", service.findAll());
    return "board/list";
}

@GetMapping("/insert")
public String insertForm() {
    return "board/insert";
}

@PostMapping("/insert")
public String insert(BoardEntity dto) {
    service.save(dto);
    return "redirect:/board/list";
}

@GetMapping("/detail")
public String selectOne(Model model, int id) {
    model.addAttribute("dto", service.findById(id));
    return "board/detail";
}

@GetMapping: 화면 조회 요청
@PostMapping: 입력 데이터를 서버에 전달하는 요청
Model: Controller에서 조회한 데이터를 Thymeleaf로 전달
redirect:: 작업 완료 후 새로운 주소로 다시 요청

5. 회원 Entity와 회원가입

회원 정보를 저장하기 위해 MemberEntity를 작성했다.

@Entity
@Table(name = "member")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class MemberEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;

    @Column(nullable = false, length = 50, unique = true)
    private String username;

    @Column(nullable = false, length = 100)
    private String password;

    @Column(nullable = false, length = 50)
    private String name;
}

username에는 unique = true를 지정해 같은 아이디가 중복 저장되지 않도록 했다.

6. BCrypt 비밀번호 암호화

비밀번호를 평문으로 저장하지 않도록 BCryptPasswordEncoder를 Bean으로 등록했다.

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

회원가입 시 입력받은 비밀번호를 암호화한 뒤 DB에 저장한다.

@Override
public MemberEntity save(MemberEntity dto) {
    dto.setPassword(passwordEncoder.encode(dto.getPassword()));
    return repository.save(dto);
}

BCrypt로 암호화된 비밀번호는 약 60자의 문자열로 저장된다.

7. UserDetailsService

Spring Security는 로그인 요청이 들어오면 loadUserByUsername()을 호출해 사용자를 조회한다.

@Override
public UserDetails loadUserByUsername(String username)
        throws UsernameNotFoundException {

    MemberEntity member = repository.findByUsername(username)
        .orElseThrow(() ->
            new UsernameNotFoundException("사용자를 찾을 수 없습니다."));

    return User.builder()
        .username(member.getUsername())
        .password(member.getPassword())
        .roles("USER")
        .build();
}

DB에서 조회한 MemberEntity를 Spring Security가 사용하는 UserDetails 형태로 변환한다.

8. SecurityFilterChain

SecurityFilterChain에서 URL별 접근 권한과 로그인 방식을 설정했다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http)
        throws Exception {

    http.csrf(csrf -> csrf.disable())
        .authorizeHttpRequests(auth -> auth
            .antMatchers(
                "/",
                "/member/register",
                "/member/login",
                "/css/**",
                "/js/**",
                "/images/**"
            ).permitAll()
            .antMatchers("/board/**").authenticated()
            .anyRequest().permitAll())
        .formLogin(form -> form
            .loginPage("/member/login")
            .loginProcessingUrl("/member/login")
            .defaultSuccessUrl("/board/list", true)
            .failureUrl("/member/login?error=true")
            .permitAll())
        .logout(logout -> logout
            .logoutUrl("/member/logout")
            .logoutSuccessUrl("/")
            .permitAll());

    return http.build();
}

permitAll(): 로그인하지 않아도 접근 가능
authenticated(): 로그인한 사용자만 접근 가능
loginPage(): 로그인 화면 주소
loginProcessingUrl(): Spring Security가 처리할 로그인 요청 주소
defaultSuccessUrl(): 로그인 성공 후 이동할 주소
failureUrl(): 로그인 실패 후 이동할 주소

9. 로그인 처리 흐름

로그인 폼 제출
→ Spring Security Filter
→ loadUserByUsername() 호출
→ DB에서 회원 조회
→ BCrypt 비밀번호 비교
→ 인증 성공
→ /board/list 이동

Spring Security가 POST /member/login 요청을 처리하기 때문에 Controller에서 아이디와 비밀번호를 직접 비교하지 않아도 된다.

Controller는 로그인 화면을 반환하는 GET 요청만 처리한다.

@GetMapping("/login")
public String loginForm() {
    return "member/login";
}

10. ddl-auto 설정

수업에서는 서버 실행 시 테이블을 새로 생성하기 위해 다음 설정을 사용했다.

spring.jpa.hibernate.ddl-auto=create

create는 서버를 실행할 때 기존 테이블을 삭제하고 다시 생성한다. 이 때문에 서버를 재시작하면 회원과 게시글 데이터가 사라질 수 있다.

실습 중 데이터를 유지하기 위해 다음과 같이 변경했다.

spring.jpa.hibernate.ddl-auto=update

update는 기존 데이터를 유지하면서 Entity 변경 사항을 테이블에 반영한다.

정리

오늘은 Spring Data JPA로 게시판과 회원 테이블을 구성하고, Spring Security를 이용해 회원가입과 로그인 기능을 구현했다.

비밀번호는 BCrypt로 암호화했으며, UserDetailsService로 DB 회원을 조회했다. 또한 로그인하지 않은 사용자는 /board/**에 접근할 수 없도록 URL 권한을 설정했다.

[2026.07.08] - TIL 68일차 (Spring Data JPA로 게시판 CRUD 구현하기)

buckwheat — Wed, 8 Jul 2026 17:27:38 +0900

오늘은 StartBoot04 프로젝트에서 Spring Data JPA를 사용해 기존 게시판 흐름을 다시 구현했다.
이전에는 MyBatis Mapper에 SQL을 직접 작성했다면, 오늘은 Entity와 Repository를 중심으로 DB 작업을 처리했다.

1. JPA 프로젝트 설정

JPA를 사용하려면 DB 연결 정보와 Hibernate 설정이 필요하다.

spring.datasource.driver-class-name=oracle.jdbc.OracleDriver
spring.datasource.url=jdbc:oracle:thin:@localhost:1521/XEPDB1
spring.datasource.username=multi
spring.datasource.password=multi

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.Oracle12cDialect
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

ddl-auto=validate는 Entity와 DB 테이블 구조가 맞는지 검사한다.
테이블이나 시퀀스가 맞지 않으면 서버 시작 단계에서 에러가 난다.

2. Entity 클래스

JPA에서는 DB 테이블과 연결되는 Java 객체를 Entity라고 한다.

@Entity
@Table(name="MYBOARD")
public class JpaEntity {

    @Id
    @SequenceGenerator(name="my_seq", sequenceName="SEQ_MY", allocationSize=1)
    @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="my_seq")
    @Column
    private int myno;

    @Column(updatable=false, nullable=false)
    private String myname;

    @Column
    private String mytitle;

    @Column
    private String mycontent;

    @Column(updatable=false, nullable=false)
    private Date mydate;
}

핵심은 @Entity, @Table, @Id다.

@Entity
- 이 클래스가 JPA가 관리하는 DB 객체라는 뜻

@Table
- 실제 DB 테이블 이름 지정

@Id
- 기본키 필드 지정

기존 DB에서는 SEQ_MY 시퀀스를 사용하고 있었기 때문에 @SequenceGenerator로 JPA가 이 시퀀스를 사용하게 설정했다.

3. Repository와 JpaRepository

JPA에서는 DAO 역할을 Repository 인터페이스로 만들 수 있다.

@Repository
public interface JpaDao extends JpaRepository<JpaEntity, Integer> {

    public JpaEntity findByMyno(int myno);

    //JPQL
    @Query("DELETE FROM JpaEntity J WHERE J.myno = :myno")
    @Modifying
    @Transactional
    public void delBoard(@Param("myno") int myno);
}

JpaRepository<JpaEntity, Integer>는 이렇게 해석할 수 있다.

JpaEntity : 이 Repository가 관리할 Entity
Integer   : Entity의 기본키 타입

JpaRepository를 상속하면 기본 CRUD 메서드를 바로 사용할 수 있다.

dao.findAll();
dao.save(dto);
dao.deleteById(myno);

4. findBy 메서드 규칙

Spring Data JPA는 메서드 이름을 보고 쿼리를 자동으로 만들어준다.

public JpaEntity findByMyno(int myno);

이 코드는 myno 필드로 데이터를 조회한다는 뜻이다.

findBy필드명
= 해당 필드 조건으로 조회

중요한 점은 DB 컬럼명이 아니라 Entity 필드명을 기준으로 작성한다는 것이다.

5. JPQL에서 주의할 점

JPQL은 SQL과 비슷해 보이지만 기준이 다르다.

@Query("DELETE FROM JpaEntity J WHERE J.myno = :myno")

SQL이라면 테이블명과 컬럼명을 사용한다.

DELETE FROM MYBOARD WHERE MYNO = ?

하지만 JPQL은 Entity명과 필드명을 사용한다.

MYBOARD X  -> JpaEntity O
MYNO    X  -> myno O

그래서 J.MYNO처럼 쓰면 에러가 난다.
JpaEntity 클래스 안에는 MYNO가 아니라 myno 필드가 있기 때문이다.

6. Controller CRUD 흐름

목록 조회는 findAll()을 사용했다.

@GetMapping("/list")
public String selectAll(Model model) {
    List<JpaEntity> list = dao.findAll(Sort.by(Sort.Direction.DESC, "myno"));
    model.addAttribute("list", list);
    return "jpalist";
}

상세 조회는 findByMyno()를 사용했다.

@GetMapping("/detail")
public String selectOne(Model model, int myno) {
    JpaEntity dto = dao.findByMyno(myno);
    model.addAttribute("dto", dto);
    return "jpadetail";
}

등록은 save()를 사용했다.

@PostMapping("/insert")
public String insert(JpaEntity dto) {
    dto.setMydate(new Date(System.currentTimeMillis()));
    dao.save(dto);
    return "redirect:/board/list";
}

mydate는 form에서 입력받지 않기 때문에 Controller에서 직접 현재 날짜를 넣어주었다.

7. save()의 insert/update 판단

JPA의 save()는 insert와 update를 모두 처리할 수 있다.

dao.save(dto);

기준은 기본키다.

id가 없거나 DB에 없는 값이면 insert
id가 있고 DB에 같은 데이터가 있으면 update

수정에서는 기존 데이터를 다시 조회한 뒤 제목과 내용만 바꿔 저장했다.

@PostMapping("/update")
public String update(JpaEntity dto) {
    JpaEntity Dto = dao.findByMyno(dto.getMyno());
    Dto.setMytitle(dto.getMytitle());
    Dto.setMycontent(dto.getMycontent());
    dao.save(Dto);

    return "redirect:/board/detail?myno=" + dto.getMyno();
}

이렇게 하면 form에서 넘어오지 않은 myname, mydate 값이 유지된다.

8. Thymeleaf 화면 처리

목록 화면에서는 th:each로 데이터를 반복 출력했다.

<tr th:each="dto : ${list}">
    <td th:text="${dto.myno}">myno</td>
    <td th:text="${dto.myname}">myname</td>
    <td>
        <a th:href="@{/board/detail(myno=${dto.myno})}" th:text="${dto.mytitle}">
            mytitle
        </a>
    </td>
    <td th:text="${dto.mydate}">mydate</td>
</tr>

상세, 수정 화면에서는 th:object와 *{} 문법을 사용했다.

<form action="/board/update" method="post" th:object="${dto}">
    <input type="hidden" name="myno" th:value="*{myno}">
    <input type="text" name="mytitle" th:value="*{mytitle}">
    <textarea name="mycontent" th:text="*{mycontent}"></textarea>
</form>

th:object="${dto}"를 지정하면 내부에서 *{mytitle}처럼 간단히 접근할 수 있다.

9. 개인적으로 추가해본 삭제 알림

수업 핵심 내용은 아니지만, 삭제 후 알림을 띄우는 기능도 추가해봤다.

Controller에서 삭제 후 메시지 파라미터를 붙여 redirect했다.

@GetMapping("/delete")
public String delete(int myno) {
    dao.delBoard(myno);
    return "redirect:/board/list?msg=delete";
}

목록 페이지에서는 msg=delete가 있으면 alert를 띄운다.

<script th:if="${param.msg != null and param.msg[0] == 'delete'}">
    alert("삭제 완료!");
</script>

Controller는 브라우저 alert를 직접 띄울 수 없기 때문에, 메시지를 URL로 넘기고 View에서 JavaScript로 처리했다.

정리

오늘은 Spring Data JPA로 게시판 CRUD 흐름을 구현했다.

핵심은 다음과 같다.

Entity
- DB 테이블과 연결되는 Java 객체

JpaRepository
- 기본 CRUD 메서드를 제공하는 Repository

findBy필드명
- 메서드 이름으로 조건 조회 쿼리 생성

JPQL
- 테이블/컬럼명이 아니라 Entity/필드명을 사용

save()
- 기본키 상태에 따라 insert 또는 update 처리

Thymeleaf
- Entity 데이터를 화면에 출력하고 form으로 다시 전달

MyBatis는 SQL을 직접 작성하는 느낌이 강했고, JPA는 객체와 메서드 이름을 중심으로 DB 작업을 처리한다는 점이 가장 큰 차이였다.

[2026.07.07] - TIL 67일차 (JSP 게시판을 Thymeleaf로 전환하기)

buckwheat — Tue, 7 Jul 2026 17:37:53 +0900

StartBoot02_Thymeleaf 프로젝트에서 기존 JSP 게시판 화면을 Thymeleaf 템플릿으로 바꾸는 작업을 했다.
기존 Controller, Biz, Dao, Mapper 구조는 유지하고, View 영역만 JSP에서 Thymeleaf HTML로 전환하는 흐름이었다.

1. JSP와 Thymeleaf의 차이

JSP에서는 데이터를 출력할 때 ${}를 HTML 안에 직접 작성했다.

${dto.mytitle}

Thymeleaf에서는 HTML 태그의 th:* 속성을 사용한다.

<td th:text="${dto.mytitle}">제목</td>

Thymeleaf의 장점은 HTML 파일 자체가 브라우저에서도 어느 정도 자연스럽게 보인다는 점이다.
제목 같은 기본 텍스트를 넣어두면 서버 없이 열었을 때도 화면 구조를 확인할 수 있다.

2. Thymeleaf 기본 선언

Thymeleaf 문법을 사용하려면 HTML 태그에 네임스페이스를 선언한다.

<html xmlns:th="http://www.thymeleaf.org">

이 선언을 해야 th:text, th:href, th:action, th:onclick 같은 Thymeleaf 속성을 명확하게 사용할 수 있다.

3. 목록 페이지 구현

게시글 목록은 Controller에서 list라는 이름으로 전달된다.

model.addAttribute("list", biz.selectList());
return "myboardlist";

Thymeleaf에서는 th:each로 목록을 반복 출력한다.

<tr th:each="dto : ${list}">
    <td th:text="${dto.myno}">번호</td>
    <td th:text="${dto.myname}">작성자</td>
    <td>
        <a th:text="${dto.mytitle}" th:href="@{/myboard/detail(myno=${dto.myno})}">
            제목
        </a>
    </td>
    <td th:text="${dto.mydate}">날짜</td>
</tr>

여기서 ${list}는 Model에 담긴 게시글 목록이고, dto는 반복 중인 게시글 하나를 의미한다.

4. `${}`와 `@{}` 차이

Thymeleaf에서 자주 쓰는 표현식은 ${}와 @{}이다.

${} : Model에 담긴 데이터 꺼내기
@{} : URL 만들기

예를 들어:

<td th:text="${dto.myname}">작성자</td>

이 코드는 dto 객체의 myname 값을 화면에 출력한다.

반면:

<a th:href="@{/myboard/detail(myno=${dto.myno})}">상세</a>

이 코드는 다음과 같은 URL을 만든다.

/myboard/detail?myno=1

즉, $는 데이터, @는 주소라고 생각하면 이해하기 쉽다.

5. 상세 페이지 구현

상세 페이지에서는 Controller에서 dto 하나만 전달한다.

model.addAttribute("dto", biz.selectOne(myno));
return "myboarddetail";

따라서 반복문 없이 ${dto.필드명}으로 출력하면 된다.

<td th:text="${dto.myno}">번호</td>
<td th:text="${dto.myname}">작성자</td>
<td th:text="${dto.mytitle}">제목</td>
<td>
    <textarea rows="10" cols="40" readonly="readonly" th:text="${dto.mycontent}">
        내용
    </textarea>
</td>

수정, 삭제 버튼은 해당 글 번호를 URL에 붙여 이동한다.

<input type="button" value="수정"
    th:onclick="|location.href='@{/myboard/updateform(myno=${dto.myno})}'|">

<input type="button" value="삭제"
    th:onclick="|location.href='@{/myboard/delete(myno=${dto.myno})}'|">

6. 등록 페이지 구현

등록 페이지는 새 글을 입력하는 화면이므로 기존 데이터가 필요 없다.

<form th:action="@{/myboard/insert}" method="post">
    <table border="1">
        <tr>
            <th>작성자</th>
            <td><input type="text" name="myname"></td>
        </tr>
        <tr>
            <th>제목</th>
            <td><input type="text" name="mytitle"></td>
        </tr>
        <tr>
            <th>내용</th>
            <td><textarea rows="10" cols="40" name="mycontent"></textarea></td>
        </tr>
    </table>
</form>

name 값은 DTO 필드명과 맞춰야 한다.

name="myname"    -> dto.setMyname()
name="mytitle"   -> dto.setMytitle()
name="mycontent" -> dto.setMycontent()

7. 수정 페이지 구현

수정 페이지는 기존 글 정보를 화면에 먼저 출력한 뒤, 사용자가 제목과 내용을 바꿀 수 있게 한다.

<form th:action="@{/myboard/update}" method="post">
    <input type="hidden" name="myno" th:value="${dto.myno}">

    <input type="text" name="mytitle" th:value="${dto.mytitle}">
    <textarea name="mycontent" th:text="${dto.mycontent}">내용</textarea>
</form>

수정 요청을 보낼 때는 어떤 글을 수정할지 알아야 하므로 myno를 hidden input으로 함께 보낸다.

<input type="hidden" name="myno" th:value="${dto.myno}">

8. JavaScript에서 Thymeleaf 값 사용

상세 페이지에서 버튼 클릭 시 alert를 띄우는 예제도 다뤘다.

<input type="button" value="확인" onclick="test();">

<script type="text/javascript" th:inline="javascript">
    function test(){
        let myno = [[${dto.myno}]];
        let myname = [[${dto.myname}]];
        alert(myno + myname);
    }
</script>

JavaScript 안에서 Thymeleaf 값을 사용할 때는 th:inline="javascript"를 추가하고, [[...]] 문법을 사용한다.

실수했던 부분도 있었다.

onlcick="test();"

이렇게 쓰면 오타 때문에 클릭 이벤트가 실행되지 않는다.
정확히는 아래처럼 써야 한다.

onclick="test();"

정리

오늘은 기존 JSP 게시판 화면을 Thymeleaf 템플릿으로 바꾸면서 View 영역의 문법을 집중적으로 학습했다.

핵심은 다음과 같다.

th:text
- 태그 안의 텍스트를 서버 데이터로 바꿈

th:each
- 리스트 반복 출력

th:href
- 링크 URL 생성

th:action
- form 요청 URL 생성

th:onclick
- 버튼 클릭 시 이동 경로 생성

${}
- Model 데이터 출력

@{}
- URL 생성

[[...]]
- JavaScript 안에서 Thymeleaf 값 사용

JSP에서 하던 게시판 화면 처리를 Thymeleaf 방식으로 바꾸면서, Spring Boot에서는 HTML 템플릿을 더 자연스럽게 사용할 수 있다는 점을 확인했다.

[2026.07.06] - TIL 66일차 (Spring Boot 게시판 보완과 Thymeleaf 시작)

buckwheat — Tue, 7 Jul 2026 17:35:29 +0900

기존 StartBoot02 게시판 프로젝트를 보완하고, StartBoot03에서 Thymeleaf 기본 문법을 학습했다.
기존 JSP 기반 흐름에서 Spring Boot 방식의 설정, 필터, 인터셉터, MyBatis Mapper 구조를 조금 더 정리했고, 이후 Thymeleaf 템플릿 사용법으로 넘어갔다.

1. StartBoot02 게시판 구조 보완

StartBoot02는 Spring Boot에서 Oracle DB와 MyBatis를 사용해 게시판 CRUD를 구현한 프로젝트다.

전체 흐름은 다음과 같다.

Controller
 -> Biz
 -> Dao
 -> Mapper
 -> DB

기존에는 DAO 안에 SQL이 직접 들어가 있었는데, SQL을 Mapper로 분리했다.

@Mapper
public interface MyBoardMapper {

    @Select(" SELECT * FROM MYBOARD ORDER BY MYNO DESC ")
    List<MyDto> selectList();

    @Select(" SELECT * FROM MYBOARD WHERE MYNO = #{myno} ")
    MyDto selectOne(@Param("myno") int myno);
}

이렇게 하면 DAO는 SQL을 직접 갖지 않고 Mapper를 호출하는 역할만 하게 된다.

@Repository
public class MyDaoImpl implements MyDao {

    @Autowired
    private MyBoardMapper mapper;

    @Override
    public List<MyDto> selectList() {
        return mapper.selectList();
    }
}

즉, SQL 관리는 Mapper에서 하고, DAO는 데이터 접근 흐름만 담당하게 되어 구조가 더 깔끔해진다.

2. Filter 설정

Spring Boot에서는 web.xml 대신 Java 설정 클래스로 필터를 등록할 수 있다.

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<Filter> checkFilter(){
        FilterRegistrationBean<Filter> regiBean = new FilterRegistrationBean<Filter>();

        regiBean.setFilter(new Filter() {
            @Override
            public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
                    throws IOException, ServletException {
                System.out.println("필터 실행!");
                chain.doFilter(request, response);
            }
        });

        regiBean.addUrlPatterns("/myboard/*");
        regiBean.setOrder(1);
        return regiBean;
    }
}

필터는 Controller에 도착하기 전에 먼저 실행된다.
공통 로그 출력, 인코딩 처리, 보안 검사 같은 작업에 사용할 수 있다.

3. Interceptor 설정

Interceptor는 Spring MVC 내부에서 Controller 실행 전후에 동작한다.

public class CheckInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        System.out.println("인터셉터 - 요청 uri: " + request.getRequestURI());
        return true;
    }
}

preHandle()에서 true를 반환하면 Controller가 계속 실행되고, false를 반환하면 Controller로 가지 않는다.

Interceptor는 WebMvcConfigurer를 통해 등록한다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new CheckInterceptor())
                .addPathPatterns("/myboard/*")
                .excludePathPatterns("/myboard/test");
    }
}

Filter와 Interceptor의 차이는 다음처럼 정리할 수 있다.

Filter      : Spring MVC 바깥에서 먼저 동작
Interceptor : Controller 실행 전후에 동작

4. StartBoot03과 Thymeleaf 시작

StartBoot03에서는 Thymeleaf 템플릿 엔진을 학습했다.

Thymeleaf는 HTML 안에 th:* 속성을 사용해서 서버에서 전달받은 데이터를 출력하는 템플릿 엔진이다.

<html xmlns:th="http://www.thymeleaf.org">

Controller에서 Model에 값을 담으면:

model.addAttribute("name", "Thymeleaf!!");

HTML에서는 ${}로 값을 꺼낼 수 있다.

<h1 th:text="${name}">기본 텍스트</h1>

실제 응답에서는 기본 텍스트가 아니라 Model에 담긴 값이 출력된다.

5. Thymeleaf 유틸리티 객체

Thymeleaf에는 날짜, 숫자, 문자열 등을 처리하는 내장 유틸리티 객체가 있다.

<p th:text="${#calendars.format(#calendars.createNow(), 'yyyy-MM-dd HH:mm')}">
    #date object
</p>

숫자 포맷도 가능하다.

<p th:text="${#numbers.formatInteger(345.1234, 5)}">
    #numbers object
</p>

문자열 처리도 지원한다.

<p th:text="${#strings.toUpperCase('hello,spring boot and thymeleaf')}">
    #strings object
</p>

6. Thymeleaf 조건문과 반복문

조건문은 th:if, th:unless를 사용한다.

<p th:if="*{seq gt 30}">
    <span>seq가 30보다 크다</span>
</p>
<p th:unless="*{seq gt 30}">
    <span>seq가 30보다 작다</span>
</p>

반복문은 th:each를 사용한다.

<tr th:each="dto : ${list}">
    <td th:text="${dto.subject}">과목</td>
    <td th:text="${dto.seq}">번호</td>
</tr>

JSP의 c:forEach와 비슷한 역할이다.

정리

Spring Boot 게시판 프로젝트를 보완하면서 Filter, Interceptor, Mapper 구조를 정리했고, 이후 Thymeleaf 기본 문법을 학습했다.

핵심은 다음과 같다.

Mapper
- SQL을 따로 분리해서 관리

Filter
- Controller 이전에 실행되는 공통 처리

Interceptor
- Controller 실행 전후에 동작

Thymeleaf
- HTML 기반 템플릿 엔진
- th:text, th:each, th:if 등으로 서버 데이터를 출력

[26.06.29-26.07.03] TIL 14주차 정리

buckwheat — Sun, 5 Jul 2026 15:07:56 +0900

Spring MVC부터 Spring Boot JDBC까지 한 주 정리

이번 주에는 Spring MVC 프로젝트에 공통 처리 기능을 붙이고, 파일 업로드와 REST API를 만든 뒤 Spring Boot 방식으로 넘어가는 흐름을 학습했다.

정리 범위는 다음 프로젝트다.

SpringMVC03_filter_aop_login_intercepter_transaction_encoding
SpringMVC04_file
SpringMVC05_REST
StartBoot01
StartBoot02

1. Spring MVC 기본 흐름

Spring MVC는 사용자의 요청을 Controller가 받고, 필요한 로직은 Biz(Service)와 Dao를 거쳐 처리한 뒤 JSP 화면으로 응답하는 구조다.

브라우저 요청
 -> DispatcherServlet
 -> Controller
 -> Biz(Service)
 -> Dao
 -> DB
 -> JSP 응답

목록 조회에서는 DB에서 가져온 데이터를 Model에 담아 JSP로 넘긴다.

@RequestMapping("/list.do")
public String selectList(Model model) {
    model.addAttribute("list", biz.selectList());
    return "mvclist";
}

Model은 Controller에서 JSP로 데이터를 전달할 때 사용한다.
위 코드에서는 게시글 목록을 list라는 이름으로 JSP에 넘긴다.

등록, 수정, 삭제 후에는 보통 redirect를 사용한다.

@RequestMapping("/insertres.do")
public String insert(BoardDto dto) {
    int res = biz.insert(dto);

    if (res > 0) {
        return "redirect:list.do";
    } else {
        return "redirect:insertform.do";
    }
}

redirect는 서버 내부 이동이 아니라 브라우저에게 다시 요청할 주소를 알려주는 방식이다.

2. Filter

Filter는 Controller에 도착하기 전에 먼저 실행되는 공통 처리 단계다.
이번 프로젝트에서는 한글 깨짐 방지와 요청 로그 출력에 사용했다.

<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

forceEncoding=true는 요청과 응답에 UTF-8 인코딩을 강제로 적용하겠다는 의미다.

직접 만든 LogFilter에서는 요청 URI, URL, 브라우저 정보 등을 로그로 남겼다.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {

    HttpServletRequest req = (HttpServletRequest) request;

    String uri = req.getRequestURI();
    String agent = req.getHeader("User-Agent");

    logger.info("URI: " + uri);
    logger.info("agent: " + agent);

    chain.doFilter(req, response);
}

chain.doFilter()를 호출해야 다음 단계인 DispatcherServlet과 Controller로 요청이 계속 이동한다.

3. AOP

AOP는 여러 곳에서 반복되는 공통 기능을 따로 분리하는 방식이다.
대표적으로 로그 출력, 트랜잭션 처리, 예외 처리 같은 기능에 사용한다.

핵심 로직: 게시글 등록, 수정, 삭제
공통 로직: 로그, 트랜잭션, 예외 처리

모든 메서드에 로그 코드를 직접 작성하면 코드가 지저분해진다.
AOP를 사용하면 핵심 로직은 그대로 두고, 공통 로직만 별도 클래스로 관리할 수 있다.

4. 로그인과 비밀번호 암호화

회원가입 시 비밀번호를 그대로 DB에 저장하지 않고 BCryptPasswordEncoder로 암호화했다.

String encode = passwordEncoder.encode(dto.getMemberpw());
dto.setMemberpw(encode);

int res = biz.insert(dto);

로그인할 때는 사용자가 입력한 비밀번호와 DB에 저장된 암호화 비밀번호를 비교한다.

if (res != null) {
    if (passwordEncoder.matches(dto.getMemberpw(), res.getMemberpw())) {
        session.setAttribute("login", res);
    }
}

matches()는 평문 비밀번호와 암호화된 비밀번호가 같은 값인지 확인해준다.

5. Interceptor

Interceptor는 Spring MVC 안에서 Controller 실행 전후에 동작한다.
이번 프로젝트에서는 로그인 여부를 확인하는 데 사용했다.

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws IOException {

    if (request.getSession().getAttribute("login") != null) {
        return true;
    }

    response.sendRedirect("loginform.do");
    return false;
}

preHandle()에서 true를 반환하면 Controller가 실행되고, false를 반환하면 Controller로 가지 않는다.

Filter와 Interceptor의 차이는 다음과 같이 볼 수 있다.

Filter: Spring MVC 바깥에서 먼저 처리
Interceptor: Spring MVC 안에서 Controller 전후 처리

6. Transaction

트랜잭션은 여러 DB 작업을 하나의 작업 단위로 묶는 개념이다.

@Service
@Transactional
public class BoardBizImpl implements BoardBiz {
    ...
}

DB 작업이 모두 성공하면 commit, 중간에 실패하면 rollback된다.

모두 성공 -> commit
중간 실패 -> rollback

예를 들어 insert 작업을 여러 번 수행하는 중 하나가 실패하면, 앞에서 성공한 작업까지 취소해서 데이터가 애매하게 남지 않도록 한다.

7. 파일 업로드

파일 업로드에서는 일반 form 전송과 다르게 multipart/form-data 설정이 필요하다.

<form action="upload" method="post" enctype="multipart/form-data">
    <input type="file" name="mpfile">
</form>

Controller에서는 MultipartFile로 파일을 받는다.

@RequestMapping("/upload")
public String fileUpload(UploadFile uploadFile, BindingResult result, Model model) {
    fileValidator.validate(uploadFile, result);

    if (result.hasErrors()) {
        return "uploadform";
    }

    MultipartFile file = uploadFile.getMpfile();

    UploadFile fileobj = new UploadFile();
    fileobj.setFilename(file.getOriginalFilename());
    fileobj.setDesc(uploadFile.getDesc());

    model.addAttribute("fileobj", fileobj);
    return "uploadres";
}

파일을 서버 폴더에 저장할 때는 InputStream과 OutputStream을 사용했다.

inputStream = file.getInputStream();
outputStream = new FileOutputStream(newFile);

byte[] b = new byte[(int) file.getSize()];

while ((res = inputStream.read(b)) != -1) {
    outputStream.write(b, 0, res);
}

파일 업로드 흐름은 다음과 같다.

파일 선택
 -> multipart/form-data 전송
 -> MultipartFile로 받기
 -> 유효성 검사
 -> 서버 폴더에 저장
 -> 결과 화면 출력

8. REST API

REST는 JSP 화면을 반환하는 것이 아니라 데이터를 반환하는 방식이다.
이번 프로젝트에서는 @RestController를 사용해 JSON 데이터를 응답했다.

@RestController
public class RestControllerTest {

    @RequestMapping(value="/restdto", method=RequestMethod.GET)
    public List<RestDto> getRest() {
        return service.selectList();
    }
}

@Controller는 주로 JSP 화면 이름을 반환하고, @RestController는 반환값 자체를 응답 데이터로 보낸다.

REST에서 자주 쓰는 HTTP 메서드는 다음과 같다.

GET    조회
POST   등록
PUT    수정
DELETE 삭제

등록 요청은 POST로 처리했다.

@RequestMapping(value="/restdto", method=RequestMethod.POST)
public Map<String, Integer> postRest(RestDto dto) {
    int res = service.insert(dto);

    Map<String, Integer> map = new HashMap<String, Integer>();

    if (res > 0) {
        map.put("code", 200);
    } else {
        map.put("code", 500);
    }

    return map;
}

Map<String, Integer>는 key는 문자열, value는 정수인 데이터 구조다.
위 코드는 다음과 같은 JSON 응답으로 변환될 수 있다.

{
  "code": 200
}

9. Spring Boot 시작

StartBoot01에서는 Spring Boot의 기본 실행 구조를 확인했다.

@SpringBootApplication
public class StartBoot01Application {

    public static void main(String[] args) {
        SpringApplication.run(StartBoot01Application.class, args);
    }
}

기존 Spring MVC는 외부 Tomcat에 프로젝트를 올리고 web.xml, servlet-context.xml 같은 설정을 많이 작성했다.
Spring Boot는 내장 Tomcat을 사용하기 때문에 main 메서드로 바로 실행할 수 있다.

JSP를 사용하려면 view 경로 설정이 필요하다.

spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

Controller에서 return "test";를 하면 실제로는 다음 JSP를 찾는다.

/WEB-INF/views/test.jsp

10. Spring Boot + JDBC

StartBoot02에서는 Spring Boot에서 JDBC를 사용해 게시판 CRUD를 만들었다.

DB 연결 정보는 application.properties에 작성한다.

server.port=8787

spring.datasource.driver-class-name=oracle.jdbc.driver.OracleDriver
spring.datasource.url=jdbc:oracle:thin:@localhost:1521/XEPDB1
spring.datasource.username=multi
spring.datasource.password=multi

DAO에서는 JdbcTemplate을 사용했다.

@Repository
public class MyDaoImpl implements MyDao {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Override
    public List<MyDto> selectList() {
        String sql = " SELECT * FROM MYBOARD ORDER BY MYNO DESC ";
        return jdbcTemplate.query(sql, rowMapper);
    }
}

JdbcTemplate은 JDBC 코드를 더 간단하게 작성할 수 있게 해준다.
직접 Connection, PreparedStatement, ResultSet을 매번 열고 닫는 코드를 줄일 수 있다.

Controller에서는 요청을 받아 Biz를 호출하고, 결과를 JSP로 넘긴다.

@GetMapping("/list")
public String selectList(Model model) {
    model.addAttribute("list", biz.selectList());
    return "myboardlist";
}

등록은 POST 요청으로 처리했다.

@PostMapping("/insert")
public String insert(MyDto dto) {
    int res = biz.insert(dto);

    if (res > 0) {
        return "redirect:/myboard/list";
    } else {
        return "redirect:/myboard/insertform";
    }
}

Spring Boot에서도 전체 구조는 기존 MVC와 비슷하다.

Controller
 -> Biz
 -> Dao
 -> JdbcTemplate
 -> Oracle DB

차이점은 설정 방식이다.
기존 Spring MVC는 XML 설정이 많았고, Spring Boot는 application.properties와 자동 설정을 중심으로 동작한다.

마무리

이번 주는 단순 CRUD에서 끝나는 것이 아니라 웹 애플리케이션에 필요한 공통 기능들을 하나씩 붙여보는 시간이었다.

핵심만 정리하면 다음과 같다.

Filter
- Controller 전에 실행되는 공통 처리
- 인코딩, 로그 처리 등에 사용

AOP
- 반복되는 공통 기능 분리
- 로그, 트랜잭션 등에 사용

Interceptor
- Controller 실행 전후에 동작
- 로그인 체크에 적합

Transaction
- 여러 DB 작업을 하나의 단위로 묶음
- 실패 시 rollback

File Upload
- multipart/form-data 필요
- MultipartFile로 파일 처리

REST
- JSP가 아니라 데이터를 응답
- GET, POST, PUT, DELETE 사용

Spring Boot
- 내장 Tomcat으로 실행
- application.properties 중심 설정
- 기존 Spring MVC보다 설정이 간단함

전체적으로 이번 주 학습 내용은 Spring MVC 프로젝트를 실제 웹 애플리케이션에 가깝게 확장하고, 이후 Spring Boot 방식으로 전환하는 흐름이었다.

[26.06.22-26.06.26] TIL 13주차 정리

buckwheat — Tue, 30 Jun 2026 17:27:24 +0900

https://buckwheat0.tistory.com/69

[2026.06.22] - TIL 56일차 Spring MVC 기본 구조 정리

목차1 오늘 학습 흐름2 Spring MVC 프로젝트 구조3 pom.xml과 Spring MVC 의존성4 web.xml의 역할5 DispatcherServlet6 ContextLoaderListener7 Root Context와 Servlet Context8 Controller9 @RequestMapping10 Model11 ModelAndView12 @RequestParam1

buckwheat0.tistory.com

https://buckwheat0.tistory.com/70

[2026.06.23] - TIL 57일차(Spring MVC03 게시판 프로젝트 완성)

목차1 Spring MVC 프로젝트 구조2 MyBatis를 활용한 게시판 구현3 View(JSP) 작성4 Spring 설정 파일5 프로젝트 실행 흐름6 오류 해결 과정1 Spring MVC 프로젝트 구조1) Spring MVC 패턴 이해Spring MVC는 프로젝트를

buckwheat0.tistory.com

https://buckwheat0.tistory.com/71

[2026.06.24] - TIL 58일차 개발자를 위한 UI/UX 특강 정리

목차1 오늘 학습 흐름2 UI/UX 특강 개요3 UI와 UX의 차이4 페르소나5 고객 여정 지도6 사이트맵7 와이어프레임8 프로토타입9 CodeMate 서비스 기획10 고객 여정 지도 설계 내용11 사이트맵 설계 내용12 Figm

buckwheat0.tistory.com

https://buckwheat0.tistory.com/73

[2026.06.25 ~ 2026.06.26] - TIL 59~60일차 MSA 특강 정리

목차1 MSA란 무엇인가2 모놀리식 아키텍처와 MSA3 MSA의 주요 특징4 MSA 전환 사례5 MSA를 무조건 선택하면 안 되는 이유6 MSA 이전 방법론7 소프트웨어 아키텍처 구성 요소8 ADR9 서비스 기반 아키텍처10

buckwheat0.tistory.com

[2026.06.25 ~ 2026.06.26] - TIL 59~60일차 MSA 특강 정리

buckwheat — Tue, 30 Jun 2026 17:25:38 +0900

목차
1 MSA란 무엇인가
2 모놀리식 아키텍처와 MSA
3 MSA의 주요 특징
4 MSA 전환 사례
5 MSA를 무조건 선택하면 안 되는 이유
6 MSA 이전 방법론
7 소프트웨어 아키텍처 구성 요소
8 ADR
9 서비스 기반 아키텍처
10 이벤트 기반 아키텍처
11 마이크로서비스 아키텍처
12 DDD와 마이크로서비스 설계
13 이벤트 스토밍
14 아키텍처 도식화와 C4 Model
15 Spring Cloud
16 Docker 기본 개념
17 Docker 주요 실습
18 Docker Swarm
19 Kubernetes
20 Kubernetes 주요 오브젝트
21 Ingress와 Service Mesh
22 CI/CD
23 학습 내용 정리

1 MSA란 무엇인가

1) MSA의 의미

(1) MSA

MSA는 Microservices Architecture의 줄임말이다.

하나의 큰 애플리케이션을 여러 개의 작은 서비스로 나누고, 각 서비스가 독립적으로 실행되고 배포될 수 있도록 구성하는 아키텍처이다.

(2) Microservice

마이크로서비스는 하나의 비즈니스 기능을 담당하는 작은 서비스이다.

예를 들어 쇼핑몰이라면 회원 서비스, 주문 서비스, 결제 서비스, 배송 서비스처럼 나눌 수 있다.

(3) 핵심

MSA의 핵심은 큰 시스템을 작게 나누는 것이다.

하지만 단순히 코드를 작게 나누는 것이 아니라, 비즈니스 기능 단위로 나누고 각 서비스가 독립적으로 개발, 배포, 확장될 수 있어야 한다.

2) MSA의 기본 구조

(1) 독립 실행

각 마이크로서비스는 자기 자신의 프로세스에서 실행된다.

하나의 서비스가 죽더라도 전체 시스템이 모두 멈추지 않도록 설계할 수 있다.

(2) 가벼운 통신

서비스들은 HTTP API, 메시지 큐, 이벤트 등을 통해 통신한다.

직접 메소드 호출처럼 강하게 묶이는 방식보다 느슨하게 연결되는 구조를 지향한다.

(3) 독립 배포

각 서비스는 독립적으로 배포할 수 있어야 한다.

주문 서비스만 수정했다면 전체 시스템을 다시 배포하는 것이 아니라 주문 서비스만 배포할 수 있어야 한다.

2 모놀리식 아키텍처와 MSA

1) 모놀리식 아키텍처

(1) 의미

모놀리식 아키텍처는 하나의 애플리케이션 안에 모든 기능이 들어 있는 구조이다.

회원, 주문, 결제, 배송 기능이 하나의 프로젝트와 하나의 배포 단위 안에 들어가는 방식이다.

(2) 장점

서비스 규모가 작을 때는 구조가 단순하고 개발하기 쉽다.

한 프로젝트 안에서 모든 기능을 볼 수 있고, 배포도 하나만 하면 된다.

(3) 단점

시스템이 커지면 코드베이스가 비대해진다.

한 기능의 문제가 전체 장애로 이어질 수 있고, 작은 수정에도 전체 시스템을 다시 배포해야 할 수 있다.

2) MSA

(1) 의미

MSA는 큰 시스템을 작은 서비스들로 나눈 구조이다.

각 서비스는 독립된 기능을 담당하고, 필요한 경우 서로 API나 메시지로 통신한다.

(2) 장점

서비스별로 독립 개발, 독립 배포, 독립 확장이 가능하다.

한 서비스에 장애가 발생해도 전체 시스템으로 장애가 번지는 것을 줄일 수 있다.

(3) 단점

서비스가 많아지면 통신 구조, 배포 구조, 모니터링, 로그 관리, 장애 대응이 복잡해진다.

즉, MSA는 코드를 나누는 것보다 운영 복잡도를 감당하는 것이 더 어렵다.

3 MSA의 주요 특징

1) MSA의 9가지 특징

(1) Componentization via Services

기능을 라이브러리나 모듈이 아니라 서비스 단위로 나눈다.

각 서비스는 독립적인 실행 단위가 된다.

(2) Organized around Business Capabilities

기술 계층이 아니라 비즈니스 기능을 기준으로 서비스를 나눈다.

예를 들어 Controller, Service, DAO 기준으로 나누는 것이 아니라 주문, 결제, 회원 같은 비즈니스 기준으로 나눈다.

(3) Products not Projects

프로젝트를 한 번 만들고 끝내는 것이 아니라, 서비스 자체를 계속 운영하고 발전시키는 제품으로 본다.

(4) Smart endpoints and dumb pipes

서비스 자체가 똑똑하게 비즈니스 로직을 처리하고, 통신 경로는 단순하게 유지한다.

복잡한 중앙 통합 장치에 모든 로직을 몰아넣지 않는다.

(5) Decentralized Governance

모든 서비스가 반드시 같은 기술을 사용할 필요는 없다.

서비스 특성에 따라 다른 언어, 프레임워크, 저장소를 사용할 수 있다.

(6) Decentralized Data Management

하나의 중앙 DB에 모든 서비스가 붙는 것이 아니라, 서비스별로 데이터를 분리해서 관리할 수 있다.

(7) Infrastructure Automation

서비스가 많기 때문에 배포와 운영을 수동으로 처리하기 어렵다.

CI/CD, 컨테이너, 오케스트레이션 같은 자동화가 중요하다.

(8) Design for Failure

분산 시스템에서는 장애가 발생할 수밖에 없다고 보고 설계해야 한다.

일부 서비스 장애가 전체 장애로 확산되지 않도록 해야 한다.

(9) Evolutionary Design

처음부터 완벽한 설계를 고정하는 것이 아니라, 서비스가 성장하면서 점진적으로 개선할 수 있어야 한다.

4 MSA 전환 사례

1) Coupang

(1) 초기 구조

쿠팡은 초기에는 Apache, Tomcat, MySQL 기반의 모놀리식 구조로 운영되었다.

(2) 문제점

고객과 개발자가 급격히 늘어나면서 확장성 문제가 발생했다.

한 컴포넌트의 장애가 전체 장애로 이어지고, 공통 모듈이 비대해지고, 배포와 테스트 비용이 커졌다.

(3) 전환

쿠팡은 2013년부터 MSA 전환을 추진했다.

자체적으로 Java 기반의 Vitamin Framework를 구축했다는 점이 특징이다.

2) 11번가

(1) 기존 구조

11번가는 오랫동안 초대형 모놀리식 시스템을 운영했다.

오래된 소프트웨어 스택, 거대한 공통 모듈, 어려운 개발 환경, 정기 배포의 부담이 있었다.

(2) 문제점

하나의 수정이 전체 장애로 이어질 수 있었고, IDE에 프로젝트를 띄우는 것조차 버거운 상황이었다.

(3) 전환

Netflix Spring Cloud와 Spring Boot 기반의 MSA 구조로 점진적으로 전환했다.

3) 카카오톡 이모티콘 서비스

(1) 기존 문제

이모티콘 서비스, 이모티콘 스튜디오, Admin 서비스들이 각각 모놀리식으로 구성되어 있었다.

오래된 Java와 Play Framework를 사용해 기술 부채가 컸다.

(2) 운영 문제

배포 방식이 서버마다 다르고, 브랜치 관리가 복잡하며, 메인 DB 트래픽이 높아지는 문제가 있었다.

(3) 전환 방향

Kotlin, Spring, Kubernetes, Istio 등을 활용해 MSA 기반 구조로 개선했다.

4) 토스뱅크

(1) 기존 은행 시스템

일반적인 은행 시스템은 채널계와 코어뱅킹으로 나뉜다.

채널계는 MSA 구조를 적용하기 쉬웠지만, 코어뱅킹은 오랫동안 모놀리식 구조로 유지되었다.

(2) 문제점

모놀리식 코어뱅킹은 트랜잭션 처리에는 유리하지만 스케일 아웃이 어렵고, 장애 영향 범위를 제한하기 어렵다.

(3) 전환

토스뱅크는 모바일 특화 MSA 아키텍처로 코어뱅킹을 전환했다.

이를 통해 도메인별 독립 개선과 빠른 기능 배포가 가능해졌다.

5 MSA를 무조건 선택하면 안 되는 이유

1) MSA의 적절한 사용 시점

(1) 작은 서비스에는 모놀리식이 유리할 수 있다

서비스 규모가 작을 때는 모놀리식 구조가 더 단순하고 효율적이다.

스타트업이 MVP를 만들 때 처음부터 MSA를 선택하면 오버엔지니어링이 될 수 있다.

(2) MSA가 필요한 시점

코드베이스가 너무 커져 관리가 어렵거나, 개발자가 많아져 배포 충돌이 잦거나, 특정 기능만 독립 확장해야 할 때 MSA를 고려할 수 있다.

(3) 핵심 판단 기준

MSA는 유행이라서 선택하는 것이 아니다.

서비스 규모, 팀 규모, 배포 빈도, 장애 격리 필요성, 확장성 요구가 분명할 때 선택해야 한다.

2) MSA의 어려움

(1) 서비스 간 통신 복잡도

서비스를 나누면 각 서비스가 네트워크를 통해 통신해야 한다.

네트워크 지연, 장애, 타임아웃, 재시도 같은 문제가 발생한다.

(2) 운영 복잡도 증가

서비스가 많아지면 로그, 모니터링, 배포, 설정 관리, 장애 추적이 어려워진다.

(3) 데이터 관리 복잡도

서비스별 DB를 분리하면 데이터 정합성을 맞추는 방식도 고민해야 한다.

하나의 트랜잭션으로 모든 처리를 끝내기 어려워질 수 있다.

6 MSA 이전 방법론

1) 직접 아키텍처 구축

(1) 의미

기업 내부에서 자체 프레임워크와 도구를 만들어 MSA를 구축하는 방식이다.

(2) 장점

필요한 부분을 원하는 방식으로 수정할 수 있다.

조직에 맞는 맞춤형 구조를 만들 수 있다.

(3) 단점

충분한 인력, 시간, 예산이 필요하다.

이후 유지보수 비용도 계속 발생한다.

2) Netflix Spring Cloud 사용

(1) 의미

Spring Cloud와 Netflix OSS를 활용해 MSA를 구현하는 방식이다.

Eureka, Zuul, Ribbon, Hystrix 같은 구성 요소를 사용할 수 있다.

(2) 장점

Java와 Spring Boot 기반 프로젝트에 적합하다.

사례가 많고 Java 개발자에게 익숙하다.

(3) 단점

Java와 Spring Boot에 종속될 수 있다.

MSA 관련 코드가 소스 레벨에 포함될 수 있다.

3) Kubernetes 사용

(1) 의미

컨테이너와 Kubernetes를 기반으로 서비스를 배포하고 운영하는 방식이다.

(2) 장점

언어에 종속되지 않는다.

Java, Python, Node.js 등 다양한 언어로 작성된 서비스를 함께 운영할 수 있다.

(3) 단점

Kubernetes 자체의 학습 난이도가 높다.

컨테이너, 네트워크, 배포, 운영에 대한 이해가 필요하다.

7 소프트웨어 아키텍처 구성 요소

1) 아키텍처를 구성하는 요소

(1) 아키텍처 특성

시스템이 지원해야 하는 품질 속성이다.

가용성, 신뢰성, 민첩성, 복구성, 확장성, 성능 등이 여기에 해당한다.

(2) 아키텍처 결정

시스템을 구축할 때 지켜야 하는 중요한 규칙이다.

예를 들어 데이터베이스 접근은 특정 계층에서만 허용한다는 결정이 있을 수 있다.

(3) 설계 원칙

시스템을 만들 때 따라야 할 가이드라인이다.

예를 들어 서비스 간 통신은 비동기 메시징을 우선 사용한다는 원칙을 둘 수 있다.

(4) 시스템 구조

어떤 아키텍처 스타일을 적용했는지를 의미한다.

예를 들어 레이어드 아키텍처, 이벤트 기반 아키텍처, 마이크로서비스 아키텍처가 있다.

8 ADR

1) ADR의 의미

(1) ADR

ADR은 Architecture Decision Record의 줄임말이다.

중요한 아키텍처 결정을 문서화하는 방법이다.

(2) 필요한 이유

왜 이런 기술을 선택했는지, 왜 이런 구조로 설계했는지 기록하지 않으면 시간이 지난 뒤 이유를 알기 어렵다.

ADR은 의사결정의 배경과 결과를 남기는 문서이다.

2) ADR의 기본 구조

(1) 제목

어떤 결정을 기록하는지 짧게 작성한다.

(2) 상태

제안됨, 수락됨, 대체됨 같은 상태를 기록한다.

(3) 콘텍스트

왜 이 결정을 해야 했는지 상황을 설명한다.

(4) 결정

어떤 결정을 내렸는지와 그 이유를 작성한다.

(5) 결과

이 결정이 시스템과 팀에 어떤 영향을 주는지 정리한다.

9 서비스 기반 아키텍처

1) 서비스 기반 아키텍처

(1) 의미

서비스 기반 아키텍처는 여러 원격 서비스를 사용하는 대규모 분산 레이어 구조이다.

MSA와 비슷하지만 중앙 공유 데이터베이스를 사용할 수 있다는 점이 다르다.

(2) 특징

UI와 여러 서비스가 분리되어 있고, 서비스들이 공통 DB를 사용할 수 있다.

MSA보다 현실적으로 도입하기 쉬운 경우가 있다.

(3) MSA와의 차이

MSA는 서비스별로 데이터까지 분리하는 방향을 지향한다.

서비스 기반 아키텍처는 중앙 공유 DB를 사용할 수 있어 데이터 분리 강도가 MSA보다 약하다.

10 이벤트 기반 아키텍처

1) 이벤트 기반 아키텍처

(1) 의미

이벤트 기반 아키텍처는 이벤트를 중심으로 시스템이 동작하는 구조이다.

어떤 사건이 발생하면 그 이벤트를 비동기적으로 처리한다.

(2) 장점

확장성이 좋고, 고성능 애플리케이션에 적합하다.

서비스들이 직접 강하게 연결되지 않고 이벤트를 통해 느슨하게 연결될 수 있다.

(3) 주요 구성

시작 이벤트, 이벤트 브로커, 이벤트 프로세서, 처리 이벤트 등이 있다.

중재자 토폴로지와 브로커 토폴로지 같은 구조를 사용할 수 있다.

11 마이크로서비스 아키텍처

1) 마이크로서비스 아키텍처

(1) 핵심 목표

마이크로서비스의 주요 목표는 서비스 간 결합도를 낮추는 것이다.

각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 만든다.

(2) 데이터 격리

마이크로서비스는 서비스별로 데이터를 분리하는 것이 중요하다.

데이터베이스를 공유하면 서비스 간 의존성이 커질 수 있다.

(3) API Gateway

클라이언트 요청을 여러 서비스로 라우팅하기 위해 API Gateway를 사용할 수 있다.

인증, 인가, SSL, 캐싱, 라우팅 같은 공통 기능을 처리할 수 있다.

12 DDD와 마이크로서비스 설계

1) DDD

(1) 의미

DDD는 Domain Driven Design의 줄임말로 도메인 주도 설계를 의미한다.

비즈니스 도메인을 중심으로 시스템을 설계하는 방법이다.

(2) MSA와의 관계

MSA에서는 서비스를 비즈니스 기능 단위로 나누는 것이 중요하다.

DDD는 어떤 기준으로 서비스를 나눌지 판단하는 데 도움을 준다.

2) 서브도메인

(1) 핵심 서브도메인

기업의 경쟁력을 만드는 핵심 비즈니스 영역이다.

직접 개발하고 집중적으로 관리해야 하는 영역이다.

(2) 지원 서브도메인

비즈니스에 필요하지만 핵심 경쟁력은 아닌 영역이다.

(3) 일반 서브도메인

비즈니스에 특화되지는 않았지만 필요한 영역이다.

기존 제품이나 SaaS를 활용해 대체할 수 있다.

3) 바운디드 컨텍스트

(1) 의미

바운디드 컨텍스트는 하나의 도메인 모델이 적용되는 경계이다.

같은 단어라도 컨텍스트가 다르면 의미가 달라질 수 있다.

(2) 중요한 이유

서비스의 경계를 정할 때 바운디드 컨텍스트를 기준으로 삼을 수 있다.

내부 응집도는 높이고, 외부 의존도는 낮추는 것이 중요하다.

4) 유비쿼터스 언어

(1) 의미

유비쿼터스 언어는 특정 도메인 안에서 모두가 같은 의미로 사용하는 공통 언어이다.

기획자, 개발자, 사용자, 도메인 전문가가 같은 용어를 같은 의미로 사용하도록 돕는다.

(2) 필요한 이유

용어가 다르면 요구사항 이해가 달라질 수 있다.

유비쿼터스 언어를 정리하면 도메인 이해와 커뮤니케이션 오류를 줄일 수 있다.

13 이벤트 스토밍

1) 이벤트 스토밍의 의미

(1) 이벤트 스토밍

이벤트 스토밍은 이벤트를 중심으로 이해관계자들이 모여 도메인을 분석하는 방법이다.

최종 결과는 컨텍스트맵으로 이어질 수 있다.

(2) 목적

시스템에서 어떤 사건이 발생하고, 누가 어떤 명령을 내리고, 어떤 데이터가 바뀌는지 시각적으로 정리한다.

2) 주요 스티커 유형

(1) 도메인 이벤트

이미 발생한 사건이다.

과거시제 동사로 표현한다.

(2) 커맨드

도메인 이벤트를 발생시키는 명령이다.

API 요청과 연결될 수 있다.

(3) 액터

시스템을 사용하는 사람이나 조직의 역할이다.

(4) 애그리게이트

커맨드와 이벤트가 처리하는 데이터이다.

상태가 변경되는 핵심 데이터로 볼 수 있다.

(5) 정책

특정 이벤트가 발생했을 때 어떤 커맨드를 실행할지 나타낸다.

“이 이벤트가 발생하면 이 명령을 수행한다”처럼 표현한다.

(6) 핫스팟

아직 결정되지 않은 질문, 의문, 위험 요소를 표시한다.

14 아키텍처 도식화와 C4 Model

1) 아키텍처 도식화

(1) 필요한 이유

아키텍처는 말로만 설명하면 이해하기 어렵다.

시스템 구조를 그림으로 표현하면 이해관계자와 개발자가 같은 구조를 공유하기 쉽다.

(2) 도구

UML, C4, ArchiMate 같은 표준이 있다.

PlantUML은 텍스트 기반으로 다이어그램을 작성할 수 있는 도구이다.

2) C4 Model

(1) Context

전체 시스템과 외부 사용자, 외부 시스템의 관계를 보여준다.

(2) Container

시스템 내부의 배포 가능한 단위를 보여준다.

웹 애플리케이션, API 서버, 데이터베이스 같은 단위가 컨테이너가 될 수 있다.

(3) Component

컨테이너 내부의 주요 모듈과 역할을 보여준다.

(4) Code

컴포넌트 내부의 클래스 구조를 보여준다.

필요할 때만 상세하게 작성한다.

15 Spring Cloud

1) Spring Cloud의 의미

(1) Spring Cloud

Spring Cloud는 마이크로서비스 아키텍처를 구축하고 관리하기 위한 도구와 프레임워크의 모음이다.

Spring Boot 기반 애플리케이션에 여러 분산 시스템 기능을 추가할 수 있다.

2) 주요 구성 요소

(1) Service Discovery

서비스의 위치를 등록하고 찾는 기능이다.

대표적으로 Eureka가 있다.

(2) API Gateway

클라이언트와 마이크로서비스 사이에서 라우팅, 인증, 로드밸런싱 등을 처리한다.

(3) Circuit Breaker

장애가 발생한 서비스 호출을 격리하여 전체 장애 확산을 막는다.

과거에는 Hystrix를 사용했고, 현재는 Resilience4J를 많이 사용한다.

(4) Configuration Management

여러 서비스의 설정 정보를 중앙에서 관리한다.

(5) Distributed Tracing

여러 서비스를 거치는 요청 흐름을 추적한다.

장애 분석과 성능 최적화에 도움이 된다.

16 Docker 기본 개념

1) Docker

(1) 의미

Docker는 애플리케이션과 실행에 필요한 파일, 라이브러리, 설정을 컨테이너 형태로 패키징하고 실행하는 도구이다.

(2) VM과 차이

VM은 운영체제 전체를 가상화한다.

Docker 컨테이너는 호스트의 커널을 공유하고, 애플리케이션 실행에 필요한 환경만 별도로 가진다.

(3) 장점

VM보다 가볍고 실행이 빠르다.

개발 환경과 운영 환경의 차이를 줄일 수 있다.

2) 컨테이너

(1) 의미

컨테이너는 애플리케이션을 실행하기 위한 격리된 환경이다.

애플리케이션, 라이브러리, 설정 파일을 함께 포함한다.

(2) 이미지

이미지는 컨테이너를 만들기 위한 실행 템플릿이다.

컨테이너는 이미지를 실행한 결과이다.

(3) Dockerfile

Dockerfile은 이미지를 만들기 위한 명령어를 작성한 파일이다.

어떤 베이스 이미지를 사용할지, 어떤 파일을 복사할지, 어떤 명령으로 실행할지를 정의한다.

17 Docker 주요 실습

1) 기본 명령어

(1) docker -v

Docker 버전을 확인한다.

(2) docker run

이미지를 기반으로 컨테이너를 생성하고 실행한다.

(3) docker ps

현재 실행 중인 컨테이너 목록을 확인한다.

(4) docker ps -a

종료된 컨테이너를 포함해 모든 컨테이너를 확인한다.

(5) docker images

로컬에 저장된 이미지 목록을 확인한다.

(6) docker rm

컨테이너를 삭제한다.

(7) docker rmi

이미지를 삭제한다.

2) 웹 서버 실습

(1) 포트 매핑

컨테이너 내부의 80번 포트를 호스트의 80번 포트와 연결했다.

이를 통해 브라우저에서 컨테이너 내부 웹 서버에 접속할 수 있다.

(2) Apache 실행

Ubuntu 컨테이너에 apache2를 설치하고 service apache2 start로 웹 서버를 실행했다.

3) WordPress 실습

(1) MySQL 컨테이너

WordPress에서 사용할 DB로 MySQL 컨테이너를 실행했다.

(2) WordPress 컨테이너

WordPress 컨테이너를 실행하고 MySQL 컨테이너와 연결했다.

(3) Volume 사용

DB 데이터를 컨테이너 내부에만 저장하면 컨테이너 삭제 시 데이터가 사라진다.

Volume을 사용하면 데이터를 호스트나 Docker Volume에 저장해 유지할 수 있다.

4) Docker Network

(1) bridge

기본 네트워크 방식이다.

컨테이너는 브리지 네트워크를 통해 외부와 통신한다.

(2) host

컨테이너가 호스트의 네트워크를 그대로 사용한다.

(3) none

네트워크를 사용하지 않는 컨테이너를 만들 수 있다.

(4) network alias

같은 네트워크 안에서 컨테이너를 별칭으로 접근할 수 있다.

5) Docker Logging

(1) json-file

Docker의 기본 로그 드라이버이다.

컨테이너의 stdout, stderr 로그를 JSON 파일로 저장한다.

(2) syslog

로그를 syslog로 보낼 수 있다.

(3) fluentd

fluentd를 이용해 로그를 수집하고 MongoDB 같은 저장소로 보낼 수 있다.

(4) CloudWatch

AWS 환경에서는 CloudWatch로 컨테이너 로그를 전송할 수 있다.

6) 이미지 관리

(1) docker commit

실행 중인 컨테이너의 상태를 이미지로 저장할 수 있다.

(2) docker tag

이미지에 새로운 이름과 태그를 붙일 수 있다.

(3) docker push

이미지를 Docker Hub나 Private Registry에 업로드할 수 있다.

(4) docker pull

원격 저장소에서 이미지를 내려받을 수 있다.

18 Docker Swarm

1) Docker Swarm

(1) 의미

Docker Swarm은 여러 Docker 서버를 하나의 클러스터처럼 관리하는 오케스트레이션 도구이다.

(2) 필요한 이유

실제 운영 환경에서는 컨테이너를 하나의 서버에서만 실행하기 어렵다.

여러 서버에 컨테이너를 분산 배치하고, 장애 시 복구하고, 서비스를 확장해야 한다.

2) 주요 개념

(1) Manager Node

클러스터를 관리하는 노드이다.

서비스 생성, 스케줄링, 상태 관리를 담당한다.

(2) Worker Node

실제 컨테이너 작업을 실행하는 노드이다.

(3) Service

Swarm에서 실행할 애플리케이션 단위이다.

몇 개의 replica를 실행할지 지정할 수 있다.

(4) Replica

동일한 서비스 인스턴스의 개수이다.

replica를 늘리면 여러 컨테이너가 분산 실행된다.

3) Swarm 실습

(1) 클러스터 생성

manager 노드에서 docker swarm init을 실행해 클러스터를 생성했다.

(2) worker join

worker 노드들은 join token을 사용해 클러스터에 참여했다.

(3) service create

docker service create 명령으로 서비스를 생성했다.

(4) scale

docker service scale 명령으로 서비스 인스턴스 수를 늘리거나 줄였다.

(5) 자가복구

컨테이너 하나를 강제로 삭제해도 Swarm이 원하는 replica 수를 유지하기 위해 새 컨테이너를 다시 생성한다.

19 Kubernetes

1) Kubernetes

(1) 의미

Kubernetes는 컨테이너 오케스트레이션 도구이다.

여러 서버에서 컨테이너를 배포, 확장, 복구, 네트워킹, 서비스 연결까지 관리한다.

(2) 필요한 이유

컨테이너가 많아지면 수동으로 관리하기 어렵다.

어느 서버에 어떤 컨테이너를 배치할지, 장애 시 어떻게 복구할지, 외부 요청을 어떻게 연결할지 자동화가 필요하다.

(3) 시장 표준

여러 오케스트레이션 도구 중 Kubernetes가 사실상 시장 표준으로 사용된다.

2) Kubernetes 구성 요소

(1) kube-apiserver

Kubernetes API를 제공하는 서버이다.

모든 요청은 API Server를 통해 처리된다.

(2) etcd

클러스터 상태와 설정 정보를 저장하는 key-value 저장소이다.

(3) kube-scheduler

새로 생성되는 Pod를 어떤 노드에 배치할지 결정한다.

(4) kube-controller-manager

여러 컨트롤러를 실행하며 클러스터 상태를 원하는 상태로 유지한다.

(5) kubelet

각 노드에서 실행되며, Pod와 컨테이너 상태를 관리한다.

(6) kube-proxy

Service 네트워크와 트래픽 전달을 담당한다.

20 Kubernetes 주요 오브젝트

1) Pod

(1) 의미

Pod는 Kubernetes에서 배포 가능한 가장 작은 실행 단위이다.

하나 이상의 컨테이너를 포함할 수 있다.

2) ReplicaSet

(1) 의미

ReplicaSet은 정해진 수의 Pod가 항상 실행되도록 관리한다.

Pod가 죽으면 새 Pod를 만들어 개수를 유지한다.

3) Deployment

(1) 의미

Deployment는 애플리케이션 배포 단위이다.

내부적으로 ReplicaSet과 Pod를 관리한다.

(2) 사용하는 이유

업데이트, 롤백, 스케일링을 쉽게 수행할 수 있다.

4) Service

(1) 의미

Service는 Pod에 접근하기 위한 고정된 네트워크 진입점이다.

Pod는 생성되고 삭제되면서 IP가 바뀔 수 있기 때문에 Service가 안정적인 접근 경로를 제공한다.

5) Service Type

(1) ClusterIP

클러스터 내부에서만 접근 가능한 Service이다.

(2) NodePort

모든 노드의 특정 포트를 열어 외부에서 접근할 수 있게 한다.

(3) LoadBalancer

클라우드 제공자의 로드밸런서를 사용해 외부 IP를 제공한다.

6) Update와 Rollback

(1) Update

Deployment의 이미지 버전을 바꿔 새로운 버전으로 배포할 수 있다.

(2) Rollback

문제가 생기면 이전 버전으로 되돌릴 수 있다.

7) Scaling

(1) 의미

replicas 수를 조절해 Pod 개수를 늘리거나 줄일 수 있다.

트래픽이 많아지면 늘리고, 적어지면 줄일 수 있다.

21 Ingress와 Service Mesh

1) Ingress

(1) 의미

Ingress는 외부 요청을 경로 기반이나 도메인 기반으로 내부 Service에 전달하기 위한 Kubernetes 객체이다.

(2) 필요한 이유

MSA에서는 /user, /product, /pay 같은 경로를 각각 다른 서비스로 보내야 할 수 있다.

Ingress는 이런 라우팅 규칙을 정의한다.

(3) SSL/TLS 처리

여러 서비스에 각각 인증서를 넣는 대신 Ingress에서 SSL/TLS를 일괄 처리할 수 있다.

2) Ingress Controller

(1) 의미

Ingress는 규칙만 정의한다.

실제로 요청을 받아 라우팅하는 주체는 Ingress Controller이다.

(2) 예시

nginx ingress controller를 사용할 수 있다.

외부 요청은 Ingress Controller를 거쳐 내부 Service로 전달된다.

3) Istio

(1) 의미

Istio는 마이크로서비스 간 통신을 관리하는 서비스 메쉬 플랫폼이다.

(2) Sidecar

Kubernetes에서는 Pod마다 Envoy Proxy를 sidecar로 삽입해 트래픽을 통제할 수 있다.

(3) 기능

Istio는 라우팅, Circuit Breaker, fault injection, 버전별 트래픽 분배, 로그인 사용자 기반 라우팅 같은 기능을 제공한다.

(4) Kiali

Kiali는 Istio 서비스 메쉬의 트래픽 흐름을 시각화해주는 도구이다.

22 CI/CD

1) CI/CD의 의미

(1) CI

CI는 Continuous Integration의 줄임말이다.

여러 개발자의 코드를 자주 통합하고 테스트하는 과정이다.

(2) CD

CD는 Continuous Delivery 또는 Continuous Deployment를 의미한다.

코드가 항상 배포 가능한 상태를 유지하거나, 실제 운영 환경까지 자동 배포되도록 만드는 과정이다.

(3) 핵심

CI/CD는 개발자의 코드가 사용자가 사용할 수 있는 서비스로 전달되는 과정을 자동화하는 것이다.

2) Git 브랜치 전략

(1) Gitflow

master, develop, release, feature, hotfix 브랜치를 사용하는 전략이다.

브랜치가 많아 관리가 복잡할 수 있다.

(2) Trunk-based

main 또는 trunk 브랜치를 중심으로 짧은 주기의 통합을 지향한다.

CI/CD와 잘 맞는다.

(3) Github Flow

main과 feature 브랜치를 중심으로 작업한다.

main에 merge되면 배포로 이어지는 단순한 흐름을 가진다.

3) Github Actions

(1) 의미

Github Actions는 GitHub에서 제공하는 Workflow 자동화 도구이다.

테스트, 빌드, 배포 같은 작업을 자동화할 수 있다.

(2) Workflow

자동화 프로세스의 최상위 단위이다.

.github/workflows 폴더 안에 YAML 파일로 작성한다.

(3) Event

Workflow를 실행시키는 조건이다.

push, pull request, cron, webhook 등이 있다.

(4) Job

Workflow 안에서 실행되는 작업 단위이다.

여러 Job은 병렬 또는 순차적으로 실행될 수 있다.

(5) Step

Job 안에서 실행되는 세부 작업이다.

명령어를 실행하거나 Action을 사용할 수 있다.

(6) Runner

Workflow가 실제로 실행되는 환경이다.

GitHub가 제공하는 runner를 사용할 수도 있고, 직접 runner를 구성할 수도 있다.

4) Spring Boot와 CI/CD

(1) Spring Boot

Spring Boot는 Spring 기반 애플리케이션을 빠르게 시작할 수 있도록 도와주는 프레임워크이다.

내장 Tomcat을 제공하므로 별도의 WAS 설정 없이 실행할 수 있다.

(2) Gradle 빌드

gradlew build를 통해 jar 파일을 만들 수 있다.

결과물은 build/libs 아래에 생성된다.

(3) Docker 이미지 빌드

Dockerfile을 작성해 Spring Boot jar 파일을 컨테이너 이미지로 만들 수 있다.

(4) Kubernetes 배포

Deployment와 Service YAML을 작성해 Kubernetes 클러스터에 배포할 수 있다.

GitHub Actions를 이용하면 빌드부터 배포까지 자동화할 수 있다.

23 학습 내용 정리

1) MSA

(1) MSA는 큰 애플리케이션을 작은 서비스로 나누는 아키텍처이다.

(2) 서비스는 비즈니스 기능 단위로 나누는 것이 중요하다.

(3) 각 서비스는 독립 실행, 독립 배포, 독립 확장이 가능해야 한다.

(4) MSA는 장점도 크지만 운영 복잡도도 크기 때문에 무조건 선택하면 안 된다.

2) MSA 설계

(1) DDD는 마이크로서비스 경계를 나누는 데 도움을 준다.

(2) 바운디드 컨텍스트는 서비스 경계를 정의할 때 중요한 개념이다.

(3) 유비쿼터스 언어는 도메인 안에서 같은 용어를 같은 의미로 사용하게 해준다.

(4) 이벤트 스토밍은 도메인 이벤트를 중심으로 서비스를 도출하는 방법이다.

3) 아키텍처 문서화

(1) ADR은 중요한 아키텍처 결정을 기록하는 문서이다.

(2) C4 Model은 Context, Container, Component, Code 단계로 아키텍처를 표현한다.

(3) PlantUML은 텍스트로 다이어그램을 작성할 수 있는 도구이다.

4) Spring Cloud

(1) Spring Cloud는 Spring Boot 기반 MSA 구축을 도와주는 도구 모음이다.

(2) Eureka는 서비스 등록과 탐색을 담당한다.

(3) Gateway는 요청 라우팅과 인증, 필터링을 담당한다.

(4) Resilience4J는 장애 격리를 위한 Circuit Breaker 기능을 제공한다.

(5) Config는 설정 정보를 중앙에서 관리한다.

5) Docker

(1) Docker는 애플리케이션 실행 환경을 컨테이너로 패키징한다.

(2) 이미지는 컨테이너 실행을 위한 템플릿이다.

(3) 컨테이너는 이미지를 실행한 결과이다.

(4) Volume은 컨테이너 데이터 유지에 필요하다.

(5) Dockerfile은 이미지를 만들기 위한 설계도이다.

6) Docker Swarm

(1) Docker Swarm은 여러 Docker 서버를 클러스터로 관리한다.

(2) manager node와 worker node로 구성된다.

(3) service와 replica를 통해 컨테이너를 분산 실행한다.

(4) 컨테이너가 죽어도 원하는 상태를 유지하기 위해 자가복구한다.

7) Kubernetes

(1) Kubernetes는 컨테이너 오케스트레이션 도구이다.

(2) Pod는 가장 작은 배포 단위이다.

(3) Deployment는 애플리케이션 배포와 업데이트를 관리한다.

(4) Service는 Pod에 안정적으로 접근하기 위한 네트워크 객체이다.

(5) Ingress는 외부 요청을 경로 또는 도메인 기준으로 내부 서비스에 연결한다.

8) CI/CD

(1) CI는 코드를 지속적으로 통합하고 테스트하는 것이다.

(2) CD는 배포 가능한 상태를 유지하거나 배포 자체를 자동화하는 것이다.

(3) GitHub Actions는 Workflow를 통해 빌드, 테스트, 배포를 자동화할 수 있다.

(4) Spring Boot 애플리케이션은 Gradle로 빌드하고, Docker 이미지로 만들고, Kubernetes에 배포할 수 있다.

9) 이틀 동안 배운 점

(1) MSA는 단순히 서비스를 작게 나누는 것이 아니다

서비스를 나누는 기준은 기술 계층이 아니라 비즈니스 도메인이다.

잘못 나누면 오히려 복잡도만 증가할 수 있다.

(2) MSA는 설계와 운영이 함께 필요하다

서비스 분리만으로 MSA가 완성되지 않는다.

서비스 검색, 설정 관리, 장애 격리, 로그, 모니터링, 배포 자동화가 함께 필요하다.

(3) 컨테이너는 MSA 운영의 기본 기술이다

Docker는 애플리케이션 실행 환경을 컨테이너로 통일해준다.

Kubernetes는 여러 컨테이너를 실제 운영 환경에서 관리할 수 있게 해준다.

(4) 아키텍처 결정은 기록해야 한다

어떤 기술을 선택했는지, 왜 그렇게 나누었는지 기록하지 않으면 나중에 유지보수가 어려워진다.

ADR과 C4 Model은 이런 결정을 정리하고 공유하는 데 도움이 된다.

(5) CI/CD는 MSA에서 필수에 가깝다

서비스가 많아질수록 수동 배포는 현실적으로 어렵다.

GitHub Actions 같은 도구를 이용해 빌드, 테스트, 이미지 생성, 배포를 자동화해야 한다.

(6) 앞으로의 학습 방향

이번 특강을 통해 MSA, Docker, Kubernetes, CI/CD가 서로 따로 떨어진 기술이 아니라 하나의 흐름으로 연결된다는 것을 알게 되었다.

앞으로 Spring Boot로 마이크로서비스를 만들고, Docker 이미지로 패키징한 뒤, Kubernetes에 배포하는 과정을 직접 실습해보면 MSA 구조를 더 명확히 이해할 수 있을 것 같다.

[2026.06.24] - TIL 58일차 개발자를 위한 UI/UX 특강 정리

buckwheat — Thu, 25 Jun 2026 03:29:12 +0900

목차
1 오늘 학습 흐름
2 UI/UX 특강 개요
3 UI와 UX의 차이
4 페르소나
5 고객 여정 지도
6 사이트맵
7 와이어프레임
8 프로토타입
9 CodeMate 서비스 기획
10 고객 여정 지도 설계 내용
11 사이트맵 설계 내용
12 Figma 프로토타입 제작 및 제출
13 오늘 학습한 핵심 정리

1 오늘 학습 흐름

1) 개발자를 위한 UI/UX 특강

    (1) 오늘 학습 내용
    오늘은 개발자를 위한 UI/UX 특강을 들었다.
    단순히 화면을 예쁘게 만드는 것이 아니라, 사용자의 문제를 이해하고 그 문제를 해결하는 서비스 구조를 설계하는 과정을 학습했다.

    (2) 실습 흐름
    오늘 실습은 페르소나 작성, 고객 여정 지도 작성, 사이트맵 설계, 와이어프레임 제작, 프로토타입 제작 및 링크 제출 순서로 진행되었다.

    (3) 핵심 목표
    오늘의 핵심은 사용자의 문제를 먼저 파악하고, 그 사용자가 서비스를 이용하는 흐름에 맞춰 기능과 화면 구조를 설계하는 것이다.

    (4) 오늘 만든 서비스
    나는 초보 개발자 학습 관리 모바일 앱인 CodeMate를 기획했다.
    CodeMate는 개발 공부를 시작한 초보자가 개념 정리, 실습 코드, 에러 해결 기록, 복습을 한곳에서 관리할 수 있도록 돕는 서비스이다.

2 UI/UX 특강 개요

1) UI/UX의 필요성

    (1) 개발자에게 UI/UX가 필요한 이유
    개발자는 기능 구현에 집중하기 쉽다.
    하지만 실제 사용자는 기능이 존재하는 것뿐만 아니라, 그 기능을 얼마나 쉽게 찾고 사용할 수 있는지를 중요하게 느낀다.

    (2) 좋은 서비스의 기준
    좋은 서비스는 단순히 기능이 많은 서비스가 아니다.
    사용자의 문제를 정확히 해결하고, 사용자가 헷갈리지 않게 자연스러운 흐름을 제공하는 서비스가 좋은 서비스이다.

    (3) 오늘 특강의 의미
    오늘 특강을 통해 개발자는 코드를 작성하기 전에 사용자의 상황, 감정, 행동, 문제점을 먼저 이해해야 한다는 것을 배웠다.
    즉, 개발은 기능 구현에서 시작되는 것이 아니라 사용자 이해에서 시작된다는 점을 알 수 있었다.

3 UI와 UX의 차이

1) UI

    (1) UI의 의미
    UI는 User Interface의 줄임말이다.
    사용자가 서비스를 사용할 때 직접 보고 클릭하는 화면 요소를 의미한다.

    (2) UI 요소
    버튼, 메뉴, 입력창, 아이콘, 색상, 폰트, 레이아웃 등이 UI에 해당한다.
    사용자는 UI를 통해 서비스와 상호작용한다.

    (3) UI의 핵심
    UI는 사용자가 기능을 쉽게 찾고 사용할 수 있도록 화면을 구성하는 것이다.
    보기 좋은 디자인도 중요하지만, 사용하기 쉬운 구조가 더 중요하다.

2) UX

    (1) UX의 의미
    UX는 User Experience의 줄임말이다.
    사용자가 서비스를 이용하면서 느끼는 전체 경험을 의미한다.

    (2) UX의 범위
    UX는 화면 디자인뿐만 아니라 사용자의 감정, 행동 흐름, 불편함, 만족감까지 포함한다.
    사용자가 서비스를 처음 발견하고, 가입하고, 기능을 사용하고, 다시 돌아오는 전체 과정이 UX에 해당한다.

    (3) UX의 핵심
    UX는 사용자가 원하는 목표를 편하고 자연스럽게 달성할 수 있도록 만드는 것이다.
    사용자가 중간에 막히거나 헷갈리지 않도록 흐름을 설계해야 한다.

3) UI와 UX의 관계

    (1) UI는 UX의 일부이다
    UI는 사용자가 직접 만나는 화면이고, UX는 그 화면을 포함한 전체 경험이다.
    좋은 UI는 좋은 UX를 만드는 데 중요한 역할을 한다.

    (2) 예시
    버튼이 예쁘게 생겼더라도 사용자가 어디를 눌러야 할지 모르면 좋은 UX라고 할 수 없다.
    반대로 화면이 단순하더라도 사용자가 원하는 기능을 빠르게 찾고 사용할 수 있다면 좋은 UX가 될 수 있다.

4 페르소나

1) 페르소나의 의미

    (1) 페르소나
    페르소나는 서비스를 사용할 대표 사용자를 구체적인 인물처럼 설정한 것이다.
    실제 사용자를 상상하기 쉽게 이름, 상황, 목표, 문제점 등을 정리한다.

    (2) 페르소나를 만드는 이유
    모든 사용자를 막연하게 생각하면 서비스 방향이 흐려질 수 있다.
    특정 사용자를 구체적으로 설정하면 그 사람이 어떤 기능을 필요로 하는지 더 명확하게 알 수 있다.

    (3) 개발자 관점에서의 의미
    개발자는 기능 중심으로 생각하기 쉽지만, 페르소나를 만들면 사용자 중심으로 사고할 수 있다.
    “이 기능이 필요한가?”보다 “이 사용자가 이 기능을 왜 필요로 하는가?”를 생각하게 된다.

2) 오늘 설정한 페르소나

    (1) 페르소나 이름
    오늘 설계한 CodeMate의 페르소나는 초보 개발자 현우이다.

    (2) 페르소나 상황
    현우는 개발 공부를 막 시작한 입문자이다.
    실습 중 에러가 자주 발생하고, 해결 방법을 검색해서 해결하더라도 나중에 다시 기억하지 못하는 문제가 있다.

    (3) 페르소나 문제
    현우는 에러 원인을 파악하기 어렵고, 공부한 내용을 체계적으로 정리하기 힘들어한다.
    또한 개념 정리, 실습 코드, 에러 해결 과정을 따로 관리하다 보니 복습이 어렵다.

    (4) 페르소나 목표
    현우는 자신이 배운 개념, 실습 기록, 에러 해결 방법을 한곳에 정리하고 싶어 한다.
    나중에 같은 문제가 발생했을 때 빠르게 검색하고 다시 복습할 수 있는 서비스를 원한다.

5 고객 여정 지도

1) 고객 여정 지도의 의미

    (1) 고객 여정 지도
    고객 여정 지도는 사용자가 서비스를 이용하는 전체 과정을 단계별로 정리한 것이다.
    사용자가 어떤 행동을 하고, 어떤 생각을 하며, 어떤 불편함을 느끼는지 한눈에 볼 수 있게 만든다.

    (2) 구성 요소
    고객 여정 지도에는 단계, 행동, 생각, 접점, 문제점, 개선 기회 등이 들어간다.

    (3) 사용하는 이유
    고객 여정 지도를 만들면 사용자가 어디에서 불편함을 느끼는지 알 수 있다.
    그리고 그 불편함을 해결하기 위해 어떤 기능이 필요한지 도출할 수 있다.

2) 오늘 만든 고객 여정 단계

    (1) 1단계 문제 인식
    사용자는 실습 중 에러를 만나고, 원인을 파악하지 못해 어려움을 느낀다.
    해결 방법을 검색하지만 어떤 자료가 정확한지 판단하기 어렵다.

    (2) 2단계 서비스 탐색
    사용자는 개발 공부 기록 서비스를 검색하고 여러 서비스를 비교한다.
    개념과 에러를 함께 정리할 수 있는 서비스가 필요하다고 느낀다.

    (3) 3단계 가입 및 첫 사용
    사용자는 회원가입을 하고 과목별 카테고리를 만든다.
    처음에는 기능이 많아 어디서부터 써야 할지 고민할 수 있다.

    (4) 4단계 학습 기록
    사용자는 오늘 배운 개념, 실습 코드, 에러와 해결 방법을 기록한다.
    기록을 저장하면서 나중에 다시 복습할 수 있다는 안정감을 느낀다.

    (5) 5단계 복습 및 지속 사용
    사용자는 이전 기록을 검색하고 복습 알림을 확인한다.
    자신의 학습 진도와 약점을 확인하면서 지속적으로 학습을 관리한다.

6 사이트맵

1) 사이트맵의 의미

    (1) 사이트맵
    사이트맵은 서비스의 전체 메뉴 구조를 정리한 지도이다.
    사용자가 어떤 메뉴를 통해 어떤 기능으로 이동할 수 있는지 보여준다.

    (2) 필요한 이유
    사이트맵을 만들면 서비스의 정보 구조를 먼저 정리할 수 있다.
    화면을 만들기 전에 어떤 기능이 어디에 위치해야 하는지 정할 수 있다.

    (3) 개발자 관점에서의 의미
    사이트맵은 나중에 페이지 구조, URL 설계, Controller 설계와도 연결될 수 있다.
    즉, UI/UX 설계뿐만 아니라 실제 개발 구조를 잡는 데도 도움이 된다.

2) CodeMate 사이트맵 구조

    (1) 홈
    홈은 서비스의 시작점이다.
    사용자는 홈에서 주요 기능으로 이동할 수 있다.

    (2) 대시보드
    대시보드에서는 학습 현황 요약, 최근 학습 기록, 복습 알림, 진도 통계, 약점 분석 요약을 확인할 수 있다.
    사용자가 현재 자신의 학습 상태를 한눈에 파악하는 공간이다.

    (3) 과목 관리
    과목 관리에서는 과목 목록, 과목 추가, 과목별 설정, 카테고리와 태그 관리를 할 수 있다.
    초보 개발자가 Java, Spring, SQL처럼 과목별로 학습 내용을 정리할 수 있게 돕는다.

    (4) 학습 기록
    학습 기록은 개념 정리와 실습 기록으로 나누었다.
    개념 목록, 개념 작성, 개념 상세 보기와 실습 목록, 실습 작성, 코드 저장, 파일 첨부, 실습 상세 보기 기능을 포함한다.

    (5) 에러 기록
    에러 기록에서는 에러 목록, 에러 작성, 에러 상세 보기, 해결 방법 정리, 관련 실습과 개념 연결 기능을 제공한다.
    초보 개발자가 같은 에러를 반복해서 검색하지 않도록 돕는 핵심 메뉴이다.

    (6) 복습 관리
    복습 관리에서는 복습 목록, 복습 계획 설정, 복습 알림 설정, 복습 진행, 복습 완료 기록을 관리한다.
    기록한 내용을 실제 학습 성과로 연결하기 위한 기능이다.

    (7) 검색
    검색 메뉴에서는 통합 검색, 개념 검색, 에러 검색, 코드 검색, 태그 검색을 제공한다.
    사용자가 과거 기록을 빠르게 찾을 수 있도록 돕는다.

    (8) 마이페이지
    마이페이지에서는 프로필 관리, 학습 목표 설정, 알림 설정, 데이터 백업과 내보내기, 로그아웃 기능을 제공한다.

7 와이어프레임

1) 와이어프레임의 의미

    (1) 와이어프레임
    와이어프레임은 실제 디자인을 하기 전에 화면의 구조를 간단하게 설계한 것이다.
    색상이나 세부 디자인보다 버튼, 메뉴, 콘텐츠 위치를 먼저 정리한다.

    (2) 필요한 이유
    와이어프레임을 만들면 화면에 어떤 정보가 들어가야 하는지 미리 확인할 수 있다.
    개발 전에 화면 흐름을 점검할 수 있어 불필요한 수정도 줄일 수 있다.

    (3) 개발자 관점에서의 의미
    와이어프레임은 프론트엔드 구현 전에 화면 구조를 이해하는 데 도움이 된다.
    어떤 컴포넌트가 필요한지, 어떤 데이터가 화면에 표시되어야 하는지 미리 파악할 수 있다.

2) CodeMate 와이어프레임 설계 방향

    (1) 주요 화면 설계
    고객 여정 지도와 사이트맵을 바탕으로 주요 화면 구조를 설계했다.
    대시보드, 학습 기록, 에러 기록, 복습 관리, 검색, 마이페이지가 핵심 화면이 된다.

    (2) 화면 설계 기준
    초보 개발자가 처음 사용해도 헷갈리지 않도록 메뉴를 명확하게 나누는 것이 중요하다고 생각했다.
    특히 에러 기록과 학습 기록을 분리하면서도 서로 연결될 수 있도록 설계했다.

    (3) 핵심
    와이어프레임은 예쁜 화면을 만드는 단계가 아니라, 사용자가 기능을 어떻게 찾고 사용할지 구조를 잡는 단계이다.

8 프로토타입

1) 프로토타입의 의미

    (1) 프로토타입
    프로토타입은 실제 서비스처럼 화면을 클릭하고 이동해볼 수 있도록 만든 시안이다.
    완성된 서비스는 아니지만, 사용자 흐름을 미리 체험할 수 있다.

    (2) 필요한 이유
    프로토타입을 만들면 화면 이동이 자연스러운지, 사용자가 기능을 쉽게 찾을 수 있는지 확인할 수 있다.
    개발 전에 문제점을 발견하고 수정할 수 있다는 장점이 있다.

    (3) 오늘 제출 내용
    오늘은 Figma Make를 활용해 CodeMate 모바일 앱 디자인 프로토타입을 제작하고 링크를 제출했다.
    이를 통해 기획 내용을 단순 문서로만 정리하는 것이 아니라 실제 앱 화면 흐름에 가깝게 표현해보았다.

9 CodeMate 서비스 기획

1) CodeMate

    (1) 서비스 이름
    오늘 기획한 앱 이름은 CodeMate이다.
    CodeMate는 코딩 공부를 함께 도와주는 친구라는 의미를 담은 이름이다.

    (2) 서비스 목적
    CodeMate는 초보 개발자가 공부한 개념, 실습 코드, 에러 해결 과정을 한곳에 기록하고 관리할 수 있도록 돕는 모바일 앱이다.

    (3) 주요 사용자
    주요 사용자는 개발 공부를 시작한 입문자이다.
    실습 중 에러를 자주 만나고, 개념 정리와 복습에 어려움을 느끼는 사용자를 대상으로 한다.

    (4) 해결하려는 문제
    초보 개발자는 에러가 발생했을 때 원인을 바로 파악하기 어렵다.
    또한 해결하더라도 기록하지 않으면 같은 문제를 반복해서 검색하게 된다.
    CodeMate는 그런 문제를 줄이고, 학습 기록을 복습 가능한 자산으로 만들기 위해 설계했다.

2) 주요 기능

    (1) 학습 기록
    사용자가 배운 개념과 실습 내용을 기록할 수 있다.

    (2) 에러 기록
    에러 메시지, 원인, 해결 방법을 기록할 수 있다.

    (3) 코드 저장
    실습 코드나 중요한 코드 조각을 저장할 수 있다.

    (4) 복습 관리
    기록한 내용을 다시 복습할 수 있도록 알림과 복습 목록을 제공한다.

    (5) 검색
    개념, 에러, 코드, 태그를 기준으로 이전 기록을 검색할 수 있다.

    (6) 대시보드
    학습 현황, 최근 기록, 복습 알림, 진도 통계, 약점 분석을 한눈에 보여준다.

10 고객 여정 지도 설계 내용

1) 문제 인식 단계

    (1) 행동
    사용자는 수업 후 혼자 실습을 진행한다.
    실습 중 에러가 발생하면 에러 메시지를 확인하고 인터넷 검색이나 질문을 통해 해결하려고 한다.

    (2) 생각
    사용자는 왜 에러가 나는지 모르겠다고 느낀다.
    같은 에러를 또 만나면 어떻게 해야 할지 걱정한다.

    (3) 문제점
    에러 원인을 파악하기 어렵다.
    해결 방법을 찾아도 금방 잊어버린다.
    공부한 내용을 체계적으로 정리하기 힘들다.

    (4) 개선 기회
    에러 메시지 자동 저장 기능, 자주 발생하는 에러 가이드, 해결 방법 기록 UX가 필요하다.

2) 서비스 탐색 단계

    (1) 행동
    사용자는 개발 공부 기록 서비스를 검색한다.
    여러 서비스를 비교하고 리뷰와 기능을 확인한다.

    (2) 생각
    사용자는 개념과 에러를 함께 정리하고 싶다고 느낀다.
    개발 공부에 특화된 서비스가 필요하다고 생각한다.

    (3) 문제점
    일반 메모 앱은 개발 공부를 정리하기에 불편하다.
    어떤 서비스를 선택해야 할지 고민된다.

    (4) 개선 기회
    개발 과목별 템플릿, 실습 사용자 후기, 검색 최적화와 기능 비교 페이지를 제공할 수 있다.

3) 가입 및 첫 사용 단계

    (1) 행동
    사용자는 회원가입을 하고 과목별 카테고리를 만든다.
    기본 기능을 둘러본다.

    (2) 생각
    사용자는 과목별로 정리하니 편하다고 느낄 수 있다.
    하지만 처음에는 어떻게 써야 할지 모를 수 있다.

    (3) 문제점
    처음 사용자가 무엇을 적어야 할지 모른다.
    기능이 많아 초반에 복잡하게 느껴질 수 있다.

    (4) 개선 기회
    온보딩 튜토리얼, 초보자용 작성 예시, 카테고리 추천 기능이 필요하다.

4) 학습 기록 단계

    (1) 행동
    사용자는 오늘 배운 개념을 정리한다.
    실습 코드를 저장하고, 에러와 해결 방법을 기록한다.

    (2) 생각
    사용자는 나중에 다시 보면 도움이 되겠다고 느낀다.
    코드를 함께 저장하니 이해가 잘 된다고 느낀다.

    (3) 문제점
    기록이 많아지면 찾기 어렵다.
    코드와 설명을 따로 관리하면 불편하다.
    에러 기록 양식이 없으면 정리하기 힘들다.

    (4) 개선 기회
    태그, 즐겨찾기, 폴더 기능을 제공할 수 있다.
    코드와 설명 동시 저장 UI, 에러 기록 입력 가이드도 필요하다.

5) 복습 및 지속 사용 단계

    (1) 행동
    사용자는 이전 기록을 검색해 복습한다.
    복습 알림을 확인하고 학습 진도와 약점을 확인한다.

    (2) 생각
    사용자는 전에 정리한 내용을 바로 찾을 수 있어 편하다고 느낀다.
    자신의 약한 부분을 확인하고 스스로 문제를 해결할 수 있다고 느낀다.

    (3) 문제점
    복습할 내용을 직접 기억해야 하면 부담스럽다.
    어떤 부분이 약한지 파악하기 어렵다.
    꾸준히 사용하지 않으면 기록이 쌓이지 않는다.

    (4) 개선 기회
    복습 알림과 스페이스드 리피티션을 적용할 수 있다.
    학습 진도 대시보드, 약점 분석, 성취감 요소를 제공하면 지속 사용에 도움이 된다.

11 사이트맵 설계 내용

1) 전체 메뉴 구조

    (1) 홈
    홈은 전체 서비스의 시작 지점이다.
    사용자는 홈에서 대시보드, 과목 관리, 학습 기록, 에러 기록, 복습 관리, 검색, 마이페이지로 이동할 수 있다.

    (2) 대시보드
    대시보드는 사용자의 학습 상태를 요약해서 보여준다.
    학습 현황 요약, 최근 학습 기록, 복습 알림, 진도 통계, 약점 분석 요약 기능이 포함된다.

    (3) 과목 관리
    과목 관리는 학습 내용을 과목별로 분류하기 위한 메뉴이다.
    과목 목록, 과목 추가, 과목별 설정, 카테고리와 태그 관리 기능이 있다.

    (4) 학습 기록
    학습 기록은 개념 정리와 실습 기록으로 나뉜다.
    개념 목록, 개념 작성, 개념 상세 보기와 실습 목록, 실습 작성, 코드 저장, 파일 첨부, 실습 상세 보기 기능을 포함한다.

    (5) 에러 기록
    에러 기록은 개발자가 실습 중 만난 문제를 정리하는 메뉴이다.
    에러 목록, 에러 작성, 에러 상세 보기, 해결 방법 정리, 관련 실습과 개념 연결 기능을 제공한다.

    (6) 복습 관리
    복습 관리는 기록한 내용을 다시 학습하도록 돕는 메뉴이다.
    복습 목록, 복습 계획 설정, 복습 알림 설정, 복습 진행, 복습 완료 기록 기능이 있다.

    (7) 검색
    검색은 쌓인 기록을 빠르게 찾기 위한 메뉴이다.
    통합 검색, 개념 검색, 에러 검색, 코드 검색, 태그 검색 기능이 포함된다.

    (8) 마이페이지
    마이페이지는 개인 설정을 관리하는 메뉴이다.
    프로필 관리, 학습 목표 설정, 알림 설정, 데이터 백업과 내보내기, 로그아웃 기능을 제공한다.

2) 사이트맵 설계 핵심

    (1) 고객 여정과 연결
    사이트맵은 고객 여정 단계와 연결되도록 설계했다.
    문제 인식 단계에서는 홈과 대시보드, 서비스 탐색 단계에서는 기능 소개, 가입 및 첫 사용 단계에서는 과목 관리와 마이페이지가 연결된다.
    학습 기록 단계에서는 학습 기록과 에러 기록, 복습 단계에서는 복습 관리와 검색이 중심이 된다.

    (2) 기능 분류
    기능을 단순히 많이 넣는 것이 아니라 사용자의 흐름에 맞게 분류했다.
    학습을 시작하고, 기록하고, 다시 찾고, 복습하는 흐름이 자연스럽게 이어지도록 구성했다.

    (3) 설계 핵심 포인트
    초보 개발자의 학습 흐름인 문제 인식, 탐색, 사용, 기록, 복습에 맞춰 메뉴 구조를 구성했다.
    학습 기록과 에러 기록을 중심 기능으로 배치하고, 복습과 검색 기능을 강화했다.
    대시보드에서 학습 현황을 한눈에 파악할 수 있도록 설계했다.

12 Figma 프로토타입 제작 및 제출

1) Figma Make 활용

    (1) Figma Make
    오늘은 Figma Make를 활용해 CodeMate 모바일 앱 디자인을 제작했다.
    텍스트로 서비스의 목적과 화면 구성을 입력하고, 이를 바탕으로 모바일 앱 화면을 생성했다.

    (2) 모바일 앱 디자인
    CodeMate는 모바일 앱 형태로 설계했다.
    초보 개발자가 수업 중이나 실습 중에도 빠르게 기록하고 다시 찾아볼 수 있도록 모바일 접근성을 고려했다.

    (3) 프로토타입 제출
    최종적으로 Figma 프로토타입 링크를 제출했다.

    제출 링크:
    https://www.figma.com/make/Nky04gDXffrrrjs8T3gaks/CodeMate-Mobile-App-Design?code-node-id=0-9&p=f&t=OKhu83fVdf9OX1nS-0&fullscreen=1

2) 프로토타입 제작의 의미

    (1) 기획을 화면으로 구체화
    고객 여정 지도와 사이트맵은 사용자의 흐름과 기능 구조를 정리하는 단계이다.
    프로토타입은 이 구조를 실제 화면처럼 볼 수 있게 만드는 단계이다.

    (2) 사용자 흐름 확인
    프로토타입을 통해 사용자가 홈에서 대시보드, 학습 기록, 에러 기록, 복습 관리로 이동하는 흐름을 확인할 수 있다.
    화면 간 연결이 자연스러운지 점검할 수 있다는 점에서 의미가 있었다.

    (3) 개발 전 검증
    프로토타입을 먼저 만들면 실제 개발 전에 화면 구조와 기능 흐름을 검토할 수 있다.
    개발 후 수정하는 것보다 기획 단계에서 문제를 발견하고 수정하는 것이 훨씬 효율적이다.

13 오늘 학습한 핵심 정리

1) 페르소나

    (1) 페르소나는 대표 사용자를 구체화하는 과정이다.
    (2) 사용자의 상황, 목표, 문제점을 정리해 서비스 방향을 잡는다.
    (3) 오늘은 에러 앞에서 멈추는 초보 개발자 현우를 페르소나로 설정했다.

2) 고객 여정 지도

    (1) 고객 여정 지도는 사용자가 서비스를 이용하는 전체 과정을 단계별로 정리한 것이다.
    (2) 행동, 생각, 접점, 문제점, 개선 기회를 함께 정리한다.
    (3) 사용자가 어느 지점에서 불편을 느끼는지 파악할 수 있다.

3) 사이트맵

    (1) 사이트맵은 서비스의 전체 메뉴 구조를 정리한 것이다.
    (2) 사용자가 어떤 메뉴를 통해 어떤 기능으로 이동하는지 보여준다.
    (3) 개발 관점에서는 페이지 구조와 기능 구조를 잡는 데 도움이 된다.

4) 와이어프레임

    (1) 와이어프레임은 화면의 기본 구조를 설계하는 단계이다.
    (2) 색상이나 디자인보다 메뉴, 버튼, 콘텐츠 배치를 먼저 정리한다.
    (3) 개발 전에 화면 흐름과 필요한 기능을 확인할 수 있다.

5) 프로토타입

    (1) 프로토타입은 실제 서비스처럼 화면 이동을 체험할 수 있는 시안이다.
    (2) 개발 전에 사용 흐름을 검증할 수 있다.
    (3) 오늘은 Figma Make를 활용해 CodeMate 모바일 앱 프로토타입 링크를 제출했다.

6) CodeMate

    (1) CodeMate는 초보 개발자를 위한 학습 관리 앱이다.
    (2) 개념 정리, 실습 코드, 에러 기록, 복습 관리를 핵심 기능으로 설계했다.
    (3) 사용자가 같은 에러를 반복해서 검색하지 않고, 자신의 기록을 학습 자산으로 만들 수 있도록 기획했다.

7) 오늘 배운 점

    (1) UI/UX는 디자인만의 문제가 아니다
    오늘 특강을 통해 UI/UX는 단순히 화면을 예쁘게 만드는 것이 아니라 사용자의 문제를 해결하는 과정이라는 것을 알게 되었다.

    (2) 개발 전 사용자 이해가 중요하다
    기능을 만들기 전에 사용자가 어떤 상황에서 어떤 문제를 겪는지 먼저 파악해야 한다.
    페르소나와 고객 여정 지도는 그 과정을 도와주는 도구이다.

    (3) 사이트맵은 개발 구조와도 연결된다
    사이트맵을 만들면서 메뉴 구조가 곧 페이지 구조와 기능 구조로 이어질 수 있다는 것을 알게 되었다.
    이는 나중에 실제 웹 개발을 할 때 Controller, URL, View 설계와도 연결될 수 있다.

    (4) 초보 개발자 서비스의 핵심은 기록과 복습이다
    초보 개발자는 에러를 해결해도 다시 잊어버리기 쉽다.
    그래서 단순 기록 기능뿐만 아니라 검색, 복습 알림, 대시보드, 약점 분석 기능이 중요하다고 생각했다.

    (5) Figma 프로토타입을 통해 기획이 더 구체화되었다
    처음에는 막연히 개발 공부를 도와주는 서비스라고 생각했지만, 페르소나, 고객 여정 지도, 사이트맵, 와이어프레임을 거치면서 필요한 기능과 화면 구조가 구체화되었다.
    마지막으로 Figma Make를 활용해 CodeMate 모바일 앱 프로토타입을 만들고 제출하면서 아이디어가 실제 서비스 화면 흐름으로 이어지는 과정을 경험할 수 있었다.

[2026.06.23] - TIL 57일차(Spring MVC03 게시판 프로젝트 완성)

buckwheat — Thu, 25 Jun 2026 02:52:34 +0900

목차
1 Spring MVC 프로젝트 구조
2 MyBatis를 활용한 게시판 구현
3 View(JSP) 작성
4 Spring 설정 파일
5 프로젝트 실행 흐름
6 오류 해결 과정

1 Spring MVC 프로젝트 구조

1) Spring MVC 패턴 이해

Spring MVC는 프로젝트를 역할별로 분리하여 개발하는 구조이다.

사용자의 요청을 Controller가 받고, 실제 업무는 Biz(Service)에서 처리하며, 데이터베이스 작업은 DAO가 담당한다.

데이터는 DTO를 이용하여 전달하고, 화면은 JSP가 담당한다.

즉 하나의 요청이 아래와 같은 순서로 진행된다.

사용자 → Controller → Biz(Service) → DAO → MyBatis → Oracle Database → DAO → Biz → Controller → JSP

MVC 구조를 사용하는 이유는 각각의 역할을 분리하여 유지보수와 확장이 쉬워지기 때문이다.

2) 프로젝트 전체 구조

프로젝트에서 사용한 주요 패키지는 다음과 같다.

com.mvc.upgrade

HomeController

com.mvc.upgrade.model.biz

BoardBiz
BoardBizImpl

com.mvc.upgrade.model.dao

BoardDao
BoardDaoImpl

com.mvc.upgrade.model.dto

BoardDto

resources

board-mapper.xml

WEB-INF/views

mvclist.jsp
mvcdetail.jsp
mvcinsert.jsp
mvcupdate.jsp

2 MyBatis를 활용한 게시판 구현

1) DTO

DTO(Data Transfer Object)는 데이터만 저장하는 객체이다.

게시글 번호, 작성자, 제목, 내용, 작성일을 하나의 객체로 관리한다.

BoardDto에는

myno
myname
mytitle
mycontent
mydate

필드가 존재하며 getter/setter를 이용하여 값을 저장하고 가져온다.

2) DAO

DAO(Data Access Object)는 데이터베이스와 직접 통신하는 객체이다.

이번 프로젝트에서는 SqlSessionTemplate을 이용하여 MyBatis의 SQL을 실행하였다.

대표적인 메서드는 다음과 같다.

selectList()
selectOne()
insert()
update()
delete()

DAO는 SQL을 직접 작성하지 않고 Mapper의 SQL을 호출하는 역할만 담당한다.

3) Biz(Service)

Biz 계층은 Controller와 DAO 사이에서 동작한다.

Controller가 DAO를 직접 호출하지 않고 Biz를 거쳐서 데이터를 처리하도록 만든다.

이 구조를 사용하는 이유는

업무 로직 분리
유지보수 향상
기능 추가 시 수정 범위 최소화

때문이다.

현재 프로젝트에서는 DAO 메서드를 그대로 호출하는 형태로 구현하였다.

4) Controller

Controller는 사용자의 요청을 가장 먼저 받는 객체이다.

예를 들어

list.do

요청이 들어오면

BoardBiz의 selectList()

메서드를 호출하여 게시글 목록을 가져온다.

가져온 데이터를 Model에 저장한 후

mvclist.jsp

화면으로 전달한다.

사용자 요청 → Controller → Biz → DAO → Database → JSP

순서로 실행된다.

5) Mapper(XML)

MyBatis에서는 SQL을 XML 파일에 작성한다.

board-mapper.xml 안에는

select

insert

update

delete

SQL이 모두 작성되어 있다.

DAO에서는

myboard.selectList

처럼 namespace와 id만 호출하면 된다.

SQL과 Java 코드가 분리되어 유지보수가 쉬워진다.

3 View(JSP) 작성

1) 목록 화면

mvclist.jsp

게시글 목록을 출력하는 화면이다.

JSTL의

forEach

를 이용하여 게시글을 반복 출력하였다.

또한

상세보기
글쓰기

버튼을 추가하여 페이지 이동이 가능하도록 구현하였다.

2) 상세보기 화면

mvcdetail.jsp

선택한 게시글 하나를 출력한다.

작성자

제목

내용

을 보여주며

수정

삭제

버튼을 통해 다음 작업을 수행할 수 있도록 구성하였다.

3) 글 작성 화면

mvcinsert.jsp

새로운 게시글을 입력하는 화면이다.

사용자가 입력한 데이터를 Controller로 전송하여

insert()

메서드를 실행한다.

저장이 완료되면

list.do

로 이동하여 전체 게시글을 다시 조회한다.

4) 글 수정 화면

mvcupdate.jsp

기존 게시글의 정보를 화면에 출력한 후 수정할 수 있도록 구현하였다.

게시글 번호는 hidden으로 전달하고

작성자

제목

내용

만 수정 가능하도록 구성하였다.

4 Spring 설정 파일

1) applicationContext.xml

Spring에서 공통으로 사용하는 Bean을 등록하는 파일이다.

여기서는

DataSource
SqlSessionFactory
SqlSessionTemplate

을 등록하였다.

MyBatis와 Oracle을 연결하는 가장 중요한 설정 파일이다.

2) servlet-context.xml

Spring MVC 관련 설정을 담당한다.

대표적으로

Controller 검색
ViewResolver
Component Scan

등을 설정하였다.

Controller를 자동으로 찾아 Bean으로 등록하도록 설정하였다.

3) web.xml

웹 프로젝트의 시작점이다.

여기서는

DispatcherServlet

CharacterEncodingFilter

를 등록하였다.

CharacterEncodingFilter를 이용하여 UTF-8 인코딩이 적용되도록 설정하였다.

4) MyBatis config.xml

MyBatis의 전체 설정 파일이다.

여기서

typeAlias

mapper

를 등록하였다.

Mapper XML을 MyBatis가 읽을 수 있도록 연결하는 역할을 수행한다.

5 프로젝트 실행 흐름

브라우저에서 list.do 요청 → HomeController → BoardBiz → BoardDao → SqlSessionTemplate → board-mapper.xml → Oracle Database → 조회 결과 반환 → Model 저장 → mvclist.jsp → 게시글 목록 출력

Spring MVC에서는 사용자의 요청이 이러한 흐름으로 처리된다.

6 오류 해결 과정

프로젝트를 완성하면서 여러 가지 오류를 해결하였다.

① HTTP 404 오류

프로젝트가 Tomcat에 정상적으로 배포되지 않아 발생하였다.

프로젝트를 Maven Project로 설정하고 Server에 다시 등록하여 해결하였다.

② CharacterEncodingFilter 오류

encoding 값에

true

가 들어가 있어

UTF-8

로 수정하였다.

③ SqlSessionTemplate Bean 오류

No qualifying bean of type SqlSessionTemplate

오류가 발생하였다.

원인은 applicationContext.xml에서 Bean 이름과 참조 이름이 일치하지 않았기 때문이다.

SqlSessionFactory와 SqlSessionTemplate 설정을 수정하여 해결하였다.

④ Spring 버전 충돌

Spring 5 프로젝트에서

spring-orm 7.x

를 사용하고 있어 Bean 생성 오류가 발생하였다.

Spring Framework 버전을 모두 5.3.x로 통일하여 해결하였다.

오늘 배운 내용

이번 프로젝트에서는 Spring MVC와 MyBatis를 이용하여 게시판 CRUD 프로젝트를 완성하였다.

MVC 구조에서 Controller, Biz, DAO, DTO의 역할을 이해하였고, MyBatis Mapper를 이용하여 SQL을 분리하는 방법을 학습하였다.

또한 JSP 화면 작성부터 Spring 설정 파일, Oracle 연동, 오류 해결까지 하나의 프로젝트를 완성하는 전체 흐름을 경험할 수 있었다.

이번 프로젝트를 통해 Spring MVC 프로젝트가 실제로 어떻게 동작하는지 전체 구조를 이해할 수 있었으며, 앞으로 REST API나 Spring Boot를 학습하기 위한 기초를 다질 수 있었다.

메밀이의 공부일기

[26.07.06-26.07.09] TIL 15주차 정리

[2026.07.09] - TIL 69일차 (Spring Security와 로그인 구현)

1. Spring Security 의존성 추가

2. 게시판 Entity와 JPA

3. Repository와 Service

4. 게시글 목록, 등록, 상세 조회

5. 회원 Entity와 회원가입

6. BCrypt 비밀번호 암호화

7. UserDetailsService

8. SecurityFilterChain

9. 로그인 처리 흐름

10. ddl-auto 설정

정리

[2026.07.08] - TIL 68일차 (Spring Data JPA로 게시판 CRUD 구현하기)

1. JPA 프로젝트 설정

2. Entity 클래스

3. Repository와 JpaRepository

4. findBy 메서드 규칙

5. JPQL에서 주의할 점

6. Controller CRUD 흐름

7. save()의 insert/update 판단

8. Thymeleaf 화면 처리

9. 개인적으로 추가해본 삭제 알림

정리

[2026.07.07] - TIL 67일차 (JSP 게시판을 Thymeleaf로 전환하기)

1. JSP와 Thymeleaf의 차이

2. Thymeleaf 기본 선언

3. 목록 페이지 구현

4. ${}와 @{} 차이

5. 상세 페이지 구현

6. 등록 페이지 구현

7. 수정 페이지 구현

8. JavaScript에서 Thymeleaf 값 사용

정리

[2026.07.06] - TIL 66일차 (Spring Boot 게시판 보완과 Thymeleaf 시작)

1. StartBoot02 게시판 구조 보완

2. Filter 설정

3. Interceptor 설정

4. StartBoot03과 Thymeleaf 시작

5. Thymeleaf 유틸리티 객체

6. Thymeleaf 조건문과 반복문

정리

[26.06.29-26.07.03] TIL 14주차 정리

Spring MVC부터 Spring Boot JDBC까지 한 주 정리

1. Spring MVC 기본 흐름

2. Filter

3. AOP

4. 로그인과 비밀번호 암호화

5. Interceptor

6. Transaction

7. 파일 업로드

8. REST API

9. Spring Boot 시작

10. Spring Boot + JDBC

마무리

[26.06.22-26.06.26] TIL 13주차 정리

[2026.06.25 ~ 2026.06.26] - TIL 59~60일차 MSA 특강 정리

1 MSA란 무엇인가

2 모놀리식 아키텍처와 MSA

3 MSA의 주요 특징

4 MSA 전환 사례

5 MSA를 무조건 선택하면 안 되는 이유

6 MSA 이전 방법론

7 소프트웨어 아키텍처 구성 요소

8 ADR

9 서비스 기반 아키텍처

10 이벤트 기반 아키텍처

11 마이크로서비스 아키텍처

12 DDD와 마이크로서비스 설계

13 이벤트 스토밍

14 아키텍처 도식화와 C4 Model

15 Spring Cloud

16 Docker 기본 개념

17 Docker 주요 실습

18 Docker Swarm

19 Kubernetes

20 Kubernetes 주요 오브젝트

21 Ingress와 Service Mesh

22 CI/CD

4. `${}`와 `@{}` 차이