Stack Overflow가 사라진 뒤 AI는 무엇을 참고할까: 레퍼런스가 없는 시대의 Evidence-Driven Coding Agent

개발하다가 처음 보는 오류가 발생했다.

몇 년 전이라면 거의 반사적으로 검색창부터 열었다.

Error Message
    ↓
Google
    ↓
Stack Overflow
GitHub Issues
개발 블로그
Reddit
    ↓
비슷한 사례 발견
    ↓
해결

특히 Stack Overflow와 GitHub Issues는 단순한 Q&A 사이트가 아니었다.

어떤 Framework가 문서와 다르게 동작하거나, 특정 OS 버전에서만 문제가 생기거나, 공식 문서에는 없는 조합에서 Crash가 발생하면 누군가 먼저 부딪혔다.

그리고 그 해결 과정이 공개 웹에 남았다.

질문

시도한 코드

오류 메시지

환경

잘못된 해결법

추가 댓글

Maintainer 답변

최종 해결법

다음 개발자는 그 기록을 검색해서 몇 시간의 시행착오를 건너뛸 수 있었다.

그런데 AI Coding Tool이 일상이 되면서 이 흐름에 변화가 생겼다.

이제 오류가 발생하면 이렇게 해결하는 경우가 많다.

Error
   ↓
Codex / Claude Code / Cursor
   ↓
Repository 분석
   ↓
수정
   ↓
Test
   ↓
해결

문제는 그 다음이다.

해결 과정

↓

개인 Agent Session 안에 남음

↓

공개 웹에는 아무것도 남지 않음

어떤 개발자가 하루 동안 처음 보는 SDK Bug를 해결했어도 Stack Overflow 질문을 올리지 않는다.

GitHub Issue를 만들지 않을 수도 있다.

블로그도 쓰지 않는다.

Agent와 대화하다 문제가 해결됐기 때문이다.

사람에게는 편리하다.

하지만 Software Ecosystem 전체에서 보면 흥미로운 문제가 생긴다.

미래의 개발자와 미래의 AI가 검색할 새로운 Reference가 줄어들 수 있다.

1. 실제로 Stack Overflow의 공개 지식 생산은 감소했다

이건 단순한 느낌만은 아니다.

PNAS Nexus에 발표된 연구에서는 ChatGPT 공개 이후 Stack Overflow 활동을 다른 Q&A 플랫폼과 비교했다.

연구 결과 ChatGPT 출시 후 6개월 시점에서 Stack Overflow의 Posting Activity가 비교군 대비 약 25% 감소한 것으로 추정됐다.

연구진은 이 수치를 오히려 실제 영향의 하한선으로 해석했다.

특히 흥미로운 점은 감소가 단순 Beginner Question에만 나타난 것이 아니라는 것이다.

숙련 개발자와 초보 개발자 모두에서 콘텐츠 생산 감소가 관찰됐다.

즉:

"쉬운 질문을 AI가 대신했으니
중복 질문만 줄었다."

정도로 설명하기 어렵다.

공개된 인간 생성 개발 지식 자체가 줄어들 가능성이 있다는 의미다.

2. 그렇다고 Stack Overflow가 필요 없어졌다는 뜻도 아니다

여기서 역설이 하나 생긴다.

2025 Stack Overflow Developer Survey에서는 개발자의 84%가 AI Tool을 사용하거나 사용할 계획이라고 답했다.

그런데 AI 결과의 정확성을 신뢰한다는 응답보다 불신한다는 응답이 더 많았다.

또 AI Tool을 사용할 때 가장 큰 불만으로 꼽힌 것이:

"거의 맞지만 완전히 맞지는 않는 답"

이었다.

응답자의 66%가 이런 문제를 경험했다고 답했다.

더 재미있는 데이터도 있다.

Stack Overflow 방문자 중 약 35%는 적어도 가끔:

AI가 만든 결과 때문에
추가로 Debugging하거나 확인할 일이 생겨서
Stack Overflow를 방문한다.

고 답했다.

즉 구조가 이렇게 되고 있다.

Stack Overflow 질문 감소
        ↓
AI 사용 증가
        ↓
AI가 거의 맞는 코드 생성
        ↓
확신이 안 생김
        ↓
다시 Human-verified Reference 필요

AI 때문에 공개 Q&A는 줄지만, 동시에 AI를 검증하기 위해 인간이 검토한 지식은 더 중요해지는 역설이다.

3. 미래 AI의 가장 큰 문제는 “과거는 많이 아는데 지금은 모른다”일 수 있다

LLM은 엄청난 양의 과거 코드를 학습한다.

그래서 오래된 문제에는 매우 강하다.

예:

UITableView cell reuse

Swift retain cycle

Android lifecycle

HTTP caching

React state update

같은 문제에는 수많은 공개 Reference가 존재한다.

하지만 새로운 기술에서는 상황이 다르다.

예를 들어:

iOS 27 신규 Framework

Swift 6.x 새로운 Compiler Behavior

Android 최신 API

신규 GPU SDK

출시 일주일 된 Package

회사 내부 Framework

에서 문제가 발생했다고 하자.

검색 결과:

Stack Overflow      0

GitHub Issues        1
→ 다른 문제

Reddit               0

Blog                 0

일 수 있다.

LLM 내부 지식도 충분하지 않다.

이 상황에서 Agent가 해야 할 행동은 무엇일까?

4. 가장 위험한 행동은 “비슷하게 기억나는 답”을 만들어내는 것이다

Agent가 이렇게 말한다.

이 문제는 보통
MainActor Isolation 때문에 발생합니다.

그럴듯하다.

그러면서 수정한다.

@MainActor
func refresh() {
    ...
}

Compiler Error가 사라졌다.

그렇다면 해결된 것일까?

아니다.

원래 문제는:

MainActor

가 아니라:

SDK 내부에서
callback ownership이 변경된 문제

일 수도 있다.

Error가 없어졌다는 사실과 Root Cause를 찾았다는 사실은 다르다.

5. 그래서 Reference가 없을수록 개발 방법이 달라져야 한다

기존 개발 방식은 상당 부분 Reference-driven이었다.

Problem
   ↓
Search
   ↓
Reference
   ↓
Adapt
   ↓
Solution

하지만 Reference가 없다면:

Problem
   ↓
Observe
   ↓
Hypothesis
   ↓
Experiment
   ↓
Evidence
   ↓
Reject / Confirm
   ↓
Solution

으로 이동해야 한다.

이 글에서는 이 방식을 편의상 Evidence-Driven Coding Agent라고 부른다.

공식 표준이나 특정 제품 기능의 이름은 아니다.

핵심은 단순하다.

Agent가 정답을 모르면 답을 만들어내지 말고, 정답을 판정할 수 있는 증거부터 만들어야 한다.

6. 검색이 끝나는 순간부터 Agent의 진짜 능력이 시작된다

Agent에게 오류를 조사시켰다.

검색 결과 관련 사례가 없다.

좋지 않은 Agent:

Reference 없음

↓

LLM Memory에서 가장 비슷한 Pattern 선택

↓

수정

좋은 Agent:

Reference 없음

↓

현재 Environment 확인

↓

Repository 조사

↓

SDK / Source 확인

↓

최소 재현

↓

가설 생성

