AI로 프로그램을 만들지만 개발을 이어가기 어려운 이유
AI에게 아이디어를 설명하고 프로그램을 만들어 보는 일은 예전보다 훨씬 쉬워졌습니다. 코드를 전부 처음부터 작성하지 않아도 되고, 오류 메시지를 함께 읽으며 다음 시도를 빠르게 정할 수도 있습니다.
그런데 프로그램 하나가 만들어졌다는 사실과, 그 작업을 어디서든 계속할 수 있다는 사실은 다릅니다. 개발 환경이 한 대의 노트북 안에만 있고, 파일이 어느 폴더에 있는지 모호하며, 이전에 무엇을 바꿨는지 기록이 없다면 다른 장소에서 작업을 이어가기 어렵습니다.
AI가 코드를 작성하는 속도가 빨라질수록 오히려 개발 환경과 소스 관리의 기본이 더 중요해진다고 느꼈습니다. 코드를 만드는 도구와 코드를 다시 찾고 실행하는 방법은 서로 다른 문제이기 때문입니다.
실제 바이브 코딩 사용자와의 대화
얼마 전 IT 전공자가 아닌 분과 이런 이야기를 나눴습니다. 그분은 AI를 이용해 여러 프로그램을 직접 만들어 보고 있었지만, 작업에 사용하던 노트북이 없으면 다른 장소에서 개발을 이어가기 어렵다고 했습니다.
저는 먼저 GitHub에 소스코드를 보관하는 방법을 설명했습니다. GitHub에 올린 저장소는 다른 개발 환경에서 다시 복제할 수 있고, 변경 이력도 확인할 수 있습니다. 한 대의 노트북에 있는 파일을 단순히 다른 곳으로 옮기는 것보다, 어떤 상태에서 작업을 이어갈지 선택할 수 있다는 점이 중요합니다.
상대방은 이런 버전 관리 방법이 있는지 몰랐다고 했습니다. 그 대화에서 저도 다시 확인했습니다. AI 도구를 잘 사용하는 것만으로는 충분하지 않습니다. 소스코드를 관리하고, 개발 환경을 다시 만들고, 공개된 결과를 검증하는 흐름까지 알아야 작업이 이어집니다.
Git과 GitHub를 사용하는 이유
Git은 파일의 현재 상태만 보관하는 도구가 아닙니다. 무엇을 바꿨는지 비교하고, 필요하면 이전 상태를 참고하고, 작업을 다른 환경으로 옮길 수 있게 해 줍니다. GitHub는 그 저장소를 원격에 보관하고 다른 환경에서 접근하는 하나의 공개된 작업 공간이 됩니다.
다만 GitHub에서 소스코드를 내려받는다고 개발 환경까지 자동으로 복원되는 것은 아닙니다. 저장소를 복제한 뒤에는 Node.js 버전, 의존성, 환경 변수, 실행 방법, 배포 연결을 다시 확인해야 합니다. 소스코드의 이동과 개발 환경의 재구성은 서로 다른 단계입니다.
이 구분을 알고 나면 “노트북이 없어도 개발할 수 있는가?”라는 질문은 “어떤 환경에서 저장소를 복제하고, 무엇을 다시 준비해야 하는가?”라는 구체적인 질문으로 바뀝니다.
내가 구성한 ONSEMO 개발 환경
현재 ONSEMO 작업의 큰 흐름은 다음과 같습니다.
Windows → WSL2 Ubuntu → Codex → GitHub → Cloudflare → ONSEMO 서비스
Windows는 일상적으로 사용하는 운영체제이고, 실제 개발 작업은 WSL2 Ubuntu 안에서 진행합니다. 그 안에서 Codex와 Node.js, Git을 사용하고, 변경 내용을 GitHub에 push합니다. Cloudflare는 Git 저장소와 연결된 빌드·배포 흐름을 통해 공개 웹서비스를 갱신합니다.
다른 개발 환경에서 이어갈 때는 GitHub 저장소를 복제하고, 프로젝트가 요구하는 도구와 의존성을 준비한 뒤 로컬 빌드와 테스트를 다시 실행합니다. 파일만 복사하는 것보다 느릴 수 있지만, 작업의 출처와 현재 상태를 확인할 수 있어 결과적으로 안전합니다.
Windows 대신 WSL2 Ubuntu를 활용한 이유
AI 코딩 도구에 Windows PC 전체의 파일 접근 권한을 넓게 허용하고 싶지는 않았습니다. 개발에 필요한 파일과 개인적인 파일을 가능한 한 분리하고, 작업 범위를 명확하게 보이게 하고 싶었습니다.
그래서 WSL2 Ubuntu를 중심으로 개발 환경을 구성했습니다. 프로젝트 파일을 WSL2 안에서 관리하면 적어도 작업의 기본 경계를 정하기가 쉬워집니다. 권한과 경로를 직접 확인하면서 필요한 디렉터리만 사용하려고 했습니다.
한 번은 Windows 다운로드 폴더에 개발 파일을 넣고 Codex에게 가져오라고 요청했지만, 특정 접근 시도가 실패했습니다. 그때 실제로 무엇이 막았는지는 아직 확인하지 않았습니다. Linux 권한 문제였는지, WSL2 마운트 경로의 문제였는지, Codex의 샌드박스나 승인 범위 때문이었는지 단정할 수 없습니다.
중요한 점은 WSL2를 완전한 보안 격리 환경으로 생각하지 않는 것입니다. Windows와 파일 시스템을 연결할 수 있고, 설정에 따라 접근 범위가 달라집니다. WSL2는 작업 경계를 정하는 데 도움을 주는 개발 환경이지, 모든 위험을 자동으로 제거하는 보안 제품은 아닙니다.
Codex Remote로 외부에서 개발하기
OpenAI의 공식 설명에서 Codex Remote는 휴대폰을 개발 작업의 제어 화면으로 사용하는 흐름에 가깝습니다. 연결된 개발 호스트에서 실행 중인 작업을 시작하고, 진행 방향을 조정하고, 변경 결과를 검토할 수 있습니다. Codex Remote에 대한 공식 소개
이것은 GitHub와 같은 기능이 아닙니다. GitHub는 소스코드를 저장하고 다른 환경에서 복제할 수 있게 하는 저장소입니다. Codex Remote는 연결된 개발 호스트에서 실행되는 작업을 외부에서 확인하고 조정하는 방법입니다. Remote가 소스코드를 자동으로 다른 컴퓨터로 옮겨 주는 것은 아니며, 연결된 호스트와 그 호스트의 권한·전원·네트워크 상태가 전제됩니다.
따라서 제 흐름에서는 두 기능을 나누어 생각합니다. 작업 중인 Windows·WSL2 환경을 외부에서 이어서 조정할 때는 Remote를 사용하고, 다른 환경에서 독립적으로 이어갈 때는 GitHub에서 저장소를 복제합니다.
GitHub와 Cloudflare로 웹서비스 자동 배포
작업을 마친 뒤에는 먼저 로컬에서 빌드합니다. 기존 경로가 사라지지 않았는지, 콘텐츠와 링크가 정상인지, API처럼 선택적인 기능이 본문을 가리지 않는지 확인합니다.
검증한 변경만 GitHub에 push하면 Cloudflare Git 연동이 빌드를 시작하고 공개 사이트를 갱신합니다. 이 흐름에서는 배포 명령을 직접 실행하기보다 Git을 변경 이력과 배포 트리거로 함께 사용합니다. 배포가 끝난 뒤에는 실제 공개 URL에서 페이지와 주요 경로를 다시 확인합니다.
이렇게 하면 “AI가 코드를 만들었다”에서 끝나지 않고, 변경 내용을 검토하고 공개된 결과를 확인하는 단계까지 이어집니다. 작은 서비스라도 소스 관리, 빌드, 배포, 검증을 분리해 두는 이유입니다.
연간 10.46달러라는 비용의 의미
현재 개인 도메인에 실제로 지출한 비용은 연간 10.46달러였습니다. 이 금액은 도메인 비용만을 의미하며, 개발에 들어간 전체 비용이나 서비스 운영 비용을 뜻하지 않습니다.
작은 웹서비스를 공개하는 데 도메인처럼 피할 수 없는 비용은 있을 수 있습니다. 그렇지만 비용을 말할 때는 무엇을 포함하고 무엇을 포함하지 않았는지 함께 적어야 합니다. 그래야 다른 사람이 자신의 상황에 맞게 판단할 수 있습니다.
AI 시대에도 기본 IT 지식이 필요한 이유
AI는 코드를 작성하고 설명하는 일을 크게 도와줍니다. 그러나 어떤 파일을 열어도 되는지, 소스코드가 어디에 보관되는지, 다른 환경에서 무엇을 다시 설치해야 하는지, 배포된 결과를 어떻게 검증하는지는 여전히 사람이 판단해야 합니다.
특히 AI가 만든 결과를 실제 서비스로 연결할 때는 성공한 한 번의 명령보다 경계가 중요합니다. 개인 파일과 프로젝트 파일을 구분하고, Git 변경을 검토하고, 공개하지 않을 정보가 들어갔는지 살피고, 문제가 생겼을 때 이전 상태로 돌아갈 수 있어야 합니다.
그래서 AI 시대의 기본 IT 지식은 코드를 직접 많이 쓰는 능력만을 뜻하지 않는다고 생각합니다. 파일과 권한, 운영체제와 개발 환경, Git과 배포, 공개 URL과 검증의 관계를 이해하는 능력도 포함됩니다.
아직 확인하지 않은 것들
이번 글은 제가 실제로 사용한 흐름과 대화에서 출발한 기록입니다. WSL2에서 특정 Windows 폴더 접근이 실패한 정확한 원인은 아직 확인하지 않았습니다. 따라서 이 글에서 특정 권한 설정이 원인이었다고 단정하지 않습니다.
Linux 권한, WSL2 마운트, Codex의 승인·샌드박스 범위를 확인하는 구체적인 방법은 별도의 Practical Knowledge 글에서 검증한 뒤 다룰 예정입니다. 아직 발행하지 않은 가이드의 URL을 미리 만들어 링크하지 않는 것도 같은 이유입니다.
작은 프로그램을 계속 만들고 싶다면 먼저 작업을 이어갈 수 있는 환경을 준비해야 합니다. 한 대의 노트북에 모든 것을 묶어 두지 않고, 소스코드는 Git으로 관리하고, 개발 환경은 다시 구성할 수 있게 기록하고, 공개 배포는 검증 가능한 흐름으로 연결하는 것. 제가 이번 작업에서 얻은 가장 실용적인 결론은 그 정도입니다.