Fall in IT.

AI 에이전트 시대, 개발자에게 필요한 것은 무엇인가

D.Y — Mon, 13 Apr 2026 16:00:29 +0900

코드를 잘 짜는 능력이 개발자의 핵심 역량이라는 공식이 흔들리고 있다. 실리콘밸리의 일부 팀은 이미 구현의 상당 부분을 AI에게 맡기고 있으며, 엔지니어는 코드를 작성하는 사람에서 AI가 잘 작동할 수 있는 환경을 설계하는 사람으로 역할이 이동하고 있다. 이 변화가 현장 개발자에게 무엇을 요구하는지, 그리고 어떤 개념들을 이해해야 하는지를 정리한다.

AI 엔지니어링을 구성하는 네 가지 축

현재 AI를 활용한 개발 방법론은 크게 네 가지 영역으로 구분된다. 이 네 가지는 순서대로 적용하는 단계가 아니라, 상호 보완적으로 함께 작동하는 구성 요소이다.

1. Prompt Engineering

LLM 모델에게 의도를 정확하게 전달하는 기술이다. 구체적인 지침을 작성하거나 페르소나를 설정하는 방식이 대표적이다. 가장 먼저 알려졌고 가장 익숙한 영역이지만, 단독으로는 한계가 명확하다.

2. Context Engineering

AI에게 프로젝트 구조, 기존 코드 예시, API 문서 등을 함께 전달하는 기술이다. 단순히 정보를 많이 주는 것이 아니라, 필요한 정보를 적절하게 선별해서 제공하는 것이 핵심이다. 정보를 과도하게 제공하면 오히려 역효과가 발생한다는 것이 실제 사용 사례들을 통해 확인되었으며, LLM 모델마다 컨텍스트를 유지하는 용량이 다르기 때문에 설계 기술이 필요해졌다.

컨텍스트는 세 개의 레이어로 구성된다.

System Context: 에이전트가 항상 참조하는 기본 설정 (CLAUDE.md, AGENTS.md 등)
Conversation Context: 대화 과정에서 누적되는 이전 맥락
Tool & Environment Context: 도구 실행을 통해 얻은 실시간 정보 (MCP, 플러그인 등)

3. Harness Engineering

하네스(Harness)는 원래 말을 통제하기 위해 씌우는 마구(馬具)를 뜻한다. Harness Engineering은 강력한 AI 에이전트를 안전하게 통제할 수 있는 환경을 만드는 기술이다.

전통적인 소프트웨어는 결정론적이다. 같은 입력에는 반드시 같은 결과가 나온다. 그러나 LLM은 비결정론적이다. 같은 입력이라도 상황에 따라 다른 결과가 나올 수 있다. 이 특성 때문에 단순히 프롬프트를 정교하게 작성하는 것만으로는 부족하며, 실패가 구조적으로 반복되지 않도록 환경 자체를 설계해야 한다.

예를 들어, "DB 테이블을 절대 삭제하지 마라"고 프롬프트에 적는 것은 Prompt Engineering 방식이다. Harness Engineering 방식은 pre-commit hook을 사용해 변경된 코드에 DB 삭제 구문이 포함되어 있으면 커밋 자체가 실패하도록 강제하는 것이다. 규칙을 지키도록 요청하는 것이 아니라, 어기는 것이 불가능한 구조를 만드는 것이다.

4. Agentic Engineering

에이전트가 자율적으로 복잡한 작업을 수행할 수 있도록 설계하는 기술이다. 단일 LLM 호출이 아니라, 여러 에이전트가 역할을 나누어 협력하거나 작업을 반복·검증하는 파이프라인을 구성하는 것이 핵심이다.

Vibe Coding과 Agentic Engineering의 가장 큰 차이는 테스트다. 견고한 테스트 스위트가 있으면 AI 에이전트는 테스트가 통과할 때까지 스스로 반복하며, 그 결과에 높은 확신을 가질 수 있다. — Google Chrome Team

Harness Engineering을 깊이 이해해야 하는 이유

네 가지 축 중에서 현재 가장 주목받고 있으며, 실무 적용에서 가장 큰 변화를 만드는 영역이 Harness Engineering이다.

구성 요소 네 가지

기계가 읽는 컨텍스트 파일 코드 저장소 안에 AI가 읽고 따르는 런타임 설정 파일을 배치한다. CLAUDE.md, AGENTS.md, .cursorrules 등이 해당한다. 다만, 컨텍스트에 제약을 제공해도 이를 어기는 경우가 발생한다는 점을 전제로 해야 한다.

결정론적 CI/CD 게이트 AI 출력물이 반드시 통과해야 하는 자동화된 품질 관문이다. 린터, pre-commit hook, 구조 테스트 규칙으로 규칙 준수를 강제한다.

명시적 도구 경계 AI가 접근할 수 있는 파일, API, DB 시스템의 범위를 명확히 제한한다. 권한을 구조적으로 설정하면 모델이 아예 해당 영역에 접근하지 못하도록 차단할 수 있다.

지속적 피드백 루프 실패를 자동으로 감지하고, 규칙을 정제하며, 하네스 구조를 지속적으로 발전시킨다. Garbage Collection, 규칙 위반 감지, 자동 리팩토링, 아키텍처 체크를 주기적으로 실행하고 보완하는 구조가 필요하다.

하네스 시스템의 작동 단계

분류기: 요청의 성격을 판별한다. 단순 질의인지, 실제 코드 작업인지.
컨텍스트 관리자: 필요한 파일과 규칙만 선별해서 제공한다.
실행 루프: 테스트를 통과할 때까지 자동으로 반복 실행한다.
워커 격리: 코드를 작성하는 AI와 코드를 검토하는 AI를 분리해 이중 검증한다.

Hook의 네 가지 유형

Hook은 하네스 시스템의 핵심 작동 기제다.

유형 동작 시점 실전 예시

Pre-action	에이전트가 행동하기 전	코드 저장 전 lint 자동 실행
Post-action	에이전트가 행동한 후	커밋 후 자동 테스트 실행
Validation	에이전트 출력의 품질 검증	보안 취약점 스캔
Notification	특정 조건 충족 시	비용 임계치 초과 경고

Claude Code는 이미 이 구조 위에서 동작하고 있다. 파일 변경 시 관련 테스트가 자동 실행되고, package.json 수정 시 의존성 충돌을 검사하며, 보안 관련 파일 수정 시 보안 리뷰 에이전트가 자동으로 호출된다.

OpenAI의 실험이 보여준 것

OpenAI는 "수동으로 코드를 한 줄도 작성하지 않고 소프트웨어 제품을 만든다"는 의도적 제약을 설정하고 실제 프로젝트를 개발하는 실험을 진행했다. 3~7명의 인원이 약 5개월간 100만 줄의 코드를 작성했고, 이는 기존 대비 약 10배에 달하는 생산성이었다.

초기 진행이 예상보다 더뎠던 이유는 에이전트의 역량이 부족해서가 아니었다. 환경이 제대로 갖춰지지 않았기 때문이었다. 에이전트가 상위 목표를 달성하기 위한 도구, 추상화, 내부 구조가 부족했고, 팀의 주요 업무는 에이전트가 유용한 작업을 수행할 수 있도록 그 환경을 만드는 것으로 전환되었다.

이 실험에서 도출된 핵심 통찰은 다음과 같다.

역할의 분리가 명확해졌다.

인간: 의도 정의, 시스템 설계, 제약 설정
AI: 코드 생성, 테스트, 리뷰, 수정 실행

중요한 것은 프롬프트가 아니라 구조다. 단순히 프롬프트를 잘 작성하는 것이 아니라, 저장소 구조, 문서 구조, 테스트 시스템, CI/CD, lint 규칙, Observability, 에이전트 워크플로우 전체를 설계하는 능력이 요구된다.

코드 가독성의 기준이 바뀌고 있다. 기존에는 옆에 있는 동료 개발자가 이해하기 쉬운 코드를 작성하는 것이 목표였다. 지금은 에이전트가 이해하고 자동으로 수정·검증할 수 있는 코드가 좋은 코드의 기준이 되고 있다.

모든 의사결정은 문서로 남아야 한다. 머릿속이나 구두로만 이루어지는 의사결정은 AI 시스템에서 의미가 없다. 규칙이 적용된 문서에 기록되어야 에이전트가 참조할 수 있다. 구조적이고 규칙적으로 정리하는 능력이 중요해졌다.

하네스 엔지니어링 설계 시 주의할 점

현장에서 실제로 구현할 때 반드시 염두에 두어야 할 사항들이다.

큰 instruction 하나는 실패한다. 작고 연결된 문서 구조를 만들어, 필요할 때 필요한 정보만 참조할 수 있도록 Knowledge Graph 형태로 구성해야 한다.
Single Source of Truth 원칙을 지켜야 한다. 정보가 외부 문서, Slack, 담당자의 머릿속 등에 파편화되어 있으면 에이전트는 일관되게 작동할 수 없다.
강한 구조적 제약이 필요하다. 아키텍처, lint 규칙, 폴더 구조, 접근 권한 설정은 선택이 아닌 필수다.
리뷰도 에이전트가 수행한다. 리뷰 루프 자체가 자동화되는 방향으로 설계해야 한다.
AI에게 관찰 능력을 제공해야 한다. QA 병목을 해소하려면 Playwright, UI 스냅샷, 로그, 메트릭, trace 등 에이전트가 스스로 확인할 수 있는 도구를 갖춰야 한다.
피드백 루프가 핵심이다. "실행 → 관찰 → 평가 → 수정 → 반복"이 자동으로 작동한다면, 인간의 개입 없이도 기능 개발이 가능해진다.
개발 속도와 안정성의 균형이 재조정되고 있다. 기존에는 안정성 우선으로 코드 리뷰가 길게 이루어졌다. 현재는 속도를 우선하고, 문제가 생기면 빠르게 수정하는 방향으로 바뀌고 있다. AI를 활용하면 수정 비용이 거의 0에 가까워지기 때문이다.
Garbage Collection 설계가 필요하다. AI는 기존 패턴에 잘못된 것이 하나 들어가면 지속적으로 코드를 오염시킨다. 이를 자동으로 감지하고 정리하는 메커니즘이 반드시 필요하다.

시니어 개발자에게 요구되는 변화

이 흐름 속에서 시니어 개발자에게 요구되는 역량은 다음과 같이 정리된다.

문제를 구조화하는 능력과 시스템 설계 능력 AI가 이해하고 수행할 수 있도록 문제를 작게 쪼개고, 명세를 정확하게 작성하는 능력이 핵심 역량이 되었다.

좋은 코드의 기준 재정의 AI가 이해하기 쉽고, 자동 수정 및 검증이 가능한 코드가 좋은 코드다.

