ᓚᘏᗢ

[UNIKER 1기] 비전공자 개발일지(5) | 서비스 방향성 정비하기, 디자인 수정하기

인애_ — Sat, 1 Aug 2026 02:19:00 +0900

이전 이야기

지난주에는 Codex Exec API를 연결해서 실제로 AI와 대화를 해볼 수 있는 단계까지 왔다.

이번 주에는 직접 서비스를 계속 사용해보면서 '이 서비스가 정말 재미있는가?'를 계속 고민했던 것 같다.

이번 주 한눈에 보기

- 사용 도구: Codex, Claude, Figma, Figma MCP

-진행 내용: 서비스 방향성 재정립, 디자인 수정 및 디자인 작업 방식 변경

1. 서비스 방향성 수정하기
테스트 기반 서비스 보완

API를 연결하고 실제로 캐릭터와 대화를 해보니 생각보다 아쉬운 점이 많았다.
우선 응답 속도가 조금 느렸고, 캐릭터가 하는 말도 비슷한 패턴을 반복하는 경우가 많았다.
처음에는 신기했지만, 몇 번 대화를 이어가다 보니 실제 사람과 대화하는 느낌은 많이 부족했다.

계속 같은 이모지만 쓴다거나, 평이한 위로의 말만 반복

사실 이런 정도의 채팅은 이미 ChatGPT나 다른 AI 서비스에서도 충분히 할 수 있다.
우리 서비스만의 차별성이 무엇인지 점점 애매하게 느껴졌다.
그래서 팀원들과 앞으로 어떤 방향으로 서비스를 가져갈지 다시 이야기를 많이 했다.
우선 크게 세 가지 방향을 고민했다.

(1) 부가 기능 추가

채팅만으로는 재미가 부족하니, 다른 콘텐츠를 넣어보는 방법이다.

페메 게임 레퍼런스

예를 들어 예전 페이스북 메시지 감성처럼 미니게임을 넣거나, 캐릭터와 함께 할 수 있는 작은 기능들을 추가하는 아이디어가 나왔다.

(2) 페르소나를 훨씬 구체화하기

현재는 캐릭터마다 기본적인 성격 정도만 설정되어 있다.
하지만 실제 사람처럼 대화하려면 말투, 자주 사용하는 표현, 반응 방식, 상황별 대화 흐름까지 훨씬 구체적으로 정의해야 할 것 같았다.

예를 들어
어떤 상황에서 먼저 질문하는지 공감은 어떻게 하는지 장난은 어떤 식으로 치는지 자주 쓰는 말버릇은 무엇인지
이런 부분까지 하나씩 만들어 주고, 실제 대화 예시(Few-shot Prompting)도 함께 학습시키는 방향을 고민했다.

(3) 서비스 컨셉 자체 변경

처음부터 만들고 싶었던 것은 '폴더폰 감성'이었다.
그래서 오히려 AI 채팅 자체보다 그 감성을 살리는 방향도 생각해 봤다.

원했던 폴더폰/터치폰 감성!!

예를 들면
메시지가 바로 오지 않고 천천히 도착한다거나 기다리는 시간이 오히려 재미가 된다거나 예전 휴대폰을 쓰던 시절의 감성을 느낄 수 있는 서비스
이런 아이디어들도 함께 이야기했다.

멘토링 결과

이번 주 멘토링에서도 이 고민을 그대로 말씀드렸다.
멘토님께서는 지금 단계에서는 서비스를 크게 바꾸기보다는 페르소나를 먼저 충분히 구체화해 보는 것이 좋겠다고 조언해 주셨다.
서비스 방향 자체는 지금도 충분히 가능성이 있고, 캐릭터의 완성도가 올라가면 사용 경험도 많이 달라질 수 있다는 의견이었다.
우리도 이야기를 나눠본 결과, 우선은 페르소나를 최대한 구체적으로 만드는 방향으로 진행해 보기로 결정했다.

2. 디자인 작업 방식 바꾸기
디자인 디벨롭

이번 주에는 디자인 작업 방식도 조금 바꿨다.

지금까지는 피그마에는 간단하게 디자인만 만들어 두고, 그걸 바탕으로 Claude나 Codex에게 디자인 MD를 작성하게 해서 HTML을 수정하는 방식이었다.

그런데 계속 원하는 결과가 나오지 않았다.

디자인이 전체적으로 뭔가 아쉬웠다...

묘...하게 밤티나는 디자인..ㅠ

그래서 이번에는 접근 방식을 아예 바꿨다.

먼저 피그마에서 원하는 디자인을 최대한 자세하게 만들고,

그 디자인 자체를 기준으로 HTML을 수정하기로 했다.

이번에는 Figma MCP도 연결해서 Claude가 피그마 디자인을 직접 참고하도록 했다.

생각보다 꽤 편할 줄 알았는데...

완벽하게 그대로 구현되지는 않았다.

여백도 조금씩 다르고, 둥근 정도도 다르고, 아이콘도 원하는 스타일이 아니고,

폰트도 제대로 적용되지 않는 경우가 많았다.

결국 "조금 더 위로", "여백을 더 넓게", "모서리를 조금 더 둥글게", "이 아이콘 스타일로 바꿔줘" 같은 식으로 계속 프롬프트를 추가하면서 수정했다.

수정 중...

AI가 디자인도 꽤 잘해주는 시대라고 생각했는데,

막상 원하는 퀄리티까지 맞추려면 생각보다 사람이 엄청 꼼꼼하게 디렉션을 줘야 한다는 걸 많이 느꼈다.

그래도 이전보다 훨씬 원하는 느낌에 가까워지고 있다.

수정된 버전은 다시 디자인md로만들어 업데이트 해두었다.

다음 주 목표

다음 주에는 디자인 수정을 마무리하고,

Codex Exec API에 캐릭터별 페르소나를 계속 학습시켜 대화 품질을 높여볼 예정이다.

이번 주는 새로운 기능을 만든 주라기보다,

서비스가 어떤 방향으로 가야 하는지 다시 고민했던 시간이었다.

조금 돌아가는 것처럼 느껴질 수도 있지만, 지금 방향을 제대로 잡아두는 게 이후 개발에서는 훨씬 중요할 것 같다.

[UNIKER 1기] 비전공자 개발일지(4) | 프로토타입과 AI API 연결하기, 디자인 수정, 방향성 재정립

인애_ — Sat, 25 Jul 2026 16:07:24 +0900

이전 이야기

지난주까지 HTML형태로 프로토타입을 만들고, 디자인 MD를 1차로 적용해보았다.

이번주에는 제작한 프로토타입에 AI API를 연결하고, 디자인 세부 수정과 서비스 방향성 재정립을 해보았다.

이번 주 한눈에 보기

- 사용 도구: 코덱스, 깃헙

- 산출물: 프로토타입 URL

지난주에는 무료 버전 Gemini API를 연결해 테스트를 진행했지만, 크레딧 제한으로 인해 여러 명이 동시에 사용하는 환경에서는 원활하게 작동하지 않는 문제가 있었다. 이에 따라 유니커 주최 측에서 추천해 준 Codex Exec API를 새롭게 연결하기로 결정했고, 우선은 로컬 환경에서 안정적으로 작동하는 것을 목표로 개발을 진행했다.

이번 주에도 팀원끼리 역할을 나눠 진행했다.

(1) 프론트엔드: 세부 디자인 수정, 폰트 적용 문제 해결

(2) 백엔드: 코덱스 API 연결

(3) 디자인: 디자인 MD 수정

나는 이중에서도 프론트엔드를 담당했다.

1. HTML 초안 수정하기
QA 수행 기준 HTML 수정하기

지난 번 1차로 만들었던 HTML에 기반해 QA시트도 만들었었다.

QA 체크리스트는 Claude를 활용해 생성했는데, 무려 97개의 점검 항목이 만들어졌다.

아직 AI API를 연결하지 않은 채팅 기능을 제외한 나머지 기능을 중심으로 QA를 진행했고, 그 과정에서 수정이 필요한 사항들을 하나씩 정리했다.

그중 하나는 채팅방에서 이미지가 일부만 정상적으로 적용되는 문제였다. 같은 방식으로 이미지를 등록했음에도 어떤 이미지는 정상적으로 표시되고, 어떤 이미지는 적용되지 않는 현상이 발생했다. 수정 요청을 정확하게 전달하기 위해서는 먼저 원인을 파악하는 것이 필요하다고 판단했다.

원인을 확인해 보니 이미지 용량과 파일 확장자가 문제였다. 이미지 용량이 2MB를 초과하면 업로드가 되지 않았고, 지원하지 않는 파일 확장자 역시 적용되지 않았다.

