AI Agent로 경험해보는 소프트웨어 개발 프로세스

Dahun Yoo·2025년 9월 25일

Lessons learned

목록 보기

18/18

개요

얼마전에 전체 소스코드의 90%를 AI agent로 작성한 iOS앱을 런칭하였습니다. 주로 Claude code를 사용하고, 코드리뷰에는 codex를 사용했는데요, 이 과정에서 현업에서의 프로세스와 매우 닮은 소프트웨어 개발 프로세스에 따른 개발 플로우를 경험할 수 있었습니다.

취업 준비생 또는 주니어분들 중에서는 전반적인 개발 프로세스를 경험하지 못하는 분들이 많은데, 이럴 때 AI agent를 이용하면 혼자서라도 개발프로세스를 충분히 경험해볼 수 있습니다.

이번 포스트에서는 AI agent를 통해 기획 -> 개발 -> 테스트 -> 배포 흐름을 갖는 프로세스를 경험하는 내용에 대해 서술해보고, 각 단계에서 AI Agent를 어떤 역할로 이용했는지를 기재해봅니다.

사용할 Agent

요새 여러 agent가 있지만, 이 포스트에서는 Claude code, Codex에 대해 주로 서술합니다. 어떤 agent를 사용해도 문제없습니다만, 적어도 github의 issue와 pull request 기능을 쉽게 사용가능한 agent면 좋습니다.

또한 충분한 개발을 위해서는 적어도 아래 요금제를 사용하시길 추천합니다.

claude code : 100달러 플랜 이상
codex : 200달러 플랜

저의 경우는 Claude code 100달러 플랜 / ChatGPT 20달러 (Plus) 모델을 이용했습니다. 어느 ai agent던 메인으로 개발하기 위해서는 최소 100달러 이상의 플랜을 사용해야 부족함 없이 개발가능할 것이라 생각합니다. 물론 저는 회사 퇴근 후에 짬짬히 개발했던 것으로, 풀타임 개발을 하시는 분이라면 100달러 모델으로는 모자랄 수도 있겠습니다.

핵심 1. 문서를 통한 Agent와의 협업

AI Agent는 아무런 배경지식이 없는 프리랜서와 같습니다. 따라서 내가 만들고자 하는 서비스를 이해시키기 위해서는 충분한 설명이 필요합니다. 단순히 채팅 몇 번으로는 원하는 수준의 서비스를 개발하고 유지할 수 없습니다.

특히 장기간 개발을 하려면 작업 맥락(context)을 문서로 남겨야 합니다. 세션이 초기화되거나 대화가 길어져 새로 시작할 때, 문서가 없다면 AI는 불완전한 정보만 가지고 개발을 이어갈 수밖에 없습니다. 이는 현업에서도 흔히 발생하는 문제입니다. 빠른 개발 속도를 강조하며 기획서 없이 대화나 사내 메신저를 통해 기획을 정해버리고 개발한다던지, 식사하면서 떠오른 아이디어를 그대로 개발해버린 후에 담당자가 퇴사를 해버리면, 남아 있는 사람이 기능의 히스토리를 파악하기 위해 문서를 뒤지다가 결국에는 사내 제일 재직기간이 긴 사람에게 찾아가서 기억을 더듬어가며 기능에 대한 상세한 내용을 알게 됩니다. 이러한 경우를 마주치게 된다면, 하찮은 기능이라도 문서가 남아있다면 매우 반가워할 것 입니다.

따라서 AI와 협업할 때는 모든 작업을 문서 기반으로 지시하고, 진행 결과도 문서로 갱신하는 습관이 필요합니다. 문서 기반으로 작업을 지시하다가도, 대화세션에서 발생한 수정사항이 생기는 경우가 있는데, 이 경우도 문서에 반영을 해서, 항상 최신 상태의 문서가 유지될 수 있도록 해야합니다.

이 글에서는 이러한 원칙을 바탕으로, 기획 → 디자인 → 개발 → 테스트 → 배포까지 소프트웨어 개발 프로세스를 어떻게 경험할 수 있는지 다루겠습니다.

핵심 2. 리뷰 단계

아래에서 설명드릴 모든 단계에서, AI를 어떻게 활용하던 리뷰를 해야한다는 것을 계속해서 강조할 것입니다. AI가 나의 작업물을 리뷰하던, 내가 AI의 작업물을 리뷰하던, 리뷰는 중요합니다. 특히 AI가 잘못된 방향으로 갈 수 있기 때문에 모든 단계의 산출물에서 리뷰를 진행해야합니다.

1. 기획 단계

