Seon's IT Story

[Software Enginnering] 애자일(Agile) 스크럼 실전: 이벤트와 산출물

H.Sunny,, — Mon, 11 May 2026 17:11:43 +0900

이전 포스팅에서 스크럼 팀을 구성하는 3가지 핵심 역할과 책임을 다루 었다. 그렇다면 이들은 구체적으로 실무에서 어떻게 일할까?

https://hsunnystory.tistory.com/264

[Software Engineering] 애자일(Agile) 스크럼 기초: PO, SM, 개발팀의 명확한 실무 R&R

이전 포스팅([Software Enginnering] 애자일 선언문과 12가지 원칙)에서 강조했듯, 지라(Jira)를 쓰고 스프린트를 도입한다고 해서 곧바로 애자일 팀이 되는 것은 아니다. 시스템 구조가 바뀌려면 근본적

hsunnystory.tistory.com

애자일이 그저 "문서 없이 빨리빨리 개발하자"는 무법 지대가 되지 않도록, 스크럼은 아주 명확하고 규칙적인 이벤트와 산출물을 정의하고 있다. 이번 포스팅에서는 스크럼의 핵심 프로세스들이 어떻게 굴러가는지, 그리고 각 이벤트가 우리의 아키텍처와 코드 품질에 어떤 영향을 미치는지 살펴본다.

1. 스크럼의 심장, 스프린트 (Spring)

스프린트는 보통 1주~4주(실무에서는 2주가 가장 흔함)의 고정된 기간을 가진다. 워터폴 방식이 6개월짜리 거대한 마라톤이라면, 스크럼은 2주짜리 단거리 전력 질주를 반복하며 프로덕트를 점진적으로 완성해 나가는 구조다.

스프린트의 가장 큰 특징은 타임박싱이다. 정해진 기간이 끝나면 기획했던 기능이 100% 완성되지 않았더라도 미련 없이 스프린트를 종료하고 다음 사이클로 넘어간다. 이는 완벽주의에 빠져 일정이 무한정 지연되는 것을 원칙적으로 차단한다.

2. 스크럼의 3가지 핵심 산출물 (Artifacts)

팀이 무엇을 해야 할지, 그리도 현재 상태가 어떤지 시각적으로 보여주는 3가지 중요한 기준점이 존재한다.

프로덕트 백로그 (Procude Backlog)

- 프로덕트에 필요한 모든 요구사항의 총집합이다. PO가 관리하며, 비즈니스 가치가 높은 순서대로 정렬된다.

스프린트 백로그 (Sprint Backlog)

- 이번 스프린트(예:2주) 동안 개발팀이 완료하기로 약속한 작업들의 목록이다.

- 프로덕트 백로그의 상위 항목들을 가져와, 개발자가 실제로 코드를 짤 수 있는 수준의 기술적인 테스트(Task)로 잘게 쪼갠다.

(예: 로그인 기능 -> OAuth2 인증 API 구현, User 테이블 스키마 설계)

인크리먼트 (Increment)

- 스프린트가 끝날 때마다 완성되는 실제로 동작하는 소프트웨어의 조각이다.

- 여기서 가장 중요한 개념이 완료의 정의(Definition of Done, DoD)다. 기준이 명확해야 한다.

(예: 내 로컬에서 잘 도는게 아니라 단위 테스트 커버리지 80% 달성, QA 통과, 스테이징 배포 완료까지가 완료라는 팀 차원의 합의가 필수적이다.)

3. 스크럼의 4가지 핵심 이벤트 (Events)

스프린트라는 2주의 타잉ㅁ박스 안에는 팀의 싱크를 맞추기 위한 4가지 필수 이벤트가 규칙적으로 발생한다.

스프린트 플래닝 (Sprint Planning)

- 목적 : 이번 스프린트에 무엇을, 어떻게 만들것 인가?

- 개발팀은 비즈니스 목표를 달성하기 위해 필요한 백엔드 아키텍쳐, DB 마이그레이션 전략 등을 논의하고, 팀이 소화할 수 있는 작업량만큼만 스프린트 백로그를 가져온다. 개발자를 무리한 일정 압박으로부터 보호하는 방파제 역할을 한다.

데일리 스크럼 (Daily Scrum)

- 목적 : 매일 15분, 진행 상황을 공유하고 이슈를 식별한다.

- 어제 한 일, 오늘 할 일, 그리고 방해 요소를 짧게 공유한다.

스프린트 리뷰 (Sprint Review)

- 목적 : 스프린트 마지막에 완성된 인크리먼트(동작하는 소프트웨어)를 PO와 타 부서에 시연하고 피드백을 받는다. PPT가 아닌 실제 API나 화면으로 보여준다.

스프린트 회고 (Sprint Retrospective)

- 목적 : 스크럼에서 가장 중요한 이벤트, 프로덕트가 아니라 우리가 일하는 방식을 회고하고 개선한다.

- "이번에 배포 과정에서 DB 락 이슈로 롤백을 했는데, 다음 스프린트부터는 DDL 변경 시나리오 리뷰를 프로세스에 추가하자"와 같은 실질적인 액션 아이템(Action Item)을 도출한다.

4. [Bas vs Good Code] 완료의 정의(Dod)가 무너질 때 생기는 비극

개발자에게 애자일 환경에서 가장 위험한 순간은, 스프린트 일정을 맞추기 위해 기능만 동작하게 억지로 끼워 맞출 때다. 테스트 코드 작성이나 보안 정책 적용이 완료의 정의(DoD)에 포함되어 있지 않다면, 기술 부채는 눈덩이처럼 불어난다.

유저의 비밀번호를 변경하는 API를 예로 들어보자.

[Bad Code] DoD를 무시한 일정 맞추기용 스크립트

시간이 없다는 이유로 컨트롤러에서 직접 DB를 찌르고 비밀번호를 평문으로 저장해버린다. 단위 테스트는 생략되었다. 기능은 당장 동작하겠지만, 이는 다음 스프린트에서 심각한 보안 이슈와 버그 폭탄으로 되돌아온다.

@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserRepository userRepository;

    // 트랜잭션 처리, 암호화, 검증 로직이 컨트롤러에 무분별하게 섞여 있음
    @PostMapping("/api/users/{id}/password")
    public ResponseEntity<Void> changePassword(@PathVariable Long id, @RequestBody String newPassword) {
        User user = userRepository.findById(id).orElseThrow();

        // 치명적 결함: 암호화 적용 안 됨, 패스워드 정책 검증 없음
        user.setPassword(newPassword);
        userRepository.save(user);

        return ResponseEntity.ok().build();
    }
}

[Good Code] 엄격한 DoD를 통과한 견고한 설계

성숙한 스크럼 팀은 일정이 빡빡하더라도 보안 로직 적용과 단위 테스트 통과를 완료의 정의(DoD)로 삼고 이를 반드시 지켜낸다. 객체지향 설계를 준수하며, 안전한 코드를 인도한다.

// 1. 책임을 분리한 도메인/서비스 로직
@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder; // Security 암호화 인터페이스 위임

    @Transactional
    public void changePassword(Long userId, String rawPassword) {
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new IllegalArgumentException("User not found"));

        // 패스워드 정책 검증 (별도의 정책 클래스로 분리하는 것이 이상적)
        validatePasswordPolicy(rawPassword);

        // 암호화 책임을 PasswordEncoder에게 위임하고, 도메인 객체 상태 변경
        user.changePassword(passwordEncoder.encode(rawPassword));
    }
}

// 2. 외부 요청 처리만 담당하는 깔끔한 컨트롤러
@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @PostMapping("/api/users/{id}/password")
    public ResponseEntity<Void> changePassword(@PathVariable Long id,
                                             @RequestBody PasswordChangeRequest request) {
        // 비즈니스 로직은 서비스 레이어로 완전히 위임
        userService.changePassword(id, request.getNewPassword());
        return ResponseEntity.ok().build();
    }
}

스프린트 일정을 맞추는 것도 중요하지만, 엔지니어링의 본질인 품질을 타협하여 얻어낸 속도는 결국 다음 스프린트의 발목을 잡는 가짜 속도일 뿐이다.

5. 결론

스크럼의 이벤트와 산출물은 팀을 감시하기 위한 마이크로 매니지먼트 도구가 아니라, 팀을 보호하고 잠재적인 리스크를 가시화하기 위한 시스템이다.

단순히 주어지는 백로그를 수동적으로 쳐내는 데 그쳐서는 안 된다. 플래닝 시간에 "이 비즈니스 요구사항을 제대로 구현하려면 기존의 낡은 결제 테이블 구조를 리팩토링해야 하므로, 이번 스프린트 백로그에 기술 부채 해결 테스크를 포함해야 합니다." 라고 당당히 요구할 수 있어야 한다. 눈에 보이지 않는 백엔드의 기술적 요소들을 스프린트 안으로 끌어와 가시화하는 것, 그것이 시니어 엔지니어가 스크럼에 기여하는 가장 핵심적인 역할이다.

[Software Engineering] 애자일(Agile) 스크럼 기초: PO, SM, 개발팀의 명확한 실무 R&R

H.Sunny,, — Fri, 8 May 2026 17:05:35 +0900

이전 포스팅([Software Enginnering] 애자일 선언문과 12가지 원칙)에서 강조했듯, 지라(Jira)를 쓰고 스프린트를 도입한다고 해서 곧바로 애자일 팀이 되는 것은 아니다. 시스템 구조가 바뀌려면 근본적으로 팀원들이 일하고 협업하는 구조(R&R)가 먼저 변해야 한다.

잦은 요구사항 변경을 전제로 하는 애자일 환경에서 전통적인 수직적 역할 분담은 병목만 유발한다. 이번 포스팅에서는 애자일의 대표적인 프레임워크인 스크럼(Scrum)의 3가지 핵심 역할과, 비즈니스 담당자와의 올바른 협업이 실제 코드와 아키텍처에 어떤 영향을 미치는지 살펴본다.

1. 스크럼의 3가지 핵심 역할 (Roles)

스크럼은 복잡한 문제를 해결하기 위해 고안된 경량 프레임워크다. 스크럼 팀에는 지시를 내리는 팀장이나 전통적인 PM이 존재하지 않으며, 역할과 권한이 명확히 분산되어 상호 견제와 균형을 이룬다.

프로덕트 오너(Product Owner, PO)

- 핵심 역할: 무엇을 만들 것인가를 결정한다.

- 프로덕트의 비즈니스 가치를 극대화하는 책임을 지며, 요구사항이 담긴 프로덕트 백로그(Product Backlog)의 유일한 관리자다.

- 개발팀에게 우선순위가 높은 비즈니스 목표를 제시하지만, 그것을 어떻게 기술적으로 구현할지, 일정을 얼마나 잡을지에 대해서는 지시할 권한이 없다.

스크럼 마스터(Scrum Master, SM)

- 핵심 역할: 팀이 스크럼 원칙을 잘 지키도록 돕는 서번트 리더(Servant Leader)이자 촉진자다.

- 팀의 개발 속도를 저해하는 외부의 방해 요소를 차단하고, 매끄러운 커뮤니케이션 환경을 조성한다. 관리하는 것이 아니라 코칭하는 역할이다.

개발팀(Developers)

- 핵심 역할: 어떻게 만들 것인가를 결정한다.

- 기획, 디자인, 프론트엔드, 백엔드 등 프로덕트를 실제로 구동하게 만드는 모든 작업자를 포함한다.

- PO가 제시한 목표를 달성하기 위한 기술적 아키텍처, 코드 품질, 데이터베이스 설계 등에 대한 절대적인 권한과 책임을 가진다. 스스로 작업량을 추정(Estimate)하고 일정을 계획한다.

2. 전통적 PM vs 스크럼

기존의 PM은 일정과 리소스 관리에 초점을 맞추는 탑다운 방식이 흔했다. 반면, 애자일 스크럼에서는 각자의 전문성을 바탕으로 권한이 분리된다.

- PO: "비즈니스적으로 A 기능이 가장 시급하고 가치가 높습니다."

- 개발팀: "A 기능을 안정적으로 구현하려면 레거시 테이블 분리를 포함해 1 스프린트(2주)가 필요합니다. 동시성 이슈를 막기 위해 분산 락을 적용하겠습니다."

- SM: "PO님, 개발팀이 이번 스프린트에 온전히 집중할 수 있도록 타 부서의 갑작스러운 데이터 추출 요청은 제가 막아두겠습니다."

3. [Bad vs Good Code] 역할 분담이 아키텍처에 미치는 영향

스크럼 환경에서 개발팀은 기획서를 단순히 코드로 번역하는 하청업체가 아니다. 개발자는 PO와 지속적으로 소통하며 비즈니스 도메인을 깊이 이해해야 한다. PO의 비즈니스 언어가 코드에 그대로 투영되어야만 요구사항 변경에 유연하게 대처할 수 있다.

배송 완료 후 7일 이내에만 환불이 가능하다는 PO의 요구사항을 예로 들어보자. 도메인에 대한 고민 없이 수동적으로 코딩하는 팀과, 비즈니스 규칙을 객체에 적극적으로 녹여내는 애자일 팀의 코드는 완전히 다르다.

[Bad Code] 수동적인 팀의 절차지향적 서비스 스크립트

도메인 지식을 서비스 계층에 if문으로 흩뿌려 놓은 상태다. PO가 7일이 아니라 14일로 늘려주시고, VVIP 회원은 30일까지 가능하게 해주세요 라고 정책변경을 요청하면, 개발자는 이 거대한 OrderSerivce를 뒤져서 로직을 뜯어고쳐야 한다.

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;

    // 비즈니스 룰이 서비스 로직에 절차적으로 노출되어 있음
    @Transactional
    public void processRefund(Long orderId) {
        Order order = orderRepository.findById(orderId).orElseThrow();

        // 데이터만 가져와서 서비스 계층에서 직접 상태와 날짜를 계산 (응집도 하락)
        if (order.getStatus() != OrderStatus.SHIPPED) {
            throw new IllegalStateException("배송 완료 상태가 아닙니다.");
        }

        long daysBetween = ChronoUnit.DAYS.between(order.getShippedDate(), LocalDateTime.now());
        if (daysBetween > 7) {
            throw new IllegalStateException("환불 가능 기간(7일)이 지났습니다.");
        }

        order.setStatus(OrderStatus.REFUNDED);
    }
}

[Good Code] 능동적인 애자일 팀의 도메인 주도 설계(DDD)

건강한 스크럼 팀의 개발자는 PO와 소통하여 환불 가능 여부 라는 핵심 비즈니스 규칙을 Order라는 도메인 객체 내부로 캡슐화 한다. 서비스 계층은 그저 도메인 객체에게 메시지를 던질 뿐이다. 정책이 변경되어도 Order 객체 내부만 수정하면 되므로 안전하다.

// 1. 핵심 비즈니스 규칙을 품고 있는 풍부한 도메인 모델 (Rich Domain Model)
@Entity
public class Order {
    @Enumerated(EnumType.STRING)
    private OrderStatus status;
    private LocalDateTime shippedDate;

    // PO와 정의한 비즈니스 언어를 메서드명과 로직으로 정확히 표현
    public void refund() {
        if (!isRefundable()) {
            throw new IllegalStateException("환불이 불가능한 주문입니다.");
        }
        this.status = OrderStatus.REFUNDED;
    }

    // 환불 정책이 변경되면 이 메서드 내부만 수정하면 됨 (OCP 준수)
    private boolean isRefundable() {
        if (this.status != OrderStatus.SHIPPED) return false;
        long daysAfterShipping = ChronoUnit.DAYS.between(this.shippedDate, LocalDateTime.now());
        return daysAfterShipping <= 7;
    }
}

// 2. 도메인 객체를 호출하기만 하는 깔끔한 서비스 계층
@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;

    @Transactional
    public void processRefund(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new IllegalArgumentException("주문을 찾을 수 없습니다."));

        // 캡슐화된 도메인 로직(비즈니스 룰)을 호출하기만 함. "환불해라!"
        order.refund();
    }
}

결국, 스크럼에서 PO와 개발팀이 밀접하게 소통해야 하는 이유는 단순히 친해지기 위해서가 아니다. 비즈니스의 복잡성을 기술적인 도메인 모델로 완벽하게 매핑하여, 향후 쏟아질 요구사항 변경에 흔들리지 않는 견고한 아키텍처를 만들기 위함이다.

결론

스크럼을 도입했다고 해서 갑자기 모든 문제가 마법처럼 해결되지는 않는다. 개발자가 과거 워터폴 시절처럼 PO가 시키는 대로 코드만 짰습니다 라며 수동적인 태도를 취하거나, 반대로 기획적인 영역까지 개발팀이 독단적으로 결정하려 한다면 그 팀은 무너질 수 밖에 없다.

- PO의 권한을 존중하라: 어떤 기능이 사용자에게 더 큰 가치를 주는가에 대한 우선순위 결정은 전적으로 PO의 영역이다.

- 기술의 통제권을 사수하라: 비즈니스 목표를 이루기 위한 테이블 설계 구조, 객체지향 패턴의 적용, 기술 부채를 해결하기 위한 리팩토링 일정 분배는 철저히 개발팀이 주도하고 책임져야 한다.

직급이나 호칭이 바뀌는 것이 애자일이 아니다. 각자의 역할과 책임에 맞게 전문가로서 권한을 행사하고 책임을 지는 구조, 그것이 진짜 폭발적인 퍼포먼스를 내는 스크럼 팀의 모습이다.

[Git] 브랜치 이동 시 남은 유령 폴더 해결법 : git clean -fd

H.Sunny,, — Thu, 7 May 2026 18:12:45 +0900

실무에서 기능 개발을 위해 feature/A 브랜치에서 한참 작업하다가, 급한 버그 픽스를 위해 hotfix/B 브랜치로 switch 또는 checkout 한 경험이 있을 것이다.

그런데 분명 B 브랜치에는 존재하지 않는 A 브랜치 전용 폴더와 파일들이 내 IDE나 작업 디렉토리에 그대로 남아있는 것응ㄹ 발견하게 된다. 코드를 빌드하려니 이 폴더들 때문에 컴파일 에러가 발생하거나 롬복(Lombok), 빌드 캐시가 꼬이는 일도 부지기수다.

도대체 왜 B 브랜치에는 없는 폴더가 내 로컬에 남아있는 것이며, 이를 어떻게 깔끔하게 청소해야 할까? 이번 포스팅에서는 Git이 작업 디렉토리를 다루는 철학과 git clean의 명확한 사용법에 대해 알아본다.

1. 왜 유령 폴더가 남아 있을까?

Git의 브랜치 이동 메커니즘을 이해하려면, Git의 최우선 철학인 사용자의 데이터를 함부로 날리지 않는다(안전 우선)를 알아야 한다.

A 브랜치에서 B 브랜치로 넘어갈 때, Git은 추적 중인(Tracked) 파일들은 모두 B 브랜치의 상태로 완벽하게 동기화(변경, 삭제, 생성)한다. 하지만 추적하지 않는(Untracked) 파일이나 폴더는 절대로 건드리지 않는다.

다음과 같은 상황에서 유령 폴더가 발생한다.

- 빌드 산출물 : A 브랜치에서 코드를 실행하며 생성된 build/, out/, node_modules/ 등의 폴더

- 새로 만든 파일 : A 브랜치에서 폴더와 파일을 새로 만들었으나, 아직 git add나 git commit을 하지 않은 상태에서 B 브랜치로 넘어간 경우

- B에서는 지워진 폴더 : A 브랜치에서는 관리되던 폴더가 B 브랜치에서는 삭제되었는데, 로컬 디렉토리 내부에 Git이 모르는(Untracked) 파일이 단 하나라도 남아있는 경우, GIt은 그 파일을 보호하기 위해 부모 폴더 전체를 남겨둔다.

2. 해결책 : git clean

이러한 Untracked 파일과 폴더를 작업 디렉토리에서 완전히 쓸어버리는 명령어가 바로 git clean이다.

git clean -fd (가장 많이 쓰이는 표준)

-f (force) : 강제로 삭제를 실행한다.(Git 설정에 따라 -f 없이 clean을 입력하면 안전을 위해 거부된다.)

-d (directory) : Untracked 파일뿐만 아니라 Untracked 폴더(디렉토리)까지 모두 지운다. (이 옵션이 없으면 폴더는 껍데기로 남는다.)

git clean -fdf (또는 -ff -d)

-fdf는 f가 두 번 들어간 형태다. 보통 -fd로 충분하지만, Git에서 -f 를 두번( -ff ) 주면 내부에 .git 폴더를 가진 하위 디렉토리(Submodule 등)까지 강제로 지워버리겠다는 아주 강력한 의미가 된다. 일반적인 상황이라면 -fd만으로 충분하다.

git clean -xfd (초강력 초기화)

-x : .gitingore에 등록되어 무시되고 있는 파일들(예: 빌드 결과물, IDE 설정 파일 등)까지 전부 삭제한다.

-> 브랜치를 바꿨는데 빌드가 꼬여서 자꾸 알 수 없는 에러가 날 때, 프로젝트를 처음 git clone 받은 완전히 깨끗한 상태로 되돌리기 위해 사용

3. 주의사항 : 한번 수행되면 복구할 수 없다!

git clean은 Git의 추적 범위 밖에 있는 파일들을 지우는 명령어다. 즉, 한 번 지우면 Ctrl + z 나 Git 명령어로 절대 복구할 수 없다. 작성 중이던 중요한 메모 파일이나 신규 소스 코드가 날아가는 대참사가 발생할 수 있다.

이러한 대참사를 막기 위해 무턱대고 -f를 누르지 않고, 반드시 가상 실행( -n )을 먼저 거치자.

# 1단계: 무엇이 지워질지 리스트만 먼저 확인한다 (Dry Run)
# -n (dry-run): 실제 삭제는 하지 않고, 삭제될 대상만 터미널에 출력
git clean -nd

# 2단계: 출력된 리스트에 내가 작업 중이던 중요한 파일이 없는지 확인 후 실제 삭제
git clean -fd

4. 결론

브랜치를 이동할 때 남겨지는 유령 폴더는 Git이 버그를 낸 것이 아니라, 당신의 소중한 Untracked 데이터를 잃어버리지 않게 지켜주려는 Git의 배려다.

하지만 이 배려가 개발 환경을 꼬이게 만든다면, git clean -fd를 통해 불필요한 찌꺼기들을 확실하게 청소해 주자. 브랜치 이동 후 빌드가 꼬일 때는 삽질하지 말고 git clean -xfd로 로컬 환경을 초기화하는 것이 퇴근 시간을 앞당기는 최고의 지름길이다. 단, 엔터를 치기 전 -nd 옵션으로 한 번 더 확인하는 방어적 습관을 들이자

[Software Enginnering] 애자일 선언문과 12가지 원칙

H.Sunny,, — Mon, 4 May 2026 11:00:50 +0900

애자일은 방법론이나 툴이 아니라, 일하는 방식의 철학이다. 이번 포스팅에서는 2001년 발표된 애자일 선언문과 12가지 원칙을 실무 관점에서 다시 해석해본다.

https://hsunnystory.tistory.com/261

[Software Enginnering] 에자일(Agile) 이란?

오픈을 한 달 앞둔 시점, 기획팀 혹은 고객사로부터 이런 피드백을 받은 경험이 한 번쯤은 있을 것이다. "이거 우리가 원했던 기능이 아닌데요????"이러한 비극은 왜 터지는 것일까? 이는 우리가

hsunnystory.tistory.com

1. 가치(Value)를 중심에 둔 애자일 선언문 4가지 핵심

공정과 도구보다 개인과 상호작용

Jira 티켓에 댓글만 남기며 핑퐁을 치는 것보다 프론트엔드 개발자나 기획자와 화이트보드 앞에서 아키텍처를 논의하는 것이 훨씬 빠르고 정확하다.

포괄적인 문서보다 작동하는 소프트웨어

100장짜리 완벽한 API 명세서를 작성하느라 시간을 쏟기보다, 핵심 기능만 동작하는 API를 빠르게 배포하고 Swagger를 통해 실시간으로 스펙을 맞춰나가는 것이 실무적이다.