핵심 스킬의 변화 아키텍처 강제력 설계, 규칙 설계, 피드백 루프 설계, Observability 구축, 명세 작성 능력이 중요해지고 있다.

마인드셋의 전환 "내가 직접 해결한다"에서 "시스템이 해결하게 만든다"로의 전환이 필요하다. 이것이 이 시대 엔지니어에게 요구되는 가장 근본적인 변화다.

AI 에이전트는 이미 현장에 들어와 있다. 이 변화에서 살아남는 개발자는 코딩을 가장 잘하는 사람이 아니라, AI가 가장 잘 일할 수 있는 환경을 설계하는 사람일 가능성이 높다.

AI 에이전트 시대, 설계와 TDD의 종말인가 진화인가?

D.Y — Fri, 3 Apr 2026 10:11:20 +0900

소프트웨어 개발 패러다임이 급격하게 변하고 있다. AI 에이전트의 발전은 '코드를 작성하는 비용'을 비약적으로 낮추었으며, 이는 기존의 개발 방법론에 대한 근본적인 의문을 제기한다. 특히 설계 중심의 개발이나 테스트 주도 개발(TDD)이 여전히 유효한가에 대한 논의는 현시점 모든 개발자가 마주한 화두다.

결론부터 말하자면, 코드는 저렴해졌으나 설계의 가치는 오히려 상승했으며, TDD는 방법론적 '절차'에서 전략적 '선택'으로 진화하고 있다.

1. 코드 생산 비용의 급감과 가치의 이동
과거의 개발 프로세스에서 구현, 리팩토링, 테스트 코드 작성은 상당한 시간과 비용이 투입되는 영역이었다. 그러나 AI 에이전트의 등장으로 구현 비용은 분 단위로 단축되었고, 리팩토링과 테스트 생성 역시 자동화의 영역으로 들어왔다.

이제 '어떻게 구현할 것인가(How)'에 대한 기술적 숙련도의 중요도는 낮아지고 있다. 대신 '무엇을 해결할 것인가(What)'에 대한 문제 정의 역량이 개발자의 핵심 가치로 부상했다. 즉, 코드 그 자체보다 시스템의 목적과 방향성을 설정하는 능력이 더욱 중요해진 것이다.

2. 설계의 재정의: 구현 상세에서 경계 설계로
AI가 코드를 빠르게 양산할수록 시스템의 복잡도는 기하급수적으로 증가한다. 일관성 없는 구조, 모듈 간 경계의 모호함, 중복 로직의 범람은 AI가 가진 '국소 최적화'의 한계에서 기인한다. 시스템 전체의 일관성을 유지하는 능력은 여전히 인간 개발자의 영역에 머물러 있다.

현대적 설계의 핵심은 클래스 내부의 상세 구현을 고민하는 것이 아니다. 도메인 모델을 정립하고, 서비스 간의 책임과 경계(Boundary)를 명확히 획정하며, AI가 준수해야 할 제약 조건을 설계하는 것으로 그 역할이 전이되었다. 즉, 설계는 구현을 위한 밑그림이 아니라 AI라는 강력한 엔진을 제어하는 가이드라인이 되어야 한다.

3. TDD의 전략적 후퇴와 테스트의 질적 변화
모든 기능에 대해 테스트를 먼저 작성하는 전통적인 TDD의 효율성은 확실히 감소했다. AI를 통해 구현과 테스트를 동시에 생성할 수 있게 된 시점에서, Red-Green-Refactor 사이클을 고집하는 것은 자원 낭비일 수 있다.

하지만 테스트 자체의 중요성은 그 어느 때보다 높다. AI가 작성한 코드의 신뢰성을 검증하는 '가드레일'로서의 역할이 필수적이기 때문이다.

- TDD의 선별적 도입: 모든 영역이 아닌, 금융/정산 등 정합성이 치명적인 핵심 도메인 로직이나 버그 발생 비용이 큰 영역으로 TDD의 적용 범위를 한정해야 한다.
- 테스트 전략의 고도화: 단순히 Happy Path를 검증하는 것을 넘어, AI가 놓치기 쉬운 Edge Case를 식별하고 시스템의 행동 명세를 정의하는 '전략적 검증'에 집중해야 한다.

4. AI 시대, 개발자의 핵심 역량
앞으로의 개발자에게 요구되는 전문성은 다음의 네 가지로 요약된다.

1. 문제 구조화 능력: 모호한 비즈니스 요구사항을 AI가 이해할 수 있는 명확한 구조로 치환하는 능력.
2. 경계 설계 역량: 시스템의 응집도를 높이고 결합도를 낮추는 아키텍처 설계 및 책임 분리 능력.
3. 검증 전략 수립: 투자 대비 효율(ROI)이 높은 지점을 포착하여 집중적으로 검증하는 판단력.
4. 코드 리뷰 및 감별: AI가 생성한 결과물에서 잠재적인 결함과 구조적 결을 읽어내는 안목.

결론: 효율을 넘어 본질로
"설계와 TDD가 불필요해졌다"는 진단은 오판이다.

"설계는 더 고도화되었고, TDD는 고정된 규범에서 상황에 따른 고급 전략으로 변화했다"고 생각한다.

코드 작성이 쉬워진 만큼 개발자는 더 높은 차원의 사고에 집중할 수 있는 여력을 얻었다. 구현의 늪에서 벗어나 시스템의 본질을 설계하고, 어디가 깨질 것인지를 예측하며, 전체적인 흐름을 제어하는 '시스템 아키텍트'로서의 면모를 갖추는 것이 AI 시대 개발자가 생존하고 증명해야 할 전문성이다.

Flyway - DB 마이그레이션 전략

D.Y — Thu, 26 Mar 2026 13:55:48 +0900

들어가며

데이터베이스 스키마 변경은 애플리케이션 개발에서 피할 수 없는 일이다. 문제는 이 변경을 어떻게 관리하느냐에 있다. Flyway는 데이터베이스 스키마 변경을 코드처럼 버전 관리할 수 있게 해주는 오픈소스 DB 마이그레이션 도구로, 개발팀이 DB 구조 변경 사항을 체계적으로 추적하고 모든 환경에 일관되게 적용할 수 있도록 설계되었다.

1. 왜 Flyway가 필요한가

DB를 수동으로 관리하는 조직에서는 다음과 같은 문제가 반복적으로 발생한다.

문제 설명

스키마 불일치	팀원마다 로컬 DB가 달라 "내 환경에서는 정상 동작한다"는 상황이 발생한다
수동 실행 의존	SQL을 직접 공유하거나 문서화해야 하며, 누락 위험이 상존한다
이력 불투명	특정 테이블이 언제, 왜 변경되었는지 추적이 불가능하다
환경 재현 불가	신규 팀원 온보딩이나 서버 셋업 시 스키마를 일치시키기 어렵다

Flyway는 이 문제들에 대해 명쾌한 해법을 제시한다. 모든 DB 변경을 번호가 붙은 SQL 파일로 관리하고, 애플리케이션 실행 시 자동으로 순서대로 적용하는 것이다. 즉, DB 변경 사항이 곧 SQL 파일이고, 이 파일은 Git으로 관리된다.

2. 핵심 개념

마이그레이션 파일 네이밍 규칙

V{버전}__{설명}.sql

실제 프로젝트에서는 다음과 같은 구조가 된다.

db/migration/
├── V1__init_schema.sql
├── V2__add_user_table.sql
├── V3__add_email_column.sql
└── V4__add_index_on_email.sql

버전 번호는 반드시 유니크해야 하며, 접두사와 설명 사이의 언더스코어는 두 개(__)라는 점에 유의해야 한다. 사소해 보이지만, 실무에서 한 개만 사용하여 마이그레이션이 인식되지 않는 실수가 의외로 빈번하다.

마이그레이션 파일 종류

접두사 이름 특징 예시

V	Versioned	한 번만 실행되며, 주력으로 사용한다	V1__create_table.sql
U	Undo	롤백 용도 (유료 기능)	U1__drop_table.sql
R	Repeatable	내용이 변경되면 재실행된다	R__create_view.sql

실무에서는 V 접두사 파일이 대부분을 차지한다. R 접두사는 뷰(View)나 저장 프로시저처럼 매번 재생성해도 무방한 객체에 적합하다. U 접두사의 Undo 기능은 유료 플랜에서만 제공되므로, 무료 버전을 사용하는 경우 롤백 전략을 별도로 수립해야 한다.

flyway_schema_history 테이블

Flyway는 자체적으로 이력 관리 테이블을 생성하여 어떤 마이그레이션이 언제, 어떤 순서로 적용되었는지를 기록한다.

installed_rank version description script checksum success

1	1	init schema	V1__init_schema.sql	12345678	true
2	2	add user table	V2__add_user_table.sql	87654321	true
3	3	add email column	V3__add_email_column.sql	11223344	true

여기서 주목할 것은 checksum 컬럼이다. Flyway는 각 파일의 체크섬을 저장해두고, 이미 적용된 파일이 사후에 변경되면 즉시 오류를 발생시킨다. 이 메커니즘이 마이그레이션 이력의 무결성을 보장하는 핵심 장치이다.

3. 동작 방식

최초 실행

앱 시작
  -> Flyway가 flyway_schema_history 테이블 부재를 확인
  -> 테이블을 자동 생성
  -> db/migration 폴더에서 V*.sql 파일을 탐색
  -> 버전 순서대로 SQL을 실행
  -> 각 실행 결과를 history 테이블에 기록

두 번째 이후 실행

앱 시작
  -> flyway_schema_history 테이블을 확인
  -> 이미 실행된 파일은 건너뜀
  -> 새로 추가된 파일만 실행
  -> 실행 완료 후 history에 기록

이 구조 덕분에 개발자는 새로운 마이그레이션 파일만 추가하면 된다. Flyway가 "어디까지 실행했는지"를 알고 있으므로, 나머지는 자동으로 처리된다.

파일 변조 감지

기존 V2__add_user_table.sql의 내용을 수정
  -> Flyway가 체크섬 불일치를 감지
  -> ERROR: Migration checksum mismatch!
  -> 앱 실행을 중단

이 동작은 의도된 설계이다. 한번 적용된 마이그레이션을 사후에 수정하는 것은 환경 간 스키마 불일치를 초래하므로, Flyway는 이를 원천적으로 차단한다.

4. Spring Boot 연동

Spring Boot 프로젝트에서 Flyway를 도입하는 과정은 놀라울 정도로 간결하다.

의존성 추가 (build.gradle)

implementation 'org.flywaydb:flyway-core'

마이그레이션 파일 배치

src/main/resources/db/migration/
├── V1__init_schema.sql
├── V2__add_user_table.sql
└── V3__add_email_column.sql

application.yml 설정

