직무 타이틀의 종말: AI 시대, 엔지니어의 본질적 페르소나

소프트웨어 엔지니어링 생태계에서 우리는 오랫동안 자신이 다루는 '기술 스택'으로 스스로의 정체성을 규정해 왔습니다.

"저는 5년 차 React 프론트엔드 엔지니어입니다."
"저는 분산 트랜잭션과 대용량 데이터베이스를 다루는 백엔드 엔지니어입니다."

프론트엔드, 백엔드, 인프라, 데이터와 같은 세부 직무 분류는 도구의 복잡성이 높고 학습 비용이 막대했던 시기에 불가피하게 형성된 분업 구조였습니다. 도구가 고도화될수록 엔지니어는 자신의 영역을 깊게 파고들었고, 이는 필연적으로 조직 내 기술적 칸막이(Silo)를 형성했습니다.

그러나 Claude Code와 같은 AI 코딩 에이전트의 등장은 이러한 전통적 경계를 근본적으로 흔들고 있습니다. 구현에 수반되던 기계적인 타이핑과 보일러플레이트 작성, 이종 기술 간의 문법 장벽이 급격히 낮아졌기 때문입니다. 프론트엔드 엔지니어가 자연어로 견고한 백엔드 아키텍처를 프로비저닝하고, 백엔드 엔지니어가 디자인 시스템을 정밀하게 조합해 복잡한 인터랙션을 완성하는 일이 일상화되고 있습니다.

도구의 평준화가 이루어진 환경에서 엔지니어는 어떤 기준으로 자신의 역할을 정의해야 할까요?

Anthropic에서 Claude Code 개발을 총괄하는 Boris Cherny(Programming TypeScript의 저자)는 직무 명칭(Job Title) 대신 제품의 생애주기(Product Lifecycle)에 따른 '5대 엔지니어링 페르소나(Archetypes)' 프레임워크를 제시합니다.

Anthropic의 기술 조직은 세분화된 직무 타이틀 대신 MTS(Member of Technical Staff) 라는 단일 직함을 사용합니다. 엔지니어들은 고정된 직무에 머무르지 않고, 제품이 거치는 생애주기의 특정 국면에서 가장 필요한 역할을 유연하게 수행합니다.

이 다섯 가지는 계급이 아닙니다. 해결해야 할 문제의 성격에 따라 갈아 쓰는 모자에 가깝습니다. 아래에서는 각 페르소나가 제품 앞에서 실제로 무엇을 보고, 무엇을 위임하고, 어디서 무너지는지를 하나의 이야기로 풀어 갑니다.

Prototyper — 아직 없는 가치를 증명하는 사람

월요일 아침, 슬랙에 문장 하나가 떨어집니다. "이 플로우를 이렇게 바꾸면 전환이 오를 것 같은데." 스펙은 없고, 데이터도 없고, 아키텍처 리뷰는 더더욱 없습니다. 아이디어는 아직 가설일 뿐입니다. Prototyper는 바로 이 지점에서 움직입니다.

그가 던지는 질문은 단 하나입니다. "이 아이디어가 실제로 가치를 창출할 수 있는가?"

다수의 가설은 폐기될 것을 전제로 합니다. 완벽한 아키텍처나 장기 유지보수성보다, 가장 짧은 주기 안에 동작하는 데모를 만들어 타당성을 확인하는 일이 먼저입니다. 마인드셋은 단순합니다. 완벽함보다 동작하는 0→1 데모. 핵심 가치는 가설 검증 속도, 즉 Time-to-Feedback입니다.

그래서 Prototyper가 가장 높은 성취감을 느끼는 순간은, 아이디어가 처음으로 화면에 살아 움직이는 그 몇 분입니다. MVP가 켜지고, 클릭이 통하고, "이게 되네"라는 감각이 올 때. 반대로 가장 지치는 상황은 가설을 검증할 기회조차 없이 문서 검토와 승인 절차만 이어질 때입니다. 관료적 게이트가 피드백 주기를 늘리는 동안, 아이디어는 검증되지 않은 채 시듭니다.

AI 코딩 에이전트와의 협업도 이 리듬에 맞춰집니다. 요구사항이 흐릿해도, 화면 프로토타입과 기본 API 스캐폴딩은 에이전트에게 맡깁니다. v0나 샌드박스에서 Rapid PoC를 돌리고, 프롬프트로 뼈대를 세운 뒤, 사람이 가설의 급소를 찌릅니다. 그가 매일 들여다보는 지표는 테스트 커버리지가 아닙니다. 가설 검증 주기와, 최소 동작 모델이 실제로 도는지입니다.

