J Lab

AI 쓰면서 하는 책임 분리 고민

j1adev — Sat, 7 Feb 2026 23:36:25 +0900

AI로 코드 쓰기

처음 개발을 할 때는 지피티로 코드를 써가면서 기능을 구현해가기 시작했다. 그때는 좋은 설계가 뭔지에 대해 감이 없었다.

하지만 프로젝트가 진행될수록, ‘코드를 잘 쓰는 것’과 ‘설계를 잘하는 것’은 전혀 다른 문제라는 걸 느끼게 되었다.

설계문서를 쓰고 구현을 시작하면서, 내가 만든 서비스이니 누구보다 도메인 이해가 잘 되어 있을 거라 생각했다.

엔티티를 재설계하다

초반에 엔티티 A, 엔티티 B를 다른 책임이라 보고 다른 엔티티로 분리했다.

그러다보니 외부 api를 호출하고 이를 객체로 매핑하는 과정에서 A, B는 생명주기가 같다는 점을 발견했고 이후 도메인을 재설계했다.

처음 분리는 역할 기준이었지만, 실제 변경 이유는 항상 함께 움직이고 있었다.

SRP를 다시 이해하게 되다

이때 SRP란 무작정 다른 것이라 생각하고 분리하는게 아니라

같이 변한다면 하나로 묶어야한다는 것이다. 즉 같이 변하고, 생명주기가 같다면 의존성이 높다.

또 다른 예시 – 상태와 행동이 함께 변하는 경우

class Category {

    private final List<Item> items = new ArrayList<>();

    public void addItem(Item item) {
        items.add(item);
    }

    /**
     * 카테고리의 상태(items)에 의해
     * 자연스럽게 계산되는 값이므로
     * 별도 서비스가 아닌 엔티티 책임으로 둔다.
     */
    public double averageScore() {
        int totalScore = items.stream()
                .mapToInt(Item::score)
                .sum();

        return items.isEmpty() ? 0 : (double) totalScore / items.size();
    }
}

record Item(int score) {}

변경 이유를 기준으로 보면,

averageScore 계산은 Category의 상태 변화에만 영향을 받았다.

이 경험 이후로, SRP는 ‘역할을 나누는 것’이 아니라 ‘같이 변하는 것을 묶는 것’이라는 말이 내게는 더 정확하게 느껴졌다.

이렇게 도메인의 이해 + OOP 사고를 해야 더 알맞은 설계, 알맞은 구현을 할 수 있다.

이는 시니어가 될 수록 더 중요한 사고라고 생각한다.

개발자는 코드만 잘 쓰는게 아니라 설계도 하고 고객에게 제품 설명도 하고, 기술 선정도 해야한다. 이러려면 결국 도메인의 이해 + 서비스 이해가 잘 이루어져야 하는 것 같다.

시니어가 될 수록 소통, 협업, 도메인 이해, OOP적 사고가 중요해져서 결국 기본기, 코드 외적인 부분이 중요해지는 것 같다.

소프트웨어 장인 책을 회고하며

소프트웨어 장인 이라는 책을 읽을 당시에는 장인 정신의 핵심이 열정이라고 강조되었는데, 이제 열정의 의미가 다르게 보인다.

결국 내가 이해하게 된 장인 정신은 열정 그 자체라기보다, 설계와 판단에 책임을 지려는 태도였다. 그리고 설계와 판단을 잘하기 위해서는 도메인에 대한 이해와 본인이 어떤 기능을 만드는지에 대한 이해가 중요한 것 같다.

AI를 쓰는 지금일수록, 무엇을 자동화하고 무엇을 직접 판단해야 하는지에 대한 기준이 개발자의 역량이 된다고 느낀다.

Spring DataSource, config server 에러 : Access denied for user

j1adev — Sat, 25 Oct 2025 14:21:09 +0900

1️⃣ “로컬 실행이 안된다”

입사 한 달 차, 로컬에서 테스트하려는데 앱이 뜨질 않았다.
Access denied for user ''@'123.456.789.10' (using password: NO)
username, password가 인식이 안되었다.
“비밀번호가 틀렸다”가 아니라,
“비밀번호를 보내지도 않았다”는 뜻이었다.

2️⃣ 문제 파악 : 로그를 찍자

application.yml에 username, password를 정확히 넣고,
Config Server도 꺼봤지만 여전히 안 됐다.
그래서 결국 Bean에 로그를 박았다.
@PostConstruct
public void debugDatasource() {
    HikariDataSource ds = (HikariDataSource) dataSource();
    System.out.println("==== MariaDB DataSource ====");
    System.out.println("URL: " + ds.getJdbcUrl());
    System.out.println("USER: " + ds.getUsername());
    System.out.println("================================");
}
여전히 콘솔엔 username이 공백이었다.
심지어 jdbc-url을 바꿔도 계속 log4jdbc가 붙어서 찍혔다.
URL: jdbc:log4jdbc:mysql://123.456.789.10
USER:

3️⃣ 원인 분석 — “두 개의 함정”

이 문제에는 함정이 두 개 숨어 있었다.
하나는 코드 내부의 자동 설정 충돌,
다른 하나는 환경 설정의 공유 부재였다.

