Featured Post

AI 바이브 코딩으로 만든 테스트, Testcontainers로 진짜 믿을 수 있게 다듬은 경험

작성자:
Testcontainers - 통합 테스트 관련 이미지

갑자기 왜 Testcontainers 이야기냐면요

요즘 개발자들 사이에서 AI 바이브 코딩 이야기가 정말 많이 나오잖아요. 저도 20년 넘게 개발 현장에 있다 보니 처음엔 좀 삐딱하게 봤어요. “아니, 코드를 AI가 써준다고? 그걸 믿고 서비스에 넣는다고?” 뭐 이런 마음이었죠. 나이가 들수록 새로운 도구를 무조건 의심하게 되는 건 아닌데, 그래도 운영 장애 몇 번 맞아본 사람은 조심스러워질 수밖에 없거든요.

그런데 막상 GitHub Copilot이나 Cursor 같은 도구를 업무에 붙여보니까, 이건 또 생각보다 쓸 만하더라고요. 단순 반복 코드나 테스트 코드 초안 만드는 속도는 확실히 빨라졌어요. 특히 “아, 이거 귀찮은데…” 싶은 Repository 테스트나 API 테스트 뼈대를 잡을 때는 꽤 고마웠습니다.

근데요. 여기서 살짝 정신 차려야 합니다. AI가 만들어준 코드가 그럴듯해 보인다고 해서 바로 믿으면 안 되더라고요. 특히 통합 테스트 쪽은 더 그래요. 로컬에서는 통과하는데 CI에서 깨지고, H2에서는 되는데 PostgreSQL에서는 죽고, 설정 하나 빠져서 테스트 자체가 엉뚱한 DB를 바라보고 있고… 이런 일이 은근히 자주 생깁니다.

그래서 제가 요즘 꽤 진지하게 쓰고 있는 조합이 바로 AI 바이브 코딩 + Testcontainers입니다. 오늘은 그 이야기를 좀 편하게 해볼게요. “이론적으로 좋다” 이런 말보다는, 제가 실제로 겪었던 삽질이랑 고친 방식 위주로요.

Testcontainers는 그냥 Docker 띄우는 도구가 아니더라고요

Testcontainers를 아주 짧게 말하면, 테스트 실행 중에 필요한 Docker 컨테이너를 자동으로 띄워주는 라이브러리입니다. PostgreSQL, MySQL, Redis, Kafka, RabbitMQ 같은 것들을 테스트할 때 실제 컨테이너로 올려서 붙여볼 수 있게 해줘요.

예전에는 통합 테스트를 만든다고 하면 H2 같은 인메모리 DB를 많이 썼잖아요. 저도 오래 그렇게 했습니다. 빠르고, 설정 쉽고, CI에서도 부담이 적고요. 그런데 운영 DB가 PostgreSQL인데 테스트는 H2로 돌리면, 묘하게 다른 부분이 생겨요. SQL 문법도 다르고, 타입 처리도 다르고, 인덱스나 제약 조건 동작도 가끔 달라요.

실제로 예전에 제가 겪었던 일인데요. H2에서는 멀쩡히 통과하던 쿼리가 운영 PostgreSQL에서 터진 적이 있었습니다. 이유는 아주 사소했어요. 예약어 처리와 JSONB 컬럼 관련 쿼리 차이였는데, 테스트가 H2 기반이다 보니 그걸 전혀 못 잡은 거죠. 그날 로그 보면서 커피를 몇 잔을 마셨는지 모르겠습니다. 뭐랄까, 테스트가 나를 안심시켜준 게 아니라 속인 느낌이었어요.

Testcontainers를 쓰면 이런 문제가 꽤 많이 줄어듭니다. 운영에서 PostgreSQL 15를 쓴다면 테스트에서도 PostgreSQL 15 컨테이너를 띄우면 되니까요. 특히 AI가 만들어준 SQL이나 JPA 매핑 코드가 실제 DB에서 잘 도는지 바로 확인할 수 있습니다.