계약 협상 보다 고객과의 협력

방어적으로 코딩하는 대신, 비즈니스 목표 달성을 위해 시스템 구조를 어떻게 유연하게 가져갈지 함께 고민해야 한다.

계획을 따르기보다 변화에 대응

초기 아키텍처 설계가 완벽할 것이라는 환상을 버려야 한다. 변화를 수용할 수 있는 확장성 있는 코드 베이스를 유지하는 것이 핵심이다.

2. 개발자가 명심해야 할 애자일 원칙 3가지

가치 있는 소프트웨어를 일찍, 그리고 지속적으로 전달한다.

이는 곧 CI/CD 파이프라인의 구축을 의미한다. 개발자가 코드를 푸시하면 자동으로 테스트가 돌고 스테이징 서버에 배포되어야만 지속적인 전달이 가능하다.

기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민성을 높인다.

애자일을 단순히 빨리 대충 개발하는 것으로 오해하면 안 된다. 탄탄한 객체지향 설계와 리팩토링, 그리고 테스트 코드가 뒷받침되지 않으면 기술 부채가 쌓여 결국 변화에 대응할 수 없는 레거시가 된다.

단순성 - 안해도 될 일을 최대한 하지 않는 기술이 필수적이다.

미래에 발생할지도 모르는 오버 엔지니어링을 경계해야 한다. YAGNI(You Aren't Gonna Need It) 원칙에 따라 현재의 비즈니스 요구사항을 해결하는 가장 단순하고 우아한 구조를 선택해야 한다.

3.무늬만 애자일을 피하는 기술적 탁월함

요구사항이 매 스프린트마다 변경되는 애자일 환경에서, 기술적 탁월함이 결여된 코드는 어떻게 무너지는지, 그리고 어떻게 방어해야 하는지 살펴보자

할인정책(Discount Policy)이 수시로 변하는 이커머스 도메인을 가정해 보자. 기획팀은 이번 주에는 정액 할인을, 다음주에는 비율 할인을, 그 다음 주에는 특정 등급 전용할인을 테스트해보고 싶어 한다.

[Bad Code : 기술적 탁월함이 결여된 Fake Agile]

새로운 정책이 추가될 때마다 기존 OrderService 클래스의 코드를 직접 수정해야 한다. 사이드 이펙트가 두려워 배포를 주저하게 되고, 결국 요구사항 변경을 환영할 수 없는 상태가 된다.

@Service
public class OrderService {

    // 비즈니스 로직에 분기문(if-else)이 덕지덕지 붙기 시작함 (OCP 위반)
    public long calculatePrice(Order order, String discountType) {
        long price = order.getOriginalPrice();

        if ("FIXED".equals(discountType)) {
            price -= 1000; // 정액 할인
        } else if ("PERCENT".equals(discountType)) {
            price = price - (price * 0.1); // 10% 할인
        } else if ("VIP".equals(discountType)) {
            // 요구사항이 추가될 때마다 이 거대한 클래스를 수정해야 함
            price = price - (price * 0.2);
        }
        return price;
    }
}

[Good Code: 변화를 환영하는 True Agile 아키텍처]

Spring Boot의 DI와 다형성을 적극 활용한 전략 패턴(Strategy Pattern) 구조다. 새로운 할인 정책이 필요하다면 기존 코드는 단 한 줄도 건드리지 않고, 새로운 클래스만 추가하여 확장에 열려 있는(OCP) 시스템을 만든다.

// 1. 추상화된 할인 인터페이스
public interface DiscountPolicy {
    boolean isSatisfiedBy(String discountType);
    long applyDiscount(long price);
}

// 2. 개별 정책 구현 (새로운 정책은 새로운 클래스 추가만으로 해결)
@Component
public class FixedDiscountPolicy implements DiscountPolicy {
    @Override
    public boolean isSatisfiedBy(String type) { return "FIXED".equals(type); }
    @Override
    public long applyDiscount(long price) { return price - 1000; }
}

// 3. 핵심 비즈니스 로직 (변화로부터 격리됨)
@Service
@RequiredArgsConstructor
public class OrderService {

    // Spring이 구현체 List를 런타임에 자동 주입
    private final List<DiscountPolicy> discountPolicies;

    public long calculatePrice(Order order, String discountType) {
        return discountPolicies.stream()
            .filter(policy -> policy.isSatisfiedBy(discountType))
            .findFirst()
            .map(policy -> policy.applyDiscount(order.getOriginalPrice()))
            .orElse(order.getOriginalPrice()); // 일치하는 정책이 없으면 원가 반환
    }
}

안전한 테스트 코드와 위와 같은 클린 아키텍처가 존재할 때, 개발자는 기획팀의 요구사항 변경을 스트레스가 아닌 프로덕트의 성장을 위한 자연스러운 실험으로 받아들일 수 있다.

결론

애자일은 기획자나 스크럼 마스터만의 전유물이 아니다. 훌륭한 프로세스를 도입하더라도, 개밭팀의 코드가 스파게티처럼 얽혀있다면 그 팀은 절대 애자일해질 수 없다.

무늬만 애자일을 피하고 진정한 기민성을 얻고 싶다면, Jira의 티켓 상태를 업데이트하는 것만큼이나 코드를 리팩토링하고, 자동화된 테스트를 작성하며, 아키텍처의 결합도를 낮추는 일(엔지니어링 프랙티스)에 팀의 리소스를 투자해야 한다. 시스템의 구조가 유연해야만 비즈니스도 유연해질 수 있다.

[Software Enginnering] 에자일(Agile) 이란?

H.Sunny,, — Thu, 16 Apr 2026 13:26:10 +0900

오픈을 한 달 앞둔 시점, 기획팀 혹은 고객사로부터 이런 피드백을 받은 경험이 한 번쯤은 있을 것이다.

"이거 우리가 원했던 기능이 아닌데요????"

이러한 비극은 왜 터지는 것일까? 이는 우리가 여전히 요구사항이 변하지 않을 것이라 가정하는 워터폴(Waterfall)속에서 개발하고 있기 때문이다. 이번 포스팅에서는 워터폴의 한계와 이를 극복하기 위한 에자일(Agile)의 본질에 대해 정리해본다.

https://hsunnystory.tistory.com/260

[Software Enginnering] 워터폴(Waterfall) 방법론의 명과 암

대형 SI 프로젝트나 공공기관 차세대 시스템 구축에 투입되면, 어김없이 거대한 엑셀 파일 두 개를 마주하게 된다. 수개월의 일정이 빼곡히 적힌 WBS와 수백 페이지에 달하는 요구사항 정의서다.

hsunnystory.tistory.com

1. 에자일(Agile): 방법론이 아닌 마인드셋

에자일을 지라(Jira)를 쓰고, 아침마다 스탠드업 미팅을 하는 도구나 프로세스로 오해하는 경우가 많다. 하지만 에자일의 본질은 기법이 아니라 변화를 수용하는 마인드셋이다.

애자일은 소프트웨어 개발의 불확실성을 인정한다. 처음부터 완벽한 설계는 없으므로, 동작하는 가장 작은 단위의 소프트웨어를 빠르게 만들어 고객에게 전달하고, 피드백을 받아 지속적으로 개선해 나가는 것이 핵심이다.

이러한 애자일의 철학은 개발자가 작성하는 코드, 그리고 객체지향 설계의 원리와도 정확히 맞닿아 있다. 변화에 유연하게 대응하기 위해 우리는 코드 레벨에서 어떤 고민을 해야 할까?

2. 변화를 대하는 코드의 자세

워터폴 방식처럼 요구사항은 고정되어 있다고 가정하는 코드는 확장에 닫혀 있어 작은 변경에도 시스템 전체가 흔들린다. 반면, 애자일 방식의 코드는 다형성과 OCP를 활용해 변화를 부드럽게 수용한다.

결제 시스템의 알림 기능을 예로 들어보자. 초기 요구사항은 이메일 알림 하나 였다.

[Bad Code : 워터풀 방식의 경직된 설계]

새로운 요구사항(SMS, 카카오톡 알림 등)이 추가될 때마다 핵심 비즈니스 로직인 OrderSerivce의 코드를 직접 수정해야 한다. 이는 변경에 취약하고 테스트하기 어려운 구조다.

// 핵심 비즈니스 로직이 구체 클래스에 강하게 결합되어 있음 (OCP 위반)
public class OrderService {
    private EmailSender emailSender = new EmailSender(); // 구체 클래스 의존

    public void completeOrder(Order order) {
        // 1. 주문 처리 로직
        processPayment(order);

        // 2. 알림 발송 (요구사항이 변경되면 이곳을 직접 수정해야 함)
        emailSender.send(order.getUserEmail(), "주문이 완료되었습니다.");
        // 만약 SMS 알림이 추가된다면? if문이 추가되고 코드가 뚱뚱해진다.
    }
}

[Good Code: 에자일 방식의 유연한 설계]

에자일 환경에서는 요구사항이 언제든 변할 수 있음을 전제한다. 따라서 인터페이스에 의존하도록 설계하여, 새로운 알림 수단이 추가되더라도 기존 코드를 수정하지 안하고 확장만으로 대응할 수 있게 한다.

// 변화를 수용하는 인터페이스 설계
public interface NotificationSender {
    void send(User user, String message);
}

public class EmailSender implements NotificationSender { /* 구현 생략 */ }
public class SmsSender implements NotificationSender { /* 구현 생략 */ }

// 핵심 비즈니스 로직 (수정에 닫혀 있고 확장에 열려 있음 - OCP 준수)
@Service
@RequiredArgsConstructor
public class OrderService {

    // 다형성을 활용하여 런타임에 전략을 주입받음
    private final NotificationSender notificationSender;

    public void completeOrder(Order order) {
        // 1. 주문 처리 로직
        processPayment(order);

        // 2. 알림 발송 (알림의 종류가 SMS든 카카오톡이든 OrderService는 변경되지 않음)
        notificationSender.send(order.getUser(), "주문이 완료되었습니다.");
    }
}

결국 코드를 유연하게 짜는 객체지향 설계와 일하는 방식을 유연하게 가져가는 애자일은 변화에 대한 비용을 최소화 한다는 동일한 본질을 공유한다.

3. IT기업에서 애자일을 중요시 하는 이유

실무에서 비즈니스 환경은 매일 바뀐다. 경쟁사는 새로운 기능을 출시하고, 유저의 트렌드는 급변한다. 이런 상황에서 6개월 뒤에나 결과를 볼 수 있는 워터폴 방식은 비즈니스의 사형선고나 다름 없다.

리스크 최소화

6개월간 개발해서 실패하는 것보다, 2주 만에 핵심 기능만 배포해 보고 고객 반응이 없으면 빠르게 방향을 트는 것이 훨씬 안전하다.

지속적 가치 전달

MSA나 CI/CD 파이프라인 같은 현대적인 백엔드 인프라 기술들은 모두 하루에도 몇 번씩 안전하고 빠르게 배포한다는 애자일 철학을 기술적으로 뒷받침하기 위해 탄생한 것이다.

결론

애자일은 개발을 빨리하는 방법이 아니다. 올바른 방향으로 개발하고 있는지 지속적으로 확인하는 방법이다.

[Software Enginnering] 워터폴(Waterfall) 방법론의 명과 암

H.Sunny,, — Mon, 13 Apr 2026 10:56:09 +0900

대형 SI 프로젝트나 공공기관 차세대 시스템 구축에 투입되면, 어김없이 거대한 엑셀 파일 두 개를 마주하게 된다. 수개월의 일정이 빼곡히 적힌 WBS와 수백 페이지에 달하는 요구사항 정의서다. 폭포수처럼 위에서 아래로 흐르는 워터폴(Waterfall) 방법론의 본질과, 이 구조 속에서 개발자가 맞닥뜨리는 치명적인 문제, 그리고 이를 방어하기 위한 객체지향적 아키텍처 설계 전략에 대해 알아본다.

1. 워터폴(Waterfall) 방법론이란?

워터폴 방법론은 소프트웨어 개발 생명주기(SDLC)를 순차적인 단계로 나누어 진행하는 고전적인 방식이다. 물이 폭포에서 아래로 떨어지듯, 한 단계가 완전히 끝나야만 다음 단계로 넘어갈 수 있다.

진행단계

요구사항 분석 -> 시스템 설계 -> 구현 -> 테스트 -> 배포 및 유지보수

사용 이유

관리자 입장에서 프로젝트의 진척도를 퍼센트로 측정하기 쉽고, 각 단계별 산출물이 명확하게 남기 때문에 계약 기반의 외주 프로젝트에서 주로 사용

2. BDUF의 착각과 UAT(인수 테스트)의 재앙

워터폴 방법론은 하나의 거대한 전제를 깔고 있다. 바로 요구사항은 프로젝트 초기에 완벽하게 정의될 수 있다는 믿음, 즉 BDUF(Big Design Up Front)다. 하지만 현실의 비즈니스는 끊임없이 변하며, 고객은 눈으로 완성된 화면을 보기 전까지 자신이 무엇을 원하는지 정확히 알지 못한다.

피드백의 지연

개발의 90% 이상 완료된 후반부 통합 테스트나 UAT(사용자 인수 테스트) 단계에서야 고객이 결과물을 확인한다.

빅뱅(Big Bang) 리스크

뒤늦게 부정적인 피드백을 받거나 핵심 아키텍처의 성능 결함이 발견되면, 이미 설계와 DB 스키마가 굳어진 상태로 시스템 전체를 뒤엎어야 하는 대 참사가 발생한다. 폭포수는 거꾸로 흐를 수 없기 때문이다.

3. 워터폴의 경직성을 방어하는 코드 설계 전략

요구사항 변경은 필연적이므로, 후반부에 쏟아질 변경 요청의 충격을 흡수할 수 있도록 코드를 유연하게 설계해야 한다.

Bad Code: 기획서만 믿고 짠 절차 지향적 하드코딩

기획서에 명시된 일반고객과 VIP 고객의 할인 정책만을 보고, 서비스 로직 내부에 제어문을 강하게 결합시킨 최악의 코드다.

@Service
public class OrderService {

    // 문제: 오픈 1주일 전, 기획팀에서 "VVIP 등급과 신규 가입자 전용 할인을 추가해 주세요"라고 한다면?
    // 이 클래스의 코드를 직접 수정해야 하며, 이는 OCP(개방-폐쇄 원칙) 위반이다.
    public int calculateDiscount(Member member, int price) {
        if (member.getGrade() == Grade.VIP) {
            return price - 1000;
        } else if (member.getGrade() == Grade.NORMAL) {
            return price; // 할인 없음
        }
        // 끝없는 else if의 늪...
        return price;
    }
}

Good Code: 다형성을 활용한 변경에 열려있는 설계

워터폴의 폭탄(막판 요구사항 변경)을 방어하기 위해서는 비즈니스 로직을 추상화하여 OCP를 준수해야 한다.

// 1. 변하는 것(할인 정책)을 인터페이스로 추상화한다.
public interface DiscountPolicy {
    int discount(Member member, int price);
    boolean isSupport(Grade grade);
}

// 2. 구체적인 할인 정책을 구현한다. (새로운 정책이 추가되어도 기존 코드는 수정되지 않는다)
@Component
public class VipDiscountPolicy implements DiscountPolicy {
    @Override
    public int discount(Member member, int price) { return price - 1000; }

    @Override
    public boolean isSupport(Grade grade) { return grade == Grade.VIP; }
}

@Service
@RequiredArgsConstructor
public class OrderService {

    // 3. Spring의 List 주입을 통해 모든 할인 정책을 동적으로 관리한다.
    private final List<DiscountPolicy> discountPolicies;

    public int calculateDiscount(Member member, int price) {
        return discountPolicies.stream()
                .filter(policy -> policy.isSupport(member.getGrade()))
                .findFirst()
                .map(policy -> policy.discount(member, price))
                .orElse(price); // 해당하는 정책이 없으면 원가 반환
    }
}

아키텍처적 이점

워터폴 막바지에 새로운 고객 등급이나 할인 정책이 추가되더라도, OrderSerivce의 핵심 로직은 단 한 줄도 수정할 필요가 없다. 그저 DiscountPolicy를 구현한 새로운 클래스만 하나 추가하면 스프링이 알아서 의존성을 주입하고 분기 처리를 완료한다.

결론

워터폴 방법론 자체가 절대적인 악은 아니다. 우주선 제어 시스템이나 의료 기기 소프트웨어처럼 요규사항이 절대로 변해서는 안 되고 치밀한 사전 검증이 필요한 도메인에서는 여전히 최고의 선택이다.

하지만 요구사항 변화가 극심한 현대의 웹/서버 비즈니스 환경에서는 워터폴의 경직성이 독이 되는 경우가 많다. 만약 현재 워터폴 기반의 프로젝트를 수행중이라면, 방법론의 한계를 명확히 인지하고 인터페이스와 다형성을 활용하여 언제든 기획이 뒤집힐 수 있다는 전제하에 아키텍처를 설계해야 한다. 방법론이 코드를 보호해 주지 못한다면, 개발자는 유연한 설계로 스스로를 보호해야 한다.

[Spring Boot] Relaxed Binding란

H.Sunny,, — Thu, 9 Apr 2026 14:06:33 +0900

이전 포스팅에서 5가지 네이밍 컨벤션과 데이터 매핑 전략에 대해 알아보았다.

https://hsunnystory.tistory.com/258

[Clean Code] 실무에서 알아야할 5가지 네이밍 컨벤션과 데이터 매핑 전략

개발자로 일하다 보면 프론트엔드 개발자나 인프라 담당자와 협업할 때 이런 상황을 자주 겪는다.프론트엔드에서 API 로 user_name 이라는 데이터를 보냈는데, 백엔드의 자바 객체(DTO)에서는 userName

hsunnystory.tistory.com

이번 포스팅에서는 스프링 부트 환경에서 이질적인 네이밍 컨벤션들을 어떻게 유연하게 연결해 주는지, 그 핵심 원리인 Relaxed Binding에 대해 알아본다.

스프링 부트 애플리케이션을 개발하고 배포하다 보면 잉런 경험이 한 번쯤 있을 것이다. 로컬 환경에서는 application.yml에 max-reetry-count=3 이라고 표기하여 개발을 진행한다. 그런데 Docker나 Kubernetes를 통해 운영 서버에 배포할 때, 인프라 담당자는 OS 환경 변수로 MAX_RETRY_COUNT=5를 주입한다.

자바 코드에서는 maxRetryCount 라는 카멜 케이스(Camel Case) 변수를 사용하고, 설정 파일은 케밥 케이스(Kebab Case)를 쓰며, OS 환경 변수는 대문자 스네이크 케이스(Upper Snake Case)를 쓴다. 놀랍게도 스프링 부트는 아무런 추가 설정 없이 이 모든 것을 알아서 하나의 자바 변수에 매핑해 준다.

1. Relaxed Binding이란?

Relaxed Binding은 단어 뜻 그대로 느슨한 바인딩을 의미한다. 스프링 부트 환경에서 application.yml, application.properties, OS 환경 변수 등 다양한 외부 설정값들을 자바 객체(Bean)의 필드에 매핑할 때, 이름의 규칙이 정확히 일치하지 않아도 문맥상 같은 의미라면 자동으로 매핑해 주는 기능이다.

매핑 지원 규칙 예시

자바 객체의 필드명이 firstName 일 때, 아래의 모든 표기법이 동일하게 매핑된다.

- Kebab Case : first-name (.yml이나 .properties 에서 권장)

- Camel Case : firstName

- Snake Case : first_name

- Upper Snake Case : FIRST_NAME (OS 환경 변수에서 주로 사용)

2. @Value의 한계와 파편화

개발자들이 가장 많이 하는 실수는 모든 설정값을 @Value로 주입 받는 것이다.

Bad Code: 파편화된 설정과 @Value 남용

@Service
public class PaymentService {

    // 문제 1: 프로퍼티 키값이 오타가 나도 컴파일 타임에 잡히지 않는다.
    // 문제 2: 곳곳에 @Value가 흩어져 있어 설정의 응집도가 떨어진다.
    @Value("${app.payment.max-retry-count}")
    private int maxRetryCount;

    @Value("${app.payment.api-key}")
    private String apiKey;

    public void process() {
        System.out.println("Retry count: " + maxRetryCount);
        // 결제 로직...
    }
}

문제점

@Value는 스프링의 Relaxed Binging을 완벽하게 지원하지 않는다. (일부 제한적으로 동작하지만, 환경 변수 변환 등에서 제약이 많다.) 또한, 여러 서비스에서 동일한 설정값을 사용할 경우 코드가 중복되며, 객체지향의 응집도 측면에서도 설정 정보가 비즈니스 로직에 결합하여 매우 나쁜 구조가 된다.

3. 해결책: @ConfigurationProperties와 Relaxed Binding

스프링 부트는 외부 설정을 강력한 타입 세이프(Type-safe) 구조로 관리할 수 있도록 @ConfigurationProperties를 제공한다. 이 어노테이션은 Relaxed Binding을 100% 지원한다.

Good Code: 객체지향적인 설정 관리와 유연한 매핑

설정값을 담을 전용 클래스를 생성한다. 자바 16이상이라면 record를 활용하여 불변 객체로 아주 깔끔하게 작성할 수 있다.

import org.springframework.boot.context.properties.ConfigurationProperties;

// 설정 정보를 독립적인 도메인으로 분리하여 응집도를 높인다.
// prefix는 반드시 소문자 케밥 케이스(kebab-case)로 작성해야 한다.
@ConfigurationProperties(prefix = "app.payment")
public record PaymentProperties(
int maxRetryCount, // 환경 변수 APP_PAYMENT_MAX_RETRY_COUNT 와 자동 매핑
String apiKey // 환경 변수 APP_PAYMENT_API_KEY 와 자동 매핑
) {
}

이제 비즈니스 로직에서는 이 PaymentProperties를 의존성 주입 받아서 사용하기만 하면 된다.

@Service
@RequiredArgsConstructor
public class PaymentService {

    // 설정 정보가 캡슐화된 객체 자체를 주입받음
    private final PaymentProperties paymentProperties;

    public void process() {
        // 비즈니스 로직은 설정값이 어떻게 주입되었는지(YAML인지, OS환경변수인지) 알 필요가 없다.
        int retryCount = paymentProperties.maxRetryCount();
        System.out.println("Retry count: " + retryCount);
    }
}

아키텍처적 이점

인프라 환경(Docker, OS)의 명명 규칙과 애플리케이션의 명명 규칙(Camel Case) 사이의 임피던스 불일치(Impedance Mismatch)를 스프링 부트가 오나벽히 해결해 준다. OCP(개방-폐쇄 원칙) 관점에서도 인프라 환경이 바뀌어 프로퍼티 주입 방식이 달라져도 자바 코드는 단 한줄도 수정할 필요가 없다.

4. 주의사항

Prefix는 반드시 Kebab Case로 작성할것

- @ConfigurationProperties(prefix = "app.payment") (O)

- @ConfigurationProperties(prefix = "app.paymentConfig") (X)

-> 스프링 부트 규약상 prefix는 영문 소문자와 대시(-) 만 허용된다.

@Value 대신 @ConfigurationProperties를 기본으로 사용할 것

- 단일 값을 주입받는 극히 예외적인 상황이 아니라면, 설정은 그룹화하여 객체로 다루는 것이 유지보수와 테스트(Mocking)에 훨씬 유리하다.

환경 변수(OS Env) 적용 규칙 기억하기

- OS 환경 변수는 점(.)을 사용할 수 없으므로, 언더스코어(_)로 치환하여 사용한다.

- 예 : app.payment.max-retry-count -> APP_PAYMENT_MAX_RETRY_COUNT

결론

스프링 부트의 Relaxed Binding은 단순한 편의 기능을 넘어, Infrastructure의 제약과 객체지향 설계 사이의 간극을 메워주는 핵심 아키텍처 요소다.

더 이상 @Value를 이곳저곳 흩뿌려놓지 말고, @ConfigruationProperties를 통해 설정을 도메인 객체로 격상시키자.

[Clean Code] 실무에서 알아야할 5가지 네이밍 컨벤션과 데이터 매핑 전략

H.Sunny,, — Tue, 7 Apr 2026 14:57:16 +0900

이전 포스팅에서 스프링 부트의 Relaxed Binding에 대해 알아보았다.

https://hsunnystory.tistory.com/259

[Spring Boot] Relaxed Binding란

이전 포스팅에서 5가지 네이밍 컨벤션과 데이터 매핑 전략에 대해 알아보았다.https://hsunnystory.tistory.com/258 [Clean Code] 실무에서 알아야할 5가지 네이밍 컨벤션과 데이터 매핑 전략개발자로 일하다

hsunnystory.tistory.com

이번 포스팅에서는 자주 쓰이는 5가지 네이밍 케이스를 정리하고, 특히 각기 다른 컨벤션을 가진 시스템(DB, JSON API, OS)간의 임피던스 불일치(Impedance Mismatch)를 아키텍처 관점에서 어떻게 해결해야 하는지 알아본다.

개발자로 일하다 보면 프론트엔드 개발자나 인프라 담당자와 협업할 때 이런 상황을 자주 겪는다.

프론트엔드에서 API 로 user_name 이라는 데이터를 보냈는데, 백엔드의 자바 객체(DTO)에서는 userName으로 받고 있어 값이 전부 null로 매핑되는 것이다.

이때 자바 변수명을 user_name으로 바꾸면 해결되겠지라고 생각한다면 큰 오산이다. 프로그래밍에서 네이밍 컨벤션(Nameing Convension)은 단순한 취향 차이가 아니라, 시스템 간의 데이터를 주고받는 규악이자 언어 생태계의 표준이다.

1. 5가지 주요 네이밍 컨벤션

카멜 (Camel, camelCase)

- 첫 단어는 소문자, 이어지는 단어의 첫 글자는 대문자로 표기

- Java, JavaScript의 변수명 및 메서드명, JSON의 표준 키값에 사용

파스칼 (Pascal, PascalCase)

- 카멜 케이스와 같지만, 첫 단어의 첫 글자도 대문자로 표기한다.(Upper Camel Case)

- Java, C# 등의 클래스명, 인터페이스명에 사용

케밥 (Kebab, kebab-case)

- 모든 단어를 소문자로 쓰고, 단어 사이를 하이픈( - )으로 연결

- URL URI 경로, HTML/CSS의 클래스명, application.yml 등의 설정 파일 키값에 사용

스네이크 (Snacke, snake_case)

- 모든 단어를 소문자로 쓰고, 단어 사이를 언더스코어( _ )로 연결

- Python의 변수명, RDB의 테이블 및 컬럼명에 사용

어퍼 스네이크 (Upper Snake, UPPER_SNAKE_CASE)

- 스네이크 케이스와 같지만, 모든 글자를 대문자로 표기

- Java의 static final 상수, OS 환경 변수(Environment Variables)

스네이크와 어퍼 스네이크를 분리하는 이유

형태상으로는 대소문자 차이일 뿐이지만, 실무에서는 이 둘을 완전히 다른 목적으로 취급한다. snake_case는 DB나 API를 통해 흘러 다니는 가변적인 일반 데이터(State)를 의미하고, UPPER_SNAKE_CASE는 코드 내부의 상수나 OS 인프라에서 주입되는 불변의 설정(Constant)을 의미한다. 코드는 의도를 담아야 하므로 두 케이스는 아키텍처 상 분리해서 사고하는 것이 옳다.

2. 문제점 - 컨벤션이 충돌하는 경계

가장 큰 문제는 서로 다른 컨벤션을 사용하는 시스템이 통신할 때 발생한다. 데이터베이스는 주로 스네이크 케이스(user_id)를 사용하고, 자바 백엔드는 카멜 케이스(userId)를 사용하며, 외부 API는 종종 스네이크 케이스 포멧의 JSON을 던져준다.

이 때 데이터를 제대로 받기 위해 자바 코드의 네이밍 규칙을 무너뜨리는 것은 객체지향 설계의 본질을 해치는 최악의 접근이다.

Bad Code: 생태계 표준을 무시한 DTO 설계

public class UserRequestDto {
    // 문제 1: Java의 카멜 케이스 표준을 위반했다.
    // 문제 2: 외부 시스템의 JSON 키 포맷이 변경되면 자바 코드(필드명, getter/setter)를 전부 뜯어고쳐야 한다.
    private String user_name;
    private String phone_number;

    public String getUser_name() { return user_name; }
    public String getPhone_number() { return phone_number; }
}

이러한 코드는 자바의 표준을 깨뜨릴 뿐만 아니라, 외부 통신 규약과 내부 도메인 로직을 강하게 결합시킨다. OCP(개방-폐쇄 원칙)에 위배되는 전형적인 사례다.

3. 해결책 - 어댑터(Adapter) 역할을 하는 프레임워크 기능 활용

설계의 원칙은 명확하다. 내부(Java)는 철저히 자바의 표준(Camel Case)을 따르고, 시스템의 경계(Controller, Repository)에서만 직렬화/역직렬화를 통해 포맷을 변환한다.

Spring Boot 환경에서는 Jackson 라이브러리와 Hibernate가 이 어댑터 역할을 아주 훌륭하게 수행해 준다.

Good Code: Jackson을 활용한 JSON 매핑

개별 필드 매핑 ( @JsonProperty )

특정 필드만 다른 이름으로 매핑해야 할 때 유용하다. 자바 필드명은 userName을 유지하면서, JSON으로 들어오고 나갈 때는 user_name으로 안전하게 변환된다.

public class UserRequestDto {
    @JsonProperty("user_name")
    private String userName; // Java 표준인 Camel Case 유지

    @JsonProperty("phone_number")
    private String phoneNumber;
}

클래스 단위 일괄 매핑 ( @JsonNameing )

만약 외부 API가 100% 스네이크 케이스 포맷을 사용한다면, 일일이 @JsonProperty를 붙이는 것은 비효율적이다. 이때는 클래스 레벨에서 Naming Strategy를 지정할 수 있다.

import com.fasterxml.jackson.databind.PropertyNamingStrategies;
import com.fasterxml.jackson.databind.annotation.JsonNaming;

// 이 DTO의 모든 필드는 직렬화/역직렬화 시 자동으로 스네이크 케이스와 매핑된다.
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
public class UserRequestDto {

    private String userName;      // JSON: user_name
    private String phoneNumber;   // JSON: phone_number
    private String emailAddress;  // JSON: email_address
}

데이터베이스와의 매핑도 마찬가지다. Spring Data JPA를 사용하면 SpringPhysialNamingStrategy가 기본적용되어, 자바 엔티티의 userName 필드를 DB의 user_name 컬럼으로 자동 변환해 준다.

결론

카멜, 파스칼, 케밥, 스네이크, 어퍼 스네이크 케이스는 단순한 텍스트 형태가 아니라 각 기술 생태계가 합의한 언어다.

프레임워크가 제공하는 매핑 전략(Jackson, JPA Naming Strategy 등)을 시스템의 경계에 배치하여 통신을 매끄럽게 번역하자. 네이밍 컨벤션을 지키는 것은 클린 코드와 유연한 아키텍처를 향한 가장 기본적이고 중요한 첫걸음이다.

[Software Engineering] 테스트 주도 개발(TDD)란?

H.Sunny,, — Mon, 6 Apr 2026 17:40:42 +0900

개발자라면 누구나 한 번쯤 TDD(Test-Driven Development) 테스트 주도 개발에 대해 들어보았을 것이다. 이번 포스팅에서는 TDD에 대해서 다룬다.

1. 문제 상황 : 테스트 코드를 나중에 작성하면 생기는 일

보통의 개발 흐름은 요구사항을 받으면 일단 비즈니스 로직부터 작성한다. 기능이 정상 동작하는 것을 확인한 후 뒤늦게 테스트 코드를 덮어 씌운다 (이를 Test-Last 방식이라 한다.)

Bad Code: 테스트하기 어려운 설계

주말에는 영화 티켓값을 10% 할인해 주는 로직을 개발했다고 가정하자

public class TicketService {

    // [Bad Code] 운영 코드를 먼저 짜면, 현재 시간에 강하게 결합된 코드가 나온다.
    public int calculatePrice(int basePrice) {
        DayOfWeek today = LocalDate.now().getDayOfWeek(); // 제어할 수 없는 외부 상태(현재 시간)에 의존

        if (today == DayOfWeek.SATURDAY || today == DayOfWeek.SUNDAY) {
            return (int) (basePrice * 0.9);
        }
        return basePrice;
    }
}

이제 이 코드를 검증하기 위해 테스트 코드를 작성한다고 했을 때, 이 테스트는 오늘이 무슨 요일이냐에 따라 성공과 실패가 오락가락 하는 엉터리 테스트가 된다. 수요일에 이 코드를 커밋하고 CI/CD를 돌리면 주말 할인 테스트는 무조건 실패한다.

2. TDD란? (Red-Green-Refactor)

TDD는 개발의 순서를 완전히 뒤집는다. 실패하는 테스트 코드를 먼저 작성하고(Red), 그 테스트를 통과시킬 만큼만 코드를 구현한 뒤(Green), 코드를 깔끔하게 다듬는(Refactor) 과정을 짧게 반복한다.

RED (실패하는 테스트)

아직 구현되지 않은 기능의 테스트를 작성한다. 이때 어떻게 구현할지가 아니라 무엇을 해야 하는지(인터페이스와 스팩)를 먼저 고민한다.

GREEN (테스트 통과)

꼼수를 써서라도 가장 빠르게 테스트를 통과 시킨다.

REFACTOR(리팩토링)

테스트가 코드를 보호해주고 있으므로, 안심하고 중복을 제거하고 객체 지향적인 설계로 다듬는다.

3. 실전 TDD 적용

Step 1: RED (테스트를 먼저 설계한다.)

할인 로직을 검증하려면, 내가 요일을 임의로 조작할 수 있어야 한다는 사실을 테스트 코드를 짜면서 자연스럽게 깨닫게 된다.

class TicketServiceTest {

    @Test
    @DisplayName("주말(토, 일)에는 티켓 가격이 10% 할인되어야 한다.")
    void weekend_discount() {
        TicketService service = new TicketService();

        // given: 내가 직접 날짜를 주입(제어)할 수 있도록 인터페이스를 설계하게 됨!
        LocalDate saturday = LocalDate.of(2023, 10, 28);

        // when
        int price = service.calculatePrice(10000, saturday);

        // then
        assertThat(price).isEqualTo(9000);
    }
}

코드 구현이 없으므로 당연히 컴파일 에러가 나거나 테스트에 실패한다.

Step 2: GREEN (가장 단순한 구현)

테스트를 통과시키는 것이 최우선이다. 오직 테스트를 만족시키는 코드만 작성한다.

public class TicketService {

    // 테스트 코드를 통해 '날짜'를 외부에서 주입받아야 한다는 설계를 이끌어냈다!
    public int calculatePrice(int basePrice, LocalDate date) {
        if (date.getDayOfWeek() == DayOfWeek.SATURDAY || date.getDayOfWeek() == DayOfWeek.SUNDAY) {
            return (int) (basePrice * 0.9);
        }
        return basePrice;
    }
}

Step 3: REFACTOR (안전한 개선)

이제 테스트가 든든하게 받쳐주고 있으니, 로직을 더 우아하게 개선해 본다.

public class TicketService {

    public int calculatePrice(int basePrice, LocalDate date) {
        if (isWeekend(date)) {
            return (int) (basePrice * 0.9);
        }
        return basePrice;
    }

    // 주말 여부를 판단하는 로직을 별도 메서드로 추출 (가독성 향상)
    private boolean isWeekend(LocalDate date) {
        DayOfWeek day = date.getDayOfWeek();
        return day == DayOfWeek.SATURDAY || day == DayOfWeek.SUNDAY;
    }
}

4. TDD의 가치: 테스트가 아닌 설계(Design)을 주도한다.

TDD의 목적은 단순히 커버리지 100%의 방대한 테스트 코드를 짜는 것이 아니다. 앞선 예제에서 보았듯, 사용자(클라이언트)의 관점에서 테스트를 먼저 작성하다 보면, 필연적으로 테스트하기 좋은 코드(= 의존성이 낮고 모듈화가 잘 된 결합도 낮은 코드)를 강제로 설계하게 된다.

- LocalDate.now() 같은 숨겨진 의존성은 메서드 파라미터나 의존성 주입(DI)으로 끌어내게 된다.

- 비대한 Service 클래스는 테스트가 너무 복잡해지기 떄문에, 자연스럽게 역할을 분리(Entity 나 다른객체로 위임)하게 된다.

결론

바빠서 테스트 코드를 짤 시간이 없다는 말은 사실 모순이다.

개발 이후에 손으로 Postman을 수십 번 클릭하며 디버깅하는 시간, 라이브 서버에서 터진 버그를 수습하느라 날리는 주말을 생각하면 TDD는 시간을 잡아먹는 것이 아니라 오히려 시간을 가장 확실하게 아껴주는 투자다.

복잡한 비즈니스 로직이나 도메인 핵심 규칙만큼은 반드시 테스트를 먼저 작성하는 TDD 사이클을 경험하는 습관을 들이자

[Software Engineering] 트랜잭션 스크립트 패턴(Transaction Script Pattern)

H.Sunny,, — Tue, 31 Mar 2026 17:09:38 +0900

최근 몇 년간 백엔드 생태계에서는 도메인 주도 설계(DDD)와 객체지향이 최고의 미덕처럼 여겨지고 있다.

https://hsunnystory.tistory.com/255

[Skill] DDD(도메인 주도 설계)란

실무를 하다 보면, 수천 줄이 넘어가는 거대한 Service 클래스를 마주하게 되는 날이 온다. 비즈니스 로직은 모두 서비스 계층에 몰려있고, 정작 데이터의 주체여야 할 Entity 클래스들은 그저 getter

hsunnystory.tistory.com

트랜잭션 스크립트 패턴(Transaction Script Pattern)은 무조건 피해야 할 레거시(Legacy)이자 안티 패턴일까? 이번 포스팅에서는 트랜잭션 스크립트 패턴에 대해 알아본다.

1. 트랜잭션 스크립트 패턴(Transaction Script Pattern) 이란?

트랜잭션 스크립트는 사용자의 요청(Request) 하나당 하나의 비즈니스 트랜잭션(스크립트)을 매핑하여 처리하는 방식이다.

동작방식

컨트롤러에서 요청이 들어오면, Service 계층의 메서드 하나가 시작부터 끝까지 모든 흐름을 제어한다. DB에서 데이터를 읽어오고, 계산하고, 상태를 변경한 뒤 다시 DB에 저장하는 일련의 절차(Procedure)를 순서대로 작성한다.

특징

객체 지향이라기보다는 절차 지향(Procedural) 프로그래밍에 가깝다. 데이터베이스의 테이블과 1:1로 매핑되는 단순한 데이터 구조(DTO 또는 빈약한 Entity)를 다룬다.

2. 왜 실무에서 가장 많이 쓰일까?

트랜잭션 스크립트의 가장 큰 장점은 압도적인 직관성과 빠른 개발 속도다. 복잡한 도메인 지식이 없는 단순한 CRUD 중심의 애플리케이션에서는 이보다 좋은 패턴이 없다.

호텔 객실을 예약 하는 단순한 API

Good Code

@Service
@RequiredArgsConstructor
public class HotelBookingService {

    private final RoomRepository roomRepository;
    private final BookingRepository bookingRepository;

    // [Good Code] 단순한 요구사항에서는 가장 직관적이고 효율적이다.
    @Transactional
    public void bookRoom(Long roomId, Long userId) {
        // 1. 데이터 조회
        Room room = roomRepository.findById(roomId).orElseThrow();

        // 2. 비즈니스 로직 (검증 및 계산)
        if (!room.isAvailable()) {
            throw new IllegalStateException("이미 예약된 객실입니다.");
        }
        int price = room.getBasePrice();

        // 3. 데이터 저장 (상태 변경)
        room.setAvailable(false); // 엔티티는 그저 데이터를 담는 역할만 수행
        Booking booking = new Booking(roomId, userId, price);

        bookingRepository.save(booking);
        roomRepository.save(room);
    }
}

장점 : 코드를 위에서 아래로 읽어 내려가기만 하면 비즈니스 흐름이 완벽하게 이해된다. 객체 간의 복잡한 연관관계나 메시지 전달을 고민할 필요가 없어 학습 곡선이 매우 낮다.

3. 지옥이 되는 경우

이 패턴의 치명적인 단점은 요구사항이 복잡해질수로 서비스 계층이 통제 불능의 God Class로 비대해진다는 점이다.

서비스가 성공하여 예약 로직에 "VIP 회원 할인", "주말 할증", "연속 숙박 시 쿠폰 적용" 같은 복잡한 도메인 규칙이 추가된다고 가정해보자.

Bad Code

@Service
public class HotelBookingService {

    @Transactional
    public void bookRoom(Long roomId, Long userId, String couponCode, boolean isWeekend) {
        Room room = roomRepository.findById(roomId).orElseThrow();
        User user = userRepository.findById(userId).orElseThrow();

        if (!room.isAvailable()) { ... }

        // [Bad Code] 요구사항이 늘어날 때마다 if-else 분기가 끊임없이 추가된다.
        int price = room.getBasePrice();

        if (isWeekend) {
            price += 50000; // 주말 할증
        }

        if (user.getGrade() == Grade.VIP) {
            price = (int) (price * 0.8); // VIP 할인
        }

        if (couponCode != null) {
            Coupon coupon = couponRepository.findByCode(couponCode);
            if (coupon.isValid()) {
                price -= coupon.getDiscountAmount(); // 쿠폰 적용
                coupon.setUsed(true);
            }
        }

        // ... 코드가 수백 줄로 길어지며 유지보수가 불가능해진다.
        room.setAvailable(false);
        bookingRepository.save(new Booking(roomId, userId, price));
    }
}

문제점 1 (응집도 저하) : 가격을 계산하는 중요한 비즈니스 규칙이 Service 계층에 하드코딩 되어 있다. 만약 결제 서비스(PaymentService) 에서도 가격 계산 로직이 필요하다면 똑같은 코드를 복사 붙여넣기 해야 한다.

문제점 2 (테스트의 어려움) : 이 로직 하나를 테스트하기 위해 DB를 연결하거나 수많은 Repository를 Mocking 해야 한다.

결론

트랜잭션 스크립트를 선택하는 경우

- 비즈니스 로직이 단순한 CRUD 수준일 때

- 빠른 시장 진입(MVP 개발)이 최우선 목표일 때

- 개발팀의 객체 지향 및 DDD 숙련도가 낮을 때

도메인 모델(DDD)을 선택하는 경우

- 비즈니스 규칙이 복잡하고, 상태 변화가 다양한 도메인일 때

- 동일한 로직이 여러 서비스에서 중복해서 사용되기 시작할 때

개발자라면 명목적으로 최신 트렌드를 쫓기보다는, 현재 우리 시스템의 복잡도가 어느 수준인지 파악하고 그에 맞는 적절한 패턴을 취사선택하는 안목을 길러야 한다.

[Software Engineering] DDD(도메인 주도 설계)란

H.Sunny,, — Thu, 26 Mar 2026 10:48:12 +0900

실무를 하다 보면, 수천 줄이 넘어가는 거대한 Service 클래스를 마주하게 되는 날이 온다. 비즈니스 로직은 모두 서비스 계층에 몰려있고, 정작 데이터의 주체여야 할 Entity 클래스들은 그저 getter와 setter만 덩그러니 가지고 있는 데이터 덩어리로 전락해 있다. 이를 빈약한 도메인 모델(Anemic Domain Model)이라고 부른다.

시스템이 복잡해질수록 이런 구조는 유지보수를 지옥으로 이끈다. 이번 포스팅에서는 비즈니스 로직을 올바른 위치에 배치하고, 소프트웨어가 현실 세계의 비즈니스를 정확히 투영하도록 돕는 도메인 주도 설계(Domain Driven Design, DDD)에 대해 알아본다.

1. 문제상황 : 모든 짐을 짊어진 Serivce 계층

쇼핑몰에서 주문 취소 로직을 구현한다고 가정해 보자. 전통적인 트랜젝션 스크랩트(Transaction Script) 패턴에서는 서비스 계층이 모든 비즈니스 규칙을 검사하고 데이터의 상태를 직접 변경한다.

Bad Code : 빈약한 도메인 모델 (Anemic Domain Model)

// Entity는 그저 데이터를 담는 바구니(C 데이터 구조)에 불과하다.
@Entity
public class Order {
    private Long id;
    private OrderStatus status;
    private int totalAmount;

    // 무분별하게 열려있는 Getter / Setter
    public OrderStatus getStatus() { return status; }
    public void setStatus(OrderStatus status) { this.status = status; }
}

@Service
public class OrderService {

    @Transactional
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findById(orderId).orElseThrow();

        // 1. 서비스 계층에서 비즈니스 규칙(상태 검증)을 직접 확인한다.
        if (order.getStatus() == OrderStatus.SHIPPED) {
            throw new IllegalStateException("이미 배송된 주문은 취소할 수 없습니다.");
        }

        // 2. 서비스 계층에서 엔티티의 상태를 직접 변경한다.
        order.setStatus(OrderStatus.CANCELED);
        orderRepository.save(order);
    }
}