1. Spring Boot의 바인딩 충돌 (@ConfigurationProperties + DataSourceBuilder), 즉 local yml vs config server

처음엔 log4jdbc 문제인 줄 알았다.
하지만 원인은 Spring Boot의 자동 바인딩 순서였다.

나는 아래처럼 @ConfigurationProperties를 붙여 yml의 DB 설정을 읽게 했다.
@ConfigurationProperties(prefix = "spring.maria-db.datasource") 
public DataSource dataSource() {
	return DataSourceBuilder.create().type(HikariDataSource.class).build(); 
}
그런데 DataSourceBuilder.create()도 원격의config server의 같은 prefix(spring.maria-db.datasource)를 기반으로
username/password를 읽는다.

즉, 같은 prefix의 값이 중복 바인딩이 발생했다.

그 결과, DataSourceBuilder가 세팅한 username/password가
나중에 @ConfigurationProperties에 의해 null로 덮였다.

@ConfigurationProperties를 제거하고 강제로 DataSourceBuilder 빈에 usernmae, password설정해서 연결이 바로 성공했다.

2. DB 주소 변경 (팀 내 소통 부재)

두 번째 함정은 환경이었다.
누군가가 jdbc-url을 새롭게 바꿔 master에 머지했는데
이건 내가 권한이 없는 DB였다.
팀원 중 아무도 그 변경을 공유하지 않았고, 나는 권한도 없는 DB에 접속 시도만 하고 있었다.

코드가 맞아도, 소통이 되지 않으면 그게 버그다.

4️⃣ 해결 : @ConfigurationProperties 제거, 강제 설정

애노테이션 제거, DataSource 빈도 수동 설정

예시:

@Bean
@Primary
public DataSource dataSource() {
    return DataSourceBuilder.create()
        .driverClassName("...")
        .url("jdbc:mysql:...")
        .username("...")
        .password("...")
        .build();
}

5️⃣ 회고 — 소통도 디버깅이다

사실 위의 문제는 대부분의 서비스회사는 마주치지 않을 가능성이 높다.
@ConfigurationProperties 기반 수동 Bean 등록 + Config Server 방식은 sm 회사가 쓰는 오래된 기술이기 때문이다.

버전이 낮은 프레임워크, 구식 기술은 ‘문제 해결의 난이도’를 올린다. 그리고 그것보다 더 큰 문제는 소통 없는 환경이다.

Config나 DB 설정처럼 작은 변경일수록 문서화와 커뮤니케이션이 필수인데,
SM 회사는 “각자 맡은 일만 하는 문화”가 강해서 소통이 잘안된다.

Spring WebClient block() vs subscribe(): 계층별 사용법 정리

j1adev — Wed, 18 Jun 2025 16:01:39 +0900

Spring WebFlux나 WebClient를 처음 사용할 때 가장 많이 고민하게 되는 포인트 중 하나는 바로 block()과 subscribe() 중 무엇을 써야 하는가이다. 특히 테스트 코드, 서비스 코드, 컨트롤러, API 응답부 등 **계층마다 요구되는 특성이 다르다.

이번 포스트에서는 WebClient를 사용하는 각 계층에서의 전략적 선택 기준을 정리해본다.

기본 개념: block() vs subscribe()

메서드 설명 특징

block()	Mono/Flux의 결과를 동기적으로 대기하여 반환	블로킹 (스레드 점유), 흐름 제어 쉬움
subscribe()	Mono/Flux를 비동기적으로 실행하고 콜백으로 결과를 처리	논블로킹, 백그라운드 실행, 흐름 관리 어려움

계층별 전략 정리

계층 사용 추천 이유

✅ 단위 테스트	block()	테스트는 완료 여부가 중요함. subscribe()는 타이밍 이슈 발생 가능
✅ 통합 테스트	block()	외부 연동 흐름이 확실히 끝났는지 확인해야 함
✅ 서비스 계층	상황에 따라 선택(핵심 로직이면 block() 허용)	요약 처리, 외부 응답 필수 로직 등은 block()으로 동기화 필요할 수 있음
❌ 컨트롤러 (@RestController)	subscribe() (또는 Mono 반환)	클라이언트 요청을 처리하는 HTTP 스레드를 절대 블로킹하면 안 됨. 요청 처리 스레드 낭비로 서버 부하 유발
❌ API 응답부 (HandlerFunction 등)	subscribe()	요청 처리 스레드 낭비로 서버 부하 유발

왜 컨트롤러와 응답부에서는 block()을 쓰면 안 될까?

핵심 이유: 애플리케이션이 병목에 걸리고 결국 다운될 수 있기 때문

Spring WebFlux는 다음 철학을 바탕으로 만들어졌다:

“하나의 스레드로도 수천 개의 요청을 처리할 수 있도록 하자”

→ 이를 위해 모든 I/O, HTTP, DB 호출 등을 **논블로킹(reactive)**으로 설계

❗ block()을 쓰는 순간 무슨 일이 벌어지냐면?

해당 요청을 처리하던 스레드가 결과를 기다리며 멈춤
다른 요청이 들어와도 스레드는 아직 이전 요청 때문에 사용 중
병렬 요청이 많아지면?→ 새 요청은 처리되지 않음
→ 서버가 멈춘 것처럼 느려짐 → 다운
→ 사용 가능한 스레드가 모두 블로킹됨

