개발자가 3개월 못 한 걸, 비개발자 실무자가 자기손으로 하루 만에 옮겼습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

3개월간 개발이 지연된 서비스의 기존 주요 기능을 비개발자 실무자가 컨설턴트의 안내와 AI를 활용해 하루 안에 새 환경으로 옮겼으며, 핵심 성과는 자기 사업의 시스템을 직접 다룰 주도권을 얻은 것이었다.

📌 핵심 요점

1. 고객 진단 서비스의 어려움은 개별 기능보다 연결과 통합에 있었다. 설문, 응답 데이터, AI 분석, 결과 저장, 고객 화면을 하나의 흐름으로 묶어야 했다.
2. 외부 개발에 약 3개월을 들였지만 대표는 진행 상태와 병목을 확인하기 어려웠다. 발표자는 기술 문제보다 사업자가 자신의 시스템을 이해하고 제어하지 못하는 상황에 주목했다.
3. 기존 구조에서 기술적 잘못을 발견한 것은 아니었다. 개발팀을 운영할 계획이 없는 고객의 규모와 유지보수를 고려해 Rails와 SQLite를 사용하는 더 단순한 구조를 선택했다.
4. 실제 AI 요청과 작업은 고객사 실무자가 맡았다. 컨설턴트는 도구 선택, 작업 순서, 결과 판단을 안내했고, 기존 주요 기능 이전과 외부 접속 설정, 업무용 AI 스킬 제작을 함께 진행했다.
5. 새 환경에서 기능이 동작하는 것과 운영 준비가 끝나는 것은 별개다. 데이터 정합성·보안·백업·안정성 검증이 남았으며, 이후에는 내부에서 먼저 시도하고 필요한 지점에 전문가의 도움을 받는 방식이 제안됐다.

🧩 배경과 문제 정의

영상은 유튜브와 인스타그램에서 팔로워를 확보한 대표가 자신의 경험과 콘텐츠를 바탕으로 새 사업을 준비한 사례를 다룬다. 이 사업은 참여자의 문제와 장애 요인을 진단하고, 경험과 능력으로 새로운 기회를 만들도록 안내하는 프로그램이었다. 이를 구현하려면 설문 응답, AI 분석, 맞춤 리포트, 고객 화면을 연결하는 시스템이 필요했다.

외부 개발을 진행하는 동안 대표는 수정 결과를 기다렸고, 현재 상태와 지연 원인을 파악하기 어려웠다. 발표자는 기존 시스템의 기술적 구성이 정상적이라고 평가하면서도, 개발팀을 운영할 계획이 없는 고객에게 적합한지는 별도의 문제로 봤다. 이후 고객사 실무자가 AI를 직접 사용해 기존 기능을 더 단순한 환경으로 옮기도록 안내했고, 이 경험을 개발 주도권과 컨설팅 역할에 관한 이야기로 확장한다.

🕒 시간순 섹션별 상세정리

1. 콘텐츠 사업이 고객 진단 시스템으로 확장되는 과정

• 채널에 구독자와 팬이 모이면 강의, 커뮤니티, 새로운 사업을 준비할 수 있다. 사례의 대표도 기존 팔로워와 자신의 경험을 기반으로 사업을 구상했다. [00:53]
• 프로그램은 참여자의 문제와 막힌 지점을 진단하고, 경험과 능력으로 새로운 기회를 만드는 방법을 안내하는 형태였다. [01:14]
• 설문과 응답 데이터에 AI를 연결하는 것만으로 서비스가 완성되지는 않는다. 결과 저장, 고객 화면, 자동화 도구까지 통합하는 작업이 필요했다. [02:24]

2. 개발 지연과 시스템 통제의 어려움

• 외부 개발자를 채용해 약 3개월간 개발했지만, 수정 요청에 답변이 와도 화면 변화가 늦어지면서 사업 진행이 지연됐다. [03:00]
• 대표는 진행 상태와 병목을 판단하기 어려웠다. 저장소에서 보이는 활동은 제한적이었지만, 발표자는 기록만으로 전체 작업량을 단정하기 어렵다고 설명했다. [03:57]
• 발표자가 본 핵심 문제는 사업의 주인이 자신의 시스템을 직접 확인하고 제어하기 어렵다는 점이었다. [04:18]

3. 운영자에게 맞는 기술과 함께하는 실행

