DEVOCEAN

수정한 적 없는 단위 테스트가 라이브러리 판올림 직후 10번 연속으로 실패하고 콘솔에 BeanDefinitionOverrideException 로그가 찍힙니다. 프롬프트 엔지니어링을 거쳐 배포한 내부 기획서 생성 에이전트는 알 수 없는 문맥 왜곡과 어색한 어휘 선택 때문에 현업 기획자들의 외면을 받습니다. 디자인 시안을 코드로 옮기기 위해 매달 결제하던 고가의 디자인 도구 구독은 막상 개발팀이 에이전트를 통해 코드를 직접 수정하기 시작하자 유휴 계정으로 남습니다.

이 세 가지 문제는 겉보기에 무관한 영역에서 발생한 것처럼 보이지만 근본적인 원인은 같습니다. 사람이 작업할 때 관습적으로 허용하던 '암묵적 탐색'과 '모호한 경계'가 AI 도구의 개입으로 인해 파탄을 맞이했다는 사실입니다. 스프링의 자동 컴포넌트 스캔, 대규모 언어 모델의 확률적 토큰 생성, 그리고 디자인과 코드 사이의 핸드오프 관행은 모두 기계가 정밀하게 동작하기 위한 명시적 규칙을 요구하고 있습니다.

스프링 컴포넌트 스캔의 암묵적 탐색과 테스트 격리 실패

최근 백엔드 개발 현장에서는 코딩 에이전트를 도입해 단위 테스트나 통합 테스트 코드를 빠르게 작성하는 시도가 늘고 있습니다. 코딩 에이전트와 스프링 컴포넌트 스캔 이슈를 다룬 기술 블로그에서는 컨트롤러 테스트 파일 자체를 전혀 수정하지 않았음에도 빌드 파이프라인에서 동일한 이름의 빈이 두 번 등록되었다는 예외(BeanDefinitionOverrideException)가 발생해 10회 연속 실패한 사례를 공유했습니다.

원인을 역추적한 결과 문제는 같은 패키지 경로에 코딩 에이전트가 새로 작성해 둔 권한 검사 통합 테스트 클래스 내부의 @Configuration 빈 선언이었습니다. 스프링 부트 애플리케이션의 최상위 실행 클래스에 붙는 @SpringBootApplication 어노테이션은 기본적으로 하위 패키지 전체를 뒤져 컴포넌트를 탐색하는 @ComponentScan 동작을 포함합니다. 사람이 손으로 코드를 짤 때는 특정 테스트 내부의 설정 클래스를 무의식중에 상위 패키지와 격리하거나 중복을 눈으로 확인하지만, 코딩 에이전트는 지시받은 테스트 요구사항만을 충족하기 위해 패키지 루트 아래에 자유롭게 테스트용 설정을 추가합니다. 그 결과 프로덕션 애플리케이션 컨텍스트를 공유하는 다른 테스트들이 오염됩니다.

여기부터는 DEVOTEE의 해석입니다. 코딩 에이전트가 스프링 부트나 코틀린 환경에서 엉뚱한 코드를 만들어내는 현상은 LLM 자체의 코드 생성 능력 부족보다는 프레임워크가 제공해 온 '설정보다 관례(Convention over Configuration)' 패러다임이 에이전트의 컨텍스트 윈도우 범위와 어긋나기 때문입니다. 에이전트는 파일 단위 또는 변경 청크 단위로 컨텍스트를 파악하므로, 상위 패키지의 @SpringBootApplication이 암묵적으로 끌어올 빈 등록 범위 전체를 완전히 계산하지 못합니다.

이 문제를 해결하기 위해 실무에서는 테스트 설정과 컴포넌트 스캔 범위를 명시적으로 닫아주는 패턴을 적용해야 합니다. 슬라이스 테스트(Slice Test, 컨트롤러나 리포지토리 등 특정 계층만 잘라내어 최소한의 빈만 띄우는 테스트 기법)를 작성할 때는 @SpringBootTest로 전체 컨텍스트를 로딩하는 대신, 테스트 대상과 필요한 모듈만 명시적으로 가져오도록 선언합니다.

package com.example.service.controller;