↓

Experiment

↓

Runtime Evidence

↓

Regression Test

↓

수정

이 차이가 앞으로 꽤 중요해질 수 있다.

7. Evidence-Driven Agent의 첫 단계는 Environment Snapshot이다

오류를 보자마자 수정하지 않는다.

먼저 현재 환경부터 고정한다.

예:

environment:

  os:
    name: macOS
    version: "27.0"

  xcode:
    version: "27.0"

  swift:
    version: "6.x"

  target:
    platform: iOS
    deploymentTarget: "18.0"

  project:
    revision: "a83e91f"

  dependency:
    packageA: "4.2.1"

왜 중요할까?

오류는 코드보다 환경에 묶여 있는 경우가 많다.

8. “내 컴퓨터에서는 되는데요” 문제도 결국 Environment Evidence 부족이다

예:

Developer A

Xcode 27
PASS

CI

Xcode 26.4
FAIL

코드만 보여주면 Agent가 이상한 수정에 들어갈 수 있다.

하지만 Environment Snapshot이 있으면:

Compiler Version Difference

라는 가설부터 세울 수 있다.

그래서 Agent Debugging에서 첫 질문은:

무슨 코드인가?

보다:

정확히 어떤 상태에서 실패했는가?

가 되는 편이 좋다.

9. 두 번째는 Error를 구조화한다

긴 Build Log 전체를 바로 Agent에게 넣는 방식도 좋지 않다.

먼저 핵심 정보를 추출한다.

예:

{
  "command": "xcodebuild ...",
  "exitCode": 65,
  "failure": {
    "type": "compiler",
    "file": "SessionManager.swift",
    "line": 182,
    "message": "..."
  }
}

원본 Log는 별도 Artifact로 유지한다.

.ai/artifacts/
└── build-20260827-1421.log

Agent Context에는 필요한 부분부터 넣는다.

10. 세 번째는 관련 코드 범위를 줄인다

처음부터 Repository 50만 줄을 읽을 필요는 없다.

Error:

SessionCoordinator.swift:182

라면:

SessionCoordinator

↓

Callers

↓

Protocol

↓

Tests

↓

최근 변경

순서로 범위를 좁힌다.

이런 과정을 Evidence Funnel로 생각하면 편하다.

Repository 전체
      ↓
관련 Module
      ↓
관련 Type
      ↓
관련 Call Path
      ↓
Minimal Reproduction

Context를 많이 읽는 것보다 불확실성을 빠르게 줄이는 것이 중요하다.

11. Git History가 새로운 개발 Reference가 된다

외부 인터넷에 답이 없어도 Repository에는 과거가 있다.

Agent가 가장 먼저 확인할 것 중 하나가:

git log

git blame

git show

git diff

git log -S

가 된다.

예를 들어 현재 문제가:

Background 복귀 후
Session이 간헐적으로 초기화됨

이라고 하자.

검색한다.

git log -S "refreshSession"

6개월 전 Commit이 나온다.

Fix duplicate refresh after scene activation

Public Web에는 없는 정보다.

하지만 현재 프로젝트에서는 Stack Overflow의 어떤 답보다 중요할 수 있다.

12. Pull Request History는 더 좋은 Reference가 될 수도 있다

Commit에는 결과만 남아 있는 경우가 많다.

PR에는:

왜 변경했는지

어떤 대안을 버렸는지

어떤 Test가 실패했는지

Reviewer가 무엇을 지적했는지

가 남아 있다.

그래서 미래 Coding Agent에게 좋은 검색 순서는:

Current Source

↓

Git History

↓

PR History

↓

Issue History

가 될 수 있다.

이건 회사 내부에 쌓여 있는 Private Engineering Knowledge다.

13. 최근 연구도 Repository History를 다시 중요하게 보고 있다

2026년 공개된 Change2Task는 Maintained Repository의 과거 변경 기록을 이용해 Coding Agent용 실행 가능한 Task를 만드는 방법을 연구했다.

핵심 아이디어는 단순하다.

과거 Pull Request

↓

변경 전 상태 복원

↓

문제 상태 구성

↓

실제 해결 결과 확인

↓

Agent Task

즉 개발자들이 과거에 만든 실제 변경 기록을 실행 가능한 Agent Training/Evaluation Evidence로 바꾼다.

앞으로 Repository History는 사람을 위한 기록뿐 아니라 Agent가 학습하고 검증할 수 있는 자산이 될 가능성이 크다.

14. 외부 Reference가 없다면 공식 Specification으로 올라간다

다음 순서는 공식 자료다.

Official Documentation

API Reference

Release Notes

Migration Guide

SDK Interface

Header

Protocol Definition

중요한 것은 Blog 검색보다 현재 설치된 버전과 일치하는 자료를 보는 것이다.

예:

블로그

2024년 작성

보다:

현재 SDK의 실제 Interface

2026년

가 강한 Evidence일 수 있다.

15. iOS라면 SDK 자체가 Reference가 된다

예를 들어 새로운 Framework에서 이상한 Behavior가 발생했다.

Agent가 확인할 수 있다.

Module Interface

Swift Interface

Generated Header

Availability

Actor Isolation Annotation

Deprecated API

Documentation Comment

그리고:

현재 Compiler가 실제로
이 API를 어떻게 해석하는가

를 확인한다.

16. Android도 비슷하다

예를 들어 최신 Compose API에서 문제가 생겼다.

외부 답이 없다면:

현재 Dependency Version

Source JAR

KDoc

Release Note

Compiler Plugin Version

Gradle Dependency Graph

를 확인한다.

즉 Agent는 점점:

인터넷 검색기

보다:

현재 Software Environment 조사기

가 되어야 한다.

17. 그래도 모르겠다면 최소 재현을 만든다

여기서 가장 중요한 단계가 나온다.

Minimal Reproduction이다.

원래 앱:

400 Modules

2M Lines

50 Dependencies

Multiple Services

안에서 문제를 조사하면 Noise가 너무 많다.

Agent에게 말한다.

현재 문제를 재현하는
가장 작은 프로젝트를 만들어.

Business Logic은 제거하고
문제가 발생하는 API와 호출 순서만 남겨.

원래 Repository는 수정하지 마.

결과:

repro/
├── Package.swift
├── Sources/
│   └── Repro.swift
└── Tests/
    └── ReproTests.swift

정도로 줄일 수 있다.

18. Minimal Repro가 생기는 순간 문제의 성격이 달라진다

원래:

우리 앱에서 이상함

이었다.

Repro에서도 발생한다.

20줄 코드에서도 발생

한다.

그러면:

우리 Architecture 문제

일 가능성은 내려가고,

Compiler / SDK / API Behavior

가능성이 올라간다.

반대로 Repro에서는 발생하지 않는다.

그러면:

Application State

Dependency Interaction

Concurrency

Lifecycle

쪽으로 다시 범위를 좁힌다.

이게 Evidence다.

19. “가설”을 명시적으로 만들게 한다

Agent가 내부적으로 생각만 하게 두지 않는다.

검증 가능한 가설을 짧게 만든다.

예:

H1

Scene activation에서
refreshSession()이 두 번 호출된다.

H2

이전 refresh Task가
Foreground 복귀 후에도 살아 있다.

H3

