소크라테스 인터뷰로 기획하고 ChatGPT Sites로 배포하기

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

소크라테스식 인터뷰로 요구사항을 기획서로 정리하고 ChatGPT Sites로 구현·배포하되, 업무 흐름 검증과 접근 권한 설정까지 마쳐야 실제 활용으로 이어진다.

📌 핵심 요점

1. AI가 질문하면서 기획을 구체화한다. 무엇을 만들지 미리 확정하기보다 사용자의 문제와 필요를 묻는다. 실습에서는 최대 10개의 질문으로 원무과의 반복 문의, 필요한 정보, 상태 변경 담당자, 조회부터 답변까지 5초라는 목표를 정한다.
2. 인터뷰 결과를 구현용 기획서로 전달한다. 대화 내용을 기획서로 정리한 뒤 Sites에 본문을 붙여 넣거나 MD 파일을 첨부한다. 실습에서는 Work 모드와 GPT6 루나, 미디엄 추론 강도를 사용하며 작업 시간과 사용량을 확인한다.
3. 생성 결과는 실제 업무 순서로 검증한다. 같은 기획서에서도 화면과 코드가 달라질 수 있다. 서류 등록이 목록에 반영되는지, 접수→작성 중→의사 확인 중→발급 가능으로 상태가 바뀌는지 확인하고, 누락된 정보 수정 기능은 화면 위치와 원하는 동작을 함께 지정해 요청한다.
4. 서버 배포와 외부 공개를 구분한다. 실습의 생성 페이지는 이미 서버에 배포되어 있지만 초기 접근 권한은 본인에게만 있다. 공유 범위를 변경해 게시하면 외부에서도 접속할 수 있으며, 공개 상태는 권한을 다시 바꾸기 전까지 유지된다.
5. 운영에는 계정·권한과 개발 환경 검토가 뒤따른다. 관리자와 일반 사용자의 조회·수정 권한을 나누고, 소셜 로그인은 외부 서비스 설정까지 연결해야 한다. 규모가 큰 서비스는 로컬 개발 환경을 검토하며, 자체 서버 운영에는 IT 전문 인력의 도움이 필요하다고 설명한다.

🧩 배경과 문제 정의

• AI로 도메인 지식을 가진 실무자가 직접 웹서비스를 만들 수 있어도, 무엇을 해결할지 정하는 기획 과정은 필요하다.
• 실습의 출발점은 원무과에서 사용할 웹페이지가 필요하다는 요구다. 반복 업무와 서류 발급 문의를 구체화해 실제로 유용한 기능을 정해야 한다.
• 소크라테스식 인터뷰로 요구사항을 기획서로 만들고, Sites로 구현한 뒤 사용자 관점의 테스트와 수정 요청을 반복한다.
• 웹페이지를 만든 이후에는 공개 범위, 회원 관리, 관리자와 일반 사용자의 권한, 서비스 규모에 맞는 개발 환경까지 검토해야 한다.

🕒 시간순 섹션별 상세정리

1. 도메인 전문가에게도 기획은 필요하다

• 기존 개발에서는 분야 전문가와의 미팅을 바탕으로 기획서와 설계서를 작성하고, 디자인과 코딩을 거쳐 결과물을 납품했다. AI가 등장하면서 도메인 지식을 가진 사람이 원하는 결과물을 직접 만드는 방식이 가능해졌다 [00:34]
• 직접 개발하더라도 기획은 필요하다. 무엇을 만들고 어떻게 구현할지를 AI와 편하게 대화하면서 구체화할 수 있다 [01:14]

2. AI가 질문하는 소크라테스식 인터뷰

• AI에 소크라테스 역할을 부여해 무엇을 만들고 싶은지, 왜 필요한지를 사용자에게 질문하도록 한다. 사용자가 질문하는 대신 AI가 요구사항을 끌어내는 방식이다 [02:04]
• 충분한 기획에는 30~50번 질문하기도 하지만 실습에서는 최대 10개로 제한한다. 답하기 쉬운 객관식을 기본으로 하되 주관식 답변도 허용한다 [02:34]

3. 반복 문의를 업무 흐름과 응답 목표로 구체화한다

• 질문은 직원이 자주 겪는 문제, 반복 문의의 주요 유형, 서류 발급 문의가 반복되는 이유로 좁혀진다. 이전 답변의 맥락을 유지하면서 다음 요구사항을 확인한다 [04:10]
• 발급 시점을 답하는 데 필요한 정보, 직원이 원하는 화면과 상세 정보, 상태를 변경할 담당자를 구체화한다. 원무과 직원이 변경할지, 담당 부서가 자기 단계만 변경할지도 검토한다 [04:43]

4. 인터뷰 결과를 구현용 기획서로 전환한다