그래서 오류 상황을 ① 이미지 용량 초과와 ② 지원하지 않는 파일 형식으로 구분하고, 각 상황에 맞는 경고 문구가 표시되도록 수정을 요청했다.

아주 잘 적용된 모습

이 외에도 QA를 진행하며 발견한 자잘한 오류와 UI 개선 사항들을 하나씩 수정했다. 이제 HTML 기반의 프로토타입은 어느 정도 안정화되었다. 다음 단계는 AI API를 연동해 실제 채팅 기능을 구현하는 것이다.

2. AI API 연결하기

팀원이 원래 제미나이 API에 학습되어있던 캐릭터별 채팅 페르소나를 CODEX exec로 옮겨주었다.

팀원이 API 연결법이나 세팅을 깃헙에 올려주어서, 코덱스에게 이를 토대로 HTML에 연결해주고, 버전을 2.0으로 올려달라고 했다.

목표 설정으로 될 때 까지 진행해달라고 해서, 실행되기를 기다렸는데...

작동이 되지 않았다!!!

오류 사항을 수정해 달라고 요청한 뒤, HTML에 API를 직접 연결하는 대신 HTTPS 환경에서 접속할 수 있는 형태로 구현해 주었다. 덕분에 AI API를 연동한 채팅 기능도 정상적으로 테스트할 수 있었다.

다만 현재 페이지는 Codex Exec API를 연동한 팀원의 로컬 서버에서 실행되고 있기 때문에, 해당 팀원이 서버를 켜 두어야만 정상적으로 접속할 수 있었다. 즉, 다른 사람이 언제든 접속할 수 있는 형태로 배포된 서비스는 아니었다.

디자인 MD도 조금 수정한 모습..

아래는 실제로 구현된 서비스와 AI와의 대화 예시이다.

대화의 맥락은 비교적 잘 이해하는 편이었지만, 같은 표현을 반복하거나 질문만 연달아 이어가는 경우가 많았다.

대화의 질이 떨어지니, 우리 서비스의 차별성이나 독특함이 많이 줄어드는 듯한 문제가 발생했다. 이런 간단한 반응은 기존의 챗 GPT나 다른 AI 메신저 서비스로 할 수 있는데, 뭔가 서비스의 방향성이 명확하지 않으니 이도저도 아니게 애매해지는 느낌..?

앞으로 각 캐릭터의 말투와 성격, 대화 방식, 반응 패턴 등을 더욱 구체적으로 정의해 보다 자연스러운 대화 경험을 구현하는데 집중해야 할 것 같다.

3. 멘토링

이번 주에도 멘토링을 진행했다. 이번주 멘토링을 통해서는 기능적인 부분(채팅 데이터 저장 등)과 서비스 방향성에 대한 조언을 얻었다.

(1) 채팅 데이터는 Local Storage로 관리해보기

현재는 테스트를 진행할 때마다 새로운 채팅방이 생성되어 이전 대화가 모두 사라지는 상태였다. 멘토님께 여쭤본 결과, 브라우저의 Local Storage를 활용하면 채팅 데이터를 저장해 새로 접속하더라도 이전 대화를 유지할 수 있을 것이라는 조언을 받았다.

이 부분은 Codex를 활용해 구현해 볼 예정이다.

---

(2) 지금은 사업성보다 타깃이 중요하다

서비스를 개발하면서 ChatGPT는 대화 품질이 더 뛰어나고, 타 AI 채팅 서비스들은 캐릭터 몰입감이 더 높다는 생각이 들었다. 그래서 지금 아이템이 충분한 경쟁력을 가질 수 있을지 고민이 많았다.

이에 대해서 현재 서비스는 대학생을 주요 타깃으로 설정하는 것이 좋겠다는 피드백을 받았다. 예를 들어 AI 캐릭터도 대학생이라는 설정을 가지고, 방학이나 과제, 시험, 교수님 등 대학생들이 공감할 수 있는 상황을 자연스럽게 대화에 녹여내면 훨씬 몰입감 있는 서비스를 만들 수 있다는 조언이었다.

---

(3) AI 서비스의 차이는 프롬프트가 아니라 구조

처음에는 캐릭터의 말투나 성격을 더 자세하게 작성하면 자연스러운 대화가 만들어질 것이라고 생각했다.

하지만 멘토님은 타 서비스는 단순히 시스템 프롬프트만으로 동작하는 것이 아니라, 사용자의 질문을 분석하고, 가장 적절한 답변을 선택하며, 안전성을 확인한 뒤, 마지막으로 캐릭터의 말투에 맞게 응답을 생성하는 다중 에이전트 구조를 갖추고 있다고 설명해 주셨다.

현재 MVP 단계에서는 이러한 구조를 모두 구현하기는 어렵지만, Few-shot Prompting을 활용해 원하는 답변 예시를 함께 제공하면 응답 품질을 높이는 데 도움이 될 수 있다는 팁도 얻었다.

---

(4) 앞으로의 서비스 방향

멘토링 이후에는 기능을 무작정 추가하기보다 AI 채팅 경험 자체를 고도화하는 방향에 집중하기로 했다.

예를 들어 AI가 먼저 말을 거는 기능이나 음성 기반 대화, 그룹 채팅과 같은 기능은 이후 확장 아이디어로 남겨두고, 우선은 자연스러운 대화와 캐릭터의 일관성을 높이는 데 집중할 예정이다.

이번 멘토링을 통해 단순히 기능을 많이 만드는 것보다, 명확한 타깃을 설정하고 그들에게 자연스러운 대화 경험을 제공하는 것이 AI 서비스에서 가장 중요한 요소라는 점을 다시 한번 확인할 수 있었다.

---

다음주는 이에 따라 서비스 방향성도 조금 뾰족하게 잡고, 그에 따라 디자인/페르소나 학습을 더 해봐야 할 것 같다!!

[UNIKER 1기] 비전공자 개발일지(3) | HTML 프론트엔드 개발, 디자인md 적용하기

인애_ — Sun, 19 Jul 2026 03:28:50 +0900

이전 이야기

지난주까지 화면별 상세 PRD를 구체화하고, 피그마로 화면별 와이어프레임을 제작했다.

이번주에는 Codex를 이용해 프론트엔드 개발을 해 HTML 형태로 프로토타입을 만들고, 제작된 디자인 md를 프로토타입에 적용해보았다.

이번 주 한눈에 보기

- 사용 도구: 코덱스(프로토타입 제작, 디자인 md 작성·적용), 피그마

- 산출물: 프로토타입 HTML, 디자인 md

지난번 피그마를 활용해 와이어프레임 제작을 완료한 이후, 팀원들은 역할을 다음과 같이 분담해 본격적인 개발을 진행했다.

(1) 프론트엔드: 사용자가 직접 보게 되는 화면과 인터랙션 구현

(2) 백엔드: 화면 뒤에서 동작하는 기능 구현 (AI 챗봇 페르소나별 말투 학습, API 연동 등)

(3) 디자인: 디자인 시스템 및 Design MD 제작

나는 이중에서도 프론트엔드를 담당했다.

1. HTML 초안 만들기
화면별 프로토타입 제작, 합치기

우리 서비스의 화면은 크게 세 개로 나누어 볼 수 있다.

(1) 친구 목록 화면: 내 프로필 수정, AI 친구 추가 및 프로필 설정

(2) 채팅 목록: 개인/단체 채팅방 생성

(3) 채팅방: AI와의 대화, 채팅방 설정 변경

사실 처음에는 모든 기능을 하나의 파일에서 구현하지 않고, 기능별로 프로토타입을 분리해 총 3개의 HTML 파일을 제작했다.

처음부터 하나의 프로젝트에서 모든 기능을 구현하면 AI와의 대화가 길어질수록 컨텍스트가 커지고, 세부 기능을 수정할 때 토큰 사용량도 크게 늘어날 것으로 판단했다. 그래서 각 기능을 개별적으로 구현해 어느 정도 완성한 뒤, 마지막에 하나의 프로젝트로 통합하는 방식으로 개발을 진행했다.

친구목록을 구현한 방식을 예시로 과정을 써보자면,

우선 클로드에게 제작해둔 피그마 와이어프레임과 화면별 PRD을 학습하라고 한 뒤 부족한 내용이나 와이어프레임에서 빠진 부분이 있는지 물어보았다.

그랬더니 생각하지 못한 부분에서도 세세하게 보충할 부분을 알려주었다. 그래서 제작해둔 screen spec을 추가로 제공한 뒤 흐름에 맞추어 부족한 부분을 보충해달라고 요청했고, 그것에 기반해 와이어프레임을 수정해달라고 요청했다.

이렇게 요청을 했는데, 클로드는 폰트 적용이 잘 안되는 것 같다. 디자인 요청사항이 많이 모호해서 그런 걸 수도 있지만, 폰트정도는 잘 적용되길 바랐는데... 결국 폰트는 나중에 일괄로 수동 수정했다.