이걸 "스레드 고갈(thread exhaustion)" 또는 "리액터 데드락"이라 부른다.

subscribe()는 언제 쓰나?

내부적으로 로그 전송, 알림 메시지, 모니터링 이벤트 전송 등
결과를 굳이 기다리지 않아도 되는 비핵심 로직
예: 슬랙 알림

slackWebClient.post()
    .uri("/chat.postMessage")
    .body(...)
    .retrieve()
    .bodyToMono(String.class)
    .subscribe(); // 결과는 중요하지 않음

보너스: block()은 “컨텍스트 안에서만” 써라

@Scheduled, Batch, Retry Processor, Message Listener → block() 허용 가능
HTTP 요청/응답 컨텍스트 (Controller) → 절대 block() 금지

마무리

WebClient는 강력한 도구지만, 사용 위치에 따라 전략적으로 다뤄야 한다.

비동기를 고집하다 테스트가 깨지고, 동기를 남발하다 서버가 느려지는 일은 흔하다.

따라서 계층별로 다음을 기억하자:

테스트는 block(), 실서비스는 subscribe(), 컨트롤러는 절대 block() 금지!

Spring 테스트가 끝나지 않던 이유: subscribe(), @Value, MockWebServer

j1adev — Wed, 18 Jun 2025 14:57:31 +0900

배경

최근 프로젝트에서 Slack 알림 기능을 WebClient로 구현하고, 그에 대한 단위 테스트를 작성했다.

Slack API를 직접 호출하지 않기 위해 MockWebServer를 활용했고,

비즈니스 로직에서는 Spring의 @Value를 이용해 외부 설정값을 주입했다.

@Value("${slack.enabled:true}")
private boolean slackEnabled;

그러나 테스트를 실행하자 문제가 발생했다.

✅ 테스트는 통과하지 못하고 무한히 실행 중인 상태로 멈춰 있었다.

✅ GitHub Actions에서는 6시간 제한 초과로 build가 자동 취소되었다.

✅ 로그에는 특별한 에러도 없고, WebClient 요청도 정상처럼 보였다.

도대체 왜 테스트가 끝나지 않았던 걸까?

원인

SlackNotificationService는 비동기 방식(subscribe())으로 WebClient 호출
MockWebServer.takeRequest()가 응답을 받지 못하고 무한 대기 상태 에 빠질 수 있다. → 테스트가 끝나지 않음
게다가 @Value가 제대로 주입되지 않음 → 조건문 우회도 실패

조건문 우회 로직 :

if (!slackEnabled) {
    return;
}

즉 다시 정리하자면,

테스트에서 WebClient.subscribe() 비동기 방식으로 슬랙에 메시지를 전송
요청은 백그라운드 쓰레드에서 실행됨.
```
var recordedRequest = mockWebServer.takeRequest();
```
→ 이 줄에서 요청이 올 때까지 기다림
하지만 테스트 코드에서는:
그런데 비동기 요청이 끝나기 전에, 테스트 메인 쓰레드는 이미 takeRequest()에 도달해서 요청을 기다리는 중
비동기 요청이 끝나지 않거나 실패하면→ 테스트는 절대 종료되지 않음
→ takeRequest()는 요청을 받지 못해서 계속 대기
GitHub Actions는 워크플로 실행 시간이 6시간을 초과하면 자동으로 테스트를 취소(cancelled)
```
The job has exceeded the maximum execution time of 6h0m0s
```
→ 그래서 다음 메시지가 떴던 것:

실패한 시도들

❌ application.yml 설정 수정

test/resources/application.yml에 slack.enabled: true를 명시
@ActiveProfiles("test") 도입
→ 문제 해결되지 않음

❌ @SpringBootTest 도입

Spring이 @Value 주입을 포함한 전체 빈 구성 및 컨텍스트를 로딩해줌
하지만 Spring이 생성한 WebClient는 여전히 application.yml의 Slack base URL을 사용
별도로 WebClient 설정을 override하지 않았기 때문에,
테스트에서 사용 중인 MockWebServer와는 연결되지 않았고, 요청은 Slack으로 날아감

❌ System.setProperty() 시도

WebClient의 baseUrl을 시스템 프로퍼티로 override하려 했다.
그러나 WebClient Bean 생성시 이걸 반영하지 않았어서(즉 override할게 없었다) 또 이걸 소스코드에 수정하려니 코드가 복잡해진다고 느꼈다.

✅ 최종 해결: 직접 객체 생성 + setter 주입 + block()

WebClient와 서비스 객체를 테스트 코드에서 직접 생성
설정값은 setter로 수동 주입
subscribe() 대신 block()으로 테스트용 동기 메서드 분리

slackNotificationService = new SlackNotificationService(webClient);
slackNotificationService.setSlackEnabled(true); // ✅ 수동 주입

public void sendSummaryToUserSync(...) {
    ...
    slackWebClient.post()
        ...
        .block(); // ✅ 테스트용
}

비슷한 문제: SlackRequestVerifier

@Value를 쓰는 또 다른 클래스에서도 동일한 문제가 있었지만,