spring:
  flyway:
    enabled: true
    locations: classpath:db/migration
    baseline-on-migrate: true    # 기존 DB에 처음 Flyway를 적용할 때
    out-of-order: false           # 버전 순서를 강제한다
    validate-on-migrate: true     # 체크섬 검증을 활성화한다

baseline-on-migrate 옵션은 이미 운영 중인 DB에 Flyway를 사후 도입할 때 필수적인 설정이다. 이 옵션이 true이면 Flyway는 현재 DB 상태를 기준선(baseline)으로 설정하고, 이후 추가되는 마이그레이션만 실행한다. 신규 프로젝트라면 이 옵션 없이 시작해도 무방하다.

Spring Boot에서는 애플리케이션 시작 시 마이그레이션이 자동으로 실행되므로, 별도의 수동 개입이 필요하지 않다.

5. 주요 CLI 명령어

명령어 설명

flyway migrate	미실행 마이그레이션을 순서대로 실행한다
flyway info	현재 마이그레이션 상태를 조회한다
flyway validate	파일 변조 여부 및 체크섬을 검증한다
flyway repair	실패한 마이그레이션 이력을 수정한다
flyway baseline	기존 DB를 특정 버전 기준으로 초기화한다
flyway clean	모든 테이블을 삭제한다 (운영 환경에서는 절대 사용 금지)

repair 명령어는 마이그레이션 실행 중 오류가 발생하여 history 테이블에 실패 기록이 남았을 때 유용하다. 원인을 해결한 후 repair로 실패 이력을 정리하고, migrate를 다시 실행하는 것이 일반적인 복구 절차이다.

6. 실무 주의사항

Flyway를 운영하면서 체감한 규칙들을 정리한다.

기존 파일은 절대 수정하지 않는다. 체크섬 불일치로 애플리케이션 기동이 실패한다. 수정이 필요하면 반드시 새 버전 파일을 추가한다.
버전 번호는 유니크하게 유지한다. 동일한 버전 번호를 가진 파일이 두 개 이상 존재하면 오류가 발생한다. 여러 개발자가 동시에 작업할 경우, 타임스탬프 기반 버전 번호(예: V20260326_1430__description.sql)를 사용하면 충돌을 줄일 수 있다.
flyway clean은 운영 환경에서 절대 사용하지 않는다. 이 명령은 모든 테이블을 삭제한다. Spring Boot 설정에서 spring.flyway.clean-disabled=true를 운영 프로파일에 명시해 두는 것이 안전하다.
DB 접속 정보를 마이그레이션 파일이나 설정 파일에 직접 노출하지 않는다. 환경 변수나 Vault를 통해 주입하는 방식을 사용한다.
마이그레이션 파일에는 DDL만 포함하는 것을 원칙으로 한다. DML(데이터 조작)이 필요한 경우, 해당 파일의 설명에 데이터 변경임을 명시하고 트랜잭션 안전성을 반드시 확인한다.

7. Flyway vs Liquibase

DB 마이그레이션 도구를 선정할 때 Flyway와 함께 거론되는 것이 Liquibase이다.

항목 Flyway Liquibase

문법	SQL 위주로 직관적이다	XML, YAML, JSON, SQL을 모두 지원한다
학습 곡선	낮다	상대적으로 높다
롤백	유료 플랜에서 제공한다	무료로 지원한다
커뮤니티	활발하다	활발하다
적합한 상황	소~중규모 프로젝트에서 빠르게 도입할 때	복잡한 엔터프라이즈 환경에서

Flyway의 장점은 SQL을 그대로 사용한다는 점이다. 별도의 DSL을 학습할 필요 없이, DBA가 작성한 SQL을 그대로 마이그레이션 파일로 사용할 수 있다. 반면 Liquibase는 DB 벤더에 독립적인 추상화 레이어를 제공하므로, 다중 DB를 지원해야 하는 환경에서는 Liquibase가 더 적합할 수 있다.

마치며

Flyway의 본질은 단순하다. "DB 변경을 파일로 만들고, 순서대로 실행하고, 한번 실행한 것은 건드리지 않는다." 이 세 가지 원칙만 지키면 환경 간 스키마 불일치, 변경 이력 추적 불가, 수동 배포 의존이라는 고질적인 문제에서 벗어날 수 있다.

참고 자료

DB에 JSON 데이터를 저장하는 두 가지 방법: JSON 타입 vs TEXT 타입

D.Y — Thu, 26 Mar 2026 13:31:49 +0900

문제의 출발점

애플리케이션에서 구조화된 데이터를 하나의 컬럼에 통째로 저장해야 하는 경우가 있다. 설정값, 메타데이터, 가변적인 속성 목록 등이 대표적이다. 이때 선택지는 크게 두 가지로 나뉜다.

데이터베이스가 제공하는 JSON/JSONB 타입을 사용하는 방법
일반 TEXT 타입에 JSON 문자열을 그대로 저장하는 방법

두 방식 모두 현업에서 널리 쓰이며, 어느 쪽이 절대적으로 우월하다고 말하기는 어렵다. 상황에 따라 적합한 선택이 달라지기 때문이다.

JSON/JSONB 타입으로 저장하는 경우

개요

PostgreSQL의 jsonb, MySQL 8.0+의 JSON 등 주요 RDBMS는 JSON 전용 컬럼 타입을 지원한다. 단순히 문자열로 저장하는 것이 아니라, DB 엔진이 JSON 구조를 인식하고 파싱한 상태로 보관한다.

장점

1. 데이터 무결성 보장

INSERT/UPDATE 시점에 DB가 JSON 유효성을 자동으로 검증한다. 잘못된 형식의 데이터가 저장되는 것 자체를 원천 차단할 수 있다. TEXT 타입에서는 애플리케이션 레이어에서만 이를 검증할 수 있으므로, 버그나 직접 SQL 실행 등으로 잘못된 데이터가 유입될 가능성이 존재한다.

2. JSON 내부 필드 쿼리

JSON 내부의 특정 키에 대해 직접 조건절을 작성할 수 있다.

-- PostgreSQL 예시: 변수 목록에서 type이 'FORMULA'인 step 조회
SELECT * FROM recipe_steps
WHERE variable_metadata::jsonb @> '[{"type": "FORMULA"}]';

TEXT 타입에서는 LIKE '%FORMULA%'와 같은 문자열 패턴 매칭에 의존해야 하며, 이는 정확도와 성능 양면에서 불리하다.

3. 인덱싱 지원

PostgreSQL의 jsonb는 GIN 인덱스를 생성할 수 있어, JSON 내부 필드에 대한 검색 성능을 크게 향상시킬 수 있다.

CREATE INDEX idx_variable_metadata ON recipe_steps
USING GIN (variable_metadata jsonb_path_ops);

4. 저장 공간 효율 (JSONB 한정)

PostgreSQL jsonb는 바이너리 형태로 저장하므로, 키 중복 제거와 압축이 적용되어 TEXT 대비 저장 공간이 절약된다. 또한 읽기 시 파싱 비용이 들지 않는다.

단점

1. DB 간 호환성 부족

JSON 타입의 문법과 기능은 DB 벤더마다 상이하다. PostgreSQL의 jsonb 연산자(->, ->>, @>)는 MySQL이나 H2에서 동작하지 않는다. 테스트 환경에서 H2를 사용하고 운영에서 PostgreSQL을 사용하는 경우, JSON 타입 컬럼은 호환성 문제를 일으킨다.

2. ORM 매핑의 복잡성

JPA/Hibernate에서 jsonb 컬럼을 매핑하려면 별도의 설정이 필요하다. @JdbcTypeCode(SqlTypes.JSON) 어노테이션을 사용하거나, hypersistence-utils 같은 서드파티 라이브러리를 추가해야 한다. 단순한 String 필드에 columnDefinition = "TEXT"를 지정하는 것에 비하면 진입 장벽이 높다.

3. 쓰기 성능 오버헤드

jsonb는 저장 시 파싱과 바이너리 변환 과정을 거치므로, 단순 TEXT 저장보다 쓰기 비용이 높다. 빈번한 갱신이 발생하는 컬럼에서는 이 차이가 누적될 수 있다.

TEXT 타입으로 저장하는 경우

개요

JSON 문자열을 있는 그대로 TEXT 컬럼에 저장하는 방식이다. DB 입장에서는 일반 문자열과 다를 바 없으며, JSON 파싱과 검증은 전적으로 애플리케이션의 책임이 된다.

장점

1. DB 독립성

TEXT는 모든 RDBMS에서 동일하게 지원된다. 운영 DB와 테스트 DB가 다른 벤더를 사용하더라도 문제가 없다. 예를 들어, 운영에서 PostgreSQL을 쓰고 테스트에서 H2 인메모리 DB를 쓰는 구조에서 TEXT 컬럼은 아무런 호환성 이슈 없이 동작한다.

2. ORM 매핑의 단순함

Java의 String 필드에 @Column(columnDefinition = "TEXT")만 선언하면 끝이다. 별도의 타입 변환기, 서드파티 라이브러리, DB별 방언 설정이 전혀 필요 없다.

@Column(name = "variable_metadata", columnDefinition = "TEXT")
private String variableMetadata;

3. 쓰기 성능

파싱이나 바이너리 변환 없이 문자열을 그대로 저장하므로 쓰기 속도가 빠르다.

4. 유연성

DB가 JSON 구조를 강제하지 않으므로, 스키마 변경 없이 JSON 구조를 자유롭게 변경할 수 있다. 과도기적 데이터 마이그레이션 시에도 유연하게 대처할 수 있다.

단점

1. 무결성 미보장

DB는 컬럼에 어떤 문자열이 들어오든 허용한다. 잘못된 JSON, 빈 문자열, HTML 등이 저장되어도 DB 레벨에서 막을 수 없다. 데이터 품질은 전적으로 애플리케이션 코드에 의존하게 된다.

2. 내부 필드 검색 불가

JSON 내부의 특정 키를 조건으로 검색하려면 LIKE 또는 정규식을 사용해야 하며, 이는 정확성도 낮고 인덱스를 활용하지 못한다.

3. 읽기 시 파싱 비용

매번 조회할 때마다 애플리케이션에서 JSON 파싱을 수행해야 한다. jsonb는 이미 파싱된 상태로 저장되므로 읽기 시 추가 비용이 없지만, TEXT는 매번 ObjectMapper.readValue() 등을 호출해야 한다.

비교 요약

기준 JSON/JSONB 타입 TEXT 타입

DB 레벨 유효성 검증	O	X
내부 필드 쿼리	O	X
GIN 인덱스	O	X
DB 간 호환성	제한적	완전 호환
ORM 매핑 복잡도	높음	낮음
쓰기 성능	상대적으로 느림	빠름
읽기 시 파싱 비용	없음 (이미 파싱)	매번 파싱 필요
저장 공간 효율	좋음 (JSONB)	보통

