이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 아래 두 편의 글을 재구성한 것입니다:

“업계를 떠나야 할까요?”#

지난 2년간 개발자 멘토링과 컨퍼런스를 다니며, 프로그래머이자 작가이자 작곡가인 Charles Humble은 이전 30년간 한 번도 들어본 적 없는 질문을 반복적으로 듣게 되었습니다.

“Is it time to leave the industry?”

시니어 개발자들은 자신이 “공룡처럼 느껴진다"고 말합니다. AI를 활용한 코딩 자체에 흥미를 느끼지 못하는 사람도 있고, 대규모 저작물 도용 위에 세워진 생성형 AI의 윤리적 문제, 그리고 환경에 미치는 영향에 대해 고민하는 사람도 있습니다. 많은 이들이 이런 고민을 하는 것이 자기뿐이라고 생각하며 고립감을 느끼고 있습니다.

Humble 자신도 “무언가를 만드는 기쁨이 빼앗기는 느낌"이라고 솔직히 고백합니다. 2025년 여름 런던에서 열린 ‘AI for the Rest of Us’ 컨퍼런스에서는 “애도하고 있다"고 말하는 참석자도 있었습니다.

그런데 Humble이 깊이 존경하는 엔지니어들 — Kent Beck, Gene Kim, Adrian Cockcroft 같은 이들은 새로운 도구를 진심으로 받아들인 것 같습니다. 이 간극이 현재 업계의 혼란을 잘 보여줍니다.

펀치카드에서 AI까지: 기술 전환은 반복됩니다#

이런 전환이 처음은 아닙니다. Humble은 1960년대 케냐에서 ICT 펀치카드 시스템의 프로그래머로 일했던 장모님 Lesley Finne의 이야기를 들려줍니다. 당시 프로그래밍이란 특수 양식에 코드를 작성해 천공실에 넘기는 것이었고, 메인프레임 시간을 빌려 테스트하는 것이었습니다. 고도로 숙련된 흥미로운 일이었지만, 1980년대 중반 화면과 키보드가 달린 터미널이 등장하면서 그 기술은 쓸모없어졌습니다.

Humble 자신도 이 패턴을 경험했습니다. 10대에 BBC Micro와 Commodore 64에서 BASIC과 어셈블리를 배웠지만, C 언어가 등장하면서 레지스터 할당 같은 기술은 불필요해졌고, Java가 나오면서 수동 메모리 관리도 사라졌습니다. 그러나 “컴퓨터가 실제로 무엇을 하는지” 에 대한 이해는 계속 가치가 있었습니다.

이제 또 한 번의 전환이 왔습니다. Extreme Programming의 창시자이자 TDD의 선구자인 Kent Beck은 2025년 12월 시드니 YOW! 컨퍼런스에서 이렇게 말했습니다:

“아무도 모릅니다. ‘상황에 따라 다르다’ 라는 수준에 도달하는 것만으로도 진전일 것입니다. 왜냐하면 아직 무엇에 따라 다른지조차 모르기 때문입니다. 우리 모두 함께 이 공간을 탐색해야 합니다.”

탐색-확장-추출: AI는 어디에 강한가#

Beck의 3x 모델은 제품 개발을 세 단계로 나눕니다:

  1. 탐색(Exploration) — 투자 대비 수익이 가능한지 탐색하는 위험한 단계
  2. 확장(Expansion) — 성장의 병목을 제거하는 단계
  3. 추출(Extraction) — 수익성 있는 성장이 계속되는 단계

Humble은 프로그래밍이라는 분야가 상당히 오랜 시간 ‘추출’ 단계에 머물러 있었다고 지적합니다. Beck의 표현을 빌리면, “프로그래밍은 Smalltalk-80 이후로 실질적으로 진보하지 않았다"는 것입니다. 1970~80년대에 놓인 기반 위에서 45년간 작은 개선만 이어져 왔습니다.

그런데 생성형 AI 코딩 어시스턴트라는 지니가 병에서 나왔고, “그 모든 확실성이 창밖으로 날아갔다"고 Beck은 말합니다.

AI는 탐색 단계에서 매우 강력합니다. Atsign의 엔지니어 Chris Swan은 “아이디어에서 코드까지 가는 비용이 그 어느 때보다 저렴해졌다"고 썼습니다. 하지만 새로운 제약 조건은 “좋은 아이디어"입니다. 만들 가치가 있는 앱에 대한 아이디어를 가진 사람의 수는 무한하지 않습니다.

반면 확장과 추출 단계에서 AI는 문제가 많습니다. 너무 많은 실수를 하고, 그 실수가 미묘하고 찾기 어렵습니다. 본질적으로 이것은 검증(validation) 문제 입니다. 그리고 이 검증은 사람이 AI 생성 코드를 읽는 것만으로, 혹은 테스트가 모두 통과하는 것만으로 해결되지 않습니다.