이 역시 setter 방식으로 테스트에서 직접 주입하여 해결했다.

slackRequestVerifier = new SlackRequestVerifier();
slackRequestVerifier.setSigningSecret("dummy_secret");
slackRequestVerifier.setVerifySignature(true);

언제 setter 방식이 좋은가?

크게 세 가지이다. 다른 해결방법이 좀 지저분하다 싶으면(webclient와의 연동이 지저분해진다던지...) setter를 쓰는 것이 괜찮은 듯하다.

@SpringBootTest가 너무 무거운 경우
@Value나 @Autowired를 사용하는 컴포넌트를 단위 테스트하고 싶을 때
Spring 컨텍스트 없이 빠르게 검증하고 싶을 때

테스트에서 block() vs subscribe()

상황 block() subscribe()

실패 요청이 왔을 때	테스트가 바로 실패함	테스트는 몰라서 통과한 것처럼 보이기도 함
요청이 너무 느릴 때	테스트가 timeout으로 실패	테스트는 이미 끝났는데 요청은 백그라운드에서 계속 처리 중일 수 있음
takeRequest() 대기 중	요청이 오면 바로 깨짐	요청이 안 오면 무한 대기 (성공 여부 보장 X)

즉 block()이라면 명확하게 실패, 성공을 알려줄 수 있다. 하지만 subscribe()는 무한 대기할 수 있는 문제가 생기는 것이다.

마무리

이번 경험은 나에게 Spring 테스트 환경에서 설정 주입이 어떻게 동작하는지,

그리고 WebClient 테스트 시 비동기 처리의 함정이 무엇인지를 깨닫게 했다. WebClient, @Value, Mock 서버 간의 연동 흐름이 정확히 일치하지 않으면 테스트는 hang되거나 실패한다는 점을 겪었다.

AWS Docker와 JMeter 연동 문제(빈 등록 안 됨) 디버깅

j1adev — Thu, 29 May 2025 13:41:04 +0900

1. 문제 상황

JMeter를 활용해 Spring Boot 프로젝트를 AWS EC2 위 Docker 환경에서 테스트하는 중, 예상치 못한 문제가 발생했다.

하나의 Test Group 안에는 현재 Thread Group1, Thread Group2가 있는데 하나는 성공, 하나는 실패하는 것이다.

JMeter 시나리오 구성:

Thread Group 1: Slack 메시지 수신 API 테스트( /slack/events ) → 성공, 200 OK
Thread Group 2: 스케줄러 수동 트리거 API 테스트( /test/run-daily-scheduler )→ 실패, 500 Internal Server Error

Docker 로그에는 해당 컨트롤러( TestSchedulerController 라는 이름이다) 관련 로그가 전혀 출력되지 않음
그러나 IDE(IntelliJ)에서는 문제없이 정상 동작

2. 특이사항 및 증상

/test/run-daily-scheduler 호출 시 500 에러
Docker 환경에서는 로그가 아예 출력되지 않음
@PostConstruct, System.out.println, static {} 블록을 넣어도 전혀 동작하지 않음
IDE에서 실행하면 @PostConstruct 로그가 잘 출력됨

이 시점에서 의심했다. 클래스 자체가 메모리에 올라가지 않았고, Spring의 빈으로 등록되지 않았다는 것이다. 단순히 메서드가 호출되지 않은 게 아니라, 애초에 컨트롤러 자체가 생성되지 않은 상태였다.

3. 원인 추정 및 진단

3.1 프로파일 미적용 가능성

Dockerfile에 다음처럼 ENTRYPOINT로 프로파일을 지정했으나:

ENTRYPOINT ["java", "-Dspring.profiles.active=docker,mock-openai", "-jar", "/app.jar"]

이렇게 하면 프로파일 설정이 실제로 적용되지 않는다. 즉 application-docker.yml이 무시된다. 그러면 이 속의 spring.data.redis.host: redis도 무시되어서 Redis의 도커 연결도 해지되니 더 문제가 심각해진다.

안정적으로 프로파일을 적용하려면 아래처럼 환경변수로 프로파일을 전달하자.

조치: ENTRYPOINT 설정을 제거하고, docker run 시 환경 변수로 프로파일 전달:

docker run -e SPRING_PROFILES_ACTIVE=docker,mock-openai ...

→ 이후 application-docker.yml 정상 반영 + Redis 연결도 복구됨

3.2 컨트롤러가 빈으로 등록되지 않음

Docker 로그에는 아무런 로그조차 찍히지 않았다.

static {} 안 찍힘	JVM이 아예 클래스를 로딩하지 않음
@PostConstruct 안 찍힘	빈 등록조차 안 됨

해당 컨트롤러는 com.jia.study_tracker.controller라는 별도 패키지에 위치했었다. 이는 다른 컨트롤러와는 다른 곳이었다.

즉, 컨트롤러가 스캔 대상에서 누락되어 빈으로 등록되지 않았던 것이다.

그래서 해당 컨트롤러는 다른 정상작동되는 컨트롤러와 같은 위치에 놓아두었고 그제서야 해결했다.

조치: 문제되는 그 해당 컨트롤러( TestSchedulerController )를 다른 컨트롤러가 있는 곳으로 패키지 이동 → 로그 정상 출력, API 정상 응답 확인

