[2025 SUMMER DEV] 생성형 AI를 이용한 어린이 동화 창작 서비스 ‘IngQ’, 맥모닝팀

프로젝트 소개

IngQ는 저연령층의 사고력 증가 및 독서 흥미 유도를 위한 생성형 AI 기반 동화 만들기 앱입니다.

팀원 소개

맥모닝팀은 FE 지유님, BE 인재님, AI 준서님으로 구성되어 있습니다!

인터뷰

Q. 프로젝트를 소개해주세요!

A. 지유(FE): ingQ는 저연령층을 위한 AI 동화책 생성 어플리케이션입니다. 단순히 재미있는 이야기를 보여주는 것에서 그치는 것이 아니라, 아이들이 선택을 통해 스토리를 직접 만들어가고, 그 과정에서 자연스럽게 생각하는 힘을 기를 수 있도록 기획을 구체화했습니다. 처음에는 어떻게 하면 아이들이 부담 없이 접근할 수 있을까에 대한 고민으로 시작했습니다. 그래서 복잡한 설정 없이도 간단한 선택만으로 동화를 만들 수 있도록 구성했고, 줄거리도 직관적이고 간결하게 정리해주는 방식으로 기획을 구체화했습니다. 아이들의 몰입을 높이기 위해, 이야기 진행 중간마다 다양한 선택지를 제공하고, 선택 후에는 “왜 이걸 골랐나요?” 라는 질문을 통해 자연스럽게 생성된 이야기에 대한 사고를 유도할 수 있도록 했습니다. 이 부분은 단순히 스토리를 읽는 것이 아니라, 본인이 선택한 이유를 고민하고 이를 통해 독서에 있어 중요한 요소인 사고력을 길러내고자 했습니다. 무엇보다도, 내가 만든 이야기를 끝으로 끝나는 것이 아니라, 다른 친구들이 만든 이야기들을 읽어보고, 같은 테마로 자신만의 동화를 다시 만들어볼 수 있게 구성하면서 콘텐츠의 확장성과 참여도를 함께 높이고자 했습니다.

Q. 프로젝트 하면서 어떤 문제를 겪었나요?

A. 지유(FE): 저는 이번 프로젝트가 TypeScript 기반으로 프로젝트 초기 세팅부터 전반적인 개발까지 직접 주도해본 첫 경험이었습니다. 특히 “어디까지 타입으로 관리해야 하는가”에 대한 기준을 세우고 유지하는 과정에서 많은 고민이 있었습니다. 처음에는 명확한 타입 설계 기준 없이 개발을 시작했기 때문에, 점차 타입 정의가 중복되거나 지나치게 세분화되어있지 않은지 고민하기도 했습니다. 이러한 경험을 통해 프로젝트 초반에 타입의 범위와 추상화 수준을 명확히 정해두는 것이 얼마나 중요한지 깨닫게 됐습니다. TypeScript의 장점을 제대로 활용하려면 단순히 타입을 선언하는 것을 넘어서서, 설계 단계에서 구체적인 계획을 세워야만 한다는 걸 알게 됐습니다. 특히 위에서 말했던 이야기를 진행하는 StroyProgress 부분을 리팩토링하면서 타입이 가지고 있는 장점과 활용 방법에 대해서 고민해볼 수 있었습니다.

Q. 프로젝트 하기 전후 달라진 점이 있다면?

A. 준서(AI): 지금까지 저는 개발 과정에서 주로 다른 분야와 협업해 왔지만, 이번 프로젝트에서는 처음으로 같은 분야의 사람들과 협업하게 되었습니다. 혼자 개발할 땐 잘 몰랐는데, 같은 분야 개발자와 같은 파일을 만지고 나니 제가 놓치고 있던 부분과 부족한 점이 하나둘 보이기 시작했습니다. 그중 하나가 코드 컨벤션에 관한 부분이었습니다. 어느 날 다른 팀원의 PR을 보는데, 제가 작성한 코드에 ‘들여쓰기만’ 수정된 변경 사항이 잔뜩 보였습니다. 그제서야 서로 코드 스타일이 제각각이라 불필요한 수정이 생기고 있다는 걸 깨달았고, “이런 걸 어떻게 맞춰야 하지?”라는 의문이 들었습니다. 찾아보니 .eslintrc.js와 .prettierrc.js에 원하는 설정을 넣고, package.json에서 스크립트로 자동화를 걸어두면 서로의 코드 스타일을 맞출 수 있다는 걸 알게 됐습니다. 그리고 또 하나는 전역 상태 관리의 필요성입니다. 이야기 글자 크기를 바꾸는 단순한 기능을 구현하는데, 메뉴 컨테이너 → 상단 네브바 → 페이지 → 페이지 컨테이너로 props를 계속 전달해야 했습니다. 사실 프로젝트에 zustand가 이미 깔려 있었지만, 당시엔 전역 상태 관리 방법을 몰라 쓰지 못했죠. 그 결과, 불필요하게 깊은 컴포넌트 트리를 따라 데이터를 넘겨야만 했습니다. 이러한 경험들을 바탕으로, 저는 제가 작성한 코드에서의 추가적인 문제점들도 하나씩 분석해 나갔습니다. 프로젝트 전에는 단순히 팀원의 코드 스타일과 구조를 따라 하면서 코드를 짰기 때문에 “왜 이런 방식을 사용했을까?”라는 의문을 갖지 못했습니다. 하지만 이번 협업을 거치면서, 왜 TypeScript를 사용하는지, 어떻게 react-query를 적용하는지와 같은 기술적 선택의 이유를 고민하고 이해하게 되었습니다.

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