어떤 경우에 무엇을 선택할 것인가

TEXT가 적합한 경우

데이터를 통째로 읽고 쓰기만 하고, DB에서 JSON 내부를 쿼리할 일이 없는 경우
운영 DB와 테스트 DB가 다른 벤더를 사용하며, 호환성이 중요한 경우
ORM 설정을 단순하게 유지하고 싶은 경우
JSON 스키마가 자주 변경되는 초기 개발 단계

JSON/JSONB가 적합한 경우

DB 레벨에서 JSON 내부 필드를 조건으로 검색해야 하는 경우
데이터 무결성이 비즈니스 요구사항 수준에서 중요한 경우 (예: 규제 환경)
동일 DB 벤더를 운영/테스트 모두에서 사용하는 경우
저장된 JSON이 크고, 부분 읽기/업데이트가 필요한 경우

실무 적용 사례

EBR(Electronic Batch Record) 시스템에서는 레시피 단계(Step)별 변수 목록을 variable_metadata 컬럼에 JSON 배열로 저장하고 있다. 이 필드는 다음과 같은 특성을 가진다.

Step 단위로 통째로 읽고 쓴다
DB에서 JSON 내부를 쿼리하지 않는다
운영은 PostgreSQL, 테스트는 H2를 사용한다

이러한 조건에서 TEXT 타입은 합리적인 선택이다. H2 호환성을 유지하면서 ORM 매핑을 단순하게 가져갈 수 있기 때문이다. 만약 향후 "특정 타입의 변수를 포함하는 Step을 검색"하는 요구사항이 발생한다면, 그때 jsonb로 전환하는 것이 YAGNI 원칙에도 부합하는 접근이다.

결론

JSON 데이터의 저장 방식은 "정답"이 아니라 "맥락에 따른 선택"의 문제이다.

DB가 JSON을 이해할 필요가 있는가, 여러 DB 벤더를 지원해야 하는가, ORM 복잡도를 얼마나 감수할 수 있는가 이 세 가지 질문에 대한 답이 선택의 기준이 된다. 현재 필요하지 않은 기능을 위해 복잡성을 도입하기보다는, 실제 요구사항이 발생했을 때 전환하는 편이 대부분의 경우 더 나은 전략이다.

[주간 IT 동향] 2026-03-16 ~ 03-19: NVIDIA GTC 2026 총정리, Groq 3 LPU 공개, 에이전트 보안의 "Sudo 레이어"

D.Y — Fri, 20 Mar 2026 09:18:33 +0900

TL;DR

NVIDIA GTC 2026 키노트에서 Jensen Huang이 Blackwell+Vera Rubin 주문량이 2027년까지 1조 달러에 달할 것으로 전망했다. 지난해 5,000억 달러 전망의 2배다
Groq 3 LPU가 NVIDIA 최초의 추론 전용 칩으로 공개되었다. 200억 달러에 인수한 Groq 기술을 기반으로, Vera Rubin GPU 옆에 256개 LPU를 탑재하는 LPX 랙이 Q3에 출하된다
NemoClaw가 OpenClaw의 엔터프라이즈 레퍼런스 스택으로 발표되면서, NVIDIA가 에이전트 경제의 인프라 레이어를 장악하려는 전략이 명확해졌다
AI 에이전트에 "Sudo 레이어"를 구축해야 한다는 주장이 등장했다. Regex 기반 필터링의 한계를 넘어, 결정론적(deterministic) 권한 통제가 에이전트 보안의 핵심 패턴으로 부상하고 있다
OpenSearch 3.5가 agentic conversation memory를 지원하면서, 에이전트 워크로드를 위한 데이터 인프라가 빠르게 진화하고 있다

1. NVIDIA GTC 2026: 에이전트 경제의 인프라를 선점하다

이번 주 IT 업계의 모든 시선이 산호세에 쏠렸다. Jensen Huang의 2시간 키노트는 단순한 제품 발표를 넘어, NVIDIA가 AI 경제의 "운영 레이어"가 되겠다는 전략을 명확히 한 자리였다.

가장 큰 숫자부터 보자. Jensen은 Blackwell과 Vera Rubin 시스템의 주문량이 2027년까지 1조 달러에 달할 것으로 전망했다. 지난해 가을 GTC에서 제시한 5,000억 달러의 정확히 2배다. AI 인프라 투자가 둔화될 것이라는 우려에 대한 NVIDIA의 대답은 "오히려 가속"이었다.

하드웨어 측면에서 가장 주목할 발표는 Groq 3 LPU다. 이것은 NVIDIA가 작년 200억 달러에 인수한 Groq 기술을 기반으로 한 최초의 추론 전용 칩이다. Q3에 출하 예정이며, 256개 LPU를 탑재하는 Groq 3 LPX 랙은 Vera Rubin 랙 옆에 배치되도록 설계되었다. 학습은 GPU, 추론은 LPU라는 이분화된 AI 컴퓨팅 아키텍처가 NVIDIA 내부에서 공식화된 것이다. Google TPU, AMD, 그리고 자체 추론 칩을 개발하는 클라우드 업체들에 대한 NVIDIA의 직접적인 견제다.

Vera Rubin NVLink 72도 무대에 올랐다. Jensen은 "10년간 4,000만 배의 컴퓨팅 증가"라고 표현했고, "초고성능 싱글스레드 AI 성능을 위해 완전히 새로운 CPU를 설계했다"고 밝혔다.

소프트웨어 측면에서는 NemoClaw가 핵심이다. 이것은 OpenClaw를 "엔터프라이즈 레디"로 만들기 위한 레퍼런스 스택이다. Jensen은 "OpenClaw를 찾아서 다운로드하고, AI 에이전트를 빌드해준다"고 설명했다. Nemotron Coalition이라는 오픈 프론티어 모델 연합도 발표되었는데, Perplexity, Reflection, Black Forest Labs 등이 참여한다.

Jensen은 엔지니어에게 연봉과 함께 연간 AI 토큰 예산을 지급하자고 제안했다. 토큰이 전기나 컴퓨팅 자원처럼 핵심 업무 인프라가 되었다는 인식의 전환이다. 실리콘밸리에서 면접 시 "추론 용량을 얼마나 배정받느냐"를 묻는 후보가 늘고 있다는 관측도 나왔다.

2. 에이전트 보안의 새로운 패러다임: "Sudo 레이어"와 OpenShell

이번 주 에이전트 보안 영역에서 두 가지 중요한 논의가 등장했다.

첫째, "Why Regex is Not Enough: Building a Deterministic 'Sudo' Layer for AI Agents"라는 기사다. Claude Code로 오래된 프로젝트를 정리하다가 "디스크가 꽉 찼는데 정리 좀 해줘"라고 프롬프트했더니, 에이전트가 docker system prune을 포함한 공격적인 정리 명령을 제안한 경험에서 출발한다. 핵심 주장은 regex 기반 명령어 필터링으로는 에이전트의 위험한 행동을 막을 수 없다는 것이다. 대신, 리눅스의 sudo처럼 결정론적(deterministic)인 권한 통제 레이어가 필요하다. 에이전트가 특정 임계치를 넘는 행위를 하려면 명시적 승인을 받아야 하는 구조다.

둘째, "NVIDIA OpenShell and the Rise of Agent Sandboxes in Agentic DevOps"라는 기사다. GTC 2026에서 발표된 OpenShell을 에이전트 샌드박스의 맥락에서 분석한다. 에이전트를 베어메탈에서 실행하는 것이 왜 위험한지, 그리고 3계층 방어 아키텍처(instructions, hooks, gates)가 247개 커밋, 100% 테스트 커버리지, 제로 롤백을 달성한 경험을 공유한다. 지난주 Docker NanoClaw + Sandboxes, AWS Nitro Enclaves 레퍼런스와 함께, 에이전트 격리 실행이 "선택"이 아닌 "기본값"이 되어야 한다는 합의가 형성되고 있다.

3. AWS 보안 에이전트와 에이전틱 인프라의 확장

AWS에서 이번 주 주목할 두 가지 업데이트가 있었다.

첫째, AWS Security Agent가 침투 테스트 보고서 다운로드를 지원하기 시작했다. 보고서에는 경영진 요약, 테스트 범위, 방법론, 태스크 상세, 취약점 분석이 포함되며 필터 기반 커스터마이징이 가능하다. 에이전트가 보안 테스트를 자동 수행하고, 그 결과를 사람이 검토 가능한 형태로 산출하는 패턴이 정착되고 있다.

둘째, Amazon Inspector가 에이전트 없는 EC2 스캐닝을 확장하면서 Windows OS 취약점 스캐닝도 지원하게 되었다. WordPress, Apache HTTP Server, Python 패키지, Ruby gems까지 커버리지가 넓어졌다. 에이전트리스(agentless) 보안 스캐닝이 멀티 OS, 멀티 런타임으로 확장되는 추세다.

OpenSearch 3.5도 에이전틱 AI 기능을 대폭 강화했다. Agentic conversation memory가 대화 컨텍스트와 도구 호출 결과를 캡처하면서, 에이전트 워크로드를 위한 검색 엔진으로의 진화를 보여준다. 에이전트가 과거 대화를 기억하고 맥락에 맞는 검색을 수행하는 것이 인프라 레벨에서 지원되기 시작한 것이다.

4. Kubernetes Image Promoter 재작성과 인프라 신뢰성

registry.k8s.io에서 풀하는 모든 컨테이너 이미지는 kpromo(Kubernetes Image Promoter)를 통해 배포된다. 이 도구가 이번 주 대대적으로 재작성되었다. 스테이징에서 프로덕션으로 이미지를 복사하고, cosign으로 서명하고, 20개 이상 리전 미러에 시그니처를 복제하고, SLSA provenance attestation을 생성하는 전 과정이 대상이다.

눈에 보이지 않는 인프라이지만, Kubernetes 생태계 전체의 공급망 보안에 직접 영향을 미치는 핵심 컴포넌트다. 소프트웨어 공급망 보안이 더 이상 선택이 아닌 기본 요구사항이 된 시대에, 이런 "보이지 않는 재작성"이 실제로 가장 중요한 작업인 경우가 많다.

이번 주 주목할 기술 동향