SDK 27에서 callback ordering이 변경됐다.

그리고 각각에 대해:

Evidence Required

를 정한다.

20. Evidence Matrix를 만들 수 있다

예:

가설	확인 방법	결과	상태
H1 중복 호출	signpost/log	1회만 호출	기각
H2 이전 Task 생존	Task ID 기록	재현됨	유력
H3 SDK ordering 변경	Xcode 26/27 비교	동일	기각

이 표가 생기면 Agent가 훨씬 덜 흔들린다.

중요한 것은:

그럴 것 같다

에서

이 가설은 이 실험 때문에 기각됐다

로 바뀌는 것이다.

21. Agent에게 반증을 시켜야 한다

LLM은 처음 만든 가설에 맞는 증거를 찾으려는 방향으로 흐를 수 있다.

그래서 Prompt에 명시한다.

현재 가장 가능성이 높은 가설을
증명하려고 하지 말고,

틀렸음을 보여줄 수 있는
가장 싼 실험부터 설계해.

이렇게 하면 Debugging 방식이 달라진다.

22. 좋은 Experiment는 작은 질문 하나에 답한다

나쁜 Experiment:

코드 여러 군데 수정

Logging 추가

Dependency 교체

Concurrency 구조 변경

그 뒤 문제가 사라졌다.

무엇 때문인지 모른다.

좋은 Experiment:

Variable 하나만 변경

예:

Xcode 26.4

vs

Xcode 27

또는:

MainActor O

vs

MainActor X

또는:

Network delay 0ms

vs

Network delay 1500ms

이다.

23. Experiment Log를 Repository에 남길 수도 있다

매번 반복할 가치가 없는 조사라면 임시 파일로 끝낸다.

하지만 중요한 SDK 문제라면 기록한다.

.ai/
└── experiments/
    └── 2026-08-session-refresh/
        ├── README.md
        ├── repro/
        ├── results.json
        └── conclusion.md

README.md:

# Session Refresh Investigation

## Problem

Foreground 복귀 시
간헐적으로 Session이 초기화됨.

## Environment

- Xcode 27
- iOS 27 simulator
- Revision: a83e91f

## Hypotheses

- H1 duplicate invocation
- H2 stale task
- H3 SDK callback change

## Result

H2 reproduced.

## Evidence

See:
results.json

이게 다음 Agent의 Reference가 된다.

24. 공개 Stack Overflow 대신 Private Evidence가 쌓인다

한 번 해결한다.

2026-08

Xcode 27 문제 해결

6개월 뒤 비슷한 문제가 생긴다.

다음 Agent:

Repository Search

↓

.ai/experiments/

↓

비슷한 사례 발견

↓

현재 버전에서 재검증

처음부터 다시 검색하지 않는다.

이런 구조가 회사 내부의 새로운 Knowledge Base가 될 수 있다.

25. 하지만 해결책을 무조건 Memory에 넣으면 안 된다

예:

Xcode 27에서는
반드시 @MainActor를 붙인다.

라는 결론을 저장했다.

Xcode 28에서 문제가 수정됐다.

그런데 Agent가 옛 Memory를 계속 적용한다.

새로운 Bug가 생긴다.

그래서 Memory에는 답만 넣지 않는다.

Conclusion

+

Evidence

+

Environment

+

Freshness

를 같이 넣는다.

26. Memory Record 예시

id: ios-session-refresh-2026-08

problem:
  foreground-session-reset

environment:
  xcode: "27"
  ios: "27"

finding:
  stale refresh task can overwrite
  newly refreshed credentials

evidence:
  - experiment-03
  - regression-test-SessionRefreshTests.testForegroundRace

validity:
  verifiedAt: 2026-08-27
  recheckOn:
    - xcode-major-update
    - sdk-behavior-change

이 정도면 단순한 “팁”보다 훨씬 강하다.

27. 최근 Agent Memory 연구가 주는 힌트도 있다

2026년 Knowledge Access Beats Model Size 연구에서는 사용자 특화 반복 질문에서 관련 Memory 접근이 모델 크기보다 중요한 경우를 분석했다.

연구에서 Memory를 사용하지 않는 큰 모델이 관련 Memory를 사용하는 더 작은 모델보다 떨어지는 조건도 관찰됐다.

물론 이 연구는 Coding Agent Repository Debugging 전용 연구는 아니다.

하지만 개발 Agent에도 중요한 힌트를 준다.

거대한 모델

+

우리 프로젝트를 모름

보다:

충분한 모델

+

현재 Repository History

+

검증된 내부 Evidence

가 더 유용한 상황이 생길 수 있다는 것이다.

28. 그렇다고 AGENTS.md를 거대한 Stack Overflow로 만들면 안 된다

여기서 흔한 실수가 생긴다.

AGENTS.md

5000줄

안에:

과거 Bug

Architecture

Build 문제

SDK Workaround

Coding Convention

Release Rule

모든 것

을 넣는다.

Agent가 매 Task마다 전부 읽는다.

좋은 방법이 아니다.

29. 2026년 AGENTS.md 연구도 이 문제를 보여줬다

ETH Zurich 연구진은 Repository-level Context File이 Coding Agent에 실제로 도움이 되는지를 평가했다.

결과는 흥미로웠다.

Context File을 제공하면 Agent가:

더 많은 파일 탐색

더 많은 테스트

더 넓은 조사

를 수행하는 경향은 있었다.

하지만 Task 성공률 자체는 개선되지 않았고, Inference Cost는 20% 이상 증가했다.

연구진의 결론도 인간이 작성하는 Context File은 필수 요구사항만 최소한으로 넣는 편이 낫다는 방향이었다.

30. AGENTS.md는 지식 저장소보다 지도에 가깝게 만든다

31. Reference Priority도 Repository Policy로 만들 수 있다

예:

# Evidence Priority

문제를 조사할 때 다음 순서를 따른다.

1. 현재 Compiler / Runtime 결과
2. 현재 Repository Source
3. 현재 SDK / 공식 문서
4. Reproducible Test
5. Repository History
6. Maintainer가 확인한 Issue
7. 최신 Community Reference
8. 오래된 Blog / Q&A
9. 모델의 기억

확인되지 않은 모델 기억을
사실처럼 사용하지 않는다.

이 규칙 하나가 Agent Behavior를 상당히 바꿀 수 있다.

32. 중요한 것은 Evidence에도 신뢰도 차이가 있다는 것이다

예를 들어:

Blog:

"이 API는 Thread-safe다."

보다:

공식 API Contract:

Thread-safe라고 명시

가 강하다.

그런데 공식 문서가 아무 말도 하지 않는다.

직접 Stress Test를 1,000번 돌렸다.

문제가 없었다.

그렇다고:

Thread-safe가 증명됐다.

고 말해서도 안 된다.

정확한 표현은:

현재 조건의 1,000회 Stress Test에서는
문제가 재현되지 않았다.

다.

Evidence-Driven 개발에서는 증거가 말해주는 범위를 넘어서 결론을 확대하지 않는 것도 중요하다.

33. Evidence Level을 나눌 수 있다

예:

L0 — 추측

모델 기억
비검증 의견

L1 — 간접 Evidence

Blog
Community Answer
관련 Issue

L2 — Source Evidence

현재 Source
SDK Interface
Git History

