신들이 API를 배포해 버렸다
2003년 프로그래밍 책이 AI 시대를 살아가는 법에 대해 가르쳐 준 것
최근 2003년에 출간된 오래된 한국 프로그래밍 책, 프로그래머 그들만의 이야기를 다시 펼쳤다.
향수를 기대했다.
Java. .NET. 오픈 소스. 모바일. 데이터베이스.
소프트웨어 엔지니어링의 고고학적 지층 같은 것들 말이다.
그런데 뜻밖에도 2026년인 지금 읽어도 이상할 만큼 와닿는 이야기를 발견했다.
저자는 언젠가 기술이 발전해 소프트웨어 작성이 극적으로 쉬워지면 어떤 일이 생길지 궁금해했다.
그가 내린 결론은 개별 프로그래밍 작업은 단순해질 수 있지만, 소프트웨어 시스템 자체는 계속 더 크고 복잡해질 것이라는 것이었다.
따라서 코딩을 잘하는 것만으로는 결국 충분하지 않게 된다.
엔지니어는 더 큰 그림을 이해해야 한다.
시스템, 설계, 아키텍처, 그리고 기술적 의사 결정.
현대적인 cloud computing이 등장하기 전의 글이다.
스마트폰이 일상을 장악하기 전.
Kubernetes 이전.
대규모 언어 모델 이전.
coding agent 이전.
저자는 소프트웨어의 완전 자동화가 가까운 시일 안에 일어나지는 않을 것이라고도 했다.
아마 아주 오랫동안 말이다.
그런데.
23년이 지난 지금, 아무래도 신들이 API를 배포해 버린 모양이다.
이 영화, 전에도 봤다
소프트웨어 엔지니어들은 새로운 추상화가 등장할 때마다 프로그래머가 더 이상 필요 없어질 것이라는 말을 들어 왔다.
고급 언어.
객체 지향 프로그래밍.
Visual development tool.
오픈 소스.
Offshore development.
Cloud computing.
Low-code.
그리고 이제 AI다.
대개 재미있는 일이 벌어진다.
새로운 추상화는 실제로 한 계층을 더 쉽게 만든다.
그러면 우리는 절약된 생산성을 이용해 세 배 더 복잡한 무언가를 만든다.
한때 database application에는 database만 있으면 됐다.
그러다 server가 필요해졌다.
Web application이 필요해졌다.
Authentication이 필요해졌다.
Caching이 필요해졌다.
Container가 필요해졌다.
Orchestration이 필요해졌다.
Telemetry가 필요해졌다.
Security policy가 필요해졌다.
Compliance가 필요해졌다.
Multi-region deployment가 필요해졌다.
그리고 누군가 회의에 들어와 묻는다.
“이걸 여러 region에서 active-active로 만들 수 있을까요?”
어딘가에서 한 엔지니어가 조용히 LinkedIn을 닫는다.
추상화는 한 계층을 단순하게 만들었다. 우리는 남은 생산성으로 계층 열두 개를 더 만들었다.
2003년의 그 책은 이 패턴을 놀라울 만큼 일찍 알아봤다.
새로운 기술은 개별 프로그래밍 작업을 단순하게 만들지만, 소프트웨어의 전체 범위는 계속 확장된다.
그런데 AI는 이전의 많은 추상화와는 조금 다르게 느껴진다.
AI는 단지 memory management를 감추거나 deployment를 자동화하는 수준이 아니다.
AI가 할 수 있는 일은 점점 늘고 있다.
- 낯선 코드 읽기
- 코드 작성
- 테스트 생성
- repository 설명
- 로그 조사
- 장애 요약
- 문서 초안 작성
- migration 제안
- 변경 사항 검토
- 여러 단계로 구성된 엔지니어링 작업 실행
그래서 적절한 대응이 이것이라고는 생각하지 않는다.
“걱정 마세요. AI도 그저 또 하나의 도구일 뿐입니다.”
또 하나의 도구인 것은 맞다.
다만 꽤 큰 도구다.
내가 오래도록 생각했던 소프트웨어 엔지니어링
내 경력의 상당 부분에서 소프트웨어 엔지니어링은 대략 이런 모습이었다.
문제 이해
↓
해결책 설계
↓
코드 작성
↓
디버깅
↓
테스트
↓
출시
↓
운영
직업적 정체성의 많은 부분이 그 한가운데에 있었다.
코드 작성.
당시에는 타당했다.
구현은 비쌌다.
복잡한 아이디어를 신뢰할 수 있는 소프트웨어로 만드는 일은 어려웠다.
좋은 엔지니어가 가치 있었던 이유 중 하나는 그 어려운 일을 꾸준히 해낼 수 있었기 때문이다.
AI는 그 가운데 부분을 압축하기 시작했다.
이제 workflow는 점점 이런 모습에 가까워진다.
문제 이해
↓
의도와 제약 정의
↓
시스템 설계
↓
구현 위임
↙ AI 사람 ↘
↓
철저한 검증
↓
통합
↓
운영
↓
결과에 대한 책임
이는 엔지니어링의 가치가 놓이는 위치를 바꾼다.
내 경력의 지금 단계에서는 AI가 코드 천 줄을 더 만들 수 있는지보다 그 변화가 훨씬 더 흥미롭다.
그 책에는 50세 이후의 프로그래머 이야기도 나온다
내가 가장 좋아하는 대목 중 하나는 경력의 지속 가능성을 다룬다.
저자는 50세가 넘어서도 프로그래머로 남기를 바랐다고 썼다.
하지만 그가 떠올린 숙련된 프로그래머는 25세보다 더 빨리 타이핑하려고 필사적으로 노력하는 사람이 아니었다.
그가 상상한 사람은 이런 일을 할 수 있었다.
- 코드 검토
- 아키텍처 개선
- 젊은 엔지니어 지원
- 설계 참여
- 프로젝트가 어려워졌을 때 좋은 기술적 결정 내리기
AI 시대에는 이 모습이 더욱 적절해 보인다.
경험의 가치는 나이 든 엔지니어가 문법을 더 많이 외우고 있기 때문에 생기는 것이 아니다.
검색 엔진은 이미 문법 암기의 가치를 낮췄다.
AI는 그 가치를 더 낮춘다.
경험이 가치 있는 이유는 실패하는 모습을 여러 번 봤기 때문이다.
그러면 질문이 달라진다.
예전의 나는 이렇게 물었을지 모른다.
“이걸 어떻게 구현하지?”
경험이 쌓인 지금은 점점 이런 질문을 한다.
“이것이 정말 존재해야 하는가?”
“이 상태의 주인은 누구인가?”
“일부만 실패하면 어떻게 되는가?”
“데이터 손상을 어떻게 발견할 것인가?”
“Rollback 전략은 무엇인가?”
“우리가 인식하지 못한 채 전제하고 있는 것은 무엇인가?”
“AI가 만든 답이 실제로 맞는지 어떻게 아는가?”
이 질문들은 성가실 정도로 autocomplete에 잘 걸리지 않는다.
그래서 내 직무 설명을 바꾸고 있다
지금 내가 생각하는 변화는 대략 이렇다.
Software Engineer
↓
Senior Software Engineer
↓
System Owner
↓
AI-Native Technical Owner
마지막 역할이 가장 흥미롭다.
“Prompt engineer”를 말하는 것이 아니다.
새로 등장하는 모든 agent framework를 외우는 사람도 아니다.
그리고 이런 글을 올리는 사람은 확실히 아니다.
“AI가 점심시간 전에 코드 1만 4천 줄을 작성했습니다 🔥”
8,421번째 줄을 아무도 읽지 않았다는 사실은 말하지 않은 채 말이다.
점심 전에 코드 1만 4천 줄. 검증은 아무래도 오후 근무인 모양이다.
내가 말하는 사람은 복잡한 시스템을 충분히 깊게 이해해 다음을 결정할 수 있는 엔지니어다.
기계가 무엇을 해야 하는가?
무엇을 사람의 결정으로 남겨야 하는가?
“정확하다”는 것은 실제로 무엇을 뜻하는가?
결과를 어떻게 검증할 것인가?
어디에서 사람이 승인하거나 개입해야 하는가?
현실이 demo와 다를 때 누가 책임지는가?
마지막 질문이 중요하다.
현실은 demo보다 불공평하게 유리하다.
현실에는 사용자가 있기 때문이다.
AI는 구현의 가치를 바꾼다
나는 오랜 시간 동안 데이터, 서비스, 신뢰성, 성능, 운영을 포함한 대규모 소프트웨어 시스템에서 일했다.
어떤 일반적인 production 환경에서 engineering agent가 다음 작업을 할 수 있다고 상상해 보자.
아키텍처 문서 읽기
↓
telemetry 조사
↓
장애 분석
↓
진단 query 생성
↓
resource pressure와 runtime 동작의 상관관계 분석
↓
여러 root-cause 가설 제안
↓
테스트 제안
↓
incident summary 초안 작성
이는 대단히 유용할 것이다.
하지만 처음부터 이런 동작을 원하지는 않는다.
AI가 무언가 잘못됐다고 판단
↓
AI가 production을 변경
↓
모두가 그 “무언가”의 의미를 뒤늦게 발견
차라리 이렇게 시작하고 싶다.
AI:
“resource pressure 때문에 실행 시간이
안전 임계값을 넘어서 이 장애가 발생했다고 생각합니다.”
Engineer:
“근거를 보여 줘.”
AI:
“여기 있습니다.”
Engineer:
“이번에는 네가 틀렸을 수 있는 그럴듯한 이유 세 가지를 보여 줘.”
이제 좀 의미 있는 방향으로 가고 있다.
충분히 이해한 운영 작업이라면 언젠가는 다음 단계까지 갈 수 있을 것이다.
AI가 제안
↓
사람이 승인
↓
시스템이 실행
↓
telemetry가 검증
그 지점에서 엔지니어의 역할은 바뀐다.
단지 시스템을 운영하는 대신, 숙련된 엔지니어가 숙련된 엔지니어가 시스템을 안전하게 운영할 때 사용하는 사고방식 자체를 코드로 표현하기 시작한다.
그것은 키보드보다 훨씬 멀리 확장될 수 있다.
뜻밖에 더 중요해지는 능력: 검증
수십 년 동안 소프트웨어 엔지니어링은 만드는 능력을 강조했다.
만들 수 있는가?
AI는 만드는 비용을 낮춘다.
그리고 만드는 일이 저렴해지면 다른 무언가가 비싸진다.
신뢰.
Tests.
Invariants.
Observability.
Evals.
Canaries.
Rollback.
Security boundaries.
Data validation.
Failure isolation.
이것들은 더 이상 엔지니어링을 보조하는 활동으로만 보이지 않을 수 있다.
오히려 중심적인 엔지니어링 능력이 될 수 있다.
2003년의 그 책은 새로운 기술을 끝없이 뒤쫓는 대신 기본기, 논리적 사고, 테스트, 버그 감소를 여러 번 강조한다.
그 조언은 놀라울 만큼 잘 늙었다.
어쩌면 당시의 일부 기술 예측보다 더 잘 늙었을지도 모른다.
정답이 “AI 엔지니어가 되자”라고는 생각하지 않는다
2026년을 바라보며 이런 결론을 내리기는 쉽다.
AI가 미래다
↓
AI 엔지니어가 되어야 한다
하지만 그러면 중요한 질문 하나를 건너뛴다.
정확히 무엇을 버리겠다는 것인가?
수년간 쌓아 온 경험이 있다.
- distributed systems
- production 장애
- data platform
- 성능
- 신뢰성
- 운영
- 기술적 trade-off
- business context
모델이 Python을 만들 수 있다는 이유로 이런 것들이 쓸모없어지지는 않는다.
오히려 AI와 결합하면 더 유용해질 수 있다.
그래서 내 개인적인 공식은 다음에 가깝다.
Distributed Systems
+
Data / Domain Knowledge
+
Agentic AI
=
내가 있고 싶은 유용한 자리
이것보다는 말이다.
수십 년의 엔지니어링 경험
↓
rm -rf
↓
NewAgentFramework.js로 Hello World
소프트웨어 프로젝트는 이미 충분히 많이 다시 시작했다.
나 자신까지 다시 시작할 필요는 없다.
소프트웨어 프로젝트는 충분히 많이 다시 시작했다. 내 경력까지 재설치할 필요는 없다.
오래된 책의 또 다른 좋은 생각: “Me Inc.”
책의 마지막 부분에는 이런 제목의 장이 있다.
“IT 전문가의 미래 — Me Inc.”
나는 이 표현이 마음에 든다.
자신을 아주 작은 회사라고 생각해 보자.
고용주는 중요하다.
하지만 고용주가 경력의 전부는 아니다.
기술은 자산이다.
경험은 지적 자본이다.
Professional network는 선택지를 넓힌다.
글쓰기는 distribution이다.
실험은 R&D다.
평판은 brand다.
월급은 현재 가장 큰 고객 계약이다.
마지막 문장은 조금 우스꽝스럽다.
그래서 아마 기억하게 될 것이다.
핵심은 모두가 회사를 그만두고 독립해야 한다는 것이 아니다.
오히려 그 반대에 가깝다.
목표는 현재 있는 곳에서 계속 더 가치 있는 사람이 되면서도 한 조직이 나의 직업적 가치를 완전히 정의하도록 두지 않는 것이다.
그러려면 다음에 계속 투자해야 한다.
- 기술적 깊이
- 아키텍처
- 커뮤니케이션
- 글쓰기
- 시스템 설계
- AI-assisted engineering
- 조직 밖에서의 학습
- 복잡한 내용을 명확하게 설명하는 능력
회복력 있는 distributed system은 하나의 node에 완전히 의존해서는 안 된다.
경력도 마찬가지 아닐까.
지금 내가 바꾸는 것
앞으로 몇 년 동안의 전략은 꽤 단순해지고 있다.
1. AI를 적극적으로 사용하되 판단까지 맡기지는 않는다
Agent가 더 많은 일을 하게 하고 싶다.
- 탐색
- 종합
- 구현
- 테스트
- 조사
하지만 무엇이 “좋은 결과”인지 정의하는 일은 여전히 사람이 해야 한다.
AI 사용량 자체가 지표는 아니다.
더 나은 엔지니어링 결과가 지표다.
2. 코드 소유에서 시스템 소유로 이동한다
코딩 작업이 작고 독립적일수록 자동화하기 쉬워진다.
흥미로운 문제는 점점 경계 사이에 존재한다.
software
data
infrastructure
operations
security
cost
reliability
users
나는 그 경계에서 더 많은 시간을 보내고 싶다.
3. 검증을 유난히 잘하는 사람이 된다
AI가 더 많은 구현을 생성한다면, 엔지니어는 생성된 결과가 정확한지 판단하는 데 뛰어나야 한다.
이는 코드만 테스트한다는 뜻이 아니다.
가정을 테스트한다는 뜻이다.
4. 계속 글을 쓴다
아키텍처 노트.
기술 저널.
설계 설명.
Postmortem 사고 과정.
공개해도 적절한 엔지니어링 노트.
글쓰기는 흐릿한 생각을 명시적인 생각으로 바꾼다.
개인 지식을 재사용할 수 있는 지식으로 바꾸기도 한다.
재사용할 수 있는 지식은 leverage다.
5. 모든 유행을 쫓는 대신 기존 전문성을 복리로 키운다
책에는 지금도 타당해 보이는 조언이 하나 더 있다.
기술의 큰 흐름은 이해하되, 새롭다는 이유만으로 모든 기술을 깊게 배우지는 말라는 것이다.
실제 문제와 관련이 생겼을 때 깊이 들어가면 된다.
2003년에는 모든 Java 또는 .NET framework를 배우지 않는다는 뜻이었을 수 있다.
2026년에는 아마 다음 모든 것의 전문가가 될 필요가 없다는 뜻이다.
model
agent SDK
vector database
orchestration framework
protocol
모델은 바뀔 것이다.
Framework도 바뀔 것이다.
오래 남는 능력은 이것이다.
낯설고 복잡한 시스템을 이해하고, 실제 문제를 찾아내고, 견고한 해결책을 설계하고, AI로 구현을 가속하고, 결과를 검증하고, trade-off를 설명하고, 실패했을 때 책임지는 능력.
이것이 경력을 지탱하는 능력이다.
그리고 Physical AI가 있다
나는 로보틱스와 Physical AI에도 점점 더 관심을 두고 있다.
지금은 그것을 경력 전체를 초기화하는 일이라기보다 두 번째 궤도로 본다.
그 흐름은 흥미롭다.
Distributed Systems
↓
AI Agents
↓
물리 시스템에 연결된 agents
↓
Robots
↓
이제 소프트웨어 버그가 가구를 들이받을 수 있음
흥미진진한 일이다.
바퀴 달린 소프트웨어 버그는 유산소 운동도 시켜 준다.
이제 소프트웨어 버그에는 바퀴와 질량, 그리고 약간의 선두 거리까지 생겼다.
하지만 같은 원칙이 그대로 이어진다.
- 아키텍처
- observability
- 안전
- 장애 복구
- 사람의 감독
- 시스템 통합
물리 세계는 cloud 환경보다 관대하지 않다.
Rollback 버튼도 더 적다.
어쩌면 프로그래머는 애초에 코드가 아니었는지도 모른다
내 경력 대부분에서 “programmer”와 “program을 작성하는 사람”은 거의 같은 뜻이었다.
합리적인 정의였다.
코드는 컴퓨터에게 무엇을 하라고 지시하는 주된 매체였다.
하지만 더 근본적인 일은 언제나 이것이었는지도 모른다.
문제를 충분히 깊게 이해해 기계가 유용한 일을 신뢰할 수 있게 수행하도록 만드는 것.
수십 년 동안 직접 코드를 작성하는 것이 그 목표를 달성하는 주된 방법이었다.
이제 새로운 추상화 계층이 등장하고 있다.
AI가 점점 코드의 일부를 작성한다.
그렇다고 엔지니어가 사라진다는 뜻은 아니다.
엔지니어가 다음 방향으로 이동해야 한다는 뜻이다.
의도, 아키텍처, 검증, 통합, 판단, 책임.
결국 오래된 그 책은 놀라울 만큼 현대적인 지점을 짚는다.
소프트웨어 엔지니어는 결국 사회의 중요한 인프라 일부를 책임지는 사람이 된다.
이 말은 2003년보다 2026년에 훨씬 더 사실처럼 느껴진다.
나는 코딩을 그만둘 생각이 없다.
여전히 즐긴다.
다만 내가 직접 만들어 낸 코드의 양으로 엔지니어로서의 가치를 측정하고 싶지 않을 뿐이다.
그 차이가 점점 중요하게 느껴진다.
앞으로 5년 동안.
어쩌면 10년 동안.
결과를 다시 보고하겠다.
그때까지 내 agent가 이 블로그를 차지하지 않았다면 말이다.
이 글에 대하여
이 글은 2003년에 출간된 한국 책 프로그래머 그들만의 이야기와 소프트웨어 엔지니어로서의 개인적인 경험 및 관찰에서 영감을 받았다.
소프트웨어 엔지니어링, AI, 경력의 지속 가능성, 숙련된 엔지니어의 역할 변화에 관한 개인적인 견해를 담고 있다.
예시는 의도적으로 일반화했으며 특정 고용주, 고객, 독점 시스템 또는 기밀 프로젝트를 묘사하지 않는다.