• 10개 질문을 마치면 인터뷰 내용을 바탕으로 기획서를 작성한다. 자동으로 작성되지 않으면 지금까지의 인터뷰를 토대로 기획서를 작성해 달라고 요청한다 [05:34]
• 기획서가 완성되면 실제 웹페이지 구현으로 넘어간다. 기획 대화는 유지하고 새 탭에서 작업을 시작한다 [06:18]

5. Work 모드에서 모델과 추론 강도를 설정한다

• 장시간 작업과 복잡한 작업에는 Work 모드를 사용한다. 실습에서는 GPT6 루나 모델을 선택한다 [06:39]
• 추론 강도는 미디엄으로 설정한다. 실습에서 제시한 선택 기준은 코딩에 필요한 토큰 소모를 줄이는 것이다 [07:05]

6. Sites에 기획서를 텍스트나 파일로 전달한다

• 기획서 응답을 복사한 뒤 “아래의 기획서대로 개발해 줘”라는 요청 아래에 붙여 넣는다. 작업 지시와 기획서 본문은 줄바꿈과 구분선으로 나눈다 [07:28]
• 구현 요청에는 Sites 옵션이 활성화되어 있어야 한다. 기획서를 별도로 보관하려면 MD 파일로 저장해 달라고 요청할 수 있다 [08:17]

7. 작업 시간과 사용량을 확인하며 구현한다

• Sites로 웹사이트를 만드는 작업에는 Work 모드를 사용한다. 구현 시간은 보통 5~30분 정도지만, 분량과 복잡도에 따라 2~3시간처럼 길어질 수도 있다 [10:55]
• 모델에 따라 토큰 소진 속도가 달라질 수 있다. 실습자의 테스트에서는 GPT6 루나와 미디엄 조합의 토큰 소모가 크지 않았다 [11:29]

8. 같은 기획서에서도 구현 결과는 달라질 수 있다

• AI는 코드를 생성할 때도 확률적으로 다음 내용을 구성하므로 같은 요구사항에서 서로 다른 소스코드가 나올 수 있다 [13:43]
• 코드의 차이는 화면 디자인과 구조의 차이로 이어질 수 있다. 생성된 페이지가 의도대로 작동하는지는 사용자 관점에서 직접 테스트해야 한다 [14:15]

9. 등록과 상태 변경이 실제로 동작하는지 검증한다

• 생성된 화면에는 테스트 환자 7건과 의사 확인 중·발급 가능·오늘 접수 등의 정보가 표시된다. 환자를 선택하면 오른쪽에서 진행 상황을 확인하고 상태를 변경할 수 있다 [15:41]
• 서류 등록 메뉴에서 환자 정보, 진료과, 신청 서류를 입력하고 등록한다. 입력한 정보가 목록에 실제로 추가되는지 확인해야 한다 [16:32]

10. 빠진 수정 기능을 화면 위치와 함께 요청한다

• 실무 활용 가능성을 판단하려면 화면의 만족도뿐 아니라 빠진 기능도 확인해야 한다. 실습 결과에서는 서류 상태를 바꿀 수 있지만 환자 관련 정보를 수정하는 기능은 없는 것으로 보였다 [17:36]
• 수정 요청 기능에서 환자 이름을 지정하고, 이름을 선택하면 관련 서류 정보를 수정하는 화면이 나오도록 요청한다. 수정할 위치와 원하는 동작을 함께 전달한다 [18:34]

11. 생성된 사이트는 비공개 링크로 먼저 접근한다

• 생성된 웹페이지는 이미 서버에 배포된 상태이며, 작업 화면의 제목 아래 링크로 별도 브라우저에서 열 수 있다 [20:27]
• 초기 접근 권한은 본인에게만 있으므로 계정 인증이 필요하다. 인증을 마치면 생성된 서류 발급 현황 페이지에 접속할 수 있다 [21:00]

12. 공유 권한을 바꾸면 외부에서도 접속할 수 있다

• 공유 메뉴에서 링크 접근 권한을 ‘나만’에서 ‘인터넷 사용자 누구나’로 변경하고 게시한다. 다른 사용자에게는 접속할 사이트 주소를 전달해야 한다 [22:09]
• 방문자는 제작자의 컴퓨터가 아닌 서버에 접속한다. 제작자의 컴퓨터가 꺼져도 사이트를 볼 수 있으며, 다시 본인만 접근하도록 바꾸기 전까지 공개 상태가 유지된다 [22:59]

13. 회원 관리와 역할별 권한을 추가한다

• 공개 사이트에는 회원가입과 로그인이 필요할 수 있다. 관리자는 전체 관리와 수정 권한을 갖고, 일반 사용자는 자기 상태를 조회하되 수정하지 못하도록 역할을 구분할 수 있다 [23:43]
• 회원가입·로그인·로그아웃과 관리자·일반 사용자 기능은 전문 IT 용어 없이 원하는 동작을 말로 설명해 추가 요청할 수 있다 [24:32]

