엔지니어링 원리 원칙 대전: AI 시대에도 변치 않는 “현장의 판단 OS”를 만들다

엔지니어링 원리 원칙 대전: AI 시대에도 변치 않는 “현장의 판단 OS”를 만들다

권장 태그:

Engineering

DevOps

SRE

Platform Engineering

AI

Architecture

Team Topologies

DORA

Qiita

엔지니어링에서 정말로 효과적인 원리 원칙은 유행하는 프레임워크의 이름이 아니다.

현장에서 오랫동안 효과를 발휘하는 것은 다음과 같은 질문들이다.

• 어디가 병목(Bottleneck)인가
• 피드백은 몇 분·몇 시간·며칠 만에 돌아오는가
• 인지 부하(Cognitive Load)는 누구에게 편중되어 있는가
• 정말로 지켜야 할 신뢰성은 어디인가
• 그 아키텍처(Architecture)는 조직 구조와 맞물려 있는가
• AI에게 맡긴 코드를 누가, 무엇으로, 어떻게 검증할 것인가

AI 코딩, Platform Engineering, SRE, DORA, Team Topologies, OpenTelemetry, SSDF, OWASP. 이름만 쫓다 보면 지친다. 하지만 그 배후에 있는 원리는 놀라울 정도로 일관적이다.

엔지니어링이란 불확실성을 검증 가능하고, 변경 가능하며, 운용 가능한 형태로 변환하는 기술이다.

이 기사는 개별 기술의 소개가 아니라, 현장에서 판단에 사용할 수 있는 「엔지니어링의 OS」를 정리한다.

읽는 대상은 소프트웨어 엔지니어, SRE, EM, PdM, Tech Lead, Platform Team, AI 시대의 개발 프로세스를 재설계하고 싶은 사람이다.

반대로, 「이 도구를 도입하면 전부 해결된다」라는 답을 찾고 있는 사람에게는 맞지 않는다. 그런 은탄환(Silver Bullet)은 없다. 아마 이번 주에도, 다음 주에도 없을 것이다.

이 기사에서 가져가야 할 것은 세 가지만 있으면 된다.

첫 번째는, 개발 생산성은 “사람의 노력”이 아니라 시스템의 흐름으로 결정된다는 관점.

두 번째는, AI 시대일수록 설계·검증·관측·의사결정 로그의 가치가 올라간다는 현실.

세 번째는, 좋은 팀은 빠른 팀이 아니라, 빠르게 학습하고 망가져도 빠르게 복구할 수 있는 팀이라는 기준이다.

2025년 Stack Overflow Developer Survey에 따르면, 응답자의 84%가 개발 프로세스에서 AI 도구를 사용하고 있거나 사용할 예정이라고 답했으며, 전문 개발자의 51%가 일상적으로 AI 도구를 사용하고 있다고 보고되었다. AI 이용은 이미 특수 기술이 아니라 일상적인 개발 환경이 되어가고 있다.

GitHub Octoverse 2025 또한 AI, 에이전트(Agent), 타입 지정 언어(Typed Language)가 소프트웨어 개발의 큰 변화를 일으키고 있다고 정리하고 있다. 특히 TypeScript가 큰 존재감을 드러낸 것은 AI 시대에도 「모호함을 줄이는 메커니즘」이 중요하다는 것을 보여준다.

다만, AI가 보급되었다고 해서 엔지니어링의 원리 원칙이 불필요해지는 것은 아니다. 오히려 반대다.

코드 생성 비용이 낮아질수록, 무엇을 만들어야 하는지, 어떻게 검증할지, 어떻게 잘 망가지지 않게 할지, 어떻게 운용할지의 가치가 올라간다.

현장의 문제는 대개 단독으로 발생하지 않는다.

"리뷰가 느리다"

"장애가 많다"

"릴리스가 두렵다"

"사양 변경이 힘들다"

"AI로 코드는 늘었지만 품질이 의심스럽다"

