OPERATING MODEL

AI 시대,
엔지니어가 일하는 방식

Product Engineer 와 AI-native 개발팀의 operating model

02 AI 로 구현 비용이 내려가면 무엇이 달라지는가

01

AI 로 구현 비용 감소

코드를 쓰는 비용이 내려감

02

한 엔지니어의 scope 확대

책임지는 problem & decision scope 가 넓어짐

03

operating model = product engineer

이 변화에 맞는 일하는 방식

주의

모든 software engineer 의 직무명이 바뀐다는 뜻이 아님 · 더 많은 engineer 가 product engineer 처럼 end-to-end ownership 을 맡는 방향

03 오늘 다룰 것

Part 1

요즘 회사들은 AI 와 어떻게 협업하는가

Uber · OpenAI · Naver · 우아한형제들 → 3가지 질문

Part 2

일하는 방식과 역할의 변화

AI 전후 비교 → AI-native 개발팀의 개인·팀·조직 loop → architect 와 product engineer 의 역할 재배치

Part 3

그에 따른 역량과 성장

역량 모델 → verification → 성장 모델 → 프로그램 커리큘럼

Context · Verification · Delegation → 덱 전체를 관통하는 3가지 질문

04 사례 ① Uber — agent 가 시스템 맥락 안에서 판단

70%+

PR 에 local · cloud agent 관여

review CI debugging maintenance

→ agent 담당

Context graph

24M

node

80M

edge

개별 코드베이스 한계 극복 → agent 가 시스템 맥락 안에서 판단

05 사례 ② OpenAI — 직무 무관 coding · 장기 병렬 agent

직무 무관 coding · Codex 사용 중 engineering 비율

25%

product · marketing · ops

31%

finance · bizops

엔지니어 · 연구 조직

1시간 이상 장기 작업

병렬 agent 작업

복잡한 작업은 바로 구현시키지 않음

01

context 이해

현재 시스템과 코드

02

plan 초안

architecture / implementation plan

03

AI 와 논의

대안과 trade-off 검토

04

확정 후 구현

architecture 확정 → 구현

06 사례 ③ Naver — agent 가 좋은 코드를 쓰는 환경 구축

Playwright 기반 e2e verification harness

AI 에게 코드 작성 위임 → agent 테스트 → 실패 → 수정 ↺

실패 → 수정 loop 를 agent 가 스스로 반복

Context provider

조직 · 서비스 context 를 agent 에게 제공

경험규칙기억 →축적하는 agent framework

engineer 의 역할

좋은 코드를 직접 작성

전환

agent 가 좋은 코드를 작성할 수 있는
환경 구축

ex. feedback loop

07 사례 ④ 우아한형제들 — deterministic rules 와 skills

INPUT

엔지니어링 표준 · 컨벤션

팀이 이미 가진 규칙

주입

AGENT 환경

deterministic rules + skills

agent 가 매번 같은 방식으로 따르는 규칙

결과

OUTPUT

제어 가능한 workflow

결과를 예측하고 검증할 수 있는 흐름

역할

화면 너머 비즈니스까지 내다보는 Product Engineer

08 사례에서 나온 3가지 질문

대기업 사례지만 회사 크기가 중요한 게 아님 → 모든 회사에 필요한 질문 3개

Context

agent 에게 context 를
어떻게 줄 것인가

Uber context graph Naver context provider

Verification

agent 의 결과를
어떻게 믿을 것인가

Naver e2e harness 우아한형제들 rules · skills deterministic workflow

Delegation

사람과 agent 사이에
일을 어떻게 나눌 것인가

OpenAI 장기 병렬 agent 작업

09 AI 를 쓰면 생산성은 무조건 올라간다?

확실한 것

코드 생성은 빨라짐

≠

확실하지 않은 것

생산성이 올라가는 건 아닐 수 있음

중요한 건 software engineering loop 를
재설계했는가

무엇이 바뀌었고 loop 와 역할을 어떻게 다시 그리는가 → Part 2

10 AI 등장 전 — 일하는 방식 두 가지

대기업 / 전통 조직

architect

architecture 결정

software engineer

구현

설계와 구현이 역할로 분리

테크기업 / 스타트업

staff engineer · product engineer

설계와 구현을 한 사람이 함께

설계와 구현을 함께 맡는 역할이 이미 존재

11 AI 등장 후 — 설계 비용까지 내려갔다

구현+ 시스템 탐색+ architecture 검토+ 설계 고도화 →비용 감소

01

architecture 초안

engineer 가 직접 작성

02

AI 와 논의 · 고도화

대안과 trade-off 검토

03

확정

불확실한 일부만 prototype / spike

04

구현

A·B 를 모두 구현해 고르는 방식은 일반적이지 않음

구현 context 를 가장 많이 가진 engineer 가 architecture 논의·검증에 직접 참여 → architect 의 일부 결정이 product engineer 에게 내려옴 · architect 도 hands-on

12 변하지 않은 것과 변한 것

변하지 않은 것 — 원리

경계데이터상태 인터페이스의존성 분산 시스템의 제약

변한 것 — 비용과 속도

탐색→ 적용→ 검토→ 수정

