taecostudy76 님의 블로그

[Spring Boot] IoT 헬스케어 시스템의 실시간 데이터 파이프라인 구축기 (SSE + 데이터 샘플링)

taecostudy76 — Sun, 10 May 2026 10:14:46 +0900

1. 들어가며: 쏟아지는 센서 데이터, 어떻게 감당할 것인가?

현재 라즈베리파이를 활용한 '실시간 피보호자 헬스케어 모니터링 시스템'의 백엔드를 개발 중이다. 센서로부터 심박수, 호흡수, 낙상 여부 등의 생체 데이터가 1초 단위로 서버에 전송되고 있는데, 여기서 큰 고민에 빠졌다.

"1초마다 들어오는 데이터를 그대로 DB에 save() 하면, 유저가 늘어날수록 DB I/O 부하가 폭발하지 않을까?"

하지만 보호자 앱에서는 1. 1초 단위의 실시간 그래프를 봐야 하고, 2. 긴급 상황 발생 시 즉시 알림이 가야 한다. 이 딜레마를 해결하기 위해 데이터의 목적에 따라 처리 방식을 나누는 '3-Track 데이터 파이프라인'을 설계하고 적용한 과정을 기록해 본다.

2. 아키텍처 설계: 3-Track 파이프라인

단순히 Controller -> Service -> DB 저장으로 이어지던 일차원적인 로직을, 중간에 VitalService를 '총괄 매니저'로 두어 3갈래로 데이터를 분배하도록 개선했다.

Track A (실시간 모니터링): 1초마다 들어오는 데이터는 DB를 거치지 않고, 가공(DTO 변환) 후 곧바로 SseService를 통해 프론트엔드로 전송한다.
Track B (블랙박스/긴급 상황): 심박수 비정상이나 낙상이 감지되면, 증거 보존을 위해 즉시 EmergencyEvent 테이블에 저장하고 알림을 발생시킨다.
Track C (일반 데이터 샘플링): 가장 부하가 심한 일반 생체 데이터(Vital 테이블)는 10초 주기로 1개씩만 솎아내어(Sampling) 저장한다. 이를 통해 DB 용량과 부하를 1/10 수준으로 최적화했다.

3. 핵심 구현: 동시성을 고려한 10초 샘플링 로직

가장 핵심이 되는 '10초 샘플링' 로직을 구현할 때, 단순히 서버에 long lastTime 변수 하나를 두면 여러 기기에서 동시에 데이터가 들어올 때 초시계가 꼬이는 문제(동시성 문제)가 발생한다.

이를 해결하기 위해 ConcurrentHashMap을 사용하여 '기기별 독립적인 초시계 장부'를 만들었다.

트래픽 최적화를 적용한 코드 (VitalService.java)

Java

@Service
@RequiredArgsConstructor
public class VitalService {

    // ... (의존성 주입 생략)

    //   기기별로 마지막 저장 시간을 기록하는 스레드 안전한 Map 장부
    private final Map<String, Long> lastSavedTimeMap = new ConcurrentHashMap<>();

    @Transactional
    public void getVitalData(VitalRequestDto vitalDto) {
        // 1. 유저 및 기기 확인
        Device device = deviceRepository.findBySerialNum(vitalDto.serialNum()).orElseThrow(...);
        Users user = device.getUser();

        // 2. 긴급 상황 검사 (Track B)
        boolean isFallEvent = emergencyEventService.checkFallEvent(vitalDto, user, device);
        boolean isHREvent = emergencyEventService.checkHeartBreathEvent(vitalDto, user, device);
        boolean isEmergency = isFallEvent || isHREvent; // 하나라도 발생하면 긴급!

        // 3. 실시간 SSE 전송 (Track A)
        String statusStr = isEmergency ? "위험" : "정상";
        ResponseUserVital sseData = new ResponseUserVital(user.getId(), vitalDto.heartRate(), vitalDto.breathRate(), statusStr);
        sseService.sendVitalDataToClient(user.getId(), sseData);

        // 4. 10초 샘플링 DB 저장 (Track C)
        long currentTime = System.currentTimeMillis();
        long lastSavedTime = lastSavedTimeMap.getOrDefault(vitalDto.serialNum(), 0L);

        // 마지막 저장 시점으로부터 10초(10,000ms)가 지났을 때만 DB에 Insert
        if (currentTime - lastSavedTime >= 10000) {
            Vital newVital = Vital.builder()
                .user(user)
                .device(device)
                .heartRate(vitalDto.heartRate())
                .breathRate(vitalDto.breathRate())
                .isFallDetected(isEmergency)
                .isPresent(vitalDto.isPresent())
                .build();
            
            vitalRepository.save(newVital);
            
            //   [주의] 저장 후 반드시 장부의 시간을 현재 시간으로 갱신해야 함!
            lastSavedTimeMap.put(vitalDto.serialNum(), currentTime);
        }
    }
}

4. 오늘 마주친 트러블슈팅 & 배운 점

1. DTO와 Entity의 엄격한 분리

초기에는 라즈베리파이에서 받은 데이터 형식과 프론트로 보내는 형식이 혼재될 뻔했다.

외부 통신(택배 상자): VitalRequestDto, ResponseUserVital (DTO 패키지)
내부 DB(창고): Vital, EmergencyEvent (Entity 패키지) 역할을 명확히 분리하니, 서비스 레이어(VitalService)가 단순한 비즈니스 로직이 아니라 데이터를 가공하고 라우팅하는 훌륭한 파이프라인 매니저 역할을 수행하게 되었다.

2. 상태(State) 갱신의 중요성

초기 코드 작성 시 10초마다 save()는 작성해 놓고, 정작 lastSavedTimeMap.put()으로 타이머를 초기화하는 코드를 빼먹는 실수를 했다. 이 한 줄이 빠지면 첫 10초 이후에는 서버가 무조건 10초가 넘었다고 판단하여 다시 1초마다 DB에 저장하는 폭주 기관차가 되어버린다. 조건문을 통과하여 동작을 수행했다면, 반드시 기준이 되는 상태값을 업데이트해야 함을 뼈저리게 느꼈다.

5. Next Step ‍♂️

1초 단위의 거대한 데이터 흐름을 제어하는 뼈대는 완성되었다. 다음 작업으로는 아래 두 가지를 진행할 예정이다.