4. 해결 결과

/test/run-daily-scheduler API: 200 OK 응답
Redis 연결 정상화 → /actuator/health: UP
JMeter 부하 테스트 성공

5. 내가 배운 점

✅ 프로파일은 ENTRYPOINT보다 환경변수로 설정하자

-Dspring.profiles.active=... 방식은 Docker 내에서 예측 불가능한 문제가 발생할 수 있음
-e SPRING_PROFILES_ACTIVE=...는 Spring이 공식 지원하는 방식이며 신뢰도 높음

✅ 로그가 없다 = 아예 실행되지 않은 것일 수 있다

로그가 하나도 없다면, 애초에 빈 등록이 안 된 것일 가능성이 높다

처음에는 해당 컨트롤러가 `com.jia.study_tracker.controller` 패키지에 있었다.
이 위치는 `@SpringBootApplication` 기준으로 볼 때 스캔 대상이 맞았지만,
이상하게도 Docker 환경에서는 아무 로그도 출력되지 않았다.

그러나 같은 코드를 `com.jia.study_tracker.slack` 패키지( 정상작동되는 다른 컨트롤러가 있는 곳)로 옮기자마자
바로 `@PostConstruct`가 실행되고, API 응답도 200 OK가 나왔다.

이는 단순한 컴포넌트 스캔 문제라기보다는,
빌드 과정에서 특정 패키지의 클래스가 JAR에 포함되지 않았거나,
복사/로드 누락이 있었던 것으로 보인다.

[Spring Boot + Prometheus] /actuator/prometheus 안 뜰 때 해결

j1adev — Thu, 22 May 2025 00:17:45 +0900

프로젝트에서 애플리케이션 메트릭을 Prometheus로 수집하기 위해 Spring Boot에 Prometheus를 연동했습니다. 이 글에서는 제가 마주했던 문제와 그 원인, 그리고 어떻게 해결했는지를 기록합니다.

시작: Spring Boot Actuator만으로는 충분할까?

보통 Prometheus와 Spring Boot를 연동할 때는 다음 의존성을 추가합니다:

implementation 'org.springframework.boot:spring-boot-starter-actuator'

그리고 application.yml에 아래와 같이 설정하면 /actuator/metrics 등의 엔드포인트가 활성화됩니다:

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  metrics:
    export:
      prometheus:
        enabled: true

참고로 include: "*"로 모든 엔드포인트를 노출할 수도 있지만, 운영 환경을 고려해 필요한 항목만 명시적으로 포함했습니다. actuator는 편리하지만 보안 리스크가 있어, 전체 노출보다는 필요한 항목만 선택적으로 관리하는 것이 더 안전한 운영 방식이라 판단했습니다.

이후 Prometheus 서버가 http://localhost:8080/actuator/prometheus를 스크랩하도록 설정하면 된다고 생각했습니다.

그런데 문제는 여기서부터였습니다.

❌ 예상치 못한 장애

Spring Boot 애플리케이션은 정상적으로 기동되었고 /actuator 페이지도 잘 열렸습니다. 하지만…

http://localhost:8080/actuator/prometheus 요청 → 404 에러
콘솔 로그에 다음과 같은 메시지 출력:

No static resource actuator/prometheus.

처음에는 이 메시지를 보고 정적 리소스 설정 문제라고 오해했습니다. 즉 /static/actuator/prometheus 같은 파일이 없는 것처럼 보여서 의존성에 문제가 있다고 생각했습니다(추후 디버깅 삽질로 web, webflux 의존성 충돌 의심을 합니다). 단순히 정적 파일이 없다고 생각했고, actuator를 잘 몰랐으니 이 사태가 납니다.

하지만 actuator 경로는 일반적인 정적 리소스가 아닌, Spring이 노출하는 동적 엔드포인트입니다. 따라서 이 메시지는 /actuator/prometheus가 아예 등록되지 않았다는 뜻입니다.

원인 분석: Prometheus registry가 없었다

결론부터 말하자면, 아래 의존성을 추가하지 않았기 때문입니다:

implementation 'io.micrometer:micrometer-registry-prometheus'

Spring Boot는 내부적으로 Micrometer를 통해 다양한 메트릭을 수집하지만, Prometheus와의 연동은 별도의 모듈로 분리되어 있습니다. 이 모듈이 없으면 /actuator/prometheus 엔드포인트 자체가 생성되지 않습니다.

참고

Spring Boot 2.0 이후부터는 Micrometer가 기본 메트릭 수집 도구로 사용되며, Prometheus export 기능은 별도 registry로 제공됩니다.

디버깅 삽질기: Web vs WebFlux 의존성 문제?

처음엔 의심을 잘못된 곳에 했습니다. spring-boot-starter-web과 webflux 의존성을 동시에 쓰고 있었고, 그게 원인일 수 있다고 생각했죠.

implementation 'org.springframework.boot:spring-boot-starter-web'
// implementation 'org.springframework.boot:spring-boot-starter-webflux'

Web과 WebFlux는 각각 DispatcherServlet과 WebHandler 기반의 서로 다른 웹 엔진을 사용하기 때문에 충돌 가능성이 있습니다. 실제로 이 둘을 함께 쓰는 건 일반적으로 권장되지 않습니다. actuator 관련 빈의 해석 순서나 우선순위가 꼬일 수 있다는 것도 문서에서 확인했습니다.

