Search

블로그 게시글

들어가며

AI 코딩 도구(Claude Code, Devin 등)를 실무에서 적극 활용하면서 한 가지 예상치 못한 문제를 발견했다. AI가 코드베이스의 로그 메시지를 "사실"로 받아들여, 잘못된 방향으로 문제를 진단하는 현상이다.

로그가 말하는 것 vs 실제로 일어나는 것

로그는 작성자의 가설이다

로그 메시지는 코드를 작성한 사람이 "이 시점에 이런 일이 일어날 것"이라고 가정한 내용이다. 하지만 시스템이 복잡해지면 그 가설이 틀릴 수 있다.
예를 들어, 분산 스트리밍 환경에서 이런 로그가 있다고 가정하자:
AI 에이전트가 잘못된 로그에 속을 때 — 확증 편향과 로그 정합성
2026/02/01
생각 정리
Devops
키워드 정리중

들어가며

실무에서 사용하는 오픈소스가 요구사항을 "거의" 충족하지만, 딱 하나가 안 되는 경우가 있다. 이때 선택지는 보통 세 가지다:
1.
다른 방식으로 직접 구현
2.
다른 레이어에서 우회
3.
오픈소스를 커스텀
이 글에서는 실제로 오픈소스 커스텀을 선택했던 경험을 바탕으로, 의사결정 프레임워크를 정리한다.

상황: "거의 다 되는데, 하나가 안 된다"

오픈소스를 커스텀해야 할 때 — 의사결정 프레임워크
2026/01/27
아키텍처
생각 정리
키워드 정리중

들어가며

Claude Code를 사이드 프로젝트에서 적극 활용하면서, AI 에이전트가 생산성을 높여주는 동시에 예상치 못한 문제를 일으키는 것을 경험했다. 아키텍처 규칙을 무시하고, 계획 없이 코드를 수정하고, 위험한 명령어를 실행하는 경우가 반복되었다.
이 글에서는 Claude Code의 Hooks 기능을 활용하여 AI 에이전트가 프로젝트 규칙을 따르도록 강제하는 가드레일 시스템을 설계한 경험을 공유한다.
Claude Code Hooks로 AI 에이전트 가드레일 만들기

들어가며

"느리다"는 리포트를 받았을 때, 어디서부터 봐야 할까? 로그? APM? 프로파일러?
가장 빠르고 확실한 방법 중 하나는 Thread Dump다. 특히 Kubernetes Pod 환경에서, APM이 없거나 설정이 안 된 상태에서 즉시 할 수 있는 것이 Thread Dump다.
이 글에서는 JVM 기반 애플리케이션(Spring Boot 등)의 성능 병목을 Thread Dump로 찾는 실전적인 방법을 정리한다.

Thread Dump란?

Thread Dump는 JVM의 모든 스레드가 "지금 이 순간" 무엇을 하고 있는지를 스냅샷으로 찍은 것이다. 각 스레드의 호출 스택(Stack Trace)이 포함되어 있어, 어떤 메서드에서 시간을 소비하고 있는지 알 수 있다.
Thread Dump로 성능 병목을 찾는 실전 가이드
2025/11/01
Spring
운영
Java
키워드 정리중

스팟잇(Spot It!) 사이드 프로젝트 회고

프로젝트 소개

두 마리 토끼를 잡으려는 건 어리석은 발상이다

개발자가 사이드 프로젝트를 통해 얻을 수 있는 것은 다음과 같이 크게 2가지가 있다.
1.
기술적 학습 및 경험
2.
실제로 유의미한 문제를 해결하는 서비스 출시, 나아가 사업화
현직자에게 사이드 프로젝트란
2025/10/23
팀 프로젝트
사이드 프로젝트
작성 완료

계기

우테코하면서 진행한 프로젝트인 데벨업 프로젝트는 원래 서비스 종료 예정이었으나, 서비스 유지를 원하는 팀원이 있어서 목숨만 부지하고 있었다.
이에 인증서 갱신 등의 작업을 주기적으로 해야 하는데, docker 기반의 인프라로 이를 자동화 하는 것은 상당히 귀찮은 일이다. 마침 회사 업무에서 k8s 를 활용하면서 이런 인증서 발급이나 네트워크 설정들을 k8s 환경에서 구축하는 것이 훨씬 쉽다는걸 깨달았고, 이를 적용해보면 신경쓰지 않아도 될 것 같아 길고 긴 추석 연휴에 이 작업을 수행하게 되었다.