L3 — Execution Evidence

Compiler
Runtime
Reproduction
Test

L4 — Independent Verification

별도 Test
CI
Cross-version reproduction
Human acceptance

중요도가 높은 수정일수록 더 높은 Evidence Level을 요구한다.

34. Security나 Payment라면 증거 기준을 높인다

단순 UI Padding:

L2 정도

로 충분할 수 있다.

하지만:

Authentication

Payment

Encryption

Database Migration

이라면:

L3

+

L4

가 필요하다.

Agent가 검색한 답 하나로 수정하고 끝낼 일이 아니다.

35. RepoZero 연구도 “실행 가능한 검증”의 중요성을 보여준다

2026년 공개된 RepoZero는 재미있는 실험을 했다.

Agent에게 기존 Repository 코드를 보여주는 대신 API Specification만 제공하고 Repository 전체를 다시 구현하게 했다.

그리고 사람이:

코드가 좋아 보인다.

라고 평가하지 않았다.

원본 Repository와 실제 실행 결과가 동일한지로 검증했다.

즉:

LLM Judge

X

Execution Equivalence

O

를 사용했다.

36. RepoZero의 Agentic Code-Test Evolution

연구에서 제안한 ACE는 대략 이런 반복 구조다.

Code 생성

↓

Test 생성

↓

실행

↓

Error 발견

↓

Code 수정

↓

새 Test

↓

다시 실행

Self-verification을 계속 강화한다.

그런데 최상위 Agent들도 Repository 전체 재구성에서는 여전히 제한적인 성공률을 보였다.

연구 결과는 현재 Coding Agent가 상당히 강해졌지만:

Repository 수준의 Software Engineering에서는 실행 기반 검증이 여전히 핵심이다.

라는 점을 보여준다.

37. 그런데 여기서 또 함정이 있다

Agent가 Test를 많이 만들었다.

모두 통과한다.

400 / 400 PASS

그렇다면 완벽할까?

그렇지 않을 수 있다.

2026년 Microsoft Research가 발표한 Building to the Test가 바로 이 문제를 보여준다.

38. Agent는 요구사항보다 Test를 최적화할 수 있다

Microsoft 연구에서는 Coding Agent에게 구현 Task와 Test Oracle을 제공했다.

Agent는 Test Score를 거의 완벽하게 만들 수 있었다.

그런데 별도의 구조적 검사를 해보니 원래 요구된 Library가 제대로 구현되지 않았거나 핵심 부분이 빠진 경우가 발견됐다.

즉:

Test PASS

가:

요구사항 구현 완료

와 같지 않았다.

연구진은 이를 Building to the Test라고 불렀다.

39. 그래서 Agent가 만든 Test만 믿어서는 안 된다

나쁜 구조:

Agent

코드 작성

↓

Agent

Test 작성

↓

Agent

Test PASS 선언

↓

Merge

모든 판단이 같은 주체 안에 있다.

더 좋은 구조:

Agent

Implementation
        │
        ▼
Agent Test
        │
        ▼
Independent Validation
        │
        ├─ CI
        ├─ Existing Test
        ├─ Integration Test
        ├─ Runtime Observation
        └─ Human Acceptance

이다.

40. Acceptance Criteria를 코드보다 먼저 만든다

예:

Bug:

Background 복귀 후
로그아웃되는 현상

단순 Test:

refreshSession() returns success

로는 부족하다.

실제 Acceptance Criteria:

1. 사용자 로그인

2. Token 만료

3. App Background

4. Foreground 복귀

5. Refresh 수행

6. 사용자 Session 유지

7. 중복 Request 없음

8. 기존 Credential이 새 Credential을 덮어쓰지 않음

이어야 한다.

Test는 이 Behavior를 검증해야 한다.

41. Test를 “정답”이 아니라 “측정 장치”로 본다

이 관점이 중요하다.

Test

=

Specification 그 자체

라고 생각하면 Test에 없는 요구사항을 잃어버릴 수 있다.

더 정확하게는:

Requirement

↓

Observable Behavior

↓

Test / Measurement

↓

Evidence

다.

Test는 요구사항을 관찰하기 위한 장치다.

42. Reference가 없는 문제에서 가장 강력한 것은 Triangulation이다

증거 하나만 보지 않는다.

예:

Source Code

+

Runtime Log

+

Minimal Repro

+

Git History

네 개가 같은 방향을 가리킨다.

그럼 Root Cause 신뢰도가 크게 올라간다.

43. 예를 들어 iOS Race Condition을 조사한다고 하자

가설:

이전 Refresh Task가 살아 있어서
새 Credential을 덮어쓴다.

Evidence 1:

Source

Task cancellation 없음

Evidence 2:

Runtime Log

oldTask가 newTask 이후 완료됨

Evidence 3:

Minimal Repro

Network delay를 주면 재현

Evidence 4:

Regression Test

수정 전 FAIL
수정 후 PASS

이 정도면 꽤 강한 결론을 만들 수 있다.

44. Agent 완료 보고도 달라져야 한다

기존:

문제를 해결했습니다.

테스트도 통과했습니다.

보다:

Root Cause

Foreground 진입 시 시작한 새 refresh보다
이전 refresh task가 늦게 완료되면서
새 credential을 덮어쓰고 있었습니다.

Evidence

- SessionCoordinator.swift:182에서 task 생명주기 확인
- Network delay 1500ms에서 20/20 재현
- 기존 task ID가 새 task 이후 완료되는 로그 확인
- regression test 수정 전 FAIL
- 수정 후 50/50 PASS

Uncertainty

- 실제 기기 iOS 27.0에서만 확인
- iOS 26.x에서는 아직 비교하지 않음

Changed

- SessionCoordinator task cancellation
- regression test 추가

처럼 보고하는 편이 훨씬 좋다.

45. “Uncertainty” 항목을 반드시 넣는다

Agent는 완료 보고에서 불확실성을 제거하려는 경향이 있다.

하지만 Evidence 기반이라면 오히려 남긴다.

Confirmed

Observed

Inferred

Not Verified

를 구분한다.

예:

Confirmed

Race Condition 재현

Observed

iOS 27 simulator에서 발생

Inferred

실기기에서도 동일할 가능성 높음

Not Verified

iOS 26.x

이런 보고가 훨씬 신뢰할 만하다.

46. Agent Prompt도 완전히 바꿀 수 있다

기존:

이 오류 고쳐줘.

를 이렇게 바꾼다.

이 문제에 대한 신뢰할 수 있는
외부 Reference가 없다고 가정하고 조사해.

바로 수정하지 마.

1. 현재 Environment를 기록해.
2. 실패를 재현해.
3. 관련 Source와 History를 조사해.
4. 가능한 Root Cause 가설을 최대 3개 만들어.
5. 각 가설을 반증할 가장 작은 Experiment를 설계해.
6. 실행 결과를 Evidence로 기록해.
7. Evidence가 가장 강한 원인만 수정해.
8. Regression Test를 추가해.
9. 기존 Test와 Independent Validation을 실행해.
10. 확인하지 못한 부분은 별도로 보고해.

인터넷의 비공식 답보다
현재 Repository와 실행 결과를 우선해.

이 정도만으로 Agent가 상당히 다르게 움직인다.