AS IS -> TO BE

이전 와이어프레임에 비해 화면이 간결해졌고, 흐름도 명확해졌던 것 같다.

이후부터는 작업 환경을 코덱스로 옮겨 HTML 구현을 시작했다.

이 단계부터 코덱스를 사용한 이유는 로컬 프로젝트와 직접 연결되어 있기 때문이다. 따라서 화면을 수정하거나 기능을 변경하면 HTML뿐만 아니라 PRD, 화면별 PRD, Screen Spec 등 관련 문서까지 함께 수정하도록 한 번에 요청할 수 있었다. 덕분에 구현 내용과 문서 간의 일관성을 유지하면서 개발을 진행할 수 있었다.

그리고 나서 codex가 만들어준 HTML 프로토타입 초안

색도... 디자인도 마음에 들지 않는 부분이 많았지만, 이 단계에서 중요한 것은 기능이 제대로 구현되고 있는지였기 때문에 기능 위주로 코덱스에게 피드백을 주었다.

이렇게 총 3개의 프로토타입 화면을 어느정도 구현해둔 뒤, 세 파일을 하나로 합쳤다.

2. HTML 수정하기
제한사항 적용, 세부 사항 수정, QA시트 만들

세 개의 HTML 파일을 하나의 프로토타입으로 통합한 뒤, 실제로 사용해 보면서 기획에 맞게 추가하고 싶은 화면들이 생겼다.

주요 수정 사항

- 앱에 처음 접속했을 때 사용자 이름을 설정하는 온보딩 화면 추가
- 친구 목록에서 내 프로필과 친구 프로필이 명확하게 구분되도록 UI 개선
- 내 프로필도 친구 프로필처럼 사진을 직접 선택해 등록할 수 있도록 수정
- 채팅방 이름을 언제든 변경할 수 있도록 수정
- 채팅방 멤버를 자유롭게 추가·삭제할 수 있도록 기능 추가

이러한 화면들은 텍스트만으로 코덱스에 요청하면 의도한 UI와 동선이 정확하게 구현되지 않을 가능성이 있다고 판단했다. 그래서 먼저 피그마에서 수정할 화면을 직접 디자인한 뒤, 이를 바탕으로 구현을 요청했다. 대부분 기존 화면을 일부 수정하는 수준이었기 때문에 디자인 작업에는 많은 시간이 소요되지 않았다.

수정이 필요한 화면들은 피그마의 별도 섹션에 정리해두고, 코덱스가 해당 화면을 참고해 구현할 수 있도록 했다.

화면 구조는 피그마를 기준으로 구현했지만, AI가 임의로 작성한 문구나 버튼 간격, 줄바꿈, 정렬과 같은 세부적인 요소들은 코덱스를 통해 반복적으로 수정했다. 이러한 수정 사항은 직접 HTML을 편집해서 반영할 수도 있었지만, HTML 구조를 잘못 수정해 다른 기능에 영향을 줄 가능성을 고려해 모든 변경 사항을 코덱스를 통해 적용했다. 수정 요청과 실제 코드 변경 과정을 일관되게 관리하는 편이 더 안정적이라고 판단했기 때문이다.

또한 변경 사항이 발생할 때마다 GitHub에 즉시 반영해 팀원들과 공유했다. 이를 통해 다른 팀원들도 최신 프로젝트를 내려받아 자신의 코덱스에서 동일한 작업 환경을 유지하며 개발을 이어갈 수 있었다.

또한 이렇게 작업을 하다가, 꼼꼼하게 모든 기능을 이용해보고 수정 사항을 확인해야 할 것 같아 QA 시트를 만들었다.

(이것 또한 AI에 요청...ㅎㅎ)

이후 기능들이 추가되면서 QA 시트를 업데이트해야겠지만, 작업을 하면서 확인해야 할 부분을 미리 적어두는 정도로 생각하고 미리 만들어두었다. AI에게 요청하니 내가 생각하지도 못했던 부분들까지 꼼꼼하게 적어주어서 맡기길 잘했다는 생각이 들었다.

3. 디자인md 적용하기
디자인 md 적용, 기기 범용성 확대

팀 회의를 거쳐, 디자인을 맡은 팀원이 만든 디자인md를 HTML에 적용했다.

우리가 원했던 디자인 컨셉은 꽤나 명확했다. 옛날 피처폰/폴더폰의 문자 감성!!

전체적인 디자인은 귀여운 분위기를 유지하면서도 픽셀 이모지와 픽셀 폰트를 활용해 레트로 게임 감성을 담으려 했다.

다만 가장 걱정됐던 부분은 폰트 적용이었다. 사용할 폰트는 상업적 이용이 가능한 무료 폰트였지만, 이전에 AI를 활용해 와이어프레임을 제작하는 과정에서도 폰트가 정상적으로 적용되지 않았던 경험이 있었기 때문이다. 그래서 실제 HTML 환경에서도 동일한 문제가 발생하지 않을지 우려가 있었다.

하지만~우려가 무색하게 폰트 적용은 너무 잘되었다 ㅎㅎ...

사실 저 상태가 될때까지 세부적으로 수정한 사항은 정말 많지만, 결론적으로는 잘 만들어졌다.

멘토링 및 다음 과제

이후 우리의 과제는 프로토타입과 회피형, 안정형, 불안형으로 설계한 AI 페르소나를 연결하는 것이었다.

하지만 구현 과정에서 예상하지 못한 문제가 발생했다. 예산이 없었기 때문에 무료로 사용할 수 있는 Gemini API를 활용하려고 했는데, 개인 API 키를 사용하는 방식이다 보니 다른 팀원이 동일한 API를 사용할 경우 사용량 제한에 걸리는 문제가 있었다.

우리의 1차 목표는 로컬 환경에서 서비스가 정상적으로 동작하는 것이었다. 그래서 API 의존성을 줄이기 위해 코덱스 Exec 기반으로 AI를 변경하는 방안을 검토했다.

그러나 백엔드를 담당한 팀원이 기존 Gemini API를 코덱스 Exec 방식으로 전환하는 과정에서 또 다른 문제가 발생했다. AI는 정상적으로 응답했지만, 각 페르소나에 맞게 학습시켜 둔 말투와 성격이 제대로 반영되지 않았다.

이 문제는 어떻게 해결해야 할지 모르겠어서, 유니커 멘토링에서 질문하기로,,

또 다른 문제도 발생했다. HTML 프로토타입에 폰트를 적용했을 때 내 로컬 환경에서는 정상적으로 표시되었지만, 다른 팀원들의 컴퓨터에서는 동일한 폰트가 적용되지 않는 문제가 발생했다.

처음에는 코드 자체의 문제인지, 폰트 파일을 불러오는 방식의 문제인지 원인을 명확하게 파악하지 못했다. 팀원들의 개발 환경에서만 발생하는 문제였기 때문에 쉽게 해결하기도 어려웠다. 결국 이 문제 역시 자체적으로 해결하기보다는 멘토링 시간에 원인을 함께 점검하고 해결 방안을 조언받기로 했다.

이주의 질문사항
1. API 사용 관련 질문
- 현재 Gemini API 무료 버전으로 페르소나를 학습시킨 상태인데, Codex exec(구독 호출)로 어떻게 바꾸면 될지 여쭙고 싶습니다!
- 페르소나 학습은 모두 유지한 채로 제미나이 → 코덱스로 빠르게 바꾸는 방법이 있을까요?

2. 폰트 적용 방식
- 프로토타입을 작업한 사람에게만 폰트가 적용되고 있습니다. 다른 팀원의 PC에도 같은 폰트가 설치되어 있는데, 동일하게 적용되지 않았으며 + 핸드폰에서도 적용이 안되는 상황입니다.
- 팀원 모두에게 동일한 폰트가 적용되도록 하려면 어떤 방식으로 설정하면 될까요?

3. MVP 테스트를 위한 서버 운영 방식
- MVP 테스트를 진행할 때도 로컬 서버를 사용하는 것이 일반적인가요, 아니면 별도의 배포 서버를 사용하는 것이 좋을까요? MVP 테스트 진행 과정이 궁금합니다.

멘토링에서는 질문했던 내용 중 1번과 2번에 대해 먼저 피드백을 받았다. 멘토님께서는 GitHub 저장소와 HTML 코드를 직접 검토한 뒤 원인을 함께 살펴보겠다고 말씀해 주셨다.

한편 3번 질문인 서비스 배포에 대해서는 현실적인 한계가 있었다. 당시 유니커 활동에서는 별도의 배포 인프라를 제공하지 않았기 때문에, 서비스를 외부에 배포해 공유하는 것은 어려운 상황이었다. 따라서 최종 시연은 로컬 환경에서 서버를 실행한 뒤 화면을 공유하는 방식으로 진행하는 것이 가장 현실적인 방법이라는 조언을 받았다.

