[GL 5기] 삽질 주도 개발을 AI와 함께 🤖

AI에게 코드를 맡기면 구현 속도는 빨라집니다. 하지만 실행되는 코드가 곧 올바른 코드는 아닙니다. 시간대 하나를 잘못 해석해 그래프가 멈추거나, 눈에 보이지 않는 보안 문제가 생기거나, 편의를 위해 넣은 라이브러리가 다음 변경의 발목을 잡을 수도 있습니다.

2026년 5월 16일 그로스라운지에서 열린 17차 그로스톡에서 이황수 님은 삽질 주도 개발을 AI와 함께라는 주제로 발표했습니다. 방송대 학우들이 전공 학습과 프로젝트 경험을 나누는 그로스로그에서, 개발 초보자의 AI 활용을 “어떻게 빨리 만들까”보다 “어떻게 방향을 정하고 검증할까”라는 질문으로 확장한 시간이었습니다.

전공 네 개를 지나 개발 앞에 선 사람 🧭

이황수 님은 문예창작, 북한학, 일본학을 공부했고 현재 컴퓨터과학을 배우고 있습니다. 게임 기획자와 시나리오 작가로 일하며 여러 게임의 출시와 라이브 서비스를 경험했지만, 자신을 프로그래머로 소개하지는 않았습니다. 개발 업무를 가까이에서 보아 온 기획자가 직접 만들기 시작하며 겪은 시행착오가 이번 발표의 출발점이었습니다.

발표자 소개 슬라이드 옆에서 전공과 경험을 설명하는 이황수 발표자

2026년 5월 16일, 이황수 님이 네 전공과 게임 기획 경험을 소개한 17차 그로스톡 현장

발표 사례는 AI가 경제 지수와 뉴스를 분석해 다음 영업일의 시황을 예상하는 웹사이트였습니다. 가족이 큰 소리로 경제 유튜브를 시청하는 모습을 보고, 필요한 정보를 더 차분하게 확인할 방법을 직접 만들어 보자는 생각에서 시작했습니다. 생활 속 불편을 바로 개발 문제로 바꾼 셈입니다.

AI를 많이 써도 방향은 사람이 정합니다

이황수 님은 아이디어 구상, 브레인스토밍, 기획, 구현, 검토와 개선의 모든 단계에 AI를 배치했습니다. 그렇다고 전 과정을 한 번에 맡기지는 않았습니다. 아이디어를 넓히고 자료를 모을 때는 AI의 도움을 받되, 어떤 문제를 풀지와 무엇을 포기할지는 사람이 결정했습니다.

기획과 설계 단계에서는 사람이 가장 깊게 개입하고, 구현 단계에서는 AI의 비중을 높였습니다. 마지막에는 다시 사람이 결과를 검증하고 문서에 남겼습니다. 이렇게 쌓인 문서가 다음 수정의 입력이 되면서, 한 번의 시행착오가 이후 작업을 더 빠르게 만드는 구조가 만들어졌습니다.

발표자가 사용한 모델의 역할도 달랐습니다. 발표 당시 경험을 기준으로 Gemini는 문서 작업과 브레인스토밍·검색, Claude는 구조와 설계 및 선택지 비교, Codex는 범위가 작고 조건이 분명한 코딩 작업에 나눠 활용했습니다. 한 모델의 답을 그대로 따르기보다 역할을 나누고 기록을 합치는 방식입니다.

한 문장으로 좁혀야 구현을 나눌 수 있습니다

기획은 “AI가 경제 지수와 뉴스를 토대로 다음 영업일 시황을 분석하고 예상해 주는 웹사이트”라는 한 문장으로 정리했습니다. 이른바 One Page Proposal과 육하원칙을 이용해 누구를 위한 무엇인지 먼저 고정한 뒤, 큰 아이디어를 AI가 처리할 수 있는 작은 작업 단위로 나눴습니다.

