블로그로 돌아가기
AISoftware EngineeringCareerDeveloper Tools

소프트웨어 엔지니어링의 FOMO 시대: 툴을 쫓는 것이 어떻게 본질을 갉아먹는가

AI 툴은 매일 쏟아지고, 개발자들은 그것을 쫓다가 실제 엔지니어를 만드는 것을 잃어가고 있다. 데이터가 보여주는 이 표류의 실상, 그리고 엄밀함을 되찾는 방법.

Aam2rican5
15분 읽기
new agent v0.3try this NOW+1 installgame-changer9 updatesharness betadeprecated soon10x or left behindthe FOMO era of software engineering

토요일에서 수요일까지의 사이클

지난 주말, 나는 스스로도 비웃었던 행동을 하고 있는 자신을 발견했다. 토요일 오후를 통째로 새로운 에이전트 프레임워크를 설정하는 데 쏟아부었다. 일요일 저녁이 되자 작동하는 파이프라인이 생겼고, 나름 뿌듯했다. 수요일이 됐을 때 다른 툴이 절반의 설정으로 같은 일을 한다고 주장하는 트위터 스레드를 봤고, 위장 속이 살짝 뒤틀리는 느낌이 들었다 — 자신도 모르게 뛰어든 경주에서 뒤처졌다는 것을 깨달을 때의 그 느낌.

그 뒤틀림에는 이제 이름이 생겼다. 개발자들은 그것을 AI 피로, 툴 피로, 아니면 더 솔직하게 FOMO라고 부른다. 개발자 창업자 Sri Ram은 한 게시물에서 그 메커니즘을 정확하게 묘사했다. "토요일에 새 툴을 설정하는 데 시간을 쓴다. 일요일이면 워크플로가 생긴다. 수요일이 되면 누군가 훨씬 나은 툴을 올린다." 사이클은 JavaScript 프레임워크 피로가 올해의 밈이었던 시절에는 월 단위였다. 이제는 일 단위다. 그리고 뒤틀림은 사실 어떤 특정 툴에 관한 것이 아니다. 표면적인 변화를 쫓는 동안 무언가 더 근본적인 것이 조용히 갉아먹히고 있다는 느린 의심이다.

이 글은 무엇이 갉아먹히고 있는지에 관한 것이다. 측정치가 실제로 무엇을 보여주는지. 그리고 나 자신을 위해 무엇을 하려 하는지 — 나도 그 뒤틀림에서 자유롭지 않으니까.

FOMO의 실제 비용

내가 계속 돌아오게 되는 수치로 시작하겠다. 2월에 Anthropic은 AI 보조가 코딩 스킬 형성에 미치는 영향에 관한 무작위 대조 실험을 발표했다. 결과는 불편했다. AI를 사용한 개발자들은 직접 방금 작성한 코드에 대한 이해도 테스트에서 **50%**를 받은 반면, 수동으로 코딩한 사람들은 **67%**를 받았다. Cohen's d = 0.738, p = 0.01 — 통계학 용어로 이것은 노이즈가 아니다라는 뜻이다. 거의 두 등급 차이에 해당한다.

이 교환을 정당화할 것이라 기대됐던 속도 향상? 약 2분이었다. 통계적으로 유의미하지 않다. 방금 만든 것의 정신 모델에 측정 가능한 구멍을 남기는 대가로 2분의 타이핑을 절약한 셈이다.

Comprehension on code you just wroteManual67%AI-assisted50%Source: Anthropic, 2026. p=0.01, Cohen's d=0.738.

그 단일 연구에서 한 발 물러서면 그림은 더 나빠진다. Google의 2025 DORA 보고서는 AI 도입률 90%인 팀이 버그율 9% 증가, 리뷰 시간 91% 증가, PR 크기 154% 증가를 경험했다고 밝혔다. Stack Overflow 종단 연구는 AI 중사용자에게 코드를 처음부터 작성하는 능력이 23% 감소했음을 보였다. CodeRabbit의 810만 건 PR 분석은 AI 생성 코드가 PR당 평균 10.83건의 문제를 일으키는 반면 사람 코드는 6.45건이고, 논리 오류는 1.75배, 보안 취약점은 1.57배 더 빈번하다고 했다. 코드 중복은 약 4배 증가했다.