• 컨설팅 과정에서 기존 결과물을 확인한 발표자는 프런트엔드·백엔드 분리, 별도 데이터베이스와 클라우드 인프라에서 기술적 잘못을 발견하지 못했다. [04:48]
• 고객은 개발팀을 운영하기보다 필요한 기능을 조금씩 직접 바꾸고 싶어 했다. 발표자는 실무자와 나란히 앉아 하루 동안 함께 작업하자고 제안했다. [05:31]
• 새 장비에 AI 코딩 도구와 필요한 환경을 준비했다. 실무자가 AI에 직접 설치를 요청하고, 발표자는 설치 대상과 순서를 안내했다. [06:13]

4. 기존 기능 이전과 외부 접속 연결

• 기존 저장소를 가져와 AI로 프로젝트를 분석한 뒤, 사업 규모와 유지보수를 고려해 Rails와 SQLite를 사용하는 구조로 바꾸기로 했다. 기준은 기술의 우열보다 누가 운영할 것인가였다. [06:49]
• AI가 기존 코드와 기능을 분석해 새 구조에 맞게 재구성했고, 로컬 서버에서 기존 주요 화면과 기능이 동작하기 시작했다. [07:13]
• 도메인 연결과 터널을 통한 외부 접속을 설정했다. AI가 절차를 정리하고 브라우저에서 작업했으며, 발표자는 방향을 안내하고 결과를 직접 확인했다. [07:53]

5. 업무용 AI 스킬과 운영 검증의 경계

• 기존 보고서를 참고 자료로 넣고 원하는 구성과 문체를 반영해 보고서 작성 등 업무용 AI 스킬을 만들었다. 초기 결과가 만족스럽지 않아 분석과 지침 수정을 반복했다. [08:29]
• 발표자는 AI 스킬을 사용하면서 계속 개선해야 한다고 설명했다. 몇 시간 뒤 시스템이 새 환경에서 동작했지만, 운영에는 데이터 정합성·보안·백업·안정성 검증이 더 필요했다. [08:57]
• AI에 프롬프트를 전달하고 작업을 진행한 사람은 고객사 실무자였다. 발표자는 도구, 순서, 결과 판단과 검증 방법을 안내했다. [09:17]

6. 기술을 배우는 고객에서 문제를 해결하는 고객으로

• 발표자는 러셀 브론슨의 『마케팅 설계자』를 다시 읽으며 자신이 만나고 싶은 고객을 돌아봤다. AI 학습 자체보다 AI로 해결할 문제가 분명한 사람에게 관심이 옮겨갔다. [09:59]
• 고객은 자신의 사업과 필요한 기능을 잘 알지만 개발 지식 때문에 실행할 때 도움을 요청해 왔다. 발표자는 이들에게 자기 문제를 AI와 함께 해결하는 경험이 필요하다고 봤다. [10:23]
• 기존 고객의 소개, 유튜브, 커뮤니티, 기업 강의에서 비슷한 고민을 가진 사람들을 만날 수 있었다. 앞으로 실제 사업 문제의 해결 과정을 보여주는 콘텐츠를 늘리려 한다. [11:01]

7. 개발 주도권을 확인하는 진단 구상

• 무료 강의나 전자책에 앞서 고객이 자신의 상태를 확인하도록 돕는 접근을 제안했다. 소스 코드 관리, 개발자 부재 시 운영 가능성, 도메인과 서버 계정의 소유권 등을 질문한다. [11:34]
• 내부 직원이 AI로 문제 원인을 확인하거나 작은 기능을 만들 자신감이 있는지도 살핀다. 이를 바탕으로 가칭 ‘AI 개발 주도권 진단’을 만들 계획을 밝혔다. [11:47]
• 약 12개 질문으로 회사의 시스템 통제 수준과 AI를 활용한 직접 개발 준비도를 확인하려는 구상이다. 질문을 통해 현재 상황이 더 분명해질 수 있다고 설명했다. [12:10]

8. 고객의 성과와 전문가에게 묻는 방식의 변화

• 발표자가 본 가장 큰 성과는 특정 기술이나 스킬보다 고객이 직접 통제하고 기획하고 만들 수 있다고 느낀 경험이었다. [12:34]
• 먼저 AI에 코드와 문제를 제시하고 작은 수정을 시도한 뒤, 해결되지 않는 부분에 전문가의 도움을 받는 순서를 제안했다. 요청도 제작 의뢰에서 자신이 만든 결과의 검토로 달라진다. [13:06]
• 컨설팅의 목표는 고객이 시스템을 이해하고 수정·운영할 방법을 찾도록 돕는 것이다. 발표자는 고객의 독립을 선호하며, 전문가의 역할도 고객이 만들 수 있는 환경을 설계하는 방향으로 이동할 수 있다고 봤다. [14:05]