문제점

Order 객체는 자신의 상태를 스스로 제어하지 못하는 수동적인 존재다. 만약 다른 서비스에서도 주문 취소 기능이 필요하다면, 저 검증 로직 코드가 여기저기 중복해서 복사될 확률이 높다. 결국 객체 지향적이지 않은 절차지향적 코드가 된다.

2. 해결책 : 풍부한 도메인 모델 (Rich Domain Model)

DDD의 핵심 전술 중 하나는 데이터를 가진 객체가 비즈니스 로직도 함께 가져야 한다는 것이다. Serivce는 그저 도메인 객체를 불러오고, 도메인 객체에게 명령을 내리는 오케스트레이터(Orchestrator) 역할만 수행해야 한다.

Good Code: 도메인 객체 스스로 행동하기

// Entity가 비즈니스 로직의 중심이 된다. (Rich Domain Model)
@Entity
public class Order {
    private Long id;
    private OrderStatus status;
    private int totalAmount;

    // 1. Setter는 닫아두고, 명확한 의도를 가진 메서드를 열어둔다.
    public void cancel() {
        verifyNotShipped(); // 자기 자신의 상태는 스스로 검증한다.
        this.status = OrderStatus.CANCELED;
    }

    // 2. 도메인 규칙(비즈니스 로직)이 엔티티 내부에 응집된다.
    private void verifyNotShipped() {
        if (this.status == OrderStatus.SHIPPED) {
            throw new IllegalStateException("이미 배송된 주문은 취소할 수 없습니다.");
        }
    }
}

@Service
public class OrderService {

    @Transactional
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findById(orderId).orElseThrow();

        // 서비스는 그저 도메인 객체에게 행동을 위임(Delegation)할 뿐이다.
        order.cancel();
    }
}

이제 주문 취소에 대한 비즈니스 규칙은 오직 Order 클래스 내부에서만 관리한다. 응집도가 극대화되며, 코드를 읽었을 때 도메인의 규칙이 한눈에 파악된다.

3. DDD의 주요 구성 요소 (전술적 설계)

비즈니스 로직을 도메인으로 옮기는 과정에서 몇 가지 중요한 개념들을 활용하여 도메인을 모델링 한다.

엔티티(Entity)

- 고유한 식별자(ID)를 갖는 객체

- 속성값이 바뀌어도 식별자가 같다면 동일한 객체로 취급

- 위 예제의 Order, Member 등이 해당

값 객체(Value Object, VO)

- 식별자가 없고, 속성값 자체가 식별자인 객체

- 데이터의 불변성을 보장해야 하며, 값이 같으면 완전히 같은 객체로 취급 (equals & hashCode 재정의 필수)