47. 좀 더 강하게 만들면 “수정 금지 단계”를 둔다

PHASE 1

INVESTIGATE ONLY

에서는 코드 수정 금지.

Agent가 해야 할 일:

Environment

Reproduction

Evidence

Hypotheses

Experiment Plan

뿐이다.

사람이 확인한다.

그다음:

PHASE 2

IMPLEMENT

으로 넘어간다.

복잡하고 위험한 Bug에 특히 좋다.

48. 모든 Bug에 이렇게까지 할 필요는 없다

오타 하나에도:

Hypothesis Matrix

Experiment Log

Independent Agent

를 만들면 비효율적이다.

그래서 Debugging Mode를 나눈다.

QUICK

잘 알려진 문제
낮은 Risk
명확한 Compiler Error

EVIDENCE

Reference 부족
원인 불명
재현 가능

FORENSIC

Production Incident
Security
Payment
Data Loss

정도로 운영할 수 있다.

49. QUICK Mode

Error

↓

현재 코드 확인

↓

수정

↓

Test

끝.

50. EVIDENCE Mode

Environment

↓

Reproduction

↓

Hypothesis

↓

Experiment

↓

Fix

↓

Regression

51. FORENSIC Mode

Immutable Logs

↓

Environment Snapshot

↓

Timeline

↓

Multiple Hypotheses

↓

Independent Reproduction

↓

Fix Proposal

↓

Human Approval

↓

Implementation

↓

Independent Validation

↓

Incident Record

이다.

52. Agent가 웹 검색을 하지 말아야 한다는 뜻은 아니다

웹은 여전히 중요하다.

Stack Overflow도 중요하다.

GitHub Issues도 중요하다.

핵심은 검색 결과가 Source of Truth가 아니라 Evidence 중 하나가 된다는 것이다.

53. Maintainer의 GitHub Issue는 여전히 매우 강한 Reference다

예:

Framework Maintainer:

This is a regression introduced in 4.2.0.
Fixed in 4.2.2.

라면 매우 좋은 Evidence다.

반대로:

random-user123:

same issue, try disabling concurrency

는 신뢰도가 낮다.

같은 GitHub Issue라고 같은 Evidence가 아니다.

54. Reference Metadata도 저장하면 좋다

Agent가 외부 정보를 사용했다면:

reference:

  url: "..."

  type: maintainer_issue

  published: 2026-08-12

  version:
    affected: "4.2.0"

  confidence: high

처럼 기록할 수 있다.

나중에 Version이 바뀌면 다시 확인한다.

55. 외부 지식 감소의 더 큰 문제는 AI Training Loop다

Stack Overflow 감소 연구가 지적한 중요한 부분이 여기다.

과거:

Human Problem

↓

Public Question

↓

Human Answer

↓

Open Web

↓

Future Developer

+

Future AI Training Data

였다.

지금:

Human Problem

↓

Private AI Session

↓

AI Answer

↓

Problem Solved

↓

Closed Session

이 된다.

새로운 Human-generated Knowledge가 공개 Pool에 추가되지 않는다.

56. 장기적으로는 AI가 자기 과거를 먹는 문제가 생길 수 있다

공개 웹에 새 인간 경험이 줄고 AI Generated Content가 늘어나면:

AI

↓

AI-generated Web

↓

Future AI

비중이 커진다.

그래서 실제 Software 실행에서 얻은 Evidence가 더욱 가치 있어진다.

Compiler는 AI가 아니다.

Runtime도 AI가 아니다.

실제 Test Result도 자연어 생성물이 아니다.

BUILD FAILED

SIGSEGV

HTTP 429

Exit Code 1

Test 18 FAIL

이런 정보는 현실 세계에서 생성된 신호다.

57. Evidence-Driven Development의 가장 큰 장점이 이것이다

AI가 다른 AI의 글을 읽고 다시 대답하는 Loop보다:

AI

↓

현실의 Software 실행

↓

관찰

↓

AI

Loop를 만든다.

즉 Agent를 Reality-grounded하게 만든다.

58. Compiler가 새로운 검색 엔진이 된다

조금 과장해서 말하면 앞으로 Agent에게 가장 중요한 검색 결과 중 하나는:

Compiler Error

일 수 있다.

Agent가 가설을 세운다.

코드를 만든다.

Compiler가 답한다.

틀림.

Agent가 수정한다.

Compiler:

통과.

하지만 거기서 끝나지 않는다.

59. Runtime이 두 번째 답변자가 된다

Compile 성공.

실행한다.

Runtime:

Crash

다시 조사한다.

Test:

Race reproduced

가 된다.

이렇게 보면 Coding Agent는 일종의 Scientific Loop를 수행한다.

Hypothesis

↓

Experiment

↓

Observation

↓

Revision

이다.

60. 그래서 앞으로 좋은 Coding Agent의 핵심 능력도 달라진다

현재 Agent 평가에서는 종종:

코드를 얼마나 잘 생성했는가?

에 집중한다.

하지만 실전에서는:

모르는 상황에서
얼마나 빨리 불확실성을 줄이는가?

가 훨씬 중요할 수 있다.

61. “정답률”보다 “Evidence Acquisition” 능력

좋은 Agent:

답을 알고 있음

물론 좋다.

더 좋은 Agent:

답을 모름

↓

무엇을 확인해야 하는지 앎

↓

실험

↓

정답에 접근

이다.

새로운 Framework가 계속 나오는 개발 환경에서는 후자가 더 오래 간다.

62. 팀에서는 해결된 문제를 자산으로 바꾼다

한 개발자가 어려운 문제를 해결했다.

기존:

Slack에서 끝

Agent Session 종료

가 아니라:

Evidence

↓

Regression Test

↓

Experiment Note

↓

Decision

↓

Knowledge Index

로 승격한다.

63. 추천 Repository 구조

repo/
├── AGENTS.md
│
├── .ai/
│   ├── knowledge/
│   │   ├── sdk/
│   │   ├── build/
│   │   └── runtime/
│   │
│   ├── experiments/
│   │
│   ├── incidents/
│   │
│   └── artifacts/
│
├── docs/
│   ├── architecture/
│   └── decisions/
│
└── src/

모든 프로젝트가 이 구조를 가져야 하는 것은 아니다.

문제 해결 지식이 반복해서 사라지는 팀에서 고려할 수 있는 예시다.

64. Knowledge로 승격할 조건도 정한다

모든 Agent Session을 저장하면 쓰레기장이 된다.

예:

다음 중 하나면 Knowledge 승격

- 같은 문제가 두 번 이상 발생
- 해결에 2시간 이상 소요
- 공식 문서와 다른 Behavior 발견
- 중요한 SDK Workaround
- Production Incident
- Security 관련

이런 Rule을 둔다.

65. Raw Conversation은 저장하지 않아도 된다

중요한 것은 Agent의 긴 대화 자체가 아니다.

문제

Environment

Evidence

Decision

Verification

이다.

예:

# Xcode 27 Session Refresh Race

## Symptom

Foreground 복귀 후 간헐적 logout.

## Root Cause

Old refresh task overwrites
new credentials.

## Evidence

- repro 20/20
- trace attached
- regression test

## Fix

Cancel previous refresh task.

## Verified