설치 과정

arm VM 생성

오라클 클라우드에서는 익히 알려진대로 arm 기반의 vm 을 4코어 CPU, 24 GB 메모리를 평생 무료로 제공해준다. 하지만, 이런 vm 을 프리 티어 계정에서 생성하는 것은 불가능에 가깝다. 정확히 공지된 바는 없지만, 오라클이 프리티어 사용자들이 생성할 수 있는 vm 총량에 제한을 걸어두었고, 2025년 10월인 현재로선 이를 뚫고 vm을 생성할 방법이 없다.
단, 이는 프리티어 한정이고 유료 계정으로 전환하면 생성이 가능하다. 유료 플랜으로 전환한 뒤 무료 할당량만큼만 사용한다면 과금은 발생하지 않는다. 관련 정보를 찾아보면 많은 실패 사례가 나오지만, 다행히 이미 무료 계정을 발급받아서 사용중이었고, 업그레이드도 별 문제 없이 수행되었다. 단, 이때 지급 방법 검증 차원에서 100달러가 결제되었다가 환불되었다. 하마터면 안될뻔..
OCI(오라클 클라우드)에 K3S 인프라 구축하기
2025/10/12
사이드 프로젝트
Devops
k8s
작성 완료
복제 = 데이터를 여러 위치에 중복 저장해서 안정성 높이는거
샤딩 = 대규모 데이터베이스를 작은 단위(샤드)로 나누어 각각을 별도의 서버에서 다루는 방식
즉, 복제본 세트를 여러 샤드로 나누어 관리하게 된다.
복제본 세트는 하나의 주서버와 여러개의 보조 서버로 이루어짐. 주 서버는 모든 쓰기 작업을 담당, 데이터 변경사항을 oplog 에 저장. 보조 서버는 oplog를 참조해 동일한 작업 수행해 데이터 일관성 유지. 주 서버 장애시 자격을 갖춘 보조 서버가 주서버로 선출되는 과정 시작.
몽고 DB는 분산 시스템의 데이터 일관성 보장을 위해 RAFT 합의 알고리즘 사용. 이 알고리즘에 투표 매커니즘 포함되어있음. 투표는 당므 상황에서 발생
•
복제본 세트의 서버 추가 또는 제거
몽고DB 복제 & 샤딩
2025/09/09
키워드 정리중

스팟잇(Spot It!) 사이드 프로젝트 회고

프로젝트 소개

스팟잇(Spot It!)은 팝업 스토어 정보 플랫폼이다. 방문객들은 팝업 정보를 쉽게 확인하고 현장 대기 기능을 활용할 수 있으며, 주최자들은 효과적으로 팝업을 홍보하고 관리할 수 있다.
아직 완성되지 않은 부분이 많지만, 이 글에서는 프로젝트 자체보다는 사이드 프로젝트를 통해 무엇을 배우고자 했고, 실제로 무엇을 얻었는지 공유하려 한다.

사이드 프로젝트를 시작한 이유

1. 빠른 피드백 사이클에 대한 갈증

현직자에게 개발동아리 활동이란
2025/09/02
팀 프로젝트
사이드 프로젝트
작성 완료

감사 로그란?