데이터 안정화: 센서 데이터가 일시적으로 튀는 노이즈 현상을 막기 위해 이동 평균(Moving Average) 알고리즘 구현하기
배치 처리(Batch): 매일 새벽, 하루 동안 쌓인 샘플링 데이터를 분석해 평균/최소/최대 수치를 계산하고 HealthStatus 테이블에 요약 저장하는 스케줄러 개발하기

[백엔드 개발기] 실시간 IoT 헬스케어 생체 데이터 파이프라인 구축 및 아키텍처 설계

taecostudy76 — Fri, 8 May 2026 23:52:26 +0900

1. 도입: 기획 화면을 서버 아키텍처로 번역하다

프로젝트의 시작은 팀원이 그려온 기획 화면(사진)들이었다. 스마트워치(Edge 기기)에서 수집된 피보호자의 생체 데이터(심박수, 호흡수, 낙상 여부)를 실시간으로 모니터링하고, 비정상 수치 발생 시 보호자에게 즉각적인 알림을 보내는 시스템을 구축해야 했다.

단순한 CRUD 게시판이 아니라 1초마다 쏟아지는 센서 데이터를 어떻게 안정적으로 처리하고 화면에 뿌려줄 것인가? 이 질문에서부터 아키텍처 고민이 시작되었다.

2. 데이터 성격에 따른 처리 주체 분리 (Edge vs Server)

가장 먼저 고민한 것은 "긴급 상황을 누가 판단할 것인가?" 였다.

낙상 감지 (Edge Computing): 초당 수십 번씩 변하는 자이로스코프의 원시 데이터(Raw Data)를 서버가 다 받을 수는 없다. 따라서 기기가 직접 연산하여 isFallDetected = true라는 '결과값'만 던져주면, 백엔드는 이를 100% 신뢰하고 즉시 알림을 생성하도록 설계했다.
심박수/호흡수 이상 (Server-side Rule Engine): 반면, 심박/호흡은 병원 정책이나 환자 상태에 따라 '정상 기준'이 수시로 바뀔 수 있다. 따라서 기기는 '수치'만 던지고, 백엔드에서 60~120이라는 비즈니스 룰을 적용해 이상 여부를 판단하도록 역할을 명확히 분리했다.

3. 객체 지향(OOP)을 활용한 클린 코드: "룰은 엔티티가 스스로 알게 하라"

기능을 구현하다 보니 EmergencyEventService(알림 생성)와 UserProfileService(화면 조회) 양쪽에서 '심박수 60~120 비교 로직'이 중복해서 사용되는 것을 발견했다.