Lambda AZ 메타데이터 지원: Lambda 함수가 실행 중인 Availability Zone ID를 알 수 있게 되면서, same-AZ 라우팅으로 cross-AZ 레이턴시를 줄이는 것이 가능해졌다. 에이전트 워크로드의 지연 최적화에 직접 활용 가능하다.
멀티클라우드 에이전트 배포: VPN 없이 AWS, GCP, Azure에 걸쳐 에이전트를 배포하는 방법이 2줄 명령어로 단순화되는 도구가 등장했다. 크로스클라우드 에이전트 오케스트레이션의 진입장벽이 낮아지고 있다.
Amazon ECR Chainguard Pull Through Cache: 보안 강화된 컨테이너 이미지 공급원으로 Chainguard가 ECR pull through cache에 추가되었다. 컨테이너 공급망 보안의 선택지가 확대된다.
Redshift 신규 쿼리 성능 최대 7배 향상: BI 대시보드, ETL, 그리고 "자율적 목표 추구형 AI 에이전트"의 SQL 쿼리 성능이 크게 개선되었다. AWS가 에이전트 워크로드를 데이터 인프라 최적화의 기준으로 삼고 있다는 신호다.
모바일 DevOps 대시보드: Docker 컨테이너를 폰에서 SSH 없이 관리하는 모바일 대시보드가 등장했다. 저녁 식사 중 Telegram 알림 받고 6인치 화면에서 docker ps 치는 고통에서 해방.

참고 자료

tmux를 사용해서 Claude Code 사용성을 높여보자

D.Y — Fri, 20 Mar 2026 08:56:48 +0900

Claude Code를 로컬 맥 환경에서 처음 쓰는 개발자 대부분은 iTerm2를 열고, 그 안에서 claude 명령어를 실행한다. 작동은 한다. 그러나 iTerm2 창을 닫거나 맥을 재시작하는 순간 진행 중이던 작업 세션과 작업환경은 사라진다. (세션이야 resume 명령어로 다시 불러올 수 있다. 하지만, 작업환경은 사라진다.) 백엔드 엔지니어들이 tmux를 사용하는 본질적인 이유가 바로 여기에 있다.

이 글은 두 개념을 명확히 구분하고, tmux가 왜 생산성을 높이는지, 현업에서 어떻게 쓰이는지를 실제 사례와 함께 설명한다.

1. 개념 구분: 터미널 클라이언트 vs tmux

터미널 클라이언트란 무엇인가

iTerm2, Terminal.app, Warp 같은 도구는 터미널 클라이언트다. 이 도구들의 역할은 단 하나다 — 사용자가 입력한 키스트로크를 셸로 전달하고, 셸의 출력을 화면에 렌더링한다. 마치 텍스트 전용 브라우저와 같다. 브라우저가 HTML을 시각적으로 표현하듯, 터미널 클라이언트는 문자 스트림을 시각적으로 표현한다.

핵심은 이것이다. 터미널 클라이언트는 프로세스를 소유하지 않는다. 창을 닫으면 그 안에서 실행 중이던 프로세스는 종료된다. 창이 곧 세션이고, 세션이 곧 프로세스의 생애 주기다.

tmux란 무엇인가

tmux는 **터미널 멀티플렉서(Terminal Multiplexer)**다. 터미널 클라이언트와 전혀 다른 계층에 존재한다.

tmux는 OS 위에서 독립적인 서버 프로세스로 동작한다. 이 서버가 **세션(session)**을 관리한다. 세션 안에는 여러 **윈도우(window)**가 있고, 하나의 윈도우는 여러 **팬(pane)**으로 분할될 수 있다. 중요한 것은 이 세션이 터미널 클라이언트와 완전히 독립되어 있다는 점이다.

iTerm2로 tmux 세션에 접속(attach)하면, iTerm2는 단순히 그 세션의 출력을 보여주는 뷰어에 불과해진다. iTerm2를 닫아도 tmux 세션은 OS 백그라운드에서 살아 있다. 언제든 다시 접속(re-attach)하면 작업은 그대로다.

비유하자면: iTerm2는 TV이고, tmux는 방송국이다. TV를 꺼도 방송은 계속된다. TV를 다시 켜면 방송을 이어서 볼 수 있다.

2. 왜 tmux가 생산성을 높이는가

백엔드 엔지니어들이 tmux를 사용하는 이유는 단순히 "여러 창을 열 수 있어서"가 아니다. 본질적인 이유는 세 가지다.

세션의 영속성

서버 작업을 하는 백엔드 개발자는 배포, 빌드, 테스트를 원격 서버에서 장시간 실행한다. SSH 연결이 끊기거나 노트북 덮개를 닫아도 작업은 계속 실행되어야 한다. tmux가 없으면 프로세스가 즉시 종료된다. tmux가 있으면 세션이 서버에 살아 있고, 나중에 다시 접속해 결과를 확인한다.

Claude Code 관점에서 이것은 결정적이다. 대규모 코드베이스 분석이나 멀티 스텝 작업을 Claude Code에게 맡겨 놓고 자리를 비울 수 있다. 맥 화면이 꺼지거나 iTerm2가 강제 종료되어도 작업은 계속 진행된다.

컨텍스트 전환 비용 제거

일반적인 개발 흐름을 생각해보자. Claude Code로 코드를 생성하면서, 동시에 Git 로그를 확인하고, 서버 로그를 모니터링하고, 테스트를 실행해야 한다. iTerm2만 사용하면 각 작업마다 탭을 전환하거나 창을 새로 열어야 한다. 멘탈 컨텍스트가 분산된다.

tmux에서는 단일 화면을 여러 팬으로 분할한다. 왼쪽에 Claude Code, 오른쪽 위에 파일 트리, 오른쪽 아래에 테스트 결과가 동시에 보인다. 물리적으로 같은 화면에 모든 컨텍스트가 존재한다.

작업 단위의 격리

프로젝트별로 tmux 세션을 분리하면 작업 단위가 명확해진다. ebs-backend 세션에서는 EBR 시스템 개발만, devops 세션에서는 인프라 작업만 진행한다. 세션을 전환하는 것은 프로젝트를 전환하는 것이다. 각 세션의 상태는 완전히 독립적으로 보존된다.

3. 현업 개발자들은 tmux를 어떻게 사용하는가

기본 구조 설계

현업에서 사용하는 tmux 구조는 대체로 다음 패턴을 따른다.

세션: project-name
  ├── window 0: main     — Claude Code 실행
  ├── window 1: git      — git 작업, 브랜치 관리
  ├── window 2: server   — 개발 서버 실행
  └── window 3: logs     — 서버 로그 모니터링

하나의 프로젝트가 하나의 세션이다. 세션 안의 윈도우는 역할로 구분한다.

필수 단축키 (실전 기준)

tmux의 모든 명령은 프리픽스 키 이후에 입력한다. 기본값은 Ctrl + b다.

작업단축키

새 세션 생성	tmux new -s project-name
세션 목록 확인	tmux ls
세션 재접속	tmux attach -t project-name
새 윈도우	Ctrl+b c
다음 윈도우	Ctrl+b n
화면 수직 분할	Ctrl+b %
화면 수평 분할	Ctrl+b "
팬 간 이동	Ctrl+b 방향키
세션 분리 (detach)	Ctrl+b d

현업 개발자 대부분은 Ctrl+b 대신 Ctrl+a로 프리픽스를 재설정한다. ~/.tmux.conf에 한 줄 추가로 변경 가능하다.

# ~/.tmux.conf
set-option -g prefix C-a
unbind-key C-b
bind-key C-a send-prefix

Claude Code와 함께하는 실전 워크플로우

아침에 맥을 켰을 때 tmux를 사용하는 개발자의 루틴은 다음과 같다.

# 어제 작업하던 세션으로 복귀
tmux attach -t ebs-backend

# → 어제 실행 중이던 Claude Code가 그대로 실행 중
# → git 윈도우에는 어제 마지막 커밋 상태가 그대로
# → 서버 로그 윈도우에는 밤새 발생한 로그가 쌓여 있음

세션을 새로 만드는 것이 아니라, 어제 작업 상태로 그대로 복귀한다. 이것이 tmux 사용자와 비사용자의 첫 번째 차이다.

4. 대표 사례: Claude Code 멀티 에이전트 작업

다음은 Claude Code를 tmux와 함께 사용할 때 나타나는 대표적인 패턴이다.

시나리오: EBR 시스템의 API 레이어와 DB 스키마를 동시에 작업한다.

# 세션 생성
tmux new -s ebr-dev

# window 0: orchestrator Claude Code
claude --model claude-opus-4-6

# Ctrl+b c → window 1 생성: subagent Claude Code
claude --model claude-sonnet-4-6

# Ctrl+b c → window 2 생성: 파일 변경 감시
watch -n 2 'git diff --stat'

# Ctrl+b c → window 3 생성: 테스트 자동 실행
pytest --watch

Opus가 전체 아키텍처를 설계하는 동안, Sonnet이 개별 컴포넌트를 구현한다. watch가 파일 변경을 실시간으로 보여주고, pytest가 변경 즉시 테스트를 돌린다. 이 모든 것이 단일 터미널 화면에서, 세션이 끊기지 않고, 동시에 진행된다.

iTerm2만 사용했다면 이 중 어느 하나에 집중할 때 나머지 세 개의 컨텍스트를 탭 전환으로 잃어가며 작업해야 했을 것이다.

정리

터미널 클라이언트는 화면을 렌더링하는 도구다. tmux는 세션을 관리하는 OS 레벨 서버다. 이 둘은 같은 계층에 있지 않다.

tmux가 백엔드 엔지니어 사이에서 표준으로 자리 잡은 이유는 화려한 기능 때문이 아니다. 세션의 영속성, 컨텍스트의 동시 가시성, 작업 단위의 격리 — 이 세 가지가 장시간 복잡한 작업을 수행하는 개발자의 흐름을 유지시키기 때문이다.

Claude Code를 진지하게 사용한다면, tmux는 선택이 아니라 인프라다.

AI 에이전트 팀으로 개발 업무 자동화(daily-todo-workflow 설계기)

D.Y — Wed, 18 Mar 2026 16:07:37 +0900

시작하기 전에: 이 글의 목적

이 글은 Claude Code의 커스텀 스킬 기능을 활용하여 개발자의 일상적인 반복 업무를 AI 에이전트 팀이 자동으로 처리하도록 설계한 daily-todo-workflow의 탄생 배경, 핵심 아키텍처, 그리고 실제 운용 과정에서 마주한 문제를 v2로 어떻게 해결했는지에 대해 기록한 글이다.

단순한 스크립트 자동화 이야기가 아니다. 이것은 AI가 기존 개발 방식의 협업 구조를 어떻게 재해석할 수 있는가에 대한 구조적 실험의 기록이다.

1. 왜 만들었는가

반복되는 컨텍스트 전환

개발자의 하루는 흔히 TODO 목록 작성으로 시작된다. (데일리 스프린트를 한다거나..)

그러나 그 TODO를 실제 개발로 연결하기까지의 과정은 생각보다 번거롭다. 매일 아침 다음과 같은 작업이 반복된다.

오늘 처리할 작업을 머릿속에서 정리하여 TODO로 작성한다
각 항목이 Jira에 이미 등록된 이슈인지 검색한다
등록된 이슈는 상태를 "개발 중"으로 전환한다
미등록 이슈는 새로 생성하고, 담당자를 지정하고, 상태를 전환한다
우선순위를 결정하고 첫 번째 작업에 집중한다

