AI가 하한선을 올린 순간, 저희는 직무를 다시 그리기로 했습니다

이미 경계는 넘어가고 있었습니다

어느 순간부터 팀 안에서 낯선 장면이 자주 보였습니다. PM이 직접 프로토타입을 만들어 왔습니다. PD가 디자인 시스템을 붙잡고 제품 화면을 조립했습니다. BE 개발자가 간단한 프론트 수정을 손수 처리하고, FE 개발자가 필요한 API를 스스로 정의해 왔습니다.

누가 시켜서 벌어진 일이 아닙니다. AI가 각 직무의 역량 하한선을 끌어올린 결과입니다. 예전 같으면 "그건 제 담당이 아니라서"로 끝났을 일이, 이제는 "일단 제가 해볼게요"로 바뀌었습니다. 경계는 이미 무너지는 중이었고, 저희는 그걸 뒤늦게 이름 붙였을 뿐입니다.

직무 경계는 왜 생겼나

PM, PD, FE, BE라는 기본형은 하늘에서 떨어진 게 아닙니다. 제품 하나를 만들려면 각 영역이 일정 수준 이상의 역량을 갖춰야 했고, 그 역량을 한 사람이 다 감당할 수 없으니 나눈 것입니다. 경계는 능력의 분업이자, 서로에 대한 기대치를 맞추기 위한 약속이었습니다.

그런데 그 전제가 흔들립니다. 프론트를 만들려고 프론트 전문가가 되어야만 했던 제약, 백엔드를 손대려고 백엔드 깊이를 갖춰야만 했던 제약이 느슨해집니다. 한 동료의 말을 빌리면, 이건 역량을 억지로 넓히는 이야기가 아닐 수 있습니다. 제품을 만들려고 서로에게 기대하는 역량 수준을 맞춰야 했던 오래된 제약이 풀리는 것으로도 볼 수 있습니다.

그래서 몇 달에 걸쳐 해보기로 했습니다

말로만 "경계를 넘자"고 하면 아무것도 바뀌지 않습니다. 저희는 FE와 BE의 직무 통합을 실제 로드맵으로 짰습니다. 거창한 조직 개편이 아니라, 몇 달에 걸쳐 단계를 밟는 실험입니다.

첫 두 주는 서로의 직무를 교차해 온보딩합니다. 신규 입사자가 받는 정도의 온보딩급 태스크로 감을 잡습니다. 코드를 아주 깊이 파고들지 않아도, AI의 도움을 받으면 일단 작업이 굴러갑니다. 그다음 한 달가량은 페어링과 상호 리뷰로 두 프로젝트를 교차해 진행합니다. 마지막은 회고입니다.

회고에서 갈라내려는 건 세 가지입니다. 현실적으로 지금 가능한 것, 플랫폼과 도구의 지원이 더 필요한 것, 그리고 솔직히 기대하기 어려운 것. 이 세 갈래를 구분하는 일이 이번 실험의 실제 목적에 가깝습니다.

그러면 코드 품질은 누가 책임지나

이 제안에 동료들이 그냥 박수를 친 건 아닙니다. 장밋빛 이야기만 돌아오지 않아서 오히려 다행이었습니다.

가장 먼저 나온 질문은 검증이었습니다. "이렇게 작성된 코드가 동작한다는 걸 어떻게 보장하나요. 테스트가 중요합니다." 저는 이렇게 답했습니다. 지금도 저희는 그걸 잘 못하고 있고, 상당 부분 개인기에 기대고 있는 것 같다고. 그러니 이건 통합이 만들어낸 문제가 아니라, 통합 이전부터 있던 문제라고. 그 바닥을 어떻게 찾아내고 끌어올릴지가 진짜 숙제입니다.

또 다른 우려도 나왔습니다. "할 수 있는 일만 잔뜩 늘어나서 오히려 감당이 안 되고 퀄리티가 떨어지는 것 아닌가요. 막을 장치가 필요합니다." 여기에도 쉬운 답은 없습니다. 테스트를 붙여도, 그 테스트 자체가 틀렸을 때의 구멍은 여전히 남습니다. 저는 여기서 정직하게 인정할 수밖에 없었습니다. 해보기 전에는 알기 어렵다고.

넓히는 게 앞서가는 걸까

가장 아픈 반문은 방향에 관한 것이었습니다. "넓힐 것인가 깊어질 것인가. 넓히는 것만이 앞서가는 건 아니지 않나요."

맞는 지적입니다. 그래서 저희는 이걸 "무조건 넓히기"로 규정하지 않으려 합니다. 앞서 말했듯 제약이 풀리는 쪽에 가깝습니다. 직군과 상관없이 기본기를 잘 갖춘 사람일수록 수평으로 확장할 여력이 더 생긴다는 관찰도 있습니다. 각자 자기 직군의 깊이를 타고 내려가다 보면 다른 직군으로도 뻗어나갈 수 있게 되고, 그만큼 팀 전체의 유연성이 올라갑니다.

이 두려움을 감당하게 해주는 건 그동안 쌓아온 자산입니다. vertical slice로 기능 단위를 세로로 잘라 왔고, micro frontend로 화면을 독립적으로 다뤄 왔습니다. 자체 디버깅 도구가 있고, design system이 갖춰져 있습니다. 이것들이 있기에 경계를 넘는 순간의 두려움을 견딜 수 있습니다. 부족한 부분은 넘어가면서 찾아 메꾸면 됩니다.

엔지니어가 필요 없어진다는 뜻은 아닙니다

오해는 미리 끊어두겠습니다. PM이 AI를 손에 쥐었다고 해서 엔지니어가 필요 없어지는 시점은 아직 오지 않았습니다. 할 수 있는 일이 많아진 것이지, 전문 역량이 필요 없어졌다는 뜻이 결코 아닙니다.

바깥을 봐도 그렇습니다. 전사 차원에서 코딩 에이전트를 도입한 회사가 나오고, AI 네이티브 팀 운영 가이드가 공유되고, 자연어로 풀스택을 뽑아주는 도구들이 쏟아집니다. Stack Overflow의 2025 개발자 설문에서는 새로운 스택을 배울 때 AI를 쓴다는 응답이 47.4%에 달했습니다. 도구가 좋아진 만큼, 그걸 제대로 쓰고 결과를 판단하는 전문성의 몫은 오히려 커집니다.

정의당하기보다, 정의하는 쪽으로

저희가 바라는 건 단순합니다. 기술적인 이유가 제품을 만드는 데 경계를 만들지 않는 것. 각자 자기 직무의 입장에서가 아니라, 프로덕트 엔지니어로서 제품에 필요한 일을 하는 것.

모든 걸 한꺼번에 바꿀 수는 없습니다. 해보기 전에는 모릅니다. 그래서 저희는, 해봅니다. 남이 정해준 직무 정의에 맞춰 사는 존재이기보다, 저희가 직접 정의하고 그 정의가 통하게 만드는 존재이고 싶습니다. 이 변화기의 한복판에서, 저희는 뒤따라가는 쪽이 아니라 앞서가는 쪽에 서 있으려 합니다.