엔지니어의 업무는 '만드는 것'에서 '경계를 긋는 것'으로 바뀌었다

올해 들어서부터, 업무상 작성하는 코드의 차이점(diff)을 거의 읽어보지 않게 되었다. 코드를 짜는 것은 AI에게 맡기고, 검증도 다른 AI에게 시킨다. 자사에서 사용하는 GitLab을 4단계로 버전 업그레이드할 때도, 절차 조사부터 실행까지 AI에게 지시했고, 중단 시간은 41분이 걸렸다. 내가 한 일은 '어디까지는 AI가 하게 하고, 어디부터는 사람이 확인하며 진행할지'를 결정하는 것이었다.

예를 들어, 비밀 정보 등록과 같은 정해진 작업은 AI에게 커맨드를 만들게 하지만 실행은 시키지 않고, 고정된 스크립트에 전달한다. 외부로 보내는 메일은 문안을 AI가 만들고, 보낼지 여부는 사람이 결정한다. 코드를 짜는 대신, 이런 '선'을 긋는 작업이 늘었다. 엔지니어로서의 업무는 '만드는 것'에서 '경계를 긋는 것'으로 옮겨갔다는 것이 올해의 실감이다.

여기서는 그 너머에 무엇이 남았는지, 16개 회사에서 내가 경험한 범위 내에서 적어본다. 일반적인 조사가 아니라, 한 사람의 관찰이다.

판단도 AI에게 맡기고. 그래도 남은 것

AI가 쓰는 시대에 사람에게 남는 것은 '판단'라고 자주 말한다. 하지만 실제로는 판단까지 상당히 AI에게 맡기고 있다. 설계안에 대한 반증을 다른 에이전트(agent)에게 시키거나, 출력물 리뷰를 다른 모델(model)에게 시키는 등의 활용은 더 이상 특별한 것이 아니다.

그래도 남은 것이 두 가지 있다. '무엇을 만들고 싶은가'와 '자사라면 이렇게 할 것이다'.

무엇을 만들고 싶은지는 AI로부터 나오지 않는다. AI는 걸어둔 것이 없기 때문에, 목적(goal)을 주지 않는 한 선택지를 계속 나열할 뿐이다. 무엇을 중요하다고 여기고 무엇을 버릴지는 결과를 책임질 수 있는 사람만이 결정할 수 있다. 이것은 예전부터 변하지 않았다.

바뀐 것은 두 번째 무게추다. 기술 선정(technology selection)을 생각할 때, AI에게 묻는 경우가 많다. 하지만 AI가 돌려주는 것은 일반론이라서, 자사의 실태와 맞지 않을 때가 있다.

AI는 평균적인 회사에 맞춰 답한다

사내 Teams 통화를 녹음하는 봇을 직접 만들어서 구동하고 있다. Microsoft Graph의 미디어 봇(media bot)으로, Windows 위에서 작동해야 하며, Microsoft 자료에서도 최소한 2코어가 필요하다고 한다. 일반적인 답변은 Azure에 Windows VM을 세우는 것이라, 실제로 처음에는 그렇게 했다. 평일 낮 시간대에만 구동해서 월 143~149달러가 들었다.

2026년 9월에, Azure의 작은 Linux VM을 중계로 삼아, 봇 본체는 집의 Windows 기기에서 작동하는 구성으로

녹음 봇의 중계 구성은 한 번에 완성된 것이 아니었다. WireGuard 터널이 계속해서 확립되지 않거나, 전환 직후 TLS 연결이 약 3할 정도 실패하는 등의 난관을 겪는 일이 이어졌다. 원인은 전송해야 할 포트 범위와 WireGuard의 기본 포트가 겹쳤던 점이나 회선의 MTU 문제였다. 이 모든 것은 알게 되면 단순한 문제이지만, 혼자 조사하면서 처음 만난 난관에서 '어렵다', '불가능하다'고 선을 그었거나, 원인에 도달하기 전에 흥미를 잃어 세상에 나오기가 상당히 늦어졌다고 생각한다. 시도를 거듭했기 때문에, 할 수 없다고 생각했던 영역이 넓어졌다.