import com.example.service.auth.SecurityConfig;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.context.annotation.Import;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@WebMvcTest(UserController.class)
@ContextConfiguration(classes = {UserController.class})
@Import(SecurityConfig.class)
class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    @DisplayName("인증되지 않은 사용자는 401 응답을 받는다")
    void shouldReturnUnauthorized() throws Exception {
        mockMvc.perform(get("/api/users/me"))
                .andExpect(status().isUnauthorized());
    }
}

위 코드처럼 @ContextConfiguration에 필요한 클래스를 직접 명시하거나 테스트 전용 설정 클래스에 @TestConfiguration을 선언하여 자동 스캔 대상에서 제외시키는 구조를 확립해야 합니다. 이 작업에 대한 DEVOTEE의 판단은 조건부로 유효하다입니다. 컴포넌트 스캔 범위를 명시적으로 좁히고 모듈화하는 작업은 에이전트가 생성한 코드로 인한 컨텍스트 오염을 원천 차단하지만, 이미 수천 개의 빈이 거대하게 얽혀 있는 레거시 모노리스 애플리케이션에 일괄 적용하려면 설정 클래스 분리에 따른 초기 공수가 상당하기 때문입니다.

토큰 확률 조작과 워터마크 기술이 만든 텍스트 품질의 왜곡

에이전트가 코드를 작성하는 환경에서 암묵적 설정이 빈 충돌을 일으킨다면, 자연어 생성 영역에서는 통계적 확률 분포를 외부에서 임의로 비트는 행위가 실무 사용성을 저해하고 있습니다. LLM 텍스트 워터마크 도입과 부작용을 다룬 포스트에서는 내부 생성형 AI 서비스에 텍스트 워터마크를 적용한 후, 프로덕트 매니저(PM)들이 문맥의 어색함을 느끼고 타 모델로 이탈한 실제 사례를 공개했습니다.

텍스트 워터마크 기술(KGW, SynthID-Text, textGrain 등)은 인공지능이 생성한 텍스트인지 판별하기 위해 문맥과 사전에 공유된 비밀키를 기반으로 토큰 선택 확률을 조작합니다. 일반적으로 LLM은 다음 토큰을 생성할 때 확률 분포(Logits)를 계산한 뒤 상위 후보들 중에서 샘플링을 진행합니다. 워터마크 알고리즘은 직전 생성된 토큰(n-gram)의 해시값을 비밀키와 조합하여 전체 어휘집을 '선호 목록(Greenlist)'과 '비선호 목록(Redlist)'으로 나눕니다. 그리고 선호 목록에 속한 토큰의 로짓에 일정 가중치(Bias)를 강제로 더해 해당 토큰이 뽑힐 확률을 인위적으로 높입니다.

이론적으로는 가중치를 정밀하게 조정하면 언어 모델 본래의 엔트로피와 확률 분포를 평균적으로 유지할 수 있다고 알려져 있습니다. 그러나 원문에서 지적하듯 고정된 키 환경에서 짧은 프롬프트나 전문 용어가 빈번히 등장하는 도메인 문서를 생성할 때, 가장 적절한 단어가 비선호 목록에 배치되면 모델은 문맥에 맞지 않는 억지 유의어나 부자연스러운 조사를 강제로 선택하게 됩니다. PRD(제품 요구사항 정의서) 작성 에이전트를 사용하던 기획자들이 결과물의 미묘한 문장 어색함을 감지하고 에이전트를 신뢰하지 않게 된 배경입니다.

여기부터는 DEVOTEE의 해석입니다. 텍스트 워터마크는 저작권 보호나 부정 사용 방지라는 거버넌스 목적에는 부합하지만, 생성 품질의 미세한 왜곡이 제품 수용성을 직접적으로 떨어뜨립니다. 특히 정밀한 기술 명세나 논리적 연결이 중요한 실무 문서 작성 도구에서는 토큰 확률을 통계적으로 왜곡하는 워터마크를 도입하는 순간 사용성 저하라는 트레이드오프를 감수해야 합니다.

