에이전틱 엔지니어링 다음

에이전틱 엔지니어링과 그 다음

에이전틱 엔지니어링 사례 + 그 다음 단계 일부

2026-04-07

0. 발표자

포털, 게임 회사, UX 에이전시 등에서 개발자, 연구원, 데이터 엔지니어, 기획자 등으로 근무

현재는 코르카에서 일하는 중

1. 시작하기 전에

❌ “베스트 프랙티스를 찾았다. 이제 인간은 놀기만 하면 된다.”

✅ “제법 괜찮은 방법 하나를 찾았다. 인간이 할 일이 조금 바뀐 것 같다.”

해봤더니 잘 되는 것, 앞으로 해보려고 고민 중인 것.

2. 코드 품질

AI가 코드를 읽고 쓰는데 코드 품질이 여전히 중요할까?

사람이 안 쓰고 안 읽어도 품질이 좋으려면?

코드 품질이 여전히 중요할까?

AI는 아직 인간을 모방 중. (아직은. 하지만 Welcome to the Era of Experience)

현재 코드의 품질이 좋아야 AI도 좋은 코드를 만들 것. (참고: Improving frontend design)

코드 품질이 낮아지면(긴 코드, 순환 참조, 높은 결합도 등) LLM의 컨텍스트에 올릴 토큰 수가 많아짐 → context rot.

코드 품질이 좋아야 리뷰하기 수월함. 리뷰를 인간이 하건 AI가 하건.

사람이 안 쓰고 안 읽어도 코드 품질이 좋으려면?

타입 검사, 테스트 자동화, 테스트 커버리지 측정.

린터: 파일 길이 제약, 함수 길이 제약, 함수 문장 수 제약, 인지복잡도 제약 등.

의존 관계 강제: 큰 설계를 벗어나지 못하게 제약. (예: 비즈니스 로직이 UI에 의존하지 못하게 하기)

코드 중복 검사: 구조적으로 동일한 덩어리를 발견해서 제거.

죽은 코드 검사: 안 쓰이는 코드, 안 쓰이는 의존성 검사해서 제거.

뮤테이션 테스트: 코드를 임의로 바꿨는데 테스트가 안깨지면 테스트에 틈이 있다는 뜻. (단, 속도 주의)

참고: AI 시대의 소스코드 품질 (아 그리고, 공급망 공격 가능성 낮추기: dep cooldown, e18e 등)

조합이 중요

“악마는 디테일에 있다.”

좋은 조합이 중요. 예시:

테스트-프로덕션 코드 비율을 강제하지 않으면서 테스트 커버리지만 검사하면 테스트 갯수가 한없이 늘어남
인지복잡도를 측정하지 않으면서 중복만 제거하라고 하면 로직이 한없이 복잡해짐

터미널 덜 보기

어차피 터미널에서 “ㅇㅇ” 밖에 안하는데 터미널을 왜 보고 있지?

깃헙 이슈 작성 → 클로드 코드가 이슈를 읽고 코드를 작성하여 PR 생성 → 인간이 리뷰하고 머지.

claude --dangerously-skip-permissions -p "docs/issue.md 파일의 지시를 수행해"

3. 명세서

코드를 안 쓰고 안 읽으면 뭘 읽고 쓰나? 명세서.

명세서 기반 개발 (SDD; Spec-Driven Development)

하지만…

문제 1. 자연어로 작성된 명세서의 모호함.

“What you write down doesn’t mean exactly what you think it means. And when it does, it doesn’t have the consequences you expected.” —Daniel Jackson, Software Abstractions: Logic, Language, and Analysis

문제 2. 문서-코드 불일치 문제 (spec-code drift).

명세서를 실행하자

2002년에 Ward Cunningham이 만든 Framework for integrated test.

Framework for integrated test.png

두 가지 문제가 완화됨: 1) spec-code drift, 2) 자연어의 모호함.

specdown

specdown: 마크다운 문서 안에 인수 테스트를 적어서 실행 가능한 소프트웨어 명세서를 작성하는 방식.

4. 고민중인 거

에이전트로 개발을 잘 하는 건 이런 식으로 하다보면 잘 풀린 것 같다. 그 다음은 뭘까?

Self-healing, self-growing S/W:

시스템 로그를 에이전트가 볼 수 있다면? (참고: Defect cost increase)
구글 애널리틱스 정보를 에이전트가 볼 수 있다면?
스스로 홍보 전략을 수립하고 실행한다면?

더 많은 소프트웨어 vs. 더 좋은 소프트웨어.

디자인은 나무가 아니다..

끝

요약:

코드 품질은 여전히 중요하고, 어느 정도 잘 관리할 방법이 있다.
실행 가능한 명세서를 잘 갖추면 문서-테스트-코드가 연결되어 문서-코드 불일치 문제를 줄일 수 있다.
개발은 전체 사이클의 한 단계에 불과하다. 스스로 개선하고 스스로 성장하는 소프트웨어에 대해 고민해보자.
디자인에 대해 지금보다 더 깊게 고민해보면 좋겠다.

감사합니다.