AI 시대, 개발자에게 남은 것
개발자의 진화: 코드를 넘어 비즈니스를 설계하라
실리콘밸리의 에어비앤비(Airbnb)나 스트라이프(Stripe) 같은 빅테크들의 채용 공고를 보면 심심찮게 등장하는 직무가 있다. 바로 ‘프로덕트 엔지니어(Product Engineer)’다.
이들은 기획자가 넘겨준 명세서대로 기능을 구현하는 수동적인 개발자가 아니다.
비즈니스 문제를 정의하고, 기술적 해법을 설계하며, 배포까지의 전 과정을 주도하는 ‘올라운더’다.
국내 기업들의 숨은 요구사항
흥미로운 점은 국내 테크 기업들의 움직임이다. 무신사, 토스, 당근 같은 선도적인 IT 기업들의 채용 공고를 살펴보면, ‘프로덕트 엔지니어’라는 직함이 명시적으로 드러나지 않는 경우가 많다. 하지만 그 속내를 들여다보면 사정은 다르다.
무신사의 경우, 개발 직군 채용 시 우대사항이나 핵심 가치(Core Value)에 “비즈니스 임팩트를 고려한 개발”,
“주도적인 문제 해결”을 강조한다. 직함은 여전히 ‘백엔드 엔지니어’, ‘프론트엔드 엔지니어’일지라도, 기업이 요구하는 실질적인 역량은 이미 프로덕트 엔지니어의 그것을 가리키고 있다. 즉, 직함은 없지만 역할은 이미 필수불가결한 시대가 된 것이다.
왜 기업들은 ‘기획하는 개발자’를 원하는가?
전통적인 워터폴(Waterfall) 방식이나 역할이 엄격히 분리된 조직에서는 기획자가 ‘무엇(What)’을 정의하면, 개발자가 ‘어떻게(How)’를 고민한다. 이 과정에서 필연적으로 ‘번역’의 누수가 발생한다.
기획 의도가 코드에 온전히 반영되지 않거나, 기술적 제약으로 인해 뒤늦게 기획이 엎어지는 비효율이 반복된다.
하지만 개발자가 유저 시나리오 정의부터 요구사항 명세, 시퀀스 다이어그램 작성, 도메인 객체 및 ERD 설계까지 전체 사이클을 주도하면 이야기가 달라진다. 그렇다면 개발자는 어떻게 기획에 접근해야 하는가?
텍스트로 된 요구사항을 코드로 번역하는 것을 넘어, “실현 가능한 설계도”를 그리기 위한 구체적인 방법론을 살펴보자.
개발자가 기획하는 방법: 4가지 핵심 접근법
1. 유저 시나리오: ‘스토리’가 아니라 ‘상태 기계’로 바라보기
기획자가 쓰는 유저 시나리오는 “사용자가 결제를 한다”와 같은 ‘행동’ 중심이다. 하지만 개발자가 작성하는 시나리오는 시스템 내부의 ‘데이터 상태 변화’가 중심이 되어야 한다.
개발자가 시나리오를 작성할 때 가장 먼저 고려해야 할 것은 성공 케이스가 아니라 실패/예외 케이스다.
기획적 접근:
사용자가 [구매] 버튼을 누르면 → 결제가 완료되고 → 주문 내역 페이지로 이동한다.
개발자적 접근 (State Machine 관점):
- 사용자가 [구매] 요청 → 주문 상태 PENDING 생성
- 재고 확인 (동시성 이슈 고려: Lock 필요 여부 판단)
- PG사 API 호출 → 타임아웃 발생 시 재시도 전략(Retry Policy) 수립
- 결제 성공 수신 → 주문 상태 PAID로 변경 (멱등성 보장 필수)
- 실패 시 → 주문 상태 FAILED 변경 및 사용자에게 알림
즉, 개발자의 시나리오는 “모호한 비즈니스 요구사항을 명확한 트랜잭션 단위로 쪼개는 과정”이어야 한다.
이 과정에서 ‘결제 중 이탈하면 재고는 어떻게 원복할 것인가?’와 같은 치명적인 결함을 기획 단계에서 잡아낼 수 있다.
2. 요구사항 명세서: 기능이 아닌 ‘계약’과 ‘제약’의 정의
개발자가 쓰는 요구사항 명세서는 추상적인 희망 사항이 아니라, 시스템이 보장해야 할 SLA(Service Level Agreement) 수준의 기술적 계약이어야 한다.
기능적 요구사항 (Functional):
- ❌ “빠른 검색이 되어야 한다”
- ✅ “100만 건의 데이터 내에서 검색 결과는 200ms 이내에 반환되어야 하며, 이를 위해 Elasticsearch를 도입한다”
비기능적 요구사항 (Non-Functional): 사실상 개발자만이 정의할 수 있는 핵심 영역이다.
- 확장성(Scalability): 트래픽이 10배 증가했을 때 DB 구조가 버틸 수 있는가? (샤딩, 파티셔닝 고려)
- 일관성(Consistency): 데이터가 실시간으로 일치해야 하는가(Strong Consistency), 아니면 약간의 지연은 허용하는가(Eventual Consistency)? 이 결정이 전체 아키텍처(Redis 캐싱 전략 등)를 좌우한다.
3. 시퀀스 다이어그램 & ERD: 코드의 청사진이자 비즈니스의 거울
글로 적힌 기획서는 오해의 소지가 있지만, 다이어그램은 거짓말을 하지 않는다. 개발자가 그리는 다이어그램은 단순한 그림이 아니라 ‘논리적 검증 도구’다.
시퀀스 다이어그램 (Sequence Diagram):
객체 간의 협력과 책임을 시각화한다.
여기서 개발자는 ‘API의 Ping-Pong 횟수’를 줄이는 고민을 해야 한다. 프론트엔드와 백엔드 사이의 통신이 너무 빈번하지 않은지, 하나의 트랜잭션에 너무 많은 외부 의존성이 걸려 있지 않은지 시각적으로 확인하며 리팩토링 포인트를 사전에 찾아낸다.
ERD (Entity Relationship Diagram): 데이터 모델링은 곧 비즈니스 모델링이다. 1:N인지 N:M인지 관계를 정의하는 것은 단순한 DB 설계를 넘어 비즈니스의 확장성을 결정짓는다.
고민 포인트: “지금은 상품과 카테고리가 1:1이지만, 향후 하나의 상품이 여러 카테고리에 속할 가능성은 없는가?”
→ 이 질문 하나가 미래의 대규모 스키마 변경 비용을 0으로 만든다.
4. 기획과 설계의 동기화
개발자가 작성한 요구사항 명세는 단순한 텍스트가 아니다.
그것은 도메인 객체의 메서드로 직결되고, 시퀀스 다이어그램을 거쳐 테이블 구조(ERD)로 즉각 치환된다. 기획과 설계의 불일치가 사라지고, 비즈니스 로직이 코드 레벨까지 매끄럽게 연결되는 ‘동기화(Synchronization)’가 일어나는 것이다.
이를 통해 ‘실현 가능성(Feasibility)’을 담보한 기획이 가능하다. 개발자가 유저 시나리오를 작성할 때는 화려한 기능보다 데이터의 흐름을 먼저 본다. “사용자가 결제 버튼을 누른다”는 문장을 적는 순간, 개발자의 머릿속에는 트랜잭션의 범위와 테이블 간의 잠금(Lock) 이슈가 그려진다. 기획 단계에서 이미 기술적 비용을 계산하고 리스크를 차단하기 때문에, “개발해 보니 안 됩니다”라는 소모적인 피드백 루프를 획기적으로 줄일 수 있다.
AI 시대, ‘구현’을 넘어 ‘설계’로의 도약
혹자는 묻는다. “개발하기도 바쁜데 기획까지 해야 하나?”
그러나 시대는 이미 변했다. Claude나 ChatGPT 같은 AI 도구의 등장은 코딩, 즉 ‘구현’의 장벽을 허물었다. 문법을 외우고 라이브러리 사용법을 익히는 것만으로는 더 이상 개발자의 경쟁력이 될 수 없다.
AI가 3년 차 개발자 수준의 코드를 순식간에 제안하는 세상이다.
이제 개발자의 가치는 ‘주어진 문제를 얼마나 빨리 코딩하느냐’가 아니라, ‘해결해야 할 문제가 무엇인지 정의하고, 전체적인 구조를 어떻게 설계하느냐’에서 판가름 난다.
AI는 코드를 짜줄 수는 있어도, 비즈니스의 맥락을 읽고 우리 서비스에 맞는 최적의 도메인 모델을 결정해주지는 못한다. “이 데이터 구조가 우리 서비스의 3년 뒤 미래를 감당할 수 있는지” 판단하는 것은 여전히 인간의 영역이다.
개발자가 기획 문서와 설계도를 직접 작성한다는 것은, AI라는 강력한 엔진을 탑재할 차체(Body)를 만드는 행위다.
탄탄한 설계(기획)가 뒷받침되지 않은 AI 생성 코드는 모래성일 뿐이다. 결국 유저 시나리오를 깊이 있게 이해하고, 이를 안정적인 시스템 구조로 변환하는 ‘설계 역량’이야말로 AI가 대체할 수 없는 인간 개발자의 고유 영역이다.
결론: 대체 불가능한 엔지니어로의 진화
국내 채용 시장에서 ‘프로덕트 엔지니어’라는 타이틀이 있건 없건 중요하지 않다. 중요한 것은 우리가 ‘코드를 작성하는 사람’이라는 좁은 정의에 갇히지 않는 것이다.
무신사의 채용 공고에 ‘프로덕트 엔지니어’라는 단어가 없다고 실망할 필요는 없다. 오히려 그들이 찾는 ‘문제 해결 능력이 뛰어난 엔지니어’가 바로 기획과 설계를 주도하는 사람이다.
우리가 가진 도메인 지식과 기술적 사고력은 프로젝트를 안전하고 빠르게 목적지까지 안내하는 내비게이션과 같다. 개발자가 도메인 지식을 무기로 기획에 참여할 때, 프로젝트는 비로소 ‘기술적 실현 가능성’과 ‘비즈니스 가치’라는 두 마리 토끼를 잡을 수 있다.
유저의 요구사항을 기술 언어로 해석하고, 비즈니스 가치를 시스템 구조에 녹여내는 것. 유저 시나리오를 트랜잭션 단위로 분해하고, 요구사항을 기술적 제약 조건으로 구체화하며, 다이어그램으로 논리를 검증하는 것. 그리하여 기획과 개발의 경계를 허물고 프로젝트 전체를 조망하는 것.
이것이 AI 시대에 우리 개발자들이 단순 코더(Coder)로 도태되지 않고, 시스템 전체를 조망하는 아키텍트(Architect)이자 대체 불가능한 프로덕트 엔지니어로 진화하는 유일한 길이다. 개발만 잘하는 시대는 저물었다. 이제 우리는 비즈니스를 설계해야 한다.