DRY(Don't Repeat Yourself) 원칙을 지키기 위해, 판단 로직을 서비스 클래스에서 빼내어 데이터의 주인인 Vital 엔티티 내부의 메서드(isHeartBreathNormal())로 캡슐화했다. 마찬가지로 "FALL = 낙상이 감지되었습니다" 같은 문자열 변환 로직도 EmergencyEvent 엔티티로 응집시켜, 불필요한 서비스 간의 의존성(순환 참조 위험)을 제거하고 유지보수성을 극대화했다.

4. 실시간 데이터 파이프라인과 Two-Track 저장 전략

센서에서 데이터가 들어올 때의 플로우를 다음과 같이 컨베이어 벨트처럼 4단계 파이프라인으로 설계하고, 이를 지휘하는 VitalProcessingService(총괄 매니저)를 도입했다.

안정화 (Filter): 날것의 센서 데이터에서 튀는 값(Noise)을 깎아내는 알고리즘 적용
실시간 전송 (SSE): 프론트엔드 그래프 렌더링을 위해 가공된 데이터를 지연 없이 스트리밍
긴급 검사: 수신 즉시 룰을 체크하여 긴급 상황이면 DB에 알림(EmergencyEvent) 생성
최종 저장: 생체 데이터(Vital) DB 저장

트래픽 최적화 포인트 (Two-Track 전략): 1초마다 들어오는 모든 정상 생체 데이터를 그대로 DB에 INSERT 하면 부하가 엄청나다. 따라서 긴급 상황은 1초마다 실시간으로 검사 및 알림을 보내되, 정상 데이터는 메모리(Buffer)에 들고 있다가 Spring @Scheduled를 활용해 10초 주기로 한 번에 DB에 밀어 넣는(Batch Insert) 투트랙 아키텍처를 도입해 DB I/O를 획기적으로 줄였다.

5. 트러블슈팅: 404 에러와 DB 페이징의 함정

개발 중 겪었던 두 가지 재미있는(?) 삽질과 해결 과정이다.

API 404 Not Found의 비밀: Postman으로 긴급 알림 상세 조회 테스트 중 권한(401/403)이나 서버 에러(500)가 아닌 404 에러를 마주했다. 원인은 컨트롤러의 클래스 레벨 @RequestMapping과 메서드 레벨 @GetMapping이 합쳐지는 과정에서 주소 경로 맨 뒤의 /detail을 호출 시 누락했던 단순 오타였다. (덤으로 @GetMapping 내부 문자열 시작 시 안전하게 /를 붙이는 컨벤션도 맞추었다.)
사라진 최신 데이터 미스터리: 분명 서버 코드는 OrderByRecordedAtDesc로 최신 데이터를 가져오게 짰는데, DB GUI 툴(Supabase)에서는 최신 데이터가 안 보였다. 알고 보니 서버 버그가 아니라, 브라우저 렌더링 부하를 막기 위해 GUI 툴 자체가 100건 단위로 페이징(Pagination) 처리를 해서 보여주고 있었기 때문이었다. 이는 역으로 나중에 프론트엔드에게 통계 리스트를 내려줄 때 왜 페이징 처리가 필수적인지 뼈저리게 깨닫는 계기가 되었다.

6. 결론: 협업을 위한 읽기/쓰기(Read/Write) 분리

팀원과 업무를 나눌 때, 생체 데이터 처리는 내가 맡고 화면 통계 API는 팀원에게 위임했다. 이것이 가능했던 이유는 데이터를 가공해서 밀어 넣는 파이프라인(Write)과 저장된 데이터를 꺼내보는 통계(Read)의 역할을 완벽하게 분리했기 때문이다. 팀원에게는 "데이터를 자바 메모리로 다 가져오지 말고, 무조건 DB 단에서 JPQL로 AVG, MAX, GROUP BY 계산을 끝내서 응답해라!"라는 성능 최적화 가이드라인도 함께 전달했다.

이제 뼈대는 완벽하게 세워졌다. 다음 목표는 실시간 센서 데이터의 노이즈를 효과적으로 제거할 '데이터 안정화 알고리즘'을 구현하여 파이프라인의 첫 단추를 완성하는 것이다!

[Spring Boot] IoT 실시간 모니터링: SSE 통신 원리와 Optional 리팩토링 경험기

taecostudy76 — Thu, 16 Apr 2026 15:34:39 +0900

최근 라즈베리 파이(IoT)에서 수집한 활력 징후(심박수, 호흡수 등) 데이터를 프론트엔드로 실시간 전달하는 백엔드 서버를 개발하고 있습니다. 이 과정에서 SSE(Server-Sent Events)를 활용한 실시간 통신 원리를 깊게 이해하게 되었고, JPA를 사용할 때 Optional을 처리하는 로직을 제 방식대로 깔끔하게 리팩토링한 경험을 공유하고자 합니다.

1. SSE(Server-Sent Events) 통신: 헷갈렸던 데이터의 흐름

초기에는 라즈베리 파이에서 서버로 데이터를 쏘는 부분(POST /api/vitals)에 프론트엔드로 데이터를 전달하는 로직이 섞여 있어서 통신 방식에 대한 혼란이 있었습니다.

"클라이언트가 조회를 하려면 무조건 GET 방식을 써야 하는데, 왜 POST 요청 안에서 클라이언트에게 데이터를 쏴주고 있지?"

이 혼란은 SSE의 본질인 "단방향 Push"와 "스트림(Stream)"의 개념을 깨달으면서 완벽하게 해결되었습니다. 서버에는 총 3개의 문(API)이 분리되어 있어야 했습니다.

데이터 수신 (POST): 라즈베리 파이가 측정한 데이터를 서버로 던지는 문.
실시간 파이프 연결 (GET): 프론트엔드가 처음 접속해 EventSource로 "나 계속 데이터 받을게!" 하고 수도관(SSE)을 열어두는 문.
과거 기록 조회 (GET): 파이프 연결 전의 과거 데이터를 한 번에 가져가는 일반적인 문.

즉, 라즈베리 파이가 POST로 데이터를 던지자마자, 서버는 DB에 이를 저장함과 동시에 미리 열려있던 프론트엔드의 GET 파이프(SSE)**를 통해 데이터를 물이 흘러가듯(Stream) 강제로 밀어 넣는 것이었습니다.

단순히 API를 만드는 것을 넘어, ConcurrentHashMap을 이용해 여러 유저의 SseEmitter(수도관)를 스레드 안전하게 관리하고, 연결이 끊기면 장부에서 삭제하는 디테일한 로직까지 고민해 볼 수 있는 좋은 경험이었습니다.

2. 논리적 모순 해결: Optional과 orElseThrow의 올바른 사용법

기기를 조회하는 로직을 작성하던 중, 기존 로직의 불필요한 점을 발견하고 구조를 개선했습니다. 기존 코드는 아래와 같이 작성되어 있었습니다.

[수정 전 코드: 논리적 모순]

Java

public Optional<DeviceDto.ResponseDevice> getDeviceStatus(Long userId) {

    Device device = deviceRepository.findByUserId(userId)
        .orElseThrow(() -> new IllegalArgumentException("연결 된 디바이스가 없습니다."));

    boolean isConnected = checkConnection(device.getLastConnectedAt());

    return new DeviceDto.ResponseDevice(...); // 타입 에러 발생!
}

이 코드는 다음과 같은 두 가지 문제가 있었습니다.

orElseThrow()를 사용해 예외 처리를 마쳤음에도, 메서드의 반환 타입을 Optional로 선언했습니다.
예외가 터지지 않고 맨 밑의 return까지 도달했다는 것은 **"기기가 무조건 100% 존재한다"**는 뜻인데, 굳이 "없을 수도 있다"는 의미의 Optional로 다시 포장할 필요가 없었습니다.

[수정 후 코드: 깔끔한 단일 객체 반환]

Java

public DeviceDto.ResponseDevice getDeviceStatus(Long userId) {

    // 1. 없으면 바로 예외를 던지고 종료!
    Device device = deviceRepository.findByUserId(userId)
        .orElseThrow(() -> new IllegalArgumentException("연결 된 디바이스가 없습니다."));

    // 2. 예외가 안 터졌다면 무조건 객체가 있으므로 안전하게 로직 실행
    boolean isConnected = checkConnection(device.getLastConnectedAt());

    // 3. Optional 껍질 없이 DTO 알맹이만 깔끔하게 반환
    return new DeviceDto.ResponseDevice(
        device.getId(),
        isConnected,
        device.getSerialNum()
    );
}

[리팩토링의 결과] "기기가 1대만 존재한다"는 비즈니스 로직에 맞춰 반환값을 단일 객체로 변경했고, 중간에 orElseThrow()로 방어벽을 세웠으니 반환 타입에서 과감하게 Optional을 제거했습니다. 덕분에 코드가 위에서 아래로 물 흐르듯 자연스러워졌고, 이 메서드를 호출하는 컨트롤러 입장에서도 껍질을 깔 필요 없이 바로 DTO를 사용할 수 있게 되었습니다.

마무리하며

이번 경험을 통해 "돌아가는 코드"를 짜는 것을 넘어, "왜 이 통신 방식을 사용하는가?", "이 타입(Optional)을 반환하는 것이 논리적으로 타당한가?"를 치열하게 고민하게 되었습니다. 앞으로도 프론트엔드와 유연하게 소통하며, 불필요한 리소스 낭비가 없는 단단한 백엔드 서버를 구축해 나가고 싶습니다.

[JPA/Spring] 엔티티 설계의 정석: @NoArgsConstructor(access = AccessLevel.PROTECTED)와 @Builder의 조화

taecostudy76 — Wed, 11 Mar 2026 15:51:14 +0900

최근 프로젝트를 진행하며 JPA 엔티티를 설계하는 과정에서 왜 특정 어노테이션을 조합해 사용하는지, 그리고 객체 지향적인 설계란 무엇인지 깊게 파고들어 보았습니다. 공부한 내용을 잊지 않기 위해 정리합니다.

1. @NoArgsConstructor(access = AccessLevel.PROTECTED)

JPA 엔티티를 만들 때 가장 먼저 마주친 의문은 "왜 기본 생성자를 굳이 protected로 막는가?"였습니다.

JPA의 요구사항: JPA는 프록시 객체를 생성하기 위해 기본 생성자가 반드시 필요합니다. 하지만 접근 제어자가 private이면 접근할 수 없으므로 최소 protected 이상이어야 합니다.
객체 오염 방지: 개발자가 new Member()와 같이 빈 객체를 생성하는 것을 막기 위함입니다. 필수 데이터가 없는 불완전한 객체가 시스템을 돌아다니는 것을 원천 차단합니다.
결론: JPA는 일하게 하되, 개발자의 실수는 막는 절묘한 방어막입니다.

2. @Builder와 생성자의 조합

빈 객체 생성을 막았다면, 객체는 어떻게 만들어야 할까요? 정답은 빌더 패턴입니다.

가독성: new Member("홍길동", 20, ...) 처럼 순서에 의존하는 대신 .name("홍길동").age(20)처럼 명확한 코드를 작성할 수 있습니다.
안전성: 클래스 레벨이 아닌 생성자 레벨에 @Builder를 붙여, 내가 허용하는 필드만 빌더에 포함하는 정교한 설계가 가능해집니다.

3. @Embeddable & @Embedded (데이터의 부품화)

모든 필드를 하나의 클래스에 다 넣으면 클래스가 너무 비대해집니다. 이때 사용하는 것이 임베디드 타입입니다.

@Embeddable: 독립적인 테이블이 아닌, 다른 엔티티의 부품이 될 클래스에 사용합니다.
@AttributeOverrides: 같은 부품을 한 테이블에서 다른 컬럼명으로 쓰고 싶을 때 재정의하여 사용합니다.
이점: 코드의 재사용성이 높아지고, 실력 점수 계산 같은 특정 로직을 해당 클래스에 응집시킬 수 있어 객체 지향적입니다.

4. 양방향 연관관계와 데이터 일치

MatchRecord(게임 기록)와 MatchParticipant(참가자)의 관계를 공부하며 가장 헷갈렸던 부분입니다.

@ManyToOne vs @OneToMany: '다(Many)' 쪽이 외래 키(FK)를 가지는 주인입니다.
양방향 데이터 일치의 필요성: DB는 FK 하나로 양쪽을 알지만, 자바 객체는 그렇지 않습니다.
연관관계 편의 메서드: matchRecord.getParticipants().add(this);
생성자에서 이 코드를 호출함으로써, 내 수첩뿐만 아니라 상대방의 리스트에도 나를 추가해줘야 메모리상에서 데이터 불일치가 일어나지 않습니다.

마치며

단순히 코드를 작동시키는 것을 넘어, "왜 이 어노테이션을 쓰는가?"와 "어떻게 하면 더 안전한 객체를 만들 것인가?"를 고민해 본 시간이었습니다. JPA는 알수록 객체 지향 프로그래밍에 대한 깊은 이해를 요구하는 것 같습니다.

멀티캠퍼스 [현대 이지웰] 풀스택 개발자 수강 최종 후기

taecostudy76 — Mon, 22 Dec 2025 15:22:49 +0900

드디어 멀티캠퍼스 [현대이지웰] 풀스택 개발자 과정을 수료하게 되었습니다.

처음 시작 했을 때가 7월 초였는데 이제 6개월이 지나 12월이 되었고 크리스마스 얼마 남지 않았습니다.

시간이 정말 빠른 것 같습니다. ㅜㅜ

오늘은 후기에 대해서 작성을 해보려고 합니다.

현대 이지웰 과정은 총 6개월입니다.

보통 다른 과정들도 6개월이라서 큰 차이는 없습니다.

저는 6회 차를 수강했는데 이번 과정에 약 30명 정도 하는 인원이 듣기 때문에 메인 강사님과 보조 강사님 두 분이 같이 진행하셨습니다.

메인 강사님은 모든 과정 수업을 진행하시고 보조 강사님은 질문 같은 것들을 답변해주시면서 진도에 차질 없이 수업을 진행할 수 있었습니다.

현대 이지웰 과정은 기본 HTML, CSS, JavaScript 등 프론트 과정과 Java, Spring Boot 등 백엔드 과정으로 되어 있습니다.

기본 웹 페이지를 개발 하는 것들은 거의 다 배울 수 있었습니다.

처음에 이 과정을 봤을 때 MyBatis만 배우고 JPA는 안배우는 줄 알았지만 JPA도 배워서 좋았습니다.

수업 내용을 전부 설명할 수는 없지만 웹 개발 생태계가 시대에 따라 변화하는 과정을 함께 언급하시며 수업을 받았기 때문에 유익했습니다.

그리고 전담 취업 컨설턴트님도 있어서 취업 관련 고민 상담이나 진로 선택에 있어서 많은 도움을 받았습니다.

그리고 수업 과정 중간에 취업 관련 멘토링도 있어서 자소서나 포트폴리오를 어떻게 작성해야 하는지에 대한 부분도 굉장히 유익했습니다.

다만 아쉬웠던 점은 초반에는 취업 컨설턴트님과 접점이 있었지만 후반으로 갈 수록 접점이 거의 없었습니다.

공지사항이나 관련 정보등 MLP라는 사이트를 통해서 확인할 수 있었습니다.

이런 점은 비대면으로 수업하면서 좋았다고 생각합니다. Slack를 사용해서 매니저님이 공지를 해주시기도 했지만, MLP로 직접 들어가서

확인을 할 수 있었습니다.

수업은 매주 월요일 부터 금요일까지 아침 9시부터 오후 6시까지 진행했습니다.

오랜 시간 앉아서 수업을 듣기 때문에 지루할 수도 있습니다.

저는 이론 보다는 직접 생각하면서 코드를 짜는 것이 더 재밌었습니다.

그래서 초반에 이론 중심으로 수업을 들을 때는 굉장히 지루했습니다.

하지만 중간에 실습하는 과제를 주시는데 그때 정말 재미있게 과제를 풀어나갔습니다.

그래서 이론과 실습을 적절히 분배해서 수업을 하는 것 같아서 만족했습니다.

이론 수업이 다 끝나면 수업을 바탕으로 프로젝트를 진행합니다.

프로젝트는 랜덤으로 팀을 만들어 주고 주어진 주제에 대해서 저희가 아이디어를 내고 개발을 진행합니다.

최종 프로젝트 개발 기간은 대략 8주 정도 주어집니다.

그 기간 동안에는 멘토링 시간도 있어서 더욱 알찬 시간입니다.

수업 때와 똑같이 아침 9시부터 오후 6시까지 개발을 진행합니다.

이때가 저는 가장 재미있었습니다.

실제 배운 내용을 가지고 개발을 진행하고 어려움이 있으면 고민도 하고 구글링도 하면서 실력이 늘어나는 것을 몸소 체감하는 시간이었습니다.

그리고 거의 끝날 때쯤에는 배포 과정 설명을 따로 pdf 파일로 주셔서 그걸로 진행했습니다.

한 번도 직접 배포한 경험이 없었기 때문에 굉장히 어려웠지만 하면서 배우는 것들이 있어서 좋았습니다.

이론적으로 자세한 설명이 있었던 것은 아니지만 직접 이론도 찾아가며 배포하는 경험이 유익했습니다.

배포는 AWS의 EC2를 사용해서 진행했습니다.

CI/CD는 Jenkins를 사용해서 자동 빌드 및 배포하도록 했습니다.

여러 취업 조건에 CI/CD를 사용한 배포 경험이라는 것을 많이 봤습니다.

정확하게 무엇인지 몰랐지만 이번 프로젝트를 통해서 경험을 할 수 있었습니다.

그리고 TIL 챌린지를 참여하면서 수업을 참여했습니다.

이 챌린지 일주일에 한 번만 자신의 블로그에 배운 내용 등을 작성해서 올리는 것입니다.

한 달에 총 4번을 작성하게 되면 네이버 페이를 줍니다.

이게 정말 좋습니다! 내 포트폴리오를 쌓을 주으면서, 6번의 네이버 페이를 받을 수 있습니다. 이게 제법 쏠쏠합니다.

만약에 이 과정을 하신다면 이건 꼭 하세요!

마무리....

6개월 동안 힘들지 않았다고 하면 거짓말이겠죠?

힘들긴 했지만 그만큼 얻어 가는 것도 많았다고 생각합니다.

학교에서는 취업을 위한 수업이 아니라 학문을 위한 수업을 위주로 하기 때문에 실무에서 사용한 기술이나 프로젝트 진행 방식을 경험하기에는 한계가 있습니다.

그래서 이 과정을 수강했습니다.

만약 개발자나 IT 업계로 취업을 하시고 싶고, 개발에 대한 지식이 하나도 없다면 이 과정을 추천드립니다!

멀티캠퍼스 [현대 이지웰] 외부 파일에 이미지 저장 및 불러오기

taecostudy76 — Mon, 15 Dec 2025 16:42:35 +0900

프로젝트를 하면서 사용자로부터 받은 이미지를 내 컴퓨터에 로컬에 저장을 했습니다.

리뷰를 작성하면서 이미지를 업로드하면 로컬 폴더에 저장이 되었습니다.

이제 배포를 하면서 외부 파일을 사용해야 했고, FileZilla를 통해서 aws에 열었던 IP를 사용해 연결을 했습니다.

그리고 project 파일에 configure.properties를 넣었습니다. 이 파일은 application.properties에 있던 중요 정보를 옮겨 넣었습니다.

그리고 projectImage 폴더를 넣었고 그 안에 리뷰 사진들과 상품 사진들 등 사진들이 저장되는 것을 확인했습니다.

이제 이거를 코드를 사용해서 CRUD를 구현했습니다.

먼저 interface를 만들어 틀을 제공합니다.

그리고 서비스 로직을 구현 합니다.

@Value 어노테이션은 properties에 있는 이미지 파일 저장 경로를 자동으로 불러와 upLoadDir에 넣어 줍니다.

upload 메서드는 MultipartFile 객체로 여러 개의 파일을 받아 옵니다.

MultipartFile은 스프링에서 HTTP 요청으로 업로드된 파일을 표현하는 인터페이스입니다.

클라이언트가 전송한 파일의 이름, 크기, 콘텐츠 타입 등을 쉽게 다룰 수 있게 해 줍니다.

받아 온 데이터를 if 문을 통해서 확인하고 이름을 만들어 줍니다. UUID를 사용해서 랜덤 문자열을 만들고 기존 파일의 이미지 명과 uuid를 합쳐서 고유한 이미지 파일 이름을 만듭니다.

이미지 경로를 Paths.get 메서드를 사용해서 가져오고 그 자리에 파일을 넣습니다.

delete 메서드는 파일 이름을 가져옵니다.

파일 이름이 /images/abc.jpg 이런 식이라면 뒤에 실제 파일 이름만을 남겨 놓습니다.

그리고 Path 객체를 사용해서 실제 파일 경로를 찾고 삭제를 해줍니다.

리뷰 서비스 클래스에서

파일을 받아 올 때 List 객체를 MultipartFile 타입으로 받아 옵니다.

그리고 이미지 파일 여부를 따진 후에 imageUrl과 review를 entity 타입으로 바꿔 이미지를 저장합니다.

리뷰를 수정할 때도 같은 로직을 사용해서 이미지를 수정 삭제 삽입을 합니다.

이미지를 삭제할 때는 DB에서 이미지 이름을 그대로 가져옵니다. 그리고 url로 외부 파일에 있는 이미지를 삭제합니다.

컨트롤러에서 이미지 파일을 가져올 때는 위 사진처럼 @RequestPart 어노테이션을 사용했습니다.

HTTP 요청의 multipart/form-data 중에서 이름이 "files"인 파트를 이 파라미터에 매핑한다는 뜻입니다.

required = false는 이 값이 아무 값도 안 들어와도 에러를 내지 않는다는 뜻입니다.

null이나 빈 리스트로 값이 들어오는 것을 허용합니다.

멀티캠퍼스 [현대 이지웰] AWS 활용한 배포 War, tomcat(버전 맞추기 필수!)

taecostudy76 — Mon, 8 Dec 2025 18:18:28 +0900

AWS에 지금까지 했던 프로젝트를 배포하려고 합니다.

AWS에 포트를 활성화 했고, jenkins를 사용해서 빌드를 하려고 했습니다.

근데 빌드는 성공했고, tomcat도 잘 올라와 있는데 404 에러가 떴습니다.

프로젝트 build.gradle 보니 war이 아니라 jar이었습니다.

JAR 파일

- 독립적인 Java 애플리케이션을 패키징할 수 있고, 실행 가능한 JAR 파일로 만들어서 개발자가 쉽게 어플리케이션을 실행할 수 있습니다.

- Java 애플리케이션의 진입점인 main 메서드를 포함하고 있어 JVM에서 직접 실행하여 별도의 서버가 필요하지 않습니다.

WAR 파일

- Java 웹 애플리케이션을 패키징하는 데 최적화 되어 있고, 웹 구성 요소인 JSP, 서블릿, 리스너 등과 웹 어플리케이션을 실행하기 위한
서블릿 컨테이너에서 필요한 설정 파일, 라이브러리 등을 포함하여 한번에 배포를 할 수 있습니다.

원래 프로젝트의 application.properties에 가보면 jar로 되어 있습니다. 이제 배포를 하기 위해서 외부 톰캣을 사용할 것이기 때문에
war로 바꾸는 작업을 했습니다.

war는 활성화하고 jar는 비활성화를 했습니다.

그리고 외부 WAS에 WAR 파일을 배포할 때 Spring Boot 애플리케이션을 초기화하고 SpringApplicationBuilder를 사용해 ShoppingmallApplication 클래스를 메인 소스로 지정하여 이를 통해 웹 컨테이너가 Spring 콘텍스트를 자동으로 로드하고 실행하는 configure 메서드를 오버라이드 했습니다.

이렇게 한 후에 빌드를 해보면 war 파일이 생성된 것을 확인할 수 있습니다. jenkins에 올리기 전에 외부 톰캣을 활용해서 실행을 시켜

테스트를 진행을 했는데 또 404가 떴습니다.

war를 선택을 해서 서버를 실행시켜야 됩니다.

그리고 컴퓨터에 설치한 외부 톰캣 webapps에 자신의 프로젝트에서 생성된 war 파일을 붙여 넣으면 톰캣이 실행되면서 자동으로 파일 압축을 풉니다.

그리고 실행시켰는데 또 404가 뜹니다.

필요한 것들은 다 했고 WAR도 서버에 잘 올라가는데 404 에러 계속 떴습니다.

구글링을 계속한 결과 스프링부트 버전이 높아서 tomcat도 버전을 맞춰서 올려야 한다는 블로그를 확인했습니다.

참고

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-tomcat/3.5.7

저희 프로젝트 spring boot 버전이 높아서 10 버전을 사용해야 했고 저는 9 버전의 외부 톰캣을 사용하고 있었습니다.

그래서 404 에러가 떴고 10 버전을 다운 받아서 실행해 보니 잘 동작을 했습니다.

jenkins에 빌드를 전에 했을 때 외부 톰캣 10 버전으로 했는데 404가 떴습니다.

궁금한 거: 외부 톰캣 버전을 10.1.xx 버전으로 해서 했더니 잘 동작했다. 근데 우리 jenkins에서도 톰캣버전이 10 버전인데 왜 이전에는 안되었을까?

jenkins 실행 성공이 되어야지 80 포트도 실행되는 게 아닌가?

-> war 생성 후 git에 올려서 jenkin에 올려 실행시켜야 하는데 전에는 war를 생성하지 않은 버전을 git에 올렸다

그렇기 때문에 톰캣 버전이 10 이어도 404가 떴었다.

gradle 썼기 때문에 꼭 구성에서 gradle 버전을 설치해줘야 합니다.

Jenkins를 사용하여 CI/CD 사용법을 익힐 수 있었습니다.

CI는 직속적 통합으로 코드 변경 시 자동 빌드와 테스트 진행으로 충돌 조기 발견을 하고 Git 같은 저장소에 주기적 병합으로 팀 협업을 강화할 수 있습니다.

CD는 지속적 제공 및 배포로

Continuous Delivery: 테스트 완료 후 수동 배포 승인과
Continuous Deployment: 모든 테스트 통과 시 자동 프로덕션 배포를 담당합니다.

이렇게 빌드시 충돌을 확인할 수 있어 매우 간편합니다. 만약 충돌 로그를 확인하고 싶다면 오른쪽 사진처럼 Console Output를 눌러

확인하면 됩니다.

멀티캠퍼스 [현대 이지웰] Spring Boot 활용하여 기본 CRUD 기능 구현

taecostudy76 — Mon, 1 Dec 2025 11:15:00 +0900

Spring Boot를 활용해서 리뷰의 기본 CRUD 기능을 구현했습니다.

어떻게 구성하는지 간단하게 기록해 보도록 하겠습니다.

기본 아키텍처는 Controller 와 Service, Repository, Entity, DTO로 구성되어 있습니다.

Repository는 JPA를 활용하여 DB와 직접 소통하는 클래스입니다.

Entity를 사용해서 직접 소통하며, JPA는 기본 CRUD를 제공하기 때문에 직접 SQL 쿼리문을 작성할 필요가 없습니다.

만약에 성능 또는 커스텀이 필요하다면 @Query 어노테이션을 사용하여 JPQL 문을 사용하면 됩니다.

JpaRepository를 상속받아 사용하고, 타입은 <Entity, pk타입>을 입력해 줍니다.

직접 메서드 작성을 안 해도 되지만 주석을 사용하여 어떤 메서드를 사용했는지 남겼습니다.

이렇게 @Query 어노테이션을 사용하여 직접 원하는 데이터 값을 가져올 수 있습니다.

Repository를 모두 구현했다면 이제 Service를 클래스를 사용하여 원하는 기능을 구현합니다.

리뷰 등록 기능을 구현했습니다.

Service에서 기능을 구현할 때 예외 상황을 먼저 생각을 하고 예외 상황이 발생했을 때 어떻게 해야 할 건지를 코드 작성 했습니다.

클라이언트에서 ReviewDTO 데이터 값과 이미지 파일, 리뷰를 작성한 사용자의 memberNo를 받아 옵니다.

그리고 예외 상황을 미리 예상해 보면, 1. 구매 내역이 없는 사용자 2. 주문한 사용자와 로그인한 사용자 일치 확인 등등 을 생각했습니다.

클라이언트에서 받아온 ReviewDTO를 DBMS와 소통해야 하기 때문에 Entity로 변경합니다.

그리고 이미지와 태그를 따로 테이블에 저장을 한 후 reviewNo를 다시 반환해줍니다.

리뷰 조회는 수정 페이지에서 정보를 불러오는 것과 상품 페이지에서 리뷰 목록을 불러오는 것 이렇게 2 기능을 구현했습니다.

클라이언트에서 reviewNo를 받으면 예외가 생길 경우 "리뷰 조회 에러"를 띄웁니다.

ReviewDTO 클래스 안에 있는 toDto() 메서드를 활용해서 DB에서 가져온 데이터를 (Entity타입) DTO로 변환하고 클라이언트에 보냅니다.

리뷰 목록도 같은 맥락입니다. 리뷰 목록에서는 stream를 사용해서 작업을 진행했습니다.

리뷰 삭제는 간단합니다. 해당 reviewNo를 클라이언트에서 받아온 뒤에 .deleteById(reviewNo) 메서드를 사용해서 삭제하면 됩니다.

삭제 메서드도 마찬가지로 예외 상황을 고려하여 대비해주고, 리뷰 정보에 같이 있는 태그와 이미지도 같이 삭제해줍니다.

리뷰 업데이트는 등록과 비슷합니다.

예외 상황 대비하여 코드를 작성하여 클라이언트에서 받은 데이터를 .update()메소드를 통해 DB에 넣어줍니다.

Service 클래스에 원하는 기능을 다 만들었다면 이제 클라이언트와 소통하는 Controller를 구성해야 합니다.

클라이언트와 서버는 API를 통해 소통을 합니다.

위 사진에 PostMapping("/reviews") 이렇게 작성했는데 "/reviews"는 진짜 URL이 아니라 클라이언트와 소통하는 경로입니다.

@RequestPart 어노테이션은 여러 파일을 받기 위한 매핑 어노테이션입니다.

value = "files" name이 files인 List 형태의 파일들을 받고, required = false 이므로 파일이 없어도 에러가 생기지 않고 서버에 빈 상태 그대로 저장합니다. 그리고 Spring JWT로 로그인이 구현되어 있어 token을 받아 사용하기 때문에 위 사진처럼 예외 상황을 대비하여 코드를 작성했습니다.

멀티캠퍼스 [현대 이지웰] 인터페이스 기반 프로젝션이란?

taecostudy76 — Mon, 24 Nov 2025 20:03:34 +0900

인터 페이스 기반 프로젝선(Interface-Based Projecttion)

Spring Data JPA에서 엔티티의 전체가 아닌 일부 필드만 선택적으로 조회할 수 있게 해주는 기능입니다.

리뷰를 작성하는 사용자와 다른 사용자가 비슷한 피부 타입을 가지고 있을 때 리뷰를 분석하여 어떤 태그를 사용했는지를 통해
다른 사용자가 상품구매를 하기 전 판단을 할 수 있게 하는 기능을 만들고자 했습니다.

Tag에 모든 엔티티를 조회하지 않고 필요한 필드만 조회할 수 있는 인터페이스 기반 프로젝션을 사용하고자 했습니다.

인터피에스 기반 프로젝션이란?

기본 개념

- 일반적으로 JPA Repository 쿼리는 엔티티 전체를 조회합니다.

- 하지만 인터페이스 기반 프로젝션을 사용하게 되면, 원하는 필드만 SELECT 하도록 JPA가 쿼리를 최적하 하여 필요 없는

데이터를 제외하고 경량 DTO 역할을 하게 만듭니다.

이 Interface는 Repository 안에서 선언 한 것이며 따로 만든 Tag 관련 Entity나 DTO 하고는 전혀 상관없는 코드입니다.

프로젝션 인터페이스는 JPA가 쿼리 결과를 매핑해주는 임시 DTO 역할(조회 전용, 일시적 데이터 받기)만 합니다.

@Query 인터페이스를 사용하여 JPA가 기본으로 제공하는 쿼리문이 아닌 직접 쿼리문을 작성할 수 있는 어노테이션입니다.

특정 상품과 특정 피부타입인 리뷰들의 태그별 개수를 구하는 쿼리문을 작성항 것입니다.

쿼리문을 작성할 때 주의해야 하는 점은 인터페이스 프로젝션을 미리 만들어 놨기 때문에 필드 이름과 SELECT 별칭은 일치해야 합니다.

JPA가 SQL 실행을 하고 결과를 인터페이스에 맞춰 프록시 객체로 생성하여 반환하게 됩니다.

프락시 객체란?

- 실제 엔티티의 "가짜 대리 객체"로 실제 데이터를 즉시 메모리에 올리지 않고, 필요할 때 데이터베이스에서 객체를 조회하는 방식입니다.

위 코드에서 보면 TagStatSimple 타입으로 프록시가 생성이 됩니다.

TagStatSimple은 직접 구현한 실체 클래스가 아니라 동적으로 getter만 존재하는 임시 익명 프록시 객체를 만들어 각 row의 값을 할당합니다.

개발자는 .getTagName, getCount(), getTagStatus를 부르면 프록시 객체가 내부에 저장된 값을 그대로 돌려줍니다.

특정 사용자가 쓴 총 리뷰 수를 구해서 백분율을 계산을 할 때 분모를 사용하고자 했습니다.

리뷰 개수를 조회하는데 있어서 혹시 모를 중복 방지를 위해 DISTINCT를 걸었습니다.

JOIN을 통해서 원하는 테이블까지 경로를 만들고 oi.product.prdNo = :prdNo 를 통해서 리뷰가 달린 주문 항목의 상품 번호가

현재 상품 번호와 같은 경우 와 s.skinType = :skinType 회원이 설정한 skinType이 조건과 동일한 경우를

Where 절로 하여 분모를 정했습니다.

현재 로그인한 사용자의 피부 타입을 가져오기 위해서 userSkin에 로그인한 사용자를 넣어주고, 그 사용자의 피부타입을 가져옵니다.

Repository에서 만든 총 리뷰 수를 구하는 메서드를 불러 값을 넣어주고, 만약 리뷰수가 없다면 빈 값을 넣어 주는 작업을 진행했습니다.

분자 계산에서는 상위 3개의 태그를 가져올 예정이기 때문에 Pageable를 사용했습니다.

Pageable이란 페이징을 위한 설정 정보를 담는 인터페이스 입니다.

PageRequest.of() 메서드를 사용해서 첫 번째부터 3개 데이터 만들 가져오도록 Pageable를 구현합니다.

여기서 Proejction을 매핑하여 TagStat DTO로 변환하는 작업을 합니다.

percantage에 각 태그마다의 빈도수를 백분율로 변환하고 dto 객체를 생성합니다.

이런 식으로 데이터를 사용해서 원하는 기능을 완성할 수 있었습니다.

멀티캠퍼스 [현대 이지웰] Spring 어노테이션 기록하기

taecostudy76 — Tue, 18 Nov 2025 21:44:17 +0900

Spring을 프레임워크를 이용한 백엔드 개발을 진행하고 있습니다.

오늘은 제가 진행한 내용을 기록하고자 합니다.

먼저 dto와 Entity를 먼저 설계하고 Reposiroty와 Service를 구현하고 Controller를 사용해서 클라이언트와 API 통신을 할 겁니다.

먼저 ReviewDto를 살펴 보면

어노테이션들이 여러 개를 설정했습니다.

@Getter와 @Setter는 각 필드의 get 메서드와 set 메서드를 Spring이 자동으로 만들어 주는 기능을 합니다.

그래서 따로 제가 코드를 작성할 필요가 없어 간편하고 길게 코드를 쓰지 않아도 됩니다.

@NoArgsConstructor는 매개변수 없는 기본 생성자를 자동으로 생성해 주는 어노테이션입니다.

@AllArgsConstructors는 클래스 내 모든 필드를 매개변수로 받는 생성자를 자동으로 생성하는 어노테이션입니다.

@Builder는 빌더 패턴을 쉽게 구현할 수 있도록 도와주는 어노테이션입니다.

필드를 체인 방식으로 설정하며 객체를 생성할 수 있는 빌더클래스를 자동 생성합니다. 가독성과 유지보수성을 향상하는데 유용합니다.

저는 Dto 클래스 안에 Entity를 Dto로 변환하는 메서드를 만들었습니다.

장점 태그와 단점 태그 두 개가 따로 필요해서 나눴고, Review테이블과 Tag테이블을 연결해 주는

테이블인 ReviewTagMaps 테이블 Entity에서 pk를 찾고 있으면 빌더 패턴을 사용해서 각 태그 변수에 넣어 줍니다.

여기서 Stream를 사용했습니다.

Java의 Stream API는 선언형 프로그래밍 방식으로 기존의 반복문 대신 필터링, 매핑, 정렬 등을 연속된 연산 체인으로

간결하게 표현할 수 있습니다.

1. map()

- Stream 내의 각 요소를 내가 원하는 형태로 변환하는 중간 연산입니다.

- ex) .map(ReviewTagMap::getTag) // ReviewTagMap 객체에서 getTag()로 Tag 객체만 추출

