올해 엔지니어가 내릴 가장 중요한 결정

Source: Dev.to

엔지니어를 위한 이분법적 선택

옵션 A: 인간이 작성한 것처럼 코드를 한 줄씩 계속 검토합니다. 이 경로는 당신이 병목이 되어 팀의 처리량을 억제한다는 것을 보장합니다.

옵션 B: 검토 정책을 발전시켜 저수준 구현 제어를 AI에 맡겨 고수준 아키텍처 속도를 확보합니다.

만약 옵션 A를 선택한다면, 이 글은 당신에게 맞지 않습니다. 외부 지표가 변화를 강요할 때까지 끊임없이 늘어나는 풀 리퀘스트 물결에 계속 빠질 가능성이 높습니다.

만약 옵션 B를 선택한다면, 패러다임 전환을 준비한 것입니다. 하지만 거버넌스 시스템 없이 무작정 “AI에게 코딩을 맡기는” 것은 혼란을 초래합니다. 구현의 모든 줄을 일일이 검토하지 않고도 시스템 품질을 유지할 수 있는 견고한 전략이 필요합니다. 옵션 B를 현실로 만드는 다섯 가지 전략을 소개합니다.

속도 함정: 옵션 A가 수학적으로 불가능한 이유

이 결정은 확고한 수학적 현실에 의해 좌우됩니다.

• 숙련된 엔지니어는 시간당 약 200줄의 복잡한 코드를 의미 있게 검토할 수 있습니다.
• AI 에이전트는 초당 200줄의 코드를 생성할 수 있습니다.

Option A를 선택하면, 선형적인 인간 처리 속도와 지수적인 AI 생성 속도를 겨루게 됩니다. 팀이 더 많은 AI 도구를 도입할수록 생성되는 코드 양은 급격히 증가합니다. 검토 정책을 “모든 라인을 인간이 직접 확인”으로 유지한다면, 백로그는 무한히 늘어나고 속도는 결국 0에 수렴하게 됩니다.

기계를 읽어내는 것을 능가할 수 없습니다. 당신은 기계를 생각하는 방식을 능가해야 합니다.

전략 1: 추상화 사다리 오르기

첫 번째 단계는 소프트웨어에 대해 이해하고 있는 것을 재정의하는 것입니다.

전통적으로 “코드베이스를 이해한다”는 것은 특정 함수 안에서 if 문이 어떻게 작동하는지를 아는 것을 의미했습니다. AI 시대에는 이것이 지속 가능하지 않습니다. 정신 모델을 다음과 같은 계층 구조로 나누세요:

Product → System → Modules → Functions

전환: 가장 낮은 수준(예시에서는 함수)을 검토하는 것을 중단합니다.

제품에 Stripe 통합이 있다면 코드가 삼항 연산자를 사용하든 if‑else 블록을 사용하든 신경 쓸 필요가 없습니다. 대신 청구 시스템 안에 Stripe 모듈이 존재하고 특정 계약을 준수한다는 사실에 주목해야 합니다.

당신의 역할은 상위 수준(제품 및 시스템)의 명확한 정신 모델을 유지하는 것입니다. 이는 **The Principle of Contractual Specialization**와 일치합니다. 경계를 견고하게 유지함으로써 AI가 그 경계 내 구현 세부 사항을 처리하도록 할 수 있습니다. **Coding is Now a Commodity**에서 언급된 바와 같이, 가치는 “벽돌”(함수)에서 “청사진”(시스템 아키텍처)으로 이동했습니다.

Strategy 2: 코드가 아니라 지시사항 검토

아키텍처나 로직에 결함을 발견하면, 본능적으로 코드를 수정하고 싶어집니다. 그것을 억제하세요.

AI가 여러분의 아키텍처를 위반하는 코드를 생성한다면, 이는 멘토십 실패입니다. 코드를 다시 쓰는 대신, 이를 생성한 instruction 또는 system prompt를 다시 작성하세요.