함정은 바로 그 속도에 있습니다. 검증용 코드에서 테스트와 에러 핸들링을 생략한 채 방치하면, 프로토타입은 순식간에 기술 부채가 됩니다. 그래서 검증이 끝나는 순간이 중요합니다. 도메인 인터페이스만이라도 경계를 긋고, 바로 다음 모자 — Builder — 에게 넘기거나, 에이전트로 최소한의 테스트 하네스를 보강해야 합니다. Prototyper의 일은 "만든다"가 아니라 "살아남을 가설만 남긴다" 에 가깝습니다.

Builder — 가설을 시스템으로 올리는 사람

가설이 살아남았습니다. 데모는 설득력이 있었고, 사용자는 반응했습니다. 이제 문제는 바뀝니다. 거친 코드를 프로덕션으로 올리면, 그 시스템은 앞으로 몇 년의 트래픽과 변경을 버텨야 합니다. Builder가 등장하는 장면입니다.

그가 던지는 질문은 이렇습니다. "검증된 가설을 어떻게 확장 가능하고 견고한 프로덕션으로 전환할 것인가?"

프로토타이퍼가 남긴 스케치는 안정적인 데이터 모델, 명확한 인터페이스, 테스트 스위트를 갖춘 시스템으로 다시 그려집니다. 마인드셋은 "확장 가능하고 신뢰할 수 있는 1→10 구현" 입니다. 핵심 가치는 아키텍처의 견고성과 확장성입니다. Clean Architecture, 도메인 모델링, 타입 안전성, TDD, SOLID — Builder의 언어는 구조의 언어입니다.

성취감은 모호했던 비즈니스 요구사항이 명료한 모듈 경계로 떨어질 때 옵니다. "이 도메인은 여기까지, 저 도메인은 저 인터페이스 너머"라는 선이 그어지고, 테스트가 그 선을 지켜 줄 때. 반대로 가장 큰 피로는 일정 압박이 그 선을 지울 때입니다. 임시방편이 쌓이고, 타입이 느슨해지고, 모듈이 서로를 직접 호출하기 시작하면 Builder는 시스템이 훼손되는 소리를 듣습니다.

AI에게 맡기는 일도 그 기준을 따릅니다. 화면을 빨리 그리는 일이 아니라, 도메인 인터페이스의 엄격한 타입 정의와 경계 조건에 대한 포괄적 단위 테스트입니다. 사람이 경계를 설계하고, 에이전트가 그 경계를 테스트로 봉인합니다. 그가 점검하는 지표는 모듈성, 테스트 커버리지, 아키텍처가 다음 변경을 흡수할 수 있는지입니다.

그런데 Builder의 맹점은 바로 그 성실함입니다. 미래의 확장까지 지금 다 그리려다 과도한 추상화에 빠지고, 출시는 미뤄집니다. 보완책은 단순합니다. YAGNI. 지금 검증된 요구사항의 범위 안에서만 확장성을 설계하고, Prototyper의 속도감을 일부러 수용해야 합니다. 완벽한 시스템은 출시되지 않은 시스템입니다.

Sweeper — 시스템을 가볍게 만드는 사람

기능은 계속 들어옵니다. 실험은 남고, 플래그는 남고, "나중에 쓸지도 모르는" 추상화도 남습니다. 제품은 커지는데 코드베이스는 더 빠르게 무거워집니다. 어느 날 빌드가 느려지고, 온보딩이 어려워지고, 아무도 건드리고 싶어 하지 않는 파일이 생깁니다. Sweeper는 이 엔트로피를 못 본 척하지 않습니다.

그의 질문은 추가가 아니라 삭제입니다. "제품과 코드베이스의 불필요한 복잡성을 어떻게 덜어낼 것인가?"

마인드셋은 한 문장으로 충분합니다. 가장 훌륭한 코드는 삭제된 코드. 핵심 가치는 시스템 복잡성의 제어, 엔트로피 감소입니다. Unshipping, Dead Code Elimination, 의존성 가지치기, 리팩터링 — Sweeper의 일은 기능을 더하는 손이 아니라, 기능을 거르는 면역 체계입니다.

그가 성취감을 느끼는 순간은 수천 줄이 사라지는 날입니다. 레거시가 걷히고, 순환 복잡도가 떨어지고, 빌드와 번들이 가벼워질 때. Net Negative Lines는 자랑이 아니라 건강 지표입니다. 반대로 가장 지치는 상황은, 효용이 다한 기능이 그대로 남아 매 스프린트마다 유지보수 세금만 물 때입니다. 아무도 쓰지 않는 버튼이 테스트도, 번역도, 접근성도, 장애 포인트도 계속 만들어 냅니다.

AI 에이전트는 여기서 탐지기가 됩니다. 미사용 함수, 중복 로직, 불필요한 서드파티 의존성을 코드베이스 전역에서 찾아내는 일. 사람이 "이 기능은 죽어도 되는가"를 판단하고, 에이전트가 "이 코드는 이미 죽어 있는가"를 보고합니다. 그가 보는 숫자는 라인 수 감축량, 번들 크기, 순환 복잡도입니다.

