이 기사는 연재 「생성형 AI 시대, 엔지니어는 무엇으로 먹고사는가」의 실전편 #03입니다.

• 도입편은 이쪽에서 확인하세요.
• 실전편 #01 「전원이 AI를 사용할 수 있는」 팀은 왜 붕괴하는가
• 실전편 #02 아무도 하지 않았던 일을 하는 사람이 다음 시대의 키맨이 된다
• 실전편 #03 「AI 네이티브 팀」의 현장에서 무엇이 일어나고 있는가 ← 지금 여기
• 실전편 #04 PG에서 프롬프트 아키텍트(Prompt Architect)로. 커리어를 바꾼 사람들의 이야기
• 실전편 #05 조직이 AI를 도입하고 반년 후, 살아남은 엔지니어의 공통점

최근 현장 이야기를 들으며 깨달은 것이 있습니다.

「AI 툴을 도입하고 있는 팀」과 「AI를 전제로 설계·운영되고 있는 팀」은 완전히 별개라는 점입니다.

전자는 Copilot을 넣었다, ChatGPT를 사용하고 있다, 라는 상태입니다. 후자는 「AI가 있다는 것을 전제로, 팀의 역할·플로우·평가 기준까지 재설계하고 있는」 상태입니다.

이 기사에서는 후자——AI 네이티브 팀——의 현장에서 실제로 무엇이 일어나고 있는지를 여러 현장에서 들은 이야기를 바탕으로 정리합니다.

엔지니어 3명, PM 1명, 디자이너 1명의 작은 팀입니다. AI를 전제로 한 체제로 이행한 후, 개발 사이클이 크게 변했습니다.

기존에는 「PM → 요구사항 정의 → SE → 설계 → PG → 구현 → QA → 릴리스」라는 흐름이었습니다. 지금은 전원이 AI를 사용하면서 동시 병행으로 움직이는 형태가 되었습니다.

PM이 AI로 요구사항의 초안을 내는 동안, 엔지니어가 AI로 기술 검증을 동시에 실행합니다. 설계와 구현의 경계가 모호해지며, 「만들면서 설계를 굳히는」 스타일로 변했습니다.

이 팀에서 흥미로운 점은, 특정 멤버가 **「AI 아웃풋 통합자 (AI Output Integrator)」**라는 비공식적인 역할을 맡기 시작했다는 것입니다.

전원이 AI를 사용하면 각자의 아웃풋 입도(Granularity)나 방향성이 어긋날 때가 있습니다. 그것을 「팀으로서 일관된 프로덕트가 되어 있는가」라는 관점에서 통합·조정하는 사람이 자연 발생했습니다.

그 사람은 전직 PG이지만, 지금은 코드를 거의 쓰지 않습니다. 하지만 팀 내에서 가장 중요한 역할을 맡고 있습니다.

품질의 편차가 큽니다. AI의 아웃풋을 리뷰하는 비용이 구현 비용보다 높아지는 경우가 있습니다. 「AI를 쓰면 빨라질 텐데, 왜인지 리뷰에서 막힌다」라는 역전 현상이 일어나고 있습니다.

규모가 커지면 AI 도입 효과와 마찰이 모두 커집니다.

이 팀에서 특징적이었던 것은, 문서 생성 속도가 너무 빨라진 것으로 인해 발생한 혼란입니다.

설계서·사양서·의사록——AI로 양산할 수 있게 된 결과, 문서가 너무 많아져서 아무도 전부 읽을 수 없게 되었습니다. 「적혀는 있지만」 「읽히지 않는」 문서가 대량 발생했습니다.

정보의 양은 늘어났는데, 팀의 공통 인식은 줄어들고 있었습니다.

이 과제에 대응하기 위해, 「문서 큐레이터 (Document Curator)」라고 불러야 할 역할이 생겨났습니다.

AI가 생성한 대량의 문서 중에서 「지금, 이 팀에 정말로 필요한 정보」를 골라내어 정리하고, 참조하기 쉬운 형태로 만드는 사람입니다.

사서(Librarian)에 가까운 일이라고 하는 편이 이해하기 쉬울지도 모릅니다. 기술 지식보다 「무엇이 중요한지에 대한 판단력」과 「구조화 능력」이 요구되는 역할입니다.

