위축 문제
Source: Dev.to
위에 제공된 소스 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.
연결이 끊기는 순간
조용히 찾아오는 순간이 있습니다. 위기 상황이나 늦은 밤 배포 중이 아니라, 평범한 1:1 미팅 한가운데서 말이죠. 엔지니어가 기술적인 내용을 설명하고 접근 방식을 이야기하고 있는데, 두 번째 정도 지나서야 당신은 고개를 끄덕이고 있었지만 실제로는 따라가지 못하고 있음을 깨닫습니다. 관심을 잃어서가 아니라, 뇌와 작업 사이의 연결 고리가 추적하지 못한 방식으로 얇아졌기 때문입니다.
저도 그런 순간을 겪었습니다. 한 번이 아니라 여러 번. 의식적으로 disengage(분리)하기 위해 선택한 것이 아니라, 몇 주에 걸친 작은 결정들이 쌓이면서 주의를 어디에 둘지에 대한 선택이 누적된 결과였습니다. 일정은 리뷰, 팀 간 조정, 전략적 대화로 가득 차고, 코드와 직접 마주하는 개인적인 시간은 점점 짧아지고 드물어집니다. 그리고 그 흐트러짐은 스스로 알리지는 않습니다. 그냥 자리를 잡을 뿐이죠.
그 순간은 스프레드시트와 리더십 오프사이트에 너무 오래 머물렀던 엔지니어링 매니저들에게 흔히 나타났습니다. 순수 프로세스로만 떠다니게 된 시니어 엔지니어, 두 해째로 PR을 열지 않은 채 “기술 담당”이라고 자신을 소개하는 VP 등 말이죠. 그 흐름은 느리고 대부분 눈에 보이지 않으며, 직접 물어보면 그들은 아직도 작업과 가깝다고 말합니다.
The New Accelerant
몇 주 전, 나는 엔지니어들이 AI‑주도 개발이 그들의 본능에 어떤 영향을 미쳤는지에 대해 토론하는 스레드를 읽는 데 시간을 보냈다. 그들의 속도나 산출물의 품질이 아니라, 그들의 본능에 대해서였다.
한 엔지니어가 정확히 이렇게 말했다. 그는 주로 AI 에이전트를 지시하고, 생성된 결과물을 검토하며, 풀 리퀘스트를 승인하는 방식으로 전환했다. 그러던 중 프로덕션에서 메모리 문제가 발생했는데, 이는 시스템이 여러 레이어에서 동시에 무엇을 하고 있는지에 대한 정신 모델을 유지해야 하는 실제 디버깅 문제였다. 먼저 어디를 살펴봐야 할지 알려주는 본능이 사라졌다. 완전히 사라진 것은 아니지만, 느려졌다. 마치 긴 휴가를 다녀온 뒤 자신의 부엌에서 물건을 찾으려는 듯한 느낌이었다.
그는 시니어 엔지니어였다. 이전에 시스템을 구축한 경험이 있었다. 그 능력이 일주일 만에 사라진 것이 아니라, 매일 유지하던 연습이 중단되면서 조용히 약화된 것이었다.
스레드의 나머지를 읽어보니, 같은 패턴이 다른 세부 사항과 함께 계속 등장했다. 아직 코드를 읽을 수 있고, PR을 승인할 수 있으며, 아키텍처에 대해 유창하게 이야기할 수 있는 엔지니어들. 하지만 더 깊은 본능… 충분히 코드를 작성해 보면서 무언가가 잘못됐다는 직감을 말로 표현하기 전에 느끼는 감각… 그것들이 점점 부드러워지고 있었다. 그리고 가장 심하게 영향을 받은 사람들은 겉으로 보기엔 가장 생산성이 높은 엔지니어들이었다.
실제로 작업이 얼마나 걸리는지, 특정 패턴이 부하가 걸릴 때 왜 깨지는지, 눈에 보이기 전에 미묘한 버그가 어떤 냄새가 나는지에 대한 근육 기억은 코딩을 멈추면 약해진다.
예전에는 이것이 시니어‑리더십의 문제였다. 전략 업무로 옮겨가면 코딩을 멈추게 되고, 본능이 서서히 흐려진다. 모두가 그 트레이드‑오프를 이해하고 있었다. 이제 AI‑보조 워크플로우가 하루 작업에서 어려운 사고를 제거하면서도 생산성이라는 외관은 유지하기 때문에, 같은 역학이 훨씬 짧은 시간 안에 압축되고 있다.
AI와의 근본적으로 다른 두 관계
-
이해하고 있는 문제를 AI를 사용해 더 빠르게 해결하기
- 판단은 여러분이 내리며, 도구는 실행을 가속화합니다.
- 피드백 루프는 그대로 유지됩니다—여전히 사고, 디버깅, 아키텍처 결정, 문제의 저항을 체감합니다.
- 도구는 언제나 기계적이었던 부분을 처리합니다. 판단은 여전히 여러분에게 있습니다.
-
생각하고 싶지 않은 문제를 AI로 건너뛰기
- 결과물은 여전히 도출되고, 속도 지표도 괜찮아 보입니다.
- 처음에 판단을 만들던 사고 과정이 조용히 외주화되고, 판단은 스스로 보존되지 않습니다.
대부분의 엔지니어가 스스로에게 말하는 버전은 자신들이 가치 사슬을 올라갔다는 것입니다. 이제는 구현보다 지시라는 고차원적 사고를 하고 있다고 생각합니다. 이런 프레이밍이 사실일 수도 있습니다. 문제는 그 지시가 충분히 구현을 경험하고 어려운 부분이 무엇인지 내면화한 뒤에 얻어지는 판단에 기반하고 있는가 하는 점입니다.
어려운 점은 두 접근 방식이 외부에서는 똑같이 보인다는 것입니다. PR은 어느 쪽이든 병합되고, 기능은 어느 쪽이든 배포됩니다. 퇴화는 어떤 대시보드가 측정하는 선 아래에서 일어납니다.
Signals of Drift
나는 AI가 이 대화의 일부가 되기 훨씬 전에, 몇 년 전부터 내 안에서 신호들을 추적하기 시작했다:
- “접근 방식을 설명해 주세요.” 대신 “무슨 일이 일어나고 있나요?” 라고 물어보면서 점점 상태 보고서가 된 1:1 회의.
- 내가 완전히 이해하지 못한 기술 설명을 고개를 끄덕이며 듣기.
- 코드베이스에서 정말 놀라운 일을 3주 동안 한 번도 경험하지 않음.
그러한 신호들은 크게 외치지는 않는다. 그것은 약간의 무뎌짐—당신이 생각하는 직감과 실제 직감 사이의 차이이다.
대부분 AI‑주도 워크플로우에서 일하는 엔지니어들에게는 같은 신호가 더 일찍, 더 빠르게 나타난다:
- 결과물은 많아 보이지만 실제 사고는 얕아져 생산적이라고 느끼는 날들.
- 도움 없이 디버깅 세션에 뛰어들기 전 점점 커지는 주저함.
- 복잡한 문제가 더 어려워서가 아니라, 예전엔 쉽게 해결할 수 있었던 패턴 인식 능력이 녹슬어서 낯설게 느껴짐.
업계는 아직 이에 대한 지표를 만들지 못했기 때문에, 대부분의 사람들은 무시할 수 없게 될 때까지 이를 눈치채지 못한다.
시스템에 가깝게 유지하기
나는 여전히 풀 리퀘스트를 읽는다—구문을 승인하기 위해서도, 엔지니어들이 내리는 결정을 세세히 관리하기 위해서도 아니다. 팀이 어떻게 생각하는지를 이해하기 위해 읽는다:
- 코드베이스 전반에 걸쳐 연결이 형성되는 위치와 형성되지 않는 위치.
- 우리가 합의한 패턴이 실제 배포 압박 속에서도 유지되는지 여부.
시스템에 그렇게 가깝게 머무르는 것은 무언가가 … (원본 텍스트가 여기서 끊깁니다).
Source: …
AI 시대의 기술 본능
빠르게 행동하려는 본능은 여전히 존재합니다. 몇 달 전, 고객 경험을 악화시키는 버그가 나타났습니다. 일반적인 지원 경로를 거치지 않고 로그를 확인하고 데이터 문제를 찾아 30분 만에 고객 경험을 복구했습니다. 이는 눈에 띄는 엔지니어링이라기보다, 뇌와 시스템 사이의 연결 고리를 느슨해지게 두지 않았을 때 가능한 일입니다.
기술 본능이 중요한 이유
- 본능은 한 번에 사라지지 않으며, 사용하지 않으면 점진적으로 약화됩니다.
- 본능은 의도적인 연습을 통해 점진적으로 회복됩니다.
AI 시대를 가장 잘 헤쳐 나갈 엔지니어는 도구에 저항하는 사람들이 아닙니다. 그들은 어떤 사고 부분을 유지할지 의도적으로 고민하는 사람들입니다.
본능을 보존하는 실용적인 방법
-
엔지니어를 위한:
- 스프린트당 최소 하나의 문제를 선택해 AI 도움 없이 실제 디버깅을 수행합니다.
- 이를 순수함을 위한 연습이 아니라 필수적인 유지보수로 생각하세요.
-
리더를 위한:
- 실제 작업에 충분히 가까이 있어, 자신이 알고 있다고 생각하는 것과 실제 상황 사이의 격차가 좁게 유지되도록 합니다.
- PR을 읽고, 로그를 파고들며, 때때로 코드베이스에 놀라움을 허용하세요.
도구는 기계적인 작업을 더 빠르게 수행해야 합니다. 판단을 내리는 사고 자체는 하지 말아야 합니다.
“What‑If” 테스트
AI가 내일 멈춘다면, 당신은 여전히 고용된 일을 수행할 수 있나요?
- 보조 없이 프로덕션 이슈를 디버깅할 수 있나요?
- 자신의 사고만으로 시스템을 설계할 수 있나요?
- PR을 검토하고 접근 방식에 대해 진정한 의견을 형성할 수 있나요? (테스트가 통과했는지 여부만이 아니라)
많은 엔지니어에게 이 질문은 이미 불편합니다. 멀리서 AI 워크플로를 지시해 온 리더에게는 더욱 불안할 수 있습니다. 이 불편함이 신호입니다—실패했기 때문이 아니라, 도구를 버려야 한다는 뜻이 아니라, 본능이 점점 흐려지고 있음을 인지하지 못했기 때문입니다.
AI가 대체할 수 없는 것
AI는 이제 코드를 작성할 수 있지만, 다음은 할 수 없습니다:
- 시스템에 대해 잘못된 경험을 쌓고 그 실수에서 배우는 수년간의 시간.
- 나쁜 아키텍처 결정의 무게를 몸소 느끼며 형성된 본능.
- 누군가가 충분히 오래 고민해 자동화된 판단을 만들게 된 판단력.
그 부분은 여전히 당신에게 남아 있습니다. 중요한 것은 그것을 유지하고 있느냐 하는 점입니다.
주당 한 번, The Builder’s Leader에서 보내는 이메일 — 프레임워크, 맹점, 그리고 대부분의 리더가 피하는 대화.
무료 구독하기 (링크 자리표시자)