함정은 삭제 그 자체에 매몰되는 일입니다. 가치 창출을 미루거나, 예기치 못한 회귀를 만들 수 있습니다. 그래서 Sweeper는 감각이 아니라 증거로 지웁니다. 텔레메트리로 사용률 0인 기능을 격리하고, E2E와 회귀 테스트가 안전망이 된 뒤에야 점진적으로 Unshipping합니다. 잘된 삭제는 조용합니다. 제품은 더 선명해지고, 시스템은 다시 Builder와 Grower가 움직일 공간을 되찾습니다.

Grower — 사용자의 행동을 제품에 되먹이는 사람

시스템은 단단해졌고, 군더더기도 걷혔습니다. 그런데 사용자가 기대한 지점에서 이탈합니다. 내부에서는 "이 기능이 직관적이다"라고 말하지만, 퍼널은 그렇지 않다고 말합니다. Grower는 코드의 구조가 아니라 사용자의 실제 행동 패턴을 봅니다.

질문은 이렇습니다. "사용자의 실제 행동 패턴과 요구사항에 어떻게 부합할 것인가?"

배포 이후가 시작입니다. 지표를 관찰하고, 가설을 세우고, 실험하고, 다시 관찰합니다. 마인드셋은 데이터와 유저 피드백 기반의 최적화입니다. 핵심 가치는 리텐션과 제품-시장 적합성(PMF). A/B 테스트, 피처 플래그, 프로덕트 애널리틱스, 퍼널 로깅이 그의 도구입니다.

성취감은 가설이 숫자로 증명될 때 옵니다. 카피 한 줄, 온보딩 한 스텝, 가격 노출 시점이 전환율과 코호트 리텐션을 실제로 끌어올릴 때. 반대로 가장 큰 피로는, 피드백도 데이터도 없이 직관만으로 큰 기능이 결정될 때입니다. Grower에게 "느낌상 좋을 것 같다"는 구현 허가가 아닙니다.

AI에게 맡기는 일은 실험의 뼈대입니다. 사용자 행동 이벤트 로깅 파이프라인을 깔고, 분석 스크립트를 자동화하는 일. 사람이 가설과 성공 기준을 정의하고, 에이전트가 계측을 빠짐없이 심습니다. 그가 매일 보는 지표는 코호트 리텐션, DAU/MAU, 퍼널 단계별 전환율입니다.

맹점은 단기 지표에 쫓기는 속도입니다. 승리하지 못한 실험 코드와 피처 플래그가 남고, 분기가 쌓이며 시스템은 파편화됩니다. 그래서 실험이 끝나는 즉시 패배한 코드를 회수하는 Flag Lifecycle이 의무가 되어야 합니다. 기반 아키텍처를 훼손하지 않는 범위에서만 실험하고, 승자가 확정되면 Builder와 함께 본류로 합류시킵니다. Grower의 일은 기능을 많이 넣는 일이 아니라, 사용자가 실제로 반응하는 변화만 남기는 일입니다.

Maintainer — 보이지 않는 곳에서 영속성을 지키는 사람

제품은 성장했고, 실험은 이겼고, 사용자는 늘었습니다. 이제 실패의 비용이 달라집니다. 새벽의 장애 한 번이 신뢰와 매출과 온콜 피로를 동시에 가져갑니다. Maintainer는 기능이 아니라 연속성을 책임집니다.

질문은 무겁습니다. "대규모 스케일에서도 시스템이 결함 없이 동작하도록 보장하는가?" 더 짧게 말하면, 장애 없이 영속적으로 지속 가능한 구조인가?

성숙기의 시스템은 보안 취약점, 성능 병목, 장애 위험, 인프라 비용의 비효율을 동시에 안고 있습니다. Maintainer는 이를 사전에 식별하고 제어합니다. 마인드셋은 "보이지 않는 곳에서 시스템을 지탱하는 수호" 입니다. SLO/SLA, Observability, Sentry와 Datadog, 카오스 엔지니어링, 보안 패치가 그의 언어입니다.

성취감은 아무 일도 없었던 것처럼 지나간 트래픽 피크에서 옵니다. 극한의 변동과 잠재적 장애 앞에서도 무중단 가용성이 유지될 때, 그는 일이 끝난 것이 아니라 일이 제대로 된 것을 압니다. 반대로 가장 지치는 상황은, 모니터링도 테스트도 없이 잠재 결함을 끌어안고 운영해야 할 때입니다. 관측되지 않는 시스템은 이미 장애 중입니다. 다만 아직 모르고 있을 뿐입니다.

