몇 달 전, 내 편지함에 메시지 하나가 도착했다. 직함은 그대로지만 업무 범위(scope)가 새로 설정되었다. 프론트엔드(Frontend), 백엔드(Backend), 그리고 QA가 하나의 역할로 통합되었다. 팀에 나머지 부분을 커버할 AI가 생겼기 때문이다.

나는 수년 동안 백엔드 업무를 수행해 왔다. 우리 코드베이스의 프론트엔드 절반과 QA 절반은 거의 건드린 적이 없었다. 마감 기한이 정해진 상태에서 누군가의 프론트엔드 패턴을 처음으로 빠르게 읽어 내려가는 것은 그 자체로 하나의 기술이며, 나는 아직 그 기술을 갖추지 못했다.

그럼에도 나는 수락했다.

당신의 역할 안에 두 번째, 세 번째 직업이 조용히 생겨나고 있지는 않은가

승진이 아니다. 새로운 인원 충원도 아니다. 직함은 같고, 급여 범위도 같다. 하지만 예전에는 두 명의 팀원이 메우고 있던 공백을 이제는 도구가 차지하게 되면서, 갑자기 한 사람에게 세 가지 분야의 역량이 요구된다.

나는 그 공백이 내부에서 실제로 어떻게 느껴지는지에 대해 솔직해지고 싶다. 왜냐하면 이 문제에 대해 내가 읽은 대부분의 글은 이를 스프레드시트(spreadsheet) 상의 문제로 취급하기 때문이다. 그렇지 않다. 그것은 당신이 실제로 훈련받았던 업무를 온종일 마친 후, 오후 6시경에 직관도 없는 CSS 레이아웃을 디버깅(debugging)하고 있을 때 나타나는, 특유의 물리적인 피로감이다.

도구는 구문(syntax)을 커버하지만, 판단력(judgment)은 커버하지 못한다

AI는 기계적인 부분들을 빠르게 해결해 주었다. Flexbox, 깨진 빌드 단계(build step), 한 번도 직접 작성해 본 적 없는 테스트 파일의 형태 등 말이다. 진심으로 빨랐다. 에러를 붙여넣으면 1분도 채 되지 않아 그럴듯한 해결책을 얻을 수 있었다.

하지만 AI가 결코 주지 못한 것은, 그 그럴듯한 해결책이 '이' 코드베이스에는 왜 틀린 것인지, 그리고 왜 이 컴포넌트가 특이한 방식으로 구조화되어 있는지에 대한 판단력(judgment)이었다. 생성된 테스트가 실제로 무언가를 증명하는지, 아니면 단순히 빨간색 X 표시를 초록색으로 바꾸기만 하는 것인지에 대한 판단 말이다. 그러한 판단력은 해당 계층에서 이전에 무언가를 망가뜨려 본 경험에서만 나오는데, 나는 이전에 QA 영역에서 무언가를 망가뜨려 본 적이 없었기에 아무런 판단력도 없었다.

도구는 구문(syntax)의 격차를 즉각적으로 메워준다. 하지만 판단력(judgment)의 격차에는 아무런 도움이 되지 않는다. 이 둘은 서로 다른 격차이며, 이 둘을 혼동하는 것이 현재 많은 AI 생산성 낙관론이 잘못된 지점이라고 생각한다.

실제로 격차를 메운 것과 그렇지 못한 것

내가 직접 코드를 작성하는 것보다, 내가 직접 작성하기 전에 다른 사람들이 프론트엔드 (frontend) 및 QA 레이어에서 AI의 도움을 받아 수행한 변경 사항의 트랜스크립트 (transcripts)를 읽는 것이 격차를 메우는 데 더 큰 도움이 되었다. 나는 마치 시니어 팀원이 나와 페어 프로그래밍 (pairing)을 하며 가르쳐주는 것과 같은 방식으로, 좋은 프론트엔드 작업의 '형태 (SHAPE)'를 그것이 일어나는 과정을 지켜보며 배웠다. 다만 그 팀원은 사람이 아니라 디프 (diff)였다.

도움이 되지 않았던 것은, AI의 첫 번째 답변이 컴파일 (compile)된다는 이유로 그것이 정답이라고 간주하는 것이었다. 통과하는 테스트는 테스트가 실행되었다는 것만을 증명한다. 그것이 테스트하고 있는 대상이 실제로 중요한지에 대해서는 아무것도 증명하지 못한다. 나는 첫 달에 깔끔하게 통과하지만 실제로는 아무것도 테스트하지 않는 두 개의 테스트를 배포했고, 실제 QA 직무를 수행하는 팀원이 리뷰 과정에서 부드럽게 지적해 줄 때까지 그 사실을 알지 못했다.

3개월이 지난 시점에서 발견한 불편한 사실은, 새로운 업무 범위에서 가장 어렵게 느껴졌던 부분은 결코 구문 (syntax)이 아니었다는 점이다. 그것은 나에게 아직 흉터 조직 (scar tissue)이 없는 부분, 즉 이전에 유사한 문제가 발생했던 기억이 없어 단순히 작동하는 것과 좋은 것을 구분할 수 없는 부분들이었다.

솔직하게 말하고 싶은 부분

나는 이러한 변화가 가짜라고 생각하지 않으며, 동시에 그것이 공짜라고도 생각하지 않는다. 이 두 가지는 모두 사실이다. 도구는 진정으로 한 사람이 과거에 세 명이 필요했던 영역을 커버할 수 있게 해준다. 하지만 그렇다고 해서 그 한 사람이 세 명의 개별 전문가가 가졌던 세 영역 모두에서 즉각적으로 그만큼 유능해지는 것은 아니다. 이 둘은 서로 다른 주장이며, 두 번째 주장이 흔히 간과되곤 한다.

만약 당신의 업무 범위가 나처럼 넓어졌다면, 정직한 계획은 "AI가 다 알아서 해줄 거야"가 아니다. 그것은 오히려 견습생 (apprentice)이 실제로 하는 일에 더 가깝다. 해당 레이어에서 자신의 첫 번째 초안을 신뢰하기 전에, 의도적으로 자신이 작성하는 것보다 더 많은 작업물을 낯선 레이어에서 읽어보는 것이다.

당신의 차례

당신이 실제로 훈련받은 적 없는 스택 (stack)의 어떤 레이어를 AI가 당신에게 넘겨주었나요?

이 내용이 유익했다면

저는 성공과 정체(freezes)의 순간 모두를 LinkedIn과 YouTube를 통해 공개적으로 공유하며 작업하고 있습니다. 공개적으로 구축하는(building in the open) 과정의 실제 버전이 여러분에게 유용하다면, 그곳에서 확인하실 수 있습니다. X, GitHub에서 저를 찾으실 수 있으며, next8n.com에서 저의 작업물을 확인하실 수 있습니다.