위 원리를 다루는 비용과 속도 가 바뀜

13 변화 정리 — 과거 방식 vs AI-native 방식

과거에 상대적으로 많았던 방식	AI-native 방식
맡은 기술 영역의 구현 중심	문제의 결과까지 ownership
사람이 구현 집중	사람+agent 에게 구현 분배 · 사람은 판단과 검증 집중
architecture → implementation 비교적 분리	design ↔ build ↔ verify ↔ observation 순환
architecture 를 제한된 정보로 미리 결정	AI 와 architecture 를 빠르게 탐색·검토·고도화
코드가 주요 산출물	working software system 전체가 산출물

14 AI-native 개발팀이란

★ 정의

문제를 발견한 사람이 agent 와 함께 동작하는 시스템까지 직접 만들고 검증하며, 팀은 그 loop 가 빠르고 안전하게 돌도록 context 와 guardrail 을 함께 설계하는 조직

LOOP 1

개인 loop

LOOP 2

팀 loop

LOOP 3

조직 loop

세 층으로 설명

15 개인 loop — Discover 에서 Learn 까지 7단계

01 Discover

문제 발견

현실의 문제를 찾음

02 Design

설계 초안 · 확정

현실 문제 → 기술 설계 · architecture 초안 · AI 와 대안·trade-off 논의 후 확정

03 Build

구현

AI 와 함께 구현

04 Verify

검증 workflow

테스트 생성 → 실행 → 실패 → 수정 → 전체 통과

↻ Learn → 다시 Discover 로 · 끝없이 도는 고리

05 Deploy

배포

배포 방식 · 인프라 선택과 구현

06 Observe

관찰

logging · error · 사용자 반응

07 Learn

학습

architecture · context · workflow 개선점

16 팀 loop — Execute → Learn → Reconcile → Equip + Bound

여러 개인 loop 에서 반복되는 학습 → 팀 차원의 환경 개선

Execute

개인 loop 수행

각 engineer 가 자기 loop 를 돌림

Learn

반복 문제 발견

friction · architecture conflict

Reconcile

evidence 에 맞게 조정

architecture · boundary · contract

Equip

환경 개선

rules · skills · harness · shared context

↻ Equip → 다음 Execute 로 · 팀 환경이 나아진 채로 다시

Bound개인 loop 가 서로 충돌하지 않게

경계contractguardrail → rulesskillsharness 로 구축

17 조직 loop — 팀 간 충돌과 맥락을 조직 차원에서

Execute

Learn

Reconcile

Equip

↻ 조직 차원에서도 같은 고리

① 충돌 조정

여러 팀의 local optimum 충돌 조정

outcome 과 incentive 가 충돌할 때 해결 · A 팀은 편해지고 B 팀은 불편해지는 경계 결정

② 조직 맥락을 agent 에게

원칙 · 경계를 agent 가 소비하는 형태로

아키텍처 원칙 · domain boundary · 공유 contract · 보안 정책 — 위키·리뷰·회의록에 흩어진 것을 모아 제공 (context provider · context graph)

③ 검증 인프라

검증 인프라를 조직 책임으로

e2e harness · deterministic workflow

④ 사람과 책임

인력 배치 · 팀 책임 조정

여러 팀 loop 에서 반복된 학습과 충돌을 조직 차원에 반영

18 nested loop — 세 loop 의 연결

evidence ·
learning

위로

조직 loop여러 팀의 충돌 조정 · 조직 맥락 · 검증 인프라

팀 loopExecute → Learn → Reconcile → Equip + Bound

개인 loopDiscover → Learn → 다시 Discover

Discover

Design

Build

Verify

↻

Deploy

Observe

Learn

개선된
환경

아래로

개인 → 팀 → 조직으로 갈수록 같은 learning loop 의 범위 확대 · 하위의 evidence 는 상위의 architecture·context·guardrail 개선으로 · 상위의 개선된 환경은 하위 loop 를 더 빠르고 안전하게

19 loop 속도 — 개인이 빨라지면 팀·조직이 병목

개인 loop

AI 로 가장 먼저 빨라짐

팀 loop

조정 속도 그대로

조직 loop

조정 속도 그대로

새 병목

stale architecture outdated rules approval / coordination 병목

대응

팀·조직 loop 의 feedback latency 를 하위 loop 의 변화 속도에 맞게 단축

모든 loop 가 같은 속도일 필요는 없음 · 범위가 클수록 신중한 판단 · 다만 상위가 하위를 못 따라가면 병목

20 역할의 재배치 — 결정은 현장으로, coherence 는 더 중요하게

결정의 이동

architect

기존에 하던 architecture 결정

결정의 일부

product engineer

구현 context 를 가장 많이 가진 사람 · architecture 를 구체적으로 검토하고 결과를 빠르게 확인

그러나

local context ≠ global context

한 팀의 최적이 30개 팀의 보안 · 비용 · 규제에서는 최적이 아닐 수 있음

결정은 현장으로 내려오지만, 조직 전체의 technical coherence 를 책임지는 역할은 더 중요해짐

21 architect 의 책임 — 그리고 hands-on

domain boundary