우리를 불편하게 해야 할 부분은 이렇다. 개발자의 93%가 이제 AI 툴을 사용하는데, 생산성은 거의 움직이지 않았다 — 약 10% 수준에 고정돼 있다. BCG 연구는 동시에 네 개 이상의 AI 툴을 다루는 엔지니어들이 전환 오버헤드 때문에 생산성이 측정 가능한 수준으로 떨어진다고 보여준다. 더 많은 툴, 더 많은 조율 비용, 우리가 그것들을 산 목적의 더 적은 달성.

뭔가 계산이 맞지 않는다. 역사상 어떤 세대의 엔지니어보다 더 큰 레버리지를 갖고 있으면서, 우리의 이해도는 떨어지고, 버그는 늘어나고, PR은 비대해지고, 생산성 곡선은 평탄하다. 명백한 질문은 이렇다. 우리는 이 레버리지로 실제로 무엇을 하고 있는가?

추격 이면의 혼란

내가 생각하는 실제 상황이 있고, 이게 FOMO 이면의 진짜 이야기라고 생각한다.

대부분의 엔지니어들은 조용히, 도구가 장인 정신이라고 믿기 시작했다. 그래서 새 툴이 나오면 실존적으로 느껴진다. 장인 정신이 Cursor라면, Cursor가 필요하다. 다음 달에 장인 정신이 Claude Code가 되면, Claude Code가 필요하다. 그 다음 달에 다른 철학을 가진 에이전트 하네스가 된다면, 그것도 필요하다. 릴리즈를 놓치는 것은 자신의 일부를 놓치는 것이다.

하지만 장인 정신은 툴이 아니다. 장인 정신은 결코 툴이 아니었다. 장인 정신은 모든 툴 아래에 있고 모든 프레임워크보다 앞서는 것이다. 문제 분해, 트레이드오프 분석, 불변 추론, 가설에 의한 디버깅, 아직 보지 못한 실패 모드를 위한 설계. 그중 어느 것도 변경 로그에 없다. 어느 것도 Product Hunt 출시와 함께 나오지 않는다.

flowchart LR
  A[Problem] --> B[Decompose]
  B --> C[Form hypothesis]
  C --> D[Design for failure]
  D --> E[Reason about invariants]
  E --> F[Implement]
  F --> G{Works?}
  G -->|No| C
  G -->|Yes| H[Understand why]

그 루프가 일이다. 우리가 사용해온 모든 툴 — 펀치 카드, 어셈블러, IDE, Stack Overflow, Copilot, Claude — 은 "구현" 단계를 압축하는 레버였다. 그 중 어느 것도 나머지 다섯 단계를 압축하지 못했다. 레버는 눈부시게 발전했다. 일은 바뀌지 않았다.

툴을 쫓을 때, 우리는 마치 더 나은 레버가 우리를 더 나은 엔지니어로 만들어줄 것처럼 행동한다. 하지만 더 날카로운 끌이 당신을 조각가로 만들어주지 않는다. 당신의 실수를 더 빠르게 만들 뿐이다.

엄밀함은 사라지는 것이 아니라 이동한다

bits-bytes-nn이 쓴 *AI 에이전틱 패턴의 진화*를 읽은 이후 이것에 대해 많이 생각했다. 논제는 단순하고 나는 그것이 옳다고 생각한다. 엔지니어링 엄밀함은 AI 시대에 사라지지 않았다 — 이동했다. 저자는 세 시대를 추적한다.

flowchart LR
  P["Prompt Engineering<br/>2022–2024<br/>craft = wording"] --> C["Context Engineering<br/>2025<br/>craft = what model sees"] --> H["Harness Engineering<br/>2026+<br/>craft = system around agent"]