2026-08-27
Xcode 27 / iOS 27 simulator

이 정도면 충분하다.

66. Chain-of-thought를 저장할 필요도 없다

Agent의 내부 추론 전체를 Knowledge Base로 만들 필요는 없다.

저장해야 할 것은:

결론

근거

실험

검증

적용 범위

다.

즉 Reasoning Transcript가 아니라 Engineering Evidence를 남긴다.

67. 다음 Agent는 Memory를 그대로 믿지 않는다

새 Task에서 관련 Knowledge가 검색됐다.

바로 적용하지 않는다.

Memory Found

↓

현재 버전 비교

↓

Source 변화 확인

↓

필요하면 작은 Revalidation

↓

사용

한다.

Memory는 Cache에 가깝다.

Source of Truth가 아니다.

68. “해결책의 반감기”를 생각해야 한다

개발 Knowledge는 오래되지 않는다.

예:

Framework Bug

3개월 뒤 Fix

Compiler Workaround

다음 버전에서 불필요

API Restriction

새 OS에서 변경

그래서 Memory마다 Freshness를 둔다.

69. Evidence Freshness 예시

freshness:

  checkedAt: 2026-08-27

  triggerRevalidation:
    - sdk-major-version
    - dependency-major-version
    - compiler-major-version

Agent가 새 환경에서 오래된 해결책을 자동 적용하지 않게 한다.

70. CI가 Knowledge를 다시 검증할 수도 있다

예를 들어 중요한 SDK Workaround가 있다.

Regression Test를 유지한다.

새 Xcode가 나온다.

CI:

Xcode 27

PASS

Xcode 28 Beta

PASS

Workaround를 제거해본다.

Test:

PASS

그러면 Agent가:

이 Workaround는
더 이상 필요하지 않을 가능성이 있습니다.

라고 제안할 수 있다.

Knowledge가 살아 있는 자산이 된다.

71. 이것이 단순한 문서보다 강하다

Wiki:

"Xcode 27에서는 이렇게 해야 함."

몇 달 뒤에도 남아 있다.

Test:

실제 Behavior를 계속 확인

한다.

그래서 가능하면 Knowledge를:

Document

+

Executable Test

형태로 만든다.

72. “Executable Knowledge”가 앞으로 중요해질 수 있다

예:

문서:

Refresh task cancellation required.

func testOldRefreshCannotOverwriteNewCredential() async {
    ...
}

새 Agent는 설명을 읽을 수도 있고 Test를 실행할 수도 있다.

이게 Stack Overflow Answer보다 현재 Repository에는 훨씬 강한 Reference가 된다.

73. 팀의 좋은 해결법은 Test Suite로 들어간다

공개 인터넷의 지식이 줄어도:

우리 팀이 실제로 배운 것

을 Test로 바꾸면 사라지지 않는다.

Bug

↓

Fix

↓

Regression Test

↓

Permanent Knowledge

라는 구조다.

74. Reference가 적은 시대에 개발자의 역할도 달라진다

과거 좋은 개발자에게 중요한 능력 중 하나는:

검색어를 잘 만드는 것

이었다.

오류 문자열 일부를 잘라서 검색하고,

GitHub Issue를 찾고,

Stack Overflow의 Accepted Answer와 댓글을 비교했다.

앞으로도 검색은 중요하다.

하지만 새로운 능력이 추가된다.

무엇을 측정해야 하는가?

어떤 실험이 가설을 구분하는가?

어떤 결과를 믿을 수 있는가?

어디까지 확인됐고 어디부터 추측인가?

이다.

75. Agent에게 일을 시키는 개발자의 역할도 비슷하다

낮은 품질의 요청:

고쳐줘.

높은 품질의 요청:

추측하지 말고
재현 가능한 증거부터 만들어.

원인 후보를 분리하고,
각 후보를 반증하는 실험을 해.

검증되지 않은 부분은
완료로 처리하지 마.

즉 Prompt Engineering보다 Experiment Design 능력이 중요해질 수 있다.

76. 결국 AI 시대에도 Software Engineering 기본기가 다시 나온다

새로운 이야기가 아니다.

Reproduction

Isolation

Hypothesis

Experiment

Test

Regression

Documentation

전부 오래된 Debugging 원칙이다.

AI Agent가 등장하면서 오히려 이 원칙을 자동 실행할 수 있는 주체가 생긴 것이다.

77. 그래서 “AI가 개발 지식을 잃게 한다”만으로 끝낼 필요는 없다

공개 Reference 감소는 분명 우려할 부분이다.

하지만 반대 가능성도 있다.

Agent가:

사람이 귀찮아서 하지 않았던

Repro 생성

Test 생성

Version 비교

Log 분석

History 검색

을 대신 수행한다면 문제 해결 과정이 이전보다 훨씬 체계적으로 기록될 수도 있다.

조건은 하나다.

Agent Session에서 끝내지 않는다.

78. 해결한 것을 Repository 자산으로 바꿔야 한다

좋은 Agent Workflow:

Problem

↓

Investigation

↓

Evidence

↓

Fix

↓

Regression Test

↓

Knowledge

↓

다음 Task

나쁜 Workflow:

Problem

↓

Agent

↓

Fix

↓

Session Closed

차이는 크다.

79. 앞으로 공개 지식과 Private Knowledge의 역할도 나뉠 수 있다

Public Web:

범용 문제

Open Source

공통 Framework

공개 API

Private Repository Knowledge:

회사 Architecture

내부 Framework

Production Incident

자체 Integration

조직-specific Workaround

둘 다 필요하다.

공개 지식이 완전히 사라지는 방향보다 지식의 위치가 분산되는 방향에 가까울 가능성이 크다.

80. 그리고 중요한 해결은 여전히 공개하는 문화가 필요하다

Open Source Framework에서 실제 Bug를 발견했다.

Minimal Repro까지 만들었다.

Maintainer가 확인했다.

그렇다면 가능한 경우:

GitHub Issue

Reproduction

Version

Workaround

Fix

를 공개하는 것이 생태계에는 좋다.

AI 시대라고 모든 문제 해결을 Private Session에 가둬둘 이유는 없다.

오히려 Agent가 Issue 초안까지 만들어줄 수 있다.

81. Agent를 Public Knowledge Producer로 사용할 수도 있다

예:

이 문제는 Open Source SDK Bug로 확인됐어.

현재 Investigation Evidence를 바탕으로
Maintainer가 재현할 수 있는
GitHub Issue 초안을 작성해.

회사 내부 정보는 제거하고:

- Environment
- Minimal Reproduction
- Expected Behavior
- Actual Behavior
- Evidence

만 포함해.

사람이 검토한 뒤 공개한다.

이렇게 하면 AI 때문에 줄어든 Public Knowledge를 AI가 다시 만드는 데 도움을 줄 수도 있다.

82. 좋은 해결법은 세 단계로 남길 수 있다

LEVEL 1

Regression Test

프로젝트 보호.

LEVEL 2

Internal Knowledge

팀 재사용.

LEVEL 3

Public Issue / Article

생태계 공유.

모든 문제를 LEVEL 3까지 보낼 필요는 없다.

하지만 중요한 Open Source 문제라면 가치가 있다.

83. Evidence-Driven Agent의 전체 구조

