1. 인트로
최근 들어간 회사에서 부서 배치 전 신입 사원 대상 9주간의 개발 교육을 듣게 됐다.
9주 중, 앞의 5주간(2.3~3.5)의 교육기간이 끝난 후, 배웠던 내용들 (데이터 모델링, 웹개발 기초(Java, Spring, Vue.js 등), SQL)을 기반으로 약 5일간의 개인 프로젝트를 하게 됐다.
회사의 서비스 중 1가지를 선택해서 클론코딩 및 개선을 직접 해보는 것이었고, 설계 부터 개발까지를 "5일 만에 혼자서" 직접 해야 했다. 이전까지 나는 제대로 개발 공부를 해본 적이 없었고, Java/Spring/Vue.js 등도 다 처음이었다.
그 과정에서 설계부터 개발까지 요즘 소위 유행하는 *바이브 코딩(Vibe Coding) 방식에 가깝게 개발을 진행했다. 요즘 다들 관심이 많은 분야이니만큼 그 경험을 한번 공유하고 싶어 글을 쓰게 됐다.
*바이브 코딩?:
바이브 코딩(Vibe Coding)**은 인공지능(AI)을 활용하여 자연어로 코드를 생성하는 새로운 프로그래밍 방식입니다. 개발자가 "로그인 기능을 만들어줘"와 같이 자연어로 요구사항을 설명하면, AI가 이에 맞는 코드를 생성합니다. 이러한 접근법은 프로그래밍에 대한 깊은 지식이 없는 사람도 소프트웨어를 개발할 수 있게 해 주며, 소규모 팀이 대규모 팀과 맞먹는 생산성을 발휘할 수 있도록 합니다. (출처: Chat GPT)
2. 기획 배경
개인 프로젝트는 기존에 페이히어에서 담당했었던 "테이블오더"를 만들기로 결정했다.
거기엔 크게 [1) 개인적 관점 2) 사업적 관점] 의 이유가 있었다.
1) 개인적 관점
기존에 테이블오더 PO로 10개월간 일하며 기획만을 했다면, 이번엔 내 손으로 "직접 " 개발을 해보고 싶었다.
- 당시 나는 테이블오더가 출시된 지 1달 차 이후부터 팀에 합류했었기에 기본적인 기능들은 이미 출시된 이후 팀에 합류했었다. 그에 따라 테이블오더의 기본 기능에 대한 기획/개발 등을 해보고 싶은 니즈를 가지고 있었다.
- 이전에 팀에서는 PRD(기획서) 작성과 같이, 기능에 대한 상위 기획 정도와 운영만을 담당했었다. 그렇기에 이번 기회를 통해 개발자들이 담당했던 문서 (API 명세서, ERD) 작성과 더불어서, "직접 개발"까지 해보며 개발자의 고충을 한번 이해해 보고 싶었다. (만들어달라고 부탁하기만 했다면, 직접 한번 뛰어보고 싶었달까...ㅎㅎ)
2) 사업적 관점
테이블오더의 기본 기능 외에도
기존에 시장에 없던 [LLM 을 활용한 외국어 "자동" 번역 기능]을 만들어 보고 싶었다.
해당 기능은1) 저조한 외국어 지원 사용률을 개선하고 2) 테이블오더의 차별화 포인트가 되지 않을까 생각했다.
AS - IS(Pain Point)
- 기존의 외국어 지원 기능의 경우, 대부분의 업체들이 가지고 있는 기능이지만 사용률이 저조
(평균연령 50대의 사장님이 메뉴 하나하나마다, 직접 번역기를 돌린 뒤 직접 대시보드 등에 일일이 하나씩 삽입해줘야 하기 때문. 그래서 외국어 지원 기능을 업체들은 제공함에도, 사용하지 않는 매장이 다수)
- KT 하이오더의 경우도 업계 최다 12개국 언어 지원을 내세우지만 비슷한 이유로 1) 사용 X 이거나, 2) 3개 국어 정도만 쓰는 경우가 많음
TO- BE(기대효과)
- 만약, 식당 사장님이 한국어로 메뉴를 "등록" 하는 시점에 LLM 이 자동으로 각 국가의 언어로 메뉴명, 메뉴 설명등을 번역해서 DB에 저장해 버린다면?
- 그럼 사장님은 별도의 노력 없이 외국어 지원을 사용하게 될 것이기에 "외국어 지원 기능의 사용률 개선"을 노릴 수 있을 것
- 추가로 적은 비용(매장 당 단돈 *50원) 투입만으로도 테이블오더 업체 입장에선 서비스 차별화, 마케팅 소구점 생성이 가능
(*매장당 평균 50개 메뉴/5개 카테고리 가정 시 LLM 활용 번역 기능에 사용되는 예상비용)
3. 구현 기능 요약
크게 1) KT 하이오더의 기본 기능과 2) LLM을 활용한 외국어 "자동" 번역 기능을 구현하려 했다.
홀로 5일 만에 개발해야 하는 것이기 때문에, 핵심 비즈니스로직을 구현하는데 집중했다.
4. 설계 & 개발 과정 (with AI)
1) 기획서&기능명세 1차 작성
기본적으로 기획서 까진 거의 내 힘으로 작성했다.
1. 유저 시나리오(플로우)를 작성
2. 시나리오 기반 기능 우선순위를 정리
3. 각 시나리오 별 상세 기능 명세 작성
1차적으로 이렇게 작성할 때 까진, 상세 기능명세를 그렇게 까지 디테일하게 적진 않았다.
어떤 식으로 flow가 흘러가야 한다에 대해서 러프하게만 적었다.
도메인 지식도 좀 있는 영역이고, 서비스 기획일을 어느 정도 해봤기 때문에 이런 문서작업 자체가 어렵진 않았던 거 같다.
2) ERD / 테이블 정의서 작성 (with GPT)
a. ERD/테이블 정의서 초안 만들기
만든 기획서/기능명세서를 Chat GPT에게 참고할 맥락으로 던져줬다.
이를 바탕으로 GPT에게 ERD 및 테이블 정의서를 만들고 싶다고 요청했고 초안을 받아봤다.
GPT는 해당 기획서/기능명세서를 바탕으로 DB상에 필요할 테이블과, 그 안의 컬럼(속성) 들까지도 제안을 해줬다.
b. 초안 바탕, DB 기획 디테일 논의 (/w GPT)
그 초안을 받아 본 나는, 테이블 하나하나 별로 디테일한 부분들을 GPT와 대화하면서 잡아갔다.
예를 들면, 아래와 같은 DB 기획 시 고민되는 부분들에 대해 GPT와 논의했다.
1. 반정규화 필요 여부
menu 테이블에 이미 기록되고 있는 menu_name 값을, order_items(주문 상세) 에도 하나의 컬럼(속성)으로 기록할 것인가? (주문 당시 시점의 메뉴명을 히스토리 남기기 위해)
2. 속성 데이터 타입 결정
- 메뉴 가격과 관련한 컬럼을 integer 타입 대신 numeric으로 해야 하는 이유는 뭔가?
- restaurant_name(식당명)을 100자 제한으로 한 이유는?
3. 속성명 결정
- menu 테이블에도 display_order 컬럼이 있는데, category 테이블에도 동일한 컬럼명 써도 되나?
이 과정에서 특히나 좋았던 부분은 세부적으로 고민하는 포인트 들에 대해 논리와 근거를 기반으로 의견을 제시해 주는 도우미(Assistant)가 있는 부분이었다. 개인 프로젝트에서 가장 어려운 점중 하나가, 고민되는 사항에 대해 의논하고 같이 고민해 줄 사람이 없는 것이다. 그런 점에서 GPT라는 같이 고민해 주고, 본인만의 근거/논리와 함께 논의를 끌어가 주는 존재가 있는 게 굉장히 좋았다. (때로는 시니어, 때로는 도우미 인턴을 가지고 있는 기분이었달까)
또한, ERD/테이블 정의서를 이전까지 내가 만들고 기획해 본 적이 1번도 없었기에, 이 부분을 처음부터 내가 했다면 엄청 리를 싸매고 진행했을 것이다. 하지만, GPT가 초안을 만들어주고 이에 대해 도메인 지식을 가지고 있는 내 입장에서 추가로 수정/보완이 필요할 부분을 제시하는 건 크게 어렵지 않았다. 초보 DB/데이터 지식을 가지고 있는 기획자인 나와 능숙한 DA(Data Architect) GPT가 있는 느낌이었다.
c. DDL 쿼리문 생성&더미데이터 만들기 (/w GPT)
그렇게 DB를 어떻게 설계할지 틀을 만든 후엔, 실제 GPT에게 같이 만든 ERD/테이블 정의서를 기반으로 DDL 쿼리문을 짜달라고 했다. (실제 db 내 테이블과 컬럼을 생성하는 쿼리문)
내가 한 건 생성한 쿼리문에서 혹시라도 빠진 컬럼이 있거나, 컬럼의 데이터 타입이 잘못지정된게 있는지, 컬럼명을 바꿔야 할 게 있는지 확인하는 정도...이마저도, 이전에 같이 작업한 ERD/테이블정의서에 대한 메모리가 GPT에 남아있기에 거의 내가 수정할 게 하나도 없었다.
그렇게 GPT에게 받은 DDL 쿼리문을 실행한 이후에는, 실제 개발/테스트 작업을 좀 더 원활하게 하기 위해 각 db 테이블과 컬럼에 더미데이터(테스트용 데이터 (ex. 식당 메뉴, 메뉴설명, 메뉴이미지 등)) 를 넣어주는 쿼리문 또한 GPT에 만들어달라고 했다.
원하는 더미데이터에 대한 양식에 대한 최소요건(ex. 식당은 몇 개 만들어야 하고, 식당 별 테이블 개수와, 메뉴 개수는 뭘로 할지, 식당 메뉴는 양식으로 만들어줘야 하는지 등) 정도만 프롬프트에 넣었다.
그를 바탕으로 GPT는 더미데이터를 삽입하는 Insert 쿼리문 또한 대신 만들어줬다. (나는 또다시 그걸 검토 후 postgresql에서 실행버튼만 눌렀다.)
3) API 명세서 작성 (/w GPT)
DB 설계 및 더미데이터까지 나왔다면, 본격적인 개발 전 마지막으로 API 명세서를 작성하려 했다.
API 명세서는 보통은 프론트엔드 개발자와 백엔드 개발자가 서로 간에 소통을 위해(ex. 요청/응답을 위한 데이터 형식, url 등에 대한 안내 위해) 만들곤 한다. 나 같은 경우는 1인 개발이기 때문에 큰 필요가 없을 수 있지만, 문서를 만들어놓으면 실제 이 명세서에 해당하는 API를 만들어달라고 gpt에 요청할 수 있기 때문에 추후 개발이 더 수월해질 것이라 생각했다. 추가로 개발하는 과정에서도 코드에서 주고받아야 하는 데이터 형식에 대해 기억이 안 날 때 참고가 가능하고, 미개발된 API 건이 뭐인지 트래킹이 쉬워진다고 생각했다. 이러한 이유 때문에 API 명세서를 만들기로 결정했다.
API 명세서를 만들 땐 앞 단계에서 만든 [1) 기획서와 2) ERD/테이블 정의서]를 GPT에 참고 문서로 전달하고, 추가로
기존에 사이드 프로젝트 시 가지고 있던 API 명세서 양식을 같이 전달해 GPT가 output으로 도출했으면 하는 명세서 양식을 전달했다. (ex. url/요청예시(Request body)/응답예시(성공 +실패 case들) 이 포함되어 있음)
GPT는 해당 양식에 맞게 하나하나 API 명세를 설계해줬고, GPT가 만들어준 결괏값들을 검토하고, 일부 수정 필요한 부분은 수정 요청을 하며 하나하나 노션 API 명세서에 작성을 해나갔다. (GPT는 API 명부터, url, 요청/응답예시, 실패 case 별 분류까지 전달해 줬다.)
이미 GPT는 참고문서로 전달한 기획서를 통해 각 API 기능들의 "맥락"을 인지하고 있고, 앞서 같이 만든 ERD/테이블 정의서를 통해 각 테이블과 테이블 내 정확한 컬럼명까지도 알고 있었기 때문에 더 정확한 API 명세 설계가 가능했다. (어떤 기능 "기획"때문에 이 API가 나온 것인지(기획서 기반), 어떤 컬럼명의 어떤 데이터를 주고받아야 하는지(ERD 기반)를 알고 있었다.)
내가 한 것은 GPT가 전달해 준 API 명세서를 노션 양식에 잘 복붙 하고, 성공/실패 메시지를 조금 더 내 입맛에 맞게 커스텀해달라고 요청하거나, 혹시나 빠진 요소가 있을 때 추가를 요청하는 정도였다.
4) 기획서&기능명세 보완
ERD, API 명세서까지 나온 이후에는 기능 명세에 디테일한 정보들을 추가해 줬다.
(ex. 고객 화면에서 유저가 "주문" 버튼을 눌렀을 때 orderCreate API를 호출하고, 프론트에선 Path parameter와, Request body로 각각 어떤 요소들을 넘긴다 등)
이 부분도 꼭 필요한 부분은 아니었지만,
1) 개발 시 어떤 데이터를 주고받아야 하는지 헷갈릴 수 있으니 아카이빙 하는 차원
2) GPT에게 개발을 부탁할 때, 상위기획정도의 러프한 기획서보단 디테일한 기획서가 있을 때 더 정확하고 덜 수정해도 되는 코드를 전달해 줄 거라 생각해 기획서/기능명세를 보완하는 시간을 거쳤다.
5) 백엔드 API 개발 (/w GPT)
그 뒤엔 백엔드 개발을 시작했다.
지금까지 GPT와 같이 만들었던, 1) 기획서 2) ERD/테이블 정의서 3) API 명세서를 기반으로
GPT에게 개발 패키지 구조를 어떻게 설계할지부터 같이 논의를 해갔다.
MVC 구조를 기반으로 GPT는 패키지 구조를 짜줬었고, 그 큰 구조를 기반으로 API 1개씩을 만들어가기 시작했다.
아래와 같은 프롬프트를 각 API를 설계할 때마다 전달을 했다.
아래 내용들을 참고해서 restaurantInfo API 에 대한 스프링부트 기반 설계를 도와줘.
- 기존에 CustomerViewLogin API 관련해서 리파지토리, 서비스, dto, 컨트롤러 코드 예시를 만들어줬던 것처럼 도와주면 돼
- 1번째 첨부한 사진이 API 명세서에 대한 간단한 요약이야.
- db 및 엔터티 클래스는 기존 파일들을 참고해줘
- 2번째 첨부한 사진은 내가 최종적으로 프론트엔드와 어떻게 연결하고 싶은지에 대한 상세한 기능명세서라고 보면 돼. 이것도 너가 작업할 떄 참고해줘
- 참고로 엔터티 클래스들은 이미 다 만들어져 있고, db에 더미데이터 들도 넣어져 있는 상태야.
- API 명세서에 대한 상세는 아래와 같아.
이를 바탕으로, gpt는 내 db 구조, 전체 기능에 대한 이해 등을 바탕으로 MVC 구조에 맞게 요소별로 하나씩 코드를 전달해 줬다. (DTO부터, Service, Repository, Controller, Entity 등)
나는 전달해 준 코드를 한번 쭉 읽어보며 코드를 에디터에 삽입했다. 그대로 쓰는 경우도 대다수였고, 특정 부분들에 대해선 추가 질문/수정요청을 해가면서 코드를 확정했다.
그 후 Swagger로 API가 잘 동작하는지 테스트했다.
초반엔 하나하나 체크하는데 좀 시간이 걸렸지만, 뒷부분 API에는 거의 수정 없이 바로 코드를 집어넣을 정도로 익숙해졌다. 이렇게 코드를 짜는 과정에서 Cursor 에디터를 연동해서 하나하나 내가 수동으로 옮겨 넣는 게 아니라 "반영" 등의 버튼으로 하는 게 더 빠른 속도였을 수도 있다. 하지만, 나는 개발을 공부하는 차원도 있었기에 + 오히려 그렇게 자동으로 옮기는 과정에서 오류가 나는 경우도 있어서 이 부분은 수동으로 코드를 옮겨 넣었다.
6) 프론트 UI 제작 &백엔드 연동 (/w GPT)
대개 백엔드 API를 1개 만들 때마다, 그에 대응하는 프론드엔드 코드를 짜고 프론트/백엔드 연동 테스트를 진행했다.
속도/효율성을 생각하면 백엔드를 먼저 다 짠 다음에 프론트 작업을 쭉 하는 게 효율적일 수도 있었을 것이다. 하지만 개발이 거의 처음에 가깝기 때문에, 이렇게 API 1개 단위로 나눠서 백엔드 프론트엔드를 왔다갔다 하는 것이 오류가 덜 발생하는 길일 것이라고 생각했다.
프론트엔드 개발도 백엔드 개발과 거의 유사하게 GPT를 활용해서 진행했다.
이제는 활용할 수 있는 게 각종 개발 문서 외에도, 내가 API 테스트까지 완료한 백엔드 API 코드도 있기 때문에 이를 같이 전달해서 GPT에게 프론트엔드 코드 작성을 요청했다.
아래는 프롬프트와, 프론트엔드 코드 예시다.
GPT는 백엔드가 어떻게 동작하는지에 대한 맥락도 가지고 있기 때문에, 프론트/백엔드 코드 사이의 연동에서의 오류를 잡는 과정이 많이 발생하지 않았다.
7) 프론트 UI 업그레이드(/w V0)
GPT로 프론트엔드 코드의 작성, 백엔드와의 연결까지는 잘 된다. 다만 프론트엔드의 디자인을 유려하게 만드는 데 있어서는 GPT만으로는 한계가 있었다. 이 부분은 V0(https://v0.dev/) 라고 하는 프론트엔드 전문 AI 를 활용했다.
이를 통해 프론트엔드 코드의 로직은 건드리지 않으면서도, 실제 디자인들을 보다 예쁘게 만들 수 있었다.
큰 품을 들이지 않고 "예쁘게 만들어줘" 정도의 러프한 프롬프트 만으로도 디자인이 훨씬 개선 됐었다. 나는 시간상 간단하게 했었지만, 좀 더 원하는 디자인이 있을 경우 이미지를 첨부하거나, 피그마 파일을 주는 정도만으로도 원하는 디자인이 어느 정도 유사하게 구현 가능하다. 또한 겉 껍데기 html 외에도 반응형, 애니메이션 등까지도 구현을 해주는 점이 신기한 포인트였다.
8) OpenAI API 연동 &외국어 지원 기능 구현 (/w GPT, Cursor)
마지막으로 타 기본적인 기능들과 다르게 외국어 지원 기능의 경우에는 1) OpenAI의 API 연동과, 2) Vuejs의 I18n 라이브러리를 이용해서 구현했다.
사장님이 메뉴 등록을 하는 로직 동작시, GPT를 호출해서 해당 메뉴의 메뉴명/메뉴 설명등을 영/중/일로 번역하게 만들었다. 그리고 번역된 값을 db에 저장함으로써, 프론트엔드 UI 상에서 특정 언어를 고를 시 선택한 언어에 해당하는 메뉴명/메뉴 설명 값이 내려오도록 만들었다.
그 외에 프론트엔드상에 하드코딩되어 있는 값들 (ex. ~~ 원, "닫기" 버튼, "주문하기" 버튼) 등은 Vuejs의 I18n 라이브러리를 이용했다. 특정 언어를 선택 시, 선택한 언어에 해당하는 값이 등장하게 해 뒀다.
아래 코드와 같이 각 하드코딩된 값들 별로, 언어별 값을 대응시켜 놨다. 이 부분의 경우, 일일이 번역을 해줘야 할 수도 있었겠지만 cursor 에디터의 경우 코드 자동완성 기능에서 번역도 자동으로 해줬기에 해당 값들을 그대로 적용할 수 있었다.
이 2가지 방식을 통해 "메뉴명/메뉴설명" 같이 백엔드에서 내려오는 값과, "주문하기/닫기" 같은 프론트엔드 하드코딩 값을 모두 번역해 외국어 지원을 아래 UI와 같이 구현할 수 있었다.
5. 결과물
이렇게 AI와 함께 바이브코딩 방식으로 아래 list에 있는 모든 기능을 5일 만에 기획/설계부터 개발까지 홀로 할 수 있었다.
결과물에 대한 소스코드는 아래 github에서 볼 수 있다.
https://github.com/kdb1248/kt-1st-term-project
GitHub - kdb1248/kt-1st-term-project
Contribute to kdb1248/kt-1st-term-project development by creating an account on GitHub.
github.com
프로젝트에 대한 세부 기획서와 시연영상, 각종 개발문서(ERD, API 명세서)는 아래 노션 링크에서 볼 수 있다.
https://nadosunbae.notion.site/_-1b3da7c537958071bafbd08b18412d6e?pvs=4
최종_결과 보고서 | Notion
0. 목차
nadosunbae.notion.site
6. 마치며
이번 글은, AI를 활용한 바이브코딩 방식으로 기획/설계부터 개발한 과정을 자세히 적어보려 노력했다.
이어지는 다음 글은 한 명의 기획자, PM/PO 커리어를 밟아가는 사람으로서 이번 프로젝트를 하면서 느꼈던 회고를 가볍게 작성하려 한다.
(긴 글 읽어주셔서 감사합니다. 다음 글에서 뵈어요~!)
Profile:
'개발공부' 카테고리의 다른 글
| 211016 데이터 크리에이터 캠프 본선! 최우수상 수상! (0) | 2021.10.18 |
|---|---|
| 10/2(일) 데크캠 예선, 연합 PIC 심사위원 (0) | 2021.10.02 |
| 8/10(화) 머신러닝 스터디, 회장단일 (0) | 2021.08.10 |
| 08/02(월) 회장단 업무 및 머신러닝 공부 (0) | 2021.08.02 |
| 07/28(수) 대학생 스파르타 코딩 불꽃반_백엔드 짜기 (0) | 2021.07.28 |