A. 인재(BE): 에코노에 들어와 시작한 프로젝트는 낯선 사람들과 함께 만들어가는 협업 프로젝트였습니다. 이 과정에서 느낀 점 중 하나는, 자신의 생각을 말이나 글로 “정확하게 표현하는 능력”이 엄청 중요하다는 것이었습니다. 첫 번째 화면을 두고 누군가는 “홈 화면”, “홈페이지”, “메인페이지”라고 불렀습니다. 화면을 부르는 이름, 각 기능에 대한 표현들 처음엔 사소한 일들이라 넘어갔던 용어들이 시간이 지나면서 작은 오해를 쌓고 결국엔 갈등의 씨앗이 될 수 있다는 점을 알게 되었습니다. 그래서 저는 “용어 사전”을 만들어 팀 내부에서 사용하는 용어를 통일하는 것을 꼭 추천하고 싶습니다. 또, 개발을 진행하다 보면 처음 듣는 기술이나 개념을 마주칠 일이 많은데, 그런 기술들을 지나치지 말고 직접 공부해보고 적용해보는 태도도 중요하다고 생각합니다. 이러한 과정 속에서, 제가 생각했던 것보다 더 큰 개인적인 성장을 경험할 수 있었습니다. 한 가지 더 전하고 싶은 것은, 스프린트 백로그를 활용해 일정을 리마인드하며 관리하는 방식입니다. 프로젝트를 하다 보면, 처음 계획한 일정에서 벗어나는 일이 자주 발생합니다. 이럴 때 일주일 단위로 계획을 세우고, 전체 일정을 조율하는 리더 역할이 있는 것이 큰 도움이 되었습니다. 대학생의 경우 학업이나 대외활동이 병행되다 보니 프로젝트를 잠깐 잊고 지내는 경우도 종종 발생합니다. 그럴 때 팀 내 누군가가 일정을 지속적으로 리마인드해주는 등대 같은 역할을 맡는다면, 훨씬 안정감 있게 프로젝트를 이어갈 수 있습니다. 새로운 프로젝트 화이팅입니다!!

Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

A. 인재(BE): IngQ 프로젝트에서 BE는 AWS EC2 서버를 사용했고, Docker Compose를 이용해 FastAPI, Nginx, Certbot을 모두 컨테이너로 구성했습니다. 이전에는 EC2에 직접 Nginx를 설치한 후, 로컬에서 Certbot을 실행해 인증서를 발급받았는데, 이를 모두 컨테이너 환경으로 옮기면서 예상치 못한 문제가 발생했습니다. 바로 Certbot이 인증서를 발급하고 종료되면, 인증서 파일 자체도 함께 사라져버리는 것이었습니다. 결국 Nginx 컨테이너는 SSL 인증서를 참조할 수 없었고 HTTPS 연결도 안되었습니다. 문제를 해결하기 위해 로컬과 컨테이너 간의 볼륨 연결을 살펴보기도 하고, 컨테이너가 아닌 로컬에서 Certbot을 실행하는 방안도 고려해보았습니다. 그러던 중 에코노에 인프라를 잘 아는 분과 이야기하면서 Docker Volume을 명시적으로 생성해 Nginx와 Certbot 컨테이너가 공유할 수 있도록 해보는 건 어떻겠냐는 의견이 나왔고 이를 시도해보기로 했습니다. 결과적으로 Certbot 컨테이너가 종료되더라도 인증서 파일은 Docker Volume에 유지되었고, Nginx는 해당 파일을 통해 정상적으로 SSL을 적용할 수 있었습니다. “모르는게 무엇인지 알고 있다면 해결책은 금방 찾을 수 있을 것이다.” 개발을 하면서 참 많이 들었던 말이었습니다. 모르는게 무엇인지 명확히 정의할 수 없다면, 하고자 하는 작업이 왜 안되는지를 다른 사람에게 설명해보는 과정에서 자신이 놓치고 있는 부분을 발견할 수 있다는 점을 깨달았습니다. 하고자 하는 작업이 잘 안 풀릴 때는 주변 사람의 도움을 받아 내가 모르는 지점을 명확히 해보는 것도 문제 해결의 좋은 출발점이 될 수 있다고 생각합니다.

