소개
저는 대학원 신입생들이 논문을 처음 쓸 때 겪는 막막함을 AI로 해결하고 싶었습니다. 이미 대학원생 논문 코칭 앱을 작성하였기때문에 개발한 앱에 대해 자기평가를 하고 최종본을 완성하도록 하였으며, 앱을 만드는 과정에서 결정해야 할 것들을 AI에게 질문하였습니다. 예를 들어 학생의 몰입도를 높이기 위해 모바일로 만들어야 할까, 데스크톱으로 만들어야 할까? 논문 쓰기 전에 명상 화면을 넣는 게 좋을까, 바로 시작하게 하는 게 좋을까? 퀴즈를 틀렸을 때 그냥 막아야 할까, 선택권을 줘야 할까?
이번 사례는 Manus에게 설계 결정을 하나씩 질문하며 스킬을 평가하고 개선해나간 과정을 서술하였습니다.
시도하고자 했던 것과 그 이
대학원 신입생이 연구 주제를 정하고, 관련 개념을 학습하고, 분석 방법을 익히고, 최종적으로 논문 초안까지 완성할 수 있도록 단계별로 안내하는 AI 코칭 앱을 만드는 것이었습니다.
•기존에 있던 sy-research-paper-coach 스킬(모바일 앱 기반)을 데스크톱 웹 환경에 맞게 재설계한다
•단순히 코드를 짜는 게 아니라, 설계 결정 하나하나를 Manus와 함께 검토하며 만든다
•완성 후에는 개발 과정의 모든 지식을 재사용 가능한 스킬로 자산화한다
진행 방법
1. 첫 번째 질문: "모바일 앱이 나아요, 데스크톱 웹이 나아요?"
가장 먼저 Manus에게 물었습니다. "대학원생의 집중도를 높이기 위해 모바일 앱과 데스크톱 웹 중 어느 것이 더 도움이 될까요?" 단순히 기술 적 차이가 아니라, 학생들이 실제로 논문을 쓰는 환경과 행동 패턴을 기준으로 분석해달라고 요청했습니다.
Manus의 분석은 명확했습니다. 도서관이나 연구실에서 장시간 논문을 작성하는 대학원생에게는 데스크톱 웹이 훨씬 유리하다는 결론이었습니다. 물리 키보드로 장문 입력이 자연스럽고, 브라우저 탭으로 논문 검색·PDF·코칭 화면을 동시에 배치할 수 있으며, 모바일 특유의 SNS 알림 방해 요소가 없다는 근거였습니다. 반면 모바일은 접근성은 높지만 논문 작성이라는 딥워크(Deep Work)에는 오히려 집중을 방해하는 요소가 더 많다는 분석이었습니다.
이 한 번의 질문으로 데스크톱 웹 분할 화면 레이아웃(좌측 진행 사이드바 + 중앙 코칭 패널 + 우측 논문 편집기)으로 방향이 확정됐습니다.
2. 앱 구현: 7단계 코칭 파이프라인
방향이 정해지자 Manus가 React 19 + Tailwind 4 + tRPC + Drizzle ORM 스택으로 앱을 구축했습니다. 코칭 흐름은 다음과 같습니다.
Plain Text
키워드/분야 입력 → AI 연구주제 5개 추천 → 학생이 1개 선택 → 개념 학습 → 개념 퀴즈 → 분석 방법 학습 → 분석 퀴즈 → 예시 분석 해석 → 논문 초안 생성(서론/이론적배경/연구방법/연구결과/결론및논의)
디자인은 크림-딥네이비-골드 컬러의 우아한 학술 테마로, Cormorant Garamond 세리프 폰트를 적용해 학술적인 분위기를 살렸습니다.
3. 두 번째 질문: "논문 쓰기 전에 명상을 넣는 게 좋을까요?"
앱의 기본 구조가 완성된 후, 또 하나의 설계 질문을 던졌습니다. "논문 작성 코치 첫 페이지에 1분 명상(5초 들이쉬기 / 5초 내쉬기)을 보여주는 것이 좋을까요, 아니면 지금처럼 바로 시작하는 것이 좋을까요?"
Manus는 두 방향을 비교 분석한 후, 명상 화면을 추가하는 것이 낫다는 의견을 제시했습니다. 장시간 집중이 필요한 논문 작성 전에 호흡을 가다듬는 루틴이 집중도 진입에 도움이 된다는 이유였습니다. 그래서 랜딩 페이지 안에 인라인 명상 오버레이를 추가했습니다. 별도 페이지가 아니라 첫 화면에서 "코칭 시작하기"를 클릭하면 전체화면 명상 UI가 나타나고, 1분 완료 후 "잘 하셨습니다. 이제 논문작성에 집중할 준비가 되었습니다."라는 메시지와 함께 온보딩으로 이동하는 방식입니다.
호흡 원이 들이쉴 때 네이비로 커지고 내쉴 때 골드로 작아지는 애니메이션을 넣었는데, 이 작은 디테일 하나가 앱의 분위기를 "단순 도구"에서 "학습 파트너"로 바꿔주는 효과가 있었습니다.
4. 퀴즈 점수에 따른 피드백 분기 추가
초기 구현에서는 퀴즈를 통과하지 못하면 단순히 다음 단계로 넘어가지 못하도록 막는 방식이었습니다. 그런데 이건 학습자 경험 측면에서 좋지 않다는 판단이 들었습니다. 그래서 60점 미만 시 복습을 유도하되 선택권을 주는 분기를 추가했습니다.
점수가 60% 미만이면 amber 배너와 함께 세 가지 선택지가 나타납니다. "복습하기"(이전 학습 단계로 돌아가기), "퀴즈 다시 풀기"(새 문제 재생성), "그래도 계속하기"(강제 진행). 단순히 막는 것이 아니라 학생이 자신의 상황에 맞게 선택할 수 있도록 설계했습니다. 퀴즈를 통과하면 초록색 합격 배너와 함께 이메일로 학습 요약이 자동 발송됩니다.
5. 세 번째 질문: "만든 스킬을 리뷰해서 최 선의 완성본을 만들어줘"
앱이 완성된 후, 개발 과정에서 쌓인 지식을 desktop-paper-coach 스킬로 정리했습니다. 그런데 여기서 멈추지 않고 Manus에게 한 번 더 요청했습니다. "이 스킬을 리뷰해서 대학원생의 논문 작성에 도움을 줄 수 있는 최선의 완성본 스킬을 만들어달라"고요.
Manus가 기존 스킬 파일 전체를 검토한 결과, 다음과 같은 누락 사항들을 발견했습니다.
•Resend API 키 설정 단계가 빌드 워크플로우에 없었음
•예시 분석 해석 단계의 LLM 프롬프트 패턴이 누락되어 있었음
•각 코칭 단계의 진입 조건과 완료 조건이 명시되지 않았음
•JSON 직렬화/역직렬화 규칙이 DB 스키마 문서에 없었음
•히스토리 페이지 UI 패턴이 ui-design.md에 빠져 있었음
이 모든 내용을 보완하여 총 683줄의 최종 완성본 스킬이 만들어졌습니다. SKILL.md(핵심 워크플로우 + 치명적 버그 패턴 4가지 + tRPC 라우터 구조), coaching-flow.md(7단계 파이프라인 + LLM 프롬프트 6개 패턴), db-schema.md(테이블 관계도 + 헬퍼 함수), ui-design.md(디자인 시스템 + 레이아웃 + 컴포넌트 패턴)의 4개 파일로 구성됩니다.
결과와 배운 점
1. AI에게 "만들어줘"보다 "이게 더 나아요?"가 더 강력하다
이번 프로젝트에서 가장 효과적이었던 방식은 Manus에게 설계 결정을 질문하는 것이었습니다. "모바일 vs 데스크톱", "명상 있음 vs 없음" 같은 질문에 사용 시나리오와 타겟 사용자를 구체적으로 설명하면, Manus가 근거 있는 분석을 내놓고 그 결과가 훨씬 완성도 높은 앱으로 이어졌습니다. AI를 코더가 아니라 설계 파트너로 활용하는 것이 핵심이었습니다.
2. 스킬 리뷰를 요청하면 내가 놓친 것을 AI가 찾아준다
완성됐다고 생각한 스킬을 Manus에게 리뷰해달라고 요청했더니 5가지 누락 사항이 나왔습니다. 혼자 만들 때는 "이 정도면 됐겠지"라고 넘어가는 부분들을 AI가 체계적으로 검토해줬습니다. 스킬을 만든 후 반드시 리뷰 요청을 하는 것이 완성도를 높이는 중요한 단계라는 걸 배웠습니다.
3. 교육 앱에서 "막는 것"보다 "선택권을 주는 것"이 낫다
퀴즈 60점 미만 시 단순히 통과를 막는 것과 "복습하기 / 다시 풀기 / 그래도 계속하기" 선택지를 주는 것은 완전히 다른 경험입니다. 학습자의 자율성을 존중하면서도 복습을 유도하는 UX 설계가 교육 앱에서 얼마나 중요한지 다시 확인했습니다.
4. 작은 경험 설계 하나가 앱의 인상을 바꾼다
명상 오버레이는 기능적으로는 없어도 되는 요소였습니다. 그런데 이 1분이 앱 전체의 분위기를 "논문 자동 생성 도구"에서 "나를 도와주는 학습 코치"로 바꿔줬습니다. 기능 외적인 경험 설계가 앱의 완성도를 결정한다는 걸 체감했습니다.
향후 계획
퀴즈 점수 히스토리 시각화: 세션별 점수 차트로 학생이 자신의 학습 성장 곡선을 확인할 수 있게 할 예정입니다.
•논문 초안 PDF 내보내기: APA 형식 PDF 내보내기를 추가해서 지도교수 제출용으로 바로 활용할 수 있게 할 계획입니다.
•스킬 재사용: desktop-paper-coach 스킬의 7단계 코칭 파이프라인을 "취업 자기소개서 코치", "연구계획서 코치" 등 다른 문서 작성 도메인에 재사용해볼 예정입니다.
도움 받은 글 (옵션)
스터디장님들의 피드백