"Platform Team을 만들었는데, 왜인지 개발자 경험(Developer Experience)이 악화되었다"

이것들은 별개의 문제처럼 보인다. 하지만 구조는 비슷하다.

어딘가에서 국소 최적화(Local Optimization)가 전체 최적화(Global Optimization)를 망치고 있다.

현상	표면적인 원인	깊은 원인	살펴봐야 할 원리
리뷰가 정체됨	리뷰어 부족	WIP 과다, 책임 경계 불분명	리틀의 법칙 (Little's Law), 흐름 효율 (Flow Efficiency)
...

첫 번째 중요한 판단은 이것이다.

문제를 「사람」이 아니라 「시스템」으로 되돌리는 것.

누군가가 느리다. 누군가가 대충 한다. 누군가가 리뷰를 하지 않는다.

그렇게 보일 때일수록 먼저 봐야 할 것은 사람이 아니라 흐름, 대기 행렬(Queue), 인지 부하, 책임 경계, 측정 방법이다.

많은 팀은 개인의 작업 속도를 높이려고 한다.

하지만 소프트웨어 개발의 리드 타임(Lead Time)을 지배하는 것은 구현 시간보다 대기 시간이다.

리틀의 법칙(Little's Law)은 대기 행렬 이론(Queueing Theory)의 기본식으로 알려져 있다. 평균적인 시스템 내의 수 $L$, 도착률 $\lambda$, 체류 시간 $W$의 관계를 $L = \lambda W$로 나타낸다. 리틀의 1961년 논문에서는 일정 조건 하에서 이 관계가 성립함이 보여졌다.

소프트웨어 개발에 거칠게 번역하면 다음과 같다.

리드 타임 (Lead Time) ≒ 진행 중인 작업량 (WIP) / 완료율

즉, 완료율이 같다면 진행 중인 작업을 늘릴수록 속도는 느려진다.

이것은 정신론이 아니다. 시스템의 성질이다.

• 10건의 Pull Request (PR)가 정체됨
• 리뷰어가 매일 바쁨
• 우선순위 변경으로 착수 완료된 태스크가 증가함
• 사양 확인 대기, QA 대기, 릴리스 승인 대기가 증가함
• 모두가 바쁜데, 아무것도 완료되지 않음

이 상태에서 "더 열심히 하자"라고 하는 것은 불에 기름을 붓는 격이다.

필요한 것은 WIP, 즉 진행 중인 작업량을 줄이는 것이다.

개선하고 싶은 대상 = 사람의 가동률이 아니라, 완료까지의 체류 시간
봐야 할 숫자 = 착수 수, 완료 수, 체류 중인 PR 수, 리뷰 대기 시간, 릴리스 대기 시간
해서는 안 될 일 = 전원의 가동률을 100%에 가깝게 만드는 것

모두가 100% 바쁜 팀은 변화에 대응할 수 없다.

버퍼가 없는 도로가 정체되는 것과 마찬가지로, 버퍼가 없는 개발 조직은 막힌다.

DORA는 소프트웨어 딜리버리 (Software Delivery)의 퍼포먼스를 연구해 온 장기적인 프로그램이며, 개발·운영 능력과 조직 성과 사이의 관계를 다루고 있다. ([Dora][1])

DORA 지표는 단순한 DevOps 대시보드가 아니다.

현장의 대화를 "분위기"에서 "측정 가능한 개선"으로 바꾸기 위한 계기이다.

DORA는 2026년 1월 기준 가이드로, Change lead time, Deployment frequency, Failed deployment recovery time 등을 소프트웨어 딜리버리 성능의 지표로 정리하고 있다. ([Dora][2])

지표	무엇을 보는가	잘못된 사용법	좋은 사용법
Lead Time for Changes	코드 변경이 운영 환경에 도달하기까지의 시간	개인 평가에 사용	대기 시간이 발생하는 지점을 찾음
...

여기서 중요한 것은 DORA를 "순위표"로 만들지 않는 것이다.

지표는 때리기 위한 몽둥이가 아니라, 진단 장치다.

빠른 팀은 대충 내보내는 팀이 아니다.

빠른 팀은 변경 사항을 작게 만들고, 검증을 자동화하며, 문제가 생겨도 되돌릴 수 있도록 하고 있다.

DORA가 보여주는 세계관은 "속도 vs 품질"이 아니다.

정확하게는 "작고 빠르게 흘려보낼 수 있는 구조가 품질도 높인다"이다.

애자일 (Agile)은 어느샌가 미팅 체계의 이름이 되어버렸다.

데일리 (Daily), 스프린트 (Sprint), 회고 (Retrospective), 포인트 추정 (Point Estimation).

물론 도움이 되는 장면은 있다. 하지만 그것 자체가 목적이 되는 순간, 애자일은 무거워진다.

Agile Manifesto의 원칙은 "가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것"을 최우선으로 한다. ([agilemanifesto.org][3])

즉, 애자일의 중심은 프로세스가 아니다.

중심은 가치의 조기 제공과 학습 속도이다.

망가지는 방식	무엇이 일어나고 있는가	수정하기 위한 질문
스프린트가 작업 채워넣기 표가 됨	학습이 아니라 소화가 되고 있음	무엇을 검증하기 위한 스프린트인가
...

본질은 "짧은 사이클로 만들고, 보여주고, 배우는" 것이다.

이를 위해서는 사양서의 양보다 피드백의 질이 중요하다.

SRE를 "모니터링과 장애 대응 전문 부대"라고 이해하면 얕은 것이다.

SRE의 중심은 신뢰성을 감정론이 아니라, 측정 가능한 목표로 떨어뜨리는 것이다.

Google의 SRE 서적에서는 SLO는 SLI에 의해 측정되는 서비스 수준의 목표치 또는 범위라고 설명되어 있다. ([Google SRE][4])

• SLI: 무엇을 측정할 것인가
• SLO: 어디까지 지킬 것인가
• SLA: 지키지 못했을 때의 계약상의 취급
• Error Budget: 어디까지 실패를 허용할 수 있는가

여기서 중요한 것은 신뢰성은 높으면 높을수록 좋다는 식이 아니라는 점이다.

과도한 신뢰성은 비용을 늘리고 개발 속도를 떨어뜨린다.

이 서비스의 사용자에게 정말로 지켜야 할 경험은 무엇인가?
몇 %의 성공률이라면 사용자 가치를 훼손하지 않는가?
실패 예산 (Error Budget)을 다 쓰면 무엇을 멈출 것인가?
...

Google의 SRE 서적에서는 toil, 즉 수작업·반복적·자동화 가능하며 장기적 가치를 낳기 어려운 운영 작업을 줄이는 사상도 강조하고 있다. SRE 조직에서는 운영 작업을 50% 미만으로 억제하고, 최소 50%를 향후의 toil 감소나 서비스 개선으로 이어지는 엔지니어링 작업에 사용하는 목표를 제시하고 있다. ([Google SRE][5])

이것은 강력하다.

"바쁜 운영"을 미덕으로 삼지 않기 때문이다.

"엔지니어의 생산성을 측정하고 싶다"

이 질문은 위험하다. 측정 방법을 잘못 선택하면 조직이 무너진다.

코드 라인 수, 커밋 수, 티켓 처리 수, PR(Pull Request) 수.

이것들은 측정하기 쉽다. 하지만 측정하기 쉽다고 해서 반드시 중요한 것은 아니다.

SPACE Framework는 개발자 생산성을 Satisfaction and well-being(만족도와 웰빙), Performance(성과), Activity(활동), Communication and collaboration(소통과 협업), Efficiency and flow(효율성과 흐름)의 5가지 차원으로 파악하는 모델로 제안되었다. 단일 지표만으로 생산성을 판단해서는 안 된다는 점이 중요하다. ([queue.acm.org][6])

SPACE	관찰 대상	예시
Satisfaction	만족도·건강	개발자 경험, 스트레스, 지속 가능성
...

커밋 수만 본다 → 작은 변경을 남발함
코드 라인 수만 본다 → 코드를 부풀림
티켓 수만 본다 → 어려운 일을 피함
...

좋은 측정은 사람을 몰아붙이지 않는다.

시스템의 개선점을 찾아낸다.

인간의 머리는 무한하지 않다.

코드, 사양, 도메인, 인프라, CI, 권한, 운영, 보안, 모니터링, 데이터, 예외 처리. 이 모든 것을 한 사람에게 몰아넣으면 어딘가에서 무너진다.

인지 부하 이론(Cognitive Load Theory)은 문제 해결이나 학습에 있어 인간의 처리 능력에는 한계가 있으며, 불필요한 부하를 줄이는 것이 학습과 이해에 중요하다는 것을 보여주었다. Sweller의 1988년 논문은 인지 부하 이론의 기초 문헌으로 알려져 있다. ([Wiley Online Library][7])

Team Topologies는 팀 설계를 인지 부하와 가치의 흐름 관점에서 생각하는 실천 체계이며, 4가지 팀 유형, 3가지 상호작용 모드, Platform-as-a-Product(제품으로서의 플랫폼), 가치 스트림(Value Stream)과의 정렬 등을 주요 개념으로 정리하고 있다. ([팀 토폴로지스][8])

• 신규 멤버가 반년이 지나도 자립하지 못함
• 문서를 읽어도 전체상을 파악할 수 없음
• 운영 작업에 암묵지가 많음
• '잘 아는 사람'에게 의존함
• 장애 발생 시 Slack에서 사람을 찾아 헤맴
• 변경의 영향 범위를 아무도 확신하지 못함

이런 상태에서 "문서를 더 많이 쓰자"는 말은 절반만 맞다.

사실은 문서화 이전에 설계, 책임, 경계, 명명(Naming), 운영 동선이 너무 복잡할 가능성이 있다.

개발자가 헤매는 곳 = 플랫폼화 후보
자주 묻는 질문 = 문서화 후보
매번 수동으로 하는 작업 = 자동화 후보
...

Platform Engineering의 가치는 도구를 늘리는 것이 아니다.

개발자가 본래 집중해야 할 문제 이외의 것들을, 보이지 않는 곳에서 줄여주는 데 있다.

"이 서비스 경계는 왜 이렇게 이상할까?"

그렇게 생각될 때, 코드만 봐서는 답이 나오지 않는다. 조직도를 봐야 할 때가 있다.

Melvin Conway의 1968년 논문 “How Do Committees Invent?”는 시스템 설계가 그것을 만드는 조직의 커뮤니케이션 구조를 반영한다는, 이른바 Conway의 법칙(Conway's Law)의 원류로 알려져 있다. ([Mel Conway][9])

Martin Fowler 또한 Conway의 법칙의 출처가 Melvin Conway의 1968년 논문이며, Fred Brooks의 『맨먼스 미신(The Mythical Man-Month)』을 통해 널리 알려지게 되었다고 정리하고 있다. ([martinfowler.com][10])

조직이 수직적이라면, 시스템도 수직적이 된다.

승인 절차가 많으면, 배포 경로도 무거워진다.

책임 경계가 모호하면, 서비스 경계도 모호해진다.

마이크로서비스화에 실패하는 조직은 대부분 기술 때문에 실패하는 것이 아니다.

서비스 경계와 팀 경계, 그리고 의사결정 경계가 맞물리지 않기 때문이다.

역 Conway 전략(Inverse Conway Maneuver)이란, 바람직한 아키텍처에 맞춰 팀 구조를 설계하는 사고방식이다.

바람직한 상태	필요한 팀 설계
독립적인 배포를 원함	독립적으로 의사결정할 수 있는 팀
...

아키텍처 리뷰에서 조직 구조를 보지 않는 것은 지도 없이 도로를 설계하는 것과 같다.

마이크로서비스는 편리한 단어다.

너무 편리해서 무엇이든 설명할 수 있게 만든다. 그 점이 위험하다.

Martin Fowler와 James Lewis는 마이크로서비스를 "단일 애플리케이션을 작은 서비스 군으로 개발하며, 각각이 독립된 프로세스로 동작하고, 경량 통신으로 연계되며, 비즈니스 역량을 중심으로 구축되고, 자동화된 배포 메커니즘을 통해 독립적으로 배포되는 것"이라고 설명한다. ([martinfowler.com][11])

이 정의에서 중요한 것은 '작다'가 아니다.

비즈니스 능력 중심과 독립적 배포 가능성이다.

• 팀이 서비스를 소유할 수 있음

• 배포 자동화가 있음

• 모니터링(Monitoring)·로그(Log)·트레이스(Trace)가 갖춰져 있음

• API 계약을 운영할 수 있음

• 장애 격리(Fault Isolation)의 가치가 있음

• 도메인 경계(Domain Boundary)가 어느 정도 보임

• 아직 도메인이 보이지 않음

• 팀 규모가 너무 작음

• CI/CD가 취약함

• 모니터링이 취약함

• DB 분리가 불가능함

• 장애 발생 시 전원이 집합해야 함

• 단순히 '모놀리스(Monolith)가 오래됨'

모놀리스가 나쁜 것이 아니다.

나쁜 것은 변경 이유도 책임 경계도 보이지 않는 거대한 덩어리이다.

반대로, 서비스를 나누더라도 모두가 동일한 사람이 수동으로 배포하고 동일한 DB를 건드리고 있다면, 그것은 분산 모놀리스(Distributed Monolith)다. 이름만 마이크로(Micro)일 뿐, 고통은 매크로(Macro)이다.

보안을 마지막에 검토하는 조직은 매번 같은 곳에서 불이 난다.

왜냐하면 취약성의 상당수는 '구현 실수'뿐만 아니라 '설계 시점의 누락'에서 발생하기 때문이다.

NIST SP 800-218, Secure Software Development Framework version 1.1은 소프트웨어 취약성 리스크를 줄이기 위한 보안 개발 권장 사항을 정리한 문서이다. ([NIST 컴퓨터 보안 리소스 센터][12])

OWASP Top 10은 웹 애플리케이션 보안 리스크에 관한 표준적인 계몽 문서이며, 2025년판이 현재 최신 버전으로 공개되어 있다. ([OWASP Foundation][13])

OWASP Top 10:2025에서는 Insecure Design, Security Misconfiguration, Software Supply Chain Failures 등이 중요한 논점으로 다뤄지고 있다. ([OWASP Foundation][14])

AI가 코드를 작성하면 코드의 양이 늘어난다.

코드의 양이 늘어나면 공격 표면(Attack Surface)도 늘어난다.

게다가 AI가 내놓은 코드는 '그럴싸해' 보이기 때문에 인간이 방심하기 쉽다.

AI 시대의 보안 개발에 필요한 것은 AI 금지가 아니다.

필요한 것은 다음과 같은 가드레일(Guardrail)이다.

- 생성 코드의 리뷰 기준
- 의존성 라이브러리 검사
- 시크릿(Secret) 혼입 체크
...

보안은 마지막에 붙이는 스티커가 아니다.

설계, 구현, 리뷰, CI, 배포, 운영의 전 과정에 녹여내야 하는 것이다.

모니터링(Monitoring)은 알고 있는 이상 징후를 탐지한다.

관측성(Observability)은 알지 못하는 이상 징후를 조사할 수 있는 상태를 만든다.

OpenTelemetry는 클라우드 네이티브 소프트웨어를 위한 오픈 소스 Observability 프레임워크로, 트레이스(Trace), 메트릭(Metric), 로그(Log) 등의 텔레메트리(Telemetry) 데이터를 취득·수집·내보내기 위한 API, SDK, 도구 모음을 제공한다. ([OpenTelemetry][15])

CNCF는 2026년 5월 21일, OpenTelemetry의 Graduation을 발표하며 표준적인 텔레메트리 수집·처리 프레임워크로서 운영 환경에서의 성숙도를 보여주었다. ([CNCF][16])

관점	모니터링 (Monitoring)	관측성 (Observability)
주요 질문	고장 났는가	왜 고장 났는가
...

Observability를 도입하면 안심할 수 있는 것이 아니다.

로그를 늘리기만 하면 노이즈만 늘어난다.

필요한 것은 사용자 경험(UX), 서비스 경계, 의존 관계, SLO에 따른 관측 설계이다.

Platform Engineering이 유행하면 사내에 '공통 기반 팀'이 생긴다.

여기서 실패하는 회사는 플랫폼(Platform)을 프로덕트가 아니라 인프라 공유물로 취급한다.

CNCF의 Platforms White Paper는 내부 플랫폼이 애플리케이션 개발자 등 내부 고객의 작업을 촉진하고 가속하기 위해 기반 능력과 프레임워크, 경험을 수집하고 정리하여 제공하는 것이라고 설명한다. ([tag-app-delivery.cncf.io][17])

CNCF의 Platform Engineering Maturity Model은 Platform Engineering을 플랫폼의 사람, 프로세스, 정책, 기술, 사업 성과까지 포함하여 계획하고 제공하는 실천법으로 정리하고 있다. ([cloudnativeplatforms.com][18])

실패	원인
아무도 사용하지 않음	내부 고객을 보고 있지 않음
...

- 개발자가 스스로 사용할 수 있다
- 안전한 기본값(Default)이 있다
- 예외 신청이 적다
...

Platform는 강요하는 것이 아니다.

사용하고 싶어지는 "포장된 도로(Paved Road)"를 만드는 것이다.

설계 판단은 시간이 흐르면 사라진다.

그리고 반년 뒤, 누군가가 말한다.

"왜 이렇게 되어 있나요?"

그때, 대답할 수 있는 사람이 퇴사했다면 끝이다.

그래서 ADR이 필요하다.

ADR, 즉 Architecture Decision Record는 아키텍처상 중요한 의사결정을 배경, 선택지, 결정, 결과와 함께 남기는 경량 기록이다. ADR GitHub의 설명에서는 Architectural Decision을 기능 요구사항 또는 비기능 요구사항과 관련된 정당화된 설계 선택(Justified design choice)으로 정의하고 있다. ([Architectural Decision Records][19])

Martin Fowler는 Michael Nygard가 2011년에 ADR이라는 용어를 퍼뜨린 것과, ADR이 경량이며 의사결정 그 자체에 초점을 맞추는 문서라는 점을 정리하고 있다. ([martinfowler.com][20])

# ADR-0001: 인증 방식에 OIDC를 채택한다
## Status
Accepted
...

ADR의 가치는 완벽한 설계서를 만드는 것이 아니다.

미래의 회의를 짧게 만드는 것이다.

AI는 코드를 작성한다.

하지만, AI는 책임을 지지 않는다.

2025년의 DORA는 AI-assisted software development(AI 지원 소프트웨어 개발)를 다루는 보고서를 공개하며, AI가 개발 팀에 미치는 영향을 분석 대상으로 삼고 있다. ([Dora][21])

Thoughtworks Technology Radar는 AI 지원의 급격한 진화를 다루는 한편, AI로 인해 개발자 도구를 만드는 장벽이 낮아지면서 매우 새롭고 평가하기 어려운 도구도 늘어나고 있다고 지적한다. ([Thoughtworks][22])

이것은 중요하다.

AI로 만들 수 있는 것이 늘어날수록, 선택하는 힘, 버리는 힘, 검증하는 힘이 필요해진다.

AI에 맡기기 쉬운 것	인간이 쥐어야 할 것
템플릿 코드 생성	문제 설정
...

AI 시대의 최강 엔지니어는 AI를 사용하지 않는 사람이 아니다.

AI를 최대한 활용하면서, AI의 출력을 검증 가능한 공정 안에 가두는 사람이다.

1. AI에게 만들게 하기 전에, 수락 조건(Acceptance Criteria)을 작성한다
2. 생성물은 작게 만든다
3. 테스트를 먼저 준비한다
...

AI는 가속 장치이다.

단, 브레이크와 계기판이 없는 자동차로 가속하면 사고도 빨라진다.

여기서부터가 실무편이다.

이하는 팀의 Notion, GitHub Issue, Confluence, Qiita Team에 그대로 붙여넣을 수 있다.

# Engineering Decision Canvas
## 1. 해결하고 싶은 문제
- 누구의, 어떤 고통인가
...

# Weekly Flow Review
## 이번 주 완료 사항
- 완료된 변경 사항:
...

# AI Generated Code Review Checklist
## 수락 조건
- 사양을 충족하는가
...

# SLO Design Memo
## 사용자에게 중요한 경험
예: 검색 결과가 2초 이내에 반환됨
...

원리	한 줄 요약	현장에서의 질문
Little의 법칙	WIP가 늘어나면 느려진다	현재 몇 건이 정체되어 있는가
...

모두가 바쁜데 리리스(Release)가 늦다.

이것은 드문 일이 아니다. 오히려 흔히 일어난다.

원인은 사람의 능력 부족이 아니라, 버퍼(Buffer) 부족과 WIP(Work In Progress) 과다이다.

100% 가동되는 조직은 예상치 못한 업무가 올 때마다 막힌다.

서비스는 나누어져 있다.

하지만 DB는 같다.

배포는 같은 사람이 수동으로 한다.

장애 발생 시에는 전원이 집합한다.

API 계약은 모호하다.

모니터링은 부족하다.

이것은 마이크로서비스(Microservices)가 아니라, 분산된 고통이다.

Platform Team이 선의로 공통 기반을 만든다.

하지만 이용자의 업무를 보고 있지 않다.

결과적으로 개발자는 "편리한 길"이 아니라 "우회하는 검문소"를 지나게 된다.

Platform은 쓰라고 강요하는 것이 아니다.

사용하는 것이 더 빠르고, 안전하며, 편해지는 상태를 만드는 것이다.

AI가 작성한 코드는 그럴싸하다.

그럴싸한 코드는 무섭다.

왜냐하면, 틀렸더라도 읽혀버리기 때문이다.

AI 시대의 리뷰는 스타일만 봐서는 부족하다.

수락 조건 (Acceptance Criteria), 테스트, 의존성 (Dependency), 권한, 실패 시 동작까지 살펴볼 필요가 있다.

• 현재 리드 타임 (Lead Time)을 측정한다

• PR (Pull Request) 정체 수를 센다

• 배포 빈도를 확인한다

• 장애 복구 시간 (MTTR)을 확인한다

• 수동 운영 작업을 나열한다

• AI 활용 지점을 전수 조사한다

• WIP (Work In Progress)를 줄인다

• PR 사이즈를 작게 만든다

• 리뷰 관점을 통일한다

• 수동 릴리스 절차를 줄인다

• 자주 묻는 질문을 문서화한다

• SLO (Service Level Objective)를 하나 정한다

• ADR (Architecture Decision Record)을 한 권 쓴다

• AI 생성 코드 리뷰 기준을 만든다

• 플랫폼화 (Platformization) 후보를 하나 고른다

• 팀 경계와 서비스 경계를 재검토한다

• 주간 Flow 리뷰를 시작한다

• SLO 위반 시의 판단 기준을 정한다

• Toils (고된 작업)를 하나 자동화한다

• Observability (관측 가능성)의 부족함을 하나 채운다

• 한 달 뒤에 그만둘 일을 정한다

중요한 것은, 전부 다 하지 않는 것이다.

전부 다 하려고 하면, 다시 WIP가 늘어난다.

처음에는 하나로 충분하다. 흐름을 바꾸는 단 한 점을 노려라.

필요합니다. 다만, 처음부터 전부 외울 필요는 없습니다.

초보자일수록 "왜 리뷰가 있는가", "왜 테스트를 쓰는가", "왜 작게 내보내는가"를 원리로 이해하면 성장이 빨라집니다.

사용할 수 있습니다. 다만, 개인 평가에는 사용하지 않는 것이 좋습니다.

작은 팀에서는 엄격한 벤치마크보다, 대기 시간이나 변경 실패의 원인을 찾는 목적으로 사용하는 것이 현실적입니다.

피해야 하는 것이 아닙니다. 대충 시작해서는 안 된다,가 정확합니다.

독립 배포, 모니터링, 팀 소유권, API 계약, 장애 격리 준비가 되어 있지 않다면, 먼저 모듈러 모놀리스 (Modular Monolith)나 경계 정리부터 시작하는 것이 좋을 수도 있습니다.

올라가는 상황은 있습니다. 특히 템플릿 생성, 조사, 테스트 안, 리팩터링 안, 문서 초안 작성에서는 효과가 나타나기 쉽습니다.

다만, 검증 공정이 약한 팀에서는 생성량이 늘어날수록 리뷰 부하와 품질 리스크도 함께 증가합니다.

인원수만으로 결정되지 않습니다.

동일한 작업이 여러 팀에서 반복되고, 환경 구축·권한·CI/CD·모니터링·배포에서 개발자가 빈번하게 막힌다면 플랫폼 (Platform)적인 사고방식이 필요합니다. 전담 팀을 만들기 전에, Golden Path를 하나 만드는 것만으로도 효과가 있습니다.

모든 것에 엄격한 SLO를 둘 필요는 없습니다.

우선 사용자 경험이나 사업 영향이 큰 기능부터 시작하는 것이 현실적입니다. SLO는 장식이 아니라, 릴리스 판단이나 장애 대응의 우선순위를 정할 때 비로소 의미를 갖습니다.

측정 방법에 달려 있습니다.

사람을 평가하기 위해 측정하면 반감을 삽니다. 시스템을 개선하기 위해 측정한다면 오히려 도움이 됩니다. SPACE와 같이 다각도로 바라보고, 단일 지표로 사람을 심판하지 않는 것이 중요합니다.

AI는 코드를 쓴다.

도구는 매달 늘어난다.

프레임워크는 교체된다.

베스트 프랙티스 (Best Practice)는 문맥이 바뀌면 더 이상 베스트가 아니게 된다.

그럼에도 남는 것들이 있다.

• WIP를 늘리면 흐름은 느려진다
• 피드백이 늦으면 학습은 느려진다
• 인지 부하 (Cognitive Load)가 높으면 품질은 떨어진다
• 관측할 수 없는 것은 개선할 수 없다
• 조직 구조는 아키텍처에 스며든다
• 신뢰성은 감정이 아니라, 목표와 예산으로 다룬다
• 보안은 사후 처리가 아니라 공정에 내재화한다
• AI 출력물은 검증 설계 없이는 부채가 될 수도 있다
• 판단을 남기지 않는 조직은 같은 논의를 반복한다

엔지니어링이란 코드를 쓰는 것만이 아니다.

불확실한 현실을 변경 가능하고, 검증 가능하며, 운용 가능한 형태로 바꾸는 것이다.

그리고 강력한 엔지니어링 조직이란, 강력한 개인들의 집합이 아니다.

빠르게 배우고, 빠르게 되돌아오며, 불필요한 부하를 줄이고, 판단을 남기며, 고장 나는 방식까지 설계하는 팀이다.