여기서 2번부터 4번까지의 작업은 인지 자원을 소모하면서도 실제 창출하는 가치는 0에 가까운 관리 오버헤드다. 코드를 생각하려는 순간, 브라우저를 열고 Jira에 접속하고 검색창에 키워드를 입력하는 행위 자체가 집중력을 분산시킨다.

1인 개발의 한계

또 다른 문제는 실제 개발 단계에 있다. 기능 하나를 구현할 때 다음 질문들이 동시에 제기된다.

백엔드 레이어에서 어떤 파일을 수정해야 하는가?
API 변경이 발생하면 프론트엔드 호출 코드와 어떻게 동기화할 것인가?
이 변경이 기존 도메인 모델에 어떤 영향을 미치는가?
검증은 어떤 범위까지 수행해야 하는가?

이 질문들에 순서대로 답하며 코드를 작성하는 것은 곧 아키텍처 결정, 구현, 검증을 한 사람이 모두 수행하는 상황을 의미한다. 경험이 많은 개발자라면 익숙한 작업일 수 있지만, 매일 반복되는 문맥 전환 비용은 축적된다.

스킬 설계의 출발점

이 두 가지 문제 의식에서 daily-todo-workflow의 설계가 시작되었다. 목표는 단순했다.

"TODO List를 전달하면 Jira 연동부터 개발, 검증, 커밋까지 AI가 처리하게 하자."

그러나 이 단순한 목표 뒤에는 하나의 중요한 아이디어가 있었다. AI를 단일 어시스턴트로 사용하는 것이 아니라, 역할이 분리된 팀으로 운영하자는 것이다.

2. 핵심 아키텍처: AI 에이전트 팀의 구조

2.1 조직 모델: CTO + 역할 전문가팀

daily-todo-workflow의 가장 핵심적인 설계 결정은 AI를 계층적 조직 모델로 운영한다는 것이다.

┌────────────────────────────────────────────────┐
│  CTO (Opus 모델)                                │
│  - 작업 전체를 분석하고 실행 계획을 수립한다             │
│  - 역할별 작업 지시서를 작성한다                      │
│  - QA 실패 시 원인을 분석하고 재지시한다               │
└───────────────────────┬────────────────────────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
    Backend Agent  Frontend Agent  QA Agent
    (Sonnet)       (Sonnet)        (Sonnet)

이 구조를 선택한 이유는 전략적 판단과 실행을 분리하면 각 모델의 강점을 최대한 활용할 수 있기 때문이다.

Opus는 비용이 높지만 복잡한 맥락을 이해하고 전체 시스템에 걸친 의사결정을 내리는 데 탁월하다. 반면, Sonnet은 빠르고 경제적이며 명확한 지시서가 주어진 구체적 구현 작업에서 충분한 성능을 발휘한다. CTO(Opus)가 무엇을 어떻게 할지를 설계하고, 역할 에이전트(Sonnet)가 실제 코드를 작성하는 구조는 비용 대비 품질을 최적화하는 자연스러운 선택이다.

2.2 전체 실행 흐름: 6개 Phase

스킬의 전체 흐름은 6개의 Phase로 구성된다.

[Phase 1] TODO 파싱 & Jira 일괄 매핑
    ↓
[Phase 2] 복잡도 자동 분류 & 사용자 확인
    ↓
[Phase 3] CTO 일괄 분석 (Explore + 작업 지시서)
    ↓
    ├─ Simple 경로 → [Solo Agent] ─────────────────┐
    │                                              ↓
    └─ Complex 경로 → [Backend] → [Frontend] → [Docs]
                          (API 계약서 핸드오프)
                                                  ↓
[Phase 4] QA 검증 (최대 3회 피드백 루프)
    ↓
[Phase 5] 커밋 & Jira 완료 & 다음 TODO
    ↓
[Phase 6] 일일 리포트

Phase 1 (Jira 매핑): 개발자가 자연어로 "feat: 라우팅 목록에 필터 추가"라고 쓰면 스킬이 자동으로 Jira를 검색하여 기존 이슈와 매핑하거나, 없으면 새로 생성하고 담당자와 상태를 설정한다.

Phase 2 (복잡도 분류): 4가지 수치 규칙(S1~S4)으로 Simple/Complex를 자동 분류하여 처리 경로를 달리한다.

Phase 3 (CTO 분석): CTO가 전체 코드베이스를 탐색하고 각 작업의 영향 범위를 분석하여 역할별 작업 지시서를 작성한다.

Phase 4 (QA 루프): 실패 원인을 분석하여 담당 에이전트에게 재작업을 지시하는 피드백 루프. 최대 3회 자동 반복.

2.3 핵심 메커니즘: API 계약서 핸드오프

가장 정교한 설계 중 하나는 Backend → Frontend 에이전트 간 API 계약서 핸드오프다.

AI 에이전트의 가장 큰 약점 중 하나는 병렬 실행 시 에이전트 간 컨텍스트 단절이다. Backend 에이전트가 API의 파라미터 타입을 String에서 Enum으로 변경했다면, 이 사실을 모르는 Frontend 에이전트는 여전히 문자열로 API를 호출하는 코드를 작성한다. 결과는 QA 실패다.

이를 해결하기 위해 Backend 에이전트는 작업 완료 시 반드시 다음 형식의 API 계약서를 출력하도록 설계되었다.

---API_CONTRACT_START---
endpoints:
- GET /api/routing?status={ENUM:DRAFT|EFFECTIVE}&page={int}
dtoChanges:
- RoutingListResponse: status 필드 String → RoutingStatus Enum
notes: status 값은 반드시 대문자 ENUM 값 사용
---API_CONTRACT_END---

Frontend 에이전트는 이 계약서를 프롬프트 상단에서 필독 섹션으로 받아 시작한다. 계약서 없이는 Frontend 에이전트가 시작될 수 없다. 이것은 소프트웨어 팀에서 백엔드 개발자가 API 명세를 공유한 후 프론트엔드 개발자가 작업을 시작하는 실제 협업 프로세스를 AI 에이전트 간에 그대로 구현한 것이다.

3. v1의 문제: 운용하면서 발견한 구조적 비효율

스킬을 실제로 사용하면서 v1의 구조적 문제들을 파악하고 개선하였다.

문제 1: 모든 TODO를 동일하게 처리하는 비효율

v1은 1줄짜리 버튼 색상 수정에도 다음 과정을 강제했다.

Explore Agent 실행 → CTO 분석 → Backend Agent → Frontend Agent → QA Agent

단순한 CSS 토큰 적용이 필요한 작업에 4~5개의 에이전트 실행이 소요되는 것이다. 토큰 소비와 실행 시간 모두 낭비였다.

문제 2: TODO 개별 분석의 반복 오버헤드

TODO가 5개라면 Explore Agent도 5회, CTO 분석도 5회 실행되었다. 이 5개의 작업이 동일한 코드베이스의 연관된 도메인에 있다면, 탐색 결과의 대부분은 중복이다.

문제 3: 에이전트 프롬프트의 컨텍스트 중복 주입

각 서브에이전트의 프롬프트에 50줄짜리 프로젝트 컨텍스트가 반복 삽입되었다. 그러나 Claude Code의 서브에이전트는 이미 CLAUDE.md를 자동으로 로드한다. 에이전트당 수천 토큰의 낭비였다.

문제 4: 중단 후 재시작의 비효율

작업 도중 세션이 끊기거나 오류가 발생하면 처음부터 다시 시작해야 했다. 상태가 저장되지 않아 모든 작업을 재실행해야 하는 상황이 발생했다.

문제 5: 에픽 테이블 하드코딩

Jira 에픽 매핑이 SKILL.md에 하드코딩되어 있어 프로젝트 변경 시 파일을 직접 수정해야 했다.

4. v2로의 진화: 핵심 개선 원칙과 구현

이러한 문제들을 분석하면서 v2의 설계 원칙이 도출되었다.

적절한 모델을 적절한 작업에

CLAUDE.md가 이미 존재한다면 재주입하지 말라

에이전트 간 상태를 명시적으로 전달하라

한 번 한 일은 두 번 하지 말라

개선 1: Simple/Complex 경로 자동 분기

v2는 TODO 항목을 4가지 수치 규칙(S1~S4)으로 자동 분류한다.

Simple 조건 (4가지 모두 충족 시):
  S1. 예상 변경 파일 ≤ 3개
  S2. 기존 패턴의 반복 수정 (CSS, 텍스트, CRUD 패턴)
  S3. 엔티티/서비스 신규 메서드 없음
  S4. 다른 TODO와 파일 의존관계 없음

자동 판정 키워드:
  → 항상 Simple: "style:", "chore:", "fix: + UI/CSS/텍스트 관련"
  → 항상 Complex: "feat:", "refactor:", 새 API, 엔티티 변경

Simple로 분류된 작업은 CTO 분석 단계를 거치지 않고 Sonnet 단일 에이전트가 직접 처리한다. 프롬프트도 15줄 이내로 최소화된다.

개선 2: TODO 일괄 분석 (Phase 3 재구성)

