# Beyond agentic engineering

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

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

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

2026-04-07

## 0. 발표자

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

현재는 [코르카](https://corca.ai/)에서 일하는 중

## 1. 시작하기 전에

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

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

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

## 2. 코드 품질

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

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

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

AI는 아직 인간을 모방 중. (아직은. 하지만 [Welcome to the Era of Experience](https://wiki.g15e.com/pages/Welcome%20to%20the%20Era%20of%20Experience.txt))

현재 코드의 품질이 좋아야 AI도 좋은 코드를 만들 것. (참고: [Improving  frontend design](https://claude.com/blog/improving-frontend-design-through-skills))

코드 품질이 낮아지면(긴 코드, <순환 참조>, 높은 결합도 등) [LLM](https://wiki.g15e.com/pages/Large%20language%20model.txt)의 컨텍스트에 올릴 토큰 수가 많아짐 → context rot.

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

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

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

린터: 파일 길이 제약, 함수 길이 제약, 함수 문장 수 제약, [인지복잡도](https://wiki.g15e.com/pages/Cognitive%20complexity.txt) 제약 등.

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

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

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

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

참고: [AI 시대의 소스코드 품질](https://wiki.g15e.com/pages/Source%20code%20quality%20in%20the%20AI%20era.txt) (아 그리고, 공급망 공격 가능성 낮추기: dep cooldown, e18e 등)

### 조합이 중요

"악마는 디테일에 있다."

좋은 조합이 중요. 예시:

- 테스트-프로덕션 코드 비율을 강제하지 않으면서 테스트 커버리지만 검사하면 테스트 갯수가 한없이 늘어남
- [인지복잡도](https://wiki.g15e.com/pages/Cognitive%20complexity.txt)를 측정하지 않으면서 중복만 제거하라고 하면 로직이 한없이 복잡해짐

### 터미널 덜 보기

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

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

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

## 3. 명세서

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

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

하지만…

문제 1. [자연어로 작성된 명세서의 모호함](https://wiki.g15e.com/pages/Specification%20written%20in%20natural%20language.txt).

> "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](https://wiki.g15e.com/pages/Software%20Abstractions%20-%20Logic,%20Language,%20and%20Analysis.txt)

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

### 명세서를 실행하자

2002년에 [Ward Cunningham](https://wiki.g15e.com/pages/Ward%20Cunningham.txt)이 만든 [Framework for integrated test](https://wiki.g15e.com/pages/Framework%20for%20integrated%20test.txt).

![Framework for integrated test.png](Framework%20for%20integrated%20test.png)

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

### specdown

[specdown](https://wiki.g15e.com/pages/specdown.txt): 마크다운 문서 안에 <인수 테스트>를 적어서 실행 가능한 소프트웨어 명세서를 작성하는 방식.

![specdown.png](specdown.png)

## 4. 고민중인 거

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

Self-healing, self-growing S/W:

- 시스템 로그를 에이전트가 볼 수 있다면? (참고: [Defect cost increase](https://wiki.g15e.com/pages/Defect%20cost%20increase.txt))
- 구글 애널리틱스 정보를 에이전트가 볼 수 있다면?
- 스스로 홍보 전략을 수립하고 실행한다면?

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

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

## 끝

요약:

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

감사합니다.