2. filter()

- 원하는 조건(Boolean)에 따라 Stream의 요소를 선별해서 남기는 역할을 합니다.

- ex) .filter(tag -> tag.getTagStatus().equals("장점")) // 추출한 Tag 객체에서 getTagStatus()가 "장점"인 것만 남기고 나머지는 버립니다.

3. collect()

- 가공한 Stream의 요소들을 다시 List, Set등의 컬렉션으로 수집하는 최종연산입니다.

- ex) .collect(Collectors.toList()) // Stream에 남아있는 요소들을 모두 List로 변환해서 저장합니다.

그리고 이미지 관련 dto 또한 Stream를 사용해서 toDTO 메서드를 꺼내오고 List로 만들어 줍니다.

마지막으로 빌더 패턴을 사용해서 Entity를 dto로 변환해줍니다.

@Entity는 JPA 엔티티 클래스임을 명시합니다. 데이터베이스 테이블과 1대 1로 매핑이 됩니다.

@Table(name = "review") 클래스가 매핑될 DB 테이블 이름을 지정하고 없으면 클래스명이 테이블명으로 사용됩니다.

@EntityListeners(AuditingEntityListener.class)는 Auditing 기능(생성일, 수정일) 자동 입력을 활성화합니다.

@Id 테이블의 기본키와 매핑될 필드입니다. 반드시 있어야 합니다.