프롬프트 시대에는 엄밀함이 지침을 얼마나 영리하게 표현하는지에 있었다. 그다음 컨텍스트를 어떻게 조합하는지로 이동했다 — 코드베이스 전체 의미론적 검색, 다중 파일 편집, 검색 파이프라인. 이제 다시 이동하고 있다. 실무자들이 "하네스"라고 부르는 것으로 — 에이전트를 둘러싼 규칙, 오류 복구, 보안 가드레일, 검증 게이트. 기사가 명확하게 말하듯 에이전트 = 모델 + 하네스다.

기사의 역사적 비유가 인상에 남았다. 동적 언어는 타입 안전성을 포기한 것이 아니라 컴파일 타임에서 런타임 테스팅으로 이동했다. Agile은 설계를 죽인 것이 아니라 사전 문서에서 지속적 피드백 루프로 이동했다. 두 경우 모두 규율의 상실처럼 보이는 것은 사실 지리적 이동이었고, "진짜 엔지니어링은 끝났다"고 한탄한 사람들은 대부분 지도를 업데이트하지 않았을 뿐이다.

지금 같은 일이 일어나고 있다고 생각한다. 엄밀함은 사라지는 것이 아니다. 코드 작성에서 코드를 작성하는 것을 둘러싼 시스템을 설계하는 것으로 이동하고 있다. FOMO는 이동을 소멸로 혼동하는 느낌이다. 낡은 집이 비어 있다는 것을 감지하고, 새 집을 찾는 대신 가구를 사재기하기 시작한다.

새 집은, 말하자면, 이런 모습이다. 사람의 리뷰 대신 기계 판독 가능한 규칙, 신뢰 대신 자동화된 검증 게이트, 관찰 가능하고 반복 가능한 컨텍스트 조합 파이프라인, 에이전트가 건드릴 수 있는 것을 제한하는 보안 프레임워크. 덜 엄밀한 것이 아니다. 오히려 엄밀하다. 실수의 폭발 반경이 새벽 3시의 프로덕션 데이터베이스이기 때문에.

tools — treadmillfundamentals — compoundingdecomposereasoninvariantsjudgmentrigor doesn't vanish. it relocates.

두 가지 패턴: 참여 vs. 위임

Anthropic 연구로 돌아가겠다. 12개 탭짜리 AI 워크플로를 가진 모든 엔지니어가 곱씹어봐야 할 부분이기 때문이다.

연구자들은 AI 사용자가 평균적으로 이해도를 잃었다는 것만 발견한 게 아니다. AI 그룹 내부에서 두 가지 뚜렷이 다른 패턴을 발견했다. 한 그룹의 개발자들은 AI를 사용하면서 숙달도를 유지하거나 심지어 향상됐다. 다른 그룹은 퇴화했다. 차이는 어떤 모델을 사용했는지, 얼마나 많은 툴을 연결했는지에 관한 것이 아니었다. 출력물로 무엇을 했는지에 관한 것이었다.

Two patterns inside the AI-assisted groupEngagedasks follow-upsexplains it back≥65%Delegatedaccepts outputnever reads it<40%Same tools. Same models. Different habits. Different outcomes.

높은 점수를 받은 그룹은 AI를 사고 파트너로 대했다. 후속 질문을 했다. 코드와 그 코드가 왜 작동하는지에 대한 설명을 함께 요청하는 복합 쿼리를 구성했다. 개념적 탐구에는 AI를 활용하면서 어려운 부분은 직접 작성했다. 오류를 스스로 해결했다. 이해도 65% 이상을 받았다.

낮은 점수를 받은 그룹은 AI를 자판기로 대했다. 출력물을 수용한다. 출력물을 붙여넣는다. 출력물을 배포한다. 무언가 깨지면, 다시 프롬프트한다. 다시 프롬프트한다. 다시 프롬프트한다. 40% 미만을 받았다.

같은 툴. 같은 모델. 다른 습관. 완전히 다른 결과 — 스킬 유지에서도, 아마 장기적 커리어 궤적에서도.