Humble은 자동화된 검증 도구에 많은 투자가 이루어질 것으로 예상하며, 형식적 방법(formal methods)보다는 지난 10년간 주류가 된 관찰가능성(observability)과 프로덕션 테스팅 아이디어를 발전시키는 방향이 될 가능성이 높다고 봅니다.

AI 시대에도 여전히 가치 있는 6가지 스킬#

Humble은 탐색에서 확장으로 넘어갈 때 중요해지는 핵심 스킬 6가지를 제시합니다. 흥미로운 점은 테크니컬 라이터인 Tom Johnson이 이 목록을 보고 자신의 분야에도 거의 그대로 적용된다고 분석한 것입니다. 두 관점을 함께 살펴보겠습니다.

1. 컴퓨터가 실제로 무엇을 하는지 아는 것#

프로그래머 관점 (Humble): 메모리, I/O, 동시성, 비용이 큰 연산과 작은 연산의 차이를 이해하지 못하면, AI가 프로덕션에서 무너질 코드를 생성했을 때 알아챌 수 없습니다.

테크니컬 라이터 관점 (Johnson): 문서를 작성하는 시스템을 근본적으로 이해하지 못하면, AI 출력에 대한 판단과 평가가 불가능합니다. 이것은 새로운 스킬이 아닙니다. 테크니컬 라이터가 자신이 문서화하는 시스템에 대한 실무적 이해를 갖추는 것은 항상 전제되어 온 것입니다.

2. 코드를 비판적으로 읽는 능력#

프로그래머 관점: 수동 검증만으로는 충분하지 않지만, 생성된 코드가 미묘하게 잘못되었을 때 이를 포착하는 능력은 필요합니다. 엣지 케이스를 처리하는가? 규모가 커지면 성능이 나빠지는가? 보안 취약점을 도입하는가? 더 이상 사용되지 않는 라이브러리를 쓰는가?

테크니컬 라이터 관점: Johnson은 점점 더 엔지니어링 소스 파일을 직접 편집하는 일이 늘고 있다고 말합니다. Proto 파일과 Java 파일의 주석을 수정하고, 그 주석으로부터 레퍼런스 문서가 생성됩니다. 이것이 API 문서의 핵심이기 때문에 당연히 소스 코드에 손을 대야 합니다.

3. 테스트와 검증#

프로그래머 관점: 어떤 테스트를 작성해야 하는지, 어떤 케이스가 중요한지, 동작을 어떻게 검증하는지 아는 것. AI가 테스트를 생성할 수 있지만, 그것이 올바른 테스트인지, 위험한 부분을 실제로 커버하는지 판단할 수는 없습니다.

테크니컬 라이터 관점: Johnson은 이것을 자신의 “사이보그 테크니컬 라이터 10원칙” 중 “검증 전략을 적용하라"와 연결합니다. AI가 거의 즉시 콘텐츠를 생성하므로, 검증이 병목 지점이 됩니다. 실수를 잡아내는 시스템을 구축해야 합니다.

4. 도메인 지식#

프로그래머 관점: AI는 비즈니스 규칙, 사용자 워크플로, 특정 제약이 존재하는 이유를 알지 못합니다. 자신감 있게 “틀린 것을 올바르게” 하는 코드를 생성할 것입니다.

테크니컬 라이터 관점: Johnson은 도메인 지식이 있어야만 AI와 반복적인 대화를 나눌 수 있다고 강조합니다. 도메인을 모르면 대화 자체에 참여할 수 없습니다. “주제 전문성은 AI와의 반복적 대화를 가능하게 합니다. 약한 부분을 밀어붙이고, 명확화 질문을 하고, 작가와 도구의 사이보그적 통합처럼 콘텐츠를 공동 창작할 수 있습니다.”

5. 시스템 설계와 아키텍처#

프로그래머 관점: AI는 당신이 설명한 함수를 구현하는 데는 괜찮습니다. 하지만 조각들이 어떻게 맞아야 하는지, 서비스 간 경계가 어디여야 하는지, 6개월 후에도 유지보수 가능한 설계를 만드는 데는 형편없습니다.

테크니컬 라이터 관점: Johnson은 이것을 시스템 사고(systems thinking)와 연결합니다. 그는 자신의 역할에서 최소 20개의 서로 다른 API에 대한 업데이트를 담당합니다. 대부분의 엔지니어는 하나 또는 두 개의 API를 (훨씬 더 깊은 수준에서) 다룹니다. 문서 포털 전체에 걸쳐 다양한 제품이 어떻게 연결되고 상호작용하는지 이해하는 것이 테크니컬 라이터가 가져다주는 간과된 역량입니다.

6. 디버깅과 진단#