모르는 분야에서도 같은 일이 일어난다. tcpdump의 출력이나 iptables의 카운터처럼, 말하자면 계측기의 읽는 법을 AI가 그 자리에서 알려준다. 계측기를 읽을 수 있게 되면, 시도할 때마다 무엇이 바뀌었는지 알 수 있고 다음 시도를 결정할 수 있다. 그리고 그것을 어떻게 사용하는지가 사람의 일이 되었다.

호기심의 역할은 본방에서 사용할 기술을 고르는 기준에서, 시험해 볼 대상을 찾는 것으로 옮겨갔다. 이전 같으면 '재미있지만 시간이 없다'로 끝났을 것이ものが, 시험 후보에 들어온다.

시도 횟수가 늘어나면 보는 범위도 달라진다. 개인적인 취미라면, 만들어서 작동하면 끝이었다. 지금은 테스트가 어디까지 통과했는지, 품질로서 내보내도 괜찮은지 하는 생각까지 미치게 된다. AI는 계획에 적어두기만 하면 그 정도까지 해주고, 말하지 않아도 해야 할 일이 있다. 하지만 무엇을 보고, 어디서 '괜찮다'고 결정할지는 사람이다.

여기서 첫 이야기로 돌아가자. 경계를 긋는다라고 썼는데, 그 선은 시도의 비용으로 그려지고 있다. 컴퓨터 내부처럼 시도가 저렴한 곳은 AI에게 맡기고, 외부 전송이나 송금처럼 한 번의 시도가 돌이킬 수 없는 곳은 사람이 확인한 후에 진행한다. 무엇을 만들고 싶은지 정하고, 전제를 넘겨주며, 시도가 저렴한 곳과 비싼 곳의 선을 긋는다. 이것이 지금 엔지니어의 일이라고 생각한다.

감각적으로 가장 가까운 것은 수십 명의 프로젝트 팀에서 담당을 정해 진행하던 일을 전부 스스로 할 수 있게 된 느낌이다. 실제로 나의 환경에서는 장부 검토, 청구서 대조, 계약 확인, 보안 진단, 디자인, 기사 초안 작성을 각각 역할을 나눈 에이전트에게 맡기고 있다. 읽기만 하는 담당과 쓰기만 하는 담당을 나누고, 인계 지점과 사람이 확인하는 지점을 두는 것이다. 경계를 긋는다는 것은 이 담당 정하기의 문제이기도 하다. 다만, 팀과는 달리 어떤 담당도 나와 같은 전제만을 가지고 있다. 반대 의견은 나오지 않기 때문에, 전제의 오류는 아무도 지적해주지 않는다. 그 부분은 사람의 팀과의 차이점으로 남아있다.

맺음말

시킨 것을 만드는 것만 하는 사람에게 AI는 위협이라고 생각한다. 만드는 과정은 시도 횟수만큼 AI로 옮겨가고 있다. 반면, 무엇을 해결하고 싶은지 결정하고 담당을 정해 진행하는 쪽에게는 오히려 순풍이 되고 있다. 자신의 회사라면, 사업의 과제를 결정하는 프로덕트 오너(Product Owner) 역할과 그것을 푸는 기술의 역할을 혼자 가질 수 있게 되었다.

그렇기 때문에 기초적인 기술은 가볍지 않다. 일반론에 얽매이지 않고, 자사의 과제를 어떻게 풀지 생각하기 위해서는 시스템을 이해하고, AI의 답을 의심할 줄 알며, 무엇을 넘겨줘야 할지 알아야 한다. 쓰는 양은 줄었지만, 알고 있어야 하는 것은 줄지 않았다.

엔지니어 경력에서 쌓아야 할 것은 쓸 수 있는 기술의 수가 아니라, 과제를 결정하고 풀이 방법을 생각하는 힘과, 그것을 지탱하는 기초가 되었다. 자사의 전제를 알고, 그것을 AI에게 넘겨주고, 시도가 저렴한 곳과 비싼 곳의 경계를 긋는 것. 호기심은 시험해 볼 대상을 찾는 데 필요하다. 무엇을 만들고 싶은지는 앞으로도 사람의 영역에 있다.

토론