졸업프로젝트, 태초마을로 돌아가다

프로젝트를 진행할수록 초반 설계의 중요성을 뼈저리게 느끼고 있다. 

(그리고 좋은 설계를 위해서는 많은 경험이 필요하다는 것도.)

 

현재 우리 러블리한 Be My Story의 가장 중요한 기능은

일기 데이터를 이용한 동화책 생성 및 수정인데, 

'생성' 단계까지 구현을 완료했고, 

생성형 AI를 통해 만들어진 최초 동화책을 사용자가 '수정'(각색)하는 기능에 대한 회의를 진행하고 있었다.

 

 

 

어라 그런데 수정 기능 로직이 뭔가 이상하다.

우선 현재 동화책 생성 과정부터 짚고 가자.

 

 

1단계

유저가 일기 작성

→백엔드에게 일기 저장 및 동화텍스트 생성 요청

→백엔드(spring)에서 일기저장

→ AI서버(ChatGPT, Fastapi)에게 동화텍스트 생성 요청

→스프링에서 AI서버에게 텍스트 받고 DB에 저장 후 클라이언트에게 넘겨줌

 

2단계

클라이언트가 비동기로 동화책의 커버이미지와 각 페이지의 삽화이미지 요청

→스프링서버에서 AI서버(Dalle, Fastapi)에 이미지 생성 요청

→스프링에서 AI서버에게 이미지 받고 DB에 저장 후 클라이언트에게 넘겨줌

(2단계에서 이미지 생성까지 하지 못하는 이유는 이미지 생성 프롬프트에 동화 이야기가 필요하기 때문이다.)

---

그래서 동화책 수정도 위와 같은 과정을 거친 후 업데이트 된 내용에 대해

클라이언트가 spring서버에 PUT 요청을 보내면 될 거라고 생각했다.

 

 

 

그런데 갑자기 여러 의문이 들었다.

공격당하는 과거 로직들... 과거의 나...ㅎ 왜 이렇게 짰니

나:

"최초 생성물에서 수정이 무조건 이루어진다면 최초 생성물을 DB에 저장할 필요가 있나?"

 

"수정할 때도 AI 생성 요청(이미지 재생성)은 spring 서버를 거쳐가야 해?"

 

"만약 동화 이야기를 수정하고 그에 대한 이미지를 재생성하는 경우에는

spring서버에서 DB업데이트랑 AI 생성 요청을 둘다 해야 하네.

근데 수정은 여러 번 할 수도 있는 거잖아."

"안 그래도 동화책 요소(텍스트, 커버, 이미지, 생성날짜와 같은 메타정보) 다 찢어놔서 DB접근이 많은데 이런 식이면 동화책 하나에 처리해야 하는 쿼리가 너무 많은데?"

 

"그럴 거면 프론트가 직접 AI 서버랑 통신하는 게 맞지 않아?"

 

"수정할 거 다 하고 최종 저장본만 spring서버로 보내는 게 맞을 듯"

 

 

팀원들:

"근데 DB에 저장 안 하고 수정하다가 유저가 저장 버튼 안 누르고 나가버리면,

기껏 만든 거 다 날라가는데 이건 좀 아니지 않아?"

 

"기존 앱들 보면 임시저장되는 기능이 있다"

 

 

 

열띤 토론을 벌인 결과는 다음과 같다.

1. 클라이언트에서 AI 서버에 직접 동화책 생성을 요청한다.

2. 응답받은 최초 생성물을 spring서버에 보내서 DB에 저장한다.

3. 동화책 수정 페이지에서 유저가 삽화(이미지) 재생성을 원하는 경우 spring서버를 거치지 않고 

클라이언트가 AI 서버에 요청하고 받아온다.

4. 모든 수정이 끝나고 저장 버튼을 누르면 최종 동화책이 json형식으로 spring 서버로 넘어오고 DB에 저장한다.  

 

 

 

확실히 전의 단계보다 간소화되었고, 수정된 내용이 한 번에 DB에 반영된다.

눈물을 머금고 생성부터 다시 코드 대공사를 거쳐야 한다.

사실 백엔드를 담당한 나는 코드를 지우기만 하면 되어서 변화가 거의 없는데

프론트 팀원이 할 일이 많이 늘었다.....(정미닝....)

 

 

 

사실 바쁘다는 핑계와 부족한 경험 초반 설계에 공을 들이지 못했는데

(아예 감도 오지 않았다)

그 영향이 이렇게 나타나나 보다.

 

JPA도 더 공부해서 쿼리 요청을 줄이고 싶은데 프로젝트는 마지막을 향해가고

아직 구현하지 못한 기능은 많고...

백엔드 개발자로서 처음으로 진행하는 프로젝트인데 정말 우당탕탕 거침킥 찍는 기분^^

(정말 갈길이 멀다)

 

그치만 개발이 거의 처음인 나...

이렇게 성장하는 거 아닐까?>. <

아자아자 홧팅이닷