그래서 다음 주의 주 목표는 AI API 문제를 해결하고, 폰트 적용 문제 해결, 디자인 세부 수정

정도가 될 것 같다!

다음주에 계속...

바이브코딩으로 반려돌 위젯을 만들어보자 | Claude code, Codex, Github 배포파일 포함

인애_ — Tue, 14 Jul 2026 18:44:22 +0900

1) 반려돌이 가지고 싶어

나는 <에브리씽 에브리웨어 올앳원스> 영화를 좋아한다.

2022년에 처음 나온 이후, 지금까지 계속해서 아껴두고 돌려보고 있다.

그 어떤 가능성과 세계관이 있어도 난 너를 선택할거야!

거기에 나오는 googly eyes가 붙은
반려돌 굿즈가 너무 가지고 싶었다.

이 영화가 나온지 벌써 4년이나 지났지만...
아직도 이 돌이 괜히 탐났다.
그치만!! 돌을 돈주고 사기는 좀 그런...느낌

그래서 실물 굿즈 대신,
제가 하루에 절반 이상 붙어있는 컴퓨터 화면에
이 반려돌이 있으면 좋을 것 같다는 생각을 했다.

2) 기능

이 반려돌이 어떤 기능을 가지면 좋을까 고민해 보았는데,

반려돌은 원래 엄청난 기능을 가진 존재라기보다,
존재 자체만으로도 귀엽고 소중한 매력이 있는 것 같다는 생각을 했다.

그래서 제가 만든 반려돌 위젯도 특별히 많은 기능을 넣지는 않았다.
1) 사용자가 컴퓨터를 사용하는 동안에는 눈을 뜨고 있다가,
2) 일정 시간 동안 사용이 없으면 눈을 감고 잠에 든다.
3) 쓰다듬으면 눈웃음을 짓고, 흔들면 동공이 커진다.

별다른 기능은 없지만, 귀여운 것이 곧 기능인..
그런 위젯을 만들고 싶었다!

제작 과정

오늘도 결과물부터!!

이번 바이브 코딩은 Claude code를 사용해서 해보았다.

사람마다 프롬프트를 어떻게 쓰고, 어떤 스킬을 쓰느냐에 다르겠지만,
Claude code와 Codex 각각의 미묘한 기능차이가 꽤 뚜렷한 것 같다.

이번에도 따로 어떠한 파일도 제작하지 않은 채
프롬프트만 가지고 시작했다.

하지만 여기서 저의 실수..

이전에 포트폴리오 제작용으로 만들어 둔 코드 폴더에
별도의 프로젝트 폴더를 생성하지 않고 그대로 작업을 진행한 것...ㅜㅜ
① 프로젝트가 분리되어 있지 않아 별도로
폴더를 나눠 달라고 요청해야 하는 번거로움이 발생
② 이후 프로젝트를 체계적으로 관리하기 위해서도
처음부터 폴더를 분리해 작업하는 것이 중요하다!!

여튼 Claude는 이러한 제 요청에..

이런 결과물을 만들어줬다.

✅ 이미지는 마음에 든다. 꽤 귀여움!

✅ 흔들면 눈이 커지고, 클릭하면 눈웃음 짓는 것이 귀엽다

❎눈꺼풀이 징그럽다. 눈꺼풀이 가오나시마냥 눈 위아래에...

❎ 위젯 형태가 아닌 브라우저 형태로 만들어줌

이를 바탕으로, 수정사항을 클로드에 다시 요청했다.

이렇게 하니 화면에 둥둥 떠다니는 위젯 형태로는 만들어졌는데,

클릭하면 갑자기 위젯이 꺼지고, 위젯 이동시 지지직 하는 문제가 생겼다.

이것 또한 수정 요청을 하니 제대로 반영은 되었다.

그러나 또 문제~...

내가 원했던 것은 컴퓨터에서 클릭하거나 타이핑하는 등

사용자의 활동이 감지되면 위젯이 깨어 있는 기능이었다.

하지만 Claude가 구현한 버전은 컴퓨터를 사용하고 있는지와 관계없이

위젯 자체를 조작하지 않으면 계속 눈을 감고 있는 방식이었다.

즉, 사용자의 컴퓨터 활동이 아니라 위젯과의 직접적인 상호작용만 감지하고 있었던 것!!

여기서...클로드를 다른 데에도 썼더니

크레딧을 다 써버려서 Codex로 넘어가 이어 작업했다.

여전히..조금 부족한 나의 프롬프트

그래도 뭔가 쓰면 쓸 수록

내가 구현하기 원하는 기능과 범위를 명확히 제한할 수록

크레딧도 아끼고... 시간도 절약할 수 있다는 걸 느끼고 있다.

이번엔 내가 원하는 대로 모든 기능이 구현되었다!!

이후에는 깃헙에 저장소를 만들어 두고, 배포 파일을 업로드 해달라고 부탁했다.

파일을 직접 올리는게 시간을 절약하는 방법이겠지만...

깃헙을 사용한지 약 1~2주... 어떤 파일을 어떻게 올려야 하는지 아직 잘 모르겠어서

그냥 코덱스에게 요청하고 있다.

배포파일

Release everythingeverywhereallatoncepetrock v.0.0.1 · inaeichoi/everythingeverywhereallatoncestone

[Pet Rock Widget] Out of all the timelines, you got the one where you have a pet rock. Pet it → it smiles :) Shake it → it panics :(

github.com

배포 파일!!

배포 파일의 zip 파일을 다운받은 뒤 압축을 풀고,

windows 배치파일을 키면

위젯이 실행된다!

(window만 가능, 맥북은 안됨)

이용해 보신 분이 있다면...

댓글로 후기 부탁드립니다..ㅎㅎ

[UNIKER 1기] 비전공자 개발일지(2) | 화면별 상세 PRD 작성, 피그마 와이어프레임 제작, GITHUB 수정 w. 코덱스

인애_ — Sat, 11 Jul 2026 16:52:27 +0900

이전 이야기

지난주까지 기본 기획과 PRD 작성을 마쳤다.

이번 주에는 화면별 상세 PRD를 구체화하고, 피그마로 화면별 와이어프레임을 제작했다.

이번 주 한눈에 보기

사용 도구: 코덱스(PRD 작성), 클로드(와이어프레임 제작), 피그마
산출물: 화면별 상세 PRD, 피그마 와이어프레임 + 프로토타입 Flow
핵심 인사이트: 도구를 역할별로 나눠 쓰면 토큰은 아끼지만 맥락 공유가 끊긴다 / 디자인 일관성 유지는 클로드가 더 안정적이었다

1. 화면별 상세 PRD 구체화
PRD 상세화, 파일 나누기

기존에는 서비스 전체 개요 PRD만 작성했다면, 이제는 화면 단위로 PRD를 나눠 작성하기로 했다.

우리 서비스는 크게 아래 세 화면으로 구성된다.

친구 목록 / 친구 추가
채팅 목록 / 채팅 생성
채팅 화면

나는 이 중 친구 목록 페이지를 맡아 구체화했다.

[AS-IS] 채팅 화면 PRD

- 채팅 헤더 (참여 멤버 표시)
- 메시지 리스트
- 입력창
- 전송 버튼
- 사용자 메시지 즉시 표시
- AI 입력 중 상태
- AI 생각 중 상태
- 채팅방 생성 직후 기본 메시지 표시
- 메시지 저장과 복원

기존 PRD는 화면에 어떤 요소가 있는지 나열하는 수준에 그쳤다.

여기에 지난 강의에서 배운 아래 프레임을 적용해 코덱스에게 화면 PRD 상세화를 요청했다.

첫 화면: 서비스 목적과 입력값
결과 화면: 사용자가 판단할 정보
실패 상태: 추천 없음, 오류, 미선택
다시 시도: 조건을 바꿔 다시 실행

별다른 설명 없이 요청했을 뿐인데, 코덱스가 알아서 위 프레임을 반영해 문서를 구체화해줬다.

진행 과정을 보니 기존에 작성해둔 상위 문서(README, PRD, Agent 파일)를 참고해 흐름을 짠 것 같았다.

코덱스는 하나의 프로젝트에 로컬 파일을 연결해두면 새 채팅창에서도 해당 프로젝트 파일을 계속 참고한다. 덕분에 이전 작업 내용을 매번 설명하지 않아도 되고 토큰도 아낄 수 있어서 정말 편했다.

코덱스가 작성해준 상세 화면별 PRD를 검토하고, 수정할 부분을 다시 요청해 화면별 PRD 작성을 마무리했다.

PRD를 읽다 보니 상태별(입력 중, 오류 메시지 등) 와이어프레임을 따로 만들어야 하는지 궁금해져서 와이어프레임 제작 방법도 함께 물어봤다.

그랬더니 UI 흐름도 만드는 방법도 알려줬다...

이렇게나 똑똑했다고...

2. 피그마로 PRD 기반 와이어프레임 만들기
Claude + Figma 연동하기

화면별 PRD를 구체화했다면 다음 단계는 와이어프레임 제작이다.

원래는 코덱스에 피그마 플러그인을 설치해 와이어프레임을 만들려고 했는데, 계정 관리자인 유니커/DAY1컴퍼니 쪽에서 아직 해당 플러그인을 승인하지 않은 상태였다.

유니커 운영매니저님께 승인 여부를 문의해두고, 그 사이에 개인 계정 클로드로 와이어프레임 제작을 진행했다.

1) 서식 세팅하기