시스템 상에서 누가, 무엇을, 언제, 어디서, 어떻게 했는지 남긴 기록을 감사 로그라 한다. 쇼핑몰을 운영한다고 생각해보자. 여러명의 쇼핑몰 운영자가 상품을 추가하거나 가격이나 재고 등을 수정할 수 있을 것이다. 이때, 누군가 어떤 상품의 가격을 1원으로 수정했다고 하자. 이건 분명히 쇼핑몰에 엄청난 손해를 가지고 오는 행위다. 그런데, 그걸 어떤 직원이 했는지 알 수 없다면? 정말 난감할 것이다. 또, 쇼핑몰에서 계좌이체, 카드결제, 토스 페이, 카카오 페이, 네이버 페이를 지원한다고 하자. 이런 결제 연동 시스템은 쇼핑몰 입장에선 외부 시스템을 사용하는 것이기 때문에 비용을 내야 한다. 이때, 네이버 페이의 그런데, 실제로는 전체 고객 중 1%만 네이버 페이로 결제하는데 연동 비용이 가장 크다면? 당연히 네이버 페이 연동을 굳이 할 필요가 없을 것이다.
앞서 말한 사례들은 모두 감사 로그를 활용하는 사례들이다. 이런 사례들을 분류하면 크게 4가지 정도로 분류할 수 있다.
•
보안 및 규제 준수: 누가 언제 로그인했는지, 중요한 데이터를 언제 수정했는지 등의 기록을 통해 불법적인 접근이나 비정상적인 활동을 감지하고, GDPR, HIPAA 등 각종 규제 요건을 충족하는 데 필수적입니다. 문제가 발생했을 때 책임 소재를 파악하는 데 결정적인 증거가 됩니다.
•
문제 진단 및 추적: 시스템 오류나 비정상적인 동작이 발생했을 때, 감사 로그를 통해 어떤 순서로 이벤트가 발생했는지를 파악하여 문제의 원인을 신속하게 진단하고 해결할 수 있습니다.
•
운영 모니터링: 시스템의 주요 기능이 어떻게 사용되고 있는지, 특정 기능의 사용 빈도 등을 파적하여 서비스 개선이나 운영 전략 수립에 활용할 수 있습니다.
•
비즈니스 프로세스 검증: 특정 비즈니스 프로세스가 의도한 대로 수행되었는지 확인하고, 누락되거나 잘못된 부분이 없는지 검증하는 데 사용될 수 있습니다.
감사 로그를 남겨보자.
2025/05/25
키워드 정리중

들어가며

100명 규모의 개발 조직에서 공용 라이브러리를 설계하고 배포한 경험이 있다. 혼자 쓰는 유틸리티 클래스를 만드는 것과, 조직 전체가 쓸 라이브러리를 만드는 것은 완전히 다른 종류의 작업이다.
이 글에서는 구체적인 사내 코드를 공개하지 않고, 대규모 조직에서 공용 라이브러리를 설계할 때 고려했던 원칙들을 정리한다.

원칙 1: 사용하는 쪽 코드가 가장 중요하다

라이브러리 내부 구현이 아무리 우아해도, 사용하는 쪽 코드가 복잡하면 실패한 설계다.
100명이 쓰는 라이브러리에서는, "라이브러리 내부 코드 1줄"을 줄이는 것보다 "사용하는 쪽 코드 1줄"을 줄이는 것이 100배 가치가 있다.

Kotlin 확장 함수의 활용

대규모 조직에서 공용 라이브러리를 설계할 때 생각할 것들
2025/04/01
Kotlin
Spring
아키텍처
키워드 정리중

Exposed란

Exposed - 코틀린 SQL 프레임워크

분산 트랜잭션

2PC 패턴

준비(prepare)

분산 트랜잭션에 참여하는 각 참여자(멤버 트랜잭션)에게 커밋할 준비가 되었는지 확인하는 단계다. 이 시점에 멤버 트랜잭션이 관여하는 행이나 테이블에 락이 걸린다.
각 멤버 트랜잭션은 커밋할 수 없는 상태인 경우 커밋할 수 없다는 응답(abort)을 코디네이터에게 응답하고, 커밋이 가능한 경우 가능하다는 응답(prepared)을 한다.
중요한 점은 멤버 트랜잭션의 커밋 가능 여부를 응답하는 것이지, 이 시점에 커밋이나 롤백이 진행되지 않는다는 것이다.
분산 트랜잭션 - 2PC 패턴, Saga 패턴
2024/11/18
CS
면접질문
네트워크
작성 완료
면접 진행 과정에서 코틀린에 대해 아는 것이 있냐는 질문을 받았다. 코틀린은 전에 다른 기업 사전과제가 코틀린으로 작성해야 했기 때문에 문법을 살짝 공부한 적 있었다. 그 과정에서 느낀 현대적인 언어인 코틀린이 주는 편안함이 있었다고 말했다. 그런데 그 과정에서 코틀린과 자바를 함께 사용하는 환경에서 롬복을 사용하는데 문제가 있다는 글을 봤다는 이야기를 했다. 그리고 그 이유를 물어보셨다. 모르겠다고 하니 자바 컴파일 과정을 살펴보면 이유를 알 수 있을것이라 하셨다. 그래서 이 글을 쓴다.

자바 컴파일 과정과 롬복

자바 컴파일 과정을 한발 더 깊게 들어가면 다음과 같이 설명할 수 있다.

AST(Abstract Syntax Tree, 추상 구문 트리)

