AI가 소프트웨어 개발을 재정의하는 방식

게시 2026/01/10 업데이트 2026/01/10

By BLUEBUG

62 분읽는 시간

Martin Fowler의 2026년 Fragments 심층 분석

서론: 개발의 패러다임 전환기

2026년 1월, 소프트웨어 개발의 구루 Martin Fowler가 자신의 블로그에 게재한 Fragments는 단순한 기술 트렌드 소개가 아니다. 이는 AI가 소프트웨어 개발의 본질을 어떻게 변화시키고 있는지에 대한 종합적인 관찰 기록이며, 동시에 이러한 변화가 개발자 개개인의 경력과 조직 문화, 그리고 소프트웨어 엔지니어링이라는 전문 분야 전체에 미칠 영향에 대한 깊이 있는 성찰이다.

Fowler가 주목한 핵심은 세 가지 차원으로 이해할 수 있다. 첫째는 Anthropic이라는 AI 선도 기업 내부에서 AI가 개발자들의 일상을 어떻게 바꾸고 있는지에 대한 실증적 데이터다. 둘째는 Obie Fernandez라는 개발자가 단 며칠 만에 프로덕션 수준의 복잡한 시스템을 구축한 구체적 사례다. 셋째는 이러한 변화 속에서 우리가 어떤 설계 원칙과 개발 방법론을 재고해야 하는지에 대한 이론적 프레임워크다.

제1부: Anthropic 내부의 AI 혁명 - 실증 데이터가 말하는 것

1.1 양적 변화: 생산성의 급격한 도약

Anthropic이 2025년 8월에 수행한 내부 조사는 AI가 소프트웨어 개발에 미치는 영향을 측정한 가장 포괄적인 연구 중 하나다. 132명의 엔지니어와 연구원을 대상으로 한 설문조사, 53건의 심층 인터뷰, 그리고 20만 건의 Claude Code 사용 기록 분석을 통해 도출된 결과는 놀랍다.

엔지니어들은 자신의 업무 중 평균 59%에서 Claude를 사용하고 있으며, 이를 통해 50%의 생산성 향상을 경험하고 있다고 보고했다. 이는 1년 전의 28% 사용률과 20% 생산성 향상과 비교할 때 2-3배의 증가다. 특히 주목할 점은 14%의 “파워 유저”들이 100% 이상의 생산성 증가를 보고했다는 사실이다.

그러나 Fowler가 강조하듯, 이러한 자기 보고식 생산성 지표는 신중하게 해석되어야 한다. METR(AI 연구 비영리 단체)의 연구에 따르면 익숙한 코드베이스에서 작업하는 숙련된 개발자들은 AI로 인한 생산성 향상을 과대평가하는 경향이 있다. Anthropic의 경우, 엔지니어들이 전략적으로 AI에 위임할 작업을 선택하는 능력을 발전시켰기 때문에 실제 생산성 향상이 나타난 것으로 보인다.

1.2 질적 변화: 무엇이 달라졌는가

생산성 수치보다 더 중요한 것은 일하는 방식의 근본적인 변화다. Anthropic의 데이터는 세 가지 주요 전환을 보여준다.

첫째, 개발자들이 다루는 작업의 복잡도가 증가했다. 6개월 전 Claude Code는 평균 10개의 연속적인 도구 호출 후 사람의 개입이 필요했다. 현재는 21개로 증가했으며, 이는 116%의 자율성 향상을 의미한다. 작업 복잡도 점수도 1-5 척도에서 3.2에서 3.8로 상승했다. 3.2는 “Python 모듈 임포트 오류 해결” 수준이었다면, 3.8은 “캐싱 시스템 구현 및 최적화” 수준이다.

둘째, 작업의 성격이 변화했다. 코드 설계 및 기획이 1%에서 10%로, 새로운 기능 구현이 14%에서 37%로 급증했다. 반면 디버깅과 코드 이해는 여전히 가장 빈번한 작업(각각 55%, 42%가 매일 사용)이지만, 더 복잡한 창조적 작업에 AI를 활용하는 비율이 크게 증가했다.

셋째, 이전에는 하지 않았을 작업이 가능해졌다. 엔지니어들은 Claude의 도움으로 수행한 작업 중 27%가 AI 없이는 수행하지 않았을 것이라고 응답했다. 여기에는 프로젝트 확장, 대화형 데이터 대시보드 같은 “있으면 좋은” 도구, 문서화 및 테스트 같은 유용하지만 지루한 작업, 그리고 수동으로 하기에는 비용 효율적이지 않은 탐색적 작업이 포함된다.

1.3 개발자들의 전략적 위임 패턴

Anthropic 엔지니어들은 어떤 작업을 AI에 맡기고 어떤 작업을 직접 수행하는지에 대한 명확한 직관을 발전시켰다. 인터뷰에서 드러난 위임 패턴은 다음과 같다.

AI에 위임하기 좋은 작업:

컨텍스트 밖이면서 복잡도가 낮은 작업: “내가 잘 모르지만 전체적으로 복잡하지 않은 일”
쉽게 검증 가능한 작업: “검증 노력이 생성 노력에 비해 크지 않은 모든 것”
명확하게 정의되거나 독립적인 작업: “프로젝트의 하위 구성요소가 나머지와 충분히 분리되어 있으면”
코드 품질이 중요하지 않은 작업: “일회성 디버깅이나 연구용 코드라면”
반복적이거나 지루한 작업: “그 작업을 하고 싶은 마음이 클수록 Claude를 쓰지 않을 가능성이 높다”

직접 수행하는 작업:

높은 수준의 전략적 사고가 필요한 작업
조직 컨텍스트나 “취향”이 필요한 설계 결정
복잡한 아키텍처 결정
보안이나 성능이 극도로 중요한 작업

한 보안 엔지니어는 Claude가 제안한 솔루션이 “재능 있는 주니어 엔지니어가 제안할 법한, 위험한 방식으로 영리한” 것이었다고 지적했다. 이는 경험과 판단력으로만 문제를 인식할 수 있는 종류의 것이었다.

1.4 기술 역량의 양면성: 확장과 위축

AI 도구의 도입은 개발자들의 기술 역량에 복잡한 영향을 미치고 있다.

역량의 확장: 많은 엔지니어들이 이전에는 시도하지 않았을 영역으로 진출하고 있다. 백엔드 엔지니어가 복잡한 UI를 구축하고, 연구원이 데이터 시각화를 만들며, 모든 사람이 더 “풀스택”이 되어가고 있다. 한 백엔드 엔지니어는 “디자이너들이 ‘이걸 당신이 만들었다고?’라고 했다. 나는 ‘아니요, Claude가 만들었어요. 저는 그냥 프롬프트를 줬을 뿐이에요’라고 답했다”고 말했다.

역량의 위축 우려: 그러나 동시에 “사용하지 않으면 잃어버린다”는 우려도 커지고 있다. 한 엔지니어는 “어려운 이슈를 직접 디버깅하려면 문서와 코드를 읽는 시간이 필요하고, 그 과정에서 문제 해결에 직접 유용하지 않은 정보도 접하면서 시스템이 어떻게 작동하는지 모델을 구축하게 된다. 하지만 Claude가 바로 문제로 안내해주면 그런 일이 훨씬 덜 일어난다”고 지적했다.

특히 시니어 엔지니어들은 “감독의 역설”을 우려한다. Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과다 사용으로 위축될 수 있는 바로 그 코딩 능력이 필요하다는 것이다. 한 엔지니어는 “내 기술이 위축되는 것보다 감독과 관리 문제가 훨씬 더 걱정된다”고 말했다.

1.5 소프트웨어 엔지니어링의 미래: 더 높은 추상화 수준으로?

이러한 변화가 소프트웨어 엔지니어링이라는 직업의 미래에 무엇을 의미하는지에 대해 엔지니어들의 의견은 갈린다.

일부는 이것을 추상화 수준의 자연스러운 상승으로 본다. 초기 프로그래머들은 기계에 훨씬 더 가까이 작업했다 - 메모리를 수동으로 관리하고, 어셈블리 언어로 작성하거나, 심지어 물리적 스위치를 토글해서 명령을 입력했다. 시간이 지나면서 복잡한 저수준 작업을 자동으로 처리하는, 더 인간 친화적인 고수준 언어가 등장했다. “vibe coding”의 부상과 함께, 우리는 이제 영어를 프로그래밍 언어로 사용하는 단계로 이동하고 있을지도 모른다.

한 직원은 이러한 전환이 “최종 제품과 최종 사용자에 대해” 코드가 아닌 더 높은 수준에서 생각할 수 있게 한다고 말했다. 다른 이는 컴퓨터 과학에서 연결 리스트를 배웠던 것에 비유했다 - 이제는 고수준 프로그래밍 언어가 자동으로 처리하는 기본 구조다. “그것을 어떻게 하는지 아는 것이 기뻤지만… 그런 저수준 작업을 하는 것은 감정적으로 특별히 중요하지 않다. 코드가 나에게 무엇을 할 수 있게 하는지가 더 중요하다.”

그러나 다른 이들은 진정한 상실을 느낀다. “내 시대의 종말이다 - 나는 25년간 프로그래밍을 해왔고, 그 기술에서 유능하다고 느끼는 것이 내 직업적 만족의 핵심 부분이다.” 또 다른 이는 “하루 종일 Claude에게 프롬프트를 주는 것은 그다지 재미있거나 보람 있지 않다. 음악을 틀고 몰입해서 무언가를 직접 구현하는 것이 훨씬 더 재미있고 보람 있다”고 말했다.

1.6 팀 역학의 변화: 협업에서 AI 위임으로

AI 도입의 가장 예상치 못한 영향 중 하나는 팀 내 사회적 역학의 변화다.

Claude는 이전에 동료에게 갔을 질문의 첫 번째 목적지가 되었다. “이제 훨씬 더 많은 질문을 하지만, 그 중 80-90%는 Claude에게 간다”고 한 직원이 말했다. 이는 Claude가 일상적인 질문을 처리하고, 동료들은 AI의 능력을 넘어서는 더 복잡하고 전략적이거나 컨텍스트가 많이 필요한 문제를 다루는 필터링 메커니즘을 만들어낸다.