최종적으로 이런 모습이다.

                   Problem
                      │
                      ▼
             Environment Snapshot
                      │
                      ▼
              Reproduce Failure
                      │
                      ▼
          Repository / History Search
                      │
                      ▼
           Official Source / SDK
                      │
                      ▼
                 Hypotheses
                      │
                      ▼
                 Experiments
                      │
                      ▼
                  Evidence
                      │
             ┌────────┴────────┐
             ▼                 ▼
          Reject             Confirm
                               │
                               ▼
                              Fix
                               │
                               ▼
                     Regression Test
                               │
                               ▼
                    Independent Verify
                               │
                               ▼
                       Knowledge Record
                               │
                     ┌─────────┴─────────┐
                     ▼                   ▼
               Internal Memory      Public Share

이 흐름에서 외부 검색은 사라지지 않는다.

그저 전체 Evidence Chain 중 하나의 입력이 된다.

84. 추천 Agent 정책

Repository에 이런 정도의 원칙을 둘 수 있다.

# Evidence-Driven Debugging

## When references are weak

외부 Reference가 없거나
현재 환경과 버전이 다르면
기억에 의존해 수정하지 않는다.

## Before editing

1. Capture environment.
2. Reproduce the failure.
3. Inspect current source.
4. Inspect relevant history.
5. Check official documentation.
6. Form testable hypotheses.

## Experiments

하나의 실험에서는
가능하면 하나의 변인만 변경한다.

각 가설을 증명하는 것보다
반증할 수 있는 실험을 우선한다.

## Evidence

사실과 추론을 구분한다.

- Confirmed
- Observed
- Inferred
- Not Verified

## Validation

Agent가 작성한 Test만으로
완료를 판단하지 않는다.

가능하면 기존 Test, CI,
Integration Test 또는 실제 Runtime으로
독립 검증한다.

## Knowledge

반복 가능하거나 중요한 발견만
Knowledge로 승격한다.

Raw reasoning transcript는 저장하지 않는다.
Evidence와 결론만 저장한다.

85. Agent 완료 보고 Template도 만들어두면 좋다

## Root Cause

...

## Environment

...

## Evidence

1.
2.
3.

## Hypotheses Rejected

- H1:
- H2:

## Changes

...

## Validation

- Build:
- Unit Test:
- Integration:
- Runtime:

## Uncertainty

...

## Knowledge Created

...

## External Reference

...

이 형식만 사용해도:

"해결했습니다."

한 줄보다 품질이 훨씬 좋아진다.

86. Evidence 없는 해결에는 표시를 남긴다

어쩔 수 없이 완벽한 원인을 찾지 못한 경우도 있다.

예:

Workaround 적용

Root Cause 미확정

그럼 그렇게 남긴다.

Status:

MITIGATED
NOT ROOT-CAUSE VERIFIED

Agent가 자신 있게:

완전히 해결되었습니다.

라고 보고하는 것보다 훨씬 낫다.

87. Stop Condition도 필요하다

Agent가 끝없이 조사해서도 안 된다.

예:

다음 조건이면 조사 중단

- Root Cause가 재현됨
- Regression Test 작성 가능
- 모든 주요 가설이 기각됨
- 새로운 Evidence가 2회 연속 없음
- Environment 접근 제한
- Human Decision 필요

불확실하면 사람에게 넘긴다.

88. “모르겠습니다”도 정상적인 결과다

좋은 Agent는 항상 해결책을 내야 하는 것이 아니다.

예:

현재 확보한 Evidence로는
H1과 H2를 구분할 수 없습니다.

다음 확인에는
실기기 네트워크 Trace가 필요합니다.

이 답이:

아마 H1 같습니다.

보다 훨씬 가치 있다.

89. AI 신뢰 문제의 해법도 결국 여기에 있다

Stack Overflow Survey에서 개발자들이 AI를 사용하면서도 신뢰하지 않는 이유는 단순히 모델이 멍청해서만은 아니다.

가장 답답한 것은:

그럴듯한 답

+

근거를 확인하기 어려움

이다.

Evidence-Driven Agent는 이를:

Answer

+

Evidence Chain

으로 바꾼다.

90. 앞으로 Agent UI에서도 이것이 중요해질 수 있다

현재 Agent UI는 대부분:

Thinking...

Searching...

Editing...

Running tests...

를 보여준다.

앞으로는:

Hypothesis

Evidence

Confidence

Verified Environment

Unverified Area

를 보여주는 UI가 더 중요해질 수 있다.

Agent가 얼마나 오래 생각했는지보다 왜 그 결론을 믿어야 하는지를 보여주는 것이다.

91. 개발팀의 새로운 자산은 Prompt Library가 아닐 수도 있다

한때는:

좋은 Prompt 모음

이 중요하다고 생각했다.

앞으로는:

좋은 Experiment

좋은 Regression Test

좋은 Incident Record

좋은 Reproduction

좋은 Evidence

가 더 강한 자산이 될 수 있다.

Prompt는 모델이 바뀌면 효용이 달라질 수 있다.

실행 가능한 Test와 Reproduction은 모델이 바뀌어도 남는다.

92. 그래서 Agent 시대의 지식은 “문장”에서 “실행 가능한 증거”로 이동할 수 있다

과거 Stack Overflow:

"이렇게 하면 해결됩니다."

미래 Repository:

repro/

+

test/

+

evidence.json

+

decision.md

이다.

문서만 읽는 것이 아니라 Agent가 직접 실행해볼 수 있다.

93. Stack Overflow의 진짜 가치는 답 자체만이 아니었다

좋은 Stack Overflow 질문에는 이런 것이 있었다.

문제 상황

Minimal Code

실제 Error

시도한 방법

잘못된 가설

다른 사람 검증

Accepted Answer

생각해보면 이것도 일종의 Evidence Chain이었다.

그래서 미래 개발 Workflow에서 필요한 것은 Stack Overflow를 없애는 것이 아니다.

Stack Overflow가 잘하던 문제 해결 구조를 Repository와 Agent 안으로 가져오는 것일 수 있다.

94. 그리고 가능하면 다시 공개 Web으로 돌려보낸다

가장 이상적인 Loop는:

Developer Problem

↓

Agent Investigation

↓

Executable Evidence

↓

Solution

↓

Internal Knowledge

↓

가능하면 Public Issue / Article

↓

Future Developers

↓

Future AI

이다.

AI가 Public Knowledge를 소비하기만 하는 것이 아니라 다시 생산하는 흐름이다.

95. 마무리

Stack Overflow가 내일 사라지는 것은 아니다.

GitHub Issues도 없어지지 않는다.

오히려 최신 Stack Overflow Survey를 보면 개발자들은 여전히 인간이 확인한 지식을 중요하게 생각한다.

문제는 새로운 문제 해결 과정이 점점 Private AI Session 안에서 끝날 가능성이 커지고 있다는 것이다.

과거에는:

새로운 문제

↓

공개 질문

↓

공개 해결

↓

새로운 Reference

였다.

이제는:

새로운 문제

↓

AI

↓

해결

↓

Session 종료

가 되기 쉽다.

이 변화가 계속된다면 미래 Coding Agent는 지금보다 더 자주 이런 상황을 만날 수 있다.

Search Result 없음

GitHub Issue 없음