컴파일러는 본격적인 컴파일 과정 전에 소스 코드에 문법적으로, 의미적으로 문제가 없는지 확인해야 한다. 그리고 이를 위해 소스 코드를 분해해 트리 형태로 만든다. 이를 AST(Abstract Syntax Tree, 추상 구문 트리)라고 부른다. 왜 이런 자료구조를 만드는지는 컴파일러를 다루는 전문 서적이나 강의를 찾아보는 것이 좋을 듯 하다.
아무튼 핵심은 코드를 컴파일하는 과정에서 AST를 만들고 이를 활용해 실제 실행 가능한 명령어 형태로 바꾸는 것이다. 따라서, AST를 조작한다면 컴파일 과정에서 소스코드에는 없는 명령어를 추가하도록 유도할 수 있다.
왜 코틀린과 자바를 같이 쓸 때 롬복이 문제가 되나?
2024/11/16
면접질문
Java
Kotlin
CS
작성 완료
얼마전 어떤 기업의 면접에서 이들의 차이를 질문받았다. 제대로 대답하지 못한 것 같아서 다시 정리해보았다.
블로킹과 논블로킹, 동기와 비동기 개념은 공통적으로 한 주체가 다른 주체에게 작업의 실행을 넘긴 상황을 구분하는 개념이다.

블로킹과 논블로킹

블로킹은 다른 주체가 작업을 끝낼 때까지 작업을 넘긴 주체가 다른 작업을 진행할 수 없는 것을 말한다.
반대로 논블로킹은 작업을 넘긴 주체가 다른 작업을 진행할 수 있는 것을 말한다.
즉, 블로킹과 논블로킹은 작업을 넘긴 주체가 넘긴 작업 말고 다른 작업을 계속 할 수 있는지 여부로 구분된다.
블로킹 논블로킹 동기 비동기
2024/11/15
면접질문
CS
작성 완료

성능 테스트

성능이란

도서 실무로 배우는 시스템 성능 최적화에선 성능을 다음과 같이 정의한다.
고객의 특정 업무를 대상으로 운영환경하에서 고객이 수긍할 수 있는 응답시간 내에 처리할 수 있는 거래량
동일한 도서에서 다음과 같은 구절도 나온다.
응답시간은 사용자의 특성과 환경에 따라 요구하는 수준이 다르므로 동일한 응답 시간에 대해 고객마다 만족도는 다르게 나타난다. 이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 응답시간의 기준은 없다는 것을 의미한다.
또 다른 도서 전문가가 알려주는 웹 퍼포먼스 튜닝에선 부하 테스트의 계획 단계에서 제시한 개요에는 시나리오가 포함된다. 시나리오의 내용은 다음과 같다.
성능 테스트
2024/10/06
팀 프로젝트
프로그래밍 일반
운영
작성 완료

무중단 배포 환경에서 신규 버전의 배포

배포 환경 가정

1.
10대의 WAS 서버가 있다. 한번의 배포란, 특정 빌드 파일을 10대의 서버에 순차적으로 새 버전을 실행시키는 것을 말한다.
2.
데이터베이스는 하나의 Source DB와 하나의 Replication DB로 이중화 되어있다.
3.
데이터베이스의 스키마 변경은 미리 작업을 해두었다. 즉, 데이터베이스는 언제든 구버전의 기능과 신버전의 기능을 위해 준비되어있다.
4.
배포는 각 WAS에 순차적으로 진행되는 Rolling 방식이다.
신규 버전을 배포하기 위해 몇번의 배포가 필요할까?
2024/09/20
면접질문
CS
운영
작성 완료

Redis 보다 HTTP 최적화가 먼저다

더 높은 처리량을 보여주기 위해 별도의 덩치가 큰 기술을 도입하는 경우가 있다. 이는 아마도 덩치 큰 기업들에서 이런 기술을 도입해 자신들이 처한 문제를 해결하는 것을 보았기 때문이다. 그 대표적인 것으로 Redis를 뽑았지만 Redis 말고도 뭐 많다. 하지만, 이런 기술들을 도입하기 전에 기초적인 HTTP 레벨에서의 성능 향상을 꾀하지 않는다면 순서가 잘못된 것이다. 그런 의미에서 이번에 HTTP 레벨에서 성능을 향상시키기 위한 기술들이 무엇이 있는지 알아보았다.

HTTP 성능 최적화

HTTP 압축