약 절반은 팀 협업 패턴이 변하지 않았다고 보고했다. 그러나 다른 이들은 동료와의 상호작용이 줄어들었다고 설명했다. 일부는 사회적 마찰이 줄어든 것을 높이 평가한다(“동료의 시간을 빼앗는다는 기분이 들지 않는다”). 다른 이들은 변화를 거부하거나(“사실 ‘Claude에게 물어봤어?’라는 흔한 대답이 별로 좋지 않다. 나는 사람들과 직접 일하는 것을 정말 좋아하고 그것을 매우 중요하게 여긴다”) 예전 방식을 그리워한다(“사람들과 일하는 것을 좋아하는데 이제 그들을 덜 ‘필요로’ 하게 되어 슬프다”).

전통적인 멘토링 역학에도 영향이 있다. “Claude가 주니어 직원에게 많은 코칭을 제공할 수 있기” 때문에 시니어 엔지니어 대신 AI가 그 역할을 하는 경우가 많다. 한 시니어 엔지니어는 “더 주니어인 사람들이 예전만큼 자주 질문하러 오지 않아 슬프다. 하지만 그들은 확실히 질문에 대한 답을 더 효과적으로 얻고 더 빨리 배운다”고 말했다.

1.7 경력 불확실성과 적응

많은 엔지니어들이 자신의 역할이 코드 작성에서 AI 관리로 전환되고 있다고 설명한다. 한 엔지니어는 자신의 업무가 “70% 이상 순수 코드 작성자에서 코드 검토자/수정자로” 전환되었다고 추정했고, 다른 이는 “1개, 5개, 또는 100개의 Claude에 대한 책임을 지는 것”을 미래 역할의 일부로 본다.

장기적으로는 경력 불확실성이 광범위하다. 엔지니어들은 이러한 변화를 더 광범위한 산업 변혁의 전조로 보았으며, 많은 이들이 몇 년 후 자신의 경력이 어떻게 될지 “말하기 어렵다”고 답했다. 일부는 단기 낙관론과 장기 불확실성 사이의 갈등을 표현했다. “단기적으로는 낙관적이지만 장기적으로는 AI가 결국 모든 것을 하게 되어 나와 많은 다른 사람들을 무관하게 만들 것이라고 생각한다”고 한 사람이 말했다. 다른 이들은 더 직설적이다: “매일 출근해서 나 자신을 실업자로 만드는 것 같은 기분이다.”

그러나 일부 엔지니어들은 더 낙관적이다. “주니어 개발자들이 걱정되지만, 주니어 개발자들이 새로운 기술에 가장 목마른 사람들이라는 것도 안다. 나는 이 직업의 궤적에 대해 전반적으로 매우 낙관적이다”라고 한 사람이 말했다.

제2부: 실전 사례 - Obie Fernandez의 Nexus 프로젝트

What Used to Take Months Now Takes Days - Building production software with Claude Code while doing my day job

2.1 프로젝트 개요: 무엇을 만들었는가

Obie Fernandez는 2025년 크리스마스와 새해 연휴 기간 동안 Claude Code를 사용하여 Nexus라는 조직 지식 추출 시스템을 구축했다. 이것은 단순한 개념 증명이나 데모가 아니었다. 인증, 시맨틱 검색, 에이전트 액세스를 위한 MCP 서버, 주요 SaaS 플랫폼을 위한 웹훅 통합, 포괄적인 테스트 커버리지를 갖춘 프로덕션 준비 시스템이었다. 총 13,000줄에 가까운 코드였다.

Nexus의 핵심 워크플로우는 다음과 같다:

입력: Claude Code 세션이 끝날 때 자동으로 실행되는 훅, Slack Events API를 통한 Slack 스레드, GitHub PR 토론을 위한 웹훅, Linear 이슈 코멘트를 위한 웹훅, 또는 API를 통한 수동 제출 등 모든 소스에서 트랜스크립트가 들어온다.
LLM 추출: 각 트랜스크립트를 분석하여 내려진 결정, 배운 교훈, 관련된 사람들, 논의된 주제 등 구조화된 지식을 추출한다.
RDF 저장: 모든 것을 Oxigraph(완전한 SPARQL 지원을 갖춘 고성능 그래프 데이터베이스)에 시맨틱 트리플로 저장한다. 진실의 원천은 Postgres가 아니라 그래프다.
벡터 임베딩: pgvector를 통해 전체 지식 베이스에 걸친 시맨틱 유사성 검색을 가능하게 한다.
MCP 서버: 그래프를 AI 에이전트에 노출하여 Claude가 코딩 세션 중에 조직의 메모리를 직접 쿼리할 수 있게 한다.
웹 UI: 사람이 세션을 탐색하고, 온톨로지를 탐색하고, 시맨틱하게 검색하고, 충돌을 관리할 수 있게 한다.

2.2 기술 스택: 최신 기술의 통합

Fernandez의 기술 선택은 현대적이고 야심차다:

Ruby 4.0과 Rails 8 (edge): 출시되지 않은 버전을 포함한 최신 버전
Solid* gems: Redis 의존성을 제거 - 백그라운드 작업을 위한 SolidQueue, 캐싱을 위한 SolidCache, 웹소켓을 위한 SolidCable
PostgreSQL with pgvector: 일반 데이터와 함께 768차원 임베딩을 저장하고 유사성 연산자로 쿼리. Pinecone이나 Weaviate 같은 별도의 벡터 저장소 불필요
Oxigraph: SPARQL 지원을 갖춘 Rust 기반 RDF 트리플 저장소. 지식 그래프를 실제로 작동하게 만드는 핵심

2.3 개발 과정: TDD가 AI 개발의 닻이 되다

Fowler가 특히 강조한 것은 Fernandez가 Test-Driven Development(TDD)를 AI 보조 개발의 핵심 방법론으로 사용했다는 점이다.

Fernandez는 다음과 같이 설명한다: “이것을 지속 가능하게 만든 것은 TDD였다. 테스트 주도 개발. 대부분의 기능에 대해 나는 Claude Code가 나와 함께 red-green-refactor 사이클을 따르도록 고집했다. 먼저 실패하는 테스트를 작성하고, 가장 간단한 구현으로 통과시키고, 테스트를 녹색으로 유지하면서 리팩터링한다.”

이것은 단순한 방법론적 순수주의가 아니었다. TDD는 AI 보조 개발에서 결정적인 기능을 수행했다 - 개발자를 루프 안에 유지했다. 수천 줄의 코드 생성을 지시할 때, 무엇이 만들어지고 있는지 실제로 이해하도록 강제하는 메커니즘이 필요하다. 테스트가 바로 그 강제 기능이다. 이해하지 못하는 것에 대해 의미 있는 테스트를 작성할 수 없고, 의도 자체를 이해하지 못하면 테스트가 의도를 올바르게 포착하는지 확인할 수 없다.

2.4 진화와 학습: 델타 추출과 기능 제거

Fernandez의 계정에는 주요 리팩터링과 도구의 초기 버전의 많은 진화가 포함되어 있다.

델타 추출의 도입: 첫날은 핵심 아키텍처를 확립했다 - 트랜스크립트 입력, LLM 추출, RDF 저장, 쿼리 가능한 지식. 그러나 둘째 날은 현실과 직면하는 것이었다. 초기 시스템은 짧은 트랜스크립트에는 훌륭하게 작동했지만, Claude Code 세션은 몇 시간 동안 실행될 수 있고 트랜스크립트가 수천 줄로 늘어날 수 있다. 그리고 시스템을 구축한 방식대로라면, 트랜스크립트가 제출될 때마다 전체를 다시 처리했다. 데모에는 괜찮지만 LLM 토큰 비용을 지불하고 응답을 기다릴 때는 괜찮지 않다.

해결책은 델타 추출이었다. 각 트랜스크립트에서 이미 처리한 양을 추적하고 새로운 내용만 추출하는 것이다. 통찰은 간단했지만 구현하려면 전체 파이프라인을 재고해야 했다. Fernandez는 이것을 “프로덕션 소프트웨어를 데모와 구분하는 종류의 아키텍처 결정”이라고 설명한다.

기능 제거: 초기 설계는 세 가지 유형의 지식을 추출했다 - 결정, 학습, 그리고 액션 아이템. LLM은 충실하게 이것들을 추출했다. “데이터베이스 스키마를 업데이트해야 함”, “인증 흐름에 테스트를 추가해야 함” 등 각 세션에서 수십 개의 액션 아이템이 나왔다.

문제는? 누군가 그것들을 볼 때쯤이면 거의 항상 오래된 것이었다. Claude Code 세션은 즉각적인 구현을 포함한다. Nexus가 “데이터베이스 스키마를 업데이트해야 함”을 추출할 때쯤이면 데이터베이스 스키마는 이미 업데이트되어 있었다. 액션 아이템은 유용한 정보가 아니라 역사적 노이즈였다. 결정과 학습은 지속되지만 액션 아이템은 만료된다. Fernandez는 전체 기능을 제거했다: 11개 파일 변경, 8개 삽입(+), 132개 삭제(-). 추가된 것보다 더 많은 줄이 삭제되었다.

2.5 AI 도구가 RDF를 실용적으로 만들다

Fowler는 이 프로젝트가 “AI 도구가 마침내 RDF를 유용하게 만들 수 있는 방법에 대한 흥미로운 glimpse”라고 언급한다. RDF(Resource Description Framework)는 오랫동안 시맨틱 웹의 약속이었지만 실제로 널리 채택되지 못했다. 복잡성, 학습 곡선, 그리고 실용적인 도구의 부족이 장벽이었다.

그러나 Claude 같은 LLM은 자연어를 RDF 트리플로 변환하고, SPARQL 쿼리를 생성하고, 그래프 구조를 탐색하는 것이 가능해졌다. Nexus 프로젝트는 이것이 실전에서 어떻게 작동하는지 보여준다 - AI가 복잡한 시맨틱 기술을 실용적이고 접근 가능하게 만드는 인터페이스 역할을 한다.

제3부: 인터페이스 설계의 새로운 프레임워크

3.1 Obvious-Easy-Possible: MoSCoW를 넘어서