구분 H2 기반 테스트 Testcontainers 기반 테스트
실제 운영 환경과의 차이 생각보다 큼. 특히 SQL 방언, 타입, 제약 조건에서 차이가 남 운영 DB와 같은 이미지를 쓰면 거의 동일하게 검증 가능
초기 설정 가볍고 쉬움 Docker가 필요하고 설정을 조금 챙겨야 함
AI 코드 검증 그럴듯한 코드가 그냥 통과할 수 있음 실제 DB에서 바로 걸러짐
테스트 신뢰도 빠르지만 운영 반영도가 낮을 수 있음 조금 무겁지만 믿을 만함

저는 요즘 Testcontainers를 단순한 테스트 도구라기보다, AI가 만든 코드의 허세를 걷어내는 필터처럼 보고 있어요. AI가 코드를 참 말끔하게 뽑아주긴 하는데, 그게 진짜 돌아가는 코드인지는 또 다른 문제거든요.

실제로 AI가 만들어준 테스트 코드에서 터졌던 부분

최근에 Spring Boot 3.2 기반 마이크로서비스 프로젝트를 하나 봤습니다. Java 21, Gradle, PostgreSQL 15 조합이었고요. 흔한 UserRepository 테스트였어요. AI에게 “UserRepository 통합 테스트 만들어줘”라고 요청했더니, 겉보기엔 꽤 멀쩡한 코드가 나왔습니다.

항목 실제 사용 환경
프레임워크 Spring Boot 3.2
언어 / 빌드 Java 21, Gradle
AI 도구 GitHub Copilot Chat, Cursor
데이터베이스 PostgreSQL 15
테스트 도구 JUnit 5, AssertJ, Testcontainers 1.19.7

처음 AI가 만들어준 코드는 대충 이런 느낌이었습니다. 일부러 핵심만 남겨서 단순화했어요.

@Testcontainers
@SpringBootTest
class UserRepositoryTest {

    @Container
    PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15");

    @Test
    void saveUser() {
        // 테스트 코드
    }
}

처음 보면 괜찮아 보입니다. @Testcontainers도 있고, PostgreSQLContainer도 있고요. 그런데 실제로 돌려보면 이상하게 꼬입니다. 컨테이너는 뜨는데 Spring datasource가 그 컨테이너를 바라보지 않아요. 왜냐하면 @DynamicPropertySource 설정이 빠져 있었거든요.

게다가 @Container 필드도 static이 아니었습니다. 상황에 따라 테스트 인스턴스 생성 방식과 맞물려서 컨테이너 생명주기가 애매해지고, 테스트가 늘어날수록 실행 시간도 늘어납니다. 이런 건 AI가 자주 놓쳐요. 진짜 자주요.

그래서 제가 실제로 손본 코드는 이렇게 바꿨습니다.

@Testcontainers
@SpringBootTest
class UserRepositoryIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15.4")
            .withDatabaseName("integration_test_db")
            .withUsername("testuser")
            .withPassword("testpass");

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Autowired
    private UserRepository userRepository;

    @Test
    void testSaveAndFindUser() {
        User user = new User("alice", "alice@example.com");

        userRepository.save(user);
        Optional<User> found = userRepository.findByEmail("alice@example.com");

        assertThat(found).isPresent();
        assertThat(found.get().getName()).isEqualTo("alice");
    }
}

여기서 제가 꼭 보는 포인트는 딱 몇 가지입니다.

    • 컨테이너 이미지 태그가 고정되어 있는지 확인합니다. postgres:latest는 정말 피하는 게 좋아요.
    • @DynamicPropertySource로 실제 컨테이너의 JDBC URL이 Spring에 들어가는지 봅니다.
    • @Container가 static인지 확인합니다. 테스트 클래스마다 불필요하게 컨테이너가 뜨면 속도가 확 느려져요.
    • 테스트 데이터가 실제 비즈니스 규칙과 맞는지 봅니다. AI는 생각보다 엉뚱한 이메일이나 상태값을 잘 넣습니다.

이런 작은 설정 하나가 테스트 신뢰도를 확 갈라놓습니다. 솔직히 코드 몇 줄 차이인데, 장애 한 번 막아주면 그걸로 밥값은 충분히 한 거죠.

AI에게 Testcontainers 코드를 시킬 때 프롬프트를 이렇게 바꿨습니다

처음에는 저도 AI에게 이렇게 말했어요.

UserRepository 테스트 코드 만들어줘.