베테랑 멤버와의 격차. 「AI가 쓴 문서는 신용할 수 없다」라는 불신감이 뿌리 깊게 남아 있어, AI 활용 정도가 멤버에 따라 크게 다릅니다.

이것은 「기술적인 문제」가 아니라 「문화의 문제」이며, 시간과 정중한 커뮤니케이션이 필요한 케이스입니다.

정규직 팀과 프리랜서 팀에서 AI의 영향이 나타나는 방식이 다르다고 느낀 사례입니다.

이 팀은 전원이 프리랜서이며, 각자가 AI를 사용하며 독립적으로 작업하는 형태입니다. 커뮤니케이션은 Slack과 GitHub뿐입니다.

흥미로운 점은, AI가 프리랜서 간의 「언어 통일」에 기여하고 있다는 점입니다. 백그라운드가 다른 엔지니어들이 모여도, AI가 내놓는 코드 스타일 가이드를 공통 기준으로 삼음으로써 코드의 일관성을 유지하기 쉬워졌습니다.

한편으로는 「컨텍스트의 파수꾼 (Guardian of Context)」이 중요해지고 있습니다.

프리랜서가 모이는 팀은 프로젝트의 배경·역사·의사결정 경위를 공유하기 어렵습니다. AI는 그 컨텍스트를 모릅니다.

「이 프로젝트가 왜 이런 설계가 되었는지」, 「과거에 이 접근 방식을 시도했다가 실패한 이유」——그러한 「프로젝트의 기억」을 보유하여, 새로운 멤버나 AI에게 인풋으로 사용할 수 있는 형태로 관리하는 사람이 없어서는 안 될 존재가 되었습니다.

규모도 스타일도 다른 3개의 현장이지만, 공통된 점이 있었습니다.

모두가 AI를 사용할 수 있게 되었을 때, 「사용할 수 있는 사람」은 더 이상 차별화 요소가 되지 않습니다. 「제각각 생성된 아웃풋 (Output)을 팀으로서 정합시키고 통합할 수 있는 사람」이 병목 현상 (Bottleneck)이 됩니다.

AI는 정보를 늘립니다. 하지만 팀에 필요한 것은 「사용할 수 있는 정보」이지 「대량의 정보」가 아닙니다. 생성·정리·선별의 사이클을 돌릴 수 있는 팀이 강합니다.

의사결정의 근거, 스테이크홀더 (Stakeholder)와의 관계, 팀의 문화——AI가 발을 들일 수 없는 영역에 인간의 업무가 응축되어 갑니다. 기술적인 업무일수록 자동화되고, 「인간다운」 업무일수록 남게 되는 아이러니한 역전 현상이 일어나고 있습니다.

케이스 스터디 (Case Study)를 바탕으로 한 가지 강조하고 싶은 점이 있습니다.

AI 도입은 「도구의 문제」가 아니라 「팀 설계의 문제」입니다.

Copilot을 도입하거나 ChatGPT를 허용하더라도, 그것만으로는 아무것도 변하지 않습니다. 오히려 지난번에 썼던 「붕괴 패턴」에 빠질 수도 있습니다.

중요한 것은 「AI가 들어왔을 때, 누가 무엇을 담당할 것인가」를 의식적으로 설계하는 것입니다. 역할의 재정의, 책임의 명시, 품질 기준의 갱신——이것들을 병행하지 않으면, 도구만 바뀌고 팀은 바뀌지 않는 상태가 됩니다.

다음 #04에서는 실제로 커리어를 바꾼 사람들의 이야기를 소개합니다. 「PG(프로그래머)에서 프롬프트 아키텍트 (Prompt Architect)로」, 「SE(시스템 엔지니어)에서 AI 아웃풋 품질 책임자로」——어떻게 커리어를 만들어 나갔는지 구체적인 스토리를 작성하겠습니다.

「우리 현장에서도 이런 일이 일어나고 있다」, 「다른 패턴이 있었다」는 이야기, 꼭 댓글로 알려주세요. 케이스 스터디는 독자분들의 목소리로 키워나가고 싶습니다.

주식회사 나카노히토 컴퍼니 (Nakano Hito Company)에서는 수시로 엔지니어를 모집하고 있습니다. 자세한 내용은 채용 정보 페이지를 확인해 주세요.