AI에게 와이어프레임 제작을 요청하기 전에, 참고할 서식과 기본 요소를 먼저 세팅했다. 요즘 AI가 알아서도 꽤 깔끔하게 만들어주지만, 디자인 요소를 뺀 와이어프레임이라도 최대한 정돈된 레이아웃을 유지하고 싶었다.

아이콘은 피그마 커뮤니티에 공개된 리소스를 활용해 미리 페이지에 배치해뒀다.

피그마는 사용자들이 다양한 아이콘·UI 리소스를 커뮤니티에 공유해두기 때문에 필요한 요소를 쉽게 가져다 쓸 수 있다는 게 큰 장점이다.

이 중 하나를 골라 팀 피그마 페이지에 추가하고, 원하는 깔끔한 디자인으로 예시 페이지를 만들어뒀다.

2) 클로드에게 와이어프레임 제작 요청하기

클로드에게 피그마 페이지, PRD, README 파일을 주고 와이어프레임 제작을 요청했다.

글씨체·여백·색 등은 미리 만들어둔 기본 서식을 참고하도록 요청했고, 컴포넌트 구성이나 파일명 설정도 알아서 처리해달라고 했다.

결과물: 폰트가 잘 적용됐고, 미리 만들어둔 아이콘도 잘 들어갔으며, 텍스트·컴포넌트도 겹치지 않고 깔끔하게 만들어졌다.

생성된 화면을 하나씩 확인하며 수정이 필요한 부분을 정리한 뒤 다시 클로드에 전달해 수정을 요청했다. 또한 피그마 프로토타입 기능으로 화면 간 Flow도 함께 연결해달라고 요청했다.

Flow를 연결해두니 실제 화면이 어떻게 이어지는지, 사용자 흐름이 어떻게 구성되는지 한눈에 확인할 수 있어 편리했다.

실무에서 이 기능을 어느 정도까지 활용하는지는 아직 잘 모르겠지만, 피그마에 AI나 API를 연동해 프로토타입을 더 효율적으로 활용한다는 이야기도 들어본 것 같다. 나중에 시도해봐야지..

이 과정을 팀원들도 모두 거치면서 페이지별 PRD와 와이어프레임 제작을 완료했다.

작업하며 얻은 인사이트

1. AI 도구를 혼용하면서 느낀 점
- 이번에 코덱스로는 PRD 작성, 클로드로 와이어프레임을 제작했는데, 역할을 분담하니 산출물 생성에 필요한 토큰을 분산해서 사용할 수 있어 좋았다.
- 하지만 두 AI가 서로의 작업 내용을 공유하지 않기 때문에 수정 사항이나 디자인 요소를 다시 전달해야 하는 경우가 자주 발생했다.
- 토큰을 분산해서 사용하니 토큰 관리 측면에서는 효율적이었지만, 작업의 연속성과 맥락 유지 측면에서는 아쉬움이 있었다. 앞으로도 AI를 역할별로 분리해서 사용하는 것이 좋은 방식인지에 대해서는 조금 더 고민해 볼 필요가 있다고 느꼈다.

2. 와이어프레임은 누가 더 잘 만들까?
- 이후 코덱스에서도 피그마 연동이 가능해져 동일한 작업을 진행해 보았다. 기존 디자인 서식을 유지해 달라고 요청했지만, 글꼴, 자간, 색상 등 세부 스타일은 반영되지 않는 경우가 있었다.
- 프롬프트를 더 구체적으로 작성하면 될 것 같긴 하지만 디자인의 일관성을 유지하거나 기존 스타일을 반영하는 부분에서는 클로드가 더 안정적이라는 인상을 받았다.

3. 3주차 멘토링 정리

팀원들이 만든 나머지 PRD를 합치고 와이어프레임도 마무리한 뒤, 궁금한 점을 모아 3주차 멘토링을 진행했다.

멘토링을 요약해보자면 다음과 같다.

1. PRD 작성
- PRD는 하나의 문서에 모든 내용을 담기보다 전체 구조와 핵심 내용만 담는 것이 좋음
- 기능별로 spec/ 폴더를 만들어 chatting.md, user.md처럼 세부 문서 분리
- 문서가 길어졌다면 AI에게 구조를 개선하도록 요청하는 것도 좋은 방법
- 불필요한 내용을 제거하기사소한 작업도 AI에게 맡기되, 최종 검수는 사람이 꼼꼼하게 진행하는 것이 중요

2. Agents 활용
- 메인 시스템 프롬프트는 지나치게 길어지면 성능이 저하될 수 있음
- 강한 제약이나 규칙이 필요한 경우에는 메인 프롬프트뿐 아니라 Agent 프롬프트도 함께 관리하는 것이 좋음

3. 와이어프레임과 디자인
- 피그마에서 디자인한 결과물은 코덱스와 연동하여 활용할 수 있음
- 다만 현재 기준으로는 코덱스가 디자인을 100% 정확하게 재현하는 것은 어려움
- 피그마 연동 품질은 스킬(프롬프트)을 얼마나 정교하게 작성하느냐에 크게 영향을 받음
- 한 번에 전체 화면을 수정하기보다 화면 단위로 작업을 요청하는 방식이 더 안정적
- 프로젝트 규모가 커진다면 디자인 시스템을 먼저 구축하고 AI가 이를 참고하도록 하는 방식도 고려

4. 데이터 저장 방식
- 서버와 데이터베이스를 활용하는 방식이 가장 이상적
- 간단한 프로젝트라면 브라우저 스토리지를 사용하는 것도 현실적인 선택지
- 구현은 쉽지만 데이터가 삭제될 수 있다는 단점
- 여러 저장 방식을 AI에게 제안받고 프로젝트 목적에 맞게 선택하는 것도 좋은 방법

5. Gemini API 연동
- LLM API는 시스템 프롬프트와 사용자 프롬프트를 함께 전달하는 방식으로 동작
- 페르소나, 응답 규칙, 최근 대화 등을 함께 전달해 AI의 행동을 제어할 수 있음
- AI에게 API 구조를 Markdown 문서로 정리하거나, 페르소나 수정 위치를 설명하도록 요청하면 이해하기 쉬움
- Agent SDK는 메모리 활용과 복잡한 작업 처리에 강점이 있어, 향후 고도화 단계에서 검토해 볼 만한 선택지

우리가 궁금한 점에 대해 너무 잘 설명해주셨고, 진행도 원활히 되고 있는 것 같다고 해주셔서 너무 안심이 되었다..ㅎㅎ

이런 내용에 맞춰서, 다음주에는

(1) 프론트 개발(와이어프레임 기반 프로토타입 제작)

(2) 백엔드 개발(API 학습, 연동)

(3) 디자인 md 제작

으로 역할을 나누어 진행하려 한다.

그럼 다음주에 계속...

바이브코딩으로 왁뿌볼 위젯을 만들어보자 | 비전공자 개발일지 외전

인애_ — Sun, 5 Jul 2026 16:41:47 +0900

최근 서비스 개발로 AI를 사용해보다가
내 생각보다 개발 지식과 어려운 내용이 많이 들어가는 것 같아
환기를 위해 아주아주 간단하고 귀여운 서비스를 만들어봤다

그것은...왁뿌볼 위젯

완성본부터~
클릭하면 깨지는 버전, 타이핑하면 깨지는 버전 둘 다 만들었다.

이건 만드는데 30분도 안걸린 것 같고,
그마저도 AI가 일을 하길 기다리는게 절반 이상이었다.
개발 과정이랄 것도 사실 없지만 그래도 써보자면 다음과 같았다.

기획 의도
왁뿌볼? 크런치 슬랑이? 너무 비싸고 냄새난다

요즘 내 알고리즘을 장악한 왁뿌볼과 슬랑이
나도 어렸을 때 슬라임 같은 것들을 좋아했던 터라
동묘에 가서 두 개 정도 샀었다