- 예: Address(city, street, zipcode), Money(amount, currency)

에그리거트(Aggregate)

- 관련된 엔티티와 값 객체들의 묶음

- 데이터의 정합성을 유지하는 한 단위

- 루트 엔티티(Aggregate Root)를 통해서만 에그리거트 내부의 객체에 접근하고 수정 가능

- 예: Order 애그리거트는 내부적으로 OrderLine(주문 항목), ShippingInfo(배송 정보)를 가질 수 있으며, 외부에서는 오직 Order를 통해서만 내부 상태를 변경해야 함

4. 주의사항

무작정 모든 프로젝트에 DDD를 도입하려고 하면 배보다 배꼽이 더 커지는 오버엔지니어링(Over-engineering)을 겪게 된다.

단순 CRUD에는 사치다

게시판의 공지사항 읽기/쓰기 처럼 비즈니스 로직이 거의 없는 시스템에는 기존의 트랜젝션 스크립트 구조(데이터 중심 설계)가 훨씬 빠르고 효율적이다.

전술보다 전략이 우선이다

패키지 구조를 나누고 엔티티를 설계하는 전술적 설계보다 중요한 것은, 실무자와 개발자가 동일한 언어를 사용하는 보편적 언어의 확립과 도메인의 경계를 명확히 나누는 바운디드 컨텍스트(Bounded Context)를 설정하는 전략적 설계다.

결론

도메인 주도 설계(DDD)의 본질은 복잡한 소프트웨어 설계 패턴을 암기하는 것이 아니다. 우리가 해결하고자 하는 현실 세계의 비즈니스 도메인을 코드에 얼마나 객체지향적으로 잘 녹여내는가에 대한 끊임 없는 고민의 결과물이다.

[Spring] API 서버는 단일 스레드일까? (HashMap vs ConcurrentHashMap 실전 적용)

H.Sunny,, — Mon, 23 Mar 2026 10:41:57 +0900

"우리 API 서버는 요청을 동시에 여러 개 처리하는데, 이건 단일 스레드인가요? 멀티 스레드인가요?"
실무에서 주니어 개발자들의 코드르 리뷰하다 보면 가장 많이 발견되는 오해 중 하나다.

결론부터 명확하게 짚고 넘어가자면 우리가 흔히 쓰는 Spring Boot(Tomcat) API 서버는 완벽한 멀티 스레드 환경이다. 따라서 API 서버에 동시에 여러 요청이 들어온다는 것 자체가 이미 수많은 스레드가 동시에 돌아가고 있다는 뜻이다. 이번 포스팅에서는 API 서버 내부에서 스레드가 어떻게 동작하는지, 그리고 어떤 상황에서 HashMap을 써도 되고 언제 ConcurrentHashMap을 써야하는지 알아본다.

https://hsunnystory.tistory.com/253

[Java] ConcurrentHashMap 이란?

백엔드 시스템을 개발하다 보면 여러 Thread에서 동시에 접근해야 하는 인메모리 캐시나 세션 저장소를 구현해야 할 때가 있다. 이 때 가장 만만하게 쓰는 자료구조가 바로 Map이다. 필자도 그랬듯

hsunnystory.tistory.com

1. 오해 : API 서버는 멀티 스레드 환경이다 (Tomcat Thread Pool)

Node.js 같은 특별한 Non-blocking 싱글 스레드 환경이 아니라면, Java 계열의 Spring Boot(Tomcat)는 Thread Pool) 방식을 사용한다.

- 서버가 켜지면 Tomcat은 미리 스레드를 여러 개 생성한다.

- 사용자 A가 API를 호출하면, Thread Pool에서 Thread-1을 꺼내서 할당한다.

- 동시에 사용자 B가 API를 호출하면, Thread-2을 꺼내서 할당한다.

즉 동시에 들어오는 API 요청 개수 = 동시에 실행되는 스레드의 개수다. 따라서 당연히 멀티 스레드 환경이므로 동시성 문제를 고려해야 한다.

2. 그렇다면 API 서버에서는 무조건 ConcurrentHashMap만 써야 할까?

결론부터 말하면 절반만 맞은것이다. 핵심은 해당 Map 객체가 여러 Thread에 의해 공유되는 자원인지를 파악하는 것이다. 메모리 영역(Stack vs Heap)의 관점에서 두 가지 상황으로 나누어 보자.

상황 A: 지역 변수로 사용하는 경우 (HashMap 사용)

메서드 내부에서 생성된 변수는 각 Thread만의 독립적인 공간인 Stack 메모리에 저장된다. 즉, Thread-1과 Thread-2이 같은 메서드를 호출하더라도, 각자 자기만의 HashMap을 새로 만들어서 쓰기 때문에 절대 충돌이 일어나지 않는다.

@Service
public class OrderService {

    public void processOrder() {
        // [Good Code] 지역 변수: 스레드마다 각자의 Map을 생성하므로 매우 안전하다.
        // 동기화 비용이 없는 가장 빠른 HashMap을 쓰는 것이 정답이다.
        Map<String, Object> localMap = new HashMap<>();
        localMap.put("status", "READY");
        // ... 비즈니스 로직 ...
    }
}

상황 B: 전역변수로 사요하는 경우(ConcurrentHashMap 사용)

Spring의 @Controller, @Service, @Repository 같은 Bean들은 기본적으로 Singleton으로 생성된다.

즉, 애플리케이션 전체에 딱 1개만 존재하며 Heap 메모리에 올라간다. 수백 개의 Thread가 이 1개의 서비스 객체에 동시에 접근한게 된다.

@Service
public class CacheService {

    // [Good Code] 멀티 스레드가 공유하는 전역 상태이므로
    // 부분 잠금을 지원하는 ConcurrentHashMap을 사용해야 한다.
    private Map<String, Integer> globalCache = new ConcurrentHashMap<>();

    public void addCache(String key, int value) {
        globalCache.put(key, value);
    }
}

3. 아키텍처 원칙: Stateless 설계

사실 가장 좋은 방법은 스프링 Bean 안에 아에 전역 변수를 두지 않는 것이다.

- 데이터를 캐싱해야 한다면 애플리케잉션 메모리(Map)에 들고 있는 것보다, 외부의 Redis나 Memcached 같은 전문 캐시 서버에 위임하는 것이 훨씬 안전하고 서버 확장에 유리하다.

- 부득이하게 애플리케이션 내부 메모리에 데이터를 들고 있어야 하는 경우에만 제한적으로 ConcurrentHashMap을 사용하는 것이 바람직하다.

결론

- Spring API 서버는 기본적으로 Tomcat Thread Pool을 사용하는 Multi-Thread 환경이다.

- 메서드 내부의 지역변수로 Map을 쓸 때는 동시성 문제가 없으므로 제일 빠른 HashMap을 쓴다.

- Spring Bean(@Service)등의 멤버 변수로 Map을 선언하여 여러 요청이 공유하게 만들 때는 반드시 ConcurrentMap을 사용한다.

[Java] ConcurrentHashMap 이란?

H.Sunny,, — Tue, 17 Mar 2026 15:28:37 +0900

백엔드 시스템을 개발하다 보면 여러 Thread에서 동시에 접근해야 하는 인메모리 캐시나 세션 저장소를 구현해야 할 때가 있다. 이 때 가장 만만하게 쓰는 자료구조가 바로 Map이다. 필자도 그랬듯이 아무 생각 없이 HashMap을 사용했다가, 데이터 유실이나 무한 루프(Java 7 이하)로 인해 서버가 뻗어버리는 대참사를 겪게 된다.

1. 멀티스레드와 HashMap의 충돌

여러 스레드가 동시에 접속하는 트래픽 환경에서, 전역 변수로 선언된 HashMap에 데이터를 읽고 쓰는 상황을 가정해보자

Bad Code 1: 스레드 안정성(Thread-Safe)이 없는 HashMap

public class CacheService {
    // 여러 스레드가 동시에 접근하는 공유 자원
    private Map<String, Integer> cache = new HashMap<>();

    public void addCache(String key, int value) {
        // 멀티스레드 환경에서 동시에 put()이 호출되면
        // 데이터가 덮어씌워지거나, 내부 노드 링크가 꼬여버린다.
        cache.put(key, value);
    }
}

HashMap은 동기화(Synchronization) 처리가 전혀 되어 있지 않다. 두 스레드가 동시에 같은 해시 노드에 데이터를 삽입하려고 하면 경쟁 상태가 발생하여 데이터가 유실된다.

Bad Code 2: 무식한 동기화, HashTable과 SynchronizedMap

동시성 문제를 해결하기 위해 자바 레거시의 잔재인 HashTable이나 Collections.synchronizedMap()을 사용하는 경우

public class CacheService {
    // 스레드 안전성을 보장하지만 성능이 최악인 방식
    private Map<String, Integer> cache = Collections.synchronizedMap(new HashMap<>());
    // 혹은 private Map<String, Integer> cache = new Hashtable<>();

    public void addCache(String key, int value) {
        cache.put(key, value);
    }
}

이들은 내부적으로 모든 get(), put() 메서드에 전체 맵(Map) 단위의 잠금을 걸어버린다. 한 스레드가 데이터를 읽기만 하고 있어도, 다른 모든 스레드는 대기 상태에 빠지게 되어 심각한 병목현상을 유발한다.

2. 해결책 : ConcurrentHashMap

데이터의 안전성도 지키면서, 성능까지 끌어올리기 위해 ConcurrentHashMap를 사용한다.

public class CacheService {
    // 동시성 보장 + 뛰어난 성능
    private Map<String, Integer> cache = new ConcurrentHashMap<>();

    public void addCache(String key, int value) {
        cache.put(key, value);
    }

    public int getCache(String key) {
        return cache.get(key); // 읽기 작업에는 Lock이 걸리지 않아 매우 빠르다.
    }
}

3. ConcurrentHashMap의 특징

전체 맵에 락을 거는 HashTable과 달리, ConcurrentHashMap은 영리한 동기화 전략을 사용한다.

Node 단위 부분 잠금 (Lock Striping / Node Locking)

ConcurrentHashMap은 맵 전체가 아니라, 데이터가 삽입되는 해당 노드에만 잠금을 건다. 만약 스레드 A가 1번 노드에 데이터를 쓰고 있더라도, 스레드 B가 5번 노드에 데이터를 쓰는 작업은 전혀 방해받지 않고 동시에 실행된다.

CAS(Compare And Swap) 알고리즘 적용

새로운 노드를 삽입할 때, 해당 노드가 비어있다면 synchronized 락을 거는 대신 가벼운 CAS 알고리즘을 사용하여 원자적으로 값을 삽입한다. CAS는 현재 메모리의 값에 내가 기대하는 값과 같을 때만 새로운 값으로 교체하는 하드웨어 지원 원자적연산으로, 락을 획득하고 해제하는 오버헤드가 없어 매우 빠르다.

읽기(Read) 작업은 Lock-Free

가장 중요한 장점으로 get()으로 데이터를 읽어올 때는 Lock을 전혀 사용하지 않는다. 내부 데이터 구조에 volatile 키워드를 활용하여, 항상 최신 상태의 데이터를 읽어올 수 있도록 가시성을 보장한다.

결론

멀티스레드 환경에서 Map 자료구조가 필요하다면, 고민하지 말고 ConcurrentHashMap를 쓰자.

- 단일 스레드 환경 : HashMap (동기화 비용 없이 제일 빠름)

- 멀티 스레드 환경 : ConcurrentHashMap (부분 잠금 및 CAS 알고리즘으로 안전성과 성능 동시 확보)

[Design Pattern] 빌더 패턴(Builder Pattern) 란?

H.Sunny,, — Fri, 6 Mar 2026 11:36:20 +0900

개발을 하다 보면, 필드가 수십 개에 달하는 복잡한 객체를 생성해야 할 때가 많다. 특히 외부 시스템과 연동하거나, 인증 및 보안 관련 데이터를 다룰 때 더욱 그렇다.

1. 문제상황

IoT 기기 인증 시스템을 개발한다고 가정해보자. IotDevice라는 객체는 필수적인 필드(기기 ID, MAC)와 선택적인 필드(펌웨어 버전, 암호화 타입, 네트워크 상태 등)를 다양하게 가진다.

Bad Code 1: 점층적 생성자 패턴 (Telescoping Constructor)

가장 원시적인 방법은 매개변수의 개수를 늘려가며 생성자를 오버로딩(Overloading)하는 것이다.

public class IotDevice {
    private String deviceId;     // 필수
    private String macAddress;   // 필수
    private String firmwareVer;  // 선택
    private String cryptoType;   // 선택

    // 필수 필드만 받는 생성자
    public IotDevice(String deviceId, String macAddress) { ... }

    // 필수 + 선택 필드 1개
    public IotDevice(String deviceId, String macAddress, String firmwareVer) { ... }

    // 모든 필드를 받는 생성자
    public IotDevice(String deviceId, String macAddress, String firmwareVer, String cryptoType) { ... }
}

// 클라이언트 사용 시: 인자의 의미와 순서를 파악하기 매우 어렵다.
IotDevice device = new IotDevice("DEV-001", "00:1A:2B...", null, "RSA_2048");

문제점

매개변수가 많아질수록 클라이언트 코드를 작성하거나 읽기 어렵다. 특히 같은 타입(String)이 연속될 경우, 실수로 순서를 바꿔치기 해도 컴퍼일러가 잡아내지 못해 런타임 에러로 이어진다.

Bad Code 2: 자바빈즈 패턴(JavaBeans Pattern)

이 문제를 해결하기 위해 기본 생성바로 빈 객체를 만든 후, Setter 메서드를 호출하여 값을 채워 넣는 방식을 많이 사용한다.

IotDevice device = new IotDevice();
device.setDeviceId("DEV-001");
device.setMacAddress("00:1A:2B:3C:4D:5E");
device.setFirmwareVer("v1.2.4");
// ... 계속되는 Setter 호출

문제점

- 객체의 일관성 붕괴 :1회의 호출로 객체 생성이 끝나지 않는다. 필수 값이 모두 세팅되지 않은 상태로 객체가 중간에 사용될 위험이 있다.

- 불변성 상실 : Setter가 열려있으므로, 누군가 런타임에 객체의 상태를 변경할 수 있어 버그 추적이 어렵다.

2. 해결책 : 빌더 패턴

빌더 패턴은 점층적 생성자의 안전성과 자바빈즈 패턴의 가독성을 모두 취한 대안이다. 객체를 직접 생성하는 대신, 필수 매개변수만으로 빌더(Builder) 객체를 얻은 후, 빌더가 제공하는 일종의 Setter 메서드들로 선택 매개변수를 세팅한다. 마지막으로 build() 메서드를 호출하여 완전한 그리고 불변인 객체를 얻는다.

Good Code : 정적 내부 클래스 (Static Inner Class)를 활용한 빌더 구현

public class IotDevice {
    // 모든 필드는 final로 선언하여 불변성(Immutability)을 보장한다.
    private final String deviceId;
    private final String macAddress;
    private final String firmwareVer;
    private final String cryptoType;

    // private 생성자: 오직 Builder를 통해서만 객체를 생성할 수 있게 막는다.
    private IotDevice(Builder builder) {
        this.deviceId = builder.deviceId;
        this.macAddress = builder.macAddress;
        this.firmwareVer = builder.firmwareVer;
        this.cryptoType = builder.cryptoType;
    }

    // --- 정적 내부 클래스 Builder ---
    public static class Builder {
        // 필수 필드
        private final String deviceId;
        private final String macAddress;

        // 선택 필드 (기본값으로 초기화 가능)
        private String firmwareVer = "v1.0.0";
        private String cryptoType = "NONE";

        // 필수 필드는 Builder의 생성자로 받는다.
        public Builder(String deviceId, String macAddress) {
            this.deviceId = deviceId;
            this.macAddress = macAddress;
        }

        // 선택 필드는 메서드 체이닝(Method Chaining)을 위해 자기 자신(Builder)을 반환한다.
        public Builder firmwareVer(String firmwareVer) {
            this.firmwareVer = firmwareVer;
            return this;
        }

        public Builder cryptoType(String cryptoType) {
            this.cryptoType = cryptoType;
            return this;
        }

        // 최종 객체 생성 (여기서 유효성 검증 로직을 추가할 수 있다)
        public IotDevice build() {
            return new IotDevice(this);
        }
    }
}

클라이언트 코드 (빌더 사용)

public class Main {
    public static void main(String[] args) {
        // 메서드 체이닝을 통해 가독성이 비약적으로 상승한다.
        IotDevice authDevice = new IotDevice.Builder("DEV-999", "AA:BB:CC:DD:EE:FF")
                .firmwareVer("v2.1.0")
                .cryptoType("ECC_P256")
                .build();
    }
}

3. 장점

- 직관적인 가독성 : 어떤 필드에 어떤 값이 들어가는지 명확하게 보인다. 인자의 순서에 구애받지 않는다.

- 객체의 불변성(Immutable) 보장 : Setter가 없으므로 생성된 객체는 스레드 안전(Thread-safe)하며 상태가 변경되지 않는다.

- 유효성 검증의 용이성 : build() 메서드 내부에서 필수 값 누락이나 제약 조건 위반 등을 한 번에 검증할 수 있어 객체의 일관성을 유지할 수 있다.

4. Lombok과 @Builder

매번 위와 같이 긴 보일러플레이트(Boilerplate) 코드를 수작업으로 작성하기 번거롭다. Java에서는 Lombok 라이브러리의 @Builder 어노테이션을 활용하면 컴파일 타임에 자동으로 완벽한 빌더 클래스를 생성해 준다.

import lombok.Builder;

@Builder
public class IotDevice {
    private String deviceId;
    private String macAddress;
    private String firmwareVer;
    private String cryptoType;
}

단, Lombok을 사용할 때도 내부적으로 어떤 구조로 객체가 캡슐화되어 생성되는지 그 원리를 명확히 이해하고 쓰는 것과 모르고 쓰는 것은 아키텍처 설계 기능을 가르는 큰 차이가 된다.

결론

생성자의 매개변수가 4개 이상 넘어가거나, 앞으로 필드가 계속 추가될 가능성이 있다면 망설이지 말고 빌더 패턴을 도입하자. 코드를 작성할 때는 조금 더 수고스럽더라도, 미래의 나와 동료들이 코드를 읽고 유지보수할 때의 고통을 획기적으로 줄여줄 것이다.

[Design Pattern] 데코레이터 패턴(Decorator Pattern)이란?

H.Sunny,, — Thu, 5 Mar 2026 13:47:05 +0900

개발을 진행하다 보면 이미 완성된 객체에 새로운 기능을 동적으로 추가해야 할 때가 많다. 가장 먼저 떠오르는 방법은 상속(Inheritance)이지만, 요구사항이 복잡해질수록 상속만으로는 감당하기 어려운 클래스 폭발(Class Explosion) 문제에 직면하게 된다.

이번 포스팅에서는 상속의 한계를 극복하고, 객체를 유연하게 확장할 수 있는 데코레이터 패턴(Decorator Pattern)에 대해 알아본다.

1. 데코레이터 패턴이란?

데코레이터 패턴은 객체에 추가적인 기능을 동적으로 덧붙이는(Wrapping) 패턴이다. 서브클래스를 만드는 대신, 객체를 감싸는 장식자(Decorator) 클래스를 두어 런타임에 유연하게 기능을 확장한다.

- Component : 기본 기능을 정의하는 최상의 인터페이스

- ConcreteComponent : 기본 기능을 구현하는 실제 핵심 객체

- Decorator : Component를 구현하면서(IS-A), 내부에 Component 객체를 품고 있는(HAS-A) 추상 클래스

- ConcreteDecorator : 실제 부가 기능을 덧붙이는 장식자 클래스

2. 상속의 한계

사용자에게 알림을 보내는 시스템을 개발한다고 가정해보자. 초기에는 이메일 알림만 필요해서 Notifier 라는 기본 클래스를 만들었다. 하지만 요구사항은 늘 변한다. SMS 알림도 추가해야 할 수도 있고, 이메일 알림도 추가해야 할 수도 있다.

Bad Code: 상속을 남용한 경우

// 기본 알림
class EmailNotifier { ... }

// 요구사항이 늘어날 때마다 무한히 증식하는 서브클래스들
class SmsNotifier extends EmailNotifier { ... }
class SlackNotifier extends EmailNotifier { ... }
class SmsAndEmailNotifier extends EmailNotifier { ... }
class SlackAndSmsAndEmailNotifier extends EmailNotifier { ... }

위 방식의 치명적인 단점은 기능의 조합(Combination)이 발생할 때마다 새로운 클래스를 하드코딩해야 한다는 점이다. 옵션이 몇 개만 늘어나도 수십 개의 클래스가 생성되어 유지보수가 불가능해진다.

3. 데코레이터 패턴 적용

기본기능 정의(Component & ConcreteComponent)

// 1. Component: 공통 인터페이스
public interface Notifier {
    void send(String message);
}

// 2. ConcreteComponent: 기본 알림(이메일)
public class BasicNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("이메일 전송: " + message);
    }
}

장식자 구현 (Decorator)

데코레이터 패턴의 핵심이다. 자신이 장식할 대상을 주입받아 보관하고, 기본 요청은 그 대상에게 위임한다.

// 3. Decorator: 장식자 추상 클래스
public abstract class NotifierDecorator implements Notifier {
    private final Notifier wrapper; // 감싸고 있는 실제 대상 객체

    public NotifierDecorator(Notifier wrapper) {
        this.wrapper = wrapper;
    }

    @Override
    public void send(String message) {
        wrapper.send(message); // 기본 기능은 감싼 객체에게 위임
    }
}

부가 기능 추가(ConcreteDecorator)

// 4. ConcreteDecorator: SMS 알림 추가
public class SmsNotifier extends NotifierDecorator {
    public SmsNotifier(Notifier wrapper) {
        super(wrapper);
    }

    @Override
    public void send(String message) {
        super.send(message); // 내부에 감싼 객체의 알림 먼저 실행
        System.out.println("SMS 전송: " + message); // 나만의 부가 기능 실행
    }
}

// 4. ConcreteDecorator: Slack 알림 추가
public class SlackNotifier extends NotifierDecorator {
    public SlackNotifier(Notifier wrapper) {
        super(wrapper);
    }

    @Override
    public void send(String message) {
        super.send(message);
        System.out.println("Slack 메신저 전송: " + message);
    }
}

클라이언트 코드 실행

클라이언트는 런타임에 원하는 알림 방식만 레고 블록 조립하듯 동적으로 연결하면 된다.

public class NotificationSystem {
    public static void main(String[] args) {
        // 상황 1. 이메일만 보내기
        Notifier simpleNotifier = new BasicNotifier();
        simpleNotifier.send("서버 점검 안내");
        // 출력: 이메일 전송: 서버 점검 안내

        System.out.println("-----------------");

        // 상황 2. 이메일 + SMS + Slack 모두 보내기 (동적 조합)
        // 객체가 객체를 계속해서 감싸는 구조
        Notifier complexNotifier = new SlackNotifier(
                                      new SmsNotifier(
                                          new BasicNotifier()));
        complexNotifier.send("장애 발생 경고!");
        // 출력:
        // 이메일 전송: 장애 발생 경고!
        // SMS 전송: 장애 발생 경고!
        // Slack 메신저 전송: 장애 발생 경고!
    }
}

4. 결론

데코레이터 패턴의 가장 큰 장점은 OCP(개방-폐쇄 원칙)를 완벽하게 준수한다는 점이다. 기존 코드(BasicNotifier, NotifierDecorator)를 단 한줄도 수정하지 않고, 새로운 장식자 클래스만 추가하면 기능을 무한히 조합하고 확장할 수 있다.

- 활용 : Java의 I/O 스트림 (BufferedReader(new FileReader(...))), Spring 프레임워크의 HTTP Request/Response Wrapper 객체 처리 등에서 널리 쓰인다.