v1: [TODO#1 Explore] → [TODO#1 CTO] → [TODO#2 Explore] → [TODO#2 CTO] → ...

v2: [TODO 전체 Explore 1회] → [CTO 전체 분석 1회 + 지시서 일괄 작성]
                                          ↓
                               병렬 실행 가능 그룹 결정
                               → 독립적 TODO는 동시 실행

CTO는 전체 TODO의 의존관계를 파악한 뒤, 어떤 TODO를 병렬로 실행할 수 있고 어떤 TODO가 순차적이어야 하는지를 한 번에 결정한다.

개선 3: 에이전트 프롬프트 최소화

v2의 에이전트 프롬프트는 오직 세 가지만 포함한다.

역할 선언 (1줄)
작업 지시 (CTO 지시서에서 해당 역할 부분만)
완료 조건 (3-5줄)

50줄짜리 프로젝트 컨텍스트 블록은 사라졌다. CLAUDE.md가 자동 로드되므로 불필요하다. 프롬프트 길이가 v1 대비 에이전트당 60~70% 감소했다.

개선 4: 타겟 테스트 실행

v1의 QA Agent는 ./gradlew test로 전체 테스트 스위트를 실행했다. v2는 변경 파일 목록에서 도메인 패키지를 추출하여 해당 범위만 테스트한다.

# 변경된 파일
biz.page1.ebr.domain.masterdata.service.RoutingService.java

# 추출된 테스트 범위
./gradlew test --tests "biz.page1.ebr.domain.masterdata.*"

개선 5: 세션 재개 가능한 상태 저장

v2는 모든 작업의 진행 상태를 .bkit/state/daily-todo-state.json에 저장한다.

{
  "date": "2026-03-18",
  "todos": [
    { "jira": "EBR-250", "phase": "DONE", "commit": "abc1234" },
    { "jira": "EBR-251", "phase": "BACKEND_DONE", "apiContract": {} },
    { "jira": "EBR-245", "phase": "PENDING" }
  ]
}

세션이 중단된 후 재시작하면 완료된 작업은 건너뛰고 마지막으로 진행 중이던 단계부터 정확히 이어서 실행된다.

5. 설계에서 얻은 인사이트

AI 에이전트도 "분업"이 필요하다

단일 AI에게 모든 것을 맡기는 방식과 역할을 분리하는 방식의 차이는 생각보다 크다. 단일 에이전트는 맥락이 길어질수록 앞서 결정한 사항을 잊거나 일관성이 무너지는 경향이 있다. 반면 역할이 명확히 분리된 에이전트들은 각자의 범위에 집중하므로 더 예측 가능한 출력을 만들어낸다.

이것은 소프트웨어 공학의 단일 책임 원칙(Single Responsibility Principle)이 AI 에이전트 설계에도 그대로 적용된다는 것을 보여준다.

에이전트 간 인터페이스를 명시적으로 설계하라

API 계약서 핸드오프 메커니즘에서 얻은 핵심 교훈은 다음과 같다. 에이전트 간 데이터 흐름은 암묵적으로 기대하면 반드시 실패한다. 에이전트는 독립적인 새 세션(컨텍스트 윈도우)에서 실행된다. 이전 에이전트가 무엇을 했는지 알 수 없다.

이것은 마이크로서비스 아키텍처에서 서비스 간 통신을 명시적인 API로 정의하는 것과 동일한 원리다. AI 에이전트 간 '인터페이스'를 명시적으로 설계하는 것은 에이전트 시스템 안정성의 핵심이다.

결정 기준을 수치로 명시화하라

맨처음 적용했던 내용중 v1에서 CTO가 "단독 작업 모드를 선택할 수 있다"는 표현은 비결정적 행동을 만들었다. v2에서는 Simple 분류 조건을 S1~S4라는 체크리스트로 수치화했다. AI 모델의 판단은 확률적이지만, 규칙 체크리스트는 결정적이다. AI의 비결정성을 구조적 규칙으로 제어하는 것이 안정적인 워크플로우의 핵심이다.

AI에게 전달하는 컨텍스트의 질이 양보다 중요하다

프롬프트 설계에서 가장 흔한 실수 중 하나는 "더 많이 알려줄수록 더 잘할 것"이라는 가정이다. 실제로는 관련 없는 정보가 많을수록 AI는 무엇에 집중해야 할지 판단하는 데 자원을 소모한다. v2에서 에이전트 프롬프트를 60% 줄이면서도 출력 품질이 향상된 것은 이 원칙을 실증한 결과다.

6. 현재와 앞으로

daily-todo-workflow v2는 현재 실제 프로젝트 개발에 매일 사용되고 있다. TODO 목록을 전달하면 Jira 등록부터 코드 구현, 테스트, 커밋까지 AI 에이전트 팀이 처리하고 일일 리포트를 출력한다.

물론 여전히 해결해야 할 과제가 있다. Simple/Complex 분류의 오분류 케이스, Worktree merge 충돌 시 수동 개입, 복잡한 비즈니스 로직에서의 에이전트 간 컨텍스트 불일치 등은 지속적으로 개선이 필요하다.

그러나 이 스킬을 만들면서 얻은 가장 중요한 통찰은 기술적인 것이 아니다. 그것은 AI를 사용한다는 것이 어시스턴트를 고용하는 것이 아니라 팀을 조직하는 것과 같다는 인식이다.

팀원에게 일을 맡길 때처럼 역할을 정의하고, 인터페이스를 명확히 하고, 결정 기준을 세우고, 실패 시 재시도 프로세스를 구축하는 것. 그것이 AI 에이전트 시스템을 신뢰할 수 있게 만드는 핵심이다.

이 스킬은 Claude Code의 커스텀 스킬 기능과 bkit PDCA 프레임워크를 기반으로 구현되었으며, SKILL.md 파일 하나로 전체 워크플로우가 정의된다.

나는 어떤 일을, 왜, 어떻게 하고 있는걸까?

D.Y — Mon, 16 Mar 2026 16:13:52 +0900

최근 회사에서 일을 하면서 내가 하고 있는 일은 무엇인지, 어떤 문제를 풀고 있고 왜 풀고 있는건지?

그리고 최근 최대 관심사인 AI를 어떤 방법으로 활용하고 있는지에 대해서 생각해보게 되었습니다.

생각한 김에.. 이 내용을 정리한 내용을 공유합니다.

Q. 내가 하고 있는 일은 무엇인가?

EBR(Electronic Batch Record, 전자배치기록 시스템)을 개발하고 있습니다. 제조·제약 현장에서 발생하는 배치 기록을 디지털화하여, 데이터를 체계적으로 관리할 수 있도록 돕는 솔루션입니다.

Q. 어떤 문제를 풀고 있나?

제조·제약 업계에서는 Paperless 전환이 빠르게 진행되고 있습니다. 데이터 무결성(Data Integrity) 확보, 글로벌 규제 준수, 업무 효율화 등의 이유로 EBR 시스템 도입 수요가 높아지고 있습니다.

그러나 현재 시장의 EBR 솔루션은 대부분 외산 MES 기반으로, 기능 범위가 방대한 만큼 도입 비용도 매우 높습니다. 이로 인해 중소 규모 기업들은 도입 자체를 포기하고 여전히 종이 기반으로 운영하는 경우가 많습니다.

저는 이 공백을 해결하기 위해, 꼭 필요한 EBR 기능에 집중한 자체 솔루션을 개발하고 있습니다. 목표는 EBR이 필요하지만 진입 장벽에 막혀 있는 기업들에게 현실적인 선택지를 제공하는 것입니다.

Q. 비즈니스적(경제적)으로 어떤 효과가 있는가?

대형 MES 도입이 예산상 어렵거나, 그 수준까지 필요하지 않은 기업을 주요 타겟으로 합니다. 합리적인 비용으로 EBR 핵심 기능을 제공함으로써, 지금까지 시장에서 소외되었던 중소 제조·제약사들을 새로운 고객층으로 확보할 수 있습니다. 또한 종이 기반 운영 대비 데이터 오류 감소, 감사 대응 효율화 등 고객사의 실질적인 운영 비용 절감 효과도 기대할 수 있습니다.

Q. 본질적으로 이 일을 왜 하고 있는가?

여러 현실적인 이유로 데이터를 디지털로 관리하지 못하는 기업들에게, 데이터 통합 관리의 기회를 제공하고 싶기 때문입니다.

종이 기반 운영은 데이터 누락·오류·위변조 위험을 내포하고 있고, 사후 분석도 어렵습니다. 반면 데이터가 통합되면 공정 이상 감지, 품질 트렌드 파악 등 현장 운영에 실질적인 인사이트를 제공할 수 있습니다. 단순히 종이를 없애는 것이 아니라, 데이터가 의사결정의 근거가 되는 환경을 만드는 것이 이 일의 본질이라고 생각합니다.

Q. AI는 업무 어디에 적용하고 있는가?

기획부터 디자인, 개발, QA까지 전 개발 프로세스에 AI를 적용하고 있으며, 주요 도구는 Claude Code입니다.

기획 : AI와의 대화를 통해 PRD를 작성하고, 이를 바탕으로 유비쿼터스 언어 정의, 유스케이스, 시퀀스 다이어그램 등 설계 문서를 체계화했습니다.
디자인 : Figma Make에 PRD를 입력해 프로토타입 디자인을 생성했습니다. AI가 기획 의도를 반영한 초안을 빠르게 만들어줌으로써 디자인 단계의 속도를 크게 높일 수 있었습니다.
개발 : Figma MCP를 통해 디자인과 개발 환경을 연결하고, 프로젝트 기술 스택에 맞는 프론트엔드 코드로 변환하는 프롬프트 지침을 작성했습니다. 백엔드는 PRD와 다이어그램을 컨텍스트로 제공하여 아키텍처 설계와 스펙 확정 과정에도 AI를 적극 활용했습니다.

감사합니다.

[주간 IT 동향] 2026-03-13 ~ 03-16: NVIDIA GTC 2026 개막, "모델은 범용재" 논쟁, AI 에이전트 보안 아키텍처의 실전

D.Y — Mon, 16 Mar 2026 10:10:30 +0900

TL;DR

NVIDIA GTC 2026이 오늘(3/16) 산호세에서 개막한다. 30,000명이 참석하며 Vera Rubin 딥다이브, Feynman 아키텍처 최초 공개, NemoClaw 에이전트 플랫폼, Groq LPU 통합이 핵심 발표로 예상된다
"모델은 범용재(commodity)이고 인프라가 해자(moat)다"라는 주장이 실전 경험에 기반해 구체화되고 있다. 같은 Claude 모델을 쓰는 두 팀의 성과가 극명하게 갈리는 이유가 모델이 아닌 주변 인프라에 있다는 것이다
OpenClaw 보안 사고를 계기로, AWS Nitro Enclaves와 Firecracker 기반의 안전한 AI 에이전트 배포 레퍼런스 아키텍처가 등장했다. Docker도 NanoClaw + Docker Sandboxes 통합으로 에이전트 격리 실행을 밀고 있다
Anthropic이 첫 공식 기술 인증인 Claude Certified Architect(CCA)를 출시하면서, 에이전트 아키텍처 설계가 공식 자격증 수준의 전문 영역으로 자리잡았다
Lambda Managed Instances가 Rust를 지원하기 시작하면서, 고성능 서버리스 워크로드의 선택지가 확장되었다

1. NVIDIA GTC 2026: "AI의 슈퍼볼"이 시작된다

오늘 산호세 SAP Center에서 Jensen Huang의 키노트로 시작되는 GTC 2026은, 190개국 3만 명 참석에 10개 베뉴, 700개 이상 세션이라는 규모 자체가 이미 AI 인프라의 현주소를 보여준다.

이번 GTC에서 주목해야 할 발표는 네 가지다.

첫째, Feynman 아키텍처의 최초 구체적 공개가 예상된다. TSMC A16 프로세스 독점 사용, 하이브리드 본딩 기술(SoIC/EMIB), 그리고 Groq의 LPU를 통합할 가능성이 거론되고 있다. Jensen이 "한 번도 보여준 적 없는 칩"을 공개하겠다고 예고한 만큼, 마이크로아키텍처 차원의 근본적 전환이 될 수 있다.

둘째, NemoClaw라는 AI 에이전트 플랫폼 런칭이 예상된다. 기업이 시스템 전반에 에이전트를 배포할 수 있는 서비스다. GTC 현장에서는 참석자가 직접 에이전트를 만들고 배포하는 "build-a-claw" 이벤트도 진행된다.

셋째, Jensen Huang이 Ai2, Cursor, LangChain, Mistral 등의 리더들과 오픈 프론티어 모델에 대한 토론을 주최한다. 지난 1년간 오픈 모델의 급속한 발전이 모든 산업에 AI를 확산시키고 있다는 맥락이다.

넷째, Vera Rubin NVL72에서 NVL576으로의 스케일업 로드맵과 Rubin CPX(context 전용 프리필 랙)의 상세 사양이 공개될 전망이다. Thinking Machines Lab과의 기가와트급 전략적 파트너십도 발표되었다.

GTC 2026의 핵심 키워드는 "agentic performance"다. 학습 워크로드에서 추론 워크로드로, 다시 에이전틱 워크로드로 AI 인프라의 중심축이 이동하고 있다. 이건 하드웨어 엔지니어뿐 아니라, 에이전트 시스템을 설계하는 소프트웨어 아키텍트에게도 직접적인 영향을 미친다.

2. "모델은 범용재, 인프라가 해자": Harness Engineering의 실전 교훈

이번 주 가장 날카로운 기고문은 "Harness Engineering: Why the Model Is a Commodity and the Infrastructure Is Your Moat"다. 에이전트를 수개월간 프로덕션에서 운영해온 엔지니어의 핵심 주장은 명쾌하다: 모델은 거의 아무런 차이를 만들지 않고, 모델 주변에 무엇을 배치하느냐가 전부라는 것이다.

같은 Claude 모델을 사용하는 두 팀이 있을 때, 한쪽은 평범한 결과를 내고 다른 쪽은 탁월한 결과를 내는 이유가 모델의 차이가 아니라, prompt 관리, 도구 오케스트레이션, 에러 핸들링, 모니터링, 가드레일 등 "모델을 둘러싼 인프라"의 차이라는 것이다.

이 주장은 Morgan Stanley가 이번 주 발표한 보고서와도 맞닿아 있다. Morgan Stanley는 "Transformative AI"가 강력한 디플레이션 힘이 될 것이며, AI 도구가 인간 작업을 낮은 비용으로 복제하면서 기업들이 대규모 인력 감축을 이미 실행하고 있다고 분석했다. 모델 자체의 성능은 계속 올라가지만, 진정한 경쟁우위는 그 모델을 프로덕션 워크플로우에 어떻게 엮느냐에서 나온다. 시니어 아키텍트가 지금 투자해야 할 영역이 어디인지 명확히 보여주는 논쟁이다.

3. OpenClaw 보안 사고에서 배우는 에이전트 보안 아키텍처

OpenClaw 보안 취약점, Moltbook 데이터 유출, GTG-1002 AI 오케스트레이션 스파이 캠페인에 대한 포렌식 분석 기사가 이번 주 등장했다. 이 기사가 가치 있는 이유는 단순한 사후 분석을 넘어, AWS Nitro Enclaves와 Firecracker를 활용한 안전한 에이전트 배포 레퍼런스 아키텍처를 제시하기 때문이다.

Docker 진영에서도 같은 방향의 움직임이 두 가지 있었다. 첫째, NanoClaw라는 경량 에이전트 프레임워크가 Docker Sandboxes와 통합되면서 "secure-by-design" 에이전트 실행을 표방한다. 격리(isolation), 코드베이스 검사 용이성, 명확한 제어 경계가 핵심 설계 원칙이다.

둘째, Claude Code를 Docker로 실행하는 방법 가이드가 공식 Docker Blog에 게시되었다. 로컬 모델, MCP 서버, 보안 샌드박스를 결합해 AI 코딩 에이전트에 적절한 인프라, 도구 접근, 보안 경계를 제공하는 실전 구성이다.

이 세 가지 움직임을 종합하면, 에이전트 보안이 "의식의 문제"에서 "아키텍처 패턴의 문제"로 전환되고 있음을 보여준다. 에이전트를 프로덕션에 배포하려면, Nitro Enclaves, Firecracker 마이크로VM, Docker Sandboxes 같은 격리 기술이 필수 요소가 되는 시대다.

4. Claude Certified Architect: AI 에이전트 설계가 공식 자격증이 되다

Anthropic이 3월 12일 첫 공식 기술 인증인 Claude Certified Architect(CCA) Foundations를 출시했다. 이것은 개념적인 AI 리터러시 배지가 아니다. 엔지니어가 엔터프라이즈 규모에서 프로덕션급 Claude AI 애플리케이션을 설계하고 배포할 수 있는 능력을 검증하는 감독관 동석(proctored) 아키텍처 수준의 시험이다.

시험은 API 설계, 에이전트 오케스트레이션, 도구 사용, 프롬프트 아키텍처, 보안, 스케일링 등을 다룬다. AWS Solutions Architect나 GCP Professional Architect와 같은 맥락에서, "AI 에이전트 아키텍트"가 독립적인 전문 직군으로 공식화된 것이다. 에이전트 시스템을 설계하는 시니어 엔지니어라면 로드맵에 올려둘 만하다.

이번 주 주목할 기술 동향

Lambda Managed Instances Rust 지원: Lambda에서 Rust를 실행할 수 있게 되면서, 고성능 서버리스 워크로드의 선택지가 넓어졌다. 최신 세대 프로세서와 특화 컴퓨트 구성에 Lambda의 운영 단순성을 결합한다.
SAM Kiro Power: AWS SAM에 Kiro IDE 통합이 추가되어, AI 에이전트가 서버리스 애플리케이션 개발을 직접 지원한다. Lambda Durable → Kiro Power → SAM Kiro Power로 이어지는 AWS의 에이전트 기반 개발 도구 생태계가 빠르게 확장 중이다.
ChangeTrail 오픈소스: 온콜 인시던트 대응 시 "무엇이 바뀌었나?"를 Kubernetes, GitHub, AWS 변경 이력을 하나의 타임라인에서 보여주는 도구. 60초 설치.
모니터링 감사(Monitoring Audit): 코드에는 자동 품질 검사가 있는데 모니터링에는 왜 없는가? 비활성화된 알림을 아무도 모른 채 3개월이 지나는 문제를 해결하기 위한 모니터링 감사 도구가 등장했다.
GEO(Generative Engine Optimization): 요즘IT에서 제로클릭 시대에 AI의 선택을 받기 위한 SIFT 프레임워크(Structure, Intent, Fidelity, Trust) 기반 콘텐츠 전략을 다루었다.

참고 자료

[제약/바이오 IT] ERP와 EBR의 데이터 인터페이스: SAP PO와 PP 모듈의 이해

D.Y — Thu, 5 Mar 2026 09:06:01 +0900

제약 및 바이오 기업의 생산 공정 디지털화에서 가장 중추적인 과제는 시스템 간 '데이터의 연속성'을 확보하는 것이다.

전사적 자원 관리를 담당하는 ERP(Enterprise Resource Planning)와 생산 현장의 기록을 디지털화하는 EBR(Electronic Batch Record) 시스템은 유기적인 데이터 연동을 통해 비로소 하나의 완성된 프로세스를 형성한다.
(EBR은 필자가 개발중인 시스템이다.)

본 포스팅에서는 시스템 연동의 핵심 구성 요소인 SAP PO와 SAP PP의 개념 및 역할을 정리하고자 한다.

1. 전사적 자원 관리의 중심, SAP ERP

SAP는 전 세계적으로 가장 널리 사용되는 대표적인 ERP 솔루션이다.

회계, 인사, 생산, 물류, 영업 등 기업의 핵심 비즈니스 프로세스를 단일 시스템으로 통합하여 데이터의 실시간 관리와 효율적인 의사결정을 지원한다. 제약 산업에서 품목 마스터 정보부터 제조 지시까지의 모든 기준 정보는 ERP를 기점으로 생성되어 타 시스템으로 전파되는 구조를 갖는다.

2. 생산 계획과 실행의 엔진, SAP PP (Production Planning)

EBR 시스템이 가동되기 위해서는 "어떠한 제품을, 어느 라인에서, 어떠한 공정으로 제조할 것인가"에 대한 기초 데이터가 선행되어야 한다. 이 데이터를 생성하고 관리하는 주체가 바로 SAP의 PP 모듈이다.

주요 기능: 제조업의 생산 프로세스를 계획(Planning), 실행(Execution), 통제(Control)하는 핵심 모듈이다.
핵심 데이터:
- 자재 마스터(Material Master) & BOM(Bill of Material): 제품 구성 및 원자재 명세
- 작업장(Work Center) & 라우팅(Routing): 생산 설비 정보 및 표준 공정 경로
- 생산 오더(Production Order): 구체적인 제조 지시 및 생산 실적 관리
역할: 효율적인 제조 운영과 자원 최적화를 실현하는 생산 관리의 근간이 된다.

3. 시스템 간 연동의 미들웨어, SAP PO (Process Orchestration)

SAP ERP 내의 생산 정보(PP 데이터)를 외부 시스템인 EBR(PostgreSQL 기반 데이터베이스 등)로 전달하기 위해서는 중간 매개체가 필요하다. 이때 활용되는 인터페이스 전용 서버가 바로 SAP PO이다.

정의: 서로 다른 시스템 간의 데이터를 중계하고 규격을 변환하여 연결해 주는 미들웨어(Middleware) 솔루션이다.
데이터 흐름: SAP ERP (PP 데이터 생성) → SAP PO (데이터 변환 및 중계) → EBR (데이터 수신 및 저장)
필요성: 보안 강화 및 시스템 부하 분산을 위해 ERP와 외부 시스템 간의 직접 통신을 지양하고, PO라는 검증된 통로를 거쳐 안정적인 데이터 전송을 보장한다.

4. 환경의 구분: 품질(QA) 환경과 운영(PRD) 환경

제조 및 제약 업계의 IT 인프라는 시스템의 안정성과 신뢰성을 확보하기 위해 통상적으로 두 가지 환경으로 분리하여 운용한다.

구분	명칭	상세 설명
품질 환경	QA (Quality Assurance)	새로운 기능을 테스트하거나 데이터 연동 로직을 검증하는 시험/개발 환경을 의미한다.
운영 환경	PRD (Production)	실제 공장이 가동되고 실제 제품 생산 데이터가 적재되는 실제 가동 서버를 의미한다.

요약 및 결론

제약 제조 시스템의 데이터 아키텍처는 [SAP PP(기준 정보 생성) → SAP PO(중계 및 전송) → EBR(실행 및 기록)]의 선형적 구조를 띤다. 특히 규제 산업인 제약 분야에서는 이러한 데이터의 무결성과 흐름을 이해하는 것이 시스템 구축 및 운영의 성패를 결정짓는 핵심 요소가 된다.