9. 남은 결과와 시청자에게 던지는 문제

• 그날 실무자는 환경 설정, 소스 코드 이전, 외부 접속 연결, AI 스킬 기획과 제작을 진행했다. 오래 남은 변화는 대표와 실무자가 다음에 만들 것을 이야기하고 실행하기 시작했다는 점이었다. [14:40]
• 발표자는 개발을 맡긴 뒤 기다리는 상황이나 아이디어가 있어도 개발 지식 때문에 시작하지 못하는 상황을 시청자에게 돌아보게 하고, 댓글과 연락을 요청했다. [14:59]
• 앞으로 보여주려는 주제는 각자가 가진 문제를 AI와 함께 어디까지 직접 해결할 수 있는지다. 이 방향을 밝히며 영상을 마무리했다. [15:19]

🧾 결론

• 이 사례에서 하루 만에 이룬 것은 기존 코드와 주요 기능을 활용한 이전 및 동작 확인이다. 처음부터 전체 서비스를 새로 완성했다는 의미로 읽으면 범위를 과장하게 된다.
• 기술 선택의 기준은 운영자의 역량과 사업 조건이다. 발표자는 Rails나 SQLite가 다른 기술보다 우월하다고 주장하지 않았다.
• 가장 큰 변화는 대표와 실무자가 다음 기능을 직접 기획하고 실행하기 시작했다는 점이다. 전문가에게 하는 요청도 제작 의뢰에서 자신이 만든 결과의 검토 요청으로 바뀔 수 있다.
• 발표자가 지향하는 컨설팅은 고객의 지속적인 의존보다 독립적인 실행 능력을 높이는 방향이다.

📈 투자·시사 포인트

• 소규모 사업의 시스템 투자에서는 기능 목록뿐 아니라 내부 담당자가 이해하고 수정할 수 있는지도 판단 기준이 된다. 이 사례에서는 운영 가능성이 구조 변경의 핵심 이유였다.
• AI 도입의 사업적 가치는 도구 보유보다 구체적인 업무 문제를 해결하는 경험에서 드러난다. 발표자는 기술 소개 중심 콘텐츠에서 실제 사업 문제의 해결 과정을 보여주는 콘텐츠로 방향을 바꾸려 한다.
• 개발자와 컨설턴트의 역할이 고객이 직접 실행할 환경을 설계하고 결과를 검증하는 쪽으로 확장될 가능성을 제시한다. 이는 발표자의 전망이며, 시장 전반의 변화가 검증된 것은 아니다.
• 영상에는 비용 절감액, 매출 변화, 투자 수익률이 제시되지 않았다. 하루 동안의 이전 사례만으로 경제적 효과를 수치화하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 3개월의 개발 지연은 발표자가 전달한 고객 사례다. 저장소 기록만으로 전체 작업량을 단정하기 어렵다고 영상에서도 언급하므로, 개발자의 역량이나 지연 원인을 확정할 수 없다.
• 하루 작업은 기존 코드와 기능을 활용했고 컨설턴트의 안내도 있었다. 다른 비개발자가 같은 시간 안에 동일한 결과를 얻을 수 있는지는 확인되지 않았다.
• 주요 화면과 기능의 동작은 확인했지만, 데이터 정합성·보안·백업·안정성에 대한 추가 검증이 남았다. 실제 운영 성능과 장기 유지보수 결과도 제시되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 소스 코드 저장소, 도메인, 서버 계정의 소유자와 내부 담당자의 접근 가능 여부를 확인한다.
• 고객 응답 수집부터 AI 분석, 결과 저장, 고객 전달까지 현재 서비스의 흐름을 정리하고 어디에서 작업이 지연되는지 확인한다.
• 개발팀 운영 계획과 내부 담당자의 수정·유지보수 역량을 기준으로 현재 구조가 사업 조건에 맞는지 검토한다.
• 작은 기능 하나를 대상으로 내부 실무자가 AI에 직접 요청하고 결과를 확인하는 작업을 진행한다. 전문가의 안내가 필요한 단계도 함께 기록한다.

❓ 열린 질문

• 비개발자 실무자가 직접 수정해도 되는 범위와 전문가 검토가 필요한 범위는 어떤 기준으로 나눌 수 있을까?
• 새 환경의 데이터 규모와 이용자가 늘어났을 때도 내부 담당자가 안정적으로 운영할 수 있을까?
• 컨설턴트가 떠난 뒤에도 실무자가 오류를 진단하고 기능을 추가할 수 있는지는 어떻게 확인할 수 있을까?