- 주의점 : 장식자를 과도하게 사용하면 자잘한 클래스가 너무 많아지고, 초기화 코드가 길어져 (new A(new B(new C())) 가독성이 떨어질 수 있다. 이때는 팩토리(Factory)나 빌더(Builder) 패턴을 조합해 생성 과정을 깔끔하게 캡슐화하는 것이 좋다.

기능의 조합이 다양하게 발생할 여지가 있다면, 무턱대고 클래스 상속 트리부터 그리기 전에 객체를 겹겹이 감싸서 해결할 수 있을지 고민해보자.

[OOP] 다형성 리팩토링 : 인터페이스(Interface) vs 추상 클래스 (Abstract) 완벽 비교

H.Sunny,, — Tue, 3 Mar 2026 12:20:04 +0900

이전 포스팅에서 다형성(Polymorphism)을 활용해 지긋지긋한 if-else 분기문을 걷어내는 리팩토링 과정을 살펴보았다.

https://hsunnystory.tistory.com/235

[Design Pattern] 다형성(Polymorphism)으로 if-else 없애기

코드를 짜다 보면 기능은 정상적으로 동작하지만, 뭔가 지저분하고 유지보수하기 힘든 코드를 마주하게 된다. 이를 코드 스멜(Code Smell)이라고 한다. 대표적인 코드 스멜 중 하나가 객체의 타입

hsunnystory.tistory.com

근데 여기서 생기는 의문점이 하나 있다.

다형성을 위한 부모 타입으로 interface를 쓰는 게 좋을까? 아니면 abstract class를 쓰는게 좋을까?

결론부터 말하자면 두 가지 모두 다형성을 구현할 수 있지만, 객체 지향 설계의 관점(IS-A vs CAN-DO)과 코드의 재사용성 측면에서 명확히 쓰임새가 다르다.

1. 선택의 핵심 기준 : 상태(Stace)와 IS-A 관계

가장 먼저 따져야할 것은 하위 클래스들이 공통적인 상태(필드 변수)와 기본 로직을 공유하는가 이다.

- 추상 클래스 (Abstract Class) : 하위 클래스들과 IS-A (이것은 ~이다) 관계로 강하게 묶일 때 사용한다. 자식들이 공통으로 가져야 할 상태(멤버 변수)와 중복되는 구현 코드를 부모가 제공해야 할 때 적합하다.

- 인터페이스 (Interface) : 클래스의 종류와 상관 없이 CAN-DO (~을 할 수 있다) 관점에서 동일한 행위(메서드 규칙)만 보장하면 될 때 사용한다. 인터페이스는 원칙적으로 상태(인스턴스 변수)를 가질 수 없다.

2. Interface가 더 좋은 경우 (행위 중심의 다형성)

단순히 if-else 분기문을 없애고 특정 로직(알고리즘)만 상황에 따라 갈아끼우는 목적이라면, 인터페이스가 압도적으로 유리하다.

자바는 다중 상속을 지원하지 않기 때문에, 추상 클래스를 부모로 선택하면 하위 클래스는 더 이상 다른 클래스를 상속받을 수 없는 제약에 걸린다. 반면 인터페이스는 구현(implements)의 개수 제한이 없으므로 확장에 훨씬 유연하다.

Good Code : 인터페이스를 활용한 결제 로직 다형성

// 결제라는 '행위'만 규정하므로 인터페이스가 적합하다. (상태 공유 불필요)
public interface PaymentStrategy {
    void pay(int amount);
}

// 각 결제 수단은 각자의 로직만 책임진다.
public class KakaoPay implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("카카오페이로 " + amount + "원 결제");
    }
}

public class CreditCardPay implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("신용카드로 " + amount + "원 결제");
    }
}

// 클라이언트 (if-else 분기문 없이 다형성으로 처리)
public class OrderService {
    // 런타임에 외부에서 주입받은 전략(인터페이스)만 실행하면 된다.
    public void processPayment(PaymentStrategy strategy, int amount) {
        strategy.pay(amount);
    }
}

3. Abstract Class가 더 좋은 경우 (상태와 공통 기능 공유)

모든 객체가 고유의 생명력(hp, name 등)을 가지는 게임 캐릭터 시스템을 생각해보자. 모든 캐릭터는 이러한 상태를 가져야 하고, move() 같은 공통 로직은 중복해서 작성할 필요가 없다.

이럴 때는 인터페이스만으로 해결하기 어렵다. 필드 변수를 가질 수 없고, 공통 구현을 강제하면서 재사용 하기에는 한계가 있기 때문이다.

Good Code : 추상 클래스를 활용한 상태/행위 공유

public abstract class Character {
    // 1. 공통 상태 (인터페이스에서는 불가능한 인스턴스 변수)
    protected String name;
    protected int hp;

    public Character(String name, int hp) {
        this.name = name;
        this.hp = hp;
    }

    // 2. 공통 로직 (코드 중복 방지)
    public void move() {
        System.out.println(this.name + "가(이) 이동합니다.");
    }

    // 3. 다형성을 위한 추상 메서드 (자식이 반드시 자신만의 방식으로 구현)
    public abstract void attack();
}

public class Warrior extends Character {
    public Warrior(String name, int hp) {
        super(name, hp); // 부모의 상태 초기화 활용
    }

    @Override
    public void attack() {
        System.out.println("대검 휘두르기!");
    }
}

4. 결론

실무에서는 OCP(개방-폐쇄 원칙)를 준수하면서도 코드 중복을 막기 위해 인터페이스와 추상 클래스를 조합해서 사용하는 경우가 가장 많다.

a. 최상위에는 interface를 두어 다형성과 유연성을 확보한다.

b. 인터페이스를 부분적으로 구현하는 abstract class를 중간에 두어 공통 로직을 처리(중복 제거)한다.

c. 구체 클래스는 추상 클래스를 상속받아 핵심 로직만 구현한다.

자바 컬렉션 프레임워크(List 인터페이스 -> AbstractList 추상 클래스 -> ArrayList 구체 클래스)가 바로 이 패턴으로 설계되어 있다.

if-else를 제거하기 위해 다형성을 적용할 때, 다음을 기억하자

- 기본 원칙 : 유연성 확보를 위해 인터페이스(Interface)를 우선적으로 고려한다.

- 변경의 타이밍 : 하위 객체들이 서로 공유해야 할 데이터(상태)가 생기거나, 겹치는 핵심 로직이 발생하여 코드 중복이 심해진다면 그 때 추상 클래스(Abstract Class)로 리팩토링하거나 골격 구현 패턴을 도입한다.

[Refactoring] if-else 지옥에서 탈출하기 Abstract 심화편

H.Sunny,, — Fri, 27 Feb 2026 10:19:42 +0900

새로운 요구사항이 올 때마다 else if를 추가하고 있다면 그 코드는 썩어가고 있다는 신호다.

이번 포스팅에서는 abstract를 활용한 다형성(Polymorphism)으로 지저분한 분기문을 깔끔하게 리팩토링하는 과정에 대해 작성한다.

1. 문제 상황 (Bad Code)

게임의 캐릭터 스킬 시스템을 구현한다고 가정해보자.

class Character {
    String type; // "WARRIOR", "WIZARD", "ARCHER"

    void attack() {
        if (type.equals("WARRIOR")) {
            System.out.println("대검 휘두르기!");
            // 전사만의 복잡한 데미지 공식...
        } else if (type.equals("WIZARD")) {
            System.out.println("파이어볼 발사!");
            // 마법사만의 마나 소모 로직...
        } else if (type.equals("ARCHER")) {
            System.out.println("활 쏘기!");
            // 궁수만의 화살 카운트 로직...
        }
        // 새로운 직업 "THIEF"가 추가되면? -> 여기 또 수정해야 함 (OCP 위반)
    }
}

이 코드의 문제점은 새로운 직업이 추가될 때마다 기존 코드를 수정해야 한다는 점이다. 실수로 else if를 잘못 건드리면 전체가 망가진다.

2. 리팩토링 (Good Code)

공통점은 묶고(추상화), 차이점은 분리한다.

Step 1. 추상 클래스 추출

abstract class Character {
    // 공통 속성
    String name;
    int hp;

    // 공통 기능
    void move() {
        System.out.println("이동합니다.");
    }

    // 변하는 부분 -> 추상 메서드로 위임
    abstract void attack();
}

Step 2. 각 직업별 클래스 구현

class Warrior extends Character {
    @Override
    void attack() {
        System.out.println("대검 휘두르기!");
    }
}

class Wizard extends Character {
    @Override
    void attack() {
        System.out.println("파이어볼 발사!");
    }
}

Step 3. 클라이언트 코드 (다형성 활용)

public class Game {
    public static void main(String[] args) {
        // 상황에 따라 캐릭터만 갈아끼우면 됨
        Character myChar = new Warrior();
        myChar.attack(); // 대검 휘두르기!

        myChar = new Wizard();
        myChar.attack(); // 파이어볼 발사!
    }
}

3. 결론

리팩토링의 핵심은 변하는 것과 변하지 않는 것을 분리하는 것이다.

- move() 처럼 모든 캐릭터가 똑같이 하는 건 부모(추상 클래스)에 둔다.

- attack() 처럼 캐릭터마다 다른 건 자식에게 맡긴다. (abstract method)

이렇게 구조를 잡아두면, 나중에 Thief 클래스가 추가 되어도 Game 클래스나 Warrior 클래스는 건드릴 필요가 없다. 이것이 바로 객체 지향의 묘미다.

[Design Pattern] 추상 클래스(Abstract Class) 활용편 - 템플릿 메서드 패턴(Template Method Pattern)

H.Sunny,, — Thu, 26 Feb 2026 10:57:47 +0900

추상클래스(Abstract Class) 기본편(https://hsunnystory.tistory.com/247) 에서 개념을 익혔다면, 이제 실무에서 사용하는 방법인 템플릿 메서드 패턴(Template Method Pattern)에 대해 알아보도록 한다.

1. 템플릿 메서드 패턴(Template Method Pattern) 이란?

전체적인 흐름(알고리즘의 뼈대)은 부모가 잡고, 세부적인 구현은 자식에게 맡기는 패턴이다.

예를 들어 라면 끓이기를 보면,

a. 물을 끓인다. (공통)

b. 면을 넣는다. (종류마다 다름: 굵은 면, 얇은 면)

c. 스프를 넣는다. (종류마다 다름: 매운 맛, 안매운 맛)

d. 기다린다 (공통)

여기서 a,d는 부모(추상 클래스)가 정의하고, b,c는 자식(구현 클래스)에 채워 넣게 하는 것이다.

2. 코드 예제: 데이터 분석기(File vs DB)

데이터를 읽어서(read) -> 분석하고(analyze) -> 결과를 쓰는(write) 프로그램이 있다고 가정하자. 전체 흐름은 같지만, 리소스를 어디서 읽느냐에 따라 로직이 다르다.

Step 1. 추상 클래스 (템플릿 정의)

public abstract class DataAnalyzer {

    // 템플릿 메서드: 전체 흐름을 조율한다.
    // final을 붙여서 자식이 흐름을 마음대로 바꾸지 못하게 막는다.
    public final void process() {
        readData(); // 자식이 구현
        analyze();  // 공통 로직
        writeData(); // 자식이 구현
    }

    // [추상 메서드] 자식이 반드시 구현해야 함 (Hook)
    abstract void readData();
    abstract void writeData();

    // [일반 메서드] 공통 로직
    private void analyze() {
        System.out.println("데이터를 분석합니다... (공통 로직)");
    }
}

Step 2. 구현 클래스

public class FileDataAnalyzer extends DataAnalyzer {
    @Override
    void readData() {
        System.out.println("파일에서 데이터를 읽어옵니다.");
    }

    @Override
    void writeData() {
        System.out.println("파일로 리포트를 저장합니다.");
    }
}

public class DbDataAnalyzer extends DataAnalyzer {
    @Override
    void readData() {
        System.out.println("DB에서 데이터를 조회합니다.");
    }

    @Override
    void writeData() {
        System.out.println("DB 테이블에 결과를 적재합니다.");
    }
}

Step 3. 실행 (Client)

public class Main {
    public static void main(String[] args) {
        DataAnalyzer analyzer = new FileDataAnalyzer();
        analyzer.process();
        // 출력:
        // 파일에서 데이터를 읽어옵니다.
        // 데이터를 분석합니다... (공통 로직)
        // 파일로 리포트를 저장합니다.
    }
}

3. 장점

- 제어의 역전(IoC) : 자식 클래스가 흐름을 제어하는 것이 아니라, 부모 클래스가 흐름을 쥐고 자식의 코드를 호출한다.

- 코드 중복 최소화 : 변하지 않는 부분(알고리즘 구조)을 한곳에 몰아 넣어 유지보수가 쉽다.

실무에서 전체 로직은 비슷한데 특정 부분만 조금씩 다른 경우가 있다면, 주저 말고 abstract 클래스와 템플릿 메서드 패턴을 사용해보자

[Java] 추상 클래스(Abstract class) 란? (기본편)

H.Sunny,, — Fri, 13 Feb 2026 15:00:15 +0900

신입 개발자 시절 가장 이해가 안 갔던 개념이 바로 추상 클래스(Abstract class) 였다. "그냥 일반 클래스로 만들면 되지 왜 굳이 abstract를 붙여서 객체 생성도 못 하게 막는 이유가 뭘까?"

1. 추상 클래스란?

abstract 키워드가 붙은 클래스는 미완성 설계도라고 보면 이해가 쉽다.

설계도가 미완성이라서 이 클래스 자체로는 객체를 생성할 수 없다. 오직 상속받은 자식 클래스를 통해서만 완성되고 사용될 수 있다.

- 추상 메서드(abstract method) : 껍데기만 있고 구현부가 없는 메서드. 자식이 반드시 구현해야 한다.

- 일반 메서드 : 자식들이 공통으로 사용할 기능

2. 사용 이유

강제성 부여 (규격의 통일)

자식 클래스에게 메서드를 무조건 만들게 강제할 수 있다. 실수로 구현을 빼먹는 것을 방지한다.

중복 코드 제거 (공통 기능 묶기)

모든 자식들이 똑같이 쓰는 기능은 부모(추상 클래스)에 구현해두고, 자식은 가져다 쓰기만 하면 된다.

3. 예제

결제 수단은 여러가지(카드, 무통장, 포인트)가 있지만, 결제하기라는 핵심 동작은 같아야한다.

[Bad Code] : 일반 클래스 상속

class Payment {
    void pay() { /* 아무것도 안 함? 혹은 기본 로직? 애매함 */ }
}

class CardPayment extends Payment {
    // 개발자가 실수로 pay() 오버라이딩을 안 해도 에러가 안 난다.
    // 결제 로직이 없는데 프로그램은 돌아가는 대참사 발생.
}

[Good Code] : 추상 클래스 사용

// 1. 추상 클래스 선언
abstract class Payment {
    // [공통 기능] 모든 결제 수단은 로깅이 필요하다.
    public void logging() {
        System.out.println("결제 로그를 남깁니다.");
    }

    // [추상 메서드] 결제 방식은 자식마다 다르므로, 구현을 강제한다.
    abstract void processPay();
}

// 2. 자식 클래스 구현
class CardPayment extends Payment {
    @Override
    void processPay() { // 이걸 구현 안 하면 컴파일 에러 발생! (안전장치)
        System.out.println("신용카드 결제 진행");
    }
}

class CashPayment extends Payment {
    @Override
    void processPay() {
        System.out.println("현금 결제 진행");
    }
}

4 인터페이스(Interface) vs 추상 클래스(abstract class)

- 추상 클래스 : IS-A 관계. 자신의 기능(일반 메서드/필드)을 물려주면서 기능을 확장하는 것이 목적, 상태(멤버 변수)를 가질 수 있다.

Ex) Galaxy 25는 SmartPhone 이다. (부품 상태를 공유)

- 인터페이스 : HAS-A/Can-do 관계. 서로 다른 클래스들이 같은 동작을 하도록 규약한 정하는 것이 목적

EX) Galaxy 25와 Iphone는 둘다 CALL 할 수 있다.(전화 할 수 있다는 동작만 정의)

요약

- 공통된 필드와 메서드가 많고, 기본 구현을 제공하고 싶다면 abstract를 써라

- 단순히 동작의 규격만 맞추고 싶다면 interface를 써라

[IntelliJ] 인텔리제이 단축키 모음(Windows)

H.Sunny,, — Thu, 12 Feb 2026 21:39:26 +0900

1. 만능 해결사(필수)

Alt + Enter (Show Context Actions)

- 기능 : 에러 수정, import 추가, 코드 제안 등 모든 문제 해결

- 상황 : 빨간 줄이 있다? 무조건 눌러보자

Shift + Shift (Search Everywhere)

- 기능 : 파일, 클래스, 설정, 기능 까지 모든 검색

- 상황 : 특정 파일을 찾거나 설정 변경 등

Ctrl + E (Recent Files)

- 기능 : 최근 열었던 파일 목록

- 상황 : 상단 탭(Tab) 클릭하지 말자

2. 네비게이션

프로젝트 탐색기(Project View)를 마우스로 뒤적거리는 시간을 없애자

Ctrl + N

클래스 이름으로 찾기

Ctrl + Shift + N

파일 이름으로 찾기.(xml, properties 등)

Ctrl + B

선언부(Declaration)로 이동

Ctrl + Alt + B

구현체(Implementation)로 이동.

Ctrl + F12

파일 구조 보기. 현재 클래스 내의 모든 메서드와 필드를 리스트로 보여준다.

3. 편집(작성)

Ctrl + D

줄 복제 (Duplicate Line)

Ctrl + Y

줄 삭제 (Delete Line)

Alt + Shift + ↑ / ↓ : 줄이동

잘라내기(Ctrl+X) -> 붙여넣기(Ctrl+V) 대신 줄 자체를 위아래로 이동

Ctrl + Alt + L : 코드 포맷팅 (Reformat Code)

들여쓰기 정렬

4. 리팩토링(수정)

변수명 일괄 변경

Shift + F6 : 이름 변경(Rename)

변수, 메서드, 클래스 이름을 안전하게 바꾼다. 참조하고 있는 모든 곳이 동시에 바뀐다.

Ctrl + Alt + V : 변수 추출 (Extract Variable)

ex) memberRepository.findByID(1L).get() 뒤에 커서 두고 누르면 Member member = ... 자동생성

Ctrl + Alt + M : 메서드 추출 (Extract Method)

지저분한 로직을 드래그해서 누르면, 깔끔하게 메서드로 분리

5. 다중 커서

같은 단어를 여러 개 동시에 수정하고 싶을 때 쓰는 기능

Alt + J : 다음 같은 단어 선택

변수명에 커서를 두고 Alt + J 를 연타하면, 아래에 있는 변수들이 하나씩 추가로 잡힌다. 그 상태에서 타이핑하면 동시에 수정된다.

[Spring] 전략 패턴(Strategy Pattern) : Map 주입으로 if-else 제거하기 (OCP 준수)

H.Sunny,, — Wed, 11 Feb 2026 13:23:55 +0900

지난 포스팅에서 if-else 분기문이 가지는 유지보수의 문제점을 확인했다.

https://hsunnystory.tistory.com/235

[Design Pattern] 다형성(Polymorphism)으로 if-else 없애기

hsunnystory.tistory.com

이번 포스팅에서는 스프링 컨터이너의 강력한 기능인 Map 주입을 활용해보고자 한다.

1. 스프링의 Map 주입 기능

스프링은 필드 타입을 Map<String, Interface>로 선언하면, 해당 인터페이스를 구현한 모든 빈(Bean)을 찾아서 맵에 담아준다.

이때 Key는 빈 이름(Bean Name), Value는 빈(Bean) 객체가 된다.

2. 구현 코드(Refactoring)

Step 1. 빈 이름 지정

명확한 매핑을 위해 @Component에 이름을 지정한다.

@Component("NAVER") // 빈 이름 지정
public class NaverPay implements Payment { ... }

@Component("KAKAO")
public class KakaoPay implements Payment { ... }

Step 2. Service 리팩토링

@Service
@RequiredArgsConstructor
public class PaymentService {

    // [핵심] 모든 구현체가 여기로 들어옴
    // {"NAVER": naverPay객체, "KAKAO": kakaoPay객체}
    private final Map<String, Payment> paymentMap;

    public void pay(String payMethod, int amount) {
        // 1. 맵에서 꺼내기 (O(1))
        Payment payment = paymentMap.get(payMethod);

        // 2. 예외 처리
        if (payment == null) {
            throw new IllegalArgumentException("지원하지 않는 결제 방식");
        }

        // 3. 실행
        payment.pay(amount);
    }
}

이제 TossPay가 추가되어도 PaymentService는 수정할 필요가 없다. 그저 @Component("TOSS")가 붙은 클래스만 하나 만들면 끝이다.

3. 문자열(String) 대신 Enum 사용하기

NAVER, KAKAO 같은 문자열을 그대로 쓰는 것은 오타 위험이 있다. Enum을 활용하면 타입 안정성 까지 챙길 수 있다.

@Getter
@RequiredArgsConstructor
public enum PayType {
    NAVER("NAVER"),
    KAKAO("KAKAO");

    private final String beanName; // 빈 이름을 필드로 가짐
}

// Controller나 Service 호출 부
public void pay(PayType payType, int amount) {
    // Enum에서 빈 이름을 꺼내서 Map 조회
    Payment payment = paymentMap.get(payType.getBeanName());
    payment.pay(amount);
}

결론

스프링의 IoC 컨터이너는 단순히 객체를 만들어주는 것을 넘어, 다형성을 극대화할 수 있는 도구들을 제공한다. If-else 가 자꾸 늘어난다면, 혹은 switch 문이 보인다면 Map 주입을 쓸 수 없을지 고민해보자.

슈도코드(Pseudocode) 작성법 및 예시

H.Sunny,, — Tue, 10 Feb 2026 10:42:20 +0900

개발을 하다 보면 키보드에 손부터 올리는 경우가 많다. 하지만 복잡한 알고리즘 문제를 풀거나 새로운 기능을 개발할 때, 무작정 코드부터 치기 시작하면 중간에 논리가 꼬여 싹 다 지우는 경험을 하게 된다.

이 때 필요한 것이 바로 슈도코드(Pseudocode)다. 건축으로 치면 설계도에 해당한다.

1. 슈도코드(Psudocode)란

가짜를 뜻하는 Pseudo와 Code의 합성어로 컴퓨터가 아닌 사람이 읽기 위해 작성한 코드를 말한다. 특정 프로그래밍 언어의 문법에 얽매이지 않고, 프로그램의 논리적 흐름을 일반적인 언어와 코딩 스타일을 섞어 흉내 낸 것이다.

2. 필요성

- 언어 독립성 : Java 개발자와 C개발자가 서로 코드를 몰라도 슈도코드로 대화하면 로직을 이해할 수 있다.

- 논리 집중 : 세미콜론 빼먹었는지, 괄호가 맞는지 신경 쓸 필요 없이 어떻게 해결할까에만 집중할 수 있다.

- 수정 용이 : 코드를 다 짜고 나서 구조를 바꾸려면 대공사지만, 슈도코드는 그냥 지우개로 지우면 된다.

3. 작성 규칙

슈도코드는 문법이 정해져 있지 않다. 다른사람이 알아볼 수만 있으면 된다. 하지만 통용되는 관례는 있다.

- 키워드는 대문자로 : IF, ELSE, WHILE, FOR, RETURN, PRINT 등 명령어는 대문자로 써서 눈에 띄게 한다.

- 들여쓰기 : 계층 구조를 파악하기 위해 들여쓰기는 필수다.

- 간결함 : int a = 0; 처럼 구체적으로 쓰기 보단 set a to 0 처럼 쓴다.

4. 예시

[슈도 코드]

FUNCTION FindMax(array)
    Set max_value to array[0]

    FOR each number IN array
        IF number > max_value THEN
            Set max_value to number
        END IF
    END FOR

    RETURN max_value
END FUNCTION

[실제 코드]

public int findMax(int[] array) {
    int maxValue = array[0];

    for (int number : array) {
        if (number > maxValue) {
            maxValue = number;
        }
    }
    return maxValue;
}

5. 작성 팁