하지만 이번 이슈는 의존성 충돌 문제가 아니라, registry가 빠졌기 때문이었습니다. webflux를 제거해도 문제가 해결되진 않았습니다.

최종 해결

아래와 같이 Prometheus registry 모듈을 추가하고 애플리케이션을 재기동하자 /actuator/prometheus가 정상적으로 열렸습니다.

implementation 'io.micrometer:micrometer-registry-prometheus'

Prometheus 서버에서도 상태가 UP으로 바뀌었고, 메트릭이 수집되기 시작했습니다.

배운 점

이번 경험을 통해 Spring Boot Actuator만으로는 Prometheus 연동이 되지 않는다는 걸 체감했습니다. 또한:

Micrometer는 유연한 메트릭 수집 시스템이지만, 타 시스템(Prometheus, Datadog 등) 연동은 별도 모듈이 필요하다
Web과 WebFlux는 동시에 사용하지 않는 것이 좋다

단순히 작동하는 코드 이상으로, 왜 이렇게 동작하는지 이해하는 것이 중요하다는 걸 다시 느꼈습니다.

에프랩(F-Lab) 자바 코스 2개월 후기

j1adev — Sun, 11 May 2025 10:37:17 +0900

뭐하는지?

1달 동안은 주로 이론을 공부했다. 그리고 2달째 부터 현재까지 지금은 프로젝트를 만들고있다.

초보자, 비전공자이고 처음 프로젝트 만드는건데 괜찮을까?

나는 깃헙을 써보지 않은, pr도 모르던 비전공자였다. 프로젝트는 아주 간단한거 정도 만든 상태였다. 생각보다 깃헙을 다루고, 프로젝트 하는 것이 크게 어렵지는 않았다! 에프랩에는 깃헙을 어떻게 다루는지에 대해서 알려줘서 이 부분에서 큰 도움을 받았다.

깃헙 가이드라인은 에프랩에 상세하게 잘 나와 있으니까, 꼭 확인하길 바란다!!!

많은 가이드가 있음!

이 영상으로 겨우 깃헙에 pr 성공했다

내가 한 실수들 - 자기주도적 생각의 중요성을 몰라서 생긴 실수들

ai에 너무 과하게 의지하기

지피티가 만들어주는 코드를 대부분은 이해하고 프로젝트에 넣으려하지만 급한 상황이나, 무의식 중에 완전한 이해없이 그냥 소스코드에 넣는 경우가 있다. 그래서 스스로 의문하고, 이게 정말로 필요한 것인지, 로직 수정을 할 수 있는지에 대해 생각해야한다.

멘토가 다해주고, 정답을 알려줄거란 과한 기대하지 말기

예를 들어 @DisplayName을 테스트 메소드에 다 써야하는지, BDD 스타일 모키토 문법이 최신이니까, 이걸로 전부 수정해야할지 등에 대해서 멘토님이 전부 예, 아니오로 깔끔히 답해주실 줄 알았다. 나는 비전공자이고, 학생이니까 라는 마인드가 강했다. 하지만 멘토님은 실제로는 “그걸 함으로써 장점은 뭐라고 생각하시나요?, tradeoff가 있으니 생각해보세요, 저라면 이렇게 했을것 같은데, 멘티님도 생각해보시죠” 이런식으로 멘티가 스스로 생각할 수 있게 도와준다.

멘토님은 물고리를 잡아서 주시는게 아니라, 물고기 잡는 법을 알려주시는 것 같달까. 물론 물고리를 주셔서 걱정안해도 된다.

이렇게 생각하고, 스스로 사고하는 습관을 가르치는게 에프랩의 철학같다.

멘토가 프로젝트 만드는 데에 얼마나 도움이 되었나?