문제는...냄새가 너무 심해서
만지고 나면 손을 꼭 씻고 싶다는 거!!!
그리고 요즘 말랑이 가격이 너무 비싸졌다.
난 저것들을 2000~3000원에 샀는데 요즘 인기있는 건 만 원도 넘는다더라..

그래서 할 일을 할 때 뭔가를 부수는 만족감과 청각적 만족감을 주면서도,
부담은 없는 나만의 왁뿌볼 위젯을 만들기로 했다.

코딩 과정
타이핑하면 깨지는 왁뿌볼 만들기 w. 코덱스

진짜 가볍게 생각하고 시작했어서 처음 코덱스에게 요청한 것은

진짜진짜 간단했다.
앱도 아니고,,,웹페이지도 아니고,,,
이걸 뭐라고 불러야 할지도 모르겠어서 위젯이라고 했는데
결과물을 보니 위젯이 맞았던 것 같다

다만 코덱스가 너무 과하게..;; 위젯을 기획해서
이런 저런 기획 내용을 다 빼고 심플하게
왁뿌볼과 소리 기능만 남겨달라고 했다.

AI가 왁뿌볼이란 걸 알까? 이미지도 안주고
텍스트만 쳤는데 이걸 이해할까? 반신반의 했는데

오... 꽤 그럴듯한 왁뿌볼 이미지를 만들어줘서 놀랐다.
실행을 해보았는데, 문제가 있었다.

1. 이미지 테두리에 초록 누끼가 제대로 따지지 않았다.
2. 깨지는 소리에 기계음이 많이 났다. 왁뿌볼을 깨는 소리가 아니라 기계음을 친 느낌..?
3. 서서히 왁뿌볼이 깨지는게 아니라 일정 타이핑이 누적되면 한 번에 깨졌다.

그래서 이런 식으로 수정 요청을 했다.
내가봐도 프롬프트가 개발 전문 지식이라곤 1도 없지만
그래도 AI가 잘 알아들었으면 됐다..ㅎㅎ

수정본을 보니 나머지는 잘 반영이 되었는데 소리가 문제였다.
기계음으로는 아무리 해도 왁뿌볼과 비슷한 소리를 낼 수 없었다.

그래서 인터넷에서 효과음 음원을 무료로 받아 코덱스에게 주었다.
다만 음원은 연결된 음이기 때문에, 음원에서 소리가 나는 구간을 나눠
랜덤으로 재생될 수 있게 해달라고 요청했다.

너믜너믜 똑똑하다...
(소리와 이미지 등 여러 번의 테스트와 수정을 거친 후)
아주 손쉽게 완성!!!

타이핑하면 깨지는 왁뿌볼

완성도가 내 기대보다 훨씬 잘나와서
배포까지 하고 싶었다.

그래서 깃헙 저장소를 하나 파고 파일을 올려달라고 요청했다.

너무 똑똑해...
이렇게 첫 번째 타입 왁뿌볼 완성

코딩 과정2
클릭하면 깨지는 왁뿌볼 w. 코덱스

아주 만족하며 쓰던 와중...문제가 있었다
생각보다 위젯이 거슬린다는 것

생각없이 블로그 글을 쓸 때는 괜찮았는데
ppt 작업을 한다거나, 일을 할 때는
이 소리가 아주 귀찮았다.

일할 때 스트레스 받으면 잠깐 만지고 노는게
이런 말랑이류의 묘미인데!!

그래서 일을 하다가 스트레스 받을 때
누르고 안정을 얻는 클릭 버전도 만들었다.

코덱스의 토큰을 아끼기 위해
다른 채팅창을 팠다
사실 앞 버전 만들다가도 토큰을 다 써서
몇 번 기다렸다..ㅎ

코덱스의 좋은 점은

컴퓨터 내 파일과 연동해놓은 프로젝트 파일을 만들 수 있어서

다른 채팅창을 파도 프로젝트 설명을 다시 할 필요 없이이전 작업을 이어서 할 수 있다!

오타 난발의 프롬프트도 잘 보듬어 주어 고맙다...

클릭 버전은 진짜 이 한 번의 채팅으로 완성되었다.
전 버전에서 소리에 많은 토큰을 썼기에
이번에는 소리 느낌..? 설명을 처음부터 줬다.

그랬더니 아주 만족스러운 결과가!!

바로 깃헙에 올리고
메인 브랜치로 통합시킨 뒤

배포 파일을 만들었다!!

Release wackppu-ball-clickandtype · inaeichoi/wackppu-ball-widget

Wakppubol breaks whenever you click or type

github.com

배포 링크는 위와 같다.

1. 클릭 버전을 원하면 위의 것을,
타이핑 버전을 원하면 아래 것을 다운

2. zip 파일 압축을 해제한 뒤 run-widget/run-click-widget 실행

처음엔 이 화면이 나오는데 실행을 누르면 된다. 악성코드 안넣었어요...안심해주세요...

3. 왁뿌볼 즐기기!!!

진짜 별거 없는 위젯 개발기..ㅎㅎ
내딴엔 꽤 복잡한 서비스를 만들다가
이렇게 딸깍하면 나오는 위젯을 만드니
아주 재미있었다.

다음에 또 재밌는거 만들어야지

위젯 사용 후기
개발 훈수 환영합니다

[UNIKER 1기] 비전공자 개발일지(1) | 서비스 기획 초안, CODEX로 GITHUB 세팅하기

인애_ — Tue, 30 Jun 2026 17:47:30 +0900

1주차 멘토링
현직 개발자에게 받아보는 서비스 피드백과 조언

UNIKER의 본격적인 활동이 시작되었다!

1~2주 동안에는 기획 단계를 진행하면 되는데,

짧게 덧붙이자면

우리의 아이디어는, 'oo정병'이라는 단어의 보편화에서 시작했다.

취업, 연애, 우정 등등... 요즘 2030은 이런 어렵고 고통스러운 생각에

휩쓸릴 때, 이걸 정병이라고 칭한다.

"정병 온다" 불안과 희화화 사이의 외침… 정신질환은 어떻게 밈이 됐나-문화ㅣ한국일보

정병, 취준정병, 외모정병 등 정신적 고통을 자조적 유머로 표현하는 신조어가 청년 세대에서 확산 중이다. 우울감과 불안을 공감하며 사회적 연대도 느끼지만, 정신질환 비하 및 남용 우려도

www.hankookilbo.com

그리고 이런 불안한 일이 생길 때, 친구들이 자주 찾는 것은

친구들의 단톡방, 혹은 무조건적인 위로를 해주는 AI.

그래서 우리는 불안감이 엄습할 때마다

회피형, 불안형, 안정형 캐릭터를 가진 AI와 채팅을 할 수 있는

서비스를 만드려 했다.

다시 멘토링 이야기로 돌아가서!

첫 주 30분 멘토링을 통해 우리가 초안으로 작성한 PRD(서비스 소개서)를 보여드리며

서비스 구현 가능성에 대해 조언을 부탁드렸고, 개발 과정과 CODEX/GITHUB 활용법에 대한 이야기를 들을 수 있었다.

멘토링 내용을 정리하자면 하기와 같았다

1. 웹앱으로 먼저 시작하는 것이 현실적
- 서비스는 웹앱으로도 충분히 구현 가능
- 사용자 정보(쿠키 등)를 활용하면 앱처럼 운영 가능
- 처음부터 네이티브 앱을 만들 필요는 없음- 웹으로 MVP를 먼저 검증하는 것이 좋음

2. 앱 출시 시 고려사항
- iOS 개발은 맥북 필요 Windows에서도 웹 개발 및 테스트는 가능
- iOS 빌드/배포는 결국 Mac이 필요
- 애플 개발자 계정 비용 연 약 13만 원(99달러 수준)
- 이후 Android 확장 고려3. 기능 구현 난이도- 아이디어 자체는 어렵지 않음.
→ 기술적으로는 충분히 구현 가능한 수준

4. 개발 순서
- 추천한 개발 흐름설계 → 디자인 → 개발PRD(기획) 설계 문서 작성
Figma 디자인Codex에게 구현 요청 테스트 및 수정 Codex + Figma활용

방법 1
Figma 디자인 제작 Codex에게 "이 Figma대로 만들어줘"라고 요청

방법 2
브라우저를 제어하도록 사용Chrome에 Figma 로그인 Figma URL 전달 Codex가 직접 디자인를 읽고 구현처음에는 완벽하지 않을 수 있음.

5. MCP 활용
- MCP(Model Context Protocol)
- AI가 다양한 툴을 쉽게 사용할 수 있게 하는 프로토콜 Figma도 일부 MCP 지원 다만 Figma는 지원 범위가 제한적
- Codex Skill 만들기
- 반복 작업은 Skill로 정의