이것이 내가 중요하게 생각하는 분기선이다. "AI를 사용하는 사람들" 대 "사용하지 않는 사람들"이 아니다. 그 논쟁은 끝났다 — 우리의 93%가 사용하고, 나를 포함해. 진짜 분기선은 참여하는 사람들 대 위임하는 사람들이다. 그리고 FOMO는 위임 방아쇠다. 모든 새 툴이 조금 더 위임하고, 조금 덜 생각하면서도 경쟁력을 유지할 수 있다고 약속하기 때문이다. 트레드밀의 전체 피치가 "더 많은 인지를 넘겨주고 경쟁력을 유지하라"다. 데이터는 반대를 말한다. 참여 없이 더 많이 넘겨줄수록, AI 레버리지를 가치 있게 만들었던 바로 그 스킬을 더 많이 잃는다.

트레드밀 뒤의 비즈니스 모델

무엇을 해야 할지로 넘어가기 전에, 한 가지를 명확히 하고 싶다. FOMO는 사고가 아니다. 비즈니스 모델이다.

AI 툴 출시는 이제 그 자체로 하나의 카테고리다. 오픈소스 모델이 드롭될 때마다, 48시간 안에 Product Hunt에 10~20개의 래퍼가 등장한다 — 같은 모델, 다른 스킨, 모두 당신의 주의와 월 구독료를 놓고 경쟁한다. AI 인플루언서 생태계가 그 출시 리듬 위에서 자랐고, 긴박감을 산업적 규모로 제조한다. "지금 당장 이것을 시도해야 합니다." "이것은 모든 것을 바꿉니다." 모든 유튜브 썸네일, 모든 뉴스레터 제목, 모든 트위터 스레드는 다음 커리어 돌파구가 툴 하나 건너에 있다는 느낌을 만들도록 최적화됐다.

2016년의 JavaScript 프레임워크 피로와 달리, 이제 판돈은 두 가지 면에서 더 무겁다. 첫째, 이 툴들은 실제 돈이 든다 — 기본 티어에 월 20~50달러, 좋은 티어에는 100달러 이상. 평가가 더 이상 무료가 아니다. 둘째, JavaScript가 절대 갖지 않았던 커리어 불안 레이어가 있다. 아무도 React가 자신의 일자리를 가져갈 것이라고 생각하지 않았다. AI 툴 주변의 마케팅은 이 물결을 놓치면 2년 안에 취업이 안 될 수도 있다고 은근히 속삭인다.

우리 중 많은 이가 비이성적인 프레임 안에서 합리적인 결정을 내리고 있다. "출시를 놓칠 여유가 없다"는 말은 출시들 자체가 진행(progression)이 아닌 이탈(churn) 메커니즘이라는 것을 알아채기 전까지는 합리적으로 들린다. 하루에 다섯 번의 출시는 다섯 단위의 진전이 아니다. 다섯 단위의 노이즈에 신호의 거듭제곱 법칙 분포이고, 당신은 실시간으로 혼자 신호를 라우팅할 수 없다.

실제로 해야 할 것들

솔직히 말하겠다. 나는 부분적으로 나 자신을 설득하기 위해 이것을 쓰고 있다. 나도 뒤틀림을 느낀다. 북마크해놓고 절대 열지 않을 AI 툴 폴더가 있다. 48시간 후에 쓰기를 멈춘 에이전트들을 평가하며 저녁을 보냈다. 표류는 실재하고, 내가 그것으로부터 자유롭다고 가장하지 않겠다.

내가 시도하고 있는 것들이다 — 일부는 연구에서, 일부는 내가 존경하는 사람들에게서 효과가 있는 것을 봤고, 일부는 나 자신의 정신적 안정을 되찾아주고 있는 것들. 어느 것도 혁명적이지 않다. 그것이 요점이다. 일상적 노이즈에 대한 답은 더 영리한 필터가 아니다. 더 적은 결정이다.

1. 스택을 90일 시계로 동결하라

작은 스택을 선택하라. 90일간 그것에 헌신하라. 그 기간에 대안을 평가하지 마라. 유일한 예외는 지금 당장 직면한 문제 — 가상의 것이 아닌 — 를 직접 막는 툴이다.