그러면 AI는 대체로 유닛 테스트 비슷한 걸 만들어줍니다. Mockito로 Repository를 mock 처리하거나, H2 기준으로 적당히 돌아가는 코드를 주기도 해요. 나쁘진 않은데, 제가 원하는 건 그게 아니었거든요. 저는 실제 PostgreSQL에서 JPA 매핑과 쿼리가 제대로 도는지 보고 싶었습니다.

그래서 프롬프트를 훨씬 구체적으로 바꿨습니다.

Spring Boot 3.2 환경에서 UserRepository 통합 테스트를 작성해줘.
PostgreSQL 15.4를 Testcontainers로 실행하고,
@DynamicPropertySource를 사용해서 datasource 설정을 주입해줘.
컨테이너는 static으로 선언하고,
이미지 태그는 latest를 쓰지 말아줘.
build.gradle에 필요한 testcontainers, postgresql 의존성도 같이 보여줘.

이렇게 요청하면 결과물이 꽤 달라집니다. AI가 맥락을 더 잘 잡아요. 특히 운영 환경과 동일한 조건이라는 말을 넣으면, H2나 mock 테스트로 도망가는 일이 줄어듭니다.

저는 요즘 AI에게 테스트 코드를 맡길 때 거의 습관처럼 아래 문장을 붙입니다.

운영 환경과 최대한 동일한 조건에서 검증할 수 있도록 작성해줘.

별것 아닌 문장 같지만, 결과가 꽤 달라져요. AI는 우리가 대충 말하면 대충 알아듣습니다. 반대로 우리가 원하는 제약 조건을 분명히 주면, 그 안에서 꽤 괜찮은 초안을 만들어줘요. 그러니까 AI를 똑똑한 주니어 개발자처럼 대하는 게 맞는 것 같습니다. 일을 잘하긴 하는데, 요구사항은 정확히 줘야 하는 그런 동료요.

build.gradle 의존성도 AI에게 꼭 같이 요청하세요

한번은 AI가 테스트 코드는 그럴듯하게 만들어줬는데, 정작 build.gradle 의존성을 빼먹은 적이 있었습니다. IDE에서는 import가 빨갛게 뜨고, CI에서는 당연히 컴파일 실패가 났죠. 이런 거 은근히 맥 빠집니다. 코드가 틀린 것도 아니고, 준비물이 빠진 거니까요.

Spring Boot 3.x 기준으로는 보통 이런 식으로 챙깁니다.

dependencies {
    testImplementation "org.springframework.boot:spring-boot-starter-test"

    testImplementation "org.testcontainers:junit-jupiter:1.19.7"
    testImplementation "org.testcontainers:postgresql:1.19.7"

    runtimeOnly "org.postgresql:postgresql"
}

프로젝트에서 Spring Boot dependency management를 쓰고 있다면 버전 관리를 조금 다르게 할 수도 있습니다. 중요한 건 AI에게 테스트 코드만 달라고 하지 말고, 빌드 설정까지 같이 달라고 말하는 거예요.

    • 테스트 클래스 코드
    • build.gradle 또는 pom.xml 의존성
    • application-test.yml이 필요한지 여부
    • CI 환경에서 Docker 접근이 가능한지
    • 테스트 실행 시간이 너무 길어지지 않는지

이 다섯 가지를 같이 보면, 나중에 덜 고생합니다. 개발은 코드만 짜는 게 아니라, 코드가 돌아갈 자리까지 챙기는 일이잖아요. 나이 들수록 이게 더 크게 느껴집니다.

제가 실제로 챙기는 Testcontainers 사용 습관들

Testcontainers를 몇 번 써보면 “아, 이거 그냥 붙이면 되는구나” 싶다가도, 프로젝트가 커지면 또 다른 문제가 보입니다. 테스트 속도, 컨테이너 재사용, CI 환경, 병렬 실행 같은 것들이요. 제가 요즘 실제로 챙기는 습관을 좀 적어볼게요.

이미지 태그는 무조건 고정합니다

AI가 가끔 postgres:latest를 추천합니다. 저는 이거 보면 바로 고칩니다. latest는 오늘의 latest와 한 달 뒤의 latest가 다를 수 있거든요. 테스트는 재현성이 생명인데, 이미지 버전이 바뀌면 어제 통과하던 테스트가 오늘 깨질 수 있습니다.