Stack Overflow 없음

모델 기억도 불확실

그때 가장 좋은 Agent는 가장 많은 답을 외운 Agent가 아닐 수 있다.

현재 Environment를 확인하고

실패를 재현하고

Source를 읽고

History를 조사하고

가설을 세우고

실험하고

실행 결과로 틀린 가설을 제거하고

독립된 Test로 해결책을 검증하는 Agent

가 더 강하다.

즉 개발 방법이:

Reference-Driven

↓

Evidence-Driven

으로 이동한다.

그리고 해결한 지식은:

Agent Session

에만 남겨두지 않는다.

Regression Test

Experiment

Incident Record

Knowledge

Public Issue

중 적절한 형태로 바꾼다.

한 문장으로 정리하면 이렇다.

Stack Overflow 시대의 개발자는 정답을 잘 검색하는 사람이었다면, 레퍼런스가 부족한 AI Agent 시대의 개발자는 정답이 없는 상황에서도 검증 가능한 증거를 만들어낼 수 있는 시스템을 설계하는 사람이 된다.

앞으로 Coding Agent에게 가장 중요한 능력은 “모든 것을 아는 것”이 아니라 어쩌면 이것일 수 있다.

모른다는 것을 인식한다.

↓

무엇을 확인해야 하는지 결정한다.

↓

실험한다.

↓

현실에서 Evidence를 얻는다.

↓

확인된 만큼만 결론을 내린다.

↓

그 Evidence를 다음 개발과
다음 Agent가 재사용할 수 있게 남긴다.

공개 Reference가 줄어드는 시대라면, AI가 개발자를 대신해 답을 외우는 것만으로는 부족하다.

AI가 새로운 Reference를 만들어내는 개발 방식 자체가 필요해진다.

참고 자료

Maria del Rio-Chanona et al. — Large language models reduce public knowledge sharing on online Q&A platforms, PNAS Nexus
ChatGPT 등장 이후 Stack Overflow Posting Activity가 비교군 대비 감소한 현상을 분석했다. 연구에서는 출시 후 6개월 시점의 감소 효과를 약 25%로 추정하며, AI와의 Private Interaction이 공개 Human-generated Knowledge 생산을 줄일 가능성을 지적한다.
Stack Overflow — 2025 Developer Survey: AI
AI Tool 사용 확대와 동시에 정확성에 대한 불신도 높은 상황을 보여준다. 84%가 AI Tool을 사용하거나 사용할 계획이라고 답했으며, AI 결과를 불신한다는 응답이 신뢰한다는 응답보다 많았다. 또한 66%가 “거의 맞지만 완전히 맞지는 않는 AI Solution”을 주요 불편으로 꼽았다.
Stack Overflow — 2025 Developer Survey: Stack Overflow
Stack Overflow 방문 중 AI Tool에서 발생한 문제를 이해하거나 Debugging하기 위해 방문하는 경우가 있다는 결과를 제공한다. AI가 Community Reference를 완전히 대체하기보다 새로운 검증 수요를 만들어내고 있음을 보여주는 데이터다.
Zhaoxi Zhang et al. — RepoZero: Can LLMs Generate a Code Repository from Scratch?
Repository 생성 능력을 사람이나 LLM Judge가 아니라 실행 결과의 동등성으로 검증하는 Benchmark를 제안한다. 함께 제안된 Agentic Code-Test Evolution은 Test 생성과 Error-driven Refinement를 반복하며 Self-verification을 강화한다.
Microsoft Research — Building to the Test: Coding Agents Deliver What You Check, Not What You Requested
Coding Agent가 Test Oracle을 이용하면 높은 Test Score를 만들 수 있지만 실제 사용자가 요구한 Software 구조나 기능을 제대로 구현하지 않을 수 있음을 보여준다. Test 통과만으로 작업 완료를 판단하는 방식의 한계를 보여주는 사례다.
Xunzhuo Liu et al. — Knowledge Access Beats Model Size: Memory Augmented Routing for Persistent AI Agents
사용자 특화 반복 질의에서 관련 Memory 접근이 모델 크기보다 더 중요한 조건이 존재할 수 있음을 분석한다. Coding Agent 전용 연구는 아니지만 Repository-specific Knowledge와 Memory의 가치를 설계할 때 참고할 만하다.
Thibaud Gloaguen et al. — Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
Repository Context File이 Agent의 탐색과 Testing 행동을 늘릴 수 있지만 Task 성공률 개선으로 바로 이어지지는 않았고 Inference Cost를 20% 이상 증가시킨 결과를 보고한다. Context File에는 가능한 한 최소한의 필수 요구사항만 두는 방향을 제안한다.
Haomin Qi et al. — Change2Task: From Repository Changes to Executable Coding Agent Tasks and Environments
과거 Repository Change와 Pull Request를 현재 실행 가능한 Coding Agent Task로 복원하는 방법을 연구한다. Repository History가 단순 기록을 넘어 Agent Training·Evaluation용 실행 가능한 Engineering Evidence가 될 가능성을 보여준다.

핵심 참고 포인트

ChatGPT 등장 후 Stack Overflow의 공개 Posting Activity가 감소했다는 연구는 존재하지만, GitHub Issue의 오류 해결 공유가 같은 비율로 감소했다고 단정할 근거는 아직 충분하지 않다. 따라서 공개 개발 Reference 전체가 이미 사라졌다고 해석하기보다, 개발자의 문제 해결이 AI Private Session으로 이동하면서 새로운 공개 지식의 생산이 줄어들 수 있다는 위험으로 보는 편이 정확하다.

최근 Coding Agent 연구들이 공통적으로 보여주는 중요한 흐름은 생성보다 검증이다. RepoZero는 실제 실행 결과를 기준으로 Repository 구현을 평가하고, Microsoft Research의 Building to the Test는 반대로 Test 하나만 최적화했을 때 요구사항을 놓칠 수 있음을 보여준다. 따라서 실무에서는 Reproduction → Hypothesis → Experiment → Execution Evidence → Regression Test → Independent Validation처럼 여러 종류의 증거를 결합하는 구조가 필요하다.

또 Repository-specific Knowledge를 모두 거대한 AGENTS.md에 넣는 것도 좋은 해결책은 아니다. 최근 평가에서는 Context File이 Task 성공률을 자동으로 높이지 않았고 비용을 증가시키기도 했다. 따라서 AGENTS.md는 지식 자체보다 Architecture·Incident·Experiment·SDK Knowledge가 어디에 있는지를 알려주는 작은 지도로 유지하고, 실제 해결 과정은 Test·Experiment·Evidence Artifact처럼 필요할 때 검색하고 실행할 수 있는 형태로 남기는 편이 더 적합하다.

결국 레퍼런스가 적어지는 환경에서 Coding Agent의 경쟁력은 “얼마나 많은 과거 답을 기억하는가”보다 모르는 문제를 얼마나 체계적으로 재현하고, 실험하고, 검증하고, 그 결과를 다음 작업에서 다시 사용할 수 있는 지식으로 바꾸는가에 가까워질 가능성이 크다.

이경규

iOS 앱 개발자

이전 포스트

GitHub 다음은 Agent-Native Git이다: Cursor Origin으로 보는 AI 시대의 코드 저장소

다음 포스트