Accept-Encoding 헤더를 통해 클라이언트가 수용할 수 있는 압축 알고리즘을 나열한다. 그리고 서버에서 이 알고리즘 중 하나를 선택해서 적용하고 Content-Encoding 헤더를 통해 클라이언트에 알려준다.
대표적인 알고리즘으로 gzip 알고리즘이 있다. 물론 이 알고리즘을 직접 구현할 필요는 없고 서버 프로그램(톰캣, nginx 등)에서 지원하며 이를 설정하면 된다.
HTTP 성능 높이는 방법들

자바의 Thread

자바에서 스레드 기술은 태초의 Thread 클래스에서 부터 시작했다. 이후 이를 한 층 더 추상화하고, 스레드 풀을 쉽게 만들게 해주는 API가 추가되고, 스레드를 외부에서 종료시킬 수 있는 API가 추가되었다. 그리고 자바 스레드 기술의 최신 버전이 Virtual Thread다. 막 어려운 개념은 아니고, Process 로 동시성을 처리하다가 버거워서 Thread가 등장한 것 처럼, Thread로 동시성을 처리하기 버거워서 Virtual Thread가 등장한 것이다. 성능 향상을 불러오는 근본적인 이유도 같다.

Platform Thread

기존의 자바 Thread 인스턴스다. 이들은 운영체제가 제공하는 스레드를 살짝 감싸서 구현된다. 또한, 생성될 때부터 종료될 때까지 운영체제가 제공하는 스레드에 종속된다. 따라서 Platform Thread개수는 자바가 동작하는 운영체제의 OS Thread 개수에 제한된다.
운영체제는 스레드에 독립적인 스택 메모리 공간을 주고 그 외에도 여러 자원을 할당한다. 따라서, Platform Thread를 사용하는 것은 자바가 동작하는 운영체제의 제한에 크게 영향을 받는다. 대신, CPU 위주의 작업이던, IO 위주의 작업 모두 적절히 수행할 수 있다.

Virtual Thread

가상 스레드 역시 Thread 클래스의 인스턴스다. 다만, Platform Thread와 다르게 운영체제 스레드에 종속되지 않는다. 물론 실행은 운영체제의 스레드 위에서 실행된다.
Java Virtual Thread
2024/08/24
Java
CS
면접질문
작성 완료

생각하게 된 계기

기본적인 레지스트리인 도커 허브에선 무료 플랜에선 프라이빗 레지스트리를 하나만 제공한다. 또 다른 서비스인 깃허브 패키지 역시 무료 플랜에선 용량과 트래픽 제한이 있다. 다른 상용 서비스들도 여럿 있지만, 프라이빗 레지스트리를 위해선 돈을 지불해야 한다. 반면, 직접 운영하는 경우 서버 임대 비용을 제외하면 별도의 비용이 발생하지 않는다. 따라서, 직접 레지스트리를 운영하는 방법에 대해 학습할 가치가 있다고 판단했다.

구축 과정

최종적으로 구현된 자체 레지스트리 웹페이지
위와 같은 레지스트리 웹페이지를 만든 과정을 소개한다.
도커 레지스트리 직접 운영하기
2024/08/18
Docker
보안
운영
작성 완료

Spring Data JPA 쓰니까 쿼리가 이상해졌어!

아니 이걸 왜 다 따로 불러와?

Spring Data JPA 를 이용해 사용자의 예약 목록을 조회하는 페이지에 접근했더니 다음과 같은 쿼리들이 발생했다.(스압 주의)
발생한 SQL
자신의 예약 정보를 조회하기 위해서는 그저 예약, 회원, 예약 시간, 테마 테이블을 모두 join 해서 한번에 쿼리를 작성하면 된다. 비록 쿼리가 복잡해지긴 하겠지만, 저 많은 쿼리를 다 따로 데이터베이스에 전송하면서 생기는 오버헤드보다는 아마 나을 것이다.

fetch type

JPA 에서는 @ManyToOne 과 같이 연관관계를 설정하는 어노테이션에 fetch 옵션을 제공해준다. 이 옵션은 FetchType.LAZY 와 FetchType.EAGER 중 하나로 설정할 수 있다.
N + 1 문제의 원인과 해결방법
2024/05/27
Java
우테코
JPA
DB
작성 완료

아니 내 코드 다 지우라고?