이것은 포기처럼 느껴지기 때문에 어렵다. 아니다. 평가에 쓰던 인지 예산을 되찾아서 실제 대가를 받는 일로 재투자하는 것이다. 내가 아는 가장 생산적인 엔지니어들은 예외 없이 "Claude Code를 사용하고 그게 전부야"의 어떤 버전을 운영하고 있다. 그들은 따라잡지 않는다. 만든다.

2. "되돌려 설명하기" 규칙을 채택하라

AI가 비교적 중요한 코드를 만든 후, 붙여넣기 전에, 그것이 작동하는지 세 문장으로 써라. 무엇을 하는지가 아니라 — 주니어도 그건 말할 수 있다. 왜를 써라. 어떤 불변을 보존하는지, 어떤 실패 모드를 처리하는지, 데이터에 대해 어떤 가정을 하는지.

세 문장을 쓸 수 없다면, 코드를 소유할 만큼 충분히 이해하지 못한 것이다. 설명을 얻을 때까지 계속 프롬프트하든가, 코드를 버리고 직접 작성하라. 이 하나의 습관이 Anthropic 연구의 "참여" 패턴에 거의 완벽하게 매핑된다. 50/67 분할의 올바른 쪽에 머물기 위해 할 수 있는 가장 저렴한 일이다.

3. 퍼스트 프린시플 저널을 유지하라

프롬프트하기 전에, 문제 설명을 손으로 써라. 주석으로가 아니라. 종이나 플레인 텍스트 파일에. 40초의 필기 — 내가 실제로 무엇을 하려 하는가, 제약은 무엇인가, 성공 조건은 무엇인가, 무엇이 그것을 망가뜨릴 수 있는가.

이것은 생산성 쇼가 아니다. 레버를 집기 전에 스스로 문제를 분해하도록 강제하는, 현대 워크플로에서 유일한 순간이다. 이것을 건너뛰면, AI가 기꺼이 당신을 위해 문제를 분해해줄 것이고, 시간이 지나면서 그것을 하던 뇌의 부분이 멈출 것이다. 무거운 에이전트 사용 6개월 차쯤에 그것이 퇴화하는 것을 느낄 수 있다. 나 자신에게서 그것을 알아챘을 때 겁이 났다.

4. 주간 AI 없는 딥 워크 블록을 운영하라

주 2시간, 어려운 문제 하나, AI 보조 없음. 자동완성 없음. 에이전트 없음. 당신과 문제와 2018년에 사용했을 법한 문서들만.

목표는 향수가 아니다. 퍼스트 프린시플 추론을 하는 근육이 잠들지 않게 하는 것이다. 레버를 갖고 나머지 38시간을 전력 질주하게 해주는 근력 운동이라고 생각하라. 주 2시간은 업무 시간의 약 5%로, 23%의 Stack Overflow 스킬 감소에 대한 매우 저렴한 보험이다.

5. AI 출력물을 완전히 신뢰하지 않는 주니어 개발자의 PR처럼 리뷰하라

맞는 것처럼이 아니라. "아마 괜찮을 거야"도 아니라. 자신감이 부적절한 스마트하지만 미숙한 팀원의 PR처럼 리뷰하라. 찾아야 할 것들은 이렇다. 그들이 대충 넘긴 엣지 케이스, 건너뛴 오류 경로, 암묵적으로 만든 보안 가정, 도메인 모델의 얕음을 드러내는 이름들, 기존 유틸리티의 중복.

AI가 평균적인 코드로 훈련되는 경향이 있어 가장 못하는 부분이 정확히 이 부분이기 때문에, 이것은 사람의 판단이 진정으로 그리고 점점 더 유리한 분야 중 하나다. 리뷰를 다른 AI에 맡기면, 평균적인 코드에 평균적인 판단을 쌓는 것이고 그것을 엔지니어링이라고 부르는 것이다. 아니다.

6. 실제로 지킬 평가 게이트를 선택하라