- 너무 자세히 쓰지 마라 : i++, System.out.println 같이 특정 언어의 문법을 너무 많이 섞으면 슈도코드의 장점이 사라진다.

- 너무 추상적으로 쓰지 마라 : 단순히 정렬한다라고 쓰면 안된다. 버블 정렬을 수행한다 처럼 구현 가능한 수준이어야 한다.

- 한글로 써도 된다

만약(IF) 점수가 60점 이상이면
"합격" 출력
아니면(ELSE)
"불합격" 출력

결론

생각할 시간이 부족해서 코딩부터 한다는 말은 틀렸다. 생각을 정리하지 않고 코딩하면 디버깅하는 데 시간이 배로 든다.

복잡한 문제를 만났다면, IDE가 아니라 메모장을 먼저 켜는 습관을 들이자

[IntelliJ] 인텔리제이 꿀팁 모음(HTTP Client, 단축키, 디버깅 등)

H.Sunny,, — Mon, 9 Feb 2026 14:54:17 +0900

개발자라면 누구나 한 번쯤 "나는 이 비싼 IDE를 메모장처럼 쓰고 있는건 아닐까" 라는 의문을 가져본 적이 있을 것이다. 특히 Ctrl+C, Ctrl+V 와 기본적인 빌드만 하고 있다면, 인텔리제이가 가진 강력한 무기의 10%도 못 쓰고 있는 셈이다.

1. Postman이 필요 없다 : .http (HTTP Client)

인텔리제이에는 강력한 HTTP Client가 내장되어 있다. Postman 같은 무거운 툴을 켤 필요 없이, 프로젝트 내에서 API 명세서처럼 관리하고 테스트할 수 있다.

사용법

프로젝트 내에 확장자가 .http인 파일을 생성한다.

장점

- Git으로 버전 관리가 가능하다. (팀원과 API 테스트 케이스 공유 가능)

- 환경 변수(http-client.dnv.json)를 설정해 로컬/개발/운영 서버를 쉽게 오가며 테스트 할 수 있다.

EX)

HTTP
### 1. 유저 조회 API 테스트
GET http://localhost:8080/api/users/1
Accept: application/json

### 2. 유저 생성 (JSON Body)
POST http://localhost:8080/api/users
Content-Type: application/json

{
"name": "Seon",
"age": 30
}

작성 후 라인 옆의 초록색 ▶ 버튼만 누르면 바로 요청이 전송되고 결과가 하단에 노출된다.

2. Git보다 강력한 보험 : Local History

가끔 코드를 수정하다가 Ctrl+Z 로도 복구가 안되고, 아직 Commit도 안해서 망연자실한 적이 있을것이다. 이때 Local History를 쓰면 된다.

기능

인텔리 제이는 파일의 변경 사항을 자체적으로 계속 기록하고 있음 (Git 커밋 여부와 상관없음)

사용법

프로젝트나 파일 우클릭 -> Local History -> Show History

활용

실수로 지운 파일 복구, 30분 전 코드로 롤백 등이 가능

3. 필수 단축키

영역 확장/축소

- 단축키 : Ctrl + W (확장) / Ctrl + Shift + W (축소)

- 설명 : 커서가 위치한 단어 -> 문장 -> 블록 -> 메서드 전체 순으로 선택영역이 스마트하게 확장

- 활용 : if 문 전체를 복사하거나, 메서드 본문만 긁어올 때 사용

클립보드 히스토리

- 단축키 : Ctrl + Shift + V

- 설명 : 방금 복사한 거 말고, 아까 복사했던 그 코드가 필요할 때가 있다. 인텔리제이는 과거의 복사 기록(기본 5개 이상)을 기억하고 있다.

- 활용 : 여러 곳에서 변수명을 복사해 두고, 순서대로 붙여넣기 할 때 유용하다.

줄 이동 및 복제

- 이동 : Alt + Shift + ↑,↓

- 복제 : Ctrl + D

- 설명 : 코드를 잘라내기(Ctrl+X)해서 붙여넣기(Ctrl+V) 하지 말고, 그냥 그 라인을 잡고 위아래로 옮기면 된다.

최근 수정 위치로 이동

- 단축키 : Ctrl + Shift + Backspace

- 설명 : 다른 파일 보고 오느라 스크롤을 이동했다가, "방금 내가 짜던 코드가 어디지?" 하고 헤맬 때 사용

구현체로 바로이동

- 단축키 : Ctrl + Alt + B

- 설명 : Interface 메서드 위에서 크냥 클릭(Ctrl+B)하면 인터페이스 정의로만 간다. 실제 구현 클래스(Impl)가 궁금할 때 사용

4. 타이핑 속도 개선 : Postfix Completion (후위 자동완성)

변수를 먼저 치고 . 을 찍어서 문장을 완성하는 기능이다. 커서를 앞으로 옮겨서 if(...)를 감싸는 수고를 덜어준다.

- 변수.sout -> System.out.printlf(변수);

- 변수.var -> String name = 변수; (타입 추론하여 변수 선언)

- 변수.nn -> if(변수 !- null) {...} (null 체크)

- 리스트.for -> 향상된 for문 자동 생성

5. 서버 로그 분석 : Analyze Stack Trace

기능

Analyze -> Analyze Stack Trace or Thread Dump

사용법

- 서버 로그의 Exception 스택 트레이스 부분을 복사한다.

- 인텔리제이로 돌아와서 이 메뉴를 실행하면, 자동으로 클립보드 내용을 읽어온다.

- 로그의 파일명들이 하이퍼링크로 변한다. 클리하면 바로 내 프로젝트의 해당 라인으로 이동한다.

효과

버그 추적 속도가 10배 빨라진다.

조합(HAS-A)과 전략 패턴(Strategy Pattern)

H.Sunny,, — Fri, 6 Feb 2026 14:07:35 +0900

지난 포스팅에서 상속(IS-A)이 가진 경직성과 위험성에 대해 알아보았다. 객체지향 설계의 격언 중 상속보다는 조합을 선호하라 (Favor Composition over Inheritance)라는 말이 있다.

이번 포스팅에서는 조합(HAS-A) 관계를 활용해, 실행 중에 기능을 마음대로 교체할 수 있는 유연한 코드를 작성하는 방법에 대해 살펴본다. 이것이 전략 패턴(Strategy Pattern)의 기초다.

1. 조합(HAS-A)를 선호해야하는 이유

상속은 태어날 때부터 정해진 운명이라면, 조합은 장착할 수 있는 아이템과 같다.

- 느슨한 결합 : 부모 클래스 코드를 몰라도 인터페이스만 알면 된다.

- 런타임 유연성 : 프로그램 실행 도중에 객체(부품)을 교체할 수 있다.

- 다중 상속의 대안 : 여러 개의 객체를 필드로 가지면, 여러 기능을 동시에 가질 수 있다.

2. 실전 예제 : 로봇과 무기

로봇이 공격 기능을 가져야 한다고 가정해보자. 상속을 쓰면 PunchRobot, MissileRobot 등 클래스가 무한히 늘어난다. 하지만 HAS-A를 쓰면 로봇은 Weapon만 가지고 있으면 된다.

Step 1. 부품(Interface) 정의

interface Weapon {
void attack();
}

Step 2. 부품 구현체(전략)

class Punch implements Weapon {
public void attack() { System.out.println("주먹 발사!"); }
}

class Missile implements Weapon {
public void attack() { System.out.println("미사일 발사!"); }
}

Step 3. 로봇 클래스(조합 활용)

class Robot {
    private Weapon weapon; // HAS-A : 로봇은 무기를 가지고 있다.

    // 생성자로 무기 장착
    public Robot(Weapon weapon) {
        this.weapon = weapon;
    }

    // [핵심] 런타임에 무기 교체 가능 (Setter)
    public void setWeapon(Weapon weapon) {
        this.weapon = weapon;
    }

    public void fight() {
        weapon.attack(); // 기능을 위임(Delegation)
    }
}

3. 유연함의 증명

로봇 코드를 전혀 수정하지 않고도, 실행 중에 공격 방식을 바꿀 수 있다.

public static void main(String[] args) {
    Robot taekwonV = new Robot(new Punch()); // 처음엔 주먹
    taekwonV.fight();
    // 출력: 주먹 발사!

    System.out.println("--- 무기 업그레이드 ---");

    taekwonV.setWeapon(new Missile()); // 미사일로 즉시 교체
    taekwonV.fight();
    // 출력: 미사일 발사!
}

결론

HAS-A 관계는 단순히 객체를 필드로 갖는 것을 넘어, 코드를 수정하지 않고도 기능을 확장할 수 있는(OCP 준수) 강력한 무기다. 기능이 필요할 때 상속받을지를 먼저 생각하지 말고, 부품으로 가지자 라고 생각하는 습관을 들이자.

상속(IS-A)과 조합(HAS-A)

H.Sunny,, — Thu, 5 Feb 2026 15:49:48 +0900

객체지향 프로그래밍(OOP)을 처음 배울 때 상속(Inheritance)은 재사용을 위한 도구라고 배운다. 그리고 "개는 동물이다(Dog is Animal)" 같은 예시를 보며 모든 것을 상속으로 해결하려는 습관을 갖게 된다. 하지만 상속을 남용하면, 부모 클래스의 작은 수정이 자식 클래스 전체를 망가뜨리는 깨지기 쉬운 상속(Fragile Base Class) 문제를 겪게 된다.

1. IS-A 관계 (Inheritance : 상속)

~은 ~의 일종이다 (Sub is Super)가 성립할 때 사용하는 관계다. Java에서는 extends 키워드를 사요하며, 부모와 자식이

강하게 결합(Tightly Coupled)된다.

- 예시 : GalaxyS25 is a SmartPhone

- 특징 : 부모의 기능을 물려받아 구현 없이 바로 쓸 수 있다. 하지만 부모가 변경되면 자식도 강제로 영향을 받는다.

2. IS -A의 단점

현실 세계의 "IS-A"를 코드에 그대로 대입하면 논리적 오류가 발생할 수 있다 .대표적인 예가 "정사각형(Squre)은 직사각형(Rectangle)이다" 라는 명제다.

[Bad Code]

class Rectangle {
    void setWidth(int w) { this.width = w; }
    void setHeight(int h) { this.height = h; }
}

class Square extends Rectangle {
    @Override
    void setWidth(int w) {
        // 정사각형은 가로/세로가 같아야 하므로 강제로 둘 다 변경
        super.setWidth(w);
        super.setHeight(w);
    }
}

Rectangle을 사용하는 코드는 가로만 바꿨는데 세로까지 변할 것이라 예상하지 못한다. 이는 객체지향 원칙 중 리스코프 치환 원칙(LSP)을 위반하는 사례다.

3. HAS-A 관계(Composition : 조합)

~은 ~을 가지고 있다 (Container has a Component)가 성립할 때 사용하는 관계다. 상속받는 대신, 해당 클래스의 객체를 필드(멤버 변수)로 소유하는 방식이다.

- 예시 : Car has an Wheel

- 특징 : 두 클래스가 느슨하게 결합(Loosely Coupled)된다. 부품을 갈아 끼우듯 유연한 설계가 가능하다.

4. IS-A VS HAS-A

구분	IS-A (상속)	HAS-A (조합)
개념	일종이다 (Type of)	가지고 있다 (Part of)
구현	extends	new (필드 선언)
결합도	높음 (High)	낮음 (Low)
유연성	컴파일 시 결정 (변경 불가)	런타임 시 변경 가능

결론

내가 쟤의 자식인가? 가 100% 확실하지 않다면 상속을 쓰지 말자. 단순히 코드를 재사용하고 싶다면, 상속보다는 조합(HAS-A)을 사용하는 것이 훨씬 안전하다.

[Algorithm] 스택(Stack)과 큐(Queue)

H.Sunny,, — Wed, 4 Feb 2026 14:23:06 +0900

1. 스택(Stack)

개념

- LIFO(Last In First Out, 후입선출) 구조

- 가장 나중에 들어온 데이터가 가장 먼저 나가는 형태

- 입구가 출구가 하나인 구조

주요 연산

- push : 데이터를 넣는 연산 (top 위치에 삽입)

- pop : 데이터를 꺼내는 연산 (top 위치 데이터 삭제 및 반환)

- peek : 데이터를 꺼내지 않고 확인만 하는 연산

활용

- DFS(깊이 우선 탐색)

- 백트래킹 (Backtracking)

- 재귀 함수의 원리와 동일

Java 구현

Java에서 스택을 사용할 때 java.util.Stack 클래스는 사용을 지양해야 한다.

- 이유 : Stack은 초기 Java 버전의 Vector를 상속받아 구현되어 있어, 모든 메서드에 동기화(Synchronized) 키워드가 붙어 있다. 이는 멀티 스레드 환경이 아닐 때 불필요한 오버헤드를 발생시킨다.

- 대안 : Deque 인터페이스의 구현체인 ArrayDeque를 사용하는 것이 성능면에서 유리하다.

예시)

// 비추천 (Legacy)
Stack<Integer> stack = new Stack<>();

// 추천 (Modern Java)
Deque<Integer> stack = new ArrayDeque<>();

stack.push(1);
stack.push(2);
stack.peek(); // 2 출력
stack.pop(); // 2 반환 및 삭제

2. 큐(Queue)

개념

- FIFO (First In First Out, 선입선출) 구조

- 먼저 들어온 데이터가 먼저 나가는 형태

- 양쪽이 뚫려있는 구조

주요 연산

- add / offer : 데이터를 넣는 연산 (rear/tail 위치에 삽입). offer는 실패 시 예외 대신 false를 반환하므로 더 안정적

- remove / poll : 데이터를 꺼내는 연산 (front/head 위치 데이터 삭제 및 변환) poll은 비어 있을 때 null을 반환

- element / peek : 데이터를 확인만 하는 연산

활용

- BFS (너비 우선 탐색)

- 캐시(Cache) 구현

- 프로세스 스케줄링

Java 구현(LinkedList vs ArrayDeque)

Queue는 인터페이스이므로 구현체가 필요하다. 보통 LinkedList와 ArrayDeque 중 하나를 선택한다.

- LinkedList : 큐의 중간에 데이터를 삽입/삭제할 일이 많다면 유리하다. 하지만 각 요소가 노드 객체로 생성되므로 메모리 오버헤드가 있다.

- ArrayDeque : 큐의 양 끝에서만 연산이 일어난다면(순수 큐 기능) 메모리 효율과 속도(Cache Locality)면에서 LinkedList 보다 유리하다.

예시)

// 일반적인 구현 (LinkedList 사용)
Queue<Integer> queue = new LinkedList<>();

// 성능 중시 (ArrayDeque 사용)
Queue<Integer> queue = new ArrayDeque<>();

queue.offer(1);
queue.offer(2);
queue.peek(); // 1 출력 (먼저 들어간 값)
queue.poll(); // 1 반환 및 삭제

3. 우선순위 큐(Priority Queue)

- 들어간 순서와 상관 없이 우선순위가 높은 데이터가 먼저 나오는 자료구조

- 힙(Heap) 자료구조를 기반으로 구현

- Java에서는 PriorityQueue 클래스를 사용하며, 기본적으로 낮은 숫자(Min Heap)가 높은 우선순위를 가진다.(높은 숫자를 우선시 하려면 Collections.reverseOrder() 사용)

예시)

// 낮은 숫자가 우선 (Min Heap)
PriorityQueue<Integer> pq = new PriorityQueue<>();

// 높은 숫자가 우선 (Max Heap)
PriorityQueue<Integer> pq = new PriorityQueue<>(Collections.reverseOrder());

정리

스택과 큐는 알고리즘 문제 해결의 도구다. 단순히 메서드만 아는 것보다, 문제의 성격(DFS 또는 BFS)에 따라 적절한 자료구조를 선택하고, 효율적인 구현체(ArrayDeque)를 선택하는 것이 중요하다.

[Algorithm] 구간 합 (Prefix Sum) 핵심 개념 및 활용

H.Sunny,, — Tue, 3 Feb 2026 11:00:23 +0900

코딩테스트 문제를 풀다 보면 특정 구간의 합을 구하라는 요구사항을 자주 마주하게 된다. 단순히 반복문으로 그때그때 합을 구하면 될 것 같지만, 데이터의 개수가 많아지고 질의(Query) 횟수가 늘어나면 시간 초과(Time Limit Exceeded)가 발생하기 십상이다.

이때 시간 복잡도를 획기적으로 줄여주는 필수 테크닉이 바로 구간 합(Prefix Sum)과 합 배열(Prefix Sum Array)이다.

1. 구간 합

배열 내의 특정 구간 내에 포함된 모든 원소들의 합을 의미한다. 예를 들어 A[2] 부터 A[5] 까지의 합을 구하고 싶을 때, 매번 for 문을 돌리는 것이 아니라 미리 구해둔 합 배열을 이용해 O(1)의 시간 복잡도로 답을 구해내는 기법이다.

2. 합 배열 만들기

합 배열 S는 원본 배열 A의 0번 인덱스부터 특정 인덱스까지의 누적 합을 저장한 배열이다.

공식

S[i] = S[i-1] + A[i]

즉 현재 인덱스까지의 합 = 이전 인덱스까지의 합 + 현재 값 이다.

예시)

- 원본 배열 A : [3, 6, 5, 10, 14]

- 합 배열 S : [3, 9, 14, 24, 38]

S[0] = A[0] = 3

S[1] = S[0] + A[1] => 3 + 6 = 9

S[2] = S[1] + A[2] => 9 + 5 = 14

....

3. 구간 합 빠르게 구하기

합 배열 S가 준비되었다면, i번째부터 j번째까지의 구간 합은 뺄셈 연산 한 번으로 구할 수 있다.

공식

구간 합(i~j) = S[j] - S[i-1]

원리

- S[j] : 처음부터 J 까지의 합

- S[i-1] : 처음부터 i 바로 전까지의 합

따라서 S[j]에서 S[i-1]을 빼면, i부터 j까지의 합만 남게 된다.

예시) A[2] ~ A[4] 구간의 합을 구하고 싶다면?

- 공식 적용 : S[4] - S[1]

- 계산 : 38 - 9 = 29

- 검증 : 실제 값 5 + 10 + 14 = 29 (일치)

4. 사용 이유(시간 복잡도 비교)

데이터의 개수가 N개이고, 구간 합을 횟수(쿼리)가 M번이라고 가정하자.

구분	일반적인 방법 (이중 for문)	구간 합 (합 배열) 사용
전처리	없음	O(N) (합 배열 생성)
1회 조회	O(N)	O(1)
전체 복잡도	O(N×M)	O(N+M)

쿼리가 많을 수록 구간 합 방식이 압도적으로 빠르다. 코딩테스트에서 N과 M이 10만 단위를 넘어간다면 필수적으로 사용해야 한다.

5. 주의사항 및 한계

- 배열 값의 변경 : 만약 원본 배열의 값이 중간에 자주 바뀐다면, 그때마다 합 배열을 다시 만들어야 하므로 비효율적이다.

- 데이터 변경이 빈번한 경우 : 이때는 세그먼트 트리(Segment Tree)나 인덱스 트리(Index Tree) 같은 더 고급 자료구조를 사용해야 한다. (추후 포스팅 예정)

- 인덱스 주의 : 합 배열 공식에서 S[i-1]을 참조하므로, 인덱스 0번 처리에 주의하거나 배열 크기를 N+1로 잡아 1번 인덱스부터 사용하는 팁이 자주 쓰인다.

[Design Pattern] 객체지향 설계 SOLID 원칙

H.Sunny,, — Tue, 3 Feb 2026 10:40:17 +0900

좋은 개발자가 되기 위해 반드시 넘어야 할 산이 있다. 바로 객체지향 설계의 5가지 원칙, SOLID다. 로버트 마틴(Robert C. Martin, a.k.a Uncle Bob)이 정립한 이 원칙들은 유지보수 하기 쉽고, 유연하며, 확장이 용이한 소프트웨어를 만들기 위한 핵심 가이드라인이다.

면접 단골 질문이기도 하지만, 실무에서 스파게티 코드를 만들지 않기 위해 반드시 몸에 익혀야 할 5가지 원칙을 정리해 본다.

1. SRP (Single Responsibility Principle) : 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.

- 의미 : 클래스를 변경해야 할 이유는 단 하나뿐이어야 한다.

- Bad : User 클래스가 로그인도 하고, 이메일도 보내고, DB에 저장도 한다.(하나의 수정이 다른 기능에 영향을 줌)

- Good : User 클래스는 정보만 관리하고, AuthManager가 로그인을, EmailSender가 메일을 담당한다.

-> 기능을 분리

2. OCP (Open-Closed Principle) : 개방-폐쇄 원칙

확장에는 열려 있고, 변경에는 닫혀 있어야 한다.

- 의미 : 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계해야 한다.

- Bad : 결제 수단을 추가할 때 마다 If (type == CARD) ... else if (type == CASH) ... 처럼 기존 코드를 계속 수정한다.

- Good : Payment 인터페이스를 만들고 CardPayment, CashPayment가 이를 구현하게 한다. (다형성 활용)

-> 인터페이스를 통해 추상화

3. LSP (Liskov Substitution Principle) : 리스코프 치환 원칙

자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다.

- 의미 : 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 바꿔 끼워도 프로그램이 정상적으로 동작해야 한다. 상속을 올바르게 사용했는지 확인하는 원칙이다.

- Bad : 직사각형을 상속받은 정사각형 클래스. 정사각형은 너비와 높이가 같아야 하므로, 너비만 바꾸는 부모(직사각형)의 메서드를 그대로 쓰면 논리적 오류가 발생한다.

- Good : 둘은 상속 관계가 아닌, 별도의 클래스로 분리하거나 상위 인터페이스 Shape를 둔다.

-> 상속은 Is-a 관계가 확실할 때만 사용

4. ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

클라이언트는 자신이 사용하지 않는 메서드에 의존하면 안 된다.

- 의미 : 하나의 거대한 인터페이스보다는 구체적인 여러 개의 인터페이스가 낫다.

- Bad : SmartPhone 인터페이스에 Call(), sms(), wirelessCharge()가 다 있다. 무선 충전 기능이 없는 구형 폰도 억지로 wirelessCharge()를 구현해야 한다.

- Good : Phone(통화, 문자)과 WirelessChargable(무선충전) 인터페이스로 분리한다.

-> 인터페이스를 간결화

5. DIP (Dependency Iversion Principle) : 의존 역전 원칙

구체적인 클래스보다 추상화된 것에 의존해야 한다.

- 의미 : 변하기 쉬운 것(구체 클래스)에 의존하지 말고, 변하지 않는 것(인터페이스, 추상 클래스)에 의존

- Bad : Store 클래스가 SamsungCard 클래스를 직접 new 해서 사용한다.(다른 카드로 변경이 어려움)

- Good : Store 클래스는 CreditCard 인터페이스에 의존하고, 실행 시점에 SamsungCard나 KakaoCard를 주입(DI) 받는다.

-> 직접 생성하지 말고 주입 (Dependency Injection)

결론

SOLID 원칙을 지키는 것은 당장은 코드가 많아지고 복잡해 보일 수 있다. 하지만 프로젝트 규모가 커지고 유지보수 기간이 길어질수록, 이 원칙들이 만들어낸 유연함과 안정성이 빛을 발하게 된다. 결국 좋은 설계란 미래의 나, 그리고 동료들이 덜 고통받게 하는 배려다.

[Design Pattern] 객체지향의 원칙 : OCP (개방-패쇄 원칙)

H.Sunny,, — Mon, 2 Feb 2026 11:39:00 +0900

좋은 코드를 짜기 위한 5가지 원칙(SOLID) 중, 가장 중요하면서도 아이러니한 이름을 가진 원칙이 OCP(Open-Closed principle)다. 열려 있으면서 동시에 닫혀 있어야 한다는 말이 언뜻 보면 모순처럼 들리지만, 이 원칙을 이해하는 순간 객체지향의 진짜 매력을 알게 된다.

OCP(Open_Closed Princilple)