그래서 저는 보통 이렇게 씁니다.

postgres:15.4
mysql:8.0.36
redis:7.2.4
rabbitmq:3.12-management

조금 귀찮아도 버전을 박아두는 게 마음이 편해요. 특히 회사 프로젝트에서는 더 그렇습니다. 내 로컬에서만 돌리는 장난감 코드가 아니니까요.

로컬에서는 컨테이너 재사용을 켜기도 합니다

Testcontainers는 기본적으로 테스트마다 컨테이너를 띄우고 정리합니다. 안전하긴 한데, 로컬 개발할 때는 느릴 수 있어요. 테스트 한 번 돌릴 때마다 PostgreSQL 이미지를 확인하고 컨테이너를 띄우면, 은근히 기다리는 시간이 쌓입니다.

로컬에서는 ~/.testcontainers.properties 파일에 아래 설정을 넣어 컨테이너 재사용을 켤 수 있습니다.

testcontainers.reuse.enable=true

그리고 코드에서는 필요할 때 이런 식으로 붙입니다.

static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15.4")
        .withReuse(true);

다만 이건 로컬 개발 환경에서만 조심스럽게 쓰는 편이 좋아요. CI에서는 테스트 격리성이 더 중요합니다. 재사용 때문에 이전 테스트 데이터가 남아 있으면, 그때부터는 테스트가 테스트가 아니게 됩니다. 그냥 운 좋은 통과죠.

AI가 만든 테스트 데이터는 믿지 않습니다

AI는 테스트 데이터를 너무 예쁘게 만듭니다. 문제는 그 예쁜 데이터가 실제 업무 규칙을 안 지킬 때가 있다는 거예요. 예를 들어 우리 서비스는 이메일 형식을 엄격하게 보는데, AI가 test@test 같은 값을 넣을 때가 있습니다. 전화번호 형식, enum 상태값, 날짜 범위, 유니크 조건도 자주 놓칩니다.

그래서 저는 AI가 만든 @BeforeEach나 fixture 코드는 꼭 봅니다. 특히 아래 항목은 거의 체크리스트처럼 확인해요.

    • 이메일, 전화번호, 사업자번호 같은 값이 실제 validation 규칙을 만족하는지
    • 외래키 관계가 제대로 잡혀 있는지
    • 유니크 인덱스를 침범하지 않는지
    • 테스트마다 데이터가 격리되는지
    • 시간 관련 값이 현재 날짜에 따라 흔들리지 않는지

테스트 데이터는 별거 아닌 것처럼 보여도, 여기서 테스트 품질이 갈립니다. 좋은 테스트는 시나리오가 현실적이에요. 그냥 저장하고 조회하는 수준에서 멈추면, 나중에 진짜 복잡한 업무 로직에서 구멍이 납니다.

CI에서 한 번 크게 데인 RabbitMQ 테스트 이야기

로컬에서는 잘 되는데 CI에서만 깨지는 테스트, 개발자라면 다들 싫어하잖아요. 저도 한 번 제대로 당했습니다. AI가 만들어준 RabbitMQ 통합 테스트였는데, 제 노트북에서는 정말 멀쩡하게 돌았어요. 그래서 “오, 이번엔 괜찮네?” 하고 올렸죠.

그런데 GitHub Actions에서 계속 실패했습니다. 로그를 보니 포트 충돌 비슷한 메시지가 보였고, 테스트 클래스가 여러 개 병렬로 돌면서 RabbitMQ 컨테이너가 예상보다 많이 생성되고 있었습니다. 원인을 보니 @Container 선언이 static이 아니었고, 동적 포트 매핑을 제대로 활용하지 않은 부분도 있었어요.

java.net.BindException: Address already in use
Failed to start container rabbitmq:3-management

이런 로그를 CI에서 보면 마음이 참 답답해집니다. 로컬에선 되는데 왜 여기선 안 되냐고요. 근데 대부분 이유가 있습니다. 특히 Testcontainers는 Docker 환경, 병렬 실행, 컨테이너 생명주기랑 아주 밀접하게 엮여 있어서 대충 만들면 CI에서 티가 납니다.