Jason Fried의 “Obvious, Easy, Possible” 프레임워크는 Fowler가 즉시 공감한 개념이다. 전통적인 우선순위 지정 방법인 MoSCoW(Must, Should, Could, Want)나 단순한 High-Medium-Low보다 훨씬 더 유용한 렌즈를 제공한다.

Obvious(명백한 것): 사용자가 항상 하는 일, 항상 하는 것들이 명백해야 한다. 제품의 핵심, 중심, 본질이 명백해야 한다. 명백함은 지배한다. 그리고 한 번에 진정으로 지배할 수 있는 것은 하나뿐이다.

무언가를 명백하게 만드는 것은 비용이 많이 든다. 돈 이야기가 아니다(비록 그것도 포함될 수 있지만) - 주로 화면 부동산, 주의 범위, 이해력 등을 말하는 것이다. 무언가를 명백하게 만드는 것은 비싸다. 왜냐하면 종종 다른 많은 것들을 덜 명백하게 만들어야 하기 때문이다.

Easy(쉬운 것): 명백한 것 너머에는 쉬운 것이 있다. 쉬워야 하는 것들은 사람들이 자주 하지만 항상 하지는 않는 것들이다. 제품과 고객에 따라 다르지만, 제품을 만들 때는 사람들이 항상 하는 것과 자주 하는 것의 차이를 알아야 한다. 이것은 어려울 수 있고 가장 많은 내부 논쟁을 일으킬 수 있지만, 이것을 올바르게 하기 위해 always와 often의 차이에 대해 깊이 생각하는 것이 중요하다.

Possible(가능한 것): 마지막으로 가능한 것들이 있다. 사람들이 가끔 하는 것들이다. 드물게도. 그래서 앞과 중앙에 있을 필요는 없지만 가능해야 한다.

가능한 것은 보통 가장 까다로운 카테고리다. 왜냐하면 가능해야 하는 것들의 현실적인 목록이 종종 명백하거나 쉬워야 하는 것들의 목록보다 훨씬 더 길기 때문이다. 이는 가능한 목록의 일부 항목이 목록에서 완전히 제외되는 것이 더 나을 수 있음을 의미한다. 가능하게 만드는 대신 전혀 만들지 않는 것이 옳은 결정일 수 있다.

3.2 인지 비용의 전략적 배분

Fowler가 이 프레임워크에 즉각 공감한 이유는 명확하다. “도구를 사용하는 사람들에게 인지 비용을 어떻게 할당할지에 대한 좋은 사고 방식”이기 때문이다.

AI 시대의 인터페이스 설계에서 이것은 더욱 중요해진다. AI는 많은 것을 “가능”하게 만들 수 있지만, 그렇다고 모든 것을 “쉽거나” “명백하게” 만들 수는 없다. 무엇을 어떤 버킷에 넣을지 결정하는 것은 여전히 신중한 인간의 판단이 필요하다.

예를 들어 Claude Code는 복잡한 리팩터링을 “가능”하게 만들었지만, 그것을 “쉽게” 만들려면 명확한 인터페이스와 직관적인 워크플로가 필요하다. “명백하게” 만들려면 더욱 신중한 설계가 필요하다 - 아마도 대부분의 AI 보조 작업에는 적절하지 않을 것이다.

3.3 우선순위가 아닌 사용성 스펙트럼

Fried가 강조하듯, 이것은 우선순위 지정과 같지 않다. High, medium, low 우선순위는 문제에 대해 충분히 말해주지 않는다. “무엇이 명백해야 하는가?”는 “무엇이 높은 우선순위인가?”보다 더 나은 질문이다. 더욱이 우선순위는 비용에 대해 아무것도 말해주지 않는다.

AI 도구를 설계할 때, 이 프레임워크는 다음과 같은 질문을 하도록 강제한다:

사용자가 AI와 함께 항상 하는 작업은 무엇인가? (→ Obvious로 만들어라)
사용자가 자주 하지만 항상 하지는 않는 작업은 무엇인가? (→ Easy로 만들어라)
사용자가 가끔 하는 작업은 무엇인가? (→ Possible로 만들되, 아마도 숨겨두어라)
이 작업을 전혀 지원하지 않는 것이 더 나은가? (→ 제거하라)

제4부: 스펙과 학습 루프

4.1 Kent Beck의 스펙 주도 개발 비판

Kent Beck은 LinkedIn에서 스펙 주도 개발(Spec-Driven Development)에 대한 비판을 제기했다. 그가 본 대부분의 스펙 주도 개발 설명은 구현 전에 전체 명세를 작성하는 것을 강조한다. 이것은 “(내게는 기괴한) 가정, 즉 구현 중에 명세를 변경할 만한 것을 배우지 못할 것이라는 가정을 암호화한다”고 Beck은 지적한다.

Beck은 이 이야기를 그의 기술 경력 내내 수많은 방식으로 들었다고 말한다 - “만약 우리가 명세를 ‘올바르게’ 만들 수 있다면, 나머지는 쉬울 것이다”라는 선의의 사람들에 의해. 하지만 실험의 학습 루프는 어떤 종류의 가치 있는 명세의 핵심인 모델 구축에 필수적이다.

4.2 학습 루프: AI가 피드백을 가속화하다

