코딩을 모르는 내가 AI와 함께 앱을 만들기 시작한 방법
1편에서 이야기했듯이 나는 개발자가 아니다.
코딩을 배운 적도 없고, 프로그램을 직접 만들어본 경험도 거의 없다.
그런데도 Santiago Brain을 만들기 시작했다.
방법은 의외로 단순했다.
내가 직접 코드를 한 줄 한 줄 작성하는 대신,
내가 만들고 싶은 기능을 말로 설명하고 AI가 실제 개발 작업을 하도록 하는 방식이었다.
처음에는 이것이 정말 가능한지 나도 반신반의했다.
내가 사용한 도구는 Replit이었다
Santiago Brain을 만들 때 가장 중심적으로 사용한 도구는 Replit이었다.
Replit은 웹 브라우저에서 바로 프로그램을 만들고 실행할 수 있는 개발 환경이다.
예전에는 프로그램을 만들려면 컴퓨터에 여러 개발 도구를 설치하고, 코드 편집기와 서버, 데이터베이스 환경을 따로 준비해야 했다.
하지만 Replit에서는 이런 복잡한 준비를 상당 부분 줄일 수 있었다.
특히 내가 중요하게 본 것은 AI Agent와 대화하면서 개발을 진행할 수 있다는 점이었다.
나는 이런 식으로 요청했다.
오늘 화면을 만들어줘.
오늘 해야 할 일만 먼저 보여주고, 완료된 일은 기본 화면에서는 숨겨줘.
또는 이렇게 말했다.
목표 화면에서 진행률을 보여주고 싶다.
진행률은 필수 할 일 완료 개수를 기준으로 계산해줘.
내가 원하는 기능을 설명하면 AI가 코드를 만들고 화면을 수정했다.
물론 한 번에 정확하게 되는 경우는 많지 않았다.
처음부터 가장 어려웠던 것은 ‘정확하게 설명하는 일’이었다
AI가 코드를 만들어준다고 해서 개발이 저절로 되는 것은 아니었다.
오히려 처음에는 이런 문제가 자주 생겼다.
나는 분명히 “오늘 할 일”이라고 말했는데,
AI는 모든 할 일을 보여주기도 했다.
“상태를 한글로 보여줘”라고 했는데 일부 화면에는 여전히 waiting, in_progress 같은 영어가 남아 있었다.
“완료한 일은 숨겨줘”라고 했는데 다른 화면에서는 그대로 보이기도 했다.
이때 알게 된 것이 있다.
AI에게 개발을 맡길 때 가장 중요한 능력은 코딩보다 요구사항을 정확하게 설명하는 능력이라는 것이다.
예를 들어 처음에는 이렇게 말했다.
상태를 한글로 바꿔줘.
나중에는 이렇게 구체적으로 지시하게 됐다.
waiting과 pending은 ‘대기’,
active와 in_progress는 ‘진행 중’,
completed와 done은 ‘완료’,
paused와 on_hold는 ‘보류’,
cancelled와 canceled는 ‘취소’로 표시해줘.
사용자 화면에는 내부 영어 상태값이 직접 나오지 않게 해줘.
이렇게 지시하니 결과가 훨씬 정확해졌다.
앱의 뼈대부터 하나씩 만들었다
처음에는 거대한 AI 비서를 한 번에 만들려고 하지 않았다.
필요한 기능을 하나씩 추가했다.
먼저 오늘 화면을 만들었다.
그다음 목표를 만들었다.
프로젝트를 만들고,
할 일을 연결하고,
아이디어를 저장하고,
결정한 내용을 남길 수 있도록 했다.
조금씩 구조가 만들어지면서 이런 흐름이 생겼다.
목표 → 프로젝트 → 마일스톤 → 할 일 → 오늘 실행
처음에는 이 구조도 명확하지 않았다.
예를 들어 프로젝트와 목표의 차이가 애매했다.
할 일이 프로젝트에 꼭 속해야 하는지도 고민했다.
그래서 실제로 사용하면서 구조를 계속 바꿨다.
목표는 내가 이루고 싶은 결과로 정리했다.
프로젝트는 목표를 이루기 위해 실제로 추진하는 일로 만들었다.
마일스톤은 프로젝트 중간의 중요한 지점이다.
할 일은 실제로 내가 실행해야 하는 행동이다.
이렇게 정리하면서 앱의 구조도 조금씩 안정됐다.
데이터베이스라는 새로운 문제를 만났다
화면만 만드는 것으로 끝나지 않았다.
입력한 내용을 저장하려면 데이터베이스가 필요했다.
Santiago Brain에서는 Supabase를 사용했다.
처음에는 데이터베이스를 단순히 “자료를 저장하는 곳” 정도로 생각했다.
그런데 실제로 만들어보니 훨씬 복잡했다.
예를 들어 이런 문제가 있었다.
하나의 목표 아래 여러 프로젝트가 있을 수 있다.
하나의 프로젝트에는 여러 할 일이 연결될 수 있다.
어떤 할 일은 프로젝트가 없어도 목표에 직접 연결될 수 있다.
마일스톤에 연결된 할 일이 프로젝트 진행률에도 영향을 줘야 한다.
이런 관계를 제대로 만들지 않으면 진행률이 이상해지거나 같은 할 일이 두 번 계산되기도 했다.
그래서 단순히 데이터를 저장하는 것보다 데이터 사이의 관계를 어떻게 설계할지가 훨씬 중요했다.
삭제 기능 하나도 생각보다 어려웠다
앱을 만들기 전에는 삭제 버튼은 그냥 데이터를 지우면 되는 줄 알았다.
실제로는 그렇지 않았다.
예를 들어 프로젝트를 삭제한다고 해서 그 프로젝트에 연결된 할 일까지 모두 지워버리면 문제가 생긴다.
잘못 삭제했을 때 복원할 방법도 필요하다.
그래서 삭제 기능도 여러 단계로 나누게 됐다.
완료한 일은 다시 활성화할 수 있게 했다.
당장 보이지 않게 하고 싶은 것은 보관으로 처리했다.
삭제할 때는 확인 과정을 넣었다.
가능하면 휴지통에서 복원할 수 있도록 했다.
이 과정에서 나는 프로그램에서 “삭제”라는 기능 하나도 정책이 필요하다는 것을 알게 됐다.
가장 많이 했던 일은 오류 화면을 AI에게 보여주는 것이었다
개발 과정에서 내가 자주 했던 행동이 있다.
오류가 생기면 화면을 캡처해서 AI에게 보여주는 것이다.
“이게 왜 이렇게 나오지?”
“버튼을 눌렀는데 아무 반응이 없다.”
“분명 완료했는데 아직 진행 중이라고 나온다.”
이런 식이었다.
AI는 화면만 보고 원인을 추측했고,
필요하면 실제 코드를 확인했다.
그리고 다시 수정했다.
이 과정을 수없이 반복했다.
그래서 Santiago Brain 개발은 이런 순서로 진행되는 경우가 많았다.
기능 요청 → AI 개발 → 직접 사용 → 문제 발견 → 화면 캡처 → 원인 분석 → 수정 → 다시 확인
한 번에 완벽하게 만드는 방식이 아니라,
실제로 사용하면서 계속 고치는 방식이었다.
Preview에서는 되는데 실제 서비스에서는 안 되는 일도 있었다
개발 중에는 정상적으로 보이는데 실제 공개된 앱에서는 예전 화면이 그대로 나오는 경우도 있었다.
처음에는 이해하기 어려웠다.
나중에 알게 된 것은 개발 화면과 실제 배포된 서비스가 항상 같은 상태는 아니라는 것이었다.
개발이 끝났더라도 다시 배포하지 않으면 실제 사용 화면에는 수정 내용이 반영되지 않을 수 있었다.
그래서 개발 과정에는 하나의 단계가 더 생겼다.
수정 → Preview 확인 → 테스트 → 배포 → 실제 사이트 확인
이 과정도 처음에는 상당히 낯설었다.
AI에게 맡겨도 사람이 판단해야 하는 부분은 남는다
AI는 코드를 빠르게 작성해준다.
오류도 상당 부분 찾아준다.
하지만 앱의 방향까지 AI에게 모두 맡길 수는 없었다.
예를 들어 이런 결정은 결국 내가 해야 했다.
오늘 화면에 무엇을 보여줄 것인가.
프로젝트와 아이디어를 같은 화면에 둘 것인가.
목표 진행률은 무엇을 기준으로 계산할 것인가.
오래된 할 일을 자동으로 숨길 것인가.
AI가 추천한 프로젝트를 바로 저장할 것인가, 내가 확인한 뒤 저장할 것인가.
이런 것은 기술 문제가 아니라 사용 방식에 관한 결정이었다.
그래서 AI와 함께 프로그램을 만든다는 것은 AI가 대신 모든 것을 하는 것이 아니라,
사람이 방향을 결정하고 AI가 그것을 구현하는 협업에 가깝다.
개발을 하며 내 역할도 달라졌다
처음에는 내가 AI에게 이렇게 말했다.
“이거 만들어줘.”
하지만 시간이 지나면서 질문이 달라졌다.
“이 기능을 만들면 기존 데이터에는 어떤 영향이 있나?”
“이 방법과 저 방법 중 어느 쪽이 안전한가?”
“사용자가 실제로 쓸 때 어떤 문제가 생길 수 있나?”
점점 프로그램을 만드는 사람처럼 생각하게 됐다.
코드를 능숙하게 쓰지는 못하지만,
무엇을 만들지 설계하고,
문제를 찾고,
AI에게 수정 방향을 지시할 수 있게 됐다.
나에게는 이것이 꽤 큰 변화였다.
코딩을 몰라도 만들 수 있지만, 생각 없이 만들 수는 없다
Santiago Brain을 만들면서 느낀 점은 명확하다.
AI 덕분에 코딩의 진입 장벽은 분명 낮아졌다.
하지만 원하는 프로그램을 제대로 만들려면 여전히 생각해야 한다.
내가 무엇을 원하는지.
사용자는 어떻게 사용할지.
데이터는 어떻게 연결할지.
실수했을 때 어떻게 복구할지.
어떤 기능은 꼭 필요하고 어떤 기능은 필요 없는지.
이런 판단은 사람이 해야 한다.
어쩌면 AI 시대의 개발은 예전과 조금 다른 능력을 요구하는지도 모른다.
코드를 외우는 능력만큼이나,
문제를 정의하고, 요구사항을 구체적으로 설명하고, 결과를 검증하는 능력이 중요해지고 있다.
나는 지금도 Santiago Brain을 만들고 있다.
완성했다고 말하기는 어렵다.
하지만 처음에 비하면 분명 많이 달라졌다.
그리고 무엇보다 중요한 것은,
나는 개발자가 아니어도 내가 필요한 프로그램을 직접 만들어볼 수 있다는 경험을 했다.
다음 글에서는 Santiago Brain의 전체 구조를 조금 더 자세히 이야기해보려고 한다.
왜 오늘, 목표, 프로젝트 & Idea, 할 일, 결정일지, 회고, 지식창고로 나누었는지, 그리고 이 메뉴들이 서로 어떻게 연결되는지를 정리해보겠다.
다음 글 예고
3편 — Santiago Brain의 구조를 설계하다: 목표에서 오늘 실행까지
단순히 기능을 많이 넣는 것이 아니라,
생각 → 결정 → 프로젝트 → 할 일 → 실행 → 회고가 하나로 이어지도록 어떤 구조를 만들었는지 이야기해보겠다.