6. PRD와 문서 관리
- GitHub 안에서 문서를 잘 관리하는 것이 중요
- 예시: FEATURE/ AI_CHAT.md LOGIN.md CHECKLIST.md
- 각 기능마다 설명 요구사항 체크리스트를 작성
ㄴ 이유: AI는 대화가 길어질수록 일부 맥락을 잊을 수 있음(토큰 한계).
→ 문서를 함께 제공하면 맥락을 유지하면서 작업 가능

이를 토대로

- 협업 툴: GITHUB

- 디자인/프로토타입: FIGMA

- 개발: CODEX

- 배포: VERCEL

이렇게 해보려 한다.

어플 출시보다 웹앱으로 먼저 만들어서 배포해보는 것을 목표로 두었고,

멘토링 덕분에 깃헙과 코덱스 각각의 목적, 개발 과정에 대한 이해도 잘 되었다.

문제는 흐름만 알았지, 구체적으로 뭘 어떻게 해야하는지는 이제 찾아봐야 한다는 것...

다행히 이 프로그램은 패스트캠퍼스의 강의를 모두 들어볼 수 있도록

수강권을 제공해주어 강의를 들어보면서 개발을 해보려 한다.

또, 멘토링 후 GPT와 대화 후 뽑아낸 개발 과정

1. Github 저장소 생성 및 기본 세팅
2. PRD 보완 및 작업 목록 작성
3. 피그마에서 화면 설계
4. Codex에게 기능 단위로 개발 요청
5. 테스트 및 배포
6. 배포

이번 주차에는 2번까지 하는 것을 목표로~!

CODEX로 GITHUB 세팅하기
개발 협업 저장소/공간 만들기

멘토링을 통해 이해한 바

GitHub의 용도 (1)
여러 명이 함께 서비스를 개발할 때, 각자 작업한 기능을 공유하고 코드의 변경 이력을 관리하기 위해 사용한다.

GitHub의 용도 (2)
Codex로 개발할 때는 하나의 채팅창만 계속 사용하는 것보다 GitHub를 함께 활용하는 편이 효율적이다. 긴 대화로 인해 토큰 사용량이 늘어나거나 초기 설정이 누락되는 문제를 줄일 수 있고, 작업 내역도 안정적으로 관리할 수 있기 때문이다.

때문에, 팀원들이 함께 활용하기 위한 GITHUB 저장소를 먼저 세팅했다.

근데...그거 어떻게 하는데요

ㄴ 이것도 몰랐을 정도로 "개발"의 ㄱ자도 몰랐던 사람...

모를 땐 CODEX의 힘을 빌리자

우선 아무것도 안 한 상태로 CODEX에게 PRD를 주고 내 깃헙 링크를 주며

세팅을 해달라고 해보았다.

결과는 README, 워크플로우, 이슈 템플릿 등등..파일을 만들어주었다.

저장소를 아직 생성하지 않은 상태여서 CODEX가 직접 깃헙에 파일을 올리지는 못하길래,

알려준 저장소 생성 옵션대로 내 저장소를 만들었다.

저장소를 만든 뒤, 이어서 세팅을 부탁했다.

그랬더니 작업해준 결과

1. README: 서비스 소개, 기술스택, 실행법, 배포주소를 담은 문서

2. PRD: 어떤 기능을 구현해야 하는지 알려주는 명세서, 서비스 설계도

3. TEAM_WORKFLOW: 팀 단위로 작업할 때 지켜야 할 개발 규칙

이슈 티켓도 알아서 만들어줬다.

이걸 얼마나 잘 활용할지 모르겠지만

과정을 거치면서 우리 팀에 맞는 방식대로 활용하면 될 것 같다.

PRD 구체화하기
상세 기능 설정

회의 후, 들어가면 좋을 기능/제외해야할 기능을 바탕으로 prd를 구체화했다

요약하자면 이런 내용

1. 한 줄 요약

대학생이 실제 친구 단톡방에 감정을 털어놓기 전, AI 친구들과 먼저 단톡처럼 대화하며 공감과 리액션을 받을 수 있는 감정 배출 서비스

2. 목표

상담이나 문제 해결이 아닌 즉각적인 공감과 편들기 제공 실제 친구에게 말하기 부담스러운 감정을 먼저 풀 수 있는 공간 제공 실제 단톡방처럼 여러 AI가 서로 대화를 이어가며 반응하는 경험 구현

3. 핵심 기능(MVP)

(1) AI 친구 관리
기본 AI 3명 제공 안정형 불안형 회피형 AI 친구 추가 가능 이름, 프로필 이미지, 성향 수정 가능 같은 성향의 AI도 여러 명 생성 가능
(2) 채팅방
AI 1~3명 선택 개인톡 또는 단체톡 생성 채팅방 생성 직후 AI가 먼저 인사 메시지 전송 이후 사용자가 대화 시작
(3) 대화 방식
AI들은 랜덤 순서로 답변 뒤에 답하는 AI는 앞 AI의 말을 이어받음 실제 단톡처럼 AI끼리 상호작용 채팅방별 대화 맥락 지속 저장

4. 안전 정책

위험한 내용(자해, 타해, 보복 등)이 감지되면
일반 캐릭터 반응보다 안전 안내를 우선 제공

업데이트한 내용을 토대로 CODEX에게 다시 GITHUB에 업데이트를 해달라고 했다.

이제 다음으로 할 것은...

유저 플로우와 와이어프레임 만들기가 아닐까..?

AI가 디자인을 해줄 수 있다고 듣긴 했지만, 특유의 AI 디자인 깔이 마음에 들지 않아서..

이건 어떻게 해야할지 다음 멘토링에서 또 조언을 구해봐야겠다.

혹시 이 글을 보고 훈수나 조언이 있다면..

해주세요 적극적으로 받아들이겠습니다!

[KT 나스미디어] 현장실습 플랫폼 운영 지원 후기 (서류 합격/면접 불합격)

인애_ — Thu, 25 Jun 2026 16:37:42 +0900

나스미디어
KT그룹 계열의 디지털 마케팅 플랫폼 기업으로,
광고주와 매체를 연결하는 국내 대표 디지털 미디어랩 회사

여름방학~막학기에는 ipp 현장실습으로 학점을 채울 예정이었어서
학교에 올라온 공고를 보다가, 나스미디어를 발견했다.

미디어 랩사를 한 번쯤 경험해보고 싶었는데,
나스 미디어가 우리 학교에도 올라왔다니!
싶어 바로 지원했다.

어떤 부서를 선택할지 고민이 되었는데,
이전 인턴 경험을 살릴 수 있는 플랫폼 사업부로 지원 결정
(TO가 한 명이라 걱정되었지만... 되면 되고, 안되면 되는거 하자. 라는 마음으로...)

나스미디어 플랫폼 운영
전통적인 광고대행 업무보다 애드테크(Ad-Tech) 플랫폼을 기획·운영하고
광고 성과를 데이터로 최적화하는 조직

플랫폼 부서 중에서도 총 3팀이 있었는데,
그 중 제일 잘 맞겠다 싶은 곳으로 지원했다.

서류 과정

서류를 쓸 때 제일 참고한 것은
나스미디어에서 만들어주신 (1) 직무 설명 노션 페이지와 (2) NAP 홈페이지였다

특히 노션 페이지가 너무너무 잘되어 있어 어떤 일을 맡겠다~ 어떤 역량을 강조해야겠다~를 쉽게 파악할 수 있었다.
동시에 지원 과정에서부터 너무 친절해서 꼭 여기서 일을 하고 싶다는 생각이 들었다.

스펙
전공: 인서울 문과 전공, 경영학과 부전공
언어: 토익 960, 토익 스피킹 170(AL)
자격증: GTQ
활동 경력: 디지털 대행사 플랫폼 AE 9개월, 마케팅 대외활동 2회, 광고 마케팅 동아리 1년 반(부회장 역임)
수상 경력: 종대사 광고 공모전 3회 수상
해외연수: 체코 교환학생 6개월

자격증이 직무와 관련이 없지만... 문과 직무에서 자격증보다는 경험이 훨씬 더 중요한 것 같다.
그리고 나머지는 다 직무 설명 노션을 보고 유사한 경험만 추려서 썼다.

다른 후기들을 보니 포트폴리오는 거의 필수라고 하던데,
우리 학교에는 포폴을 낼 수 있는 칸이 따로 없어서 내지 않았다.

자기소개서
1. 성장과정 중 의미있던 경험, 경험에서 배운 것
> 마케팅 대외활동을 하면서 콘텐츠 성과를 보고 매체 전략을 바꾼 경험

2. 수행 직무를 희망하는 이유, 적합한 근거
자료를 보고 논리를 세워 설득하는 것에 대한 흥미
> 데이터 자료를 분석해 논리를 세워 크리에이티브를 내고,
기업 마케팅 방안에 녹여내서 대상을 받았던 공모전 경험