Fowler는 Unmesh Joshi의 말을 인용한다: “대형 언어 모델은 우리에게 큰 레버리지를 준다 - 하지만 학습과 이해에 집중할 때만 작동한다. 아이디어를 탐색하고, 설정하고, 많은 전문 언어에 걸쳐 의도를 코드로 번역하는 것을 더 쉽게 만든다. 하지만 진짜 능력 - 변화에 대응하는 능력 - 은 얼마나 빨리 코드를 생산할 수 있는지가 아니라 우리가 형성하고 있는 시스템을 얼마나 깊이 이해하는지에서 나온다.”

Kent Beck이 Extreme Programming을 정의했을 때, 그는 피드백을 네 가지 핵심 가치 중 하나로 만들었다. Fowler는 소프트웨어 개발에서 AI를 최대한 활용하는 핵심이 피드백 루프를 가속화하는 데 사용하는 방법이라고 생각한다.

4.3 스펙은 완전할 수 없다

AI 시대에 이것이 의미하는 것은 명확하다. AI가 명세에서 코드를 생성할 수 있다고 해서 명세가 완전할 수 있다는 의미는 아니다. 오히려 반대다. AI는 불완전한 명세에서 빠르게 프로토타입을 만들고, 그것을 실행하고, 피드백을 받고, 명세를 개선하는 것을 가능하게 한다.

Obie Fernandez의 Nexus 프로젝트가 이것을 잘 보여준다. 그는 완전한 명세로 시작하지 않았다. 핵심 아이디어(“조직 지식을 RDF 그래프로 추출”)로 시작해서, Claude와 함께 빠르게 반복하고, 무엇이 작동하고 무엇이 작동하지 않는지 배우고(델타 추출이 필요하다, 액션 아이템은 쓸모없다), 그에 따라 시스템을 진화시켰다.

TDD는 이 학습 루프를 구조화하는 방법이다. 각 테스트는 명세의 일부를 구체화한다. 하지만 테스트를 작성하는 과정 자체가 학습 과정이다. 그리고 AI는 이 루프를 가속화한다 - 테스트에서 구현으로, 리팩터링으로, 새로운 테스트로 더 빠르게 이동할 수 있게 한다.

제5부: 경량 AI 개발 도구 생태계

5.1 맥락 관리의 중요성

Fowler가 AI 보조 프로그래밍에 진지한 사람들로부터 듣는 중요한 것은 맥락 관리다. 프로그래밍 지향 도구는 이를 위해 더 정교해지고 있지만, 커스터마이징을 허용하는 더 단순한 도구를 제공하려는 노력도 있다.

5.2 Pi: 직접 만드는 코딩 에이전트 하네스

Mario Zechner가 개발한 Pi는 이러한 경량 도구의 예다. Zechner는 자신의 블로그에서 “그럼 Claudes에게 소리치는 노인은 뭘 할 건가? 그는 자신만의 코딩 에이전트 하네스를 작성하고 완전히 구글에서 검색할 수 없는 이름을 붙일 것이다. 그래서 절대 사용자가 없을 것이다. 그 말은 GitHub 이슈 트래커에도 절대 이슈가 없을 것이라는 뜻이다. 얼마나 어려울 수 있겠는가?”라고 말한다.

Fowler는 이런 도구들과 실제로 앉아서 놀 시간이 있다면 Pi 같은 것을 시도해보고 싶다고 말한다. 하지만 “The One True Editor”(Emacs)의 중독자로서, 그는 gptel 같은 Emacs와 작동하는 라이브러리에 더 관심이 있다. 이것은 Emacs의 고유한 프로그래밍 가능성을 사용하여 LLM과의 상호작용을 구동하는 자신만의 명령 세트를 만들 수 있게 할 것이다.

5.3 도구 선택의 철학: 통합 vs. 커스터마이징

AI 개발 도구에는 두 가지 철학이 있다:

통합 플랫폼: Cursor, GitHub Copilot, Claude Code 같은 도구는 AI 보조를 IDE에 깊이 통합한다. 설정이 거의 필요 없고 바로 사용할 수 있지만, 커스터마이징 옵션이 제한적일 수 있다.
경량 커스터마이징 가능 도구: Pi, gptel 같은 도구는 더 많은 설정이 필요하지만 개발자의 기존 워크플로에 정확히 맞출 수 있다.

Fowler 같은 숙련된 개발자들은 후자를 선호하는 경향이 있다. 그들은 이미 수십 년간 다듬어온 개발 환경을 가지고 있으며, AI를 그 환경에 통합하고 싶어한다. 새로운 환경에 적응하는 대신에.

제6부: 복잡한 진실들

6.1 AI 생성 콘텐츠의 어두운 면

Casey Newton의 기사는 AI가 허위 정보를 만드는 데 얼마나 쉽게 사용될 수 있는지 보여준다. 그는 음식 배달에서의 다크 패턴에 대한 흥미로운 이야기를 추적했지만, 그것이 AI 이미지와 문서 생성으로 뒷받침된 가짜 이야기임을 발견했다.

