By webnautes in 생각 — 01 Sep 2025

프로덕트 엔지니어(The Product Engineer)

GeekNews(https://news.hada.io/) 에서 발견한 생소한 프로덕트 엔지니어에 관한 다음 글을 클로드의 도움을 받아 내용을 보충하고 이해하기 쉽게 정리했습니다.

The Product Engineer
https://nandinfinitum.com/posts/the-product-engineer/

프로덕트 엔지니어(Product Engineer)

프로덕트 엔지니어링에 대한 흩어진 생각과 아이디어를 정리하려는 시도

배경(Background)

우리가 알고 있던 고전적인 소프트웨어 엔지니어링은 죽었습니다. 그럴 만한 이유가 있습니다. 프로그래밍의 진정한 패러다임의 마지막 변화는 1972년 Dennis Ritchie가 C 프로그래밍 언어를 발표했을 때였습니다. 그 이후로 모든 것은 기계 코드를 더 쉽게 작성하고 번역할 수 있도록 최적화되고 추상화되었습니다. 오래전부터 프로그래머들의 실력과 생산성은 주로 세 가지로 평가받았습니다. 첫째는 프로그램이 얼마나 빠르게 실행되고 메모리를 효율적으로 사용하는가, 둘째는 코드를 얼마나 간결하게 작성했는가, 셋째는 작성한 코드를 다른 개발자들이 얼마나 쉽게 읽고 이해할 수 있는가였습니다."

우리는 이제 프로그래밍 언어가 훨씬 발전한 새로운 시대에 살고 있으며, 예전처럼 이해하기 어렵고 복잡한 저급 언어를 사용하던 시절로 돌아갈 일은 거의 없을 것입니다.

게임 개발의 전설인 존 카맥이 최근에 이런 말을 했습니다. 머지않아 개발에서 가장 좋은 도구가 직접 코딩하는 것에서 AI의 도움을 받는 것으로 바뀔 것이라고 했습니다. 그래서 개발자들은 '제품 개발 능력(문제 해결 능력과 좋은 제품을 만드는 능력)'에 더 집중하고, 그때그때 가장 좋은 도구를 계속 사용해야 합니다.

소프트웨어 엔지니어링은 점차 프로덕 엔지니어링으로 변모할 것입니다. 다음은 그 모습에 대한 몇 가지 아이디어입니다

프로덕트 엔지니어

프로덕트 엔지니어는 프로덕트 관리자(product manager)와 풀 스택 소프트웨어 엔지니어가 혼합된 개념입니다. 이들은 전체 제품 주기를 소유하고 제품에 의해 생사를 좌우하는 프로그래머입니다.

단순히 코드만 작성하는 것이 아니라, 제품 기획부터 개발, 출시, 운영까지 모든 과정을 담당합니다. 마치 제품 관리자의 비즈니스 감각과 풀스택 개발자의 기술력을 모두 갖춘 사람들이라고 볼 수 있습니다.

이들의 가장 큰 특징은 자신이 만드는 제품에 대해 완전한 책임을 진다는 것입니다. 제품이 성공하면 자신의 성공이고, 실패하면 자신의 실패로 받아들입니다. 그래서 고객과 직접 소통하고, 사용 데이터를 분석하고, 제품 로드맵까지 결정하는 등 제품의 모든 면에 깊이 관여합니다.

프로덕 엔지니어는 다음과 같은 특징을 가질 것입니다:

AI 중심적: AI를 단순한 부가 도구가 아닌 기본 작업 도구로 사용합니다. 즉, AI 없이는 일하기 어려울 정도로 AI를 자연스럽게 활용하는 개발자들입니다

T자형 스킬: 엔지니어링에는 깊은 전문성을 가지고 있지만, 제품 기획, 데이터 분석, 디자인 등 다른 영역에서도 폭넓은 지식을 갖춘 사람들입니다. 마치 알파벳 T자처럼 한 분야에서는 깊고, 여러 분야에서는 넓게 아는 형태입니다.

결과 중심적: 단순히 코드를 작성하는 것이 아니라, 사용자 유지율, 활성화율, 전환율 같은 비즈니스 성과 지표를 직접 책임지고 관리합니다.

높은 자율성: 아이디어에서부터 기획서 작성, 디자인, 배포까지 전체 과정을 혼자서 처리할 수 있을 만큼 독립적으로 일할 수 있습니다.

프로덕트 엔지니어들은 소수 정예의 효율적인 팀을 만들 것이고, 팀원들끼리는 서로 업무를 바꿔서 할 수 있을 정도로 능력이 비슷할 것입니다.

조직 구조의 변화: "기존에는 기술 분야별로 팀을 나누었습니다 - 프론트엔드 팀, 백엔드 팀, 인프라 팀 이런 식으로요. 하지만 이제는 제품이나 기능별로 팀을 구성할 것입니다.

결과 중심의 업무 방식: 엔지니어들이 더 이상 기술 영역별로 분리되지 않고, 비즈니스 성과에 따라 함께 일하게 됩니다. 예를 들어 한 프로덕트 엔지니어는 회원가입 과정을, 다른 엔지니어는 결제 시스템을, 또 다른 엔지니어는 알림 기능을 담당하되, 각자 자신의 기능에 대해 사용자 경험부터 데이터 처리까지 모든 것을 책임집니다.

팀 구조의 근본적 변화: "조직 구조가 '프론트엔드/백엔드/인프라 팀'에서 '기능별 스쿼드(feature squads)'로 바뀝니다. 각 스쿼드는 모든 기술 영역을 다룰 수 있는 완전한 자율성을 갖게 됩니다."

프로덕트 엔지니어는 제품(개발 전)과 엔지니어(개발 중/개발 후)라는 두 가지 측면을 가지고 있습니다.

제품(The Product)

프로덕트 엔지니어에서 '제품' 담당 부분의 업무는 다음과 같습니다

제품 아이디어 발굴: 제품의 핵심 기능과 가치 제안, 타겟 사용자층을 찾아내고 구체적으로 정리하는 일입니다.

마인드맵 작성: 하나의 핵심 개념에서 시작해서 관련된 아이디어나 업무를 그림이나 도표로 시각화하는 작업입니다.

브레인스토밍: 혼자서 아이디어를 정리한 후, 다른 사람들에게 전달해서 아이디어를 더 발전시키고 개선하며 피드백을 받는 과정입니다.

제품 발굴: 고객의 니즈를 탐색하고 연구해서 이해하고, 시장 기회를 찾아내어 비즈니스 목표에 부합하면서 사용자에게 가치를 제공하는 제품을 개발하는 일입니다.

우선순위 선정: 제품의 전략적 방향, 비즈니스 목표, 고객 요구사항, 시장 동향을 바탕으로 어떤 기능과 프로젝트를 우선적으로 진행할지 결정하는 업무입니다.

시장 분석: 제품이 진출할 시장을 분석하고 조사하는 일입니다.

사용자 리서치: 사용자의 필요사항, 행동 패턴, 불편한 점들을 조사하고 이해하는 과정입니다.

제품 디자인: UI/UX 디자인, 서비스 디자인, 인터랙션 디자인, 사용자 테스트 등을 포함하는 전반적인 제품 설계 업무입니다.

앞서 언급한 업무들은 전통적인 제품 기획자의 역할들로, 정말 많은 일처럼 보일 수 있습니다. 하지만 기억하세요: AI는 여러분의 편입니다. AI를 위해 일하는 것이 아니라, AI와 함께 일해야 합니다.

AI의 현재 능력과 한계: 현재 AI는 기존 정보를 재조합하고 반복하는 일은 매우 잘하지만, 완전히 새로운 아이디어를 만들어내는 것은 그리 잘하지 못합니다.

올바른 AI 활용 방법: 제품에 대한 비전은 반드시 여러분이 유지해야 하며, AI는 아이디어를 발전시켜 나가는 과정에서 의견을 나누는 상대방 역할로만 활용해야 합니다. 큰 틀의 비전만 제시하면, AI 도구들은 비슷한 프로젝트에서 이미 보았던 일반적인 문제점들을 해결하는 데 도움을 줄 수 있습니다.

엔지니어(The Engineer)

프로덕트 엔지니어에서 나머지 절반은 이제 구체적으로 계획된 프로젝트 명세서를 실제로 실행하는 일을 담당합니다. 프로덕트 엔지니어는 다음 4가지 주요 영역을 책임집니다:

소프트웨어 아키텍처: 한번 구현되면 나중에 바꾸기 어려운 구조적 선택들에 대한 결정을 내리는 일입니다. 이는 전체 시스템의 청사진을 설계하고, 확장성, 성능, 보안 등을 고려한 기본 틀을 만드는 작업입니다.

시스템 설계: 시스템을 정의하고 개발하는 일로, 시스템의 구성 요소들과 그들 간의 상호작용, 데이터 흐름 등을 설계하는 작업입니다.

프론트엔드 엔지니어링: 시각적 디자인을 실제로 구현하고, 사용자가 직접 마주하는 기능들을 만드는 일입니다. 사용자 인터페이스(UI)와 사용자 경험(UX)을 코드로 구현하는 작업이죠.

백엔드 엔지니어링: 비즈니스 로직의 구현 및 최적화와 데이터베이스 설계를 담당하는 일입니다. 서버 사이드에서 데이터 처리, API 개발, 보안 등 사용자 눈에 보이지 않는 핵심 기능들을 개발하는 작업입니다."

엔지니어링이라는 빙산이 얼마나 깊은지, 그리고 제가 간과한 중요한 영역들—테스팅, 관찰가능성, 그리고 (역설적이게도) AI 통합 같은 부분들이 있다는 것을 잘 알고 있습니다. 하지만 대부분의 프로젝트에서는 이런 고급 솔루션들보다 SLC(Simple, Lovable, Complete: 간단하고, 사랑받을 만하며, 완성도 높은) 제품을 만들어서 출시하는 것이 더 중요합니다.

AI가 엔지니어링에서 더 유리한 이유: 코딩용 LLM들은 명확하게 정의되고 결정론적인 환경에서 잘 작동하기 때문에, 제품 기획 쪽보다는 엔지니어링 영역에서 AI가 훨씬 더 많은 무거운 작업을 대신 처리할 수 있습니다.

현재 상황: AI 활용은 여전히 떠오르는 주제이고, 우리는 (대부분) 아직도 이를 알아가는 과정에 있습니다.

다음은 몇 가지 일반적인 가이드라인입니다:

계획(Planning)

AI 코딩 도구를 제대로 활용하려면 가장 중요한 것이 있습니다. 바로 AI에게 '무엇을 만들고 싶은지', '어떻게 만들어야 하는지'를 명확하게 알려주는 것입니다.

프로젝트 요구사항을 체계적으로 정리해서 AI에게 제공하는 것은 단순한 작업이 아니라, 앞으로 계속 좋은 코드를 받아보기 위한 중요한 투자입니다.

그리고 '룰(Rules)'이라는 기능을 통해 AI에게 코딩 스타일, 아키텍처 패턴, 팀 컨벤션 등을 미리 알려줄 수 있습니다. 한번 설정해두면 AI가 계속 기억하고 활용하기 때문에, 매번 같은 스타일로 일관성 있는 코드를 만들어줍니다.

특히 Cline 같은 도구들은 이런 룰을 어떻게 효과적으로 작성해야 하는지에 대한 가이드도 제공합니다. 룰을 작성할 때는 다음과 같은 구조를 따르면 됩니다:"

# Project Guidelines

## Documentation Requirements

-   Update relevant documentation in /docs when modifying features
-   Keep README.md in sync with new capabilities
-   Maintain changelog entries in CHANGELOG.md

## Architecture Decision Records

Create ADRs in /docs/adr for:

-   Major dependency changes
-   Architectural pattern changes
-   New integration patterns
-   Database schema changes
    Follow template in /docs/adr/template.md

## Code Style & Patterns

-   Generate API clients using OpenAPI Generator
-   Use TypeScript axios template
-   Place generated code in /src/generated
-   Prefer composition over inheritance
-   Use repository pattern for data access
-   Follow error handling pattern in /src/utils/errors.ts

## Testing Standards

-   Unit tests required for business logic
-   Integration tests for API endpoints
-   E2E tests for critical user flows

대부분의 코딩 IDE(예: / Generate Cursor Rules)에서도 자동으로 생성할 수 있습니다.

소프트웨어 아키텍처(Software Architecture)

소프트웨어 아키텍처는 큰 그림을 그리는 일입니다. 건물을 지을 때 기초와 골조를 결정하는 것처럼, 소프트웨어에서도 전체 시스템의 뼈대가 되는 중요한 결정들을 내려야 합니다. 한번 정해지면 나중에 바꾸기가 매우 어렵고 비용이 많이 드는 결정들이죠.

주요 아키텍처 결정사항들:

아키텍처 패턴 선택: (예: 모놀리식 vs 마이크로서비스, 서버리스 vs 컨테이너화 등)
의존성 관리와 통합 경계 정의
모듈화와 관심사 분리 강제
통신 프로토콜 정의: (REST, GraphQL, gRPC, 이벤트 버스 등)
확장성 전략: (나중에 미루더라도, 예를 들어 수평 확장을 고려하는지 여부)

예를 들어, 하나의 큰 애플리케이션으로 만들지 아니면 작은 서비스들로 나누어서 만들지, 어떤 방식으로 데이터를 주고받을지, 시스템이 커졌을 때 어떻게 확장할지 같은 것들입니다.

AI는 이런 아키텍처 설계에서 도우미 역할은 할 수 있습니다. 여러 옵션들의 장단점을 분석해보거나, 시스템 구조도를 그려주거나, 결정 사항들을 문서로 정리하는 데 도움을 줄 수 있죠.

하지만 AI의 제안을 그대로 믿고 따라가면 안 됩니다. 아키텍처 결정에는 비즈니스 맥락, 팀의 역량, 조직의 문화, 장기적인 비전 등 AI가 완전히 이해하기 어려운 복잡한 요소들이 많이 관련되어 있기 때문입니다. 따라서 경험 많은 아키텍트의 전문성이 여전히 매우 중요하고, 앞으로도 그럴 것입니다.

시스템 설계(System Design)

시스템 설계는 아키텍처가 실제 코드로 구현되는 단계입니다. 큰 그림에서 그린 설계도를 실제로 동작하는 시스템으로 만들기 위해 구체적인 작업들을 하는 것이죠.

예를 들어, '사용자가 주문을 할 수 있다'는 기능이 있다면, 이를 실제로 어떤 API로 만들지, 데이터는 어떻게 저장하고 처리할지, 주문 상태가 '대기 중' → '처리 중' → '완료' 같은 과정을 어떻게 관리할지 오류가 발생하면 어떻게 대응할지 등을 구체적으로 정해야 합니다.

이런 작업에서 AI가 꽤 도움이 될 것 같습니다. API 설계 초안을 만들어달라거나, 데이터베이스 구조를 제안해달라거나, 상태 머신을 그려달라고 요청할 수 있겠죠.

특히 유용할 것 같은 방법은 이런 겁니다: 여러분이 먼저 대략적인 설계안을 만들고, AI에게 '이 설계에서 문제가 될 만한 부분이 있나?', '놓친 엣지 케이스가 있나?', '더 나은 방법은 없나?' 같은 질문을 던지는 것입니다. 마치 경험은 부족하지만 열정적이고 겸손한 주니어 개발자와 함께 코드 리뷰를 하는 것처럼 말이죠.

일반적인 시스템 설계 작업에는 API 및 서비스 경계 정의, 데이터 모델과 계층 간 데이터 흐름 방식 매핑, 오류 처리/장애 복구, 상태 전환 또는 비동기 워크플로우 모델링, 설계 문서 작성 및 에지 사례 검토 등이 포함됩니다.

프론트엔드 엔지니어링(Frontend engineering)

프론트엔드 엔지니어링의 본질: "프론트엔드 엔지니어링은 시각적 디자인과 사용자 대면 기능을 구현하는 일입니다. 제 경험상, AI는 이 영역에서 꽤 뛰어난 성능을 보입니다. 특히 React 같은 JavaScript 프레임워크에서 그렇습니다 (가장 인기 있는 프론트엔드 언어의 가장 널리 사용되는 프레임워크이기 때문입니다). React의 보편성은 광범위한 문서와 잘 정립된 패턴들이 존재한다는 것을 의미하며, 이는 모두 AI들에게 매우 유리한 조건입니다.

효과적인 AI 활용 기법: "AI 어시스턴트의 성능을 끌어올리는 유용한 기법 중 하나는 AI가 한 줄의 코드도 작성하기 전에 모든 브랜드 가이드라인(폰트, 색상)에 맞는 디자인 프레임워크를 제공하는 것입니다." AI 에디터에 브랜드 가이드라인 스크린샷 몇 장을 제공하고, 이러한 가이드라인들을 코드로 정의하게 하는 것이 엄청난 성과를 가져다주었습니다.

브랜드 가이드라인의 구체적 요소들: 이런 브랜드 가이드라인들은 폰트, 색상 팔레트, 제목 크기, 행간과 자간, 그리고 기타 반복 가능한 시각적 구성 요소들을 정의할 수 있습니다. 또한 이러한 구성 요소들이 다양한 화면 크기에서 어떻게 반응형으로 동작해야 하는지 명시하는 것도 도움이 됩니다.

AI의 코드 생성 능력: 이로부터 AI는 이러한 요소들을 코드로 정의할 수 있습니다 (예: Tailwind 설정, CSS 변수로). 이는 일관된 시각적 기반을 만들고 앞으로 브랜드에 부합하는 UI 코드를 생성하는 AI의 능력을 향상시킵니다.

도구들에 대한 언급: Tempo 같은 Figma-to-code 도구들이 있지만 아직 테스트해보지는 않았습니다. 지금까지는 디자인 스크린샷과 디자인 명세 문서를 복사해서 붙여넣기 해봤는데, 적당한 성공을 거두었습니다.

백엔드 엔지니어링(Backend Engineering)

백엔드 엔지니어링은 두 가지 핵심 영역으로 이루어집니다:

비즈니스 로직의 구현과 최적화 (Implementation and optimization of business logic): 이는 애플리케이션의 핵심 기능과 업무 규칙을 코드로 구현하고, 성능을 개선하는 작업입니다. 예를 들어 사용자 인증, 데이터 처리, 결제 시스템 등의 핵심 기능을 만들고 더 빠르고 효율적으로 동작하도록 개선하는 일입니다.
데이터베이스 설계 (Database design): 애플리케이션이 사용할 데이터를 어떻게 저장하고 구조화할지 결정하는 작업입니다. 테이블 구조, 데이터 간의 관계, 인덱스 등을 설계하는 것을 포함합니다.

AI 도구가 뛰어난 백엔드 작업들

AI 도구들은 다음 세 가지 백엔드 작업에서 매우 우수한 성능을 보입니다:

비즈니스 로직 & 핵심 기능 구현: 복잡한 업무 규칙을 자동으로 코드로 변환
데이터베이스 설계: 효율적인 데이터 구조와 관계를 제안
API 구축: 서버와 클라이언트 간의 통신 인터페이스를 자동 생성

AI 활용의 필수 조건: D&D 원칙

하지만 이런 작업들이 AI의 도움을 받으려면 반드시 D&D(Definable and Deterministic) 조건을 만족해야 합니다:

Definable (정의 가능한): 작업의 목표와 요구사항이 명확하게 정의되어야 함
Deterministic (결정론적인): 예측 가능하고 일관된 결과를 낼 수 있는 작업이어야 함

즉, 작업 범위가 애매하거나 결과를 예측하기 어려운 작업에서는 AI 도구의 효과가 떨어집니다. 명확하고 구체적으로 정의된 작업에서 AI가 최고의 성능을 발휘합니다.

실무에서 증명된 두 가지 핵심 기법

1. 문서 가져오기 (Import documentation)

AI 통합 개발환경(AI IDEs)에서는 관련 문서를 작업공간(workspace)으로 직접 가져올 수 있습니다.

핵심 이점: 이렇게 하면 환각(hallucinations) 현상을 크게 줄일 수 있습니다. 환각이란 AI가 존재하지 않는 함수나 잘못된 정보를 만들어내는 현상입니다. 정확한 공식 문서가 작업공간에 있으면 AI가 이를 참조해서 정확한 코드를 생성하게 됩니다.

2. 워크스페이스 활용 (Use workspaces)

모든 VS Code 계열 도구들에서는 File > Add Folder to workspaces 메뉴를 통해 여러 폴더를 하나의 작업공간에 추가할 수 있습니다.

핵심 이점:

더 많은 맥락 정보 제공: AI가 프로젝트 전체의 구조와 관계를 이해할 수 있음
프론트엔드-백엔드 분리 프로젝트에 특히 중요: 양쪽 코드를 모두 참조해서 일관성 있는 코드 생성 가능
전체적인 코드 품질 향상: 프로젝트의 전반적인 패턴과 스타일을 이해한 코드 작성

이 두 가지 방법을 제대로 활용하면 AI 도구의 효율성을 크게 향상시킬 수 있습니다.

프로덕트 엔지니어를 위한 일반 팁

항상 최전선에서 일하세요

사용 가능한 최신 모델을 최신 상태로 유지하세요:

컨텍스트 창 크기가 증가하여 모델이 더 큰 프로젝트를 '이해'할 수 있습니다.
최신 모델의 성능 향상: 최신 모델은 더 잘 추론하고, 환각이 적으며, 일반적으로 더 안정적입니다.

사고 모드 사용

사고 모드를 켜면 모델의 답변 품질이 크게 향상되는 것을 발견했습니다. 사고 모드를 켜는 옵션이 제공되면 항상 사고 모드를 켜두세요. 그렇지 않은 경우에는 프롬프트의 어딘가에 "울트라씽크"라는 단어를 포함하는 것도 한 가지 방법입니다.

매우 구체적이어야 합니다.

달성하려는 정확한 목표를 제시하고, 중요한 제약 조건이나 디자인 결정을 포함하며, 관련 코드 조각, 파일 경로 및 컴포넌트 이름을 제공하세요. 이것은 좋은 프롬프트입니다:

/src/pages/SignUp.tsx 양식에 분석 추적을 추가하여 사용자가 '제출'을 클릭하면 /src/lib/analytics.ts의 trackEvent() 함수를 사용하여 sign_up_started 이벤트가 발생하도록 하세요. 이벤트를 디바운스하고 사용자의 이메일 도메인(예: 'gmail.com')을 속성으로 포함해야 합니다.

시각적 컨텍스트 제공

특히 프론트엔드 작업을 할 때 유용합니다. 현재 코딩 LLM은 이미지를 이해하므로 디자인 스크린샷과 버그로 인한 오류 메시지를 첨부하면 모델 디버깅 및 수정에 도움이 됩니다.

소규모 반복 작업

인공지능이 기본 기능을 개발하도록 한 다음, 개선 작업을 통해 기능을 다듬어 나가세요. (다시 말하지만!) 프롬프트를 명확하고 정의 가능한 여러 개의 지침으로 나누세요.

궁금증 유지

인터넷에는 이와 같은 팁이 수없이 많으며, 인터넷의 오른쪽 구석을 잘 살펴보면 가장 똑똑한 사람들이 활용하는 팁에 계속 노출될 수 있습니다.

Closing thoughts

AI가 소프트웨어 개발을 혁신하고 있지만, 여전히 대체되지 않을 스킬들이 있으며, 오히려 AI 혁명으로 인해 더욱 중요해지는 스킬들이 있습니다.

1. CLI 도구들에 대한 숙련도 (특히 Git)

Git CLI 숙련도가 더욱 중요해지는 이유: CLI 도구들은 터미널에서 직접 조작하는 프로그램들로, 그래픽 인터페이스 대신 명령어로 작업하며, 스크립팅과 CI/CD 파이프라인에 통합이 가능하고 원격 환경에서도 실행 할 수 있습니다.

Git이 "가장 효율적인 코드 버전 관리 방법"인 이유: Git은 모든 작업 버전의 종이 흔적(paper trail)을 유지하는 가장 효율적인 방법입니다. 이는 AI가 생성한 출력물이 신뢰할 수 없기 때문에 특히 중요합니다. AI 코딩 도구를 사용할 때 코드가 예상과 다르게 작동하거나 버그가 발생할 경우, Git을 통해 이전 버전으로 되돌아가고 다시 정리할 수 있는 옵션이 필수적입니다.

2025년 현재 개발자들의 일상적인 개발 작업 대부분이 여전히 터미널을 통해 이루어지며, 테스트 실행, 로그 확인, PR 차이점 검토, 스테이징 배포, 데이터베이스 스냅샷 다운로드, 무효 프로세스 종료 등의 작업에서 CLI가 가장 빠르고 신뢰할 수 있는 방법입니다.

2. 엔지니어링 기초 원칙의 중요성

기술 부채(Technical Debt) 관리의 새로운 중요성: 최신 연구에 따르면 AI 도구 사용이 25% 증가하면 배포 안정성이 7.2% 감소하며, 개발자들이 AI 생성 코드를 디버깅하고 보안 취약점을 해결하는 데 더 많은 시간을 소비하고 있습니다.

AI가 코드 모듈화/구조화에서 보이는 한계: AI는 항상 코드를 구획화하거나 모듈화하는 방법이 명확하지 않습니다. AI 생성 코드는 "Don't Repeat Yourself(DRY)" 원칙을 위반하는 경우가 많으며, 코드 중복을 증가시키고 장기적인 유지보수 부담을 가중시키고 있습니다.

좋은 스타일 기초의 가치 증대:

명명 규칙(Naming things well): 변수, 함수, 클래스에 의미 있는 이름을 부여하는 것
DRY 모듈러 코드 작성: 중복을 피하고 재사용 가능한 모듈을 만드는 것

AI 도구들은 고품질의 낮은 기술부채 코드베이스에서 최고의 성능을 발휘하는 반면, 복잡하고 레거시한 코드베이스에서는 효과적인 응답을 생성하기 어려워합니다.

미래에 대한 불확실성: 하지만 더 많은 코드가 AI에 의해 작성됨에 따라 이것이 미래에 어떻게 지속될지는 확실하지 않습니다. AI가 더욱 발전하면서 이런 기초 원칙들의 중요성이 어떻게 변할지 예측하기 어렵습니다.

3. 강력한 커뮤니케이션 능력 (글쓰기와 말하기)

명확성이 레버리지인 이유: 명확성은 결과를 극대화하는 지렝대 역할을 합니다. AI 시대에서 명확하고 철저한 문서화는 개발자가 마스터할 수 있는 가장 가치 있고 간과되기 쉬운 스킬 중 하나가 되었으며, 좋은 문서는 팀원, 새로운 기여자, 이해관계자, 그리고 AI 코딩 에이전트까지 모두를 정렬시킵니다.

AI 모델의 추론 방식과 인간의 차이: 가장 중요한 점은 AI 모델이 인간처럼 의도를 추론하지 않는다는 것입니다. AI와의 상호작용에서 프롬프트의 품질이 AI 출력의 유용성, 안전성, 신뢰성에 직접적인 영향을 미치며, 2025년 프롬프트 엔지니어링은 더 이상 단순히 질문하는 것이 아니라 모델을 정확하고 관련성 있으며 실행 가능한 결과로 이끌어내는 질문 유형을 설계하는 것입니다.

AI는 당신의 지시사항을 정확히 따르되, 당신의 맹점까지도 그대로 따릅니다. 따라서 원하는 것을 얼마나 명확하게 표현할 수 있느냐에 따라 AI 어시스턴트와 팀이 전달할 수 있는 결과의 품질이 결정됩니다.

효과적인 커뮤니케이션의 구체적 영역들:

좋은 사양서 작성: 프로젝트 요구사항과 기능을 명확히 정의
명확한 프롬프트 지시사항: Few-shot prompting과 같은 기법을 활용하여 정확도를 0%에서 90%까지 향상 시킬 수 있음
잘 구조화된 문서화: 향후 개발과 유지보수를 위한 기반

최종 결과: 이 모든 것이 합쳐져서 더 빠르고, 높은 품질의 결과물을 만들어내며, 재작업을 줄일 수 있습니다. AI는 코딩 속도를 높여주지만, 코드가 왜 작동하는지 알고 인간-루프 스킬을 날카롭게 하는 것이야말로 훌륭한 개발자가 되는 길입니다.

기술 업무가 AI에 잠식되는 이유:

기술적 업무는 앞서 언급한 D&D(Definable and Deterministic) 특성 때문에 AI에 점진적으로 흡수되기 매우 적합합니다. 실제로 Amazon에서는 AI 지원 구조로의 전환의 일환으로 중간 관리층을 제거하고 있으며, 다른 AI 우선 헬스케어 회사에서는 10명의 소프트웨어 엔지니어 팀이 AI 에이전트를 감독하는 3명의 유닛으로 교체되었습니다.

AI 관리자의 가치 상승: 더 많은 기술 업무가 AI에 아웃소싱됨에 따라, AI를 관리하여 더 빠르게 작업하고, 더 생산적이며, 주주들에게 세련된 결과를 제시할 수 있는 사람의 가치가 증가합니다.

대기업의 '보이지 않는 생산 과정': 대규모 조직에서는 생산 과정이 주주와 고위 경영진에게 종종 보이지 않습니다. 그들은 업무가 어떻게 수행되었는지가 아니라 무엇이 전달되었는지만 봅니다. Harvard Business School의 새로운 연구에 따르면 생성형 AI를 사용하면 기업 계층 구조를 평면화하고 관리자들을 프로젝트 조정의 일부 업무에서 해방시켜 생산성을 간소화할 수 있습니다.

실행의 상품화와 프레젠테이션의 중요성: AI가 실행을 더 저렴하고 상품화시킴에 따라, 프레젠테이션, 포장, 그리고 전략적 전달의 인지된 가치가 상승합니다. AI 출력물을 비즈니스 목표와 일치시키고, 명확하게 소통하며, 가시적인 성과를 이끌어낼 수 있는 사람들이 점점 더 권력을 갖게 될 것이며, 반드시 원시 기술 구현을 하는 사람들이 아닙니다.

권력 균형의 변화: 이런 상황이 이미 어느 정도 존재한다는 것을 이해하지만, 저울이 관리자 쪽으로 더 기울 것입니다. AI가 다양한 업무를 자동화함에 따라 C-suite도 변화하고 있으며, 새로운 AI 리더십 역할이 등장하고 오래된 권력 역학이 변화하고 있습니다.

PE(Product Engineer) 역할이 가져올 조직 구조 변화

신흥 기업과 스타트업에서의 변화: PE 역할의 도입은 앞으로 조직 구조의 변화를 불러올 것입니다. 이는 신흥 기업과 스타트업에 더 많이 적용되겠지만, 이러한 스타트업들이 확장되고 AI가 더욱 자율적이 되면서, 우리는 새로운 팀 토폴로지가 등장하기 시작할 수도 있습니다.

전통적인 팀 구조의 변화: 전통적인 PM-디자이너-엔지니어 삼각형 대신, 제품 감각을 가진 풀스택 빌더로서 행동하는 프로덕트 엔지니어가 이끄는 더 린한 포드들을 볼 수 있을 것이며, 스택 전반에 걸쳐 그들을 보강하는 AI 코파일럿과 짝을 이룰 수 있습니다.

AI Product Engineer의 등장: AI가 역할 간의 장벽을 허물어 개인이 한때 크로스 펑셔널 팀이 필요했던 일을 할 수 있게 하면서, 전략부터 실행까지 제품 라이프사이클을 완전히 소유하는 AI Product Engineer가 등장하고 있습니다.

새로운 팀 구성의 특징:

더 작은 팀 크기: 팀은 이전보다 더 작아지는 경향이 있으며, 일부 경우에는 뛰어난 사람들이 하나 이상의 역할을 수행할 수 있을 것입니다
역할의 중첩: 전통적인 사일로화된 엔지니어링 접근법이 더 유동적인 크로스 펑셔널 팀으로 변화하고 있으며, 일부 기술 부서에서는 애플리케이션을 처음부터 끝까지 구축하는 풀스택 엔지니어의 부상을 목격하고 있습니다
자율적 AI와의 협업: 최고의 엔지니어링 팀들은 AI와 함께 코드를 작성하는 것이 아니라, 매 주기마다 학습하고 적응하며 더 빠르게 배포하는 시스템을 구축하고 있습니다

미래 조직의 모습: AI 워크포스는 인간 직원과 자율적인 AI 에이전트가 함께 일하는 구조이며, 이는 사람을 대체하는 것이 아니라 인간의 지능과 기계 지능의 최고를 결합한 더 강력하고 유연한 하이브리드 팀을 만드는 것입니다.

이러한 변화는 이미 진행 중이며, Fortune 500 기업들에서 중간 관리층이 타격을 받고, 입문 레벨 업무가 사라지며, 전통적인 팀 역할이 흐려지기 시작하고 있습니다. 향후 블로그 포스트에서 이에 대해 더 자세히 다룰 예정이라고 하니, 이 변화의 구체적인 양상을 더 깊이 있게 살펴볼 수 있을 것 같습니다.