AI Agent와 객체지향적으로 협업하기

본 글은 AI의 코드 리뷰가 필요하다 라는 관점에서 작성된 글입니다.
최근에 AI 코드를 리뷰하지 않고 커밋하는 경우도 많다는 걸 알고 있으며,
이러한 개발방식을 선호하시는 분들은 글이 유의미하지 않을 수 있습니다.

 

본 글은 제가 기본적으로 알고 있는 지식과 적용하던 절차를 바탕으로 작성된 글입니다.
이 과정이 만약 비효율적이거나 더 좋은 방법이 있다면, 언제든 수정될 수 있습니다.
최신 수정일자: 2026/03/15

 

요새는 구현 부분을 AI가 많이 대체하고 있다.

 

과거에는 기존에 TDD/구현을 직접 해보면서 요구사항 분석에 깊이가 깊어지던 시간이 있었다.

이 과정은 코드 산출물을 직접 만들면서 요구사항을 이해했기 때문에, 코드 작성 시간 시점에서 효율적이었다.

 

하지만, 이젠 코드 자체의 작성 시간이 AI로 인해 훨씬 단축되었고, 따라서 자연어로 요구사항을 이해하는 것이 훨씬 효율적으로 바뀌었다.

따라서 요구사항 분석 단계에서의 사전 요구사항 이해 능력이 중요해졌다는 걸 느끼고 있다.

SDD와 같은 패러다임의 등장도 이와 같은 맥락이라고 생각한다.
하지만, 개인적으로는 자동 스펙 생성의 경우, 보일러플레이트 스펙을 만들기에는 충분하지만, 실제 요구사항에 기민한 스펙을 만들 때는 부족함을 느끼고 있다.
최소 비용/리소스로 해당 요구사항을 만족시킨다거나, 정해진 요구사항에서 나오는 외부 제약조건(ex: 전자정부표준프레임워크)으로 인한 요구사항 생성 시에는 한계를 느낀다.

 

최근 결제 모듈을 구현하면서, 핀잇을 개발하던 때보다 훨씬 데이터 일관성을 맞추기 어려운 문제를 겪었다.

핀잇 개발 시점에는 전통적인 개발 프로세스를 사용했다.

물론 결제 모듈이 훨씬 난이도가 높기 때문에 발생한 문제일 수 있다.

하지만 분명 AI를 좀 더 적극 도입하면서 개발 효율성과 데이터 일관성 유지 및 버그 수정이 더 쉬워져야 할텐데, 왜 더 느려졌을까 라는 고민에서 시작한 글로, 전통적 방식과 최신 방식을 섞어 쓰기 위한 고민의 글이다.

요구사항 분석 과정의 경우, 정확히 이대로 구현되지 않더라도(중도에 설계/유스케이스가 바뀌더라도) 이 과정에서 최소한의 요구사항 이해를 진행해야, AI와 코드를 이해하는 과정 대부분을 빠르게 만들 수 있다.

 

또한 결국 코드는 절차적으로 흐르기 때문에, 객체지향으로 만들기 전에 절차적으로 만드는 과정 1회가 반드시 필요하다.

---

전통적인 개발 프로세스에서의 변화

전통적인 개발 프로세스 - OOP(객체 지향 패러다임)

[객체지향 패러다임] OOD와 GRASP 패턴, 웹 개발에서의 객체지향 적용

전통적인 개발 프로세스로는 OOP(객체지향 패러다임)이 자주 쓰였다.

 

위 글에서 등장하는 프로세스를 간략화하면, 다음과 같다.

• OOA
  • 객체 지향 분석
• OOD
  • 객체 지향 설계
• OOP
  • 객체 지향 프로그래밍

AI가 발전하면서 생긴 변화

AI가 발전함으로 인해, 더이상 위 작업들을 혼자서 해야 할 이유가 사라졌다.

 

따라서 도움 받을 수 있는 부분은 도움받고, 개발자가 진행해야 할 부분은 직접 진행해야 하도록 바뀌었다.

• OOA
  • 객체 지향 분석
    • 반드시 사람 중심
    • 이게 AI가 결정하게 되면 안됨. AI는 요구사항을 정확히 모름
      • 조직 내부의 암묵지
      • 정치적 제약(데이터 소유권)
      • 운영 현실
    • 사람: 주어진 기획안을 바탕으로, 주요 문서 작성
      • Use Case
      • 도메인 모델
      • 사전조건/사후조건
      • 핵심 상태 다이어그램 설계
    • AI: 주어진 UseCase 문서 정리
      • 용어집 초안 생성
      • 명시 및 동사 추출
      • 누락된 것 같은 항목 검토
        • 사람이 실제 중요한 요구사항인지 검증
• OOD
  • 객체 지향 설계
    • 사람/AI 협업
    • 현재 주어진 요구사항에 어울리는 클래스/인터페이스/디자인 패턴 설계
    • AI: 좋은 설계 리스트업
    • 사람: 설계 결정
      • 데이터 정합성
      • 성능 요구사항
      • 트랜잭션 경계 설정
      • 락/동시성 검토
• OOP
  • 객체 지향 프로그래밍
    • AI 비중을 가장 높게 가져감
    • 손코딩이 아닌, 디자인 대로 코딩이 잘 이루어졌는지 검증
    • 코드 리뷰 위주

AI한테 맡겨둔 구현의 문제점

• 장점
  • 빠르게 보일러플레이트 기반으로 요구사항을 이해할 수 있다.