Newton이 지적하듯: “내 경력의 대부분 동안, 내부 고발자가 공유한 문서는 매우 신뢰할 수 있는 것처럼 보였다. 왜냐하면 그것을 만드는 데 너무 오래 걸렸기 때문이다. 기자를 속이기 위해 시장 역학에 대한 상세한 18페이지 기술 문서를 만드는 데 시간을 들일 사람이 누가 있겠는가? 가짜 배지를 만드는 수고를 할 사람이 누가 있겠는가?”

하지만 오늘날 보고서는 몇 분 만에 생성될 수 있고, 배지는 몇 초 만에 만들어질 수 있다. 인터넷은 항상 쓰레기로 가득했고, 우리는 항상 거기서 읽는 것을 조심해야 했다. 하지만 AI는 이제 설득력 있어 보이는 증거를 쉽게 만들 수 있게 했고, 이것은 강하게 믿는 믿음과 두려움을 확인할 때 가장 위험하다.

6.2 정보 생태계에 대한 함의

이것은 개발 도구를 넘어서는 더 광범위한 함의가 있다. AI가 코드를 생성하는 것만큼 쉽게 허위 정보를 생성할 수 있다면, 우리는 무엇을 신뢰할 수 있는가?

Newton의 경험은 기자들이 거짓말을 폭로하는 데 중요한 역할을 한다는 것을 명확히 한다. 하지만 이를 하는 데 걸리는 시간은 실제 이야기를 조사하는 데 쓰이지 않는 시간이다.

개발 맥락에서 이것은 코드 리뷰와 테스트의 중요성을 강조한다. AI가 빠르게 코드를 생성할 수 있지만, 그 코드가 올바르고, 안전하고, 의도한 것을 수행하는지 확인하는 것은 여전히 인간의 책임이다. Fernandez가 TDD를 고집한 것은 이 이유 때문이다 - 테스트는 AI 생성 코드에 대한 검증 메커니즘이다.

제7부: 종합 및 시사점

7.1 개발자 역량의 진화 방향

AI 시대의 개발자는 다음 능력들이 더욱 중요해진다:

1. 아키텍처적 사고: 코드를 작성하는 것보다 시스템을 설계하는 것이 더 중요해진다. Anthropic 엔지니어들이 높은 수준의 설계와 기획 작업을 AI에 위임하지 않는 이유가 여기에 있다.

2. AI 위임 전략: 어떤 작업을 AI에 맡기고 어떤 작업을 직접 하는지 판단하는 능력. Anthropic 엔지니어들이 발전시킨 직관 - 검증 가능성, 위험 수준, 흥미도 등을 기준으로 한 위임 - 은 새로운 핵심 기술이다.

3. 검증 및 감독 능력: AI가 생성한 코드를 평가하고 개선하는 능력. 이는 여전히 깊은 기술적 이해를 요구한다. “감독의 역설”을 피하려면 의도적인 기술 연습이 필요하다.

4. 맥락 관리: AI에게 올바른 맥락을 제공하고 대화를 효과적으로 구조화하는 능력. 이것은 프롬프트 엔지니어링을 넘어서는 것이다 - 전체 개발 워크플로를 AI 협업에 맞게 설계하는 것이다.

5. 학습 루프 가속화: AI를 사용하여 더 빠르게 실험하고, 피드백을 받고, 반복하는 능력. Fernandez의 TDD 접근법이 이것의 예다.

7.2 조직적 적응 전략

조직은 다음과 같은 방식으로 AI 전환에 대응해야 한다:

1. 멘토링과 협업 재설계: Claude가 많은 기술적 질문에 답할 수 있다면, 시니어 엔지니어의 역할은 무엇인가? 아마도 더 전략적이고 맥락적인 지도로 이동할 것이다.

2. 기술 개발 경로 재정의: 주니어 엔지니어가 AI로 시작한다면 어떻게 깊은 기술적 이해를 발전시킬 것인가? 의도적인 “AI 없는” 연습이나 프로젝트가 필요할 수 있다.

3. 평가 기준 업데이트: 개발자를 평가할 때 코드 작성 속도보다 AI 활용 능력, 아키텍처 설계, 시스템 이해를 더 중시해야 할 수 있다.

4. 경력 경로 다양화: 모든 엔지니어가 “AI 관리자”가 되기를 원하는 것은 아니다. 깊은 기술적 전문성이나 손으로 직접 만드는 것을 선호하는 사람들을 위한 경로도 필요하다.

7.3 개발 방법론의 재평가

1. TDD의 새로운 중요성: Fernandez의 경험이 보여주듯, TDD는 AI 시대에 더욱 중요해질 수 있다. 테스트는 AI 생성 코드를 검증하고 개발자를 루프 안에 유지하는 메커니즘이다.

2. 스펙과 학습의 균형: Beck의 지적처럼, 완전한 스펙을 미리 작성하려는 시도는 여전히 잘못된 접근이다. AI는 불완전한 스펙에서 빠르게 프로토타입을 만들고 반복할 수 있게 하므로, 학습 루프가 더욱 중요하다.

3. 피드백 루프의 가속화: XP의 핵심 가치인 피드백은 AI 시대에 더욱 중요하다. AI를 사용하여 더 빠르게 피드백을 받고 반복하는 것이 핵심이다.

7.4 설계 원칙의 진화

