목업부터 다시 시작한 20Springs, 디자인을 실제 화면으로 옮긴 과정

세 AI에게 같은 일을 맡기다 개발을 멈췄다. 다시 시작할 때는 코드보다 내가 눈으로 확인할 수 있는 화면을 먼저 만들기로 했다.

약 2주간의 개발을 중단하고 처음부터 다시 시작하기로 했다. 첫 시도에서는 문서와 코드가 계속 생겼지만, 내가 만들고 싶은 서비스가 어떤 모습으로 완성될지는 직접 확인하기 어려웠다.

개발 지식이 부족한 상태에서 다음 기술을 선택하는 일보다 더 답답했던 것은 지금 만들고 있는 것이 맞는 방향인지 눈으로 판단할 수 없다는 점이었다. 그래서 두 번째 개발에서는 순서를 바꿨다. 코드를 먼저 만드는 대신 화면 목업을 만들고, 내가 이해하고 확인한 화면을 기준으로 개발하기로 했다.

와이어프레임으로 먼저 화면을 그렸다

나는 디자인에 대한 지식이 없었다. 하지만 거창한 디자인 결과물보다 무엇이 어디에 있어야 하는지 보여 주는 화면이 먼저 필요했다. Claude와 ChatGPT에게 20Springs를 만드는 이유와 필요한 기능을 설명하고, 처음부터 모든 기능을 담기보다 필수 화면을 중심으로 와이어프레임과 디자인 초안을 보여 달라고 요청했다.

처음 나온 화면을 그대로 사용하지는 않았다. 화면을 보면서 내가 생각한 서비스와 다른 부분을 찾았고, 메뉴와 정보의 순서, 제목과 버튼의 위치, 한 화면에 들어갈 내용 등을 계속 수정했다. 글로만 설명할 때에는 떠오르지 않던 질문이 화면을 보자 구체적으로 나타났다.

• 처음 방문한 사람에게 가장 먼저 보여 줄 내용은 무엇인가
• 자본, 배당과 후원의 흐름을 어느 순서로 설명할 것인가
• 숫자와 이야기를 한 화면에 함께 보여 줄 것인가
• 후원 기록과 커뮤니티는 어디에서 연결할 것인가
• 모바일 화면에서 반드시 남겨야 할 기능은 무엇인가

Claude와 ChatGPT가 만든 안도 서로 비교했다. 어느 하나를 그대로 고르기보다 각 결과에서 이해하기 쉬운 부분을 골라 다음 수정에 반영했다. 이전에는 같은 일을 여러 AI에게 맡긴 뒤 기술적인 의견까지 내가 결정하려고 했다면, 이번에는 내가 직접 판단할 수 있는 화면 구성과 사용 흐름에 비교 범위를 한정했다.

개발을 맡을 메인 도구로 Claude Code를 정했기 때문에, 최종적으로는 Claude에서 만든 디자인 초안에 선택한 내용을 모았다. Codex는 같은 화면을 다시 만드는 역할보다 빠진 내용이나 어색한 흐름을 검토하는 역할로 두었다.

디자인 파일을 전달해도 같은 화면이 나오지는 않았다

어느 정도로 정리된 디자인 파일을 내보내 Claude Code에게 전달하고, 이 모습과 같게 만들어 달라고 요청했다.

하지만 처음 구현된 화면은 기대한 디자인과 달랐다. 버튼의 크기, 여백, 카드의 배치와 글꼴의 느낌이 달랐고, 아직 더미 데이터가 들어간 화면이라도 디자인 초안과 코드 사이의 차이는 생각보다 컸다.

처음에는 디자인 파일을 첨부했는데 왜 그대로 만들지 못하는지 이해하기 어려웠다. 알아보니 파일을 참고 자료로 건네는 것과 디자인의 구조를 개발 환경에서 직접 읽고 연결하는 것은 다른 일이었다. 디자인 싱크 방법을 확인해 다시 연결하자 처음 만든 화면과 훨씬 가까운 결과가 나왔다.

