AI, 기죽지 맙시다 5편 : 자세히 들여다보기
그리고 멈추지 않고 반복해서 고쳐봅니다. 뚝딱 뚝딱
4편에서 클로드 코드로 무지성으로 만들어봤다. 배포까지 해봤다. 동작하는 걸 봤다. 도파민 터졌다.
이 과정에서 나도 모르게 한 것들이 있다. API도 연결해봤고, 프론트도 띄워봤고, 서버도 돌려봤다. AI한테 무엇인가를 시키면 아웃풋이 나온다는 것을 경험하며 뭔가가 보이기 시작한다.
그러면 다음은 뭘까. 완결된 프로젝트를 A부터 Z까지 만드는 게 아니다. 오히려 역으로 일부를 대체해보는 것이다.
기존 도구에서 작게 만들어보기
원래 순서라면 개념을 배우고 → 일부를 시도해보고 → 다음 단계로 가는 건데. 이번에는 순서가 다르다. 먼저 해보고 → 개념이 보이는 순서다.
Google 스프레드시트, 노션, 슬랙. 이미 매일 쓰고 있는 도구들이다. 여기서 작은 자동화를 하나 만들어보면 이게 어떻게 동작하는지 눈으로 보인다.
내가 실제로 해본 것들이다.
PT 선생님 스케줄링 자동화. PT 선생님한테 카카오톡으로 예약이 들어온다. 이걸 Google 스프레드시트에 자동으로 정리되게 만들었다. 매번 수동으로 옮겨적을 필요가 없어졌다.
학원 스쿨버스 동선 짜주기. 학원 선생님이 학생 6명을 픽업해야 하는데, 어떤 순서로 돌아야 효율적인지 모르겠다고 했다. 주소 넣으면 최적 경로 짜주는 걸 만들어줬다.
그리고 이건 다른 분이 바이브코딩에서 한 예시이다.
슬랙 → Jira 티켓 자동 생성. 슬랙에 내용을 입력하면 AI가 판단하고, 그걸 글로 작성해서 Jira 티켓으로 바로 생성되게 만들었다.
A부터 Z까지 완결된 서비스를 만드는 게 아니라, 내가 평소에 하던 반복적인 일을 하나 골라서 AI한테 이거 자동화해줘 라고 시키는 거다.
이때부터 하나씩 읽어본다
여기서 4편이랑 달라지는 게 있다.(중요!!)
4편에서는 승인 버튼 무지성으로 yes 눌렀다. 뭔 말인지 모르겠고 일단 승인했다. 그게 맞았다. 처음엔 그래야 한다. 근데 이번에는 다르다. /plan 모드로 이런 걸 만들고 싶다 라고 말하면 AI가 하나씩 스텝별로 안내해준다. 이거 연동해, 이거 해봐, 다음에 어떻게 할래? 이렇게 물어본다.
이때 하나씩 하나씩 내용을 확인하고 승인해보는 거다. 하나도 뭐라고 하는지 못 알아들을 확률이 높다. 그래도 괜찮다. 그냥 하나씩 읽어보는 것만으로 습관을 들여보는 거다.
왜냐면 이건 내가 평소에 쓰던 툴이다. 내가 평소에 하던 생각이다. 그래서 읽으면 조금씩 보일 수 있다. 아 이게 이렇게 연결되는 거구나. 아 이게 이런 뜻이구나. 그게 보이기 시작하는 순간이 온다.
정말 작게. 어떻게 동작하는지 눈으로 보는 거다.
본격 프로젝트: 카피부터 해봐라
여기까지 했으면 이제 본격적으로 프로젝트를 하나 만들어볼 차례다.
내가 진짜 추천하는 방법은 내가 만들고 싶은 프로젝트를 유사하게 카피해보는 거다. 처음부터 새로운 걸 만들려고 하면 이렇게 동작하는 게 맞나 저렇게 동작하는 게 맞나 판단하는 것도 시간이고, 그 기준이 없으니까 시간을 엄청 쓰게 된다.
목적을 명확하게 정하는 거다. AI를 배워보는 게 목적이라면 카피가 가장 빠르게 배울 수 있다.
나는 내가 하고 있는 프로젝트를 유사하게 만들어봤다. AI 챗봇 기능을 똑같이 만들어봤고, 내 머릿속에 있는 것을 만들어봤다.
재밌었던 건, 실제로 설계된 거랑 내가 만든 게 다르게 설계됐다는 거다. 그래서 오히려 두 가지를 동시에 배울 수 있었다. 기존에 설계된 거랑 내가 설계한 거. 정답이 이미 있으니까 AI가 다르게 만들어도 비교가 된다. 새로운 걸 만들면 비교 대상이 없어서 이게 맞는지 틀린지도 모른다.
개발 구조를 이해하자
이쯤 되면 전체적인 개발 구조를 좀 알아야 한다. 비개발자라도.
인프라라고 하는 게 있다. 서버를 띄우는 영역이다. 그 위에 백엔드, 프론트엔드, AI 모듈 같은 것들이 있다.
유저가 보는 화면이 프론트엔드이고, 유저가 안 보는 뒤에서 돌아가는 로직이 백엔드다.
백엔드랑 프론트엔드를 연결해줘야 하나로 동작할 수 있고. 어떤 건 화면단으로만 움직일 수 있고, 어떤 건 데이터를 가져오거나 저장해야 해서 백엔드가 필요하다. AI를 호출하는 부분도 별도로 있어야 한다.
AI 프로젝트를 만든다고 한다면 이 구조를 전체적으로 설계해보는 거다. 내가 뭘 만들고 싶은지 극대화시키는 거. 혼자 안 해도 된다. 당연히 AI랑 함께 하면 더 좋다.
근데 프론트엔드 초기 환경 설정, 백엔드 초기 환경 설정 이런 건 안 했다. 나도 못 한다. 개발자 친구들도 굳이 이것까지 안 해도 되지 않아 라고 하는 영역이더라. 그러면 나도 안 한다.
세팅에 시간 안 쓴다. 그래서 Vercel 쓰고, Supabase 쓴 거다.
목적은 내가 원하는 대로 코드를 쓰고 동작하게 만드는 거지, 세팅하는 게 아니다.
간단히 설명하면 이렇게!
자세히 설명하면 이렇게!핵심 기능부터. 잘못되면 뿌시고 다시
만드는 방법은 별거 없다. 핵심 기능부터 만든다. 잘못 되면 뿌시고 다시 만들면 된다.
만들고 → 동작 확인 → 오류 있으면 캡처 → AI한테 물어본다 → 해결법 찾는다 → 1번 해결 안 되면 2번 물어본다 → 2번 안 되면 3번 물어본다.
이때부터 엉덩이 싸움이다.
유저한테 써보게 해라
가장 좋은 건 유저들이 사용하게 해보는 거다.
원리를 아는 것도 중요하지만 사용할 때 어떻게 동작해야 되는지 아는 것도 중요하다. 배우는 이유도 결국 사용을 위한 배움이다.
실제로 사용하면 이런 오류를 만날 수 있구나 하는 것들이 나온다. 사용하고 피드백 받으면 개발 방향이 달라지는 게 재밌더라.
그리고 혼자 계속 보면 버그도 안 보인다. 남이 보면 10초 만에 버그 찾더라. 도움이 된다.
이렇게 내 배움을 보여주기 시작하면 온 사방이 다 선생님이었다. 피드백 받고 → 다음날 적용하고 → 모르면 화면 보여주고 → 넥스트 스텝 조언 받고. 이 사이클이 반복되면서 러닝커브가 엄청 빨라졌다. 플라이휠처럼 돌아갔다.
무섭지 않아졌다 = 그냥 뭐 하면 되는거 아니야?
이렇게 하다 보니 혼자 만들고 수정하고 배포하는 게 무섭지 않아졌다. 내가 하는 일에 적용하는 것도 크게 무섭지 않고. 프로덕트를 내가 원하는 대로 동작하게 만드는 것도 어렵지 않아졌다. 그냥 뭐 하면 되는거아니야? 라는 마인드가 셋팅된다. 이게 진짜 무서운 것이다.
그러면 뭐가 궁금해지냐면. AI라고 하는 건 어떻게 구성되었는지, 어떤 요소로 작동하는 건지. 뜯어보고 싶어진다. 다음 편에서는 AI 구조를 파헤치기 시작한 이야기를 쓰려고 한다.