Sri Ram의 다섯 가지 질문 게이트가 내가 본 것 중 가장 깔끔한 버전이고, 나 자신도 사용하기 시작했다.

  1. 지금 당장 내가 가진 문제를 해결하는가? 가상이 아니라. 이번 주에 경험한 것.
  2. 최소 6개월 됐는가? 출시는 불안정하다. 6개월은 피벗을 걸러낸다.
  3. 1개월 이상 사용한 실제 사용자 세 명을 찾을 수 있는가? 베타 테스터가 아니라. 실제 통합자들.
  4. 그것이 죽으면 전환 비용은 얼마인가? 파일 형식이나 CI 파이프라인을 바꾼다면, 기준이 더 높다.
  5. 한 단계를 대체하는가 아니면 추가하는가? 최고의 툴은 작업을 제거한다. 최악의 것들은 관리할 새로운 표면을 추가한다.

그는 이 필터가 출시의 약 95%를 제거한다고 말한다. 내가 2주 동안 사용한 경험과 일치한다. 중요한 것은 하나도 놓치지 않는다. 많은 과대 광고를 놓친다.

7. 주 1회 근본적인 것을 읽어라

툴 변경 로그가 아니라. 출시 게시물이 아니라. 트위터 스레드가 아니라. 논문, 책의 한 장, 사후 분석, 10년 전의 강연 — 지혜로 익은 것들. 2026년에 툴 지식의 반감기는 약 6주다. Designing Data-Intensive Applications, Google SRE 책, 또는 고전적인 분산 시스템 논문의 반감기는 수십 년으로 측정된다.

읽은 것에 대한 ROI 계산은 냉혹하다. 툴 출시 게시물에 쓴 한 시간은 한 분기 안에 거의 제로로 떨어진다. 잘 선택된 논문에 쓴 한 시간은 커리어 전체에 배당을 지불한다. 10년 지평 위에서 경쟁력을 유지하려 한다면, 두 번째 시간은 비교조차 안 된다.

마지막으로

AI 툴링 담론에서 아무도 소리 내어 말하고 싶지 않은 것이 있다. 3년 후 고용할 가치가 있는 엔지니어는 가장 많은 툴을 시도한 사람이 아니다. 한 번도 본 적 없는 문제를 압박 속에서, 불완전한 정보를 갖고, 명확하게 생각하고 좋은 트레이드오프를 만들 수 있는 사람이다. 그 스킬은 항상 만들어져 온 방식으로 만들어진다 — 어려운 문제를 천천히 하고, 실패하고, 왜 실패했는지 이해하면서. 에이전트로부터 출력물을 마찰 없이 수용하고 넘어가는 것으로 만들어지지 않는다.

AI는 계속 더 유능해질 것이다. 그것을 둘러싼 하네스는 계속 더 정교해질 것이다. 툴들은 계속 출시될 것이다, 매일, 영원히, JavaScript 프레임워크들이 결국 통합됐던 것처럼 카테고리가 통합될 때까지. 그 중 어느 것도 장인 정신이 무엇인지를 바꾸지 않는다. 장인 정신은 1995년, 2005년, 2015년과 같은 장인 정신이다. 문제 해결과 비판적 사고. 나머지는 가구다.

뒤틀림이 느껴진다면 — 새로운 에이전트 프레임워크를 누군가 올릴 때마다 "나 뒤처지고 있는 건 아닌가"라는 그 씁쓸한 작은 느낌 — 나는 재프레이밍을 제안하고 싶다. 뒤처지고 있는 것이 아니다. 잘못된 것을 측정하는 트레드밀 위를 달리라는 요청을 받고 있는 것이다. 따라잡을 가치가 있는 것은 툴이 아니다. 당신 자신의 생각하는 능력이다.

쫓기를 멈춰라. 어려운 것을 만들어라. 세 문장 설명을 써라. 논문을 읽어라. 2026년의 최고 AI 툴은 당신이 이미 갖고 있는 것일 수도 있다. 여전히 어떻게 생각하는지 아는 사람이 사용하는.


참고 문헌 및 더 읽을 거리

Share this post

PostLinkedIn

관련 글