1. Obvious-Easy-Possible 프레임워크의 적용: AI 도구와 워크플로를 설계할 때, 무엇을 명백하게, 쉽게, 가능하게 만들지 신중하게 결정해야 한다. AI가 많은 것을 가능하게 만들지만, 모든 것을 쉽거나 명백하게 만들 수는 없다.

2. 인지 비용의 전략적 배분: AI가 구현 비용을 낮추지만, 이해와 검증의 비용은 여전히 존재한다. 인터페이스는 사용자의 인지 부하를 최소화하도록 설계되어야 한다.

3. 맥락 관리 우선: AI 도구의 효과는 맥락 관리 능력에 크게 의존한다. 도구는 관련 맥락을 쉽게 제공하고 유지할 수 있어야 한다.

7.5 윤리적 고려사항

1. 허위 정보와의 싸움: AI가 설득력 있는 거짓 정보를 쉽게 생성할 수 있다면, 우리는 검증과 사실 확인을 더욱 중요하게 여겨야 한다.

2. 기술 민주화 vs. 기술 위축: AI가 기술을 민주화하는가, 아니면 기술 위축을 초래하는가? 아마도 둘 다일 것이다. 의도적인 기술 개발 노력이 필요하다.

3. 일자리와 경력의 미래: Anthropic 엔지니어들의 불확실성은 진실이다. 조직과 사회는 이 전환을 어떻게 관리할 것인가?

7.6 한국 AI 생태계에 대한 함의

한국의 AI 개발 생태계는 이러한 글로벌 트렌드를 어떻게 활용할 수 있는가?

1. Sovereign AI 전략: KT, POSCO, Naver 같은 한국 기업들이 자체 AI 역량을 구축하고 있다. Anthropic의 경험은 내부 AI 도입이 어떻게 생산성을 높이고 새로운 작업을 가능하게 하는지 보여준다.

2. 교육 혁신: 한국의 개발자 교육은 어떻게 변해야 하는가? AI 시대에는 코딩 기술뿐만 아니라 AI 활용 능력, 아키텍처 사고, 시스템 설계가 더욱 중요하다.

3. 도구 생태계: 한국은 자체 AI 개발 도구를 만들어야 하는가? 아니면 글로벌 도구를 활용하되 한국 개발 문화에 맞게 커스터마이징해야 하는가?

4. 커뮤니티와 지식 공유: Fowler의 Fragments 같은 지식 공유가 한국 개발 커뮤니티에서도 더 활발해져야 한다. AI 시대의 베스트 프랙티스는 아직 형성 중이며, 경험과 통찰을 공유하는 것이 중요하다.

결론: 변화의 시대를 항해하기

Martin Fowler의 2026년 1월 Fragments는 단순한 기술 동향 보고서가 아니다. 이것은 소프트웨어 개발이라는 직업이 근본적으로 재정의되고 있는 시기에 대한 깊이 있는 성찰이다.

Anthropic의 데이터는 AI가 개발자 생산성을 크게 향상시키고 있음을 보여준다. Obie Fernandez의 경험은 AI로 무엇이 가능한지 구체적으로 보여준다. Jason Fried의 프레임워크는 AI 시대의 인터페이스 설계에 대한 새로운 렌즈를 제공한다. Kent Beck의 통찰은 AI가 피드백 루프를 가속화하지만 완전한 스펙의 환상을 대체하지는 않는다는 것을 상기시킨다.

그러나 가장 중요한 것은 이러한 변화가 불확실성을 동반한다는 인식이다. Anthropic 엔지니어들은 단기적으로는 낙관적이지만 장기적으로는 불확실하다. 일부는 자신을 “실업자로 만들기 위해 출근하는” 것처럼 느낀다. 다른 이들은 “직업의 궤적에 대해 전반적으로 매우 낙관적”이다.

진실은 아마도 그 사이 어딘가에 있을 것이다. AI는 소프트웨어 개발을 없애지 않을 것이다. 대신 그것을 변형시킬 것이다. 코드 작성에서 시스템 설계로, 개별 기여자에서 AI 관리자로, 손으로 직접 만드는 장인에서 높은 수준의 오케스트레이터로. 일부는 이 전환을 환영할 것이고, 다른 이들은 상실감을 느낄 것이다.

중요한 것은 Anthropic의 팀 리더가 말했듯이 “적응력”이다. “아무도 무슨 일이 일어날지 모른다… 중요한 것은 정말로 적응력이 있는 것이다.”

Fowler의 Fragments는 이 적응의 여정에 대한 지도를 제공한다 - 완전하지는 않지만 통찰력 있고, 낙관적이면서도 현실적이고, 열정적이면서도 신중한. 그것이 우리가 이 불확실한 시대를 항해하는 데 필요한 바로 그런 종류의 가이드다.

작성 일자: 2026-01-10

Fragments: How AI is changing Anthropic's internal development, a detailed account of using LLM to program a knowledge management tool, obvious-easy-possible buckets for interfaces, specs can't be complete, & lightweight tools to work with LLMs

https://x.com/martinfowler/status/2009258648598438352?s=46

AI, Material

AI claude-code Medium test-driven-development TDD RDF resource-description-framework spec-driven-development SDD Claude.write