• 단점
  • 함수 이름이 정확히 뭘 하는건지 이해하기 힘들다.
    • 기술 부채가 쌓이는 듯한 불안감이 생기게 된다.
      • 글의 주제와는 다르지만, 이동욱님의 글 초반에도 관련 언급이 있다.
      • 이 문제가 명확하게 데이터로 보이진 않지만, 나의 성향 상 어느정도 공감이 갔다.
  • 실제 주어진 요구사항과 다를 수 있는 문제가 있다.
  • 학습용 이상의 가치를 지니기가 힘들다.

결국 개발자가 구현을 마무리짓더라도, 코드 리뷰는 진행할 수 있다면 진행하는 것이 좋다 생각한다.

 

 

---

OOA(객체 지향 - 요구사항 분석) 순서

 

1순위 작업은 도메인의 핵심 요구사항을 이해하기 위한 도구이다.

만약 요구사항이 복잡한 상태 머신을 가져야 한다면, 상태 후보 도출 또한 진행한다.

 

2순위 작업은 가독성을 올려 인사이트를 얻기 쉽게 만들어주는 도구이다.

인사이트 도출은 AI 모델을 통해서도 어느정도 보완되는 영역이기 때문에, 2순위로 미뤄두었다.

Use Case 작성

• 주어진 기능에 대한 이해/우선순위 결정 가능
  • 핵심 기능이 뭔지
  • 서브 기능이 뭔지
• 기능을 "적당한 단위"의 작업 Use Case로 구성
  • 지나치게 작으면, 난독화된 문서가 됨
  • 지나치게 크면, 실제 도메인 모델로 매핑되기 어려움
  • 1개의 비즈니스 트랜잭션 단위 작업이 좋음
• 유스 케이스를 작성하면서, 반드시 필요한 외부 시스템이 뭔지 확인할 수 있게 된다.
  • 시스템 시퀀스 다이어그램
• 써보지 않은 외부 시스템이 있다면?
  • AI와 함께 학습

만약 필요하다면: 서브 도메인 분리

이렇게 요구사항을 분해하다 보면, 뭐가 잘 안되고, 유스 케이스로 정리하기엔 복잡하다는 느낌이 들 때가 있다.

• 주문이 완료되면, 주문 정보를 결제 감사 로그에 남긴다.
• 주문이 완료되면, 사용자의 회원 등급을 재계산한다.
• 주문이 완료되면, 배송이 시작된다.
• 주문이 완료되면, 장바구니에 존재하는 주문 완료된 상품을 제거한다.

하나의 "주문 완료" 상황에, 변경되어야 하는 정보가 지나치게 많아 보인다.
또한, "주문 완료"가 주문이 완료된 것이 중요한건지, 결제가 완료된 건지조차 모호해진다.

 

이 경우, 대부분 이 문제에 가깝다.

• 유비쿼터스 언어가 다르다.
• 즉, 하나의 정보/상태 변화에 대해서 다루고자 하는 관점이 각자 다른 상황에서, 하나의 유스 케이스에 담으려고 노력하니, Use Case가 길고 복잡해지는 것이다.

이런 문제의 경우, 이벤트 스토밍 기법 및 바운디드 컨텍스트의 분리가 필요한 시점이다.

현재 글이 이런 대규모 설계까지 다루는 글은 아니라, 관련 글로 대체한다.

Event Storming – The Complete Guide | Qlerify

굳이 이 글이 아니라도, 구글이나 AI에 이벤트 스토밍을 검색하면 잘 나온다.

 

이를 이용하면, 유스케이스를 위에서 언급한 비즈니스 트랜잭션 단위로 문서화가 가능하다.

 

도메인 모델 작성

• 실제 클래스를 어떻게 분류해야 할 지 결정 가능
• 절차 지향 프로그래밍에서 객체 지향 프로그래밍으로 전환
• 명사 추출법(유스 케이스의 명사를 클래스화)
• 동사 추출법(유스 케이스의 동사를 클래스 간의 연관관계화)

상태 후보 도출

• 복잡한 상태 머신을 가지는 특정 도메인에 존재하는 상태 후보 도출
• 예시
  • 주문 생성
  • 결제 요청
  • 결제 승인
  • 배송 시작
  • 주문 취소

사전조건/사후조건

나는 이 부분에 대해서 전통적인 사전조건/사후조건 개념에서 탈피하는 것을 주장한다.

• 사전조건
  • 사용자가 지켜야 하는 것
  • 외부 시스템이 지킬 것이라 가정하는 것
  • 일반적인 B2C 서비스에선, 거의 없다.
  • 그냥 사용자가 어떻게 악의적으로 접근할 수 있는지 나열하는 것이 더 유리하다.
  • 혹은 외부 시스템이 어떻게 예상하지 못한 응답을 낼 수 있는지 나열하는 것이 유리하다.
• 사후조건
  • 우리 서비스가 지켜야 하는 것
  • 어떠한 일관성을 보장해야 하는가?
  • 사전 조건에서 발생할 수 있는 문제를 어떻게 해결할 것인가?
• 명시적으로 주의해서 처리해야 하는 예외 케이스 찾기
  • 이전에 어떠한 입력이 들어올 수 있는가
  • 우리는 어떠한 기능들을 반드시 예외로 처리해야 하는가
  • 발생할 수 있는 문제들에는 어떤 것들이 있는가

---

이렇게 완성된 문서를 바탕으로, AI Agent와 OOD, OOP 등을 진행한다.

• 좋은 설계 토의
• 트랜잭션 경계 설정
• 성능 검토
• 락/동시성 검토
• 작성된 코드 리뷰
  • 문제점 리스트업 및 토의
  • 작성된 코드의 작성 근거 토의

이 부분부터는 AI와 적극 토의해도 충분히 좋은 결과물을 얻을 수 있었다.

---

결제 모듈이 구현 완료되면, 이 글 하단에 별도로 Use Case의 완성 결과와 코드를 링크하도록 하겠다.