AI를 이용해 소프트웨어를 개발할 때는, 단순히 “맛집 리스트를 보여주는 웹페이지를 만들어줘.” 라고도 할 수 있습니다. 그러나 본인이 정말 개발하고 싶은 서비스가 있다면, 이러한 단순 명령으로는 디테일 사항들에 대해서는 개발자의 의도대로 개발하지 못할 수 있습니다. 내가 가진 요구사항에 대해 구체화 시켜 요구사항 명세서 라는 하나의 구체적인 문서로 만들 필요가 있습니다.

문서의 형태는 여러가지가 있을 수 있으나 가능하면 markdown 포맷의 문서로 작성하는 것이 좋습니다.

역할 1 - 기획자 / 비즈니스 분석가

문서 작성 / 요구사항 구체화

우선 마크다운 문서로 서비스 초안을 정리해보세요. AI에게 이 문서를 검토하게 하고, 부족한 부분을 보완하도록 요청합니다. 이 과정을 반복하면서 점점 더 구체적인 명세서를 완성할 수 있습니다.

AI가 상세화 시킨 요구사항 명세서에 대해서, 고객 혹은 발주사의 입장에서 리뷰를 진행합니다. 요구사항 문서를 처음부터 천천히 읽어가면서 AI가 나의 요구사항을 제대로 이해했는지, 내가 원하는 방향대로 문서화를 했는지, 부족한 점은 없는지를 체크해야합니다. 요구사항 명세에 대해 리뷰하는 것을 보통 스펙리뷰라고들 하는데, 이 활동을 통해 요구사항 명세서를 좀 더 완벽하게 구체화시키고, 잘못된 서비스를 개발하는 것을 방지합니다. 이 리뷰도 문서 기반으로 작업합니다.

리뷰 문서는 요구사항 명세서의 어떠한 항목에 대한 피드백인지를 알 수 있도록 traceability를 고려한 문서포맷이 되어야합니다. 제일 좋은 것은 table을 이용해서 작성하는 것이 좋을 것입니다.

Requirement ID	내용
F-001 (날짜입력창)	날짜에 과거날짜를 입력하면 어떻게 동작해야하는지?

역할 2 - QA엔지니어를 비롯한 이해관계자

어떤 경우에는 본인이 직접 상세한 요구사항 명세서를 작성해볼 수도 있습니다. 이러한 경우에도 이 명세서가 정말 완벽하다는 보장을 할 수 없습니다. 이럴때도 리뷰를 통한 피드백을 받아야하는데, 이럴때도 AI를 이용할 수 있습니다.
작성한 명세서가 충분히 완성도가 있는지 AI에게 “리뷰”를 부탁하세요. QA 역할의 AI는 엣지 케이스나 놓친 기능을 지적할 수 있습니다. 이때도 리뷰 내용을 별도 문서로 남기고, 어떤 요구사항과 연결되는지 Traceability를 기록하면 나중에 관리가 쉬워집니다.

문서가 어느정도 상세화가 될 때까지 위에 서술한 방식을 반복합니다.

2. 디자인 단계

상세화된 요구사항 명세를 바탕으로 디자인을 진행해야합니다. 이 때 별도의 디자인 가이드가 준비되지 않았다면 적어도 서비스의 톤앤매너를 정리해놓는 것을 추천합니다. 전반적인 배경색이나 강조색, 글자색상 등을 정해놓는 것도 좋습니다.