버트란트 마이어(Bertrand Meyer)가 정의한 이 원칙의 핵심은 다음과 같다.

소프트웨어 요소(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

- Software entities should be open for extension, but closed for modification.

확장에 열려 있다 (Open for Extension)

- 새로운 기능이나 요구사항이 생겼을 때, 기존 코드를 확장하여 쉽게 추가할 수 있어야 한다.

변경에 닫혀 있다 (Closed for Modification)

- 새로운 기능을 추가할 때, 기존의 코드는 수정되지 않아야 한다.

OCP를 위반한 사례

알림(Notification)을 보내는 기능을 만든다고 가정해보자. 처음엔 이메일만 있으면 되었다.

public class NotificationSender {
    public void send(String type) {
        if (type.equals("EMAIL")) {
            System.out.println("이메일 발송");
        }
        // 나중에 SMS 기능 추가 요청이 들어옴 -> 기존 코드를 수정해야 함!
        else if (type.equals("SMS")) {
            System.out.println("문자 발송");
        }
    }
}

문제점

- 새로운 알림 수단(카카오톡, 슬랙 등)이 추가될 때 마다 NofificationSender 클래스의 if-else 블록을 계속 수정해야 한다.

- 기존 코드를 건드리기 때문에, 잘 돌아가던 이메일 기능에 버그가 생길 위험이 있다.(변경에 닫혀 있지 않음)

OCP를 준수한 사례

OCP를 지키기 위한 핵심 키워드는 추상화(Abstraction)와 다형성(Polymorphism)이다. 변하지 않는 것(공통 역할)을 인터페이스로 격리한다.

1. 인터페이스 정의(역할)

public interface Notification {
void send();
}

2. 구현 클래스 작성(확장)

public class EmailNotification implements Notification {
    @Override
    public void send() {
        System.out.println("이메일 발송");
    }
}

public class SmsNotification implements Notification {
    @Override
    public void send() {
        System.out.println("문자 발송");
    }
}

3. 클라이언트 코드

public class NotificationSender {
    // 구체적인 타입(Email, Sms)을 몰라도 됨. 인터페이스에만 의존.
    public void sendNotification(Notification notification) {
        notification.send();
    }
}

결과

- 이제 카카오톡 알림을 추가하고 싶다면? NotificationSender를 수정할 필요 없이, 그냥 KakaoNotification 클래스를 새로 만들면 된다.

- 확장에는 열려 있고(클래스 추가 기능), 변경에는 닫혀 있다(Sender 코드 수정 불필요)

OCP가 중요한 이유

- 유지보수성 : 기존 코드를 건드리지 않으므로, 새 기능을 추가할 때 기존 기능이 망가질까봐 걱정할 필요가 없다. (Regression Bug 방지)

- 유연성 : 레고 블록 갈아 끼우듯 기능을 쉽게 교체할 수 있다.

- 가독성 : 거대한 if-else 지옥에서 벗어날 수 있다.

정리

OCP는 코드를 수정하지 말고 코드를 더해라(Add code, don't change code)라는 말로 요약할 수 있다. if문이나 switch 문으로 타입을 구분하고 있다면, OCP를 위반하고 있을 확률이 높다. 이때는 인터페이스를 통한 다형성 적용을 고려해 보자.

[Algorithm] 배열(Array) vs 리스트(List) 비교 및 선택 기준

H.Sunny,, — Fri, 30 Jan 2026 11:14:26 +0900

코팅테스트나 실무 개발에서 가장 기본이 되면서도 중요한 자료구조는 단연 배열(Array)과 리스트(List)다. 너무 익숙해서 대충 넘어가기 쉽지만, 이 둘의 차이를 명확히 알아야 문제 상황에 맞는 자료구로를 선택할 수 있다.

1. 배열(Array) : 조회에 특화

메모리의 연속된 공간에 값이 채워져 있는 형태다.

특징

- 인덱스(Index) 접근 : 인덱스를 알면 즉시 값에 접근할 수 있다.

- 크기 고정 : 선언할 때 크기를 지정해야 하며, 한번 선언하면 크기를 늘리거나 줄일 수 없다.

- 삽입/삭제 비효율 : 중간에 값을 넣거나 빼려면, 그 뒤의 모든 데이터를 한 칸씩 밀거나 당겨야 한다.

시간 복잡도

- 조회(Access) : O(1) (매우빠름)

- 삽입/삭제(Insert/Delete) O(N) (데이터를 밀어야 하므로 느림)

2. 리스트(List) : 삽입/삭제(Modification)에 유연함

값과 다음 노드를 가리키는 포인터(참조)가 묶여 있는 노드(Node)들의 연결이다. (엄밀히 말하면 LinkedList를 의미)

특징

- 순차 접근 : 인덱스가 없으므로, 원하는 값에 도달하려면 첫 노드(Head)부터 포인터를 따라가며 찾아야 한다.

- 크기 가변 : 선언 시 크기를 지정할 필요가 없으며, 데이터 개수에 따라 동적으로 늘어나거나 줄어든다.

- 삽입/삭제 효율 : 중간에 값을 넣을 때, 앞뒤 노드의 포인터 연결만 바꿔주면 끝이다. (데이터 이동 불필요)

시간복잡도

- 조회(Access) : O(N)( (앞에서부터 찾아가야 하므로 상대적 느림)

- 삽입/삭제(Insert/Delete) : O(1) (위치를 알고 있다는 가정하에)

3. ArrayList vs LinkedList

구분	배열 (Array)	ArrayList	LinkedList
기반	Primitive / Object	Array 기반 (동적 배열)	Node 기반 (연결 리스트)
조회 속도	O(1)	O(1) (인덱스 지원)	O(N)
중간 삽입/삭제	O(N)	O(N) (배열 복사 발생)	O(1) (연결만 변경)
크기 변경	불가	자동 증가 (Resizing)	자동

4. ArrayList는 리스트인가 배열인가?

이름은 List지만 내부 구현은 배열(Array)로 되어 있다. 따라서 인덱스 조회는 빠르지만, 중간 삽입/삭제는 배열처럼 느리다.

순수하게 삽입/삭제가 빈번하다면 LinkedList를, 조회 위주라면 ArrayList를 사용

5. 정리

배열(Array) 또는 ArrayList를 써야할 때

- 데이터의 개수가 정해져 있거나, 변화가 거의 없을 때

- 데이터의 조회(Access)나 인덱스 활용이 많을 때

- 대부분의 알고리즘 문제(DFS/BFS, 투 포인터 등)는 접근 속도가 빠른 배열이 유리

LinkedList를 써야할 때

- 데이터의 크기를 예측할 수 없을 때

- 중간 위치에 데이터 삽입/삭제가 매우 빈번하게 일어날 때 (단, 조회가 많다면 비추천)

무조건 ArrayList만 쓰지 말고, 문제의 특성(조회가 많은지, 삽입 삭제가 많은지)를 파악하여 적절한 자료구조를 선택

[Design Pattern] 다형성(Polymorphism)으로 if-else 없애기

H.Sunny,, — Thu, 29 Jan 2026 14:10:23 +0900

코드를 짜다 보면 기능은 정상적으로 동작하지만, 뭔가 지저분하고 유지보수하기 힘든 코드를 마주하게 된다. 이를 코드 스멜(Code Smell)이라고 한다. 대표적인 코드 스멜 중 하나가 객체의 타입에 따라 if-else나 switch 문을 길게 늘어놓는 경우다.

문제상황

쇼핑몰 결제 시스템을 개발한다고 가정해보자. 카드 결제, 무통장 입금, 카카오페이 등 다양한 결제 수단이 있다. 다형성을 활용하지 않고 구현하면 보통 아래와 같은 형태가 된다.

public class PaymentProcessor {
    public void process(Object payment) {
        // [Code Smell] 새로운 결제 수단이 추가될 때마다 if문이 계속 늘어남
        if (payment instanceof CreditCard) {
            ((CreditCard) payment).processCard();
        } else if (payment instanceof BankTransfer) {
            ((BankTransfer) payment).transfer();
        } else if (payment instanceof KakaoPay) {
            ((KakaoPay) payment).payWithApp();
        } else {
            throw new IllegalArgumentException("지원하지 않는 결제 방식");
        }
    }
}

이 코드의 문제점

- OCP(Open-Closed Principle) 위반 : 새로운 결제 수단을 추가하려면 기존의 PaymentProcessor 코드를 수정해야 한다.

- 가독성 저하 : if-else 블록이 길어질수록 로직을 파악하기 어렵다.

- 실수 유발 : 타입 캐스팅( (CreditCard) payment ) 과정에서 실수할 여지가 생긴다.

해결방법

무슨 타입인지(instanceof) 체크하지 않고 부모 인터페이스를 통해 제어하면 된다.(다형성 적용)

1. 공통 인터페이스 정의

모든 결제수단이 공통적으로 가져야 할 행동을 정의한다.

public interface Payment {
void pay(); // 구체적인 구현은 자식 클래스에게 위임
}

2. 구현클래스 작성

각 결제 수단별로 상세 로직을 구현한다.

public class CreditCard implements Payment {
    @Override
    public void pay() {
        System.out.println("신용카드로 결제합니다.");
    }
}

public class KakaoPay implements Payment {
    @Override
    public void pay() {
        System.out.println("카카오페이 앱으로 결제합니다.");
    }
}

3. 클라이언트 코드 (Refactoring 완료)

이제 PaymentProcessor는 구체적인 결제 수단을 알 필요가 없다. 단지 Payment 인터페이스에 의존할 뿐이다.

public class PaymentProcessor {
    // 코드가 매우 간결해짐
    public void process(Payment payment) {
        payment.pay(); // 다형성에 의해 실제 객체의 메서드가 실행됨
    }
}

정리 : 왜 다형성을 써야 하는가?

- 유지보수성 향상 : 새로운 결제 수단이 추가되어도 PaymentProcessor 코드는 단 한 줄도 수정할 필요가 없다.(OCP 준수)

- 캡슐화 : 각 결제 로직이 해당 클래스(CreditCard, KakaoPay) 내부에 안전하게 격리된다.

- 안전성 : 지저분한 형변환(Casting)과 instanceof 검사가 사라져 런타임 오류 가능성이 줄어딘다.

객체 지향의 핵심은 조건문을 객체 간의 관계로 대체하는것

코드 스멜(Code Smell) 이란?

H.Sunny,, — Tue, 27 Jan 2026 13:56:21 +0900

개발을 하다 보면 기능은 문제 없이 돌아가는데, 어딘가 모르게 코드를 수정하기 꺼려지고 읽기 힘든 경우가 있다. 마치 냉장고 구석에서 나는 불쾌한 냄새처럼, 코드에서 나중에 문제 생길 것 같은 징조가 느껴지는 상황. 이것을 코드 스멜(Code Smell) 이라고 한다.

코드 스멜(Code Smell)

- 정의 : 코드가 기술적으로 틀린 것은 아니지만, 설계상의 문제나 오류를 유발할 가능성이 높은 코드 패턴을 말한다.

- 유래 : Kent Beck와 Martin Fowler의 저서 Refactoring에서 처음 등장한 용어다.

- 의미 : "이 코드는 당장은 돌아가지만, 나중에 유지보수하기 지옥이야" 라는 경고 신호다. 즉, 리펙토링(Refactoring)이 필요하다는 신호다.

대표적인 코드 스멜 유형

1. 중복 코드(Duplicated Code)

- 증상 : 똑같은 코드 구조가 두 군데 이상 존재

- 문제 : 요구사항이 바뀌면 중복된 모든 곳을 찾아서 수정해야 한다. (하나라도 빼먹으면 에러 발생)

- 해결 : 메서드 추출(Extract Method)을 통해 공통 로직을 하나로 모은다.

2. 긴 메서드(Long Method)

- 증상 : 하나의 함수가 너무 길다. (스크롤을 한참 내려야 끝이 보인다.)

- 문제 : 한 메서드가 너무 많은 일을 하고 있어(SRP 위반), 읽기도 힘들고 재사용도 불가능하다.

- 해결 : 기능 단위로 메서드를 잘게 쪼갠다.

3. 거대한 클래스(Large Class / God Class)

- 증상 : 클래스 하나에 필드와 메서드가 너무 많다.

- 문제 : 모든 기능을 혼자 다 하려다 보니 결합도가 높아져 수정이 어렵다.

- 해결 : 클래스 추출(Extract Class)을 통해 책임을 분리한다.

4. 매직 넘버(Magic Number)

- 증상 : 코드 중간에 3.14, 86400 같은 숫자가 뜬금없이 박혀 있다.

- 문제 : 이 숫자가 무엇을 의미하는지 작성자만 안다. 나중에 이 값을 바꿔야 할 때 어디에 쓰였는지 찾기 힘들다.

- 해결 : static final 상수(Constant)로 선언하여 의미 있는 이름을 부여한다.

5. Switch 문(Switch Statements)

- 증상 : 객체의 타입 코드에 따라 switch나 if-else가 길게 나열된다.

- 문제 : 새로운 타입이 추가될 때 마다 분기문을 수정해야 한다. (OCP 위반)

- 해결 : 다형성(Polymorphism)을 이용해 오버라이등으로 해결한다.

리팩토링 예시

[Bad Code : 냄새나는 코드]

// 86400이 뭔데? 하루가 몇 초인지 모르면 이해 못 함
if (time > 86400) {
throw new IllegalArgumentException("시간 초과");
}

[Good Code : 향기나는 코드]

// 상수로 의미를 명확히 부여
public static final int SECONDS_PER_DAY = 86400;

if (time > SECONDS_PER_DAY) {
throw new IllegalArgumentException("시간 초과");
}

결론

코드 스멜을 없애는 과정이 바로 리팩토링이다. 처음부터 완벽한 코드를 짤 수는 없다. 하지만 코드를 작성하고 나서 찝찝한 냄새가 난다면 그때그때 환기하는 습관을 들이자. 그것이 기술 부채(Technical Debt)를 줄이는 지름길이다.

[Java] instanceof 연산자 개념 및 사용법 (feat. Pattern Matching)

H.Sunny,, — Mon, 26 Jan 2026 11:59:44 +0900

자바에서 객체 지향 프로그래밍을 하다 보면 부모 타입의 참조 변수로 자식 객체를 다루는 업캐스팅(Upcasting) 상황이 자주 발생한다. 이때 다시 원래의 자식 타입으로 되돌리는 다운캐스팅(Downcasting)을 하기 전에 해당 객체가 실제로 어떤 타입인지 확인해야 안전하다. 이 때 사용하는 것이 instanceof 연산자다.

instanceof 란?

객체가 특정 클래스(또는 인터페이스)의 인스턴스인지 확인하는 연산자다. 결과는 boolean 타입으로 반환된다.

사용법

객체 instanceof 클래스명(또는 인터페이스명)

결과

- 객체가 해당 클래스 타입이거나, 상속받은 자식 클래스라면 true

- 객체가 null이거나, 관련 없는 타입이라면 false

사용 이유(ClassCastException 방지)

무턱대고 형변환(Casting)을 시도하면 실행 시점에 ClassCaseException 에러가 발생한다.

class Parent {}
class Child extends Parent {}

public class Main {
    public static void main(String[] args) {
        Parent p = new Parent();

        // 확인 없이 형변환 시도 -> 런타임 에러 발생 (ClassCastException)
Child c = (Child) p;

        // instanceof로 타입 체크 후 형변환
        if (p instanceof Child) {
            Child c = (Child) p;
            System.out.println("형변환 성공");
        } else {
            System.out.println("형변환 불가");
        }
    }
}

상속 관계에서의 동작

instanceof는 본인 클래스뿐만 아니라 부모 클래스나 구현한 인터페이스에 대해서도 true를 반환 한다.

Parent p = new Child();

System.out.println(p instanceof Object); // true (모든 객체의 조상)
System.out.println(p instanceof Parent); // true (부모 타입)
System.out.println(p instanceof Child); // true (실제 인스턴스 타입)

Java 14+ : Pattern Matching for instanceof

자바 14부터 도입되고 자바 16에서 정식 확정된 기능으로, instanceof 검사와 형변환을 동시에 할 수 있게 되었다.

기존 방식(Java 14 이전)

if (obj instanceof String) {
String s = (String) obj; // 명시적 형변환 필요
System.out.println(s.length());
}

개선된 방식(Java 16 이후)

// 검사 성공 시, 변수 s에 자동으로 형변환되어 바인딩됨
if (obj instanceof String s) {
System.out.println(s.length()); // 바로 사용 가능
}

주의사항

instanceof를 남발하는 것은 객체 지향 설계 관점에서 좋지 않다.(Code Smell) 분기문이 길어진다면, 다형성(Polymorphism)을 이용해 메서드 오버라이딩으로 해결하는 것이 올바른 설계 방향이다.

[Algorithm] 코딩테스트 디버깅(Debugging) 핵심 요령 및 실수 유형

H.Sunny,, — Fri, 23 Jan 2026 17:47:59 +0900

코딩테스트에서 문제를 풀다 보면 논리적 오류나 사소한 실수로 인해 정답을 맞히지 못하는 경우가 많다.

이 때 대부분은 System.out.println() 같은 로그를 찍어 확인하려 하지만, 실전에서는 디버깅(Debugging) 기능을 사용하는 것이 시간 단축과 정확도 측면에서 훨씬 유리하다.

1. 디버깅(Debugging)이 필요한 이유

많은 사람들이 코드를 수정할 때 로그를 찍어서 확인한다. 하지만 로그 방식은 다음과 같은 단점이 있다.

- 시간 소요 : 로그를 찍고, 실행하고, 다시 지우고, 재실행하는 과정이 반복되어 시간이 오래 걸린다.

- 시야 협소 : 로그를 찍은 특정 부분만 보게 되어, 코드의 전체적인 흐름을 놓치고 지엽적인 부분에만 매몰되기 쉽다.

디버깅 기능을 사용하면 변수의 상태 변화를 실시간으로 추적할 수 있어 논리 오류를 빠르게 찾아낼 수 있다.

2. IDE 디버깅 기능 활용

Eclipse, Intellij 등 대부분의 IDE는 강력한 디버깅 기능을 제공한다.

- 중단점(Breakpoint) : 코드의 특정 라인에서 실행을 멈춘다.

- 변수(Variables) : 현재 시점의 변수 값을 실시간으로 확인한다.

- 수식(Expression) : 단순 변수 값 뿐만 아니라 arr[i] + arr[i] 와 같이 특정 수식의 결과를 즉시 확인해 볼 수 있다.

3. 코딩테스트에서 자주하는 실수 유형

변수 초기화 오류

현상 : 여러 테스트 케이스를 처리하는 문제에서 이전 케이스의 계산 값이 다음 케이스에 영향을 미쳐 오답 발생

해결 : for문 내에서 반복될 때 누적 변수(sum 등)나 배열이 적절한 시점에 초기화(0 또는 null) 되는 지 확인한다.

반복문 인덱스 범위 오류

현상 : N번 반복해야 하는데 N+1번 반복하거나, 배열의 범위를 벗어나는 경우

체크 : 반복문 조건이 i < N 인지, i <= N 인지 의도한 로직과 정확히 일치하는지 디버깅을 통해 확인한다.

출력 형식 오류

현상 : 문제에서는 숫자만 출력하라고 했는데, 디버깅이나 확인을 위해 넣은 텍스트를 그대로 포함하여 제출하는 경우

주의 : 불필요한 테스트 출력문이 포함되지 않았는지 마지막까지 확인해야 한다.

자료형 범위 오류(Overflow)

현상 : 로직은 완벽한데 답이 틀리거나, 뜬금없이 음수가 출력되는 경우

원인 : int 자료형의 범위(약 21억)를 초과하여 오버플로우가 발생했기 때문이다.

해결 :

- 답이 음수가 나올 수 없는 로직인데 음수가 나온다면 100% 오버플로우다.

- 팩토리얼, 순열, 경우의 수 등 값이 급격히 커지는 문제를 처음부터 long 자료형을 사용하는 습관을 들이는 것이 좋다.

4 정리

코딩테스트는 시간 싸움이다. 한 번에 완벽하게 코드를 짜면 좋겠지만, 실수가 발생했을 때 얼마나 빨리 수정하느냐가 합격을 좌우한다. 로그를 찍으며 해매기보다는, 디버깅 툴을 익숙하게 다루는 연습을 통해 디버깅 시간을 단축해야 한다.

[Algorithm] 시간 복잡도 (Time Complexity) 개념 및 Big-O 표기법

H.Sunny,, — Thu, 22 Jan 2026 10:49:35 +0900

알고리즘 문제를 풀거나 효율적인 로직을 짤 때 가장 중요한 개념중 하나인 시간 복잡도에 대해 정리한다.

시간 복잡도

시간복잡도(Time Complexity)는 주어진 문제를 해결하기 위해 필요한 연산 횟수를 의미한다. 실제 걸리는

시간(초)를 측정하는 것이 아니라, 입력 데이터의 크기에 따라 연산량이 어떻게 증가하는지를 나타내는 지표다.

일반적으로 Problem Solving 환경에서는 1억번의 연산 = 1초 로 예측한다.

시간 복잡도 표기법

- 빅-오메가 (Big-Ω) : 최선(Best Case)의 경우
- 빅-세타 (Big-θ) : 보통(Average Case)의 경우
- 빅-오 (Big-O) : 최악(Worst Case)의 경우

알고리즘 성능 평가시에는 데이터가 최악으로 주어졌을때도 처리가 가능한지를 판단해야 하므로 빅-오 (Big-O) 표기법이 가장 중요

시간 복잡도 도출 기준

1. 상수는 시간 복잡도에서 제외

연산횟수가 N이든 3N이든, N이 무한대로 커지면 상수의 영향력은 미미하므로 똑같이 O(N)으로 취급한다.

2. 가장 많이 중첩된 반복문의 횟수가 기준

반복문이 2중으로 중첩되어 있다면 O(N^2), 3중이라면 O(N^3)이 된다. 따라서 가장 깊은 반복문을 찾으면 된다.

데이터 크기와 연산 횟수 확인

시간 복잡도를 따질 때는 가장 먼저 데이터의 개수(Input Size)를 확인해야 한다. 전체 연산 횟수는 다음과 같이 계산한다.

연산 횟수 = 알고리즘 시간 복잡도 x 데이터의 크기

알고리즘 별 시간 복잡도 예시

- 버블 정렬(Bubble Sort) : O(N^2)

데이터가 많아질수록 기하급수적으로 속도 저하

- 병합 정렬(Merge Sort) : O(N log N)

N^2 대비 훨씬 효율적

효율적인 알고리즘 적용

1. 문제의 제한 시간 내에 통과할 수 있는 알맞는 알고리즘을 선택하기 위함

2. 코드 내에서 비효율적인 로직을 찾아 계산하기 위함

정리

무조건 복잡한 알고리즘을 쓰는 것이 아니라, 데이터의 크기에 맞춰 적절한 시간 복잡도를 가진 알고리즘을 선택하는 것이 핵심

[TSA] 전자서명에서 타임스탬프가 필요한 이유

H.Sunny,, — Wed, 21 Jan 2026 14:25:32 +0900

전자서명은 근본적으로 부인방지 기능으로 개인키의 소유자가 서명했다는 것을 증명한다.

따라서 서명 시각에 대한 증명은 신뢰성을 갖지 않는다.

물론 서명 시각을 넣을 수는 있지만, 클라이언트의 시간을 조작하는 방법 등으로 서명 시간 조작이 가능하다.

또한 아래와 같은 경우에

1. 전자 서명 생성

2. 인증서 폐지 발생

전자서명이 인증서 폐지보다 먼저 발생하였느냐의 검증에 문제가 발생할 수 있다.

TSA 의 역할

- 이 서명 값이

- 해당 시작에 존재

-> 전자 서명이 언제 생성되었는지 제 3자가 증명해준다.

그러나 타임스탬프가 있다고 무조건 신뢰할 수 있는 것은 아니다.

- 신뢰 불가한 TSA

- TSA 인증서/키 문제 발생

- 검증 정책(LTV 정책)이 없는 경우

-> 타임 스탬프는 조건을 만들어 주는 도구일뿐 만능 해결책은 아니다.

정리

전자서명에서 TSA는 시간 기록 용도가 아니라

전자서명 인증서의 만료/폐지 이후에도 과거 서명을 검증하기 위한 기반을 만들어준다.

[TSA] TimeStampToken(TST) 검증

H.Sunny,, — Tue, 20 Jan 2026 11:39:20 +0900

타임스탬프 토큰을 발급 받았다고 끝이 아니다. 운영에서는 검증 역시 중요하다.

- TSQ <-> TSR 매칭 여부(요청한 응답이 맞는지)

- 토큰에 대한 서명/인증서 검증(TSA를 신뢰할 수 있는지)

1. TSR status

TSR(TimeStampResp)에는 status(PKIStatusInfo)가 존재한다.

- granted / grantedWithMods 등 성공 여부 확인

2. timeStampToken

status가 성공이면 timeStampToken이 존재

3. messageImprint

- 원문을 다시 해시

- TSTInfo의 messageImprint(알고리즘+해시값)와 비교

4. nonce

TSQ에 nonce를 포함하였다면, TSR에도 같은 nonce가 있어야 한다.

- TSQ nonce == TSR nonce

- 리플레이 공격 방지용

5. policy

TSTInfo 에는 policy OID가 포함

- 허용 정책이 정해져 있다면 필터링

- TSQ에서 reqPolicy를 요청했다면 응답 policy가 동일한지 확인

6. TimeStampToken 서명 검증

- 토큰(CMS SignedData) 서명 검증

- signerInfo가 가리키는 TSA 인증서로 검증

7. TSA 인증서 체인 검증

토큰에 인증서가 포함되어 있어도 신뢰 여부는 별도로 판단해야 함

- 루트/중간CA 체인이 신뢰 저장소에 연결되는지 확인

정리

TimeStampToken 검증은 단순한 시간 검증이 아니다.

- status 확인

- token 존재 확인

- messageImprint 일치 여부

- nonce 매칭

- policy 확인

- 서명 검증

Cryptographic Message Syntax(CMS) 구조

H.Sunny,, — Mon, 19 Jan 2026 09:43:32 +0900

Cryptographic Message Syntax(CMS)

데이터에 암호 보호를 적용하는 방식을 표준으로 정의한 포멧

- CMS는 암호 알고리즘이 아님

- 암호 처리 결과를 담는 컨터이너

RFC5652는 CMS가 다음과 같은 작업을 위해 쓰인다고 설명한다.

- 서명 (Sign)

- 해시/요약 (Digest)

- 인증/무결성 (Auth)

- 암호화(Encrypt)

즉, CMS는 서명파일, 암호화 파일 같은 것을 만들 때 자주 보게 된다.

1. ContentInfo

안에 들어가는 내용 타입을 contentType로 구분하고 그 타입에 맞는 실제 데이터를 content에 담는다.

-> SignedData, EnvelopData 같은 데이터를 한 포맷으로 다룰 수 있음

2. SignedData

원문(또는 원문 해시)에 대해 누가 어떤 방식으로 서명했는지 검증에 필요한 인증서 등을 포함하여 한 덩어리로 묶어둔 구조

- encapContentInfo : 서명 대상 컨텐츠 (optional)

- signerInfos : 서명자 정보

- certificates : 인증서 (optional)

- crls : 검증에 필요한 CRL 정보 (optional)

Attached vs Detached

SignedData는 원문을 포함할 수도 있고, 서명만 포함할 수도 있다.

- Attached : SignedData 안에 원문 포함

- Detached : SignedData 안에 서명만 있고 원문은 밖에 따로 존재

인증서가 포함 되어 있을 시

SignedData에 certificates가 들어 있으면 초기 검증이 편해지는 경우가 많다.

개인키로 서명한 것은 공개키로 검증하여아 하는데, SignedData에 인증서를 포함하면 그 인증서에서 공개키를 추출하여 개인키의 서명을 검증할 수 있기 때문이다. 만약 SignedData에 인증서가 포함되어 있지 않으면, SignedData에 해당하는 공개키를 검증 시스템에서 찾을 수 있는 별도의 방법이 구현되어야 한다.

그러나 인증서가 들어 있다고 해서 신뢰 된다는 의미가 아니다.

신뢰 체인(루트/중간CA)과 정책은 검증 시스템이 결정한다.

PKCS#7과의 관계

CMS는 PKCS#7 계열에서 발전한 표준이라고 보면 된다.

- PKCS#7 문법은 RFC2315로 정의

- CMS는 IETF RFC5652에서 정의

[TSA] TimeStampToken(TST)

H.Sunny,, — Thu, 15 Jan 2026 14:54:38 +0900

TimeStampToken(TST)

TSR(TimeStampResp)에서 제일 중요한 것은 TimeStampToken 이다.

이 값은 "시간 문자열"이 아닌 TSA가 서명해서 주는 토큰이다.

TimeStampToken은 CMS 구조

RFC3161에서 TimeStampToken은 CMS(SignedData) 컨테이너 구조를 만든다고 설명한다.

즉, 토큰 안에는 보통 다음과 같은 것들을 포함한다.

- 서명(Signature)

- 서명자(SignerInfo)

- (옵션) 인증서(Cerificates)

- 본문 데이터(TSTInfo)

TSTInfo

TSTInfo는 TimeStampToken의 본문이다.

RFC3161 기준으로 TSTInfo가 DER 인코딩되어 SignedData의 eContent로 들어간다.

또한 토큰에는 TSA 서명 외에 다른 서명이 들어가면 안된다고 명시한다.

TSTInfo 주요필드

1. policy

- 어떤 정책(OID)로 발급했는지

- 요청에 reqPolicy가 있었다면, 응답 policy도 같아야 한다.(다를 시 unacceptedPolicy)

2. messageImprint (중요)

- hashAlgorithm OID + hashedMessage(해시 값)

- 요청에서 보낸 messageImprint와 동일해야 한다.

3. SerialNumber

- TSA가 각 토큰에 부여하는 고유 번호

- 같은 TSA 기준으로 유일

4. genTime

- TSA가 토큰을 생성한 시간

- UTC 기반으로 표현

5. accuracy (optional)

- genTime의 정확도(오차 범위)

- 시간 범위(상한/하한) 계산 가능

6. ordering (default false)

- ordering이 true면, 같은 TSA에서 나온 토큰들을 genTime 기준으로 정렬 가능

7. nonce (optional, but 중요)

- 요청에 nonce가 있었으면 응답에도 반드시 존재해야 하고 같아야 한다.

8. tsa / extensions (optional)

- TSA 식별 정보(GeneralName)나 확장 필드가 들어올 수 있다.

certReq를 true로 주면 뭐가 달라지나?

요청에서 certReq를 true로 주면, 응답 SignedData의 certficates 영역에 TSA 인증서가 포함되어야 한다.

(포함됐다. != 신뢰된다. 신뢰 체인은 별도 정책/검증 필요)

정리

TimeStampToken(TST)은 "시간 값"이 아니라 서명된 토큰이다.

- TST는 CMS(SignedData) 구조

- 본문은 TSTInfo

- 검증에서 제일 중요한 건 messageImprint / nonce 일치 여부

참고

- RFC 3161 (TSTInfo 구조/필드/nonce 규칙 등)

- RFC 5652 (CMS 개요)

- RFC 5816 (RFC3161 업데이트: ESSCertIDv2, SHA-1 외 해시 허용)

[TSA] RFC 3161 TimeStamp 프로토콜 구조

H.Sunny,, — Mon, 12 Jan 2026 17:42:39 +0900

RFC 3161

TSA에 보내는 요청 형식과 응답 형식을 정의한다.

TimeStampReq(TSQ)

클라이언트 -> TSA 타임스탬프 발급 요청

1. messageImprint

- hashAlgorithm OID + hashedMessage(해시값)

- TSA는 원문을 받지 않고 이 해시 값만 다룬다.

2. nonce(optional)

- 재전송 공격 방지용 랜덤 값

- 요청에 nonce를 넣어서 전송했으면, 응답에도 같은 nonce가 와야한다.

3. reqPolicy(optional)

- 특정 정책(policy OID)로 발급 요청

- TSA가 지원하지 않으면 unacceptedPolicy 에러 발생 가능

4. certReq(optional)

- 응답에 TSA 인증서를 포함해달라는 힌트

- 서버 정책/프로파일에 따라 다르게 동작한다.

5. 전자서명

- GTSA의 경우 TSQ에 서버인증서의 개인키로 전자서명을 해서 보내야한다.

TimeStampResp(TSR)

TSA -> 클라이언트 타임스탬프 응답

1. status(PKIStatusInfo)

- 처리 결과 코드

2. (status가 성공이면) timeStampToken

3. 대표적인 실패 케이스로는

- badAlg (해시 알고리즘 불가)

- badRequest (요청 불가/미지원)

- timeNotAvailable (시간원 문제)

- unacceptedPolicy / unacceptedExtension (지원하지 않는 정책)

- systemFailure (TSA 시스템 에러)

정리

TSQ = 해시 + 옵션

TSR = 상태 +(성공 시) 토큰

[TSA] TSA(Time-Stamp Authority)란?

H.Sunny,, — Tue, 6 Jan 2026 16:56:03 +0900

TSA 개념

TSA(Time-Stamp Authority)는 "어떤 데이터가 특정 시간 이전(또는 그 시각)에 존재했다." 는 사실을 제 3자가 증명해주는 기관이다.

여기서 핵심은 "내 PC 시간"이 아닌 TSA가 서명한 토큰으로 "시각"을 증명한다.

TSA 필요성

로컬 시간만 기록하면 여러 문제가 발생할 수 있다.

1. 시간 조작 가능

서버/PC 시간은 조작이 가능하다.

2. 전자서명 장기검증(LTV)과 연결

서명이 인증서 폐지 전에 생성되었음을 증명할 수 있다.

3. 감사 추적

로그가 정말 그 시점에 기록된 것이 맞는지 증명할 수가 없다.

TSA 요구사항

RFC 3161에 따르면

- 신뢰 가능한 시간원(time source) 사용

- 토큰마다 신뢰 가능한 시간값 포함(UTC 기반)

- 토큰마다 고유한 SerialNumber 부여

- 원문이 아닌 해시(messageImprint)만 타임스탬프

- TSA는 타임스탬프 전용 키로 서명

정리

TSA는 "시간 찍어주는 서버"가 아니다.

데이터를 입력으로 받아서, 데이터가 이 시각에 존재했다는 증명을 서명으로 돌려주는 제3자다.

[Tomcat] 톰캣 catalina.out 로그 일자 별 쌓기(rotatelogs)

H.Sunny,, — Tue, 15 Oct 2024 15:33:13 +0900

톰캣의 catalina.out 로그가 일자가 바뀌어도 일자별로 파일이 생성되지 않고 catalina.out에

계속 append 되는 경우가 종종 있다. 주로 리눅스 시스템에서 발생하는 듯 하다.

${catalina.base}/bin/catalina.sh

374 라인 쯔음에 보면 이런 내용이 있다.

3가지 작업을 해주면 된다.

1. catalina.out 파일 생성 주석 처리

2. 톰캣 start 시 백그라운드로 실행

3. rotatelogs 를 이용한 일자별 로그 관리

# touch "$CATALINA_OUT" // catalina.out 파일을 만드는 부분 주석 처리
  if [ "$1" = "-security" ] ; then
    if [ $have_tty -eq 1 ]; then
      echo "Using Security Manager"
    fi
    shift
    eval $_NOHUP "\"$_RUNJAVA\"" "\"$CATALINA_LOGGING_CONFIG\"" $LOGGING_MANAGER "$JAVA_OPTS" "$CATALINA_OPTS" \
      -D$ENDORSED_PROP="\"$JAVA_ENDORSED_DIRS\"" \
      -classpath "\"$CLASSPATH\"" \
      -Djava.security.manager \
      -Djava.security.policy=="\"$CATALINA_BASE/conf/catalina.policy\"" \
      -Dcatalina.base="\"$CATALINA_BASE\"" \
      -Dcatalina.home="\"$CATALINA_HOME\"" \
      -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
      org.apache.catalina.startup.Bootstrap "$@" start 2>&1\ // 백그라운드 실행
| /usr/sbin/rotatelogs "$CATALINA_BASE"/logs/catalina.%Y-%m-%d.log 86400 540 & // 일자별 로그 관리
      # >> "$CATALINA_OUT" 2>&1 "&" // 주석 처리


  else
    eval $_NOHUP "\"$_RUNJAVA\"" "\"$CATALINA_LOGGING_CONFIG\"" $LOGGING_MANAGER "$JAVA_OPTS" "$CATALINA_OPTS" \
      -D$ENDORSED_PROP="\"$JAVA_ENDORSED_DIRS\"" \
      -classpath "\"$CLASSPATH\"" \
      -Dcatalina.base="\"$CATALINA_BASE\"" \
      -Dcatalina.home="\"$CATALINA_HOME\"" \
      -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
      org.apache.catalina.startup.Bootstrap "$@" start 2>&1\ // 백그라운드 실행
| /usr/sbin/rotatelogs "$CATALINA_BASE"/logs/catalina.%Y-%m-%d.log 86400 540 & // 일자별 로그 관리
      # >> "$CATALINA_OUT" 2>&1 "&" // 주석 처리

[Java] 강한 결합 vs 약한 결합(의존성 주입)

H.Sunny,, — Mon, 14 Oct 2024 13:32:16 +0900

강한 결합

객체 간의 의존 관계에서 직접 객체를 생성 하는 경우

- 생성부터 메모리 관리를 위한 소멸까지 해당 객체의 라이프 사이클을 개발자가 다 관리해야함

ex)

public void test1(){

Test t1 = new Test(); // 강한 결합 - 직접 생성

}

약한 결합

객체 간의 의존 관계에서 이미 생성한 객체를 주입 받는 경우

- 사용하기만 하면 되므로 개발자가 관리할 것이 적음

ex)

public void test2(Test t){ // 약한 결합 - 생선된 것을 주입 받음(의존성 주입)

Test t2 = t;

}

의존성 주입(DI)을 통해 약한 결합을 사용하면 다른 클래스의 변화에 더욱 안전하고 유연하게 대처할 수 있음

[Tomcat] 콘솔 한글 깨짐 증상 해결

H.Sunny,, — Thu, 1 Feb 2024 10:47:01 +0900

톰캣을 실행하면 콘솔에서 다음과 같이 한글이 깨지는 경우가 있다.

이는 인코딩의 문제로 Windows Console의 한국어 인코딩의 경우 EUC-KR 이지만 톰캣의 인코딩의 경우 기본 UTF-8로 설정되어 있기 때문이다.

톰캣 설치경로의 conf/logging.properties 파일을 보면 아래와 같은 설정부분이 있을 것이다.

UTF-8 인코딩을 EUC-KR로 수정해주면 된다.

java.util.logging.ConsoleHandler.encoding = EUC-KR

[Gitlab]Gitlab 명령어 정리

H.Sunny,, — Mon, 10 Apr 2023 14:44:53 +0900

1. Gitlab 시작

gitlab-ctl start

2. Gitlab 종료

gitlab-ctl stop

3. Gitlab 재시작

gitlab-ctl restart

4. Gitlab 설정 적용

gitlab-ctl reconfigure

5. 서비스 상태 확인

gitlab-ctl status

6. gitlab 로그 확인

공통 로그

tail -f /var/log/gitlab/gitlab-rails/production.log

서비스 로그

gitlab-ctl tail 서비스명

ex) gitlab-ctl tail nginx