워터마크 도입에 대한 DEVOTEE의 판단은 아직 지켜볼 단계다입니다. 현재 공개된 토큰 샘플링 변조 기술은 왜곡을 줄이기 위해 다양한 연구가 진행 중이나, 도메인 특화 텍스트 생성 파이프라인에 전면 적용하기에는 사용자의 서비스 이탈 위험이 지나치게 큽니다. 법적 규제 준수가 필수가 아닌 사내 생산성 도구라면 워터마크보다는 프롬프트 로그 추적이나 시스템 내부 메타데이터 로깅을 통한 사후 검증 체계를 우선 검토하는 것이 현실적입니다.

캔버스 중심에서 코드 선언으로 이동하는 디자인 시스템

엔지니어링 설정과 생성 텍스트의 불투명성이 걷어지는 흐름은 프로덕트 디자인과 프론트엔드 협업 구조에서도 동일하게 관찰됩니다. Figma 구독 모델 변경과 워크플로 전환을 기록한 사례에 따르면, 버즈빌 디자인팀은 분기 라이선스 갱신 시점에 전사 Figma 계정을 기존 Organization 티어에서 Professional 티어로 다운그레이드 요청했습니다.

이러한 결정이 내려진 이유는 디자이너의 일하는 방식이 달라졌기 때문입니다. 과거에는 디자이너가 Figma 캔버스 위에 버튼의 크기, 패딩, 마진, 색상 코드를 픽셀 단위로 상세히 명시하고, 개발자는 이를 Dev Mode를 통해 열람하며 코드로 일일이 변환하는 핸드오프(Handoff) 방식을 취했습니다. 이 방식에서는 엔지니어 전용 좌석 라이선스가 필수적이었고, Figma 파일은 사양 문서 역할을 하느라 끝없이 무거워졌습니다.

그러나 디자인 시스템의 토큰(Token, 색상·간격·폰트 등의 디자인 최소 단위 값)과 핵심 컴포넌트가 코드 저장소에 표준화되어 정착되면서 흐름이 바뀌었습니다. 디자이너는 이제 복잡한 그래픽 캔버스에 모든 화면 상태를 그리는 대신 LLM을 활용해 디자인 시스템 기반의 Pull Request(PR)를 직접 열기 시작했습니다. 코드베이스에 이미 버튼, 모달, 인풋 필드의 명세가 정립되어 있으므로, 디자이너는 캔버스를 상세히 파는 대신 실제 코드 레벨에서 컴포넌트를 조립하고 변경 사항을 제안합니다. 그 결과 엔지니어의 Dev Mode 열람 빈도가 줄었고, 불필요해진 고비용 Organization 계정을 유지할 이유가 사라졌습니다.

여기부터는 DEVOTEE의 해석입니다. 디자인 도구의 캔버스는 시각적 발상을 자유롭게 펼치는 데는 최적이지만, 협업의 최종 단일 진실 공급원(Single Source of Truth)으로 삼기에는 버전 관리와 런타임 동기화 측면에서 한계가 뚜렷했습니다. 디자인 토큰을 JSON이나 CSS 변수와 같은 명시적 선언으로 코드 저장소에 두고, 에이전트 도구를 통해 디자이너가 직접 코드를 다루는 환경이 열리면서 핸드오프 단계 자체가 축소되고 있습니다.

디자인 토큰을 기반으로 한 워크플로 전환에 대한 DEVOTEE의 판단은 지금 써볼 만하다입니다. 디자인 시스템이 사내에 이미 라이브러리 형태로 구축되어 있는 조직이라면, 고가의 디자인 도구 애드온에 의존하기보다 코드 중심의 토큰 동기화 체계를 갖추는 편이 장기적인 툴 비용 절감과 배포 주기 단축에 직접적인 도움이 됩니다.

{
  "color": {
    "background": {
      "primary": { "value": "#ffffff", "type": "color" },
      "surface": { "value": "#f8f9fa", "type": "color" }
    },
    "text": {
      "default": { "value": "#111827", "type": "color" },
      "muted": { "value": "#6b7280", "type": "color" }
    }
  },
  "spacing": {
    "sm": { "value": "8px", "type": "spacing" },
    "md": { "value": "16px", "type": "spacing" },
    "lg": { "value": "24px", "type": "spacing" }
  }
}