꽤 큰 도움이 되었다. 지피티 보다 훨씬 나았다. ai를 이용해서 코딩을 하면 hallucination(오해의 소지가 있는 정보((인공 지능 알고리즘에 의해 그럴 법하게 사실처럼 생성된 정보)) 등이 섞여 있다. 그리고 나무가 아니라 숲을 보는 능력이 부족해서 전체 테크스펙, 아키텍처에 대한 도움을 줄 수없다.

멘토님이 특히 도와주신 점!

주제선정 - 내가 몇개 주제 후보를 가져오면, 멘토님이 이런 주제에는 어떤 기술이 필요할 거 같고~ 이렇게 즉석에서 말씀해주시는게 도움이되었다.

아키텍처 아이디어 - 외부 api에 대한 아이디어를 멘토님이 도와주셨다.

기술 - 어떤 기술을 쓸지도 도와주셨다.

코드 로직 - 역시 경력자의 눈은 속일 수 없다 짱짱

그래서 2달째 한 후기

: 내가 비전공자, 초조라서 걱정이 많았는데, 멘토님이 잘 도와주셨다. 그 방법이 막 정답을 떠먹여주시고, 암기주입식 교육이 아니라, 생각하게 만들고, 정답을 유됴하고, 힌트를 주시는 방법이라 에프랩이 끝나도 좋은 개발자가 될 것 같다는 느낌이 든다.

에프랩(F-lab) 자바 백엔드 코스 1개월 후기 : 비전공자 리뷰

j1adev — Fri, 28 Mar 2025 14:39:04 +0900

TLDR : 좋았다. 어렵지만 그만큼 배우는게 많다. 내가 포기하지 않아서 다행이다.

왜 F-Lab을 신청했는지 :

나는 비전공자이다. 전공이 정말 정말 지루했고 뭘 공부해야하는지 고민이었다. 그러다가 우연히 컴퓨터를 공부해봤고, html, css, 그리고 자바 공부가 꽤 잘맞는다고 생각했다. 그렇게 독학을 몇달 하던 중에, 온라인에 있는 사람들이 추천하는 커리큘럼을 따라가자니, 위험성도 있고, 내 자신도 믿을 수가 없었다. 그리고 그 커리큘럼을 다라갔다가, 내가 책을 이해하지 못하기도 했다. 특히 나는 영어에 자신있다고 생각해서 영어로도 공부해봤는데, 책이 어려웠어서 땅을 많이 팠다.

그렇다고 국비학원에 가기는 싫었다. 너무 많은 국비 학원 중 좋은 학원은 어떻게 찾을 것인가? 나는 너무 게으르고 서칭에 지쳐 있었다. 그냥 돈 좀 투자하고 비싸지만 유명한 것 같은 에프랩에 가는게 더 낫다고 생각했다.

요약 : 개인적으로 독학을 하다가, 헤매는 느낌이 들었고, 이때 누군가가 나를 붙잡아 줬으면 했다. 그래서 에프랩에 들어왔다.

이번달 동안 무엇을 배웠는지 :

자바를 처음부터 공부했다. 나는 일단 주니어 개발자가 목표이고, 경력이 없어서 처음부터 공부한것 같기도 하다. 그런데 커리큘럼은 멘토분과 상의해서 바꿀 수 있다.

자바의 기본서만 읽어서는 안된다는 걸 배웠다. 숨겨진 원리, 방대한 지식 등을 배웠다. 블로그, 지피티 등을 이용해 다양한 지식을 머리에 넣으려 했다. 자바의 기본서만 읽고 자바를 좀 안다고 자신했던 나는 참 오만했다.

멘토님은 어떻게 뽑는지, 어땠는지? :

일단 여러명 후보를 준다. 그 중에서 당신이 고를 수 있다. 멘토님들의 경력을 보고 잘 뽑으시길! 웬만하면 대부분 사람들이 안바꾼다고 들었다. 그만큼 멘토분들이 다 좋으시단 뜻 같다! 적어도 내 멘토분은 정말 정말 최고고 천사고 똑똑하시고(생략) 아무튼 좋다.

그리고 질문과 피드백에 대해서는… 할말이 없다. 내가 질문을 잘 안하는 타입이라서^^;; 그런데 피드백이 늦을 거라는 걱정은 안해도 될 것 같다! 멘토분이 참 열정적이고 좋은 분이시다.

멘토링에서 좋았던 점 :

일단 독학을 하다 보니 참 막막했다. 내가 잘하는지, 못하는지도 모른다. 그런데 멘토링 수업이 끝날 때마다 멘토분이 나를 평가해주시고, 그러시니 좋다. 그리고 커리큘럼과 읽어야할 책도 척척 구해다 주시니, 독학의 단점이 확 사라진다. 혼자서 커리큘럼을 책임지고 걱정하는 거랑 누군가가 서포트 해주는 거랑 차원이 다르다.

각오 : 솔직히 참 쉽지 않은 난이도이고 수업이다. 그래서 사실 초반에 에프랩에 돈 낭비했나? 내 수준이 너무 멍청한 것 같다고 생각을 했다. 그런데 나는 절박해서 여기 들어왔다. 에프랩 그만두고 어딜 갈 수 있는지 모르겠고, 나는 계획도 없었고, 개발자를 그만두면 뭘 해먹고 살지 막막했다. 그리고 무엇보다 개발자가 하고 싶다.

미래에 실패하든, 후회하든 그건 미래의 일이다. 지금 무섭다고, 돈 낭비 같다고 그만두면, 나는 내가 후회할 것을 안다.

실패하면 어떤가? 그냥 하는 거다. 그러니 입다물고 에프랩에 계속 있으려고 한다.

그래서 총 감상 및 후기 : 일대일 멘토링이니까 사기가 줄어들지 않을까? 오프라인 대형 학원에 가서 사람들이랑 소통하며 배워야해!라는 마인드를 가지셨다면, 글쎄요, 전그렇게 생각 안해요. 일대일이고 온라인 멘토링이더라도 개인이 얼마나 동기부여되어 있고, 열심히 하느냐에 따라 결과는 다릅니다. 온라인이고 일대일이라는 특징에 걱정하실 필요는 없습니다.

총 감상은 좋다라는 것입니다. 특히 본인의 의지, 열정이 있다면, 좋은 프로그램이 될것 같아요

난이도 :

솔직히 쉽지 않습니다 에프랩. 왜냐면 사실 경력자 분들도 많이 오시는 프로그램이거든요. 근데 나는 비전공자 신입 개발자가 되고 싶은 취준생이라는 점. 그래서 배경지식이 없다보니 수업 따라가는게 쉽지 않다. 하지만 성장하는건 원래 쉽지 않죠^^

마지막으로 에프랩 좋은 점 :

녹음이랑 스크립트 기능이 있어서 메모 안해도 됨.

그리고 ai 멘토가 있어서 ai로도 공부가 된다. 아래 사진은 ai가 만든 질문이다.

소프트웨어 장인

j1adev — Sat, 22 Feb 2025 14:45:36 +0900

소프트웨어 장인을 한단어로 요약하면 ‘열정’이다

가는 모든 직장, 프로젝트 하나하나가 투자이다. 커리어의 큰 목표를 향해 다가가는 단계다.

이 책은 인재를 채용하는 방법에 대해서도 기술한다. 나중에 팀 리더가 되어서 팀 운영, 면접을 해야할때 한번 더 읽으면 좋을 것 같다.

감상평 :

본격적으로 신입 자바 개발자가 되기 전에 개발자가 무엇인지에 대해 알 수 있었던 좋은 책이었다. 코딩은 혼자 하는게 아니라 여럿이서 하는 것이다. 고객을 만족시키는 전문가가 되고 싶다고 동기부여가 되었다.

1 소프트웨어 개발

개발자들은 다음과 같은 여럿을 할 수 있어야한다.

고객과 대화하기
테스트 / 배포 자동화하기
전체 비즈니스에 영향을 미칠 기술 선정하기
지리적으로 분산된 팀들과 협업하기
고객을 도와 필요한 작업을 정의하기
우선순위 선정하기
진척 상황 보고하기
변경사항과 기대일정 관리하기
잠재 고객 및 파트너에게 제품 소개하기
사전 영업 활동 지원하기
개발 일정과 비용 산출하기
채용 면접하기
아키텍처 설계하기
비기능적 요구사항과 계약 조건(SLAS) 검토하기
사업 목표 이해하기
주어진 여건에서 최적의 결정하기
새로운 기술 주시하기
더 나은 업무 방식 찾기
고객에게 가치 있는 상품이 전달되고 있는지 고민하기

애자일 매니페스토

https://agilemanifesto.org/iso/ko/manifesto.html

애자일 소프트웨어 개발 선언

애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게

agilemanifesto.org

위의 애자일 매니페스토와 함께, 열두 원칙들이 있다.

2 소프트웨어 장인정신

소프트웨어 장인정신이란?

소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

즉 이는 마음가짐이자 삶의 자세이다. 커리어에 주인의식을 가지고 프로페셔널하게 행동한다. 다른 개발자들에게 배우고 지식을 나눈다.

소프트웨어 장인정신 매니페스토

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,

변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,

개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,

고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

이 앞의 항목들(일반 굵기)을 추구하는 과정에서, 다음 항목들(볼드체)이 꼭 필요함을 의미한다.

‘동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을, ’

소스 코드는 예측 가능하고 유지보수될 수 있는 상태여야 한다. 그래야 애플리케이션을 수정하고 진화한다.

‘변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을, ’

계속 가치를 더한다는 의미는 신규 기능 추가, 버그 수정만 뜻하지는 않는다. 코드를 깔금히 정리하고 구조를 개선하며 확장성을 높이고, 테스트 가능하게 하고, 쉽게 유지보수 할 수 있게 하는 것을 포함한다.
소트프웨어 생명을 늘리며 변화에 빠르게 대응할 수 있도록 유지하는 것이 주요 목표다. 그래서 좋은 설계, 자동화된 테스트 기술이 필요.
보이스카웃이 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라는 규율이 있다. 코드도 처음 발견했을때 보다 더 깨끗하게 관리해야 한다. - 로버트 마틴

‘개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을, ’

멘토링과 공유

‘고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,’

우리는 고용자/피고용자 관계가 아니다. 적극적으로 프로젝트의 성공에 기여한다. 질문하고 비즈니스 이해하고, 개선사항 제시하고 고객과 동반자 관계이어야 한다 . 그리고 고용주를 잘 고르자.

3 소프트웨어 장인의 태도

끊임없는 자기계발

독서, 많은 독서

블로그

기슬 웹사이트

팔로우할 리더 찾기

계속 훈련

카타

펫 프로젝트

오픈 소스

페어 프로그래밍

4 영웅, 선의, 프로페셔널리즘

실패할 것 같은데, 성공해서 영웅이되겠다는 말도 안되는 생각 하지말기

‘아니오’라고 못하는 것은 선의가 아니다. 정확히 정보 전달하고 요구해라.

프로페셔널리즘은 나와 다른사람들에게 정직함을 의미.

‘아니오’라고 할때 대안을 제시하면 좋다. 대안을 모르면 최선의 노력을 한다고 보여주기, 문제 대응이 어떻게 되는지 공유하기.

실용 주의 장인정신

kent beck's four rules of simple design

모든 테스트의 통과
중복의 최소화
명료성의 최대화
구성 요소의 최소화

위의 내용 말고도 이 책에는 높은 품질의 코드의 중요성, 커리어 정하기, 채용 방법, 면접자로서의 태도 등에 대해 많은 토픽이 있다.