platform 전략

data ownership

공유 contract

reliability

scalability

architecture evolution

agent 에게 context 와 constraints 제공

팀 간 local optimum 충돌 조정

이들도 hands-on

실제 시스템과 agentic engineering 의 capability · constraint 를 체감할 만큼 직접 만들기 → 실효성 있는 상위 설계 · 정책 결정

22 역량 모델 — 3대 역량 + 관통하는 verification

①

Product Engineering

고객 · 비즈니스 문제 → 제품

②

Architecture Engineering

제품 → 확장 · 유지보수가 쉬운 시스템

③

AI Engineering

AI 로 engineering · AI 를 engineering

Verification

세 영역 전체를 관통 · e2e harness · deterministic workflow

제품을 시스템으로

AI 로 제품을 만든다

AI 를 system 에 engineering

23 역량 상세 ① Product Engineering — 문제에서 제품으로

고객 · 비즈니스 문제 발견

product engineering

제품

공감 능력

고객에게 공감하며 진짜 문제를 발견

구현 능력

AI 와 함께 feature · product · system 을 구현

제품 레벨의 추상화

현실 세계의 문제 → 기술적 설계

24 역량 상세 ② Architecture Engineering — 제품에서 시스템으로

제품

architecture engineering

확장 · 유지보수가 쉬운 시스템

boundarystatedata interfacedependency quality attributesevolution

scope 가 커질수록

조직 전체의 technical coherence 를 책임

hands-on

돌아가는 system 을 agentic engineering 으로 만드는 역량

25 역량 상세 ③ AI Engineering — AI 로 engineering · AI 를 engineering

AI 를 이용해 engineering 하고, AI capability 자체를 product / system 에 engineering 하는 역량

AI 로 engineering 하는 능력

AI 를 도구로 써서 만드는 쪽

coding agentscontext engineering skillsharness delegationevaluation

AI 를 포함한 product / system 을 engineering 하는 능력

AI 가 제품 안에 들어가는 쪽

modelinferenceagents memorytoolsconstraints evalsafetyreliability

26 Verification — 세 영역 전체를 관통하는 핵심 역량

Product Engineering

Architecture Engineering

AI Engineering

Verification — 세 영역 어디에나 들어감

AI 생성 코드와 agent 결과를 믿을 수 있게 하는 장치 설계

e2e harness

테스트 생성

실행

실패

↻

코드 수정

모든 테스트를 통과할 때까지 반복 → 모든 테스트 통과

deterministic workflow

rules · skills 로 agent 가 매번 같은 방식으로 따르는 흐름 → 결과 예측 · 검증 가능

27 성장 모델 ① Depth — 깊이 (전문성)

특정 영역에 깊이

FEBEinfra datamodelagent AI infra등

한 영역을 깊이 아는 힘 · 다른 두 축의 출발점

28 성장 모델 ② Breadth — 넓이 (e2e 범위)

인접 영역을 AI 와 함께 다룰 수 있게 되는 것

FE→ BEDBdeployment SREobservability등

역할 수행에 필요한 범위를 AI 와 함께 스스로 해결할 수 있을 만큼의 능력

29 성장 모델 ③ Scope — 영역 (architecture)

판단하는 영역이 넓어진다

feature

product

service /
domain

multiple
domains

platform

organization

architecture 에서 특히 seniority 와 강하게 연결

30 예시 — frontend 개발자가 product engineer 로 전환

Depth

FE유지

Breadth

BEdatadeploy

Scope

feature→product→domain

→ product engineer

31 프로그램 커리큘럼 — 이 operating model 로 일하는 훈련

철학

엔지니어가 실제로 이 operating model 로 일할 수 있도록 훈련 · 하나의 실제 제품 문제를 놓고 loop 여러 회차 반복

1회차
단일 feature

2회차
product 단위

3회차
AI 기반 e2e 구현

N회차
도메인 경계 · 플랫폼 제약 · 데이터 정합성 · 비용 · 보안 가드레일

breadth 확장 — 단일 feature · product 단위 → AI 기반 e2e 구현 경험

scope 확장 — 복잡한 시스템 과제 수행

32 회차마다 자라는 것 — verification · Learn → Reconcile → Equip · 3가지 질문

매 회차 verification 발전

나만의 harness 구축 · 개선

매 회차 실제 loop — Learn → Reconcile → Equip

작업 중 발견한 문제를 반영

contextarchitecture rules / skillsharness

회차별 3가지 질문에 자기 답

ContextVerificationDelegation

자기 규모에 맞는 답을 직접 만들기

최종적으로

개인 loop 뿐 아니라 팀 · 조직에서 이 loop 가 어떻게 확장 · 연결되는지 이해

33 정리 — 세 문장

1

구현 비용 감소 → 한 사람의 scope 확대 → product engineer 처럼 일하는 방향

2

생산성은 코드 속도가 아니라 loop 재설계에서 — 개인 · 팀 · 조직 loop 의 속도 정합

3

모든 회사가 답해야 할 3가지 질문 — context · verification · delegation

Q & A

AI 시대, 엔지니어가 일하는 방식 — Product Engineer 와 AI-native 개발팀