실리콘밸리에서 15년을 버티며 제가 가장 편안함을 느끼는 공간은 캘리포니아의 햇살 아래가 아니라, 검은 바탕에 흰 글씨가 깜빡이는 터미널 창 안입니다. 네이버에서 HDFS를 튜닝하던 시절부터 넷플릭스에서 수만 대의 인스턴스를 관리하는 지금까지, Neovim은 제 손과 뇌의 확장이나 다름없었습니다. 하지만 최근 저는 이 익숙한 안락함이 더 이상 나의 경쟁력이 아니라, 어쩌면 나를 도태시키는 독이 될 수 있다는 사실을 뼈저리게 인정해야만 했습니다. 얼마 전 읽은 한 엔지니어의 고백은 이러한 저의 불안감을 확신으로 바꾸어 놓았습니다. 그는 지난 20년간 Vim을 사용해왔고 sed와 awk의 난해한 문법을 마스터하여 텍스트 처리의 마법사가 되는 꿈을 꿨지만, 2026년의 문턱에서 그 모든 노력이 '베틀(loom) 짜는 법'을 배우는 것만큼이나 무의미해졌음을 시인했습니다.
저 역시 지난 몇 년간 AI 코딩 에이전트라는 존재를 애써 무시하거나 조소해 왔습니다. 2025년 중반, Claude Code와 같은 도구들에게 기회를 주었을 때 제가 느낀 감정은 경이로움보다는 피로감이었습니다. 마치 집 안을 난장판으로 만드는 과잉행동 장애가 있는 어린아이를 돌보는 기분이었기 때문입니다. 정규표현식 하나를 제대로 작성하지 못해 sed, Bash, Python을 오가며 여섯 번이나 헛발질을 하고, 결국 멀쩡한 파일들까지 훼손해 버리는 꼴을 보며 저는 가차 없이 랜선을 뽑아버리고 싶었습니다. 그래서 저는 다시 '기본'으로 돌아가기로 마음먹었습니다. 변하지 않는 로우 레벨(Low-level) 도구들의 숙련도만이 진정한 엔지니어의 덕목이라 믿으며, AI의 과대광고(Hype)에서 한 발짝 물러나 있기로 한 것입니다.
하지만 냉정하게 시스템의 가용성(Availability)을 판단해야 하는 SRE의 관점에서 볼 때, 저의 이러한 회귀 본능은 순진한 자기기만이었습니다. 비록 AI가 가끔 멍청한 실수를 저지르더라도, 대부분의 경우 그 결과물은 인간이 수동으로 작업하는 것보다 압도적으로 빠르고, 소름 돋게도 '충분히' 좋습니다. 이제 와서 awk의 복잡한 패턴 매칭을 배우는 것은 취미 생활로는 훌륭할지 몰라도, 그것이 연봉을 올려주거나 새벽 3시의 PagerDuty 호출 시간을 줄여주는 실질적인 기술이라고 착각해서는 안 됩니다. 우리가 인정해야 할 불편한 진실은, 텍스트를 정밀하게 파이핑 하여 원하는 출력을 얻어내는 그 짜릿한 '손맛'이 더 이상 비즈니스 가치를 창출하지 못한다는 점입니다.
여기서 오는 상실감은 생각보다 큽니다. Dave Kiss가 지적했듯, 우리는 지금 효율성을 얻는 대가로 무언가를 애도해야 하는 시점에 와 있습니다. 도구들은 매일 더 똑똑해지고 있지만, 역설적으로 엔지니어로서 우리가 느끼던 '유능함'의 감각은 옅어지고 있습니다. 복잡한 정규표현식을 한 줄로 작성했을 때의 쾌감, 난해한 리눅스 커널 파라미터를 튜닝해 성능을 끌어올렸을 때의 기쁨은 이제 AI에게 프롬프트 한 줄을 던지고 기다리는 지루한 관리 감독의 과정으로 대체되고 있습니다. 코드는 단순한 결과물이 아니라 많은 엔지니어들에게 기쁨의 원천이었습니다. 하지만 도구가 좋아졌다고 해서, 내 손으로 직접 문제를 해결했을 때 느끼던 그 성취감의 상실이 아무렇지 않은 것은 아닙니다.
결국 질문은 하나로 귀결됩니다. "코드를 작성하는 행위 자체가 당신에게 기쁨을 주던 것이라면, 이제 당신은 무엇을 해야 합니까?" 저는 후배들에게 잔인하지만 현실적인 조언을 건네고 싶습니다. 그 기쁨을 놓아주십시오. 시스템이 다운되었을 때 범인을 찾지 않고 원인을 분석(RCA)하듯, 우리의 커리어도 감정을 배제하고 분석해야 합니다. 코딩이라는 행위 자체에 집착하는 '장인'으로 남을 것인지, 아니면 AI라는 불안정한 도구를 통제하여 시스템 전체를 조율하는 '감독관'이 될 것인지 결정해야 합니다. 슬프게도, 연봉 테이블과 시장의 수요는 후자의 손을 들어주고 있습니다. 죽지 않고 일하려면, 그리고 이 바닥에서 살아남으려면, 과거의 낭만이 아닌 냉혹한 효율성을 선택하십시오.