이렇게 하면 여러분은 코드 리뷰어에서 에이전시의 설계자로 변합니다. **From Scripter to Architect**에서 논의된 바와 같이, 여러분은 더 이상 흐름의 작성자가 아니라 경계의 설계자입니다. 지시문을 수정하면 다음 100개의 기능을 작성할 “직원”을 유지할 수 있지만, 코드를 수동으로 수정하는 것은 아무것도 가르치지 못하고 단 한 번의 사례만 해결합니다.

전략 3: 안전망으로서의 자동 검증

저수준 코드를 검토하지 않는 것에 대한 두려움은 합리적입니다: “버그가 있으면 어떡하지?”

여기에 세 번째 전략이 있습니다: 공격적인 자동 테스트.

함수를 검토하는 일을 멈추면 눈으로 미묘한 논리 버그를 찾아내는 능력을 잃게 됩니다. 그 수동적인 경계를 **자동 검증**으로 대체하세요.

• 테스트는 세부 사항을 “무시”해도 된다는 것을 보장합니다.
• 엔지니어(또는 AI)가 완전히 이해하지 못하는 저수준 모듈에서 버그를 수정해야 할 때, 테스트 스위트가 가드레일 역할을 하여 Stripe 통합을 수정해도 User Auth 흐름이 깨지지 않도록 합니다.

이는 **내재 검증 원칙**을 구현합니다. 수동 검토의 높은 마찰 비용을 견고한 테스트를 작성하는 초기 비용으로 교환함으로써 **AI 검증 함정**을 피하고 구문보다 시스템 수준 제약에 집중할 수 있습니다.

전략 4: 스키마 우위 적용

모든 것을 검증할 수는 없지만, 경계는 검증할 수 있습니다.

AI가 한 줄의 로직을 작성하기 전에, 입력 및 출력 스키마(Types, Interfaces, Zod schemas)를 엄격히 정의합니다. 이것이 Schema Supremacy 입니다.

• 모듈에 들어오고 나가는 데이터 형태를 제어하면 내부에서 데이터가 어떻게 변환되는지에 대해 크게 신경 쓸 필요가 줄어듭니다.
• 변환 로직보다 계약의 엄격성을 검토합니다.
• AI가 스키마를 준수한다면, 나쁜 코드가 발생할 수 있는 범위가 제한됩니다.

Source: …

전략 5: 관찰성을 이자 지급으로

리뷰 깊이를 속도와 교환하면, 기술적으로 일종의 위험을 감수하게 됩니다. 이 위험에 대한 비용은 관찰성으로 지불합니다.

• “이 코드가 깨끗한가?”에서 “시스템이 건강한가?”로 초점을 전환합니다.
• 프로덕션에서 엣지 케이스가 나타날 경우 크게 경고하는 로그, 메트릭, 알림을 확보하세요.

이는 [Observability as …] (링크는 추후 추가)와 일치합니다.

[Interest Payments](https://ttoss.dev/docs/engineering/guidelines/technical-debt#4-observability-as-interest-payments).  
If you can't see it fail, you can't afford to let the AI write it without review.

결론

리뷰어에서 아키텍트로 전환하는 결정은 관련성과 활용도에 관한 것입니다.

당신은 매달 하나의 기능을 배포하면서 누락된 세미콜론을 모두 잡아내는 문지기 역할을 계속하면서, 모든 코드를 자랑스럽게 소유할 수 있습니다. 혹은 시스템을 정의하고, 지침을 작성하며, 검증 루프를 강제하는 아키텍트로 진화하여, AI 인력이 컴퓨팅 속도만큼 빠르게 배포하도록 지원할 수도 있습니다.

첫 번째 길은 전통적인 엔지니어링으로 이어집니다. 두 번째 길은 엔지니어링의 미래를 정의합니다. 선택은 여러분의 몫입니다.