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

 

이전 이야기

 

지난주까지 화면별 상세 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 문제를 해결하고, 폰트 적용 문제 해결, 디자인 세부 수정

정도가 될 것 같다!

 

 

다음주에 계속...