14. 소셜 로그인은 외부 서비스 설정까지 연결해야 한다

• 구글·애플 계정 로그인은 추가 설정이 필요한 기능이다. 구글 로그인에는 구글 클라우드 콘솔 작업이 필요하며, 이메일과 비밀번호만 사용하는 방식에는 사용자가 가입 정보나 비밀번호를 잊는 불편이 있다 [25:57]
• 웹 설정 작업을 AI에 맡기는 방법으로 자막에서 ‘어사이드’라고 부르는 도구를 활용한다. 구글 로그인에 필요한 클라우드 콘솔 설정을 요청하고, 설정 결과를 사이트에 연결하는 방법도 물어보는 방식이다 [26:58]

15. 서비스 규모에 따라 개발 환경을 확장한다

• Sites 플러그인으로 대부분의 웹사이트를 만들 수 있다는 설명이지만, 기능과 규모가 큰 전사 서비스는 어려울 수도 있다. 이 경우 데스크톱 앱과 로컬 코딩 환경을 마련하는 방향을 제안한다 [27:49]
• 로컬 개발 방법은 AI에게 질문하거나 유튜브와 관련 서적으로 학습할 수 있다. 더 전문적으로 공부하려면 코덱스나 바이브 코딩 관련 자료를 활용한다 [28:17]

16. 보안이 중요한 병원의 자체 서버 운영

• 해커가 서비스의 보안을 뚫으면 정보가 유출될 수 있으며, 이에 대한 대응은 서비스 제공 회사에 맡겨야 한다 [30:07]
• 보안이 중요한 병원은 자체 서버를 만들고, 해당 서버에 서비스를 직접 탑재해 운영해야 한다 [30:17]

17. 자체 운영에 따른 배포 난도와 전문 인력 필요

• 자체 서버에서 서비스를 운영하면 자동화된 배포를 이용할 때보다 배포 작업이 어려워진다 [30:24]
• 서버를 직접 운영하려면 IT 팀의 전문적인 도움이 반드시 필요해진다 [30:28]

🧾 결론

• 도메인 지식을 가진 실무자가 AI로 직접 개발하더라도, 해결할 문제와 완료 기준을 정하는 기획은 필요하다.
• 기획서 전달 이후에도 사용자 관점의 테스트와 구체적인 수정 요청을 반복해야 현장 업무에 맞는 서비스에 가까워진다.
• 웹페이지 구현 이후에는 공개 범위, 회원 관리, 역할별 권한, 서버 운영 방식까지 결정해야 한다.

📈 투자·시사 포인트

• AI 활용 역량에는 결과물 생성뿐 아니라 문제를 질문으로 좁히고 검증 가능한 요구사항으로 바꾸는 능력이 포함된다.
• 도입 효과를 살필 때는 화면 완성도와 함께 반복 문의 처리 흐름, 답변 목표 시간, 누락 기능을 확인필요가 있다.
• 개발 도구를 선택할 때는 구현 시간과 토큰 사용량뿐 아니라 서비스 규모와 운영 환경도 함께 검토해야 한다.
• 병원처럼 보안을 중요하게 다루는 조직에서는 배포 편의성과 자체 운영에 필요한 전문 인력·작업 난도를 함께 판단해야 한다.

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

• Work 모드, GPT6 루나, Sites의 설정과 사용 방식은 자료 속 실습 기준이다. 현재 계정에서 동일한 기능과 선택지가 제공되는지는 이 자료만으로 확인할 수 없다.
• 구현 시간 5~30분과 토큰 소모에 대한 설명은 작업 복잡도와 실습 경험에 따른 것이다. 모든 프로젝트의 소요 시간이나 비용을 보장하지 않는다.
• 회원 관리와 구글 로그인은 추가 요청 및 외부 설정을 연결하는 방식으로 설명된다. 최종 구현과 권한 통제가 실제로 검증되었는지는 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• AI가 사용 목적과 반복 업무를 질문하도록 하고, 필요한 정보·담당자·목표 응답 시간을 답변으로 구체화한다.
• 인터뷰 결과를 기획서로 정리해 Sites에 전달하고, 사용할 모드와 작업 중 사용량을 확인한다.
• 테스트 환자로 서류 등록, 목록 반영, 단계별 상태 변경, 정보 수정 기능을 확인한다.
• 빠진 기능은 수정할 화면 위치와 기대 동작을 함께 적어 요청하고, 수정 후 같은 업무 흐름을 다시 확인한다.

❓ 열린 질문

• 환자 조회부터 답변까지 5초라는 목표가 실제 업무 환경에서도 달성되는가?
• 상태 변경 권한은 원무과에 모을 것인가, 담당 부서가 자기 단계만 변경하도록 나눌 것인가?
• 회원 관리와 소셜 로그인을 추가한 뒤 사용자별 정보 접근과 수정 권한을 어떻게 검증할 것인가?