이 과정에서 배운 점은 단순했다. AI에게 참고 이미지를 보여 줬다는 사실만으로 의도와 세부 규칙이 모두 전달되는 것은 아니었다. 어느 화면을 기준으로 삼을지, 구성 요소와 상태는 무엇인지, 무엇이 달라도 되고 무엇은 같아야 하는지를 함께 알려 줘야 했다.

화면을 비교할 때에는 다음 항목을 기준으로 확인했다.

1. 헤더와 메시지, 이동 방향이 맞는가
2. 개발한 화면이 목업의 구성과 흐름을 따르는가
3. 버튼을 누르면 어디로 이동하는가
4. 클릭한 다음 화면과 누른 화면이 부드럽게 이어지는가
5. 가장 여유가 적은 모바일 화면에서도 기능과 흐름이 유지되는가
6. 화면이 완성됐을 때 직접 보고 확인할 기준이 있는가

이 기준을 모두 해결한 것은 아니었다. 다만 와이어프레임과 실제 개발 화면을 나란히 놓고 차이를 확인할 수 있게 되면서, 무엇을 수정해야 하는지는 이전보다 훨씬 분명해졌다.

정지된 화면을 누르는 화면으로 바꿨다

디자인이 실제 화면과 비슷해진 뒤에는 화면을 보는 것에서 사용하는 것으로 작업 범위를 넓혔다. 버튼을 클릭했을 때 어디로 이동할지, 한 화면에 어떤 정보가 더 필요할지, 모바일에서 이동이 자연스러운지를 하나씩 확인했다.

첫 개발에서는 문서상으로 작업이 끝났다는 말만 보고 다음 단계로 넘어간 적이 많았다. 이번에는 눈으로 확인할 수 있는 결과를 완료 기준으로 삼으려고 했다.

서비스 설명
→ 와이어프레임과 디자인 초안
→ 내가 화면을 확인하고 수정
→ 메인 AI가 실제 화면으로 구현
→ 목업과 개발 화면을 비교
→ 클릭과 이동을 확인한 뒤 다음 작업

한 번에 완성하려고 하지 않고, 내가 확인할 수 있는 단위로 작업을 줄였다. AI가 기술적인 구현을 맡더라도 어느 화면에서 어떤 일이 일어나야 하는지는 내가 설명하고 확인할 수 있어야 했다.

눈으로 확인할 화면이 생기자 개발을 계속할 수 있었다

처음부터 와이어프레임을 만들고 실제 화면과 연결하는 방식은 이제야 서비스가 되어 가고 있다는 느낌을 줬다. 개발 기간이 줄었다고 말하기는 어렵지만, 지금 무엇을 고치고 왜 고치는지는 이전보다 더 분명했다.

나는 여전히 수익을 얻지 않고 서비스를 오래 운영하는 방법을 찾고 있었다. 모든 결정을 AI에게 맡기기보다, 내가 보고 고치며 확인할 수 있는 결과를 중심으로 개발을 진행하는 것이 오히려 개발을 멈추지 않게 하는 방법이었다.

이번에는 완성됐다는 문서상의 기록보다 직접 확인할 수 있는 화면을 기준으로 삼았다. 목업과 실제 화면을 나란히 비교하고 버튼을 눌러 보면서, 개발 지식이 부족한 나도 다음에 무엇을 고쳐야 하는지 설명할 수 있었다.

그렇다고 화면을 만든 것으로 서비스가 완성된 것은 아니었다. 다음에는 증권사 계좌의 데이터를 어떤 방식으로 가져와 20Springs에 보여 줄지 결정해야 했다. 데이터를 연결하려고 법인의 운영 구조를 살펴보면서, 나는 화면보다 먼저 해결해야 할 세무 문제를 발견하게 됐다.

20Springs 서비스

• 이전 글: 세 AI에게 같은 일을 맡긴 2주, 개발을 다시 시작한 이유
• 다음 글: 증권계좌 데이터를 연결하다 1인 법인의 세무 문제를 발견한 과정
• 전체 목차: 20Springs

이 글은 개발 경험이 없는 상태에서 AI 도구로 20Springs의 목업을 만들고 실제 화면으로 옮긴 개인적인 기록입니다. 소개한 작업 방식은 프로젝트의 구조와 사용하는 도구에 따라 다르게 적용될 수 있습니다.