3. 공동의 목표를 위해 타인과 협력한 경험
> 플랫폼 AE 인턴으로 일하며 발생한 과중한 업무량을
팀원과 구글 스프레드 공유시트를 통해 해결했던 경험

4. 현장실습을 통해 이루고자 하는 목표
> 데이터 분석 역량을 기르고 싶다.
데이터로 광고 시장을 읽고 사람과 사람을 잇는 설득력을 만들고 싶다.

이런 저런 일정으로 급하게 썼어서 지금보면 전체적으로 아쉬운 점이 더 많은 자소서이다..
고칠 점: 다음부터는 급해도 꼼꼼히 알아보고 쓰기

서류 합격!

다른 학교 현장실습에도 많이 올라오는 기업이고,
자소서도 아쉬운 부분이 너무 많아 기대를 안하고 있었는데,,

서류 합격이 되었다
ㅠㅠㅠ

제대로된 대면 면접이 너무 오랜만이라 생각만 해도 긴장되기 시작

면접 준비 (질문 리스트)

면접 후기들도 찾아보고, 직무 설명 노션도 보며 예상질문 리스팅
어려운 질문보다는 정석적인 질문이 많은 것 같다.
다음은 준비해간 질문 리스트

1. 자기소개
2. 지원동기 (플랫폼 부서 중 왜 그 팀을 지원했는지)
3. 성격의 장점과 단점
4. 리더인지 팔로워인지
5. 인턴 어떤 일 했는지
6. 엑셀 실력/경험
7. 제일 기억에 남는 경험
8. 실패 경험/역경
9. 이외 경험 썰 (예비용...)
10. 반복적인 업무 괜찮은지
11. AI 활용 경험
12. 어떤 부서인지 설명
13. 어떤 업무를 하고 싶은지, 어떤걸 기대하고 왔는지
14. 나스미디어 기업 이슈, 최근 이슈
15. N년 뒤 나의 모습
16. 마지막으로 하고 싶은 말

지금보니 많이 준비하긴 했는데, 다 여기 내에서 나와서 준비하길 잘한 것 같다.
준비는 흐름만 정해두고 내 입에 맞게끔 연습했다.

면접

오전 수업이 있었어서 수업 갔다가 강남 카페에 가서 2시간 정도 기다렸다.
카페에서 옷을 갈아입었는데, 다 '저사람 면접 가는군'이라고 생각했을 듯

면접장에는 30분 일찍 갔는데 다른 사람들도 많이 와 있었다.
넉넉잡아 가는 것을 추천.

옷은 다들 정석 정장~비지니스 캐주얼 옷을 입고 있었다.
친구들 후기나, 면접 후기에서 다들 칼정장을 입고 있었다길래 나도 비슷하게 준비해서 갔다.
근데 비지니스 캐주얼로 가도 너무 괜찮을 듯 함.

인사팀 분이 면접 진행을 친절하게 설명해주시고,
사내 카페 음료도 준비해주셨다.
나스미디어는 전반적으로 채용 과정이 너무 호감이었다...

다음은 면접 질문 (면접은 다대 다, 팀장님 2분, 인사팀 1분 있는 것 같았다)

1. 자기소개
2. 해당 부서가 어떤 일을 하는지 아는지?
3. 데이터 활용 경험(생성형 AI, 분석 도구 등 활용)
4. (위의 질문과 연계하여) 프로젝트를 진행하며 힘든 일은 무엇이었는지, 어떻게 해결했는지
5. 반복 업무 괜찮은지, 어떻게 일하는지
6. 힘든 업무가 주어진다면 어떻게 할 것인지
7. 마지막으로 하고 싶은 말

예상질문 안에서 다 나왔지만, 그래도 떨렸다.
나름 잘 대답했다고 생각했는데도, 옆 지원자분들이 말을 너무 잘하셔서 너무 위축되었다.
그래도 막내 팀원의 필수 자질은 초롱한 눈과 생기라 마인드컨트롤하며... 열심히 미소짓고 끄덕였다.

면접 보고 나와서 입 밖으로 튀어나온 말 :
음~ 나 안뽑겠는데?

내가 생각해도 내 옆 지원자분을 뽑고 싶었다.
면접까지 오면 스펙은 다 비슷하고 어떻게 말하느냐, 어필을 얼마나 잘 하느냐로 갈린다고 생각하는데
말을 정리하는 연습을 많이 해야겠다.

결과는 면접을 본 2일 뒤에 나왔고,

예상했다시피

탈락했다 ㅠ

뭐... 이 시간에 다른 경험을 더 열심히 채우자!

좋은 지원 경험이었다..

[UNIKER 1기] 발대식 후기 | 비전공자도 앱 서비스를 만들 수 있을까?

인애_ — Thu, 25 Jun 2026 16:34:21 +0900

UNIKER 활동에 대해

AI의 활용 역량이 중요해지기도 하고, 바이브 코딩이 궁금해서
지원했던 대학생 AI 크루 UNIKER 1기에 지원했다.

대학생 AI 크루 UNIKER

UNIKER는 서포터즈와 공모전의 장점만 모은 서포터즈형 AI 해커톤 프로그램이에요
서포터즈처럼 재미있게 활동하고, 공모전처럼 실제 결과물을 만들며,내 아이디어를 AI 서비스로 완성해볼 수 있습니다.

우선 당시 나의 배경:

개발 비전공자

대학 졸업작품으로 어플 기획(개발은 외주 맡김)만 해봄

AI 툴 이것 저것 찍먹 해보았지만,

개발 분야에는 활용해보지 않음

사실 서비스 개발을 바로 하기에 너무 배경이 없지만

공고에 비전공자도 아이디어가 있다면 AI툴과 교육을 통해
결과물을 만들 수 있다는 말에 과감히 지원했던 것 같다.

팀원 혹은 개인별 지원이 가능했고,
나는 팀원 3명을 모아 팀으로 지원했다!

발대식
웰컴키트, 진행 주제와 방식, 자기소개, CODEX와 GITHUB

발대식은 데이원컴퍼니 본사인 센터필드 WEST에서 진행되었다.

웰컴 키트!

샌드위치와 음료, 텀블러와 노트를 주셨다.

우선 활동에 대한 소개가 있었다.

이번 기수의 주제는 대학생활을 200% 재미있게 만들 아이디어를 주제로 서비스를 만들게 된다.

우리 조의 아이디어를 조금 스포해보자면...

우리는 요즘 대학생들이 스트레스를 받을 때 GPT 등

AI에게 감정을 쏟아놓는 현상과 관련된 서비스를 만들어보려 한다.

비전공자들로 구성된 팀이기에 욕심내지 않고 핵심 서비스를 재미있게!!

만드는 것에 집중해보려고 한다.

개별 자기소개 시간도 있었다

전공자도 있었고 비전공자도 있었는데,

그만큼 다양한 시각에서 서비스가 나올 것 같았다

무엇보다 전공 지식이 없어도 서비스를

만들 수 있다는 것 같아 괜히 든든한 마음이..

내 소개 페이지

사진은 저렇게 크게 들어갈지 몰랐지만...

나는 비전공자이지만 어플 서비스에 관심이 생겨 지원했었고,

이전엔 일을 무식하게 많이 했다면 이제는 워라밸을 지키며 효율성 있게

일하고 싶다는 의미에서 키워드를 저렇게 선정했다

10주 간의 커리큘럼!

처음에는 10주가 조금 긴가? 싶었는데

자세한 커리큘럼을 들으니 할게 너무너무 많았다

1~2주에는 기획 아이디어 확정

3~4주에는 1차 프로토타입 제작

5~10주에는 핵심 기능 완성, 테스트, 최종 QA

이런 과정으로 진행된다

모든 단계에는 강의와 피드백이 제공된다고 하여

많이 든든했다

그만큼 짧은 시간 안에 얻어갈게 많았으면 좋겠다!!

이날은 강사님이 오셔서

CODEX와 GITHUB에 대해 간단하게 알려주셨다

이 활동에서는 CODEX와 GPT 요금을 지원해줘서

활동 기간동안 최대한 이용해볼 수 있다는게 좋았다

CODEX 알아보기

두 가지 툴 모두 처음 써봐서 낯설었지만

빨리 배워야겠다는 생각도 들었다~

이 대외활동에는

1) 라이브 강의

2) 멘토님 멘토링

3) 패스트 캠퍼스 강의

와 같이 서비스 기획을 하는 데에 배울 수 있는

교육의 기회를 많이 제공해줘서

활동 기간 동안 열심히 배워봐야겠다

쩜팔팀!! 파이팅!!!

서비스 기획 과정은 다음 포스팅에서 ...