[Gitlab] gitlab-ctl reconfigure 시 selinux 에러

H.Sunny,, — Mon, 27 Mar 2023 17:29:30 +0900

gitlab.rb 파일 등 gitlab 관련 설정을 변경하고 gitlab-ctl reconfigure을 시도 하는데 아래와 같은

에러 메세지가 출력 되는 경우가 있다.

Running handlers:
There was an error running gitlab-ctl reconfigure:

execute[semodule -i /opt/gitlab/embedded/selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp] (gitlab::selinux line 32) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of semodule -i /opt/gitlab/embedded/selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp ----
STDOUT:
STDERR: libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/pp failed with code: 255. (No such file or directory).
gitlab-13.5.0-gitlab-shell: libsepol.policydb_read: policydb module version 19 does not match my version range 4-17
gitlab-13.5.0-gitlab-shell: libsepol.sepol_module_package_read: invalid module in module package (at section 0)
gitlab-13.5.0-gitlab-shell: Failed to read policy package
libsemanage.semanage_direct_commit: Failed to compile hll files into cil files.
(No such file or directory).
semodule: Failed!
---- End output of semodule -i /opt/gitlab/embedded/selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp ----
Ran semodule -i /opt/gitlab/embedded/selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp returned 1

크게 비중있게 다룰 내용은 아니라 간단히 요약하자면 그놈의 selinux가 문제다.

selinux 패키지에 누락된 부분이 있어서 발생하는 것이다.

해결방법

yum install libsemanage-static libsemanage-devel

[Gitlab] Centos7에 Gitlab-CE 구축

H.Sunny,, — Mon, 27 Mar 2023 17:07:06 +0900

사전작업

1. 방화벽 해제

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
systemctl reload firewalld

GItlab 설치

1. GitLab package repository 추가

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

2. package 설치

sudo EXTERNAL_URL="사용할 도메인 주소:port" yum install -y gitlab-ce

ex) test.gitlab.co.kr 의 도메인에 18081 포트를 사용

$ sudo EXTERNAL_URL="test.gitlab.co.kr:18080" yum install -y gitlab-ce

==> 설치 후 추후 gitlab.rb에서 external_url 으로 변경 가능

3. 실행 및 로그인

정상적으로 설치가 완료되었다면 설치 시 입력한 EXTERNAL_URL의 정보를 브라우저에 입력하면

아래와 같은 페이지가 로드 될 것이다.

혹시나 아래와 같이 502 Whoops, GitLab is taking too much time to respond. 에러가 뜬다면 여유를 가지고 1~2분 정도 기다리면 접속이 된다.

아직 서비스가 정상적으로 모두 올라가지 않아서 그런 것이다.

설치가 완료되고 나면 터미널에 아래와 같은 문구가 출력되어 있을 것이다.

Notes:
Default admin account has been configured with following details:
Username: root
Password: You didn't opt-in to print initial root password to STDOUT.
Password stored to /etc/gitlab/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours.

초기 비밀번호는 /etc/gitlab/initial_root_password에 저장되어 있으며 이 파일은 처음 설정을 적용한 후 24시간 뒤에 사라진다는 내용이다. 해당 파일은 내용은 아래 처럼 적혀있다.

# WARNING: This value is valid only in the following conditions
#          1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).
#          2. Password hasn't been changed manually, either via UI or via command line.
#
#          If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

Password: uOZjs2M979UjfpZYyh1CRozf9AHZYbF4oVE0Tf4dU= (초기 root 패스워드)

# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.

근데 필자의 경우 이 초기 root 패스워드로 로그인을 시도해봐도 안되서 수동으로 root 패스워드를 재설정하였다.

https://hsunnystory.tistory.com/217

[Gitlab] 사용자 비밀번호 변경(root 계정 포함)

UI, Rake task, Rails console, Users API를 이용하여 사용자 패스워드를 변경할 수 있다. 이 글에서는 Rails console를 이용한 방법에 대해 포스팅 한다. 1. Rails console 열기 sudo gitlab-rails console 2. 변경할 사용자

hsunnystory.tistory.com

로그인 후 아래와 같이 나온다면 설치는 정상적으로 완료

https://hsunnystory.tistory.com/218

[Gitlab] SSL 인증서 적용(HTTPS 수동 설정)

Gitlab에 ssl을 적용하는 방법은 크게 2가지가 있다. 1. Let’s Encrypt 사용 2. SSL 인증서 수동 적용 이 글에서는 2. SSL 인증서 수동 적용에 관련하여 포스팅 한다. /etc/gitlab/gitlab.rb 파일에서 아래의 설정

hsunnystory.tistory.com

https://hsunnystory.tistory.com/216

[Gitlab] ERROR 422 The change you requested was rejected. 해결

Gitlab 구축 또는 설정 값을 변경 한 후 다음과 같은 에러 페이지가 나오는 경우가 있다. HTTP 상태 코드 422 는 422 Unprocessable Entity 이 응답은 서버가 요청을 이해하고 요청 문법도 올바르지만 요청된

hsunnystory.tistory.com

https://hsunnystory.tistory.com/219

[Gitlab] Repository 변경(운영 중 포함)

1. gitlab 서비스 중지 gitlab-ctl stop 2. gitlab.rb 수정 위와 같이 git_data_dirs 설정 부분에 path 설정 git_data_dirs({ "default" => { "path" => "데이터를 저장할 경로" } }) 3. 수정 사항 반영 gitlab-ctl reconfigure 4. gitlab

hsunnystory.tistory.com

https://hsunnystory.tistory.com/220

[Gitlab] gitlab-ctl reconfigure 시 selinux 에러

gitlab.rb 파일 등 gitlab 관련 설정을 변경하고 gitlab-ctl reconfigure을 시도 하는데 아래와 같은 에러 메세지가 출력 되는 경우가 있다. Running handlers: There was an error running gitlab-ctl reconfigure: execute[semodule

hsunnystory.tistory.com

참고 : Centos7 Gitlab Community Edition 설치 가이드 https://about.gitlab.com/install/#centos-7

[Gitlab] Repository 변경(운영 중 포함)

H.Sunny,, — Mon, 27 Mar 2023 16:09:42 +0900

1. gitlab 서비스 중지

gitlab-ctl stop

2. gitlab.rb 수정

위와 같이 git_data_dirs 설정 부분에 path 설정

git_data_dirs({
"default" => { "path" => "데이터를 저장할 경로" }
})

3. 수정 사항 반영

gitlab-ctl reconfigure

4. gitlab 서비스 시작

gitlab-ctl start

* 혹시 이미 운영중인데 Repository를 변경해야 하는 경우 기존 데이터를 복사 후 새로운 경로에 복사 후 그 경로를 지정해주면 된다.

[Gitlab] SSL 인증서 적용(HTTPS 수동 설정)

H.Sunny,, — Tue, 28 Feb 2023 17:33:57 +0900

Gitlab에 ssl을 적용하는 방법은 크게 2가지가 있다.

1. Let’s Encrypt 사용

2. SSL 인증서 수동 적용

이 글에서는 2. SSL 인증서 수동 적용에 관련하여 포스팅 한다.

/etc/gitlab/gitlab.rb 파일에서 아래의 설정을 해준다.

1. HTTP 요청을 HTTPS로 리다이렉트

nginx['redirect_http_to_https'] = true

2. 사용할 도메인 URL 설정

external_url '사용할 URL'

3. SSL 인증서 경로 지정

nginx['ssl_certificate'] = "crt 파일의 절대경로"
nginx['ssl_certificate_key'] = "key 파일의 절대경로"

4. SSL 인증서 패스워드 정보(Key에 비밀번호가 설정되어 있는 경우)

nginx['ssl_password_file'] = 'key 비밀번호가 있는 파일의 절대경로' --> ex) txt 파일

5. 설정 값 적용

sudo gitlab-ctl reconfigure

[Gitlab] 사용자 비밀번호 변경(root 계정 포함)

H.Sunny,, — Tue, 21 Feb 2023 15:07:46 +0900

UI, Rake task, Rails console, Users API를 이용하여 사용자 패스워드를 변경할 수 있다.

이 글에서는 Rails console를 이용한 방법에 대해 포스팅 한다.

1. Rails console 열기

sudo gitlab-rails console

2. 변경할 사용자 찾기

user = User.find_by_username '사용자이름'

3. user.password 및 user.password_confirmation에 대한 값을 설정하여 암호 재설정

new_password = '변경할 패스워드'
user.password = new_password
user.password_confirmation = new_password

4. 저장

user.save!

5. Rails Console 종료

exit

출처 : https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password

Reset a user

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

docs.gitlab.com