그 뒤로 저는 AI가 만들어준 메시지 큐 테스트를 보면 아래를 꼭 확인합니다.

    • @Container가 static으로 선언되어 있는지
    • 고정 포트 매핑을 쓰고 있지 않은지
    • Testcontainers의 동적 포트를 Spring property로 주입하는지
    • CI runner에서 Docker daemon 접근이 가능한지
    • 병렬 테스트 실행 시 서로 간섭하지 않는지

특히 고정 포트는 조심해야 합니다. AI가 가끔 5672:5672 같은 식으로 예제를 만들어주는데, 테스트에서는 굳이 그럴 필요가 없습니다. Testcontainers가 알아서 동적 포트를 잡아주고, 우리는 그 값을 애플리케이션 설정에 넣어주면 됩니다.

Testcontainers를 안 썼을 때와 썼을 때, 체감 차이

사실 Testcontainers를 쓰면 테스트가 조금 무거워지는 건 맞습니다. Docker가 필요하고, 처음 이미지를 받을 때 시간도 걸립니다. 팀원 PC 환경도 맞춰야 하고요. 그래서 “굳이 이렇게까지 해야 하나?” 싶은 순간도 있어요.

그런데 운영 환경과 비슷한 조건에서 버그를 미리 잡아본 경험이 한두 번 쌓이면 생각이 달라집니다. 저는 이제 DB나 메시지 큐가 핵심인 서비스에서는 Testcontainers 없이 통합 테스트를 짜는 게 오히려 불안합니다.

항목 AI + Testcontainers AI + H2 인메모리 DB
운영 환경 일치도 높음. 실제 PostgreSQL, MySQL, Redis 등을 사용 가능 낮음. DB 방언 차이로 운영에서 터질 수 있음
AI 코드 검증력 좋음. 그럴듯하지만 틀린 설정을 빨리 잡음 애매함. 테스트는 통과했는데 운영에서 깨질 수 있음
테스트 속도 상대적으로 느림. 최적화가 필요함 빠름. 가볍게 돌리기 좋음
초기 진입 장벽 Docker와 설정 이해가 필요함 거의 없음
장기적인 안정감 높음. 운영 전 단계에서 많은 문제를 걸러줌 프로젝트가 커질수록 불안 요소가 생김

저는 둘 중 하나만 쓰라는 이야기를 하고 싶진 않아요. 빠른 유닛 테스트나 단순 Repository 테스트에는 H2가 여전히 편할 때도 있습니다. 다만 AI가 만들어준 코드를 운영 환경 기준으로 검증하고 싶다면 Testcontainers 쪽이 훨씬 든든하다는 게 제 생각입니다.

AI 바이브 코딩할 때 제가 정해둔 작은 원칙

AI 바이브 코딩을 하다 보면 확실히 속도가 빨라집니다. 그런데 속도가 빨라질수록, 사람이 봐야 할 지점도 더 선명해져요. 저는 요즘 AI가 만든 코드를 받을 때 이런 식으로 역할을 나눕니다.

AI에게 맡기는 부분 사람이 꼭 보는 부분
테스트 코드 초안 작성 테스트 목적이 실제 업무 시나리오와 맞는지
반복적인 assertion 작성 검증 포인트가 핵심을 찌르는지
기본 Testcontainers 설정 생성 @DynamicPropertySource, static container, 이미지 태그 고정 여부
build.gradle 의존성 추천 현재 프로젝트 버전과 충돌하지 않는지
CI workflow 초안 생성 Docker daemon 접근, 병렬 실행, 캐시 전략

AI를 못 믿겠다는 이야기는 아닙니다. 오히려 저는 꽤 잘 쓰고 있어요. 다만 AI가 만들어준 코드는 “완성품”이라기보다 “꽤 괜찮은 초안”이라고 보는 게 마음 편합니다. 그 초안을 실제 서비스에 맞게 다듬는 건 여전히 개발자의 몫이고요.

뭐랄까, 예전에는 삽질하면서 처음부터 끝까지 손으로 다 만들었다면, 이제는 AI가 옆에서 빠르게 재료를 손질해주는 느낌입니다. 대신 간을 보는 건 내가 해야죠. 국이 짠지 싱거운지는 결국 사람이 먹어봐야 아니까요.

자주 받는 질문 몇 가지

AI가 만든 Testcontainers 코드를 그대로 써도 괜찮을까요?