디자인 토큰을 위와 같은 표준 JSON 형식으로 정의하고 빌드 도구를 통해 웹(CSS/Tailwind), 모바일(Swift/Kotlin)의 스타일 상수로 자동 변환하는 파이프라인을 두면, 에이전트 역시 이 명시된 토큰 키값을 참조하여 스타일 불일치 없는 UI 코드를 생성할 수 있습니다.

모호한 관례를 걷어내고 명시적 인터페이스 세우기

세 가지 현상은 모두 하나의 방향을 보여줍니다. 사람이 감각과 관습으로 메우던 모호한 경계는 AI 도구가 개입하는 순간 예외를 뿜어내거나(스프링 빈 충돌), 품질 왜곡을 낳거나(워터마크로 인한 이탈), 워크플로의 비용 낭비(디자인 도구 과다 구독)를 드러냅니다.

스프링 프레임워크에서 관례에 기대던 자동 스캔은 테스트 범위를 명시하는 선언형 격리로 대체되어야 합니다. 자연어 생성 파이프라인에서는 확률을 불투명하게 조작하는 방식 대신 입력과 출력을 있는 그대로 감사(Audit)할 수 있는 로깅 체계가 우선되어야 합니다. 디자인과 프론트엔드의 접점에서는 그래픽 도구의 시각적 사양서 대신 버전 관리되는 코드 토큰이 표준 인터페이스 역할을 맡아야 합니다.

자동화 도구와 AI 에이전트를 실무에 안착시키기 위한 전제 조건은 도구 자체의 파라미터를 늘리는 일이 아닙니다. 우리 시스템이 의존하고 있던 암묵적 규칙들을 찾아내어 기계와 사람이 모두 명확하게 해석할 수 있는 선언적 인터페이스로 다시 정의하는 작업이 선행되어야 합니다.

도입 전 확인할 것

조직 내에 코딩 에이전트나 디자인 자동화 파이프라인을 본격적으로 도입하기 전에 점검해야 할 실무 체크리스트입니다.

• 스프링 테스트 컨텍스트 분리 상태: 프로젝트 내 단위 테스트 및 슬라이스 테스트에 무분별한 @SpringBootTest가 사용되고 있지 않은지 점검합니다. 코딩 에이전트에게 작성을 맡길 테스트 클래스라면 @ContextConfiguration이나 @WebMvcTest 등으로 스캔 대상을 명시적으로 닫아둘 수 있는 아키텍처 규칙이 린터나 코드 컨벤션으로 정의되어 있어야 합니다.
• 워터마크 도입에 따른 사용자 경험 측정 지표: 사내외 LLM 서비스에 텍스트 워터마크 알고리즘을 적용할 계획이라면, 모델의 출력 텍스트에 대한 블라인드 선호도 평가(A/B 테스트)와 이탈률 지표를 사전에 정의해야 합니다. 단어 다양성과 도메인 전문 용어의 정확도가 서비스 만족도에 미치는 영향을 먼저 정량화하는 절차가 필수적입니다.
• 디자인 토큰의 코드베이스 동기화 여부: 디자인 도구 구독을 축소하고 협업 방식을 전환하려면, Figma 스타일이 코드의 토큰 파일과 실시간 또는 CI 파이프라인으로 일치되고 있는지 확인해야 합니다. 디자이너가 Git PR을 열 수 있는 최소한의 브랜치 전략과 리뷰 가이드라인이 갖춰져 있는지가 워크플로 전환의 성공을 결정합니다.

그 밖의 소식

• Google, Gemini 4 Argon 정식 출시 — 롱 디코드(Long decode)를 통해 최대 약 100만 토큰의 추론 및 출력을 지원하는 대규모 코드 리팩터링 및 연구용 모델입니다.
• Kimsuky 연관 Funhouse 랜섬웨어 유포 사례 — 이력서로 위장한 악성 한글 문서를 통해 기존 Endpoint 변종인 Funhouse 랜섬웨어와 Quasar RAT을 유포한 공격 정황이 안랩에 의해 분석되었습니다.
• Ledger 하드웨어 지갑 내 스파이 칩 삽입 사건 — 비공식 리셀러를 통해 유통된 기기 내부에서 화면과 버튼 입력을 가로채 시드 구문을 탈취하는 무단 하드웨어 변조 칩이 발견되었습니다.