입력과 출력, 제약이 분명한 닫힌 문제에서 AI는 강점을 보입니다. 반대로 요구가 계속 바뀌거나 성공 조건이 모호하면 그럴듯하지만 엉뚱한 결과가 나오기 쉽습니다. 구현을 요청하기 전에 한 문장으로 목적을 설명하고, 각 작업의 완료 조건을 적어 두는 일이 중요한 이유입니다.

스프레드시트에서 React까지 빠르게 뒤집어 보기 🛠️

프로젝트는 Google 스프레드시트에서 출발해 정적 페이지와 Vercel, React와 Vercel을 거쳤습니다. 이후 React와 자체 서버를 연결하는 단계까지 계획했지만, 발표 전까지 서버 구성을 모두 마치지는 못했습니다. 완성된 구조처럼 포장하기보다 어디까지 진행했고 무엇이 남았는지를 분명히 보여 준 점이 인상적이었습니다.

Google 스프레드시트에서 React와 서버 단계까지 개발 구조의 변화를 설명하는 이황수 발표자

경제 시황 분석 프로젝트가 스프레드시트, 정적 페이지, React를 거쳐 확장된 과정을 설명하는 장면

빠르게 배포하고 다시 고친 선택에는 이유가 있었습니다. 가족이 바로 사용할 수 있어야 했고, 사용자 요청을 받으며 구조를 바꾸는 경험도 필요했습니다. 다만 발표자는 이런 방식이 모든 업무 환경에 적합하다고 권하지 않았습니다. 빠른 공개로 얻는 피드백과 나중에 치를 변경 비용을 함께 계산해야 하는 선택으로 설명했습니다.

AI의 삽질은 운영 시나리오로 잡습니다 🔍

첫 번째 시행착오는 로직이었습니다. 해외 금융 데이터를 한국 시간 기준으로 보여 주는 과정에서 그래프가 평평하게 나타났습니다. 시장 운영 시간과 시간대, 데이터 지연을 충분히 확인하지 않은 결과였습니다. 코드만 읽는 검토를 넘어 실제 운영 시간, 지연, 호출 제한과 비용까지 시나리오로 확인해야 했습니다.

두 번째는 결과물의 품질입니다. 디자인을 다듬는 과정에서 AI가 보안과 개발 관례에 어긋나는 항목을 여러 개 만들었고, 서버리스 함수에는 인라인 이벤트 스크립트를 허용하는 코드도 섞였습니다. 화면이 정상적으로 보인다는 이유만으로 배포해서는 안 되며, 보안 규칙과 팀의 코딩 기준을 사람이 다시 확인해야 합니다.

세 번째는 라이브러리 선택입니다. 편리한 패키지도 의존성, 버전 정책, 패치 주기, 빌드 시간과 학습 비용을 함께 가져옵니다. 지금 한 줄을 줄여 주는 도구가 장기적으로 유지보수 비용을 키울 수 있으므로, 도입 전에 프로젝트의 수명과 교체 가능성을 살펴야 합니다.

코드 생성 비용이 낮아질수록 결정의 책임은 커집니다

AI 시대의 개발은 코드를 얼마나 많이 만들었는지보다 그 코드가 왜 필요한지 설명하고, 실제 조건에서 안전하게 작동하는지 확인하는 일에 더 가까워집니다. 계획이 단단할수록 되돌리는 작업이 줄고, 작업 단위를 작게 나눌수록 AI의 맥락 손실과 변경 범위를 살피기 쉬워집니다.

이번 세션이 남긴 핵심은 “AI가 만들었으니 괜찮다”는 가정을 버리는 것입니다. 다음 프로젝트를 시작할 때는 첫 프롬프트보다 먼저 한 문장의 목적, 예상 비용, 실패 시나리오와 검증 기준을 적어 보세요. AI가 구현을 돕더라도 이해와 확인, 최종 결정은 여전히 사람의 몫입니다.