우테코 레벨 2 3번째 미션을 수행하면서 기존의 JdbcTemplate을 사용한 코드를 Spring Data JPA를 이용하도록 수정하라는 요구사항을 만났다. 그리고 미션을 소개하는 시간에 코치 브라운이 이렇게 말했다.
아쉽지만 기존에 있던 JdbcTemplate 코드는 지우세요!
꼭 그렇게 다 가져가야만 속이 후련하십니까? ㅠㅠㅠㅠ

어떻게 하면 내 코드를 최대한 덜 바꿀까?

레벨 1때도 비슷한 고민을 했다. 그때는 지금의 코드에 어떤 문제가 있었지만, 코드를 최대한 조금 수정하고 문제를 해결하고 싶어했다. 당시에 코치 구구와 이야기 했었는데 구구는 이런식으로 말했다.
지금 엎는게 제일 쉬운 방법이에요.
JdbcTemplate 를 JPA로 손쉽게 갈아껴보자
2024/05/15
우테코
Java
작성 완료

처음 요청을 처리하는 곳은 DispatcherServlet 이다

HTTP 요청을 택배로 비유한다면 DispatcherServlet 는 물류센터에 비유할 수 있다. “(특별한 요청을 위해)보내다”라는 의미의 Dispatch 라는 단어가 붙은 대로 DispatcherServlet은 HTTP 요청을 처리하는 담당 클래스(= 핸들러)에게 HTTP 요청을 보내는 역할을 한다. Spring MVC 는 HttpServlet 을 이용해 클라이언트의 요청을 처리해 응답한다. DispatcherServlet은 Spring이 HttpServlet 을 구현한 구현체다.

DispatcherServlet이 처리해야 하는 작업들

우리가 @Controller 혹은 @RestController 어노테이션을 이용해 만든 컨트롤러에게 HTTP 요청의 처리를 위임해야 한다. 이를 위해선 다음 작업들이 수행되어야 한다.
1.
어떤 컨트롤러 객체를 사용해야 하는지 결정
2.
어떤 메서드를 사용해야 하는지 결정
3.
메서드를 호출하기 위한 매개변수 생성
Spring Web MVC 동작 구조 - 대체 내 컨트롤러를 어떻게 실행할까?
2024/05/08
Java
우테코
작성 완료

의존

어떤 요소 A가 동작하기 위해서 다른 요소 B가 필요하다면, A가 B를 의존한다.
Ladder가 동작하기 위해서는 List<Line> 이 필요하다. 즉, Laddder는 List와 Line을 의존한다.
정말 간단하게 자바에서 import 하는 모든 것을 의존한다고 보면 된다. 단, 그게 전부는 아니다.
이하의 글에서 A 를 의존을 하는 쪽, B를 의존 대상 이라 표현한다.

주입

의존성 주입
2024/03/23
우테코
프로그래밍 일반
Java
작성 완료

개요

sealed 키워드에 대해 이해하기 위해서는 자바에서 인터페이스와 추상 클래스, 구체 클래스를 이용한 상속 구조를 이해하고 있어야 한다. 이 포스트는 독자가 이를 이미 이해하고 있다고 가정하고 작성했다.
Java 15에 Preview 로 추가되어 Java 17에 정식 기능으로 포함된 상위 클래스(혹은 인터페이스)에서 자신을 상속(구현)하는 클래스(인터페이스)를 제한하는 기능이다.

도입 배경

인터페이스, 추상 클래스, 구체 클래스를 이용한 견고한 코드

사다리 게임 미션의 요구사항 중 사다리에 대한 제약 조건이 있다.
sealed , non-sealed
2024/03/16
Java
우테코
작성 완료
아래 글에서 타입, 클래스, 역할, 책임 등의 용어는 객체지향의 사실과 오해 라는 도서를 참고하자.

객체를 어떻게 분류할 수 있을까?

타입(혹은 클래스)가 역할이 동일한 객체를 모은 집합이라면, DTO, VO의 개념은 여러 타입에 부여된 역할이 얼마나 비슷한지에 따른 분류다.
어떤 객체가 DTO 인가? 라는 질문은 그 객체가 속한 타입이 DTO 라는 분류에 속하는가? 라는 질문을 간단히 표현한 것이다.

어떤 역할을 하는 객체가 DTO 일까?

DTO는 데이터 전달 객체다

DTO 는 Data Transfer Object 의 약자다. 직역하면 데이터 전달 객체이다. 즉, 데이터를 전달하는 역할을 가진 객체를 DTO 라고 부른다.
DTO vs VO
2024/03/08
Java
프로그래밍 일반
작성 완료
Load more