저는 그대로 쓰지 않습니다. 경험상 70~80% 정도는 맞는데, 나머지 20~30%에서 꼭 뭔가 빠져 있어요. 특히 @DynamicPropertySource, static 컨테이너 선언, 이미지 태그 고정, Gradle 의존성 누락은 자주 봤습니다. 코드가 깔끔해 보여도 한 번은 꼭 의심하고 돌려보는 게 좋습니다.

테스트가 너무 느린데 어떻게 줄이면 좋을까요?

로컬에서는 컨테이너 재사용을 고려해볼 수 있습니다. 그리고 테스트 클래스마다 컨테이너를 따로 띄우지 않도록 공통 base class를 두는 방법도 좋아요. 이미지도 가능하면 너무 무거운 걸 피하고요. 다만 CI에서는 무리하게 재사용을 켜기보다, 테스트 격리성과 안정성을 먼저 보는 게 좋습니다.

H2를 완전히 버려야 하나요?

그건 아닙니다. H2는 빠르고 편합니다. 단순한 단위 테스트나 가벼운 Repository 테스트에는 여전히 쓸 만해요. 다만 운영 DB 특성이 중요한 쿼리, 복잡한 JPA 매핑, 트랜잭션, 제약 조건 검증은 Testcontainers로 보는 편이 훨씬 안전합니다.

AI에게 어떤 식으로 요청하면 결과가 좋아지나요?

저는 “테스트 만들어줘”라고 짧게 말하지 않습니다. 사용 기술, 버전, 운영 환경, 꼭 포함해야 할 설정을 같이 말해요. 예를 들면 이런 식입니다.

Spring Boot 3.2, Java 21, Gradle 환경에서
PostgreSQL 15.4를 사용하는 UserRepository 통합 테스트를 Testcontainers로 작성해줘.
@DynamicPropertySource를 포함하고,
컨테이너는 static으로 선언해줘.
이미지 태그는 latest를 쓰지 말고,
필요한 build.gradle 의존성도 같이 작성해줘.

이 정도로 말하면 AI가 훨씬 덜 헤맵니다. 사람한테 업무 지시할 때도 배경 설명이 있으면 결과가 좋아지는 것과 똑같아요.

이런 분이라면 Testcontainers를 꼭 한 번 붙여보세요

AI 바이브 코딩을 이미 쓰고 있거나, 앞으로 써볼 생각이 있다면 Testcontainers는 꽤 좋은 안전장치가 됩니다. AI가 코드를 빠르게 만들어주는 건 분명 장점인데, 그 코드가 실제 운영 환경에서도 버틸지는 테스트가 말해줘야 하거든요.

특히 이런 분들께는 한 번 진지하게 추천하고 싶습니다.

    • AI가 만들어준 Repository 테스트가 어딘가 미심쩍은 분
    • H2에서는 통과하는데 운영 DB에서 터진 경험이 있는 분
    • PostgreSQL, MySQL, Redis, RabbitMQ, Kafka 같은 외부 시스템 의존성이 많은 서비스를 운영하는 분
    • CI/CD에서 테스트 실패 때문에 자주 발목 잡히는 분
    • 통합 테스트를 제대로 만들고 싶은데 매번 환경 구성에서 지치는 분

솔직히 처음에는 Testcontainers 설정이 살짝 귀찮습니다. Docker도 필요하고, 이미지도 받아야 하고, 팀원들 환경도 맞춰야 하니까요. 그런데 한 번 자리 잡고 나면 꽤 든든합니다. 저는 이걸 쓰고 나서 “테스트가 통과했다”는 말에 조금 더 마음을 놓게 됐어요.

AI가 코딩 속도를 올려주는 시대가 온 건 맞습니다. 다만 속도가 올라간 만큼, 검증의 밀도도 같이 올려야 한다고 봐요. 그 균형을 잡아주는 도구 중 하나가 Testcontainers였습니다. 저한테는요.

편하게 말하면 이렇습니다. AI에게 초안은 맡기되, 진짜 환경에서 한 번 굴려보세요. 그때 Testcontainers가 옆에 있으면 생각보다 마음이 편합니다. 개발 오래 하다 보면 결국 이런 안정감이 꽤 중요하더라고요.

댓글

댓글 쓰기