Q. 프로젝트의 기술적인 도전 과제나 혁신적인 부분은 무엇이었나요?

A. 지유(FE): 웹 개발 당시 로그인 기능을 구현해본 경험은 있었지만, 이번 프로젝트에서는 앱이 가지고 있는 특수성을 고려하여 앱을 재실행했을 때도 로그인 상태를 유지해야 했습니다. 이전 프로젝트에서 로컬 스토리지를 이용한 로그인 방식을 채택했던 경험을 떠올려, AsyncStorage를 활용해 사용자 정보를 저장하고 불러오는 구조를 선택하여 구현하고자 했습니다. 처음에는 앱이 시작될 때 AsyncStorage에서 저장된 토큰을 불러와 곧바로 홈 화면에 반영하도록 구현했는데, 이 부분에서 문제가 생겼습니다. 로그아웃을 했더라도 스토리지에 남아 있는 인가되지 않은 토큰이 여전히 홈 화면에 반영되고, 그 상태로 API 요청이 전송되면서 계속해서 알 수 없는 오류가 발생했습니다. 처음엔 어디서 문제가 생긴 건지 명확히 감을 잡지 못했지만, 나중에야 스토리지에 있는 값과 실제 로그인 상태를 구분하지 않고 그대로 사용한 것이 문제였다는 걸 파악하게 되었습니다. 이 문제를 해결하기 위해 전역 상태 관리 로직을 도입해, 토큰의 유효성과 로그인 상태를 명확히 분리해서 관리했고, 스토리지에서 불러온 값은 초기 상태로만 사용하고 이후 상태 변화는 전역 상태를 기준으로 동기화하도록 구조를 개선했습니다. 또한, 전역 상태가 변화할 때마다 AsyncStorage 역시도 갱신해주며 비정상적인 종료 시 발생할 수 있는 문제를 차단하며 해결했습니다.

Q. 본인 팀만의 특별한 협업 방식이 있나요? 있다면 소개해 주세요

A. 준서(AI): 여러 의미로 남들보다 ‘일찍’ 개발을 시작했다는 점이 협업에 있어 저희 팀만의 아이덴티티라고 생각합니다. 의도한 건 아니지만, ‘맥모닝’이라는 팀 이름처럼 저희 팀은 맥모닝을 살 수 있는 아침 10시에 남들보다 일찍 모여 회의와 코어타임을 가졌습니다. 아무래도 저녁에 회의를 하는 다른 팀들은 동아리방에 사람이 많으면 방해도 되고, 소란스럽기도 하지만 저희는 조용한 동아리방에서 집중력있게 코어타임을 가질 수 있었습니다. 특히 방학 동안에는 아침 6시에 온라인으로 협업하기도 했습니다. 또한 팀의 목표 중 ‘일찍 기획을 끝내고 빨리 개발에 착수하자’가 있었습니다. 처음에는 기획을 일찍 끝내면 퀄리티가 떨어지지 않을까 걱정을 했습니다. 이런 걱정이 무색하게도, 팀원들이 너무 한쪽 의견에 휩쓸리거나 자기 의견을 너무 고집하는 것 없이 적당히 타협과 조율을 해준 덕분에 몇 번의 회의 만으로 바로 개발을 시작할 수 있었습니다.

지금까지 생성형 AI를 활용해 어린이들의 창의력과 사고력을 키워주는 동화 창작 서비스 IngQ를 개발한 맥모닝팀의 이야기를 전해드렸습니다. 누구보다 이른 시간부터 함께 고민하고 협업하며, 기술적인 도전과 사용자 경험을 모두 잡아낸것이 인상 깊었는데요. 앞으로도 아이들을 위한 따뜻한 기술로 많은 사람들의 일상에 의미 있는 변화를 만들어가길 기대합니다. 🖋️