@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "review_seq_gen")

이 어노테이션은 PK 값을 자동 생성 전략을 지정합니다. 시퀀스를 사용하여 PK 값을 생성합니다.

@SequenceGenerator는 시퀀스 객체의 이름과 실제 DB 시퀀스를 필요로 하고 설정을 합니다.

@Column 매핑되는 DB 컬럼 설정. 이름 길이 등 여러 속성을 상세히 지정할 수 있습니다.

@Lob Large Object 타입에 사용하며 긴 텍스트나 대용량 데이터를 다룰 때 사용합니다.

@ManyToone(fetch = FetchType.LAZY) 다대일 관계 매핑으로 여기서는 Review가 OrderOtem 하나만 참조한다는 의미입니다.
LAZY는 실제 값이 필요할 때만 DB에서 데이터를 불러온다는 의미입니다.

@JoinColumn(name = "orderItemNo") FK 외래키 컬럼의 이름 지정을 합니다. 이 컬럼이 연결되는 관계의 데이터베이스 컬럼이 됩니다.

@OneToMany(mappedBy = "review", cascade = CascadeType.REMOVE) 일대다 관계 매핑으로 Review가 여러 ReviewTagMap과 ReviewImage를 가질 수 있고, cascade는 Review가 삭제될 때 관련 객체도 함께 삭제한다는 의미입니다.

@CreatedDate, @LastModifiedDate는 JPA Auditing에서 사용하며 각각 생성일, 수정일 자동 저장에 쓰입니다.

그리고 repository를 만들었습니다.

JpaRepository를 상속받아 사용하여 JPA를 사용합니다.

상속을 받으면 기본 CRUD 메서드를 가져다가 쓸 수 있고, 직접 선언을 안해도 됩니다.

저는 나중에 보면 확인하고 싶어서 주석 처리로 써놨습니다.

그리고 기본 제공 이외에 다른 메소드를 사용하고 싶으면 위 사진처럼 작성해서 사용을 하면 JPA가 자동으로 쿼리문을 작성합니다.

물론 직접 쿼리문을 작성해서 하는 방법도 있습니다.