프로그래머 관점: AI가 디버깅 도구로 유용할 수 있지만, 다른 기법과 지식과 병행해서만 가능합니다. 스택 트레이스를 읽고, 디버거를 사용하고, 로그를 확인하고, 무엇이 잘못되었는지 추론하는 능력은 여전히 필요합니다.

테크니컬 라이터 관점: Johnson은 이를 넓은 의미의 문제 해결 능력으로 확장합니다. 레퍼런스 문서 생성 시스템의 문제를 디버깅하는 것뿐만 아니라, 콘텐츠 문제도 포함됩니다 — 사용자가 특정 워크플로에서 왜 막히는지, 이 페이지가 왜 다른 것보다 관심을 더 받는지, 뭔가 맞지 않는 느낌이 드는 콘텐츠의 구체적인 문제가 무엇인지를 진단하는 것입니다.

그 어느 때보다 바쁘다는 역설#

6가지 스킬 목록이 프로그래밍과 테크니컬 라이팅 양쪽에서 놀라울 정도로 겹친다는 사실도 흥미롭지만, Johnson이 던지는 더 근본적인 질문이 있습니다.

2년 후 테크니컬 라이팅은 어떤 모습일까요?

Johnson은 동료와의 대화를 소개합니다. AI에 대한 열띤 의견을 나누던 중 Johnson은 “자율주행처럼 항상 2년 뒤에 온다고 하면서 실제로는 결코 실현되지 않는 것"이 될 수 있다고 말했고, 동료는 AI가 인간을 대체한다는 이야기와 달리 자신은 “그 어느 때보다 바쁘다(busier than ever)” 고 답했습니다.

Johnson도 동의합니다. 항상 AI를 사용하면서도 여전히 그 어느 때보다 바쁩니다. AI가 해방을 가져다줄 것이라는 서사 — AI가 일하는 동안 시스템 설계나 콘텐츠 아키텍처를 꿈꾸며 여유를 부릴 수 있다는 — 그런 시간은 결코 캘린더에 나타나지 않습니다. 끝없는 문서 요청, 필요한 업데이트, 릴리스 노트, 새로운 기능 문서화가 하루를 채웁니다.

Johnson은 이 패턴에서 미래의 단서를 읽습니다:

현재의 패턴은 무엇인가? 가속, 그 어느 때보다 바쁨, 그리고 동시에 그 어느 때보다 더 많은 AI 활용. 만약 반대로 내 활동과 참여가 서서히 줄어들면서 AI가 점점 더 많은 일을 떠안는 것을 관찰했다면, 그것은 다른 이야기일 것입니다.

AI는 더 많은 활동을 맡고 있지만, 우리를 끌고 가고 있습니다. 대화를 형성하고, 맥락을 제공하고, 출력을 평가하고, 검증을 실행하고, 접근법을 결정하는 적극적인 협업자입니다. AI는 우리의 일을 대체하는 것이 아니라 증강하고 가속하고 있습니다.

Johnson의 비유가 인상적입니다: “우리에게 역사상 가장 강력한 도구가 있는데, 개집 대신 고층 빌딩을 짓고 있는 것이 놀라운 일일까요?”

불확실성 속에서 가장 중요한 태도#

Beck도 2년 후 프로그래밍이 어떤 모습일지 모릅니다. 그리고 그는 이 문제를 우리 대부분보다 오래 생각해온 사람입니다.

그럼에도 Humble은 생성형 AI가 모든 사람을 프로그래머로 만들 것이라는 생각은 순수한 환상이라고 말합니다. Visual Basic이나 Microsoft Access 같은 이전 도구들처럼, 코드로 프로토타입을 효과적으로 만들 수 있는 사람의 수는 늘어나겠지만 극적으로는 아닐 것입니다. 프로그래머는 도구가 바뀌더라도 높은 수요를 유지할 것입니다.

Beck은 또 하나의 흥미로운 가능성을 제시합니다. 코드 작성이 거의 즉각적이 된다면, 기능 사이사이에 리팩토링과 개선을 할 시간이 생깁니다. 즉, AI가 선택지(optionality)를 늘리는 도구 가 될 수 있다는 것입니다.

Humble의 마무리가 특히 와닿습니다:

펀치카드에서 터미널로, 어셈블리에서 고급 언어로의 전환을 통과한 개발자들은 가장 빨리 전환한 사람들이 아니었습니다. 무엇이 진짜 중요한지 시간을 들여 파악한 사람들 이었습니다.

지금 불편하거나, 상실감을 느끼거나, 이 모든 것이 가치 있는 일인지 깊이 확신하지 못한다면, 당신은 뒤처지고 있는 것이 아닙니다. 주의를 기울이고 있는 것입니다. 그리고 그 신중하고 회의적인 주의 — 새로운 것이라는 이유만으로 받아들이기를 거부하는 것 — 이것이야말로 가장 중요한 스킬일지도 모릅니다.

References#