- 배경색: #F5F5F5  
- 기본 버튼: 파란색(#0066FF), 흰색 글자  
- 강조 버튼: 빨간색(#FF3333), 흰색 글자

역할 1 - 디자이너

이미 ai에 대해 결제한 상태이기 때문에, ChatGPT나 Claude 를 통해서 요구사항을 전달하고 스케치 레벨의 디자인을 해달라고 하는 것도 하나의 방법입니다. 이 방법을 이용하면 추후 개발단계에서 디자인 파일이 존재하는 경로를 AI에게 전달하고, 해당 디자인을 참고해서 UI개발을 진행해달라고 의뢰해도 되고, 본인이 직접 참고해서 개발을 진행해도 됩니다.

Figma MCP를 이용하는 경우라면 더욱 편리한데,

아무런 디자인도 없는 상태
이 상태에서는 AI에게 요구사항 명세를 참고하여 figma에 import 가능한 형태로 디자인해달라고 할 수 있습니다. 이후에는 디자인 리뷰가 필요합니다. AI가 디자인을 얼마나 잘 했는지, 요구사항에 명시된 기능들의 특징을 디자인에 어느정도 녹여냈는지가 필요합니다. 이 경우라면 디자인 요소에 라벨링을 한 후에, 하나의 문서형태로 정리하여 한 번에 수정을 요청해야할 것 입니다. 혹은 본인이 직접 figma를 수정하여 색상이나 형태를 변경할 수도 있습니다.

디자인이 이미 존재하는 상태
미리 figma에 디자인을 만들어놓은 경우라면 라벨링을 통해 어떤 기능에서의 어떤 디자인/화면 인지를 명시적으로 작성하여 AI가 파악하기 쉽도록 합니다.

혹은 “선택 항목 링크 복사” 를 선택해서 MCP가 연결된 AI에게 전달합니다.

이후 MCP를 통해 디자인을 코드로 변환하여 UI 개발을 진행해볼 수 있습니다.

Ref.
Figma에 Cladue 연결해서 AI에게 디자인 생성해달라고 하기인데 이제 MCP를 곁들인…
Claude 사용해서 Figma로 디자인 해달라고 하면 얼마나 잘 해줄까?

디자인의 완성도를 끌어올리기 위해 위 작업을 반복합니다. 다만, 디자인 이라는 것이 인간 디자이너의 의도를 AI가 글로만으로 완벽하게 파악할 수는 없기 때문에, 적절한 선에서 중단하고 완성도를 높이려면 사람이 마지막 터치를 해주는 것이 좋을 것입니다

3. 개발 단계

개발 단계에서는 본인이 직접 요구사항 명세를 기반으로 개발을 해도 좋고, AI에게 개발을 시켜도 좋습니다. 물론 AI가 개발하는 것이 생산성 측면에서는 매우 좋으나, 본인의 개발 실력을 향상시키고자 한다던지 등의 경우에는 본인이 직접하는 것도 좋습니다.

개발 단계에서도 몇 가지 방법을 이용해 실제 현업에서의 소프트웨어 개발 프로세스와 유사한 프로세스를 경험해볼 수 있습니다.

중요한 것은 작업 단위를 잘게 나누고, 진행 과정을 문서로 관리하는 것입니다

역할 1 - 개발자

AI로 개발을 진행하는 경우에는, 개발을 시작하기에 앞서서 앞 단계에서 정제한 요구사항 명세서를 기반으로 Todo-list와 같은 작업순서도를 먼저 문서화한 다음, 해당 문서를 기반으로 작업을 진행하라고 지시하는 것이 좋습니다. 방대한 명세서를 한 번에 개발하기 보다는 한 번 Todo-list와 같은 형태로 정제하고, 작업에 우선순위를 설정한 후에 작업을 진행하는 것이 훨씬 매끄럽게 진행됩니다.

최근의 agent는 자체적으로 Todo-list를 작성해서 진행하나, 한 번에 많은 양을 개발하기에는 한계가 있기도 하고, 유저가 도중에 세션을 중단하고 시간이 한참 흐른 후에 작업을 다시 진행해야할 수도 있습니다.

따라서 Todo-list의 형태를 통해 작업 순서를 문서화하도록 지시하고, 해당 문서의 내용을 따라 작업을 진행하도록 명시하는 것이 좋습니다. 또한, 특정 항목의 작업이 완료될때마다 문서도 갱신해서 추후에라도 작업 현황을 follow-up이 가능하도록 하는 것이 좋습니다.

테스트 주도 개발?

Anthropic의 Claude code best practice에 따르면, TDD를 권장하고 있습니다.

This is an Anthropic-favorite workflow for changes that are easily verifiable with unit, integration, or end-to-end tests. Test-driven development (TDD) becomes even more powerful with agentic coding:

https://www.anthropic.com/engineering/claude-code-best-practices

그러나 무엇을 테스트할지 정확한 범위가 정해져있지 않다면, 제대로된 TDD가 될 수 없을 것 입니다. 따라서 TDD를 진행하기 전에 반드시 요구사항이 상세화되어있는지 확인이 필요합니다.

Commit message

AI가 개발한 경우라면, commit message도 좀 더 상세히 기재해줍니다. 단순히 사람이 작업한 내용에 대해 커밋만 진행하는 경우보다, AI가 개발한 내용에 대해 context를 가지고 있는 상태에서 commit을 할 때 좀 더 많은 정보를 기재해줄 수 있습니다. 이것은 개발된 것에 대한 히스토리를 파악할 때에도 도움이 됩니다. 작업 후에 “작업 내용을 커밋해줘” 라고 하시면 됩니다.

이후 작업한 내용에 대해 Pull request를 생성하도록 합니다.

Code Review

AI가 작성한 작업 내용에 대해 리뷰를 진행합니다. 아무리 문서를 상세히 작성했다고 해도, AI는 잘못된 방향으로 흐를 가능성이 있습니다. 비즈니스 로직에 문제는 없는지, 불필요한 import가 발생하지는 않았는지, 동일한 로직이 여러군데에서 반복되지는 않는지, 간단한 로직에 대해 너무 Over engineering이 되지는 않았는지 체크해봅시다.
코드작성 작업을 할 때 반드시 변수나 메소드에 docString을 기재하는 것을 명시해서 코드 리뷰 시에 도움이 되도록 할 수도 있을 것 입니다.

역할 2 - 코드 리뷰어

사람이 직접 개발하던, AI가 개발하던 작성된 코드에 대해서는 코드리뷰를 하는 것이 바람직합니다.

코드 리뷰 시에는 로컬에서 리뷰를 해도 되지만, Github을 이용하여 Pull request를 통해 리뷰를 해볼 수도 있습니다. 어느쪽이던 상관없지만 PR을 이용한다면 별도의 다른 AI를 통해 리뷰하기도 쉽고, 사람이 직접 리뷰하게 된다면 현업과 비슷한 형태로 리뷰 프로세스를 경험해볼 수도 있습니다.

방법 1 - 사람이 직접 리뷰하기
AI가 작성한 코드에 대해 리뷰를 진행해야합니다. AI는 생각보다 실수를 많이하고, 환각으로 인하여 코드를 잘못된 방향으로 작성하기도 합니다. 따라서 사람이 직접 코드리뷰를 해주는 것이 좋습니다.

방법 2 - AI를 이용해 AI의 코드를 리뷰하기
로컬에서 AI에게 현재 수정되어있는 상태의 코드를 리뷰해달라고 할 수도 있습니다. PR을 이용한다면 또 다른 AI를 이용해서 코드리뷰를 진행해볼 수 있습니다.
기능 개발이 완료되었다면 PR을 생성하도록 합니다. commit부터 AI가 하도록 지시하면 매우 상세한 커밋메세지를 작성해줍니다.

작성한 코드에 대해서 로컬에서 agent를 이용해 리뷰를 진행해도 되고, PR을 생성해서 리뷰를 진행해도 됩니다. PR생성할 때도 AI를 이용하게 되면, 매우 자세한 내용으로 PR 내용을 작성해줍니다.
이렇게 생성된 PR에 대해서도 리뷰를 진행해야합니다. 사용자 본인이 직접 리뷰를 해도 되고, AI에게 코드리뷰를 진행하도록 할 수도 있습니다.

Claude code의 경우 API key가 별도로 필요한 반면, Codex의 경우에는 Plus 구독자도 가능합니다.

본인이 개발을 했던, AI가 개발을 했던, 피드백 사항이 발생하게 되면 이것을 다시 수정합니다. 문제 해결때까지 이 방법을 반복합니다.

4. 테스트

프로덕트가 어느정도 개발이 완료되었다면 테스트를 수행해야합니다. 간단한 프로덕트라면 unit testcode, intergration testcode를 실행하고 테스트를 종료할 수도 있겠지만, 대부분의 경우는 직접 사람이 손으로 조작하면서 디자인이나 사용성 등을 포함한 테스트를 수행해야합니다.

테스트 역시 사람이 할 수도 있고 AI가 수행할 수도 있습니다. 웹의 경우는 Playwright MCP가 잘 되어있어서 매우 손쉽게 테스트를 수행할 수 있습니다. 앱의 경우는 조금 어렵긴 하지만, adb mcp, xcodebuild mcp 등을 이용합니다. AI는 조작을 하고, 스크린샷이나 접근성 API를 이용해서 프로덕트의 상태를 확인하고, 다음 액션을 반복해나가면서 테스트를 수행합니다. 속도가 느리다면 사람이 직접 수행할 수도 있습니다.

역할 1 - QA엔지니어

요구사항이 잘 작성되어있다면, AI를 통해 테스트케이스를 작성할 수도 있습니다. 이 때 작성하는 테스트케이스도 누군가가 리뷰를 해야하는데요, 요구사항 명세항목과의 traceability가 확보되도록 테스트케이스 형태를 구성하던지, 요구사항 커버리지를 나타내는 별도의 문서가 존재한다면 파악하기가 쉬울 것 입니다.

예를 들어

# 기능 세부 사항

## F_001 날짜 입력창
- 날짜 입력창은 프로덕트를 실행했을 때의 날짜가 디폴트값으로 설정되어야한다.
- 과거 날짜는 입력할 수 없다.
- 윤달 입력이 가능해야한다.

TC_ID	대분류	중분류	테스트 요약	테스트 절차	기대 결과	실제 결과
TC_001	날짜 입력창	날짜 입력	과거 날짜 입력불가	1.과거의 날짜를 입력한다	입력할 수 없어야한다.
TC_002	날짜 입력창	날짜 입력	윤달 입력가능	1.윤년의 2월 29일을 입력 시도한다	입력할 수 있다

위와 같은 요구사항 명세서와 테스트케이스가 있다면, 어떠한 요구사항 항목으로부터 테스트케이스가 도출되었는지, 요구사항 커버리지 문서를 아래와 같이 표현할 수 있을 것입니다.

Requirement ID	TC ID
F_001	TC_001, TC_002

따라서 요구사항 커버리지를 나타내는 표 혹은 문서를 같이 생성해달라고 명시적으로 지시하는 것이 좋습니다. AI를 통해 작성한 테스트케이스는 중요 기능들과 엣지케이스들을 잘 커버하고 있는지를 사람이 리뷰해주어야합니다.

역할 2 - 테스트케이스 리뷰어

테스트케이스를 사람이 직접 작성할 수도 있습니다. 이 경우에는 테스트케이스에 부족한 부분은 없는지 AI에게 요구사항과 비교해가며 피드백을 해달라고 AI에게 지시할 수도 있습니다. 이 경우라면 AI가 알기 쉽도록 요구사항 커버리지를 나타내는 항목을 별도로 반드시 준비한 후에 테스트케이스를 리뷰해달라고 지시해야겠습니다.

다만 이 역할로 agent를 사용하게 된다면, 실제 사용성에 대한 확인이 어렵고, 현실적인 시나리오가 누락된채로 리뷰가 진행될 수 있습니다.

end to end 테스트케이스가 준비되었다면, 해당 케이스를 수행하면서 테스트를 수행합니다.

역할 3 - 테스트 수행자

테스트를 수행하면 버그가 발생하기 마련입니다.
이 때도 문서를 이용하면 좋은데, 사람이 직접 테스트를 수행하는 경우에는 이슈 리포트 수단에 대해서 현업과 비슷하게 Bug Tracking System을 이용해보았고, 저는 Github issue를 통해 이슈 리포트를 하였습니다.

issue탭에는 마치 현업에서 Bug Tracking System을 이용하는 것 처럼 상세히 기록합니다.

이슈 현상
이슈 재현 절차
기대 결과
스크린샷

AI는 이미지를 읽고 이해할 수 있기 때문에 문제가 발생한 것에 대해 스크린샷을 첨부하면 좀 더 정확한 수정이 가능합니다.

Github issue대신에 JIRA MCP 같은 것을 사용해도 상관없습니다. 다만 Claude code의 경우 Github CLIgh 의 사용방법을 기본적으로 알고 있어서 이점이 있을거라고 생각하였습니다.

이슈를 생성한 다음에는 해당 이슈에 대한 대응작업을 진행하고, PR을 생성하고, 코드리뷰를 진행하고 문제없다면 merge를 진행합니다.

업로드중..

이렇게 이슈 리포트를 하면 다시 개발단계로 돌아가 github 의 issue내용을 파악하고 수정 브랜치를 생성하고, 버그 수정을 진행할 수 있습니다. 테스트케이스를 진행하면서 발생하는 모든 이슈에 대해 위 작업을 반복합니다.

5. 배포 후 모니터링

위 프로세스를 진행하면 프로덕트는 어느샌가 배포할 타이밍이 옵니다. 배포 / 앱 출시 이후에는 모니터링을 하면서 이슈가 있다면 이슈를 리포트하고, 다음 기능을 위해서 다시 요구사항을 작성합니다.

마무리

위와 같이 제가 AI agent를 사용하면서 경험했던 작은 개발 프로세스에 대해 소개했습니다. 위의 형태는 현업에서 경험하고 있는 프로세스와 매우 흡사한 형태이며, AI Agent가 발전하였지만 아직은 일련의 프로세스를 준수하는 것이 개발산출물의 퀄리티를 훨씬 더 높여주고 개발하고자하는 프로덕트를 사용자가 원하는 방향으로 개발할 수 있다는 것을 알게되었습니다.

이것은 적어도 AI agent를 이용해 만들어낸 결과물을 “사람” 이 사용하는 한, 계속해서 가능한 방법이라고 생각합니다.

끝!

Dahun Yoo

QA Engineer

이전 포스트