AI 에이전트에게는 보이지 않는 위험을 맡깁니다. 의존성 취약점 점검, 잠재적 메모리 누수 분석, 성능 병목 프로파일링. 사람이 SLO를 정의하고 장애 예산을 관리하며, 에이전트가 그 경계를 밤사이 훑습니다. 그가 보는 숫자는 서비스 가용성, 에러 레이트, p99 레이턴시, 인프라 리소스 효율입니다.

함정은 안정성이라는 명분의 수문장화입니다. 모든 변경을 막고, 혁신의 속도를 조직의 병목으로 만들 수 있습니다. 보완책은 사람의 승인을 늘리는 일이 아닙니다. 자동화된 CI/CD, 카나리 배포, 즉각 롤백 — 안전하게 실패하고 빠르게 복구할 수 있는 환경을 만드는 일입니다. 좋은 Maintainer는 문을 닫지 않습니다. 문이 열려 있어도 시스템이 버틸 수 있게 만듭니다. 그리고 그 안정성 위에서, 다시 Prototyper가 다음 가설을 시도할 수 있습니다.

모자는 하나일 필요가 없다

다섯 페르소나는 순서대로 읽히지만, 엔지니어가 그중 하나에 묶이지는 않습니다. Boris Cherny의 모델이 주는 핵심 통찰이 바로 이 지점입니다.

초기 제품, 특히 1인 빌더 환경에서는 Prototyper로 가능성을 확인하고, Builder로 제품화하고, Sweeper로 복잡성을 걷어내는 전환이 거의 연속적으로 일어납니다. 성숙한 조직에서는 새로운 기회를 탐색하는 Grower와 기존 자산의 신뢰성을 담보하는 Maintainer 사이의 긴장이 건강해야 합니다. 한쪽이 이기면 제품은 정체하거나, 반대로 부서집니다.

실제로 Cherny는 Claude Code 프로젝트 초기에 혼자서 다섯 페르소나를 오가며 시스템을 키웠다고 회고합니다. 빠른 프로토타이핑으로 가능성을 확인하고, 프로덕션 아키텍처로 격상시킨 뒤, 부채가 쌓일 때마다 코드를 과감하게 지워 순도를 유지했습니다.

페르소나는 서로가 서로의 맹점을 가립니다. Prototyper의 속도는 Builder의 경계가 받아 주고, Builder의 과잉 설계는 Prototyper의 속도감과 Sweeper의 삭제가 잘라 줍니다. Grower의 실험은 Flag Lifecycle과 Builder의 본류 합류가 수습하고, Maintainer의 방어는 자동화된 안전망으로 열려 있어야 다음 가설이 들어올 수 있습니다.

한눈에 다시 보면, 각 페르소나의 가치와 도구와 함정은 이렇게 포개집니다.

결론: AI 시대, '파이(π)자형' 인재로의 확장

AI 코딩 에이전트의 등장이 엔지니어의 고유한 역할을 축소시킨다는 우려는 기우에 불과합니다. 오히려 단순 타이핑과 보일러플레이트 작성의 부담이 사라지면서, 엔지니어에게는 단일 전문 영역에만 갇혀 있던 'I자형' 또는 'T자형' 인재를 넘어 다방면의 깊이를 갖춘 '파이(π)자형 인재' 로의 진화가 요구되고 있습니다.

'파이(π)자형 인재'는 두 개 이상의 뚜렷한 전문 기둥(예: 프론트엔드 인터랙션과 고신뢰성 백엔드 아키텍처, 또는 데이터 기반 그로스와 분산 시스템 인프라)을 기반으로, 그 위를 관통하는 시스템 조망력과 AI 오케스트레이션 역량을 결합한 엔지니어를 의미합니다.

과거의 엔지니어링이 특정 언어와 프레임워크의 세부 문법을 얼마나 숙달했는가에 초점을 맞추었다면, AI 시대의 엔지니어링은 "지금 제품이 마주한 본질적인 병목이 무엇인가" 를 진단하고 최적의 페르소나를 전환할 수 있는 판단력에 달려 있습니다.

지금 조직에 필요한 것이 빠른 시장 검증(Prototyper) 인지, 구조적 확장(Builder) 인지, 과감한 단순화(Sweeper) 인지, 데이터 기반 성장(Grower) 인지, 혹은 신뢰성 수호(Maintainer) 인지를 명확히 식별하고 AI 에이전트를 적재적소에 지휘하는 힘.

도구의 장벽이 무너진 시대, 엔지니어의 진정한 경쟁력은 기술 스택의 명칭이 아니라 문제 해결의 전 주기를 조망하고 다방면의 페르소나를 넘나드는 유연한 공학적 깊이에서 비롯됩니다.

참고 자료 및 원문 링크

• Boris Cherny의 5대 프로덕트 페르소나(Product-Facing Archetypes) 원문 및 프레임워크 (@bcherny)
• Boris Cherny, Programming TypeScript: Making Your JavaScript Applications Scale (O'Reilly Media)