AI와 함께
일하는 법.

사람의 손과 붉은 커서, 문서, 톱니바퀴가 함께 놓인 AI 생성 협업 조형물

혼자서는 어려운 일도
함께라면, 여기까지.

전문가와 AI가 작은 업무 세계를 함께 만드는 생성 이미지 — HUMAN × AI

사람이 방향을 정하고,
AI와 함께 결과를 만듭니다.AI와 처음으로 무언가를 같이 만들려고 하는 사람들을 위한 기초지침서

01 / 28 · 시작과 전체 흐름

스스로 공부하기

처음부터 차근차근

이 자료는 AI의 이름을 많이 외우기보다, 내가 하려는 일을 AI와 나누고 결과를 확인하는 방법을 익히는 안내서입니다. 프로그래밍을 모르더라도 시작할 수 있습니다. 다만 무엇을 만들려는지, 어떤 자료를 써도 되는지, 무엇이 맞는 결과인지는 사람과 AI가 대화하며 분명히 해야 합니다.

먼저 알아둘 말

AI: 인공지능의 줄임말입니다. 이 자료에서는 주로 사람의 글이나 질문을 받아 설명·문서·코드 등의 결과를 만드는 AI를 다룹니다.
프롬프트: AI에게 보내는 질문이나 작업 요청입니다. 특별한 주문이 아니라 동료에게 일을 설명하는 문장이라고 생각하면 됩니다.
검증: 결과가 그럴듯해 보이는지에 그치지 않고, 원자료·계산·실제 동작과 맞는지 확인하는 일입니다.

왜 사람이 방향을 정해야 할까요?

“워크숍 안내를 만들어줘”만으로는 누구에게, 언제, 어떤 방식으로 안내할지 알기 어렵습니다. 같은 자료라도 신입 참여자용 안내와 담당자용 점검표는 달라야 합니다. 먼저 “참여자가 준비물을 빠뜨리지 않게 하려는 안내”처럼 목적을 말하면 AI가 무엇을 강조할지 판단하는 데 도움이 됩니다.

이 자료를 읽는 순서

앞부분에서는 역할과 요청 방법을 배우고, 중간에서는 자료 형식과 작은 프로그램을 살펴봅니다. 뒷부분에서는 저장·검증·변경 기록·자동화로 이어집니다. 각 화면의 버튼은 설명을 바꾸는 체험입니다. 버튼을 눌렀다는 사실이 실제 AI 호출이나 외부 시스템의 실행을 뜻하지는 않습니다.

화면에서 따라 하기

상단의 “스스로 공부하기”를 켜면 현재 화면 아래의 상세 설명을 읽을 수 있습니다. 켠 상태로 다음 화면에 가면 그 화면의 해설도 이어서 읽습니다.
표지의 “함께 시작하기”로 다음 내용에 들어갑니다. 이전·다음 버튼이나 목차를 이용하고, 입력창을 조작하지 않을 때는 방향키로 이동할 수도 있습니다.
필요한 개념만 보고 싶으면 “개념 전시실”이나 목차 검색을 사용합니다. 전시실의 “시작하기”는 실습을 초기 상태로 돌리고 이 표지에서 다시 시작합니다. 맞은 횟수 카운터는 초기화 대상에서 제외됩니다.

결과를 읽는 방법

한 번에 모두 이해할 필요는 없습니다. 예를 들어 “신청을 함께 저장하려면?”이 궁금하면 프론트·백엔드·DB 화면으로 이동한 뒤, 모르는 용어를 앞뒤 화면에서 찾아보면 됩니다.

헷갈리기 쉬운 점

AI를 잘 쓰는 능력은 어려운 명령어를 많이 아는 능력과 같지 않습니다. 목적을 설명하고, 필요한 맥락을 보태며, 나온 결과를 비교하고 고치는 과정이 핵심입니다.

이해 확인 · AI가 워크숍 안내문을 만들었다면, 그대로 보내기 전에 무엇을 확인할까요?

해설 행사 날짜·대상·장소·신청 방법을 원자료와 대조합니다. 문장이 자연스러워도 잘못된 날짜가 있으면 안내 목적을 달성하지 못합니다.

다음 화면에서는 AI·LLM·GPT라는 이름이 각각 무엇을 가리키는지 구분합니다.

02 / 업무를 이해하고 나누기

AI는 넓은 범주,
GPT는 모델 계열입니다.

기술의 범주 → 모델의 종류 → 사용하는 환경을 구분합니다.

개념을 눌러 차이와 대표 예시 확인하기

AI · 인공지능

인식·예측·생성처럼 지능적인 일을 수행하는 기술의 넓은 범주입니다.

예측·분류·추천도 AI의 활용입니다.

AI / 대표 활용 예시

상품 추천선호에 맞는 항목 제안
이미지 인식사진 속 대상 분류
스팸 분류메일을 자동으로 구분

ChatGPT는 모델과 도구를 사용하는 서비스입니다.

도구를 고를 때는 어떤 자료로, 어떤 결과를 만들지 먼저 정합니다.

네 개념을 한눈에 다시 보기

AI는 넓은 기술 범주, LLM은 많은 언어 데이터를 학습한 모델의 종류, GPT는 OpenAI의 모델 계열, ChatGPT는 사용하는 서비스입니다. GPT 계열에는 이미지·음성을 함께 다루는 모델도 있으며 지원 형식은 모델마다 다릅니다. 도해는 개념 이해를 위한 단순화입니다.

OpenAI · 모델 예시 Anthropic · Claude Google · Gemini ChatGPT 사용 환경모델명 예시 · 2026.10.15 공식 문서 확인

02 / 28 · AI · LLM · GPT

스스로 공부하기

처음부터 차근차근

AI, LLM, GPT, ChatGPT는 모두 같은 종류의 이름이 아닙니다. AI는 넓은 기술 범주, LLM은 언어를 중심으로 다루는 모델의 종류, GPT는 OpenAI의 모델 계열 이름입니다. ChatGPT는 사용자가 모델과 도구를 이용하는 서비스입니다. 모델과 그 모델을 쓰는 서비스를 구분하면 기능 설명을 덜 혼동하게 됩니다.

먼저 알아둘 말

모델: 학습을 통해 입력에서 결과를 만들어내도록 구성한 계산 체계입니다. 자동차에 비유하면 일을 수행하는 엔진에 가깝습니다.
LLM: Large Language Model, 즉 대규모 언어 모델입니다. 많은 언어 자료에서 패턴을 학습해 문장을 이해하고 생성하는 작업에 사용합니다.
생성형 AI: 기존 항목을 분류하는 데서 그치지 않고 글·이미지·음성·코드 같은 새로운 결과를 만드는 AI입니다. 모든 AI가 대화형 생성 AI인 것은 아닙니다.

큰 범주에서 구체적인 이름으로

사진 속 물체 찾기, 상품 추천, 스팸 분류도 AI의 활용입니다. 그중 언어를 다루는 모델을 설명할 때 LLM이라는 말을 씁니다. GPT·Claude·Gemini는 서로 다른 회사의 모델 계열 이름입니다. GPT 계열 안에서도 모델이 여러 가지일 수 있습니다. 화면의 겹친 도형은 이 관계를 단순화한 학습 그림입니다.

이름만으로 사용 가능 기능을 단정하지 않기

같은 모델을 사용해도 파일 읽기·인터넷 검색·코드 실행 도구가 연결되어 있는지에 따라 할 수 있는 일이 달라집니다. 최신 모델이라는 이름만 보고 내가 가진 폴더나 비공개 자료를 이미 읽을 수 있다고 생각하면 안 됩니다. 모델의 능력과 작업 환경의 도구·권한을 함께 확인해야 합니다.

화면에서 따라 하기

왼쪽의 AI를 눌러 상품 추천·이미지 인식·스팸 분류 예시를 읽습니다. 세 예시 모두 반드시 대화창이 있어야 하는 기능은 아닙니다.
LLM을 눌러 대표 모델 계열 예시로 내용이 바뀌는지 확인합니다. 이어서 GPT를 눌러 한 계열 안의 모델 예시를 살펴봅니다.
아래의 ChatGPT 설명을 읽고 “GPT라는 모델을 ChatGPT라는 서비스에서 사용한다”는 문장을 자신의 말로 다시 설명해 봅니다.

결과를 읽는 방법

세 버튼을 바꾸면 설명과 대표 예시도 달라집니다. 제품·모델 이름은 바뀔 수 있으므로 이름 자체보다 “기술 범주 → 모델 → 사용하는 환경”의 관계를 기억하면 됩니다.

헷갈리기 쉬운 점

AI는 모두 챗봇이라는 뜻이 아니며, GPT와 ChatGPT도 같은 이름이 아닙니다. 또한 최신 계열의 모델은 글뿐 아니라 다른 종류의 입력을 다룰 수 있으므로, 이 그림을 모든 모델의 기능을 엄밀하게 나누는 분류표로 보지는 않습니다.

이해 확인 · “이 AI가 내 컴퓨터의 파일을 고칠 수 있나요?”라는 질문에는 모델 이름만 알면 답할 수 있을까요?

해설 아닙니다. 파일에 접근하고 수정할 도구가 있는지, 어느 환경에서 실행하는지, 해당 폴더에 권한이 있는지도 확인해야 합니다.

이제 모델 이름보다 실제 업무에서 AI와 사람이 맡을 역할을 살펴봅니다.

더 읽기 · 원문과 공식 안내ChatGPT · Chat·Work·Codex 사용 안내 ↗

03 / 업무를 이해하고 나누기

초안은 맡기고, 해석은 함께.
최종 판단은 사람이 합니다.

같은 ‘워크숍 운영 보고서’ 안에서도 역할은 달라집니다.

보고서 문장 정리

AI가 제공된 내용을 요약합니다. 담당자는 날짜·대상·수치와 누락을 원문에 대조합니다.

교육용 분담 기준과 가상 업무 사례입니다. ‘AI에게 맡기기’도 무검토 사용을 뜻하지 않습니다.

03 / 28 · 맡기기 · 함께하기 · 책임

스스로 공부하기

처음부터 차근차근

하나의 업무를 통째로 “AI가 한다” 또는 “사람이 한다”로 나누면 중요한 차이가 사라집니다. 보고서 한 건 안에도 문장 다듬기, 해석, 대안 선택, 최종 승인처럼 성격이 다른 단계가 있습니다. 이 화면은 그 단계마다 중심 역할을 달리 정하는 연습입니다.

먼저 알아둘 말

초안: 검토와 수정을 전제로 만든 첫 결과입니다. AI가 만든 글이나 표가 완성품처럼 보여도 처음에는 초안으로 다루는 것이 좋습니다.
해석: 숫자나 의견이 무엇을 뜻하는지 설명하는 일입니다. 같은 수치도 조사 대상과 현장 조건에 따라 의미가 달라집니다.
승인·책임: 결과를 실제 업무에 적용할지 결정하고 그 영향에 대해 설명하는 역할입니다. AI가 문장을 써줬다고 승인 권한까지 생기지는 않습니다.

자료와 기준이 분명한 작업부터 맡기기

공지 내용을 세 줄로 줄이거나 문서의 항목을 표로 옮기는 일은 결과를 원문과 비교하기 쉽습니다. AI에게 초안을 맡기고, 사람이 날짜·대상·숫자·빠진 조건을 확인합니다. “맡긴다”는 말에는 확인할 기준을 주고 결과를 받는 과정까지 포함됩니다.

현장 맥락과 최종 선택은 따로 확인하기

설문에서 “시간을 늘려 달라”는 의견이 나왔다고 운영 시간을 바로 늘릴 수는 없습니다. 응답자의 범위, 예산, 강사 일정, 다른 참여자의 부담도 함께 봐야 합니다. AI는 의견을 묶고 대안을 비교할 수 있지만, 담당자는 실제 여건과 승인 절차를 확인해 최종 선택을 합니다.

화면에서 따라 하기

“AI에게 맡기기”를 눌러 문장 요약 사례를 읽습니다. 원문과 나란히 놓고 비교할 수 있는 작업인지 생각합니다.
“AI와 함께하기”를 눌러 운영안 비교 사례를 읽습니다. AI가 알기 어려운 현장 조건을 세 가지 적어 봅니다.
“사람이 책임지기”를 눌러 예산 확정 사례를 읽습니다. 누가 결재하고 어떤 근거를 남겨야 하는지 구분합니다.

결과를 읽는 방법

각 버튼에서 업무 사례와 사람의 확인 역할이 달라집니다. 같은 보고서를 만드는 동안에도 AI 초안 → 공동 검토 → 사람의 승인으로 역할이 이동할 수 있습니다.

헷갈리기 쉬운 점

AI에게 맡기는 영역이 있다고 해서 무검토 사용이 허용되는 것은 아닙니다. 반대로 사람이 책임진다고 모든 문장과 계산을 손으로 해야 하는 것도 아닙니다. 도구의 도움과 최종 판단을 구분하는 것이 목적입니다.

이해 확인 · AI가 예산 비교표와 추천안을 만들었습니다. “추천했으니 예산도 확정했다”고 볼 수 있을까요?

해설 아닙니다. 추천안은 판단에 쓰는 자료입니다. 실제 비용·집행 기준·승인 권한을 확인한 사람이 예산을 확정해야 합니다.

다음 화면에서는 이렇게 역할을 나눴을 때 AI에게 요청할 수 있는 구체적인 작업을 봅니다.

04 / 업무를 이해하고 나누기

요약에서 도구 제작까지,
확인 가능한 초안을 맡깁니다.

결과 형식을 선택하고, 어떤 요청과 검증이 필요한지 확인하세요.

요청의 예

“이 공지를 세 줄로 줄여줘.”

자료를 제공하고 대상과 말투를 정합니다.

확인할 것 → 날짜 · 대상 · 신청 방법

OpenAI · Use ChatGPT가능한 기능은 모델·계정·연결된 도구·기관 설정에 따라 달라집니다.

04 / 28 · GPT가 할 수 있는 일

스스로 공부하기

처음부터 차근차근

AI가 도울 수 있는 작업을 막연히 “뭐든지”라고 생각하기보다, 입력할 자료와 확인할 결과로 나누면 요청하기 쉬워집니다. 이 화면의 네 사례는 요약, 초안 구성, 계산 도구 제작, 클릭하는 교육 페이지 제작입니다. 복잡해 보이는 결과물도 작은 작업들을 이어서 만들 수 있습니다.

먼저 알아둘 말

요약: 원자료의 핵심을 정해진 길이와 목적에 맞게 줄이는 일입니다. 줄이는 과정에서 중요한 조건이 빠지지 않았는지 봐야 합니다.
변환·구성: 같은 내용을 다른 형식으로 옮기거나 순서를 정리하는 일입니다. 문장을 표로 바꾸거나 메모를 운영안으로 구성하는 것이 예입니다.
구현: 설명한 요구를 실제로 작동하는 화면이나 코드로 만드는 일입니다. 구현 완료와 결과 검증 완료는 별개입니다.

입력과 결과를 함께 말하면 요청이 선명해집니다

“잘 정리해줘”보다 “이 공지를 참여자에게 보낼 세 줄 안내로 줄이고 날짜·신청 링크는 반드시 남겨줘”가 구체적입니다. 사용할 자료, 대상, 원하는 길이, 빠뜨리면 안 되는 항목을 함께 주면 결과를 확인할 기준도 생깁니다.

AI가 결과를 만들려면 작업 환경도 필요합니다

문장 설명만 하는 대화와 실제 파일을 만들거나 코드를 실행하는 작업은 필요한 도구가 다를 수 있습니다. 예를 들어 계산 코드를 제안받은 것과 그 코드를 실행해 숫자를 확인한 것은 다릅니다. 결과를 받으면 파일이 실제로 열리는지, 버튼이 작동하는지, 계산값이 맞는지를 직접 확인합니다.

화면에서 따라 하기

요약 사례를 눌러 날짜·대상·신청 방법이 확인 항목으로 남는 이유를 읽습니다.
운영안 초안과 설문 집계 사례를 차례로 눌러, 각각 필요한 자료가 어떻게 다른지 비교합니다. 운영 조건과 점수 처리 기준은 서로 다른 맥락입니다.
교육 페이지 사례를 누르고 “읽을 문서”와 “눌러서 작동하는 도구”의 차이를 생각합니다. 후자에는 클릭 반응과 실행 확인이 추가됩니다.

결과를 읽는 방법

선택한 작업에 따라 요청 예시와 확인할 항목이 바뀝니다. 화면의 선택은 설명을 보여주는 체험이며, 여기서 새 AI 작업을 실제로 실행하지는 않습니다.

헷갈리기 쉬운 점

문장이 자연스럽고 디자인이 좋아 보인다고 내용과 기능이 모두 맞는 것은 아닙니다. 요약의 누락, 근거 없는 수치, 열리지 않는 파일, 잘못된 계산은 각각 다른 기준으로 찾아야 합니다.

이해 확인 · “설문 결과를 정리해줘”라는 요청에 한 문장을 더한다면 무엇이 좋을까요?

해설 “1~5점 응답만 포함하고 빈칸과 범위 밖 값은 제외한 뒤, 유효 응답 수·평균·제외 이유를 표로 보여줘”처럼 판단 기준과 결과 형식을 보탤 수 있습니다.

이런 작업도 자료·도구·권한이 준비되어야 가능하다는 점을 다음 화면에서 확인합니다.

05 / 업무를 이해하고 나누기

자료·도구·권한이 있어야
실제로 일할 수 있습니다.

“작년 워크숍 참여자 수를 확인해줘.”라는 요청을 가정합니다.

어떤 상황인가요?

상황을 하나씩 선택해 비교하세요.

자료가 필요합니다

미공개 내부 사실을
근거 없이 알 수 없습니다.

자료를 직접 제공하거나, 허용된 시스템의 원자료를 읽을 수 있어야 합니다.

HUMAN근거 확인
최종 승인
결과의 책임조건이 갖춰져도
사람의 판단은 남습니다.

상황별 설명을 비교하는 학습 예시입니다. 실제 파일이나 시스템에 연결하지 않습니다.
OpenAI · 결과 검토 권한과 접근 범위

05 / 28 · AI의 한계와 사람의 책임

스스로 공부하기

처음부터 차근차근

AI가 많은 일반 지식을 알고 있어도 비공개 내부 사실을 자동으로 아는 것은 아닙니다. “작년 워크숍 참여자 수를 확인해줘”라는 요청은 실제 명단이나 결과보고서를 읽어야 답할 수 있습니다. 이 화면은 자료, 연결 도구, 접근 권한이 각각 왜 필요한지 구분합니다.

먼저 알아둘 말

원자료: 답의 근거가 되는 실제 기록입니다. 결과보고서·참여 명단·담당 시스템의 조회 결과 등이 여기에 해당합니다.
도구 연결: AI가 파일이나 서비스에 접근해 필요한 기능을 사용할 수 있게 연결한 상태입니다. 연결만으로 모든 자료가 공개되는 것은 아닙니다.
접근 권한: 누가 어떤 자료를 읽거나 바꿀 수 있는지 정한 범위입니다. 사람에게 보이는 자료와 자동화 계정이 읽을 수 있는 자료가 다를 수 있습니다.

자료가 없을 때는 무엇을 해야 할까요?

AI가 그럴듯한 참여자 수를 말하더라도 원자료가 없으면 확인된 숫자가 아닙니다. 필요한 파일을 직접 제공하거나, 담당자가 허용한 시스템을 조회할 경로를 마련해야 합니다. 자료가 없다는 사실과 찾을 수 있는 다음 방법을 분명히 말하도록 요청하는 것이 좋습니다.

도구가 있어도 권한과 자료의 존재를 따로 봅니다

검색 도구를 연결했다고 모든 폴더와 내부 DB를 읽을 수 있는 것은 아닙니다. 해당 도구가 필요한 조회를 지원하는지, 계정에 권한이 있는지, 찾는 자료가 실제로 있는지를 확인합니다. 숫자를 얻은 뒤에도 연도·행사 범위·신청자와 실제 참여자의 차이까지 점검해야 합니다.

화면에서 따라 하기

“자료·연결 없음”을 선택하고 근거 없이 내부 사실을 알 수 없다는 설명을 읽습니다.
“원자료 직접 제공”과 “도구만 연결”을 비교합니다. 파일을 받았는지와 도구 이름이 보이는지는 서로 다른 조건입니다.
“도구·권한 준비”를 선택하고 조회 후에도 사람이 확인할 근거·최종 승인·책임이 남는 이유를 읽습니다.

결과를 읽는 방법

왼쪽의 네 상황을 고를 때 가운데 설명이 달라집니다. 이 페이지는 접근 조건을 설명하는 모형이므로, 실제 파일이나 기관 시스템에 연결하거나 권한을 변경하지 않습니다.

헷갈리기 쉬운 점

“연결되어 있다”와 “정확한 답을 얻었다”는 같은 말이 아닙니다. 예를 들어 올해 신청자 명단을 읽고 작년 실제 참여자 수라고 답하면 접근에는 성공했어도 질문에는 틀린 것입니다.

이해 확인 · 읽기 도구는 연결됐지만 작년 행사 폴더를 열 수 없습니다. AI가 다른 해의 숫자로 대신 답해도 될까요?

해설 안 됩니다. 접근하지 못한 범위를 밝히고, 올바른 원자료를 제공받거나 허용된 조회 방법을 확인해야 합니다. 다른 해의 수치는 별도 참고자료일 뿐입니다.

다음은 자료를 주고 한 번에 끝내기보다, 대화와 확인을 반복하는 협업 과정입니다.

06 / 업무를 이해하고 나누기

AI의 제안에 현장 맥락을 더하고,
함께 고쳐 완성합니다.

가상 사례: 만족도 설문에서 다음 학기 워크숍 운영안 만들기

사람의 전문성 × AI의 구현

“다음 학기에 무엇을 바꿀까?”

대상, 원자료, 예산·일정, 원하는 운영안 형식과 확인 기준을 공유합니다.

만족도 평균만으로 학습 효과를 단정하지 않습니다.

협업 과정에서 확인하는 질문

누가 응답했고 빠진 의견은 무엇인가? 응답의 대표성은 충분한가? 실제 수업에 적용했는가? 제안이 예산·일정·운영 여건에 맞는가? AI가 정리한 주제와 원문이 일치하는가?

교육용 가상 사례입니다. 생성 이미지는 실제 센터 행사 사진이 아닙니다.

06 / 28 · AI와 함께 완성하기

스스로 공부하기

처음부터 차근차근

AI와의 협업은 요청 한 번으로 끝나는 주문보다, 초안을 함께 다듬는 작업에 가깝습니다. 목적과 기준을 정하고, 필요한 자료로 초안을 만들고, 실제 상황과 비교한 뒤 수정합니다. 이 과정을 짧게 반복하면 무엇이 부족했는지 더 구체적으로 알 수 있습니다.

먼저 알아둘 말

맥락: 결과의 방향을 바꾸는 배경 정보입니다. 대상·목적·자료·일정·예산·제약·좋은 예시 등이 포함됩니다.
피드백: 현재 결과가 요구와 어떻게 다른지 알려주는 말입니다. “별로야”보다 “대상과 신청 방법이 빠졌어”가 수정에 도움이 됩니다.
재검증: 수정한 뒤 같은 오류가 사라졌는지, 다른 부분이 새로 틀리지는 않았는지 다시 확인하는 일입니다.

첫 초안은 부족한 조건을 발견하는 계기가 됩니다

“다음 학기 워크숍 운영안을 만들어줘”라는 요청에서 AI가 대규모 행사를 제안했는데 실제 대상은 15명일 수 있습니다. 이때 “참여자는 15명이고, 한 시간 안에 실습까지 해야 해”라고 조건을 보태면 초안의 방향을 고칠 수 있습니다. 처음 요청이 완벽하지 않아도 대화로 정교하게 만들면 됩니다.

수정 요청에도 근거와 우선순위를 줍니다

설문 의견을 묶는 기준이 어색하면 어떤 의견이 다른 주제에 들어가야 하는지 예를 듭니다. 디자인이 참고 예시와 다르면 색·배치·정보의 크기·클릭 반응 중 무엇이 다른지 구분합니다. 한 번에 모두 바꾸기 어렵다면 “핵심 내용 누락부터 고치자”처럼 우선순위를 정합니다.

화면에서 따라 하기

맥락 정하기 단계에서 대상·목표·사용 자료와 원하는 결과 형식을 읽습니다. 내가 해야 할 업무에 대입해 빈 항목을 찾아봅니다.
초안 만들기와 함께 확인하기를 차례로 누릅니다. 자료에 있는 사실과 AI가 제안한 해석·대안을 나누어 읽습니다.
수정·재검증 단계에서 처음 정한 기준으로 돌아갑니다. 고친 결과를 원문·숫자·실제 클릭 동작과 다시 대조합니다.

결과를 읽는 방법

단계마다 대화의 질문과 설명이 바뀝니다. 실제 협업에서는 앞으로만 진행하는 것이 아니라, 확인 중 새 조건이 드러나면 앞 단계로 돌아가 자료와 기준을 보완할 수 있습니다.

헷갈리기 쉬운 점

수정을 여러 번 했다는 이유만으로 실패한 작업이라고 볼 필요는 없습니다. 다만 같은 지적을 반복한다면 요청이 모호한지, 기준이 바뀌었는지, 필요한 도구가 없는지를 점검해야 합니다.

이해 확인 · AI가 제안한 운영안을 현장에 적용하기 어렵습니다. 어떤 피드백이 도움이 될까요?

해설 “강사는 한 명이고 60분 안에 마쳐야 하며, 참여자 15명은 초보자야. 이 조건에서 활동 두 개로 줄이고 준비물을 표로 다시 정리해줘”처럼 구체적인 제약을 줄 수 있습니다.

앞에서 배운 역할 구분을 세 가지 짧은 사례로 확인해 봅니다.

07 / 업무를 이해하고 나누기

맡기는 기준을 정하면
협업이 쉬워집니다

세 가지 업무 단계에서 중심이 되는 역할을 골라보세요.

이 단계는
누가 주도하면 좋을까요?

같은 업무 안에서도 역할이 바뀝니다. 선택 후 AI의 몫과 사람의 몫을 함께 확인합니다.

교육용 분류 퀴즈입니다.
실제 AI 호출이나 개인별 평가 기록은 없습니다.

사례 1 / 3정답 0 / 3

1. 공지 3줄 초안: AI가 표현을 정리하고 사람이 날짜·대상·신청 방법을 확인합니다.

2. 설문 해석과 개선안: AI와 함께하고 사람이 대표성·현장 맥락·실행 가능성을 판단합니다.

3. 예산 확정·결재: AI가 검토 자료를 도울 수 있지만 사람이 승인하고 책임집니다.

07 / 28 · 업무 분담 퀴즈

스스로 공부하기

처음부터 차근차근

이 퀴즈는 정답 수로 AI 활용 능력을 평가하려는 것이 아닙니다. 한 업무의 어느 단계에서 AI가 중심이 되고, 어느 단계에서 사람의 해석이나 승인이 필요한지 이유를 설명하는 연습입니다. 답을 고른 뒤 해설을 읽는 것이 점수를 맞히는 것보다 중요합니다.

먼저 알아둘 말

작업 단계: 업무 전체가 아니라 지금 수행하는 구체적인 일입니다. 초안 작성과 최종 발송은 같은 공지 업무 안에서도 다른 단계입니다.
대표성: 수집한 의견이나 응답이 설명하려는 전체 집단을 얼마나 잘 보여주는지에 관한 문제입니다. 응답 수만 많다고 모든 입장이 포함되는 것은 아닙니다.
판단 근거: 선택한 이유를 확인할 수 있게 남기는 자료와 기준입니다. 원문, 수치, 운영 여건, 승인 기준이 근거가 될 수 있습니다.

세 사례의 답을 읽는 방법

공지 세 줄 초안은 자료와 형식이 비교적 분명하므로 AI가 표현을 정리하는 역할을 맡기기 좋습니다. 설문 해석과 개선안은 숫자·의견에 현장 맥락을 더해야 하므로 함께 검토합니다. 예산 확정·결재는 권한 있는 사람이 승인하고 책임지는 단계입니다.

답의 경계를 과도하게 넓히지 않습니다

첫 사례를 AI에게 맡기기로 골라도 날짜와 신청 방법은 사람이 확인해야 합니다. 둘째 사례에서 AI가 의견을 잘 묶었다고 소수 의견이나 조사에 응하지 않은 사람의 상황까지 알 수 있는 것은 아닙니다. 셋째 사례에서도 AI는 예산 비교표를 만들거나 누락 항목을 찾는 데 도움을 줄 수 있습니다.

화면에서 따라 하기

현재 사례를 읽고 “이 단계에서 중심이 될 역할”을 고릅니다. 업무 전체를 AI에게 넘길 수 있는지를 묻는 문제가 아니라는 점을 기억합니다.
선택 뒤 나타나는 설명에서 AI가 할 일과 사람이 확인할 일을 각각 찾아봅니다. 예상과 다르면 분류 이유를 읽습니다.
다음 사례로 이동해 세 사례를 모두 봅니다. “처음부터”는 이 퀴즈를 다시 풀기 위한 버튼이며 실제 업무 기록을 삭제하는 기능이 아닙니다.

결과를 읽는 방법

선택에 따라 피드백과 사례 진행 상태가 바뀝니다. 여기의 점수는 이 페이지 안의 학습 표시이며 개인별 평가 자료를 외부로 보내지 않습니다.

헷갈리기 쉬운 점

업무 분담은 영구적인 직업 분류가 아닙니다. 같은 설문 보고서에서도 숫자 정리는 AI에게 맡기고, 의견 해석은 함께하며, 최종 개선안 승인은 사람이 할 수 있습니다.

이해 확인 · 공지 초안의 역할을 AI에게 맡기기로 골랐습니다. 최종 발송까지 자동으로 승인된 것일까요?

해설 아닙니다. 초안 작성과 발송 승인은 다른 단계입니다. 날짜·대상·신청 방법과 발송 범위를 확인한 뒤 사람이 사용 여부를 결정합니다.

이제 어떤 작업 환경에서 AI와 대화하고 결과를 만드는지 살펴봅니다.

HOW YOU DELEGATE

작업을 맡기는 방식

대화할 때도,
일을 맡길 때도.

기능의 경계보다
어떻게 함께 일할지 고릅니다.

주력 방식은 다르고, 기능은 겹칩니다.

Chat도 파일 요약과 후속 수정이 가능합니다. Work와 Codex 모두 문서·발표·연구에 활용할 수 있습니다.

내 업무 선택

파트너 표현은 이해를 돕는 교육용 비유입니다.

대화 중심

Chat

상담·대화 파트너

질문을 주고받으며 생각을 정리하고,
초안과 답을 후속 대화로 다듬습니다.

대상·목표를 논의하고 주제와 설문 문항을 함께 다듬습니다.

주로 확인 내용 · 논리 · 근거

작업 진행 중심

Work

단계를 이어 수행하는 작업 파트너

목표와 자료를 주면 계획을 세우고,
파일·도구를 다루며 여러 단계를 진행합니다.

기존 운영안과 수요를 읽고 일정을 구성한 뒤 운영안·안내문 파일을 준비합니다.

주로 확인 결과물 · 자료 반영 · 완료 조건

구현·검증 중심

Codex

구현·검증하는 개발 파트너

코드와 파일을 구현·수정하고,
실행·테스트·변경 비교를 자세히 확인합니다.

신청 안내 페이지가 필요하면 구현하고 오류와 실제 동작을 점검합니다.

주로 확인 실제 동작 · 테스트 · 변경 사항

Work로 맡기는 여러 단계의 예

자료 읽기계산·정리파일 제작검토

환경을 고를 때 확인할 점

세 카드는 필수 순서나 기능의 한계를 뜻하지 않습니다. 대화를 이어 갈지, 목표 중심의 여러 단계를 맡길지, 기술 세부와 변경 사항을 자세히 볼지에 따라 선호하는 환경을 고릅니다. Chat에서도 후속 대화와 파일 작업이 가능하며 Work와 Codex의 핵심 능력은 겹칩니다. 실제 도구·자료 접근 범위와 기능은 요금제·플랫폼·기관 설정에 따라 달라집니다.

OpenAI · Chat / Work / Codex 비교 OpenAI · Work의 여러 단계 작업시나리오는 교육용 예시입니다.

08 / 28 · Chat · Work · Codex

스스로 공부하기

처음부터 차근차근

Chat·Work·Codex는 기능이 서로 전혀 겹치지 않는 세 상자가 아닙니다. 무엇을 중심으로 일하고 어떤 화면으로 결과를 확인하는지가 다릅니다. 대화로 문제를 정리할 때, 여러 단계의 일을 맡겨 결과물을 받을 때, 코드와 변경 내용을 자세히 확인할 때를 구분하면 시작점을 고르기 쉽습니다.

먼저 알아둘 말

Chat: 질문·설명·아이디어 정리처럼 대화를 주고받으며 생각을 발전시키는 데 알맞은 시작 방식입니다. 파일 요약이나 문안 수정 같은 활용도 가능합니다.
Work: 원하는 결과를 정하고, 사용할 수 있는 자료와 도구로 여러 단계를 수행해 검토 가능한 결과물을 만드는 작업 방식입니다.
Codex: 개발 도구와 코드·실행·변경 비교 등을 자세히 살피기 좋은 환경입니다. 코딩 외의 문서·연구 작업에도 사용할 수 있어 Work와 활용 범위가 겹칩니다.

같은 설문 보고서를 세 관점으로 볼 수 있습니다

Chat에서는 “이 문항의 뜻이 무엇인지, 이런 해석이 과한지”를 대화로 검토할 수 있습니다. Work에서는 제공한 응답을 읽고 집계·정리해 표와 보고서 파일을 만드는 작업을 맡길 수 있습니다. Codex에서는 반복 집계 코드를 만들고, 잘못된 입력을 시험하며 수정 내용을 자세히 비교할 수 있습니다.

이름보다 지금 필요한 결과를 먼저 봅니다

Chat에서도 이어지는 질문과 수정 요청을 주고받을 수 있으므로 “연속된 대화는 못 한다”고 이해하면 안 됩니다. Work와 Codex 역시 필요한 도구·파일·실행 환경이 있어야 작업합니다. 실제 지원 기능은 계정·플랫폼·관리자 설정에 따라 달라질 수 있습니다. 한 환경에서 요구를 정리한 뒤 다른 환경에서 제작을 이어가는 방법도 있습니다.

화면에서 따라 하기

“워크숍 기획”을 선택하고 대화·결과물 제작·구현 검증이 각각 어떤 일을 하는지 읽습니다.
“설문 보고서”와 “집계 도구 제작”으로 바꾸어 같은 세 카드의 예시가 어떻게 달라지는지 비교합니다.
내가 지금 필요한 것이 설명인지, 검토할 파일인지, 실행되는 프로그램인지 한 문장으로 적습니다. 그 결과와 사용할 수 있는 도구를 기준으로 시작 환경을 정합니다.

결과를 읽는 방법

업무 선택을 바꾸면 카드의 설명과 아래 작업 흐름이 바뀝니다. 이 체험이 실제 Chat·Work·Codex로 전환하거나 각 환경의 기능을 켜는 것은 아닙니다.

헷갈리기 쉬운 점

Chat은 대화만, Work는 문서만, Codex는 코드만 할 수 있다고 나누지 않습니다. 겹치는 능력을 인정하되 파일 접근과 실행, 결과 검토에 필요한 환경이 준비되어 있는지를 확인하는 것이 중요합니다.

이해 확인 · 코딩을 모르는 사람은 Codex를 쓰면 안 될까요?

해설 그렇지 않습니다. 자연어로 원하는 결과를 설명하며 사용할 수 있습니다. 다만 결과의 실제 동작을 확인하고, 권한이나 변경 내용을 이해하기 어려운 부분은 설명을 요청해야 합니다.

작업 환경을 정했다면, 먼저 AI와 맥락을 쌓고 필요한 질문을 주고받는 방법을 살펴봅니다.

더 읽기 · 원문과 공식 안내ChatGPT · Chat·Work·Codex 사용 안내 ↗

09 / 맥락과 자료 준비

작업 전에는 토론하고,
모르면 방법까지 묻습니다.

모든 도구의 사용법을 미리 알 필요는 없습니다.

원자료 · 서식 · 좋은 예시 · 목적 · 제약
결과의 기준을 바꾸는 정보를 공유하세요.

AI와 나누는 대화의 예

바로 만들기 전에 내 목적과 조건을 함께 정리하자.
부족한 맥락을 질문하고, 어떤 자료가 필요한지 알려줘.

먼저 대상·목적·결과 형식과 확인 기준을 함께 정합니다.

막혔을 때 확인할 순서

어떤 작업의 어느 단계인지, 오류와 환경을 공유합니다.
자료·형식·권한·도구·실행 환경 중 원인을 구분합니다.
가능한 대안과 사람이 할 다음 행동을 확인합니다.
작은 자료로 다시 실행하고 원래 목표를 달성했는지 확인합니다.

주소를 AI가 읽지 못하면 원문을 제공합니다. 설치 가능 여부와 권한은 실제 환경에서 확인합니다.

OpenAI · 맥락과 결과 수정요청문은 교육용 예시입니다.

09 / 28 · 맥락 쌓기 · 모르면 질문

스스로 공부하기

처음부터 차근차근

AI에게 요청할 때 처음부터 완성된 설명을 준비할 필요는 없습니다. 내가 아는 것과 모르는 것을 말하고, AI가 질문하도록 해서 필요한 맥락을 함께 채울 수 있습니다. 이 화면에는 맥락 정리, 사용법 질문, 막힌 경로 찾기, 인터뷰 요청이라는 네 가지 대화 시작 방법이 있습니다.

먼저 알아둘 말

제약: 결과가 지켜야 하는 조건입니다. 예산·시간·사용 가능한 도구·개인정보 처리 범위 등이 해당합니다.
인터뷰 방식: AI가 필요한 질문을 순서대로 하고, 내가 답하면서 목적과 조건을 구체화하는 대화 방식입니다.
확인 기준: 만든 결과가 적절한지 판단할 수 있는 구체적인 조건입니다. “좋은 자료”보다 “초보자가 10분 안에 따라 할 수 있는 세 단계 안내”가 확인하기 쉽습니다.

네 대화 방법은 상황에 따라 골라 씁니다

01 맥락부터 쌓기는 바로 만들기 전에 목적과 필요한 자료를 정리하는 요청입니다. 02 모르는 건 질문하기는 설치법·사용법도 AI와 함께 알아볼 수 있다는 뜻입니다. 03 막히면 경로 찾기는 어느 단계에서 실패했는지와 가능한 대안을 묻는 방법입니다. 오류가 났다면 오류 문구와 이미 해본 방법을 같이 줍니다.

04에서는 AI에게 인터뷰를 맡깁니다

예를 들어 “워크숍을 기획하고 싶은데 무엇부터 말해야 할지 모르겠어. 인터뷰어가 되어 필요한 질문을 한 번에 1~3개씩 해줘”라고 시작합니다. AI가 대상·인원·시간을 물으면 내가 답합니다. 답변이 모이면 목적·조건·기준을 요약하게 하고, 틀린 점을 고친 뒤 그 답변을 근거로 운영안이나 도구를 만들게 합니다.

화면에서 따라 하기

01~04 버튼을 차례로 눌러 오른쪽의 요청문과 설명이 달라지는지 확인합니다. 지금 상황과 가장 가까운 것을 선택합니다.
“이 요청문 복사”를 누르고 사용할 AI 대화창에 붙여 넣습니다. 주소·오류 메시지·현재 환경처럼 대괄호로 표시된 부분은 실제 정보로 바꿉니다.
인터뷰 방식에서는 질문에 답하고, AI가 정리한 요약을 반드시 읽습니다. 아직 정하지 않은 조건은 미정이라고 남기고, 확인한 내용으로 작업을 이어갑니다.

결과를 읽는 방법

버튼은 미리 준비한 대화 예시를 보여줍니다. 이 화면 자체가 AI 인터뷰를 실행하지는 않습니다. 복사한 뒤 실제 AI와 대화를 이어가야 질문과 답변이 오갑니다.

헷갈리기 쉬운 점

질문을 AI에게 맡긴다고 내가 모든 답을 미리 알아야 하는 것은 아닙니다. “그건 아직 모르겠어. 선택지와 각각의 영향을 설명해줘”라고 답해도 됩니다. 다만 AI가 모르는 기관 조건을 사실처럼 대신 정하지 않게 해야 합니다.

이해 확인 · 인터뷰 중 AI가 정원을 30명으로 요약했는데 나는 정원을 말한 적이 없습니다. 어떻게 할까요?

해설 “30명은 내가 정한 조건이 아니야. 정원은 미정으로 바꾸고, 정원을 정하는 데 필요한 질문을 해줘”라고 바로잡은 뒤 작업을 계속합니다.

반복해서 쓸 업무 절차와 자료를 스킬·플러그인으로 묶는 방법을 살펴봅니다.

REUSE THE WAY WE WORK

지침 → 도구 → 꾸러미

스킬은 지침,
플러그인은 묶음.

스킬의 중심은 AI가 읽는 SKILL.md입니다.
플러그인은 스킬·도구 연결 등을 묶습니다.

SKILL / 한남대FLOW의 조회·답변 지침

반복할 업무 방식을 적습니다.

언제 쓸지, 어떤 순서로 일할지, 무엇을 검증할지 정합니다. 한남대FLOW는 확인 시각 → 검색 → 조문 조회 → 근거 표시를 지침으로 재사용합니다.

Markdown 지침 자체가 실행 코드는 아닙니다.

오른쪽의 실제 파일을 눌러
지침·연결·배포판을 비교하세요.

HANNAM FLOW공개 배포판 · 발췌

skills/hannam-regulations/SKILL.mdMarkdown · 실제 지침 발췌원본 보기 ↗

한남대FLOW 지침을 불러옵니다.

실제 SKILL.md: 규정을 찾는 순서와 답변의 근거 기준을 적습니다.

공개 배포판 파일의 발췌를 보여줍니다.

HANNAM FLOW / 실제 파일 발췌·설명

SKILL.md

지침SKILL.md어떤 순서로 확인할까?

연결MCP 도구실제 조문을 가져오기

서비스h-rules사람과 AI가 같은 근거 활용

이 사례는 어떻게 개발했나요? · 업무에서 설치 배포판까지

업무 정의
규정 검색, 근거 조문 확인, 개정 전후 비교를 반복할 업무로 정합니다.
자료·서비스 개발
공식 규정을 수집·구조화하고, 사람이 열람할 화면과 AI가 호출할 API·MCP를 제공합니다.
지침 작성
SKILL.md에 조회 순서·근거 표기·미확인 정보 처리 기준을 적고 references/에 상세 안내를 둡니다.
배포판 구성
plugin.json + mcp.json + skills/를 묶습니다. GPTs용 지침·OpenAPI 명세 등 환경별 연결 자료도 준비합니다.
연결 확인·관리
설치 후 실제 조문을 조회해 출처와 함께 답하는지 확인합니다. 서버의 규정 갱신과 설치 파일의 갱신을 각각 관리합니다.

공개 설치 안내·배포판과 확인한 프로젝트 소스를 바탕으로 정리한 개발 흐름입니다.

스킬만으로도 쓸 수 있나요? · 형식과 사용 범위

스킬은 플러그인 없이 사용할 수도 있습니다. 플러그인은 스킬, 도구 연결 또는 둘을 함께 묶을 수 있으며, 스킬만 담은 플러그인도 가능합니다. 스킬에는 필요에 따라 참고자료·서식·실행 코드를 추가합니다. MD 지침은 AI가 읽고, Python 등의 실행 코드는 해당 실행 환경에서 동작합니다. 여기서는 한남대FLOW의 공개 GPT 통합 배포판을 예로 들었습니다. 연결 설정만 만든다고 서버 기능이나 자료 접근 권한이 생기지는 않습니다.

지금 연결한 한남대FLOW 앱과 통합 배포판의 구성 차이

이 PC에서 확인한 기존 앱형 플러그인은 .codex-plugin/plugin.json의 apps: "./.app.json" 설정과 .app.json의 등록 앱 참조로 연결합니다. hannam-regulations/SKILL.md는 별도 설치된 스킬입니다. 위 탐색기는 같은 서비스의 공개 통합 배포판 hannam-regulations-gpt/를 보여주며, 이 안에는 plugin.json·mcp.json·skills/가 함께 있습니다. 설치 방식에 따라 파일 구성은 달라집니다. 참고자료와 GPTs 폴더 일부만 표시했고, 서비스 구성도는 실제 파일이 아닌 설명용 도해입니다.

연결에는 자료와 권한 확인이 함께 필요합니다.

한남대FLOW · 공개 설치 안내 실제 통합 배포판 OpenAI · 플러그인 구성2026.10.15 확인 · 실제 파일 발췌와 설명용 구성도를 구분합니다. 이 페이지는 설치·외부 조회를 실행하지 않습니다.

10 / 28 · 스킬 · 플러그인

스스로 공부하기

처음부터 차근차근

반복하는 업무 방식을 AI에게 매번 길게 설명하지 않으려면 지침과 자료를 묶어 재사용할 수 있습니다. 스킬은 업무 절차와 참고자료를 제공하고, 연결 도구는 실제 조회·실행 기능을 제공합니다. 플러그인은 이런 스킬이나 도구 연결 등을 설치할 수 있게 묶는 배포 단위입니다.

먼저 알아둘 말

스킬·SKILL.md: 스킬은 SKILL.md라는 안내 문서를 중심으로 구성한 폴더입니다. 언제 사용할지, 어떤 순서로 처리할지, 무엇을 확인할지를 적고 참고자료·서식·선택적인 실행 스크립트를 함께 둘 수 있습니다.
플러그인: 사용자가 설치해 쓸 수 있는 기능 묶음입니다. 스킬만 포함할 수도 있고 도구 연결과 함께 구성할 수도 있습니다. 설치만으로 모든 외부 자료의 권한이 생기지는 않습니다.
MCP: Model Context Protocol의 줄임말입니다. AI가 외부 자료·도구와 요청과 결과를 주고받도록 정한 공통 연결 약속입니다. USB가 여러 기기를 같은 규격으로 연결하듯, MCP는 AI와 여러 도구를 연결하는 규격이라고 생각하면 쉽습니다.
MCP 서버·설정 파일: MCP 서버는 AI가 쓸 수 있는 자료·기능을 제공하는 쪽입니다. mcp.json은 어느 서버에 어떤 방식으로 연결할지 적는 설정 파일입니다. 실제 검색은 연결된 도구·서버가 합니다.

한남대FLOW 사례로 역할을 나눠 봅시다

사람은 h-rules.stoom.win 화면에서 규정을 찾아 읽고, AI는 연결된 조회 기능으로 검색 결과나 조문을 가져올 수 있습니다. 스킬은 먼저 자료 확인 시각을 살피고, 검색한 뒤 실제 조문을 읽고, 답에 근거를 표시하는 순서를 안내합니다. 규정 본문 전체가 스킬 문서에 들어 있는 것은 아닙니다.

MCP가 있으면 무엇이 달라지나요?

“휴학 규정을 찾아줘”라고 물었다고 해 봅시다. 연결된 조회 도구가 없다면 AI는 이미 배운 내용이나 사용자가 준 자료를 바탕으로 설명할 수 있지만, 이 질문만으로 해당 규정 서버를 실제 조회한 것은 아닙니다. 규정 검색 도구가 MCP로 연결되어 있다면 AI는 검색 요청을 보내고, 서버가 가져온 규정과 조문을 받아 읽은 뒤 근거와 함께 설명할 수 있습니다. AI가 실제 자료를 확인하고 도구로 일을 하도록 연결하는 길이라고 생각하면 쉽습니다.

MCP가 직접 검색하거나 AI를 새로 학습시키나요?

역할을 세 가지로 나눠 보세요. 스킬은 “먼저 검색하고 원문을 읽은 뒤 출처를 붙여라”라는 일하는 순서입니다. MCP는 “어떤 도구가 있는지 알려주고, 요청과 결과를 이 형식으로 주고받자”라는 연결 약속입니다. 실제 규정을 찾는 기능은 도구·서버가 제공합니다. 연결했다고 AI가 규정 전체를 학습하거나 영구히 외운 것은 아닙니다. 필요한 때 자료를 받아 활용합니다.

검색 외의 도구도 연결할 수 있나요?

검색·계산·파일 조회·일정 확인처럼 서로 다른 기능도 연결할 수 있습니다. 다만 실제로 무엇을 할 수 있는지는 연결한 서버가 제공하는 기능과 사용자의 권한에 따라 정해집니다. 읽기 기능만 연결했다면 수정·삭제 기능이 저절로 생기지는 않습니다. MCP는 연결 방식의 한 예이며, AI가 도구를 쓰는 모든 방법이 반드시 MCP인 것은 아닙니다.

폴더 안의 파일은 서로 다른 일을 합니다

화면의 공개 통합 배포판 예시에서는 plugin.json이 꾸러미의 이름·버전 등 정보를, mcp.json이 도구 연결을, skills/ 아래의 SKILL.md가 업무 지침을 담습니다. references/api.md는 도구 인자와 참고 설명입니다. GPTs용 instructions.md와 OpenAPI 명세는 다른 사용 환경에서 같은 서비스를 연결하는 자료입니다. 패키지 형식은 환경에 따라 다를 수 있습니다.

화면에서 따라 하기

스킬·도구 연결·플러그인을 선택합니다. 도구 연결에서는 USB처럼 공통 규격으로 연결한다는 비유와, AI의 요청 → 실제 도구 조회 → 결과로 답변의 세 단계를 읽습니다.
파일 목록에서 SKILL.md, plugin.json, mcp.json, 참고자료와 서비스 구성도를 차례로 선택해 오른쪽의 내용과 설명을 읽습니다. 경로는 폴더 안의 파일 위치를 뜻합니다.
개발 흐름을 읽고 업무 정의 → 자료·서비스 준비 → 지침 작성 → 패키지 구성 → 연결 확인으로 이어지는 과정을 이해합니다. 교육 화면에서 실제 설치·규정 조회는 실행하지 않습니다.

결과를 읽는 방법

선택한 파일에 따라 지침·JSON 설정·설명용 구성도가 바뀝니다. 실제 파일의 발췌와 역할을 설명한 도해는 표시를 보고 구분합니다. 원본 연결 안내는 인터넷이 필요합니다. 도구 연결을 선택하면 쉬운 MCP 설명과 규정 조회 흐름이 추가로 표시됩니다.

헷갈리기 쉬운 점

SKILL.md는 사람이 읽을 수 있는 자연어 지침이므로 그 자체를 고정 실행 프로그램과 동일하게 보지 않습니다. 같은 지침도 실제 입력·도구·권한에 따라 처리 과정이 달라질 수 있습니다. 반대로 별도 실행 스크립트가 포함됐다면 실행 환경과 검토가 추가로 필요합니다.

이해 확인 · SKILL.md에 “규정을 검색하라”고 적으면 검색 기능도 자동으로 생길까요?

해설 아닙니다. 지침과 실행 기능은 다릅니다. 규정을 읽을 도구·서비스와 연결이 준비되어야 하며, 실제 결과가 없으면 근거를 확인했다고 말할 수 없습니다.

이제 AI에게 제공할 자료의 형식인 PDF와 JSON을 비교합니다.

더 읽기 · 원문과 공식 안내OpenAI · 스킬의 구성 ↗OpenAI · 플러그인의 구성 ↗한남대FLOW · 공개 서비스 ↗MCP · AI와 외부 도구를 연결하는 공통 규약 ↗

11 / 맥락과 자료 준비

PDF는 문맥을,
JSON은 구조를
함께 줍니다.

목적에 맞는 형식과
확인할 근거를 같이 준비하세요.

출처단위결측

같은 교육용 가상 보고서를 비교합니다.
참여자 수는 16명이고 만족도 값은 없습니다.
PDF와 JSON 파일을 각각 받아볼 수 있습니다.

실제 PDF 페이지와 미리 정리한 JSON 비교 · AI 추출 실행 없음

실제 PDF를 렌더링한 페이지입니다. 클릭하면 확대해서 읽을 수 있습니다.

{
  "workshop_id": "W01",
  "participants_count": 16,
  "participants_count_unit": "명",
  "satisfaction_mean": null,
  "missing_reason": "예시 자료에 만족도 값 없음",
  "source": {
    "file": "가상_워크숍_결과보고서.pdf",
    "page": 1,
    "table": "운영 결과"
  },
  "data_status": "교육용 가상 값"
}

보고서의 문장·표·각주를 함께 읽습니다. JSON은 PDF 1쪽의 ‘운영 결과’ 표를 구조화한 예시입니다.

형식별 읽기와 AI에게 줄 요청문

PDF: 문장·배치·표·그림을 함께 확인하는 데 유용합니다. 모델·도구마다 처리 방식이 다르며, 지원되는 OpenAI PDF 입력은 추출한 텍스트와 페이지 이미지를 함께 사용합니다. 텍스트만 추출하는 도구는 배치와 그림을 충분히 전달하지 못할 수 있습니다.

JSON: 필드명과 객체·배열로 구조를 명시하고 ID로 관계를 표현합니다. 집계·비교에 유용하지만 올바른 문법이 올바른 값과 해석을 보장하지는 않습니다. 항상 토큰이 적은 형식도 아닙니다. null은 0을 뜻하지 않습니다.

제공한 PDF의 운영 결과 표를 정해진 JSON 필드로 정리해줘. 값의 의미와 단위, 원문 파일·쪽·표를 함께 적어줘. 없는 값은 null로 표시하고 이유를 남겨줘. 추출한 값은 원문과 대조할 수 있게 보여줘.

participants_count는 신청자 수가 아닌 실제 참여자 수입니다. 16명은 별도 가상 값이며 뒤의 신청 표 집계와 관계없습니다. 검토한 JSON을 집계에 쓰고 해석 근거는 원문으로 돌아가 확인합니다.

OpenAI · PDF 입력 MDN · JSON

11 / 28 · PDF · JSON

스스로 공부하기

처음부터 차근차근

같은 사실을 담아도 자료 형식에 따라 읽기 쉬운 부분이 다릅니다. PDF는 보고서의 문장·표·각주·배치를 함께 살펴보는 데 유용하고, JSON은 항목 이름과 값의 구조를 명시해 반복 처리하기 좋습니다. 어느 한 형식이 언제나 더 정확한 것은 아니며 서로 대조할 수 있게 준비하는 것이 중요합니다.

먼저 알아둘 말

PDF: 문서의 페이지 모양을 보존해 전달하는 형식입니다. 글자가 들어 있는 PDF와 글자를 사진으로 담은 스캔 PDF는 읽는 방법이 다를 수 있습니다.
JSON: 항목 이름과 값을 정해진 문법으로 적는 데이터 형식입니다. 예를 들어 participants_count: 16이라는 항목은 무엇을 센 숫자인지 이름으로 밝힙니다. 실제 JSON에서는 항목 이름에 큰따옴표를 씁니다.
결측·null: 값이 없거나 확인되지 않은 상태입니다. 만족도 값이 null이라는 것은 0점이라는 뜻이 아니며, 자료에 없는 점수를 계산해 채우면 안 됩니다.

화면의 가상 보고서를 읽어 봅시다

이 예시의 실제 참여자 수는 16명이고 만족도 평균은 자료에 없습니다. “실제 참여자 수”라는 표 제목·항목과 각주가 숫자의 의미를 설명합니다. 16명을 신청자 수나 만족도 응답 수로 바꾸어 읽으면 같은 숫자를 쓰더라도 해석이 틀립니다. 이 숫자는 뒤에 나오는 신청 표의 가상 기록 수와 별개의 예시입니다.

구조를 만들 때 의미와 출처도 남깁니다

PDF의 값을 JSON으로 옮길 때 숫자만 적으면 문맥이 사라지기 쉽습니다. 항목 이름, 단위, 값이 없는 이유, 원문 파일·쪽·표를 함께 남기면 다시 확인하기 쉽습니다. JSON 문법이 맞다는 사실은 내용까지 맞다는 뜻이 아닙니다. PDF를 읽는 도구마다 텍스트·그림 처리 방식도 달라 결과를 원문에 대조해야 합니다.

화면에서 따라 하기

“PDF 원문”을 선택하고 “크게 보기”로 실제 페이지를 읽습니다. 16명과 만족도 값 없음의 근거를 표와 각주에서 찾습니다.
“JSON 구조”를 선택해 participants_count, satisfaction_mean과 출처 정보가 같은 의미를 유지하는지 비교합니다.
필요하면 PDF와 JSON을 각각 내려받습니다. 아래의 형식별 설명에서 추출 요청문을 읽고, 없는 값을 null로 남기라는 조건을 확인합니다.

결과를 읽는 방법

PDF 버튼은 실제 PDF를 렌더링한 페이지를, JSON 버튼은 미리 구조화한 같은 자료를 보여줍니다. 버튼을 누르는 동안 AI가 새로 PDF를 추출하는 것은 아닙니다.

헷갈리기 쉬운 점

JSON이면 무조건 작고 정확하고, PDF이면 무조건 AI가 못 읽는다고 생각하면 안 됩니다. 작업 도구의 지원 방식과 원문의 복잡도, 추출 후 확인 과정에 따라 결과가 달라집니다.

이해 확인 · 참여자 수가 16명이고 만족도 평균이 null입니다. 평균 만족도를 0.0으로 보고해도 될까요?

해설 안 됩니다. null은 점수가 없다는 뜻입니다. “만족도 평균은 원자료에 없어 확인할 수 없음”이라고 표시하고, 계산하려면 실제 응답 자료를 확보해야 합니다.

다음 화면에서는 원문에서 글자·표·구조를 꺼내는 파싱과 OCR을 알아봅니다.

더 읽기 · 원문과 공식 안내MDN · JSON 자료 형식 ↗OpenAI · PDF 파일 입력 ↗

12 / 맥락과 자료 준비

문서를 읽는 것부터
다시 쓸 구조로 준비합니다.

파싱은 파일의 구조와 내용, OCR은 이미지 속 문자를 읽습니다.

종이 문서가 붉은 처리 기계를 지나 구조화된 블록으로 바뀌는 AI 생성 개념 삽화

문서 → 추출 → 구조 → 대조

4단계 학습 모형 · 실제 파일 처리·AI 호출 없음

원문 파일을 준비합니다

가상 운영계획의 제목과 일정표를 확인합니다.

가상 프로그램 운영계획

프로그램	운영일	단위
AI 협업	2026-10-21	1회

※ 구조 설명을 위한 가상 문서

KORDOC

HWP·HWPX·PDF·Office → Markdown·구조화 데이터
Office: DOCX·XLS/XLSX·PPTX · CLI와 MCP 제공 · MIT 라이선스

github.com/chrisryugj/kordoc

KORDOC 활용과 설치 요청문

여러 문서의 일정표·예산표를 반복 추출하거나 복잡한 한글 문서를 다룰 때 별도 파싱 도구가 유용합니다. CLI는 명령어로 쓰는 방식이고 MCP는 AI가 쓸 도구로 연결하는 방식입니다. 스캔 문서는 OCR과 파싱을 함께 쓸 수 있습니다.

변환 뒤 확인: 병합 셀, 주석, 금액의 단위, 두 단 문서의 읽기 순서 등이 빠지거나 바뀌었는지 원문과 대조합니다.

저장소: https://github.com/chrisryugj/kordoc
이 저장소 주소의 공식 설치 안내를 확인하고 내 환경 지원 여부와 설치 순서를 알려줘. 가능한 작업은 진행해줘.

사용하려는 AI에 붙여 넣어 환경 확인부터 시작하세요. 이 버튼은 복사만 합니다.

도구의 소개는 공식 README를 요약한 것입니다. 실제 문서로 결과를 확인하고 MIT 라이선스의 저작권·허가 고지 보존 조건도 확인합니다.

KORDOC · README KORDOC · LICENSE

12 / 28 · 파싱 · OCR · KORDOC

스스로 공부하기

처음부터 차근차근

AI에게 파일을 줬다고 문서의 모든 내용과 구조가 그대로 전달되는 것은 아닙니다. 문서를 읽는 과정에서 글자, 표, 제목, 각주를 꺼내는 처리가 필요합니다. 파싱은 문서의 구조와 내용을 읽어 다시 쓸 수 있게 정리하는 일이고, OCR은 이미지에 담긴 글자를 인식하는 일입니다.

먼저 알아둘 말

파싱: 파일에 들어 있는 내용과 구조를 분석해 꺼내는 과정입니다. 예를 들어 일정표의 프로그램명·날짜·횟수를 각각 구분해 읽는 일입니다.
OCR: Optical Character Recognition의 줄임말로, 사진이나 스캔 이미지 속 문자를 글자로 인식하는 기능입니다. 글자 인식과 표의 행·열 관계 이해는 서로 다른 문제입니다.
Markdown·CLI·MCP: Markdown은 제목·목록 등을 간단한 기호로 적는 문서 형식입니다. CLI는 글자로 명령을 입력하는 사용 방식, MCP는 AI가 연결된 도구를 호출하는 데 쓰는 규약입니다.

겉으로 잘 보이는 문서도 읽기 결과는 달라질 수 있습니다

표에서 “1회”라는 값이 나왔어도 어느 프로그램의 운영 횟수인지 연결이 빠질 수 있습니다. 병합된 칸, 표 아래의 단위, 두 단으로 나뉜 본문의 읽기 순서가 대표적인 확인 지점입니다. 스캔의 숫자 1을 다른 글자로 읽거나, 각주의 예외 조건이 누락되는 경우도 생각해야 합니다.

KORDOC는 문서를 준비하는 도구의 한 예입니다

공식 저장소에서는 HWP·HWPX·PDF·Office 문서를 Markdown 등으로 처리하는 도구로 안내합니다. 실제 지원 범위와 설치 조건은 해당 버전의 README에서 확인합니다. 어떤 형식이 지원된다는 말이 모든 복잡한 문서의 표·서식·OCR까지 완벽하게 복원한다는 뜻은 아닙니다. 먼저 작은 문서 한두 개로 필요한 내용이 제대로 읽히는지 시험합니다.

화면에서 따라 하기

입력 → 추출 → 구조화 → 원문 대조의 단계를 차례로 눌러봅니다. 원문 파일에서 프로그램명·날짜·운영 횟수가 어떤 정보로 바뀌는지 읽습니다.
구조화 결과에서 값뿐 아니라 단위와 원문 위치도 남아 있는지 확인합니다. 예시의 “1”이 인원인지 횟수인지 구별할 수 있어야 합니다.
설치 요청문을 복사하려면 공식 주소와 내 환경을 확인해 사용할 AI에게 줍니다. 이 교육 화면의 버튼은 요청문을 준비하며, KORDOC를 설치하거나 내 문서를 처리하지 않습니다.

결과를 읽는 방법

단계 버튼은 교육용 가상 운영계획을 바탕으로 미리 준비한 결과를 보여줍니다. 실제 문서를 처리할 때는 원본과 추출 결과를 나란히 놓고 몇 개의 값을 직접 찾아 대조합니다.

헷갈리기 쉬운 점

OCR을 했다는 이유만으로 표의 의미가 보존되는 것은 아닙니다. 반대로 텍스트가 들어 있는 문서에 항상 OCR부터 적용해야 하는 것도 아닙니다. 문서의 상태와 필요한 결과에 맞춰 처리 방식을 선택합니다.

이해 확인 · 추출 결과에 “운영 횟수: 1”이 있지만 원문에는 “연 1회, 별도 과정 제외”라는 각주가 있습니다. 무엇을 보완할까요?

해설 숫자와 단위뿐 아니라 연간 기준과 제외 조건도 함께 남겨야 합니다. 각주를 놓치면 표의 값은 맞아도 적용 범위를 잘못 이해할 수 있습니다.

준비한 자료를 AI에게 어떤 목표와 기준으로 사용할지 요청문으로 정리합니다.

더 읽기 · 원문과 공식 안내KORDOC · 프로젝트 공식 문서 ↗

13 / 맥락과 자료 준비

좋은 요청에는 목표와
검증 기준이 함께 들어갑니다

막연한 지시를 담당자가 확인할 수 있는 결과 요청으로 바꿉니다.

로컬 요청문 구성기 · 실제 AI 호출 없음

목표·자료·형식·검증 기준을 조합한 교육용 예시입니다. 입력은 이 페이지 안에서만 사용하며 저장·전송하지 않습니다.

13 / 28 · 협업 요청문 구성기

스스로 공부하기

처음부터 차근차근

좋은 요청문은 길고 어려운 문장보다, AI가 무엇을 해야 하고 내가 무엇으로 결과를 확인할지 분명한 문장입니다. 이 화면은 목적과 작업에 자료·형식·검증 조건을 하나씩 더하는 요청문 구성기입니다. 입력한 내용이 오른쪽 요청문에 어떻게 반영되는지 보면서 배울 수 있습니다.

먼저 알아둘 말

목적: 그 일을 통해 해결하려는 문제입니다. “보고서 만들기”라는 결과물 이름보다 “다음 프로그램의 개선안을 검토하기”처럼 사용 이유를 말하면 좋습니다.
범위·형식: 어디까지 다룰지와 어떻게 보여줄지를 정한 조건입니다. 특정 기간만 분석하기, 한 쪽 요약과 표로 제시하기 등이 예입니다.
불확실성 표시: 자료가 없거나 판단이 확실하지 않은 부분을 확인 필요로 남기는 것입니다. 빈칸을 그럴듯한 사실로 채우지 않도록 요청합니다.

작업과 목적은 다를 수 있습니다

작업이 “익명 설문 결과 정리”라도 목적은 만족도 보고, 다음 행사 개선, 홍보 문안 작성 중 무엇인지에 따라 달라집니다. 먼저 목적을 정하고, 그 목적에 맞게 필요한 작업을 설명합니다. 원자료와 근거를 제한하면 AI가 밖의 정보를 섞어도 되는지 판단하기도 쉬워집니다.

세 기준은 결과를 확인할 방법을 더합니다

자료·근거 사용을 선택하면 무엇을 바탕으로 작업할지 명확해집니다. 결과 형식·범위 지정은 표의 항목과 분석 대상을 정합니다. 검증 기준·불확실성 표시는 계산 기준과 모르는 부분의 처리 방식을 정합니다. 예를 들어 만족도 평균에는 척도와 결측 처리 규칙이 있어야 숫자를 다시 계산해 볼 수 있습니다.

화면에서 따라 하기

함께 할 일을 고르고 달성하려는 목적을 자신의 말로 적습니다. 오른쪽의 목적과 작업 문장이 어떻게 바뀌는지 확인합니다.
처음에는 모두 해제된 세 기준을 하나씩 선택합니다. 선택할 때마다 요청문에 어떤 정보가 추가되는지 읽습니다.
완성한 요청문을 복사하기 전에 사용할 파일·허용 범위·기관 기준을 실제 상황에 맞게 보완합니다. 제공하지 않은 자료를 이미 전달한 것처럼 적지 않습니다.

결과를 읽는 방법

요청문은 이 페이지 안에서 구성됩니다. 복사한 내용을 실제 AI에 보내는 동작은 사용자가 별도로 합니다. 이 화면이 원자료를 분석하거나 AI 답변을 생성하지는 않습니다.

헷갈리기 쉬운 점

체크 세 개를 모두 켰다고 요청이 자동으로 완성되는 것은 아닙니다. “정확하게 해줘”만으로는 확인할 수 없으므로 “합계가 원자료와 같은지 대조하고 제외한 행의 이유를 보여줘”처럼 구체적으로 정합니다.

이해 확인 · 평균 점수를 요청할 때 “검증해줘”를 더 구체적으로 쓰려면 어떻게 할까요?

해설 “1~5점의 유효한 숫자만 포함하고 빈칸·문자·범위 밖 값은 제외해줘. 포함 수·평균·제외 이유를 보여주고, 유효 값이 없으면 평균 없음으로 표시해줘”라고 적을 수 있습니다.

정리한 요구와 검증 기준으로 작은 프로그램을 만드는 바이브코딩 사례로 이어집니다.

MAKE. CHECK. MAKE BETTER.

자연어로 도구 만들기

말로 만들고,
결과로 확인.

이 교육에서 바이브코딩은 자연어로 요구를 설명하고
AI가 코드를 만드는 방식을 뜻합니다.

이 단계의 설명 더보기

“응답 값을 넣으면 유효 응답 수와 평균을 보여주는 작은 도구를 만들어줘. 빈칸은 제외해줘.”

사람이 계산 기준까지 설명합니다. 어떤 결과가 맞는지 알아야 확인할 수 있습니다.

사람이 원하는 결과를 먼저 말합니다.

이런 도구를
만들고 싶어요.

“설문 점수를 넣으면 유효 응답 수와 평균을 보여주는 작은 도구를 만들어줘. 빈칸은 제외하고, 1~5점 숫자만 계산해줘.”

입력: 3, 4, 빈칸, 5
처리 기준: 빈칸·문자·1~5점 범위 밖은 제외
원하는 결과: 유효 3개 · 평균 4.00합계 12 ÷ 응답 3개

지금은 요구 예시입니다. 다음 단계에서 이 요구를 받아 만든 첫 시제품을 봅니다.

설문 집계 수정품 · 기준 적용 완료

v1.0

계산에 포함—

계산 평균—

제외—

값을 바꾸고 계산해 보세요. 기본 예시의 유효 응답은 3개, 평균은 4.00입니다.

항목별 처리와 계산 기준

계산하면 어떤 값이 포함·제외됐는지 표시합니다.

평균 = 포함한 값의 합 ÷ 포함 수. 숫자가 아닌 값과 1~5 범위 밖의 값은 제외합니다. 시제품 v0.1은 빈칸·결측을 0점으로 잘못 포함하며, 수정품 v1.0은 제외합니다. 평균과 기대값은 소수 둘째 자리로 반올림해 비교합니다. 기대값 일치만으로 모든 계산이 검증된 것은 아닙니다.

입력한 값으로 실제 계산합니다. 저장·전송하지 않습니다.

시제품 이후에도 업무 적용 판단이 남습니다.

실제 업무에 도입하기 전

다른 자료에서도 계산이 맞는지, 데이터와 접근 권한을 어떻게 처리하는지, 오류 대응과 유지보수는 누가 맡을지 확인합니다. 코딩 경험이 적으면 숨은 오류를 찾기 어려울 수 있으므로 필요한 기술 검토를 함께 받습니다.

교육 목적의 바이브코딩 정의와 가상 제작 사례입니다. 집계 도구는 입력한 값을 브라우저의 JavaScript로 계산하며 실제 AI 호출은 없습니다.

14 / 28 · 바이브코딩

스스로 공부하기

처음부터 차근차근

이 화면은 요구를 말하고, 오류가 있는 첫 시제품을 받아 보고, 구체적인 수정을 요청해 고친 버전을 확인하는 과정을 보여줍니다. 왼쪽 네 단계를 누르면 오른쪽도 요구 예시 → 시제품 v0.1 → 결과 비교와 재수정 요청 → 수정품 v1.0으로 바뀝니다. 같은 자료를 이어서 비교하며 AI와 작은 도구를 만드는 협업 흐름을 익힙니다.

먼저 알아둘 말

시제품: 요구가 실제 화면과 동작으로 구현되는지 시험하기 위해 만든 첫 프로그램입니다. 완성된 운영 서비스로 보기 전에 기능과 오류를 확인합니다.
입력·출력: 프로그램에 넣는 값과 프로그램이 돌려주는 결과입니다. 여기서는 점수 목록이 입력, 유효 응답 수와 평균이 출력입니다.
예외 입력: 빈칸·문자·범위 밖 숫자처럼 정상적인 점수와 다른 입력입니다. 실제 사용에서는 이런 값도 들어올 수 있으므로 미리 다뤄야 합니다.

01 요구 설명에서는 만들고 싶은 도구의 예시를 봅니다

첫 화면은 계산기가 아니라 요구 예시입니다. “1~5점 설문에서 유효 응답 수와 평균을 보여줘. 빈칸은 제외해줘”라는 요청과 입력·처리 기준·원하는 결과를 적어 둡니다. 입력이 3, 4, 빈칸, 5라면 사람이 정한 정답은 유효 3개·평균 4.00입니다. 어떤 결과를 원했는지 먼저 알아야 시제품을 평가할 수 있습니다.

02 시제품은 일부 기능이 동작하지만 오류가 남아 있습니다

시제품 v0.1에는 입력창과 평균 계산이 구현되어 있습니다. 하지만 빈칸 제외 조건이 빠져 빈칸을 0점으로 포함합니다. 합은 12인데 응답 수를 네 개로 잘못 세어 평균 12÷4=3.00이 됩니다. 이 단계에서는 빠진 조건을 체크 하나로 고치지 않고, 실제로 오류가 있는 버전을 시험한 뒤 다음 단계에서 수정 요청을 만듭니다.

03 결과 확인에서는 차이를 근거로 재수정을 요청합니다

오른쪽에 현재 입력을 시제품 방식과 올바른 기준으로 계산한 결과가 나란히 나타납니다. 기본 예시라면 4개·3.00과 3개·4.00을 비교합니다. 그 아래에는 “빈칸을 합계와 응답 수에서 모두 제외해줘. 같은 자료로 다시 확인해줘”라는 구체적인 요청이 표시됩니다. 시제품에서 바꾼 입력도 비교에 이어서 사용합니다. 빈칸이 없는 자료라면 빈칸 예시로 다시 비교할 수 있습니다.

04 수정품 구현에서는 고친 버전을 직접 사용합니다

수정품 v1.0은 빈칸 제외 조건을 적용한 버전입니다. 같은 3, 4, 빈칸, 5로 유효 3개·평균 4.00·제외 1개가 나오는지 봅니다. 다른 입력도 직접 넣고 계산할 수 있습니다. 문자·1~5점 범위 밖의 값도 제외하며 유효 응답이 없으면 평균을 0으로 꾸미지 않고 계산 불가로 표시합니다.

수정 후에는 같은 자료와 다른 자료를 확인합니다

같은 입력으로 오류가 고쳐졌는지 확인한 뒤 1과 5, 숫자 한 개, 전부 빈칸, 문자가 섞인 경우도 시험합니다. 내가 예상한 평균을 적으면 계산 결과와 비교할 수 있습니다. 한 예시의 기대값이 맞았다는 사실만으로 모든 사용 상황의 정확성이 보장되지는 않습니다.

코드 보기는 수정품의 실제 실행 파일을 보여줍니다

상단의 완성본 HTML 코드 보기는 수정품 v1.0의 화면·모양·계산 코드를 엽니다. 네 단계의 설명 화면 자체가 아니라, 따로 내려받아 실행할 계산기의 코드입니다. 문법을 모두 외우기보다 입력창·계산 버튼·제외 기준·결과 표시가 각각 어디에 연결되는지 살펴보면 됩니다.

화면에서 따라 하기

01 요구 설명에서 입력 3, 4, 빈칸, 5와 원하는 결과인 유효 3개·평균 4.00을 읽습니다.
02 시제품 구현을 선택합니다. 오른쪽이 실제 입력·계산 화면으로 바뀌고 기본 예시가 응답 4개·평균 3.00으로 잘못 계산되는지 봅니다. 값을 바꾸거나 계산 버튼으로 다시 시험할 수 있습니다.
03 결과 확인을 선택해 현재 자료의 시제품 결과와 기준에 맞는 결과를 비교합니다. 아래 재수정 요청을 읽거나 복사합니다. 다른 입력에 빈칸이 없다면 빈칸 예시로 비교를 누릅니다.
04 수정품 구현을 선택하고 같은 자료에서 유효 3개·평균 4.00을 확인합니다. 전부 빈칸, 문자·범위 밖 값, 숫자 한 개도 넣어 보고 예시로 되돌릴 수 있습니다.
완성본 HTML 코드 보기에서 HTML·CSS·JavaScript와 전체 파일을 살펴봅니다. 내려받은 HTML은 네 단계 발표 화면 없이 수정된 계산기를 독립 실행합니다.

결과를 읽는 방법

네 단계는 설명 문구만 바꾸지 않고 오른쪽 화면과 계산 버전도 바꿉니다. 02의 빈칸 제외 조건은 미구현, 04는 적용된 상태로 고정되어 있습니다. 03은 같은 입력을 두 기준으로 비교하고 재수정 요청을 만듭니다. 계산과 비교는 이 브라우저 안에서 수행되며 실제 AI에 전송하지 않습니다.

헷갈리기 쉬운 점

시제품에 입력창과 버튼이 보이고 숫자가 나와도 계산이 맞는 것은 아닙니다. 오류를 발견하면 사람이 기대한 결과와 실제 결과의 차이를 설명하고 다시 요청합니다. 04의 완성본도 이 교육 예시의 요구를 구현한 버전이며, 실제 업무 적용 전에는 더 넓은 자료·조건을 확인해야 합니다.

이해 확인 · 3, 4, 빈칸, 5에서 평균이 3으로 나왔다면 어떤 오류를 의심할 수 있을까요?

해설 빈칸을 0으로 바꾸고 전체 네 개를 응답 수로 셌는지 확인합니다. 올바른 결과는 빈칸 제외, 유효 3건, 평균 4입니다.

작은 도구를 새로 만들기 전에 이미 공개된 도구를 활용할 수 있는지, 그 조건은 무엇인지 알아봅니다.

START FROM WHAT EXISTS

쓰고 · 고치고 · 나누기

이미 있는
도구에서
시작하세요.

오픈소스는 소스 코드와 함께
사용·수정·재배포 권한을 라이선스로 제공합니다.

공개 여부 · 비용 · 이용 권한은
각각 확인합니다.

예시로 살펴보기

열어보기 ↗

행 전체 또는 화살표를 눌러 내용을 직접 확인하세요.

문서 예시와 이 페이지의 실제 계산 도구를 엽니다. 설치·외부 연결은 하지 않습니다.

READ THE LICENSE

MIT·Apache 2.0은
코드를 쓰는 조건입니다.

두 라이선스 모두 사용·수정·재배포·상업적 이용을 허용합니다.
함께 지켜야 할 조건을 읽습니다.

MIT

MIT License

짧은 허용 조건.
저작권 표시와 허가문을 보존합니다.

복사·배포할 때: 복사본이나 소프트웨어의 상당 부분에 원래의 저작권 표시와 MIT 허가문을 함께 포함합니다.
특허 조항: Apache 2.0처럼 별도의 명시적 특허 허락 조항을 두지는 않습니다.

예 · MIT 코드를 포함해 도구를 나눌 때 원본 고지와 라이선스 문구를 함께 남깁니다.

MIT 원문 확인 ↗

Apache 2.0

Apache-2.0

고지·변경 표시·특허 조항.
재배포 조건을 구체적으로 정합니다.

재배포할 때: 라이선스 사본을 제공하고, 배포하는 소스의 해당 고지를 보존합니다. 수정한 파일에는 변경 사실을 눈에 띄게 표시하고, 원본에 NOTICE가 있으면 해당하는 고지를 함께 보존합니다.
특허 조항: 기여자가 허락할 수 있는 해당 기여 범위의 특허 사용을 명시합니다. 이 저작물·기여물이 특허를 침해한다고 소송을 제기하면 특허 허락이 종료되는 조건도 있습니다.

예 · Apache 코드를 고쳐 나눌 때 LICENSE, 변경 표시, 해당 NOTICE 고지를 확인합니다.

Apache 2.0 원문 · 3·4조 확인 ↗

소스 공개 이 두 라이선스 자체는 수정한 소스 코드 전체를 공개하도록 요구하지 않습니다.

보증과 별도 권리 둘 다 보증·책임 제한 조항이 있습니다. 함께 쓰는 라이브러리·이미지의 조건은 별도로 확인합니다.

직접 비교 · 수정한 도구를 다른 사람에게 나눠준다면?

가상의 라이브러리를 포함한 배포 폴더입니다. 라이선스를 바꿔 함께 남길 파일과 고지를 살펴보세요.

MIT / 고지를 함께 배포

workshop-tool/
├─ index.html
├─ vendor/
│  └─ chart.js
└─ third-party/
   └─ chart-LICENSE.txt

원래 저작권 표시와 MIT 허가문을 남깁니다.

가상의 chart.js를 포함한 예시입니다. chart-LICENSE.txt에는 짧은 요약 대신 원래 저작권 표시와 MIT 라이선스 문구를 포함합니다.

폴더명과 파일명은 설명용입니다. 실제 배포 방식에 맞게 고지·라이선스 포함 조건을 충족해야 합니다.

Apache 2.0의 특허 허락과 이름·로고 사용은 다른가요?

특허 허락은 3조에서 정한 기여자의 해당 특허 청구 범위에 적용됩니다. 모든 특허에 대한 포괄적 허락이라는 뜻은 아닙니다. 6조는 출처 설명 등 정해진 경우를 제외한 상표·제품명 사용 권한을 부여하지 않는다고 규정합니다.

Apache 공식 FAQ · 공식 원문의 핵심을 풀어 쓴 교육용 요약 · 2026.10.15 확인 · 적용할 버전과 실제 프로젝트의 LICENSE·NOTICE 원문을 기준으로 확인합니다.

GitHub 공개 저장소와 오픈소스의 차이

GitHub에 공개됐다고 모두 오픈소스는 아닙니다. 무료라는 이유만으로 수정·재배포 권한이 생기지는 않습니다. 오픈소스도 판매·운영·지원에 비용이 들 수 있습니다. 라이선스는 고지 보존 등의 조건을 정할 수 있으므로 공식 LICENSE를 읽고 업무에 적용할 조건을 확인합니다.

Open Source Initiative · Open Source Definition점검판은 도입 검토를 위한 교육용 예시입니다.

15 / 28 · 오픈소스 · MIT · Apache

스스로 공부하기

처음부터 차근차근

오픈소스는 소스 코드가 보인다는 사실에 더해, 라이선스가 정한 조건으로 사용·수정·재배포할 수 있는 소프트웨어입니다. “GitHub에 공개돼 있다”, “돈을 받지 않는다”, “업무에 수정해 써도 된다”는 서로 다른 말입니다. 사용할 도구를 찾았다면 공식 안내와 라이선스를 먼저 읽습니다.

먼저 알아둘 말

소스 코드: 프로그램을 어떻게 동작시킬지 적은 원본입니다. 사용자가 보는 화면 뒤의 계산과 처리 방법도 코드에 들어갈 수 있습니다.
라이선스: 저작권자가 다른 사람에게 어떤 이용을 허용하고 어떤 조건을 지키도록 하는지 적은 문서입니다. 무료 여부와는 별개입니다.
README·LICENSE·이슈: README는 설치·사용 안내, LICENSE는 이용 조건입니다. 이슈는 알려진 문제나 제안을 기록하는 공간으로, 내 환경에서 주의할 점을 찾는 데 도움이 됩니다.

MIT를 처음 읽을 때 볼 핵심

MIT는 사용·수정·복사·배포·판매 등을 폭넓게 허용하는 라이선스입니다. 다만 소프트웨어의 복사본이나 상당한 부분에 저작권 고지와 허가 고지를 포함해야 합니다. “마음대로 쓰되 이름과 조건은 지워도 된다”는 뜻이 아닙니다. 보증 없이 제공한다는 내용도 있으므로 내 업무에서 동작하는지는 직접 시험해야 합니다.

Apache 2.0에서는 배포 시 조건을 더 살핍니다

Apache 2.0도 폭넓은 이용을 허용하며 명시적인 특허 허가와 관련 조건을 포함합니다. 재배포할 때 라이선스 사본을 제공하고, 수정한 파일에 변경 사실을 알리며, 관련 고지를 보존하는 조건을 살펴야 합니다. 원본에 NOTICE가 있다면 그에 담긴 관련 고지의 처리도 확인합니다. 상표를 자유롭게 사용할 권한까지 자동으로 주는 것은 아닙니다.

라이선스 이름만 보고 모든 파일을 같게 취급하지 않습니다

프로젝트의 이미지·폰트·별도 의존성에는 다른 조건이 있을 수 있습니다. 실제 배포판의 LICENSE, NOTICE, 포함된 구성 요소의 조건을 읽습니다. 이 화면은 흔한 라이선스를 이해하는 입문 설명이며, 실제 이용 범위는 해당 원문과 적용 상황을 기준으로 판단합니다.

화면에서 따라 하기

확인판의 README 행 또는 오른쪽 화살표를 눌러 설치·사용 안내 예시를 읽습니다. 따라 하기 전에 필요한 환경과 실행 방법을 찾습니다.
LICENSE 행을 열어 MIT와 Apache 2.0의 허용 범위·고지·수정 표시 예시를 비교합니다. 라이선스 파일을 배포물에 남기는 상황을 생각해 봅니다.
지원 환경·변경·이슈와 작은 자료 시험 예시도 열어봅니다. 설치 가능 여부와 실제 계산이 맞는지는 서로 다른 확인이라는 점을 연결합니다.

결과를 읽는 방법

각 행은 체크 완료 표시가 아니라 구체적인 예시를 여는 버튼입니다. 이 페이지가 실제 저장소를 분석하거나 프로그램을 설치하는 것은 아닙니다.

헷갈리기 쉬운 점

소스가 공개됐거나 무료로 내려받을 수 있다고 수정·재배포 권한까지 생기는 것은 아닙니다. 반대로 오픈소스라고 해서 운영·지원·교육 비용까지 반드시 무료인 것도 아닙니다.

이해 확인 · MIT 도구를 수정해 동료에게 나눠줄 때 원래 LICENSE를 지워도 될까요?

해설 MIT의 저작권·허가 고지를 보존해야 하는 조건을 확인해 배포물에 포함합니다. 수정한 도구가 제대로 동작하는지는 별도로 시험합니다.

공개된 웹 도구의 파일에서 자주 만나는 HTML·CSS·JavaScript의 역할을 알아봅니다.

더 읽기 · 원문과 공식 안내Open Source Initiative · MIT 원문 ↗Apache · Apache License 2.0 원문 ↗

BUILD IN THE BROWSER

눈으로 보고 클릭하는 첫 결과물

아래 예시의 스타일과 클릭 동작만 전환합니다.

HTMLCSSJS.

구조를 놓고, 모양을 정하고,
클릭할 때의 동작을 만듭니다.

HTML 구조 있음

A SMALL START

워크숍 관심 표시

버튼을 눌러 숫자를 바꿔보세요.

HTML제목, 설명, 숫자, 버튼

CSS색, 크기, 여백, 배치

JavaScript클릭하면 숫자 +1

CSS와 JS를 하나씩 꺼보세요.

로컬 체험 · 입력과 숫자는 저장·전송되지 않습니다.

첫 출발점으로 좋은 이유와 한계

간단한 페이지는 브라우저만으로 실행하며 요청한 화면과 실제 결과를 비교하기 쉽습니다. HTML은 마크업 언어이고 JavaScript는 프로그래밍 언어입니다. 로그인·공동 저장·실시간 AI 연동이 필요한 큰 앱은 추가 구조와 서버 설계가 필요합니다.

MDN · 웹의 기본 기술첫 도구 선택은 이 교육의 설계 판단입니다.

16 / 28 · HTML · CSS · JavaScript

스스로 공부하기

처음부터 차근차근

웹페이지는 보통 내용의 구조, 겉모양, 동작을 나누어 생각할 수 있습니다. HTML은 제목·문단·버튼·입력칸 같은 구조를, CSS는 색·배치·크기 같은 표현을, JavaScript는 입력을 읽고 계산하거나 버튼에 반응하는 동작을 맡습니다. 세 가지를 한 HTML 파일 안에 넣어 만들 수도 있습니다.

먼저 알아둘 말

HTML: HyperText Markup Language입니다. 문서에 “여기는 제목”, “여기는 버튼”, “여기는 표”라는 구조와 의미를 표시합니다.
CSS: Cascading Style Sheets입니다. 글자 색과 크기, 여백, 배치, 화면 크기에 따른 모양 등을 정합니다.
JavaScript·JS: 브라우저에서 실행할 수 있는 프로그래밍 언어입니다. 클릭에 반응하고 입력값을 계산하거나 결과를 화면에 표시할 수 있습니다.

작은 카운터로 세 역할을 구분합니다

HTML로 “숫자 표시”와 “1 더하기 버튼”을 놓습니다. CSS로 버튼을 노란색으로 꾸밀 수 있습니다. JavaScript로 버튼을 누를 때 숫자를 하나 올리는 규칙을 연결합니다. 따라서 버튼 모양이 남아 있어도 동작 연결이 꺼지면 숫자는 바뀌지 않을 수 있습니다.

한 파일로도 작은 프로그램이 되는 이유

페이지 안의 JavaScript가 브라우저에서 계산하므로, 모든 클릭마다 외부 서버가 계산할 필요는 없습니다. 현재 발표 자료의 화면 전환이나 설문 계산도 이런 동작입니다. 다만 공동 기록이나 비밀키가 필요한 일은 화면 코드만으로 해결하기 어려워 다음 화면의 서버 역할을 함께 봐야 합니다.

화면에서 따라 하기

작은 예시의 더하기 버튼을 눌러 숫자가 바뀌는지 봅니다. 이 숫자는 예시의 브라우저 화면에서만 바뀝니다.
CSS를 끄고 다시 눌러봅니다. 모양은 단순해져도 JavaScript가 켜져 있으면 계산 동작은 남습니다.
JavaScript를 끄면 버튼과 숫자 구조는 남아 있지만 더하기 동작은 실행되지 않습니다. 두 설정을 다시 켜고 초기화 버튼으로 예시 숫자를 되돌려 봅니다.

결과를 읽는 방법

이 화면의 CSS·JS 버튼은 작은 예시 안의 표현과 동작만 전환합니다. 발표 자료 전체나 브라우저의 JavaScript 기능을 끄는 설정이 아닙니다.

헷갈리기 쉬운 점

CSS가 없으면 문서 내용까지 없어지는 것도, JavaScript가 있으면 서버 기능까지 자동으로 생기는 것도 아닙니다. 보이는 화면, 내 기기에서의 처리, 다른 사람과 함께 쓸 처리를 차례로 구분합니다.

이해 확인 · 버튼은 보이는데 누를 때 숫자가 늘어나지 않습니다. 무엇을 먼저 확인할까요?

해설 버튼 구조가 있다는 사실과 동작이 연결됐다는 사실은 다릅니다. 이 예시에서는 JavaScript가 꺼져 있는지 확인합니다. 실제 프로그램에서는 오류나 입력 조건도 함께 살펴야 합니다.

화면에서 할 일과 서버에서 처리·보관할 일을 구분해 봅니다.

더 읽기 · 원문과 공식 안내MDN · 처음 만드는 웹사이트 ↗

17 / 필요한 도구 만들기

프론트엔드에서 시작해,
서버와 공용 저장소를 더합니다.

실제 사례 · STOOM LIVE TRANSLATOR · trans.stoom.win ↗

기능과 구성 비교

담긴 것 · 소개·실행 파일

Pages(Cloudflare)

HTML·CSS·JS를
방문자에게 전달

담긴 것 · 내려받은 화면과 코드

브라우저

언어 선택·자막 표시
음성·번역 기능 연결

내 설정 · 브라우저 저장

담긴 것 · 서버의 처리 코드

Worker

라이선스 확인
통계·개인 데이터 요청 처리

담긴 것 · 공용 기록과 보조 자료

공용 저장소

라이선스·통계·개인 보정
전문용어집·벡터 자료

01 / 04 · 실행 화면자막·번역 화면과 조작은 브라우저에서 시작합니다.

Pages(Cloudflare)의 파일 → 방문자의 브라우저 → 음성·번역 기능 연결

지금 가능한 기능

입력·계산·미리보기와 개인 임시 저장이 가능합니다. 브라우저 DB는 내 기기의 저장소입니다.

아직 없는 기능

서버의 권한 확인·비밀키 관리와 공용 접수대장은 아직 없습니다. 내 저장이 곧 공동 저장은 아닙니다.

직접 확인 · 내 저장과 공동 저장은 어떻게 다를까요?

같은 ‘추가’ 버튼도 저장 위치에 따라 결과가 달라집니다. 아래는 메모리로만 작동하는 가상 모형이며 실제 DB 저장·로그인·기기 동기화는 하지 않습니다. 방식을 바꾸면 0건부터 다시 시작합니다.

A · 내 노트북0건내가 보는 목록

B · 다른 기기0건다른 기기에서 보는 목록

내 저장소는 자동으로 다른 기기와 공유되지 않습니다.

초보자가 자주 헷갈리는 네 가지

브라우저 DB도 다시 접속하면 남나요?

네. localStorage나 IndexedDB로 내 브라우저에 남길 수 있습니다. 다만 다른 기기와 자동 공유되지는 않고, 사이트 데이터 삭제·브라우저의 저장 정책 등에 따라 사라질 수 있어 공용 원본·백업과는 구분합니다.

화면에 비밀번호를 걸면 권한 확인인가요?

화면의 버튼을 숨기는 것만으로는 부족합니다. 공식 자료를 읽거나 바꾸는 요청마다 서버가 사용자의 신원과 접근 권한을 확인해야 합니다. Worker를 추가한 뒤에도 이 검사를 직접 구현해야 합니다.

외부 API는 모두 Worker가 필요한가요?

아닙니다. 브라우저 접근을 허용한 공개 API는 직접 호출할 수도 있습니다. 기관의 비밀 API 키로 유료 AI를 호출한다면 키를 서버에 두고, 사용자의 권한과 사용량을 확인한 뒤 호출하는 구조가 필요합니다.

백엔드는 꼭 Cloudflare Worker인가요?

아닙니다. Worker는 서버 코드를 실행하는 서비스의 한 예입니다. 다른 서버·관리형 백엔드도 같은 역할을 맡을 수 있습니다. Pages(Cloudflare)는 파일 배포, Worker는 처리, D1은 공용 저장이라는 역할 예시이며 반드시 세 제품을 따로 써야 하는 것은 아닙니다. 예약 작업은 Worker에 스케줄 트리거를 설정해 실행합니다. 브라우저의 Web Worker·Service Worker와 Cloudflare Worker도 다른 개념입니다.

MDN · 도메인의 뜻 Pages · 기본 주소와 내 도메인 MDN · 브라우저 DB MDN · 서버 역할 Worker · 비밀키 예약 실행 공용 DB · D1업무 사례는 설계 설명용 · 실제 저장·외부 통신·예약 없음

17 / 28 · 프론트 · 백엔드 · Worker · DB

스스로 공부하기

처음부터 차근차근

같은 실시간 번역기 안에도 파일을 제공하는 일, 화면을 움직이는 일, 라이선스를 확인하는 일, 개인별 자료를 보관하는 일이 함께 있습니다. ①~③은 trans.stoom.win을 예로 이 역할을 더해 보며 이해하는 학습 모형입니다. ④는 별도 사례로, 전용 웹 화면 없이 정해진 시간에 설문을 집계하는 백엔드를 보여줍니다. 모든 프로그램에 프론트엔드와 백엔드가 둘 다 필요한 것은 아닙니다.

먼저 알아둘 말

브라우저·프론트엔드: 방문자의 컴퓨터나 휴대폰에서 언어를 선택하고 버튼을 누르며 자막과 번역 결과를 보는 부분입니다. JavaScript가 화면을 움직이고 지원되는 음성·번역 기능이나 API와 연결합니다.
Worker·백엔드: 서버에서 실행하는 처리 코드입니다. 화면의 요청을 받기도 하고, 화면 없이 예약 시간이나 다른 프로그램의 요청으로 실행되기도 합니다. Worker는 그런 서버 코드를 실행하는 서비스의 한 예이며, 브라우저의 Web Worker와는 다른 개념입니다.
DB·API: DB는 자료를 정리해 보관하고 조회하는 저장소입니다. API는 프로그램끼리 정해진 방식으로 요청과 결과를 주고받는 통로입니다.
도메인·호스팅: trans.stoom.win 같은 도메인은 사람들이 사이트를 찾는 이름입니다. 호스팅은 실제 파일이나 서비스를 접속 가능한 환경에서 제공하는 일입니다.
캘리브레이션: 개인의 목소리·발음 특징에 맞춰 인식 판단을 보정하는 과정과 그 보정 정보입니다. 여기서는 개인화에 쓰는 자료의 한 종류로 봅니다.
벡터·임베딩: 벡터는 대상의 특징을 여러 숫자로 적은 묶음입니다. 직접 고른 기준을 숫자로 적을 수도 있고, 학습된 모델이 글의 관계를 숫자로 표현하게 할 수도 있습니다. 뒤의 방식을 여기서는 임베딩이라고 부릅니다.
벡터 DB: 벡터를 보관하고 비슷한 벡터를 효율적으로 찾도록 지원하는 저장·검색 시스템입니다. 일반 DB의 벡터 검색 기능을 쓰는 방식과 별도의 전용 제품을 쓰는 방식이 있습니다.

④ 백엔드만: 아침마다 혼자 집계하는 직원처럼 생각해 봅니다

밤사이 저장된 설문 응답을 매일 오전 9시에 집계한다고 해 봅시다. 예약 시간이 되면 서버의 Worker가 응답을 읽고, 빈칸과 잘못된 값을 제외한 뒤 응답 수와 평균을 계산합니다. 결과와 실행 기록은 저장소에 남깁니다. 이 작업만을 위한 버튼이나 웹페이지를 만들 필요는 없습니다. 사람이 나중에 결과를 볼 때는 기존 보고서 도구나 다른 화면을 연결할 수 있습니다. 이 예시는 trans.stoom.win의 실제 예약 기능을 설명하는 것이 아니라, 화면 없는 서버 작업을 이해하기 위한 별도 구성입니다.

무엇이 시작 신호를 주나요? 내 PC를 꺼도 되나요?

브라우저의 클릭이 없어도 예약된 시간, 새 자료 도착, 다른 프로그램의 API 요청이 시작 신호가 될 수 있습니다. Cloudflare에서는 Cron Trigger라는 예약 기능과 Worker의 처리 코드를 연결할 수 있습니다. 실제 서버에 배포하고 실행 시간·자료 접근 권한·저장소 연결을 설정했다면 내 PC나 브라우저를 꺼도 서버에서 실행됩니다. 코드를 내 PC에만 저장해 둔 상태에서는 같은 뜻이 아닙니다. DB는 작업에 자료 보관이 필요해서 연결한 것이며, 모든 백엔드에 반드시 필요한 것은 아닙니다. 예약 실행에는 실패 기록과 같은 자료를 두 번 처리하지 않는 기준도 정해 두면 좋습니다.

도메인은 따로 구입하지 않고 시작할 수도 있습니다

Pages(Cloudflare)는 프로젝트의 기본 주소를 제공합니다. 이 주소로 사이트를 공개할 수 있고, 기억하기 쉬운 trans.stoom.win 같은 내 주소를 연결할 수도 있습니다. 기본 제공 주소에도 도메인 이름이 포함되어 있습니다. 필수가 아닌 것은 별도로 구입한 맞춤 도메인입니다. 기존에 관리하는 도메인의 하위 주소를 사용하는 방법도 있습니다.

브라우저는 화면, Worker는 공통 조건을 처리합니다

Pages가 소개·실행 파일을 보내면 브라우저가 언어 선택·실행 버튼·자막 표시를 처리합니다. 음성인식과 번역은 지원되는 브라우저 기능과 API를 조합합니다. 라이선스 유효 여부처럼 이용자 공통의 조건은 서버에서 확인합니다. 화면에서 버튼을 숨기는 것과 서버가 실제 요청을 허용하는 것은 역할이 다릅니다.

이 번역기에 있는 자료를 나누어 봅니다

제작자는 라이선스 확인, 사용자 통계, 개인 목소리 캘리브레이션 데이터, 분야별 전문용어집·벡터 자료를 관리한다고 설명했습니다. 이용권 상태와 횟수는 정확한 값으로 조회·집계하고, 보정 정보는 개인화에, 용어 자료는 분야에 맞는 표현을 찾는 데 활용합니다. 이 자료들이 모두 하나의 일반 DB나 특정 제품에 들어 있다고 단정하지 않고, 기록용 DB·벡터 검색용 저장소·파일의 역할로 구분합니다.

감자와 고구마의 특징을 숫자로 적어 봅니다

벡터라는 말이 어렵다면 “특징을 숫자로 적은 메모”라고 생각해 보세요. 감자와 고구마를 비교하려고 단맛·전분·식감이라는 세 기준을 골랐다고 해 봅시다. 각 기준을 0~10의 숫자로 적고, 항상 같은 순서로 묶습니다. 감자의 [2, 8, 5]에서 첫 숫자 2는 단맛, 다음 8은 전분, 마지막 5는 식감 점수입니다.

숫자를 이해하기 위한 가상 예시입니다. 실제 식품의 성분이나 측정값이 아닙니다.
대상	벡터 · [단맛, 전분, 식감]
감자	[2, 8, 5]
고구마	[8, 7, 6]

차이를 저장하기보다, 각각의 벡터를 저장하고 비교합니다

숫자 묶음을 지도 위의 좌표처럼 생각하면 쉽습니다. 감자와 고구마의 벡터를 각각 저장해 두고, 비교할 때 두 위치가 얼마나 가까운지 계산합니다. “감자와 비슷한 것을 찾아줘”라고 하면 감자 벡터와 가까운 후보를 찾는 것입니다. 여기서 거리는 실제 길이가 아니라 숫자들 사이의 차이를 비교한 값입니다. 선택한 기준과 계산 방법 안에서 가까울수록 비슷하다고 해석합니다. 비교 방법으로 거리나 코사인 유사도라는 점수를 쓸 수 있는데, 처음에는 “숫자 묶음이 얼마나 비슷한지 보는 방법”으로 이해하면 됩니다.

숫자로 바꾸는 방법은 두 가지로 나누어 생각합니다

앞의 단맛·전분·식감은 사람이 비교 기준을 정한 예시입니다. 반면 AI 임베딩은 학습된 모델이 글이나 설명을 숫자로 바꿉니다. 두 방식 모두 숫자 묶음을 만들지만, 숫자가 정해지는 과정이 다릅니다.

사람이 비교 기준을 고를 수도 있고, 모델이 학습한 표현을 사용할 수도 있습니다.
방식	기준은 누가 정하나요?	감자·고구마로 보면
직접 기준 정하기 · 명시적인 특징 벡터	사람이 목적에 맞게 고릅니다.	단맛·수분·열량·가격 등을 정하고 숫자로 적습니다.
모델에 맡기기 · 임베딩 모델의 벡터	모델이 학습한 방식으로 바꿉니다.	단어 또는 설명을 넣으면 여러 숫자로 바꿔 줍니다.

먼저 “무엇이 비슷한 것을 찾을까?”를 정합니다

요리할 때 맛이 비슷한 재료를 찾는 것과, 영양이 비슷한 재료를 찾는 것은 기준이 다릅니다. 직접 기준을 고른다면 단맛을 얼마나 중요하게 볼지, 가격은 원 단위인지 천 원 단위인지도 맞춰야 합니다. 기준·단위·중요도를 어떻게 정하느냐에 따라 가까운 후보가 달라질 수 있습니다. 모델을 쓴다면 어떤 모델을 고르고 무엇을 입력할지 정합니다. “감자”라는 단어만 넣을 때와 영양·조리 특성까지 설명해서 넣을 때는 비교 결과가 달라질 수 있습니다.

실제 AI의 숫자 하나하나에 이름을 붙이지는 않습니다

실제 임베딩 모델은 흔히 수백~수천 개의 숫자로 내용을 표현합니다. 이때 첫 숫자가 단맛이고 둘째 숫자가 전분이라는 식으로 뜻을 정하지는 않습니다. 모델이 학습한 관계를 여러 숫자에 나누어 담기 때문입니다. 앞의 세 숫자 표는 원리를 쉽게 이해하기 위한 예시입니다. 함께 비교할 자료와 검색어는 같은 모델과 처리 기준으로 바꿔야 의미 있게 비교할 수 있습니다.

벡터화와 벡터 DB는 언제 필요할까요?

“라이선스 번호가 정확히 같은가?”, “이번 달 사용 횟수는 얼마인가?”는 일반 DB의 조회·합계로 시작하면 됩니다. 작은 용어집에서 같은 단어를 찾는 일도 사전이나 키워드 검색으로 충분할 수 있습니다. 표현이 달라도 의미가 가까운 설명·용어·예문을 찾고 싶다면 벡터화를 검토합니다. 그런 자료를 많이 저장하고 자주 검색한다면 벡터 검색을 지원하는 DB가 도움이 됩니다. 일반 DB에 벡터 검색 기능을 더할 수도 있고, 전용 벡터 DB를 쓸 수도 있습니다. 적은 수의 벡터를 비교하는 데 전용 DB가 반드시 필요한 것은 아닙니다.

trans.stoom.win의 전문용어집과 연결해 봅니다

제작자가 설명한 분야별 전문용어집·벡터 자료는 번역에 맞는 용어와 표현을 찾기 위한 사례로 볼 수 있습니다. 입력 문장과 관련 자료를 숫자 묶음으로 표현하면, 글자가 달라도 의미가 가까운 후보를 찾는 데 도움이 됩니다. 벡터 옆에는 원래 용어·설명·분야·언어 같은 정보도 함께 연결해 둡니다. 찾은 후보가 해당 분야와 문맥에 맞는지 확인한 뒤 번역에 활용합니다. 벡터를 만드는 일과 보관·검색하는 일은 구분되며, 서비스를 만들 때 두 과정을 연결합니다. 이 설명은 역할을 이해하기 위한 것이며 실제 저장소 제품을 특정한 것은 아닙니다.

화면에서 따라 하기

기본 제공 주소와 trans.stoom.win을 비교하고, 사이트를 찾는 이름과 실제 파일을 제공하는 곳을 구분합니다.
프론트엔드만 → + Worker → + 공용 DB를 차례로 선택해 파일·화면·검증·보관 역할이 어떻게 더해지는지 읽습니다. 이어서 ④ 백엔드만을 눌러 전용 웹 화면이 없는 별도 구성을 비교합니다.
3단계의 네 자료 종류를 읽습니다. 정확한 이용권 조회와 비슷한 전문용어 찾기에 같은 검색 방식이 필요한지 생각합니다.
아래 개인 저장·공용 저장 모형에서 가상 기록을 추가하고 A와 B의 건수를 비교합니다. 개인 저장이 자동으로 공용 기록이 되지는 않는다는 점을 확인합니다.

결과를 읽는 방법

선택마다 구성 요소와 설명이 바뀝니다. ③에는 번역기의 라이선스·통계·개인 보정·전문용어 자료가, ④에는 예약 시간 → Worker 집계 → 저장소 기록의 별도 사례가 표시됩니다. ④에서는 브라우저와 Pages를 거치지 않습니다. 교육 모형이므로 실제 서비스의 라이선스나 개인 데이터를 조회·수정하거나 예약 작업을 실행하지 않습니다.

헷갈리기 쉬운 점

DB에 넣기만 하면 자료가 자동으로 벡터가 되는 것은 아닙니다. 사람이 기준을 정해 숫자를 만들거나, 모델로 임베딩을 만드는 과정이 필요합니다. 또 벡터가 가깝다는 사실만으로 올바른 번역이 보장되거나 모델을 새로 학습한 것은 아닙니다. 개인 목소리의 보정 정보와 글의 의미 검색용 벡터도 쓰는 목적이 다릅니다.

이해 확인 · 감자와 고구마를 벡터로 저장한다면 무엇을 저장하나요? 모든 검색에 벡터 DB가 필요할까요?

해설 감자와 고구마 각각의 숫자 묶음을 저장하고, 비교할 때 거리나 유사도를 계산합니다. 먼저 맛을 비교할지 영양을 비교할지 정해야 합니다. 정확한 라이선스 조회나 사용 횟수 합계에는 일반 DB로 시작할 수 있고, 의미가 비슷한 자료를 많이·자주 찾을 때 벡터 검색을 지원하는 DB를 고려합니다.

이 역할 구분을 바탕으로 정적 파일만으로 시작할 일과 서비스 연결이 필요한 일을 골라봅니다.

더 읽기 · 원문과 공식 안내MDN · 도메인의 뜻 ↗Cloudflare Pages · 기본 주소와 내 도메인 ↗Cloudflare · Workers ↗Cloudflare · 화면 없이 예약 실행하는 Cron Triggers ↗MDN · 브라우저의 IndexedDB ↗OpenAI · 임베딩과 벡터 검색 ↗Cloudflare · 벡터 DB의 역할 ↗STOOM LIVE TRANSLATOR · 공개 소개 ↗

18 / 필요한 도구 만들기

정적 파일도 도구가 됩니다.
공용 기록·권한은 서버와 연결합니다.

STATIC FILES

파일만으로 가능한 일

내 브라우저에서 읽고, 계산하고, 보관

SERVER / SERVICE

서버·서비스를 연결할 때

함께 쓸 원본, 접근 권한, 비밀키, 예약

정적 파일로 시작

이 발표 자료가 ‘파일로 만든 작은 프로그램’입니다.

화면 전환·퀴즈·계산은 내 브라우저의 JavaScript가 실행합니다. 필요한 자원을 파일에 넣으면 인터넷 없이도 사용할 수 있습니다.

화면은 정적 파일로 두고, 필요한 기능만 서버나 기존 서비스에 연결할 수도 있습니다.

정적·동적의 차이와 ‘서비스 연결’을 조금 더 살펴보기

정적 파일: 미리 준비한 HTML·CSS·JS를 제공합니다. JS가 브라우저에서 화면을 바꾸고 입력을 처리하므로 탭·애니메이션·계산·개인 저장도 가능합니다. ‘움직이는 화면’이 곧 서버의 동적 처리라는 뜻은 아닙니다.

서버의 동적 처리: 요청한 사람과 자료에 따라 결과를 만듭니다. 서버가 HTML을 만들 수도 있고, 정적 화면이 서버에서 JSON을 받아 표시할 수도 있습니다. 기존 접수·인증 서비스를 연결하면 그 서비스의 서버가 처리·저장 역할을 맡습니다.

내 브라우저 저장소는 다른 기기와 자동으로 공유되지 않습니다. 공식 신청 기록, 비공개 자료, 비밀 API 키, 브라우저 밖의 예약 실행이 필요해지면 서버 기능을 검토합니다. 화면의 버튼을 숨기거나 JS에 비밀번호를 넣는 것만으로 접근 권한이 보장되지는 않습니다.

전달·배포 방법 살펴보기 · Cloudflare / GPT Sites / Drive

전달 방식 선택 학습 모형 · 배포나 업로드는 실행하지 않습니다

웹사이트 호스팅

정적 파일을 올리고 웹 링크로 제공합니다.

Pages(Cloudflare) Direct Upload로 준비한 파일을 배포할 수 있습니다. Workers도 정적 파일과 서버 처리를 지원합니다.

Cloudflare는 새 프로젝트에 Workers를 권장하며 Pages(Cloudflare) Direct Upload도 제공합니다.

배포 전 확인할 조건

보여줄 자료와 기능, 사용 대상의 접근 권한, 외부 자원, 계정과 지원 여부를 확인합니다. 정적 프론트엔드에 백엔드 API를 연결하는 구성도 가능합니다. ChatGPT Sites에는 호환되는 프로젝트를 만들고 저장·배포를 요청하며, 대상과 권한은 사용하는 계정에서 확인합니다. Google Drive는 HTML 파일을 보관·공유하고 내려받아 실행하는 전달 방식이며 Drive 자체의 웹 호스팅 기능은 종료됐습니다.

Cloudflare · Direct Upload OpenAI · Sites Google · Drive 호스팅 종료

MDN · 정적·동적·서버 역할 브라우저 저장 정적 파일 + 서버 기능 비밀키 예약 실행사례 선택은 학습용 설명 · 저장·통신·배포를 실행하지 않습니다

18 / 28 · 정적 · 동적 페이지 · 배포

스스로 공부하기

처음부터 차근차근

정적 페이지라는 말은 화면이 움직이지 않는다는 뜻이 아닙니다. 미리 준비한 파일을 제공하고 브라우저에서 JavaScript를 실행하는 방식으로도 퀴즈·계산·검색·개인 메모를 만들 수 있습니다. 사용자가 달라져도 함께 유지할 원본이나 권한 처리가 필요하면 서버의 동적 기능이나 기존 서비스를 연결하는 구성을 고려합니다.

먼저 알아둘 말

정적 파일: 요청할 때마다 업무용 서버가 새로 만들어내지 않고, 준비해 둔 HTML·CSS·JS 등의 파일을 전달하는 방식의 파일입니다. 전달받은 뒤 브라우저에서는 다양한 동작이 가능합니다.
동적 처리: 요청 내용이나 사용자·데이터 상태에 따라 서버가 처리하고 결과를 돌려주는 방식입니다. 로그인한 사람의 기록 조회나 공용 신청 접수가 예입니다.
호스팅·배포: 호스팅은 웹 파일이나 서비스를 접속 가능한 환경에서 제공하는 일이고, 배포는 준비한 새 버전을 그 환경에 반영하는 과정입니다.

정적 파일로 시작하기 좋은 일

혼자 쓰는 계산기, 안내 자료, 이 발표처럼 클릭하며 배우는 교육 페이지는 브라우저의 기능으로 만들 수 있습니다. 개인 메모도 브라우저 저장소를 사용하면 다시 열었을 때 남길 수 있습니다. 다만 다른 기기 공유와 백업, 사이트 데이터 삭제에 대한 처리는 별도 문제입니다.

공용 원본·권한·비밀·예약이 판단 기준입니다

여러 사람이 제출한 신청을 모으거나 본인에게만 결과를 보여주려면 공용 데이터와 접근 확인이 필요합니다. 기관 비밀키를 쓰거나 브라우저를 닫아도 정해진 시간에 집계하려면 서버 기능을 고려합니다. 직접 모두 개발할 필요 없이 기존 신청·인증 서비스를 연결할 수도 있습니다. 화면이 애니메이션인지 여부보다 이 조건으로 판단합니다.

파일을 나눠 주는 것과 웹사이트를 운영하는 것은 다릅니다

HTML을 Drive에 보관해 공유하면 받는 사람이 내려받아 브라우저에서 열 수 있습니다. 이는 웹 호스팅과 다른 전달 방식입니다. Cloudflare나 지원되는 Sites로 배포하면 접속 링크로 제공할 수 있습니다. 실제 지원 방식과 공개 범위는 해당 서비스의 공식 안내와 내 계정에서 확인합니다.

화면에서 따라 하기

교육 페이지·계산 도구·개인 메모 사례를 선택해 정적 파일로 가능한 이유를 읽습니다.
공동 신청·접근 권한·비밀키와 예약 사례를 선택해 필요한 서비스 기능을 찾습니다. “어디에 공통 기록이 있는가?”를 먼저 물어봅니다.
아래 전달 방식에서 파일 다운로드와 웹 접속 링크의 차이를 읽습니다. 사용하는 사람의 설치·접속 환경과 자료 공개 범위를 함께 생각합니다.

결과를 읽는 방법

사례와 전달 방식을 선택하면 설명이 바뀝니다. 이 선택이 파일을 실제로 업로드하거나 사이트를 배포하는 것은 아닙니다.

헷갈리기 쉬운 점

“정적 사이트에는 서버가 전혀 없다”는 뜻으로 이해하지 않습니다. 파일을 전달하는 호스팅 서버가 있을 수 있고, 여기서는 별도의 업무 처리 서버가 필요한지를 구분하는 것입니다.

이해 확인 · 익명 퀴즈를 풀고 점수를 내 기기에서만 확인하는 페이지는 반드시 공용 DB가 필요할까요?

해설 그 기능만이라면 브라우저 계산으로 시작할 수 있습니다. 여러 사람의 결과를 모아 비교하거나 계정별로 보관하려면 공용 저장과 권한 같은 조건을 추가로 설계해야 합니다.

공용 저장을 고려한다면, 먼저 표의 한 행에 무엇을 기록할지 정해야 합니다.

더 읽기 · 원문과 공식 안내MDN · 처음 만드는 웹사이트 ↗Cloudflare · Workers ↗

19 / 필요한 도구 만들기

한 줄에 담을 기록부터 정합니다.

열 = 항목
행 = 기록

워크숍 운영 자료교육용 가상 데이터 · 실제 DB 아님

정리 전 원본

사람·워크숍·신청을 한 표에

아래 시트를 바꿔 비교해보세요. 행 번호는 그 줄의 의미, 열 제목은 항목의 역할을 보여줍니다. 표를 좌우로 밀어 모든 열을 보세요.

원본 살펴보기

사람과 여러 신청을 한 표에 모아 썼습니다.

A의 두 신청이 한 행의 여러 칸에 나열되어 있습니다. 뒤의 세 시트에서는 사람·워크숍·신청을 각각 기록합니다.

KEY · 기록을 찾고 연결하는 기준

이름 대신 ‘번호표’로 찾으면 쉽습니다.

동명이인이 있어도 서로 구별하려고 사람마다 P01, P02 같은 ID를 붙입니다. 여기서는 ‘참가자 ID’가 키 역할을 하는 항목이고, 그 칸에 적힌 ‘P01’이 실제 키값입니다.

항목 이름참가자 ID실제 키값P01이 값으로 찾는 사람가상 참가자 A

키값을 골라보세요

**① 참가자 표**PK · 기본키 이 표에서 한 사람을 구별하는 고유번호
참가자 ID이 표의 고유번호 · PK	이름

**② 신청 표**FK · 외래키 참가자 표의 사람을 가리키는 연결번호
신청 ID이 표의 고유번호 · PK	참가자 ID참가자 표 연결 · FK	워크숍 ID워크숍 표 연결 · FK

P01 = 가상 참가자 A → 신청 2건

참가자 표의 P01은 한 사람을 구별하므로 한 번만 나옵니다(PK). 신청 표에는 그 사람이 두 번 신청해 P01이 두 번 나옵니다(FK). 신청 자체는 R01·R02라는 서로 다른 PK로 구별합니다.

기억할 것: PK는 ‘내 표의 고유번호’, FK는 ‘다른 표로 이어지는 연결번호’입니다. 같은 P01도 어느 표에서 쓰느냐에 따라 역할이 달라집니다. 표를 정렬해 행 순서가 바뀌어도 ID는 유지합니다.

더 알아보기 · 키값 중복, 없는 번호, NULL

PK는 겹치지 않게

참가자 표에서 두 사람에게 모두 P01을 주면 누구를 뜻하는지 알 수 없습니다. PK는 같은 표에서 중복되거나 비면 안 됩니다. 여러 항목을 묶어 하나의 PK로 정하는 방법도 있습니다.

FK는 연결할 대상이 있게

이 예시에서 P99가 참가자 표에 없다면 P99의 신청을 연결할 수 없습니다. 반면 P01의 서로 다른 신청이 여러 건 있으면 FK 칸에는 P01이 반복될 수 있습니다.

NULL은 값이 없는 상태

메모가 아직 입력되지 않은 상태를 예시에서 ‘미입력 · NULL’로 표시했습니다. 숫자 0이나 빈 문자열과는 구분합니다. 실제 DB에서는 필수 여부와 연결 규칙을 따로 설정합니다.

AI에게 DB 구현을 맡기기 전에 정할 조건

한 행의 단위와 값: 사람 한 명, 워크숍 한 개, 신청 한 건을 구분합니다. 이름은 동명이인이 있어 고유번호 대신 쓰지 않습니다. 각 열의 자료형, 필수 항목, 미입력을 허용할 항목을 정합니다. 신청 표에서는 같은 참가자의 같은 워크숍 신청이 중복되지 않도록 두 ID의 조합을 확인합니다.

조회·권한·운영: 필요한 항목만 수집합니다. 워크숍별 신청 목록·사람별 내역·신청 건수를 정하고 담당자별 조회·수정 권한을 나눕니다. 동시 사용자 수, 저장 위치, 백업·복구, 변경 담당자도 확인합니다. 표는 설계 예시이며 실제 PK·FK·중복 방지 규칙은 DB에 구현하고 검증해야 합니다.

Microsoft Learn · PK와 FK 제약 모든 ID·이름·날짜·정원은 교육용 가상 값입니다.

19 / 28 · DB 설계 · 키 · PK · FK

스스로 공부하기

처음부터 차근차근

DB는 익숙한 스프레드시트처럼 표로 생각하면 시작하기 쉽습니다. 먼저 한 줄에 사람 한 명을 담을지, 신청 한 건을 담을지 정합니다. 그다음 각 기록에 번호표 같은 ID를 붙입니다. 이 번호로 기록을 찾고 다른 표의 정보와 연결하는 기준을 키라고 생각하면 됩니다. 이 화면에서는 같은 워크숍 사례로 키·키값·PK·FK를 차근차근 비교합니다.

먼저 알아둘 말

테이블·행·열: 테이블은 같은 종류의 기록을 모은 표입니다. 행은 기록 한 건, 열은 이름·날짜처럼 그 기록의 항목입니다. 왼쪽 행 번호는 화면의 위치입니다.
ID: 사람·워크숍·신청 등을 구별하려고 붙인 식별 값입니다. 여기서는 P01처럼 문자와 숫자를 섞은 설명용 번호를 씁니다. 반드시 숫자로만 만들어야 하는 것은 아닙니다.
키·키값: 여기서 키는 기록을 구별하거나 표를 연결하는 데 쓰는 항목입니다. ‘참가자 ID’가 키 역할을 하는 항목 이름이고, 그 칸에 들어 있는 P01·P02가 실제 키값입니다.
PK·기본키: Primary Key의 줄임말입니다. ‘이 표에서 기록 하나를 확실히 구별하는 기준’이라고 읽습니다. 예시의 참가자 표에서는 참가자 ID가 PK입니다. 같은 표의 PK는 겹치거나 비어 있으면 안 됩니다.
FK·외래키: Foreign Key의 줄임말입니다. ‘연결할 기록을 가리키는 기준’이라고 읽습니다. 이 예시에서는 신청 표의 참가자 ID가 참가자 표의 ID를 가리킵니다. 같은 사람의 여러 신청을 연결하므로 값이 반복될 수 있습니다.
NULL·UNIQUE: NULL은 값이 없는 상태로 숫자 0과 다릅니다. UNIQUE는 정한 항목 또는 항목의 조합이 중복되지 않게 하는 조건입니다.

명단의 번호표를 떠올려 보세요

이름이 같은 참가자가 두 명 있다면 이름만으로 신청을 연결하기 어렵습니다. 그래서 한 사람에게 P01, 다른 사람에게 P02를 붙입니다. “P01의 신청을 찾아줘”라고 하면 P01로 연결한 기록을 찾을 수 있습니다. 번호에 그 사람의 모든 정보가 들어 있는 것은 아닙니다. P01을 기준으로 해당 사람의 이름과 관련 신청을 찾아보는 것입니다.

항목 이름과 실제 키값은 다릅니다

스프레드시트의 열 제목에는 ‘참가자 ID’라고 적혀 있고, 그 아래 각 칸에는 P01·P02가 들어 있습니다. 여기서는 참가자 ID라는 항목을 키로 쓰겠다고 정한 것입니다. “키값이 뭐예요?”라는 질문에는 ‘참가자 ID라는 열 이름’이 아니라 ‘이 사람의 값은 P01입니다’라고 답하면 됩니다. 이름 칸의 ‘가상 참가자 A’는 사람이 읽기 좋은 표시명이고, ID 칸의 P01은 그 사람을 구별하는 값입니다.

PK는 내 표에서 기록 하나를 찾는 기준입니다

참가자 표의 P01은 가상 참가자 A 한 명을 뜻합니다. 다른 사람에게 같은 P01을 주면 누구인지 구별할 수 없습니다. 이 표에서 참가자 ID를 기본키, 즉 PK로 정하면 값의 중복과 빈 값을 막도록 구현합니다. 워크숍 표에서는 W01·W02, 신청 표에서는 R01·R02·R03이 각 표의 기록을 구별합니다. PK는 꼭 번호 한 칸이어야 하는 것은 아니며, 여러 항목의 조합을 하나의 기준으로 정할 수도 있습니다.

FK는 다른 표의 기록으로 이어지는 기준입니다

신청 표에 “R01 / P01 / W01”이라고 적혀 있다면 R01 신청은 P01 참가자의 W01 워크숍 신청이라는 뜻입니다. 참가자 이름은 참가자 표의 P01에서, 워크숍 이름은 워크숍 표의 W01에서 찾습니다. 신청 표에 있는 참가자 ID와 워크숍 ID는 연결 역할을 하므로 외래키, 즉 FK라고 부릅니다. 같은 P01이라도 참가자 표에서는 그 표의 PK이고 신청 표에서는 사람을 연결하는 FK입니다.

같은 P01이 두 번 보인다고 모두 중복 오류는 아닙니다

A는 AI 협업과 수업 설계라는 두 워크숍에 신청했습니다. 따라서 참가자 표에는 P01의 사람 한 명이 있고, 신청 표에는 P01을 가리키는 두 신청이 있습니다. 두 신청은 R01과 R02라는 별도의 PK로 구별됩니다. 참가자 표의 PK가 겹치는 상황과, 신청 표에서 같은 FK를 여러 번 사용하는 상황은 이렇게 다릅니다. P02를 선택하면 B 한 명과 그 사람의 신청 한 건을 비교할 수 있습니다.

행 번호와 이름을 고유번호 대신 쓰면 불편할 수 있습니다

화면의 2행·3행은 지금 보이는 위치입니다. 표를 이름순으로 다시 정렬하면 위치가 바뀔 수 있지만, 같은 기록의 ID는 그대로 두고 연결해야 합니다. 사람의 이름을 수정할 때도 참가자 표의 이름을 고치고 같은 ID로 연결하면 그 사람의 신청을 계속 찾을 수 있습니다. 연결된 ID 자체를 바꾸거나 기록을 삭제할 때는 다른 표의 연결을 어떻게 유지할지 규칙을 함께 정합니다.

정리 전 시트와 비교하면 번호가 필요한 이유가 보입니다

원본에는 A의 두 신청이 한 행의 여러 칸에 모여 있고, B도 같은 워크숍에 신청해 날짜·정원이 반복됩니다. 뒤에서는 참가자 두 명, 워크숍 두 개, 신청 세 건을 나누어 적습니다. 원본의 정보를 버리는 것이 아니라 각각의 기록에 ID를 붙이고 그 값으로 연결하는 것입니다.

번호를 붙이는 일과 중복 신청을 막는 일은 함께 정합니다

R01과 R02처럼 신청 번호가 달라도 같은 사람의 같은 워크숍 신청이 두 번 들어갈 수 있습니다. 한 과정에 한 번만 신청하게 하려면 참가자 ID와 워크숍 ID의 조합이 겹치지 않게 하는 업무 규칙이 필요합니다. 또 참가자 표에 없는 P99를 신청에 적으면 누구를 연결하는지 알 수 없습니다. 이런 중복·연결 규칙은 실제 DB에 설정하고 확인해야 합니다.

화면에서 따라 하기

정리 전 원본 → 참가자 → 워크숍 → 신청 시트를 차례로 선택합니다. 각 표의 가로 한 줄이 무엇 한 건을 뜻하는지 읽습니다.
열 제목이나 행 번호를 눌러 설명을 봅니다. ‘참가자 ID’라는 항목 이름과 칸에 적힌 ‘P01’이라는 실제 값을 구별합니다.
아래 키값 비교에서 P01을 누릅니다. 참가자 표의 한 사람과 신청 표의 두 기록이 함께 강조되는지 봅니다. 같은 P01이 두 표에서 각각 PK와 FK로 쓰이는 이유를 읽습니다.
P02를 누르고 B 한 사람과 신청 한 건으로 강조 표시가 바뀌는지 봅니다. 신청 ID인 R03은 그 신청 자체의 PK입니다.
더 알아보기를 펼쳐 PK 중복, 없는 참가자 번호, 메모가 없는 NULL 상태를 비교합니다. 이름 변경·정렬·중복 신청 같은 업무 조건을 어떻게 정할지도 생각합니다.

결과를 읽는 방법

기존 네 시트는 기록 단위를 비교합니다. 아래 키값 체험은 같은 가상 자료에서 선택한 사람과 관련 신청을 함께 강조합니다. P01은 사람 1명·신청 2건, P02는 사람 1명·신청 1건입니다. 실제 DB를 만들거나 신청을 저장하는 기능은 아닙니다.

헷갈리기 쉬운 점

키값은 화면의 행 순서나 사람의 이름과 같은 개념이 아닙니다. 키가 반드시 숫자여야 하는 것도 아닙니다. 또 PK의 값은 같은 표에서 고유해야 하지만 FK의 값은 여러 행에서 반복될 수 있습니다. 화면에 PK·FK라고 적거나 같은 색으로 칠하는 것만으로 DB의 연결·중복 방지 규칙이 구현되는 것은 아닙니다.

이해 확인 · 참가자 표에는 P01이 한 번, 신청 표에는 P01이 두 번 있습니다. 잘못된 것일까요?

해설 이 예시에서는 올바릅니다. 참가자 표의 P01은 A 한 명을 구별하는 PK입니다. 신청 표의 두 P01은 같은 A의 두 워크숍 신청을 연결하는 FK입니다. 각각의 신청은 R01·R02라는 서로 다른 신청 ID(PK)로 구별합니다. 같은 값이라도 어느 표에서 어떤 역할을 하는지 살펴봅니다.

이렇게 정보가 반복되며 생기는 문제를 줄이는 설계 원리를 정규화라고 부릅니다.

더 읽기 · 원문과 공식 안내Microsoft Learn · 기본키와 외래키 ↗

20 / 필요한 도구 만들기

정보는 한 곳에서,
관계는 ID로 연결합니다.

2이름 복사본

앞 화면과 같은 가상 신청 3건의 이름 변경 실험 · 실제 DB 변경 없음

신청마다 이름을 복사한 한 표

정규화 전 가상 신청 세 건
신청	참가자	표시명	워크숍	워크숍명
R01	P01	가상 참가자 A	W01	AI 협업
R02	P01	가상 참가자 A	W02	수업 설계
R03	P02	가상 참가자 B	W01	AI 협업

Participants

참가자 기준 정보
ID · PK	표시명
P01	가상 참가자 A
P02	가상 참가자 B

이름을 고치는 한 곳

Workshops

워크숍 기준 정보
ID · PK	이름
W01	AI 협업
W02	수업 설계

Registrations

ID로 연결한 신청
신청 · PK	참가자 · FK	워크숍 · FK
R01	P01	W01
R02	P01	W02
R03	P02	W01

ID를 맞춰 조회한 W01 신청 2건R01 · AI 협업R03 · AI 협업

W01 이름이 2곳에 반복됩니다.

‘워크숍명 바꾸기’를 눌러 한 행만 고쳤을 때의 결과를 확인하세요.

NF = Normal Form(정규형) · 1NF·2NF·3NF를 예시로 보기

표를 정리하는 규칙

NF는 Normal Form,
우리말로 ‘정규형’입니다.

1NF = 제1정규형
2NF = 제2정규형
3NF = 제3정규형앞 단계의 조건을 지키며 다음 규칙을 더합니다.
숫자는 표의 개수가 아닙니다.

앞 화면과 같은 교육용 가상 사례입니다. 참가자 A는 워크숍 2개, 참가자 B는 1개에 신청했습니다. 아래에서 한 단계씩 비교하세요.

제1정규형

여러 신청을 한 칸에 몰아 쓰지 않습니다.

A가 두 번 신청했으면 신청도 두 줄로 적습니다.

정리 전 사람마다 한 줄

한 칸에 여러 신청을 적은 원본
참가자 ID	이름	신청 워크숍 ID
P01	가상 참가자 A	W01, W02
P02	가상 참가자 B	W01

“W02에 신청한 사람만 찾기”부터 번거로워집니다.

1NF 적용 신청마다 한 줄

한 칸에 하나의 워크숍 ID를 적은 신청 세 건
참가자 ID	이름	워크숍 ID
P01	가상 참가자 A	W01
P01	가상 참가자 A	W02
P02	가상 참가자 B	W01

신청 3건이 3행이 됩니다. 각 칸에는 한 값만 둡니다.

기억할 말 목록을 한 칸에 쓰거나 ‘워크숍1·워크숍2’ 열을 늘리기보다, 신청을 한 줄씩 추가합니다.

제2정규형 · 1NF의 조건도 유지

두 번호 중 하나만 알면 정해지는 정보는 따로 둡니다.

참가자 이름은 참가자 ID에, 워크숍 이름은 워크숍 ID에 딸린 정보입니다.

이 예시의 규칙 같은 사람은 같은 워크숍에 한 번만 신청합니다. 따라서 참가자 ID + 워크숍 ID 두 칸을 함께 보면 신청 한 건을 구분할 수 있습니다.

아직 1NF 신청마다 이름까지 복사

두 ID로 구분하는 신청에 참가자명과 워크숍명이 반복되는 표
참가자 ID 키의 한 부분	참가자 이름	워크숍 ID 키의 한 부분	워크숍 이름
P01	가상 참가자 A	W01	AI 협업
P01	가상 참가자 A	W02	수업 설계
P02	가상 참가자 B	W01	AI 협업

P01의 이름을 고치려면 두 신청 행을 고쳐야 합니다. W01의 이름도 두 곳에 반복됩니다.

이름은 해당 번호의 표로 옮기고, 신청에는 두 번호를 남깁니다.

2NF 적용 참가자

참가자 ID로 정해지는 이름
참가자 ID	이름
P01	가상 참가자 A
P02	가상 참가자 B

사람 이름은 여기서 한 번.

워크숍

워크숍 ID로 정해지는 이름
워크숍 ID	이름
W01	AI 협업
W02	수업 설계

워크숍 이름도 여기서 한 번.

신청

참가자와 워크숍의 두 ID로 연결하는 신청
참가자 ID	워크숍 ID
P01	W01
P01	W02
P02	W01

두 번호를 연결해 신청 3건 유지.

기억할 말 신청을 구분하는 두 번호의 일부에만 딸린 이름을 분리합니다. 정확한 용어로 ‘부분 종속 제거’입니다.

제3정규형 · 1NF·2NF의 조건도 유지

담당자 이름은 담당자 표에서 관리합니다.

이번에는 워크숍 ID가 아닌, 담당자 ID가 이름을 결정합니다.

설명을 위해 추가한 가상 조건 워크숍마다 담당자는 한 명입니다. 두 워크숍을 같은 담당자 T01이 맡습니다. 아래는 담당자 정보를 추가한 워크숍 표이며, 참가자·신청 표는 앞 단계 그대로입니다.

아직 2NF 워크숍마다 담당자 이름까지 복사

워크숍 표에 담당자 ID와 이름을 함께 반복한 예시
워크숍 ID 이 표의 키	워크숍 이름	담당자 ID	담당자 이름
W01	AI 협업	T01	가상 담당자 가
W02	수업 설계	T01	가상 담당자 가

담당자 이름이 바뀌면 두 워크숍 행을 모두 고쳐야 합니다.

워크숍 ID담당자 ID담당자 이름

3NF 적용 워크숍

담당자 이름 없이 담당자 번호를 연결하는 워크숍 표
워크숍 ID	이름	담당자 ID
W01	AI 협업	T01
W02	수업 설계	T01

담당자 번호만 연결합니다.

담당자 새로 분리한 표

담당자 이름의 기준 정보 한 건
담당자 ID	이름
T01	가상 담당자 가

이름은 이 한 곳에서 고칩니다.

기억할 말 표의 키가 아닌 다른 항목을 거쳐 정해지는 정보를 분리합니다. 이 예시는 ‘이행 종속 제거’입니다. 3NF라고 표가 세 개라는 뜻은 아닙니다.

표를 나눠도 신청 관계는 이어집니다.

참가자 1명 → 신청 여러 건 · 워크숍 1개 → 신청 여러 건
신청 표가 두 ID를 연결하므로, 조회할 때 각 ID로 이름을 찾아 함께 보여줄 수 있습니다.

정확한 용어와 이 예시의 범위

1NF: 각 칸에 하나의 값이 있도록 하고 반복되는 목록·열을 없앱니다.
2NF: 1NF를 만족하고, 키가 아닌 속성이 복합 키의 일부에만 의존하는 ‘부분 함수 종속’을 제거합니다. 이 예시는 두 ID의 조합이 신청을 식별한다는 규칙을 사용합니다.
3NF: 2NF를 만족하고, 키가 아닌 속성 사이의 ‘이행 함수 종속’을 제거합니다. 여기서는 워크숍 ID → 담당자 ID → 담당자 이름의 관계를 분리합니다.

이해를 돕기 위해 일부 열을 생략한 가상 표입니다. 표를 무조건 잘게 나누는 것이 목표는 아닙니다. 무엇이 무엇을 결정하는지와 업무 규칙을 먼저 확인합니다.

Microsoft Learn · 정규화 IBM · 정규형과 예시 Microsoft Learn · PK와 FK모든 표는 교육용 가상 값입니다.

20 / 28 · 정규화 · 테이블 관계

스스로 공부하기

처음부터 차근차근

정규화는 같은 사실을 여러 곳에 복사해 생기는 수정 누락과 불일치를 줄이기 위해 표의 구조를 정리하는 방법입니다. 핵심 질문은 “이 정보는 무엇을 알면 하나로 정해질까?”입니다. 표를 무조건 많이 나누거나 예쁘게 만드는 작업과는 다릅니다.

먼저 알아둘 말

NF·정규형: NF는 Normal Form의 줄임말이고 우리말로 정규형입니다. 1NF·2NF·3NF는 조건을 차례로 더한 단계이며 표가 한 개·두 개·세 개라는 뜻이 아닙니다.
갱신 이상: 같은 사실이 여러 행에 복사되어 한 곳만 수정하면 서로 다른 값이 남는 문제입니다. 같은 W01의 이름이 두 가지가 되는 상황이 예입니다.
관계·조회: 여러 표의 ID가 어떻게 연결되는지를 관계라고 이해할 수 있습니다. 조회할 때 연결된 ID로 이름과 정보를 찾아 함께 보여줄 수 있습니다.

1NF: 한 칸에 여러 신청을 모아 쓰지 않습니다

A가 W01과 W02에 신청했다면 한 칸에 “W01, W02”라는 목록을 넣는 대신 신청 두 행으로 기록합니다. 한 칸에는 정해진 항목의 값 하나를 두고, 같은 종류의 신청을 워크숍1·워크숍2처럼 열을 늘려 기록하지 않는 방향을 배웁니다. 이 예시에서 신청 한 건을 검색하고 세기가 쉬워집니다.

2NF: 두 번호의 일부에만 딸린 정보를 떼어 봅니다

화면의 예시는 “같은 사람은 같은 워크숍에 한 번 신청한다”는 규칙 아래 참가자 ID+워크숍 ID의 조합으로 신청을 구별합니다. 그런데 참가자 이름은 참가자 ID만 알면 정해지고, 워크숍 이름은 워크숍 ID만 알면 정해집니다. 두 번호 중 일부만 필요한 이름은 각각 참가자·워크숍 표에서 관리합니다. 이를 부분 종속을 없앤다고 설명합니다.

3NF: 다른 항목을 거쳐 정해지는 정보도 구분합니다

워크숍마다 담당자가 한 명이라고 가정하면 워크숍 ID로 담당자 ID를 알 수 있습니다. 담당자 이름은 그 담당자 ID에 딸린 정보입니다. 같은 담당자가 여러 과정을 맡을 때 이름을 과정마다 복사하면 수정 누락이 생깁니다. 담당자 이름을 담당자 표에서 관리하고 워크숍에는 담당자 ID를 연결하는 예가 3NF 설명입니다.

화면에서 따라 하기

정리 전 상태에서 “워크숍명 바꾸기”를 누릅니다. 같은 W01의 복사본 중 한 곳만 바뀌어 이름이 달라지는 이유를 읽습니다.
정리 후 상태에서도 이름을 바꿔 봅니다. 기준 정보 한 곳을 고치고 신청은 ID로 이름을 조회하는 흐름을 비교합니다.
아래 NF 설명을 열고 1NF → 2NF → 3NF 탭을 차례로 봅니다. 어떤 번호가 어떤 정보를 정하는지 화살표와 가로 표에서 찾아봅니다.

결과를 읽는 방법

예시의 이름 변경은 메모리 안에서 일어나는 모형입니다. 정리 후에 이름이 함께 바뀌어 보이는 것은 각 신청의 ID로 같은 기준 정보를 조회하는 상황을 보여주기 때문입니다.

헷갈리기 쉬운 점

표를 세 개로 나눴다는 이유만으로 3NF가 되는 것은 아닙니다. 또 신청 ID 하나를 새로 붙였다고 반복되는 사실과 업무상 중복 규칙이 저절로 해결되는 것도 아닙니다. 실제 정규화는 후보가 되는 키와 정보의 의존 관계를 살펴 판단합니다.

이해 확인 · 두 워크숍이 같은 담당자 T01을 가리킵니다. 담당자의 이름이 바뀌면 어디를 고치는 것이 좋을까요?

해설 담당자 표의 T01 이름을 한 곳에서 관리하고 고칩니다. 워크숍에는 T01 연결을 남기고 조회할 때 그 이름을 함께 보여주면 복사본을 여러 개 고칠 필요가 줄어듭니다.

표의 구조와 계산 기준을 알았다면, 작은 정답 자료로 도구의 결과를 확인할 수 있습니다.

더 읽기 · 원문과 공식 안내Microsoft · 데이터베이스 정규화 ↗

21 / 검증·기록·자동화

작은 정답 데이터로
도구의 오류를 찾을 수 있습니다

1~5점 만족도 설문. 기준을 빠뜨린 계산과 기준을 적용한 계산을 비교합니다.

가상 데이터 · 사전에 만든 계산 예시

응답값 (쉼표로 구분, 빈칸은 결측)

직접 값을 바꿔볼 수 있습니다.
‘빈칸’, 숫자가 아닌 값, 0 또는 6 등을 넣어보세요.

계산식과 가정 확인

평균 = 포함한 값의 합 ÷ 포함한 응답 수

올바른 기준: 유한한 숫자이며 1 이상 5 이하인 값만 포함합니다. 빈칸·문자·범위 밖 값은 제외합니다. 소수도 범위 안이면 포함합니다. 유효 값이 없으면 평균을 표시하지 않습니다.

오류 예: 숫자라는 이유만으로 6이나 0까지 포함합니다. 이는 교육을 위해 의도적으로 만든 오류입니다.

포함한 응답

평균

4.40

제외한 응답

입력값별 포함·제외 결과
입력	처리	이유

기본 예시의 정답: 유효 4건 · 평균 4.00 · 제외 2건

실제 대학 설문이 아닌 교육용 모의 자료입니다. 계산은 브라우저 안에서만 실행합니다.

21 / 28 · 설문 도구 검증

스스로 공부하기

처음부터 차근차근

AI가 만든 계산 도구를 확인할 때는 손으로 정답을 구할 수 있는 작은 입력부터 사용합니다. 이 화면은 1~5점 만족도 응답이라는 규칙을 지킨 계산과 그 규칙을 빠뜨린 계산을 비교합니다. 결과 숫자뿐 아니라 어떤 입력이 포함·제외됐는지 이유를 읽는 연습입니다.

먼저 알아둘 말

유효 응답: 이 작업의 포함 기준을 만족하는 응답입니다. 여기서는 유한한 숫자이고 1 이상 5 이하인 값입니다. 범위 안의 소수도 포함하는 예시입니다.
평균: 포함한 값의 합을 포함한 값의 개수로 나눈 값입니다. 제외한 입력은 합과 개수 양쪽에서 제외해야 합니다.
경계값·제외 이유: 1과 5처럼 허용 범위의 끝에 있는 값이 경계값입니다. 빈칸·문자·0·6이 왜 제외되는지 설명할 수 있어야 계산 규칙을 확인할 수 있습니다.

기본 예시를 손으로 계산해 봅시다

입력이 5, 4, 빈칸, 3, 4, 6이라면 1~5점 기준에서 5·4·3·4 네 개만 포함합니다. 합계는 16이고 평균은 16÷4=4입니다. 빈칸과 6 두 개가 제외됩니다. 기준을 빠뜨린 모형은 숫자라는 이유로 6도 포함해 합계 22, 개수 5, 평균 4.4가 됩니다.

평균이 없다는 것과 평균 0은 다릅니다

입력이 전부 빈칸이나 범위 밖 값이면 포함할 응답이 없습니다. 이때 0으로 나눠 평균을 만들 수 없으므로 평균 없음으로 표시해야 합니다. 실제로 0점을 허용하는 다른 조사라면 규칙 자체를 달리 정해야 합니다. 이 화면의 0 제외는 1~5점이라는 교육용 조건에 따른 것입니다.

화면에서 따라 하기

기본 입력을 보고 먼저 유효 4건·평균 4.00·제외 2건이라는 정답을 확인합니다.
“기준을 빠뜨린 도구”와 “기준을 적용한 도구”를 번갈아 눌러 포함 수·평균·제외 수를 비교합니다. 입력별 처리 이유도 읽습니다.
1과 5, 숫자 한 개, 전부 빈칸, 문자와 0·6이 섞인 입력을 각각 시험합니다. 예상한 결과와 다르면 어떤 값의 처리에서 차이가 났는지 찾습니다.

결과를 읽는 방법

입력이나 계산 모드를 바꾸면 실제 브라우저 계산이 갱신됩니다. “계산식과 가정 확인”을 열면 현재 규칙을 다시 볼 수 있습니다. 개인별 실제 설문 자료가 아닌 가상 데이터를 사용합니다.

헷갈리기 쉬운 점

평균이 두 자리 소수로 표시된다고 정밀하게 검증됐다는 뜻은 아닙니다. 무엇을 포함했는지와 분모를 어떻게 셌는지가 틀리면 소수 자리수와 관계없이 잘못된 결과입니다.

이해 확인 · 입력이 빈칸, 문자, 0, 6뿐입니다. 이 화면의 기준에서 평균은 무엇일까요?

해설 유효 응답이 0건이므로 평균 없음입니다. 제외한 네 항목을 억지로 0점 응답 네 개로 바꾸거나 평균 0으로 보고하면 안 됩니다.

발견한 오류를 수정했다면 무엇을 왜 고쳤는지 기록하고 검토하는 방법을 알아봅니다.

22 / 검증·기록·자동화

Git과 GitHub는
변경 기록과 검토를 돕습니다

Git은 버전 관리 도구, GitHub는 저장소를 공유하고 검토하는 서비스입니다.

파일을 모으고, 변경 이력까지 관리합니다.

같은 설문 도구를 세 가지 모습으로 비교해 보세요.

설문.html
└ 화면과 계산 기능이 담긴 파일

파일은 내용을 담습니다.

예를 들어 설문.html에는 입력창과 평균 계산 코드가 들어 있습니다. 파일을 수정하고 저장하면 현재 내용이 바뀝니다.

별도 복사본이나 기록 기능이 없다면, 저장한 파일만으로는 “어제 어떤 줄을 왜 바꿨는지” 알기 어렵습니다.

설문도구/
├ index.html   화면
├ style.css    디자인
└ app.js       계산 기능

폴더는 관련 파일을 모읍니다.

화면·디자인·계산 파일을 한곳에 정리하면 프로젝트를 다루기 편합니다. 폴더를 만들었다고 Git의 버전 기록이 자동으로 생기지는 않습니다.

파일을 “최종 → 진짜최종 → 최종수정”으로 복사하는 대신, 변경 이유와 차이를 체계적으로 남기고 싶을 때 Git을 씁니다.

설문도구/
├ index.html
├ style.css
├ app.js
└ .git/       Git의 기록 보관 영역

기록 1 · 첫 계산 도구
기록 2 · 빈칸을 평균에서 제외

리포지토리(repository)는 Git 저장소입니다.

일반적인 로컬 프로젝트에서는 작업 파일과 Git의 관리 정보를 함께 다룹니다. 숨김 영역인 .git에는 기록과 브랜치 등의 정보가 들어 있습니다.

저장 ≠ commit. 저장은 현재 파일을 바꾸는 일, commit은 선택한 변경을 설명과 함께 버전으로 남기는 일입니다. 모든 편집이 자동 기록되지는 않습니다.

폴더 이름에 ‘Git’을 붙이는 것만으로 저장소가 되지는 않습니다. 아래는 저장소 안에서 변경을 나누고 기록·공유·검토하는 흐름입니다.

가상의 설문 도구 변경 예 · 실제 Git 명령을 실행하지 않습니다.

AI가 바꾼 내용도 무엇을, 왜, 어떻게 확인했는지 남깁니다.

branch: 수정 흐름 분리 · commit: 로컬 버전 기록 · push: 원격 공유 · PR: 검토와 통합 제안 · merge: 대상 흐름에 통합
기록한 버전은 비교와 복구의 기준이 됩니다. Git은 모든 편집 순간을 자동 저장하지 않으며, merge 후 배포 여부는 프로젝트 설정에 따릅니다.

Git · 저장소의 구조 GitHub · 리포지토리 Git · 버전 관리 GitHub · GitHub flow

22 / 28 · Git · GitHub

스스로 공부하기

처음부터 차근차근

파일과 Git은 대체 관계가 아닙니다. 파일에는 현재 내용이 들어 있고, 폴더는 파일을 정리하며, Git은 프로젝트 파일의 변경 이력을 관리하는 도구입니다. 저장소를 뜻하는 리포지토리(repository)는 Git이 기록과 버전 흐름을 관리하는 단위입니다. GitHub는 그 저장소를 온라인에서 공유하고 검토할 수 있는 서비스입니다.

먼저 알아둘 말

파일·일반 폴더: 설문도구.html 같은 파일은 내용 한 묶음이고, 폴더는 관련 파일을 담아 정리하는 공간입니다. 폴더에 파일을 넣고 저장하는 것만으로 Git의 변경 기록이 생기지는 않습니다.
리포지토리·로컬·원격: 일반적인 로컬 Git 프로젝트에서는 작업 파일이 있는 폴더 안의 숨김 .git 영역에 이력·브랜치 등 관리 정보가 들어 있습니다. 내 컴퓨터의 것은 로컬 저장소, GitHub 등 공유할 곳의 것은 원격 저장소라고 부릅니다.
커밋·브랜치: 커밋(commit)은 선택한 변경을 설명과 함께 한 시점의 버전으로 기록하는 일입니다. 브랜치(branch)는 같은 이력에서 다른 변경 흐름을 진행할 수 있게 하는 갈래입니다.

일반 파일 저장과 커밋은 무엇이 다를까요?

파일을 편집하고 저장하면 현재 파일 내용이 바뀝니다. Git에서는 그중 기록할 변경을 골라 커밋해야 버전 이력의 기준점이 생깁니다. “최종.html, 최종2.html, 진짜최종.html”을 계속 복사하는 대신 같은 파일의 기록된 버전을 비교할 수 있습니다. 저장소 안의 모든 파일과 매 편집 순간이 자동으로 기록되는 것은 아닙니다.

GitHub에 올리는 단계도 따로 있습니다

로컬에서 커밋만 하면 기록은 아직 내 컴퓨터에 있습니다. 푸시(push)는 그 기록을 연결된 원격 저장소에 올리는 일입니다. PR(Pull Request)은 변경을 검토하고 합치자고 제안하는 공간이고, 머지(merge)는 변경 흐름을 대상 브랜치에 통합하는 일입니다. Git은 GitHub 없이도 로컬 버전 관리에 사용할 수 있습니다.

AI가 고친 내용도 이유와 확인 결과를 남깁니다

예를 들어 “빈칸을 응답 수에서 제외하도록 수정했다. 3·4·빈칸·5의 평균 4.0을 확인했다”는 기록은 나중에 무엇을 되돌리거나 비교할지 판단하는 근거가 됩니다. 같은 부분을 서로 다르게 고쳐 충돌이 나면 어느 내용을 남길지 요구를 다시 확인해야 합니다.

화면에서 따라 하기

위쪽의 파일·일반 폴더·Git 저장소 비교를 선택해 현재 파일 내용, 파일 묶음, 변경 이력의 차이를 읽습니다. 숨김 .git은 일반적인 구성의 설명용 표시입니다.
아래 branch → commit → push → PR → merge를 차례로 누릅니다. 현재 어디까지 기록·공유·검토된 상황인지 구분합니다.
merge까지 본 뒤 실제 배포가 자동으로 이어지는지는 별도 설정이라는 설명을 읽습니다. 다음 실제 사례 화면에서 그 연결을 다시 확인합니다.

결과를 읽는 방법

파일 구조·이력·차이 표시는 교육용 모형입니다. 실제 파일이나 Git 저장소를 수정하거나 GitHub에 업로드하지 않습니다.

헷갈리기 쉬운 점

리포지토리는 단순히 “파일을 인터넷에 올리는 폴더”만을 뜻하지 않습니다. 로컬 저장소도 있고 변경 기록을 관리하는 구조가 핵심입니다. 또한 커밋, 푸시, PR, 머지, 배포는 서로 다른 단계입니다.

이해 확인 · 파일을 고쳐 저장한 뒤 커밋도 했습니다. 동료의 GitHub 화면에도 바로 새 버전이 보일까요?

해설 로컬에서만 작업했다면 아직 아닙니다. 연결된 원격 저장소에 푸시해야 공유됩니다. 운영 사이트 반영은 머지와 배포 설정까지 확인해야 합니다.

검증한 과정을 반복 실행하려면 시작 계기와 실행 조건을 정하는 자동화가 필요합니다.

더 읽기 · 원문과 공식 안내Git · Git의 개념 ↗Git · Git 저장소 만들기 ↗GitHub · 저장소의 개념 ↗

REPEAT A RELIABLE PROCESS

트리거 → 조건 → 동작

자동화에는
시작이 필요합니다.

언제 시작하고, 무엇을 확인하며,
어떤 작업을 실행할지 정합니다.

01 / TRIGGER

시작 계기

담당자가 버튼이나 요청으로 시작합니다.

02 / CONDITION

실행 조건

새 익명 설문 자료 있음워크숍 ID·점수 열 있음설문 파일 읽기 권한 있음

읽기 권한 → 새 응답 → 필수 열 순서로 확인합니다.

03 / ACTION

실행할 동작

자료 읽기 · 집계
검토용 보고서 초안 준비

담당자 검토 후 업무 적용

가상 사례 · 워크숍별 만족도 집계

워크숍_설문.csv
필수 열: 워크숍 ID · 점수

조건을 바꾼 뒤 버튼으로 시작 계기를 발생시켜 보세요.

READY워크숍별 만족도 집계를 준비합니다.
CASE워크숍 ID와 점수 열이 있는 가상 CSV 파일입니다.
NEXT시작 계기를 선택하고 실행 결과를 확인하세요.

반복하기 전에 정할 것

입력 자료와 접근 방법, 처리·완료 기준, 중복 실행 방지, 자료 없음·오류·예외 처리, 검토와 실행 권한, 실패 알림과 담당자, 처리 기록을 정합니다. 안정된 절차부터 반복하고 기관 명의의 발송·변경·최종 승인은 정한 권한과 검토 절차에 따릅니다.

파일명·응답값·권한은 교육용 가상 조건입니다. 실제 정기 작업 등록, 파일 감지, 보고서 생성이나 외부 API 호출은 실행하지 않습니다.

23 / 28 · 자동화 · 트리거 · 동작

스스로 공부하기

처음부터 차근차근

자동화는 “AI가 알아서 해준다”는 한 문장으로 구성되지 않습니다. 언제 시작하는지, 어떤 조건에서 진행하거나 멈출지, 무엇을 실행할지를 정해야 합니다. 이 화면은 워크숍 설문을 집계하는 가상 상황으로 트리거 → 조건 → 동작의 관계를 보여줍니다.

먼저 알아둘 말

트리거(Trigger): 작업을 시작시키는 계기입니다. 담당자의 요청, 매주 월요일 9시, 새 파일 도착 등이 예입니다.
조건(Condition): 작업을 계속할지 판단할 기준입니다. 읽기 권한이 있는지, 새 자료인지, 필수 열이 있는지 등을 확인합니다.
동작(Action): 조건을 통과한 뒤 수행할 일입니다. 자료 읽기·집계·보고서 초안 준비 등이 해당합니다.

시작할 시간이 됐다고 무조건 집계하면 안 됩니다

자동화 계정이 폴더를 못 읽으면 파일 내용부터 확인할 수 없습니다. 이미 처리한 파일만 있다면 새 응답이 아니므로 같은 초안을 또 만들지 않도록 건너뛸 수 있습니다. 점수는 있는데 워크숍 ID가 없으면 어느 과정의 응답인지 몰라 워크숍별 평균을 낼 수 없습니다. 각각 멈추거나 건너뛰는 이유가 다릅니다.

오류 안내에는 다음 행동이 있어야 합니다

“필수 항목이 빠졌습니다”만으로는 무엇을 고칠지 알기 어렵습니다. “워크숍 ID 열이 없어 W01과 W02 응답을 나눌 수 없습니다. 원자료에서 올바른 ID를 보완한 뒤 다시 실행하세요”처럼 누락·영향·보완 방법을 함께 설명해야 합니다. AI가 빈 ID를 추측해 채우는 것을 해결 방법으로 삼지 않습니다.

반복 작업에는 중복과 검토도 설계합니다

같은 파일이 다시 들어와도 한 번만 처리하도록 파일이나 작업의 식별자를 관리할 수 있습니다. 결과가 준비됐더라도 초안 검토 뒤 업무에 적용하도록 구분할 수 있습니다. 이 화면은 권한 → 새 자료 → 필수 열 순서로 확인하지만 모든 자동화의 검사 순서가 같다는 뜻은 아닙니다.

화면에서 따라 하기

수동 요청·정해진 시간·새 파일 도착 중 하나를 선택합니다. 아래 실행 버튼의 문구와 상황 설명이 바뀌는지 읽습니다.
읽기 권한, 새 자료, 필수 항목 조건을 하나씩 해제해 봅니다. 체크를 바꾼 단계는 아직 실행 전 상황 설명입니다.
실행 버튼을 눌러 STOP·SKIP·REVIEW 결과를 읽습니다. 모두 충족한 가상 사례에서는 W01의 3·4·빈칸·5에서 유효 3건, 평균 4.00인 검토 초안을 준비하는 상황을 보여줍니다.

결과를 읽는 방법

버튼이 시간 도착이나 파일 도착을 가정해 줍니다. 실제 예약 실행·폴더 감지·보고서 생성은 하지 않습니다. 조건을 바꾸면 이전 실행 결과를 지우고 새 상황을 먼저 표시합니다.

헷갈리기 쉬운 점

화면을 열어두고 조건을 선택한 것과 실제 자동화를 운영하는 것은 다릅니다. 브라우저를 닫아도 실행하려면 서버나 자동화 서비스의 실행 환경·권한·예약 설정 등이 별도로 필요합니다.

이해 확인 · 파일 이름만 바꾼 지난주 설문이 도착했습니다. 새 파일이라는 이유로 다시 집계해야 할까요?

해설 내용이나 처리 식별자로 이미 집계한 자료인지 확인하고 중복이면 건너뛰는 규칙이 필요합니다. 단순히 파일명만 다르다는 이유로 새 응답으로 세면 수치가 중복될 수 있습니다.

다음 화면은 이런 시작·조건·동작이 실제 사이트 수정과 자동 배포를 연결하는 예시입니다.

24 / 검증·기록·자동화

한 번의 수정 요청이
기록과 배포로 이어집니다.

우리의 제작 사례 · 실시간 번역기trans.stoom.win ↗GPT × GitHub × Cloudflare

수정부터 기록·배포 확인·사이트 점검까지, LLM에게 말로 요청합니다.

설정은 이미 완료! LLM의 도구 연결·저장소 접근 권한·Pages(Cloudflare) 자동 배포가 준비된 상황입니다.

1 / 4 단계

이번 예시에서 바꿀 것~~지금 실행하기~~실시간 번역 시작

01 / LLM에게 수정 요청

원하는 변화를
말로 설명합니다.

이 단계에서 LLM에게 할 말

trans.stoom.win 소개 화면의 ‘지금 실행하기’를 ‘실시간 번역 시작’으로 바꿔줘. 바뀐 화면도 보여줘.

LLM이 연결된 도구로 파일을 수정하고, 바뀐 화면을 보여줍니다.

담긴 것: 수정 요청·작업 기준과 연결된 작업공간의 파일
하는 일: LLM이 개발 도구로 코드를 수정

파일 수정과 공개 사이트 반영은 서로 다른 단계입니다.

LLM이 연결된 도구로 처리·확인해 알려준 결과 · 예시

GPT · 대화와 파일 수정내 작업공간

사람의 요청

“지금 실행하기” 버튼을
“실시간 번역 시작”으로 바꿔줘.

AI의 작업

소개 페이지의 버튼 문구를 바꿨습니다.
아래 수정한 파일 미리보기에서 확인해보세요.

수정한 파일 미리보기아직 공개 전

STOOM LIVE TRANSLATOR

강의의 음성을 자막과 번역으로.

바꾸기 전 ~~지금 실행하기 ↗~~파일 수정 후 실시간 번역 시작 ↗

LLM의 보고 · “요청한 문구로 파일을 수정했습니다.”

현재 반영 상태파일만 수정 · 아직 공개 전

화면·저장소명·변경 번호·배포 상태는 과정을 설명하는 교육용 모형입니다.

코드·기록 예시도 보기

수정한 버튼 · 설명용 예시파일 수정

- <button>지금 실행하기</button>
+ <button>실시간 번역 시작</button>

TRIGGER / 시작LLM이 변경을 배포 브랜치에 올림

CONDITION / 조건준비된 Git 연결과 배포 규칙 적용

ACTION / 동작Pages가 자동 배포 → LLM에게 결과 확인 요청

나는 LLM에게 말하는데, 뒤에서는 무엇이 이어지나요?

LLM → 개발 도구·GitHub

“버튼을 고쳐줘. 바뀐 내용을 GitHub에 기록하고 올려줘.”라고 요청합니다. LLM이 이미 연결된 개발 도구로 파일을 수정하고, 변경 이유와 함께 커밋·푸시합니다.

GitHub → Pages(Cloudflare)

저장소·배포 브랜치·자동 배포 설정은 이미 준비되어 있습니다. LLM이 해당 브랜치에 변경을 올리면 Pages의 Git 연동이 새 배포를 시작합니다. “배포가 끝났는지 확인해줘.”라고 이어서 요청합니다.

LLM → 배포 상태·브라우저

“배포 결과를 확인하고, 사이트를 열어 새 문구와 버튼 동작도 점검해줘.”라고 요청합니다. LLM이 연결된 도구로 상태와 접속 화면을 확인해 알려줍니다. 기대와 다르면 본 화면을 설명하고 수정을 요청합니다.

커밋은 “무엇을 바꿨는지 남긴 기록”, 푸시는 “그 기록을 GitHub에 올리기”입니다. 이 용어를 외우지 않아도 “이번 수정을 기록하고 올려줘.”라고 요청할 수 있습니다. v1.0 → v1.1 같은 버전 번호도 필요하면 LLM에게 정리해달라고 말합니다.

원하는 결과가 안 나오면? · 이렇게 LLM에게 물어보세요

파일이 그대로일 때 → “요청한 파일이 실제로 수정됐는지 확인하고, 바뀐 내용을 보여줘.”
GitHub까지만 반영됐을 때 → “방금 올린 변경의 배포 상태와 실패 원인을 확인하고, 필요한 수정을 진행해줘.”
배포 성공인데 화면이 그대로일 때 → “trans.stoom.win에서 이전 문구가 보여. 배포한 변경과 실제 주소·화면을 대조해 원인을 찾아줘.”

사례 주소는 trans.stoom.win입니다. 공개 소개 화면에서 STOOM LIVE TRANSLATOR의 실행 안내와 음성·자막·번역 기능을 확인했습니다. 라이선스·통계·개인 보정·전문용어집과 벡터 자료는 제작자가 설명한 기능을 반영했습니다. 저장소명·실제 배포 로그를 재현한 그림은 아니며, 문구 변경은 교육용 예시입니다.

우리는 원하는 결과를 말하고, 확인과 수정도 요청합니다.
LLM은 연결된 도구를 쓰고, GitHub·Pages는 각자의 일을 이어갑니다.

OpenAI · 플러그인과 도구 연결 Cloudflare · Git 자동 배포체험은 오프라인 모의 동작입니다.

24 / 28 · 실제 사례 · GPT → GitHub → Pages(Cloudflare)

스스로 공부하기

처음부터 차근차근

우리는 원하는 결과를 말로 설명하며 AI와 만드는 바이브코더입니다. 이 화면은 LLM의 개발 도구·GitHub 연결, 필요한 저장소 접근 권한, Pages(Cloudflare)의 자동 배포 설정이 이미 완료된 상황을 전제로 합니다. 설정 메뉴를 찾아 작업하는 대신, 수정·기록·배포 결과 확인·사이트 점검을 모두 LLM에게 요청합니다. trans.stoom.win 소개 화면의 “지금 실행하기”를 “실시간 번역 시작”으로 바꾸는 한 가지 예시를 끝까지 따라갑니다.

먼저 알아둘 말

LLM과 연결된 도구: LLM은 사람의 요청을 이해하고 어떤 작업이 필요한지 판단합니다. 실제 파일 수정, GitHub 기록, 배포 상태 조회, 브라우저 점검은 연결된 도구를 통해 수행합니다. 이 예시에서는 필요한 연결과 권한이 준비되어 있습니다.
커밋·푸시: 커밋은 무엇을 왜 바꿨는지 남기는 변경 기록이고, 푸시는 그 기록을 GitHub 같은 원격 저장소에 올리는 일입니다. 용어를 외우지 않아도 “이번 수정을 GitHub에 기록하고 올려줘.”라고 요청할 수 있습니다.
자동 배포: 준비된 Git 연결이 배포 브랜치의 새 변경을 받아 사이트에 제공할 파일을 준비하고 공개하는 과정입니다. 여기서는 Pages(Cloudflare)가 수행하고 LLM에게 그 결과를 확인해달라고 요청합니다.
도메인·배포 브랜치: trans.stoom.win 같은 도메인은 사용자가 찾아가는 주소입니다. 배포 브랜치는 배포 서비스가 새 코드를 받아오도록 정해 둔 변경 흐름입니다. 이 예시에서는 둘 다 연결이 완료되어 있습니다.

① 수정도 LLM에게 요청합니다

“trans.stoom.win 소개 화면의 ‘지금 실행하기’를 ‘실시간 번역 시작’으로 바꿔줘. 바뀐 화면도 보여줘.”라고 말합니다. LLM이 연결된 개발 도구로 작업공간의 파일을 고치고, 미리보기와 변경 내용을 알려줍니다. 오른쪽 GPT 화면은 이 답변과 파일의 변경 전후를 보여주는 예시입니다. 기대와 다르면 “새 문구가 너무 길어. 더 짧게 바꿔줘.”처럼 원하는 결과를 추가로 설명합니다.

② 기록하고 올리는 일도 요청합니다

“방금 수정한 내용을 GitHub에 기록하고 올려줘. 무엇이 바뀌었는지와 올라간 기록도 알려줘.”라고 말합니다. LLM이 변경을 커밋·푸시하고 결과를 보고합니다. GitHub에는 원본 코드와 변경 이력이 보관됩니다. 오른쪽 변경 #02는 이전 문구와 새 문구, 변경 이유가 함께 남았다는 설명용 그림입니다. 배포 브랜치에 변경이 올라가면 이미 준비된 Pages의 Git 연동이 자동 배포를 시작합니다.

③ 자동 배포의 결과도 물어봅니다

“방금 올린 변경의 자동 배포가 끝났는지 확인해줘. 실패했다면 원인을 찾아 수정하고 다시 확인해줘.”라고 요청합니다. Pages는 파일을 준비하고 새 버전을 제공하는 배포 서비스이고, LLM은 연결된 도구로 배포 상태와 오류를 확인해 알려줍니다. 이 둘의 역할을 구분하면 “AI가 파일을 고쳤다”와 “방문자가 볼 새 파일이 배포됐다”가 다른 상태임을 이해할 수 있습니다. 오른쪽은 같은 변경 #02의 배포가 성공했다는 예시입니다.

④ 사이트 화면과 동작 점검도 요청합니다

“trans.stoom.win을 열어 ‘실시간 번역 시작’ 문구가 보이는지, 버튼도 동작하는지 확인해줘. 변경 전후와 점검 결과를 알려줘.”라고 말합니다. LLM이 브라우저 도구로 화면과 동작을 점검하고 결과를 보여줍니다. 내가 보는 화면과 다르거나 기대한 동작이 나오지 않으면 그 현상을 그대로 알려줍니다. 예를 들어 “내 화면에는 이전 문구가 보여. 배포한 변경과 실제 주소·화면을 대조해서 원인을 찾아줘.”라고 요청할 수 있습니다.

오류를 만났을 때도 원하는 해결 결과를 말합니다

설정 화면이나 오류 용어를 전부 외울 필요는 없습니다. “어느 단계에서 멈췄는지 찾아서 설명해줘. 필요한 수정을 하고 같은 주소에서 다시 확인해줘.”라고 말할 수 있습니다. 오류 메시지나 내가 본 현상을 함께 알려주면 LLM이 확인할 단서가 됩니다. 사용자는 결과가 목적에 맞는지 판단하고, 빠진 점과 원하는 변화를 이어서 설명합니다.

사이트를 만드는 역할과 사용하는 동안의 역할은 다릅니다

GPT 같은 LLM과 연결 도구는 코드를 수정하고 기록·배포·점검을 돕습니다. GitHub는 원본과 이력을 보관하고, Pages는 배포한 파일을 제공합니다. 방문자 브라우저는 내려받은 코드로 언어 선택·실행 버튼·자막과 번역 화면을 움직입니다. 제작자는 Worker에서 라이선스를 확인하며 사용자 통계·개인 목소리 캘리브레이션·분야별 전문용어집과 벡터 자료도 관리한다고 설명했습니다. 이 실제 기능 설명과, 수업의 가상 변경 기록·배포 그림을 구분합니다.

이 수업의 버튼은 요청과 결과를 연습하는 모형입니다

각 단계의 노란 카드에는 LLM에게 할 요청문이 있고 복사 버튼으로 가져갈 수 있습니다. 오른쪽은 LLM이 연결된 도구로 처리하거나 확인해 보고한 결과를 나타냅니다. 마지막 새 버튼을 누르면 가상 자막·번역 화면이 열립니다. 실제 음성 인식이나 번역을 실행하지 않습니다. 코드가 궁금하면 접힌 기록 예시를 펼칠 수 있습니다. 실제 저장소명·변경 번호·배포 로그를 재현한 화면은 아닙니다.

화면에서 따라 하기

위의 설정 완료 전제를 읽습니다. GPT 단계에서 “LLM에게 할 말”과 처리 결과를 살펴보고 요청문 복사를 눌러봅니다.
GitHub 단계로 넘어가 기록을 올려달라는 요청과 변경 #02의 이전·새 문구를 비교합니다.
Pages(Cloudflare) 단계에서는 자동 배포 결과를 확인해달라는 요청과 같은 변경 #02의 성공 보고를 연결합니다.
사이트 단계에서는 화면과 버튼 동작 점검 요청을 읽고, 수업의 새 버튼을 눌러 가상 실행 결과도 체험합니다. 처음부터는 첫 요청으로 돌아갑니다.

결과를 읽는 방법

단계를 바꾸면 복사할 요청문과 LLM의 처리·확인 결과 예시가 함께 바뀝니다. 마지막 새 버튼은 가상 실행 화면을 열고 닫습니다. 이 체험 자체는 실제 LLM·GitHub·Cloudflare를 호출하거나 외부 사이트를 수정하지 않습니다.

헷갈리기 쉬운 점

“LLM에게 요청한다”는 말은 모든 역할이 LLM 한곳에서 실행된다는 뜻이 아닙니다. LLM은 연결된 도구로 작업하고, 준비된 Pages의 Git 연동이 자동 배포를 수행합니다. 커밋·푸시·배포·접속 화면 확인은 다른 상태입니다. 커밋이 쌓인다고 v1.0 같은 버전 번호가 저절로 증가하는 것도 아니므로 필요하면 번호 정리도 요청합니다.

이해 확인 · LLM이 GitHub에 기록했다고 했지만 사이트에는 예전 버튼이 보입니다. 어떤 요청을 이어서 하면 좋을까요?

해설 “방금 올린 변경의 배포가 성공했는지 확인해줘. trans.stoom.win의 화면과 배포한 변경을 대조하고, 이전 문구가 보이는 원인을 찾아 수정한 뒤 다시 점검해줘.”라고 요청합니다. 배포 상태·대상 변경·실제 주소와 화면을 함께 확인해달라고 말하면 됩니다.

다음 화면에서는 이 교육 페이지도 사람이 원하는 결과를 요청하고 AI와 함께 수정하며 만들었다는 과정을 돌아봅니다.

더 읽기 · 원문과 공식 안내Cloudflare Pages · Git 연결 배포 ↗STOOM LIVE TRANSLATOR · 공개 소개 ↗

25 / 활용과 다음 작업

이 페이지가 바로,
AI와 함께 만든 결과입니다.

사람이 요청을 구체화하고, AI가 구현하고, 결과를 보며 다시 수정했습니다.

사람의 실제 요청

“목적은 AI 협업하며 일하는법”

“html 기반의 인터렉티브 페이지로”

“지나고난뒤에서 클릭해서 찾아볼수 있게”

“그냥색상만 일치시킨거야 이건”디자인 참고 사이트를 줬지만, 첫 결과가 구조와 인터랙션보다 색상만 따랐다는 피드백입니다.

예시를 줘도, 결과의 차이를 짚고 다시 고칩니다.

MADE
WITH AI ↗

HUMAN대상·목적·기준
피드백·최종 활용 판단

AI구성·공식 자료 확인
코드·생성 이미지·점검

NEXT기관 맥락 확인
교육 현장에 맞게 조정

참고 예시가 있어도, 요구를 놓칠 수 있습니다

처음 결과

참고 사이트가 있었지만, 첫 결과는 색상 위주의 반영에 그쳤다는 지적을 받았습니다.

사람의 피드백

“컨텐츠의 내용을 잘 전달하게끔 각 프레임을 인터렉티브한 요소와 디자인적 요소를 살려서 재구성하고 재배치해야지”

다시 확인할 기준

정보의 위계·화면 배치·클릭 반응을 참고 예시와 대조합니다. 수정 뒤에도 내용 전달과 실제 조작을 다시 확인합니다.

맥락과 예시를 제공한 뒤에도 결과를 비교하고, 놓친 요구를 구체적으로 짚으며 수정·검토합니다.

생성 이미지와 제작 과정

표지와 개념 화면의 입체 조형물 4종은 AI 이미지 생성 도구로 제작했습니다. 협업 모형, 문서 파싱 기계, 손·커서·문서·톱니 도구, 화면·서버·DB 시스템입니다. 실제 인물·센터 행사·내부 자료를 묘사한 사진이 아닙니다. 큰 제목, 기울인 콜라주와 공간 탐색은 사용자가 제시한 디자인 사이트를 참고해 이 교육의 내용으로 구성했습니다.

이 대화에서 실제 제시한 요청과 피드백을 바탕으로 작성했습니다. 담당자의 최종 내용 검토와 현장 적용 판단은 이어서 필요합니다.

25 / 28 · 이 페이지의 AI 제작 과정

스스로 공부하기

처음부터 차근차근

지금 보고 있는 교육 페이지도 AI와 함께 만든 결과물입니다. 사람은 대상·목적·기준을 정하고 화면을 보며 수정할 점을 알려줬고, AI는 내용 구성과 코드·이미지 제작을 도왔습니다. 이 화면은 앞에서 배운 협업 과정이 실제 제작에서 어떻게 나타났는지 돌아보는 사례입니다.

먼저 알아둘 말

인터랙티브: 사용자의 선택·입력·클릭에 따라 반응이 달라지는 성질입니다. 예를 들어 PDF와 JSON을 바꿔 보거나 숫자를 넣어 결과를 확인하는 방식입니다.
참고 예시·피드백: 참고 예시는 원하는 방향을 보여주는 자료이고, 피드백은 현재 결과와 원하는 결과의 차이를 짚는 말입니다. 예시를 줘도 구체적으로 비교할 필요가 있습니다.
생성 이미지·실제 기록: 이 페이지의 조형물 이미지는 AI가 만든 개념 삽화입니다. 실제 인물이나 내부 행사 사진, 실제 업무 결과를 증명하는 기록과는 구분해서 읽습니다.

색이 같아도 요구를 충분히 따른 것은 아닙니다

제작 과정에서 참고 사이트가 있었지만 첫 결과가 색상 위주로만 반영됐다는 피드백이 나왔습니다. 원래 원한 것은 내용을 잘 전달하는 화면 구성과 클릭 반응까지 포함한 경험이었습니다. “색은 비슷하지만 정보의 위계와 화면 배치, 인터랙션이 다르다”처럼 차이를 구체화해야 수정 방향이 분명해집니다.

좋은 수정 요청은 관찰 가능한 기준을 줍니다

“더 멋지게” 대신 “개념을 누르면 대표 예시가 바뀌게”, “체크는 해제된 상태로 시작해 하나씩 설명하게”, “숫자를 직접 넣어 계산하게”라고 요청하면 실제 동작으로 확인할 수 있습니다. AI가 고친 뒤에는 클릭하고 입력해 요청한 동작이 생겼는지 다시 봅니다.

보기 좋은 결과와 검토된 결과는 함께 필요합니다

생성 삽화·콜라주·전시실 공간은 이해와 탐색을 돕습니다. 그러나 숫자·용어·출처와 계산 동작의 정확성은 별도로 살핍니다. 캐릭터와 전환 연출도 내용을 가리지 않는지, 작은 화면과 성능이 낮은 기기에서 부담이 크지 않은지 최종 사용 환경에서 확인할 대상입니다.

화면에서 따라 하기

노란 메모에 적힌 요청과 피드백을 읽고 대상·목적·형식·사용 방식이 어떻게 정해졌는지 찾습니다.
“참고 예시가 있어도 요구를 놓칠 수 있습니다”를 열어 처음 결과, 사람의 피드백, 다시 확인할 기준을 비교합니다.
생성 이미지와 제작 과정 설명을 읽고, 실제 사례의 증거와 교육용 삽화·모형을 구분합니다. 앞의 화면 중 한 곳을 다시 눌러 구현된 요구를 확인해 봅니다.

결과를 읽는 방법

이 화면은 제작 과정을 설명합니다. 삽화가 실제 행사를 촬영한 사진이거나, 예시의 숫자와 배포 상태가 실제 기관 기록이라는 뜻은 아닙니다.

헷갈리기 쉬운 점

AI로 만들었다고 사람이 아무 역할도 하지 않은 것도, 사람이 여러 번 고쳤다고 AI 협업이 아닌 것도 아닙니다. 목적을 정하고 결과를 보며 기준에 맞춰 고치는 과정 자체가 협업입니다.

이해 확인 · 참고 예시와 색만 비슷한 결과를 받았습니다. 어떤 피드백이 좋을까요?

해설 원하는 예시와 비교해 제목·본문의 크기, 정보 순서, 화면 배치, 클릭 후 변화 중 차이를 짚습니다. 그중 먼저 고칠 항목과 확인 가능한 결과를 구체적으로 요청합니다.

이 경험을 자신의 작은 업무 한 가지로 옮겨 첫 요청을 만들어 봅니다.

26 / 활용과 다음 작업

작은 업무 하나에서
협업을 시작하세요.

AI 역량은 맡기고, 확인하고, 함께 고치는 능력입니다.

내가 맡길 초안은 무엇이고,
직접 확인할 기준은 무엇인가요?

바꿔볼 업무 하나직접 확인할 기준 하나

조금 더 잘 맞는 답을 원한다면

AI에게 역할을 맡겨보세요.

페르소나 = AI에게 맡기는 역할과 관점.
누구의 관점에서, 어떤 방식으로 도울지 정하면 답변이 더 잘 맞는 경우가 있습니다.

AI에게 맡길 역할 선택 사항

역할에 대상·할 일·기준을 함께 적어보세요. 사실과 계산은 근거로 확인합니다.

다음 작업에 붙여 넣을 요청

업무 하나와 확인 기준을 적어보세요.
입력 내용은 이 브라우저 안에서만 사용됩니다.

한 번의 성공을 다음 업무로

결과가 마음에 들고, 같은 일을 또 한다면
“이 과정을 스킬로 만들어줘.”

이번에 잘된 순서·서식·확인 기준을 묶어 두면, 다음에도 처음부터 길게 설명할 필요를 줄일 수 있습니다.

01 결과가 잘 나왔는지 확인
02 반복해서 할 업무인지 판단
03 잘된 과정을 스킬로 정리

AI에게 이렇게 요청해보세요 · 요청문 펼치기

방금 함께 완성한 업무의 결과가 마음에 들어.
이 일을 반복할 때 다시 쓸 수 있도록 스킬로 만들어줘.

잘된 작업 순서, 필요한 자료, 결과 형식, 확인 기준과 주의점을 정리하고,
성공한 결과나 서식은 참고 예시로 연결해줘.
날짜·대상·자료처럼 매번 바뀌는 값은 새로 입력받도록 해줘.
빠진 정보가 있으면 먼저 질문하고,
지금 쓰는 AI 환경에서 저장하고 다시 사용하는 방법도 알려줘.

완성된 결과뿐 아니라, 그 결과를 만든 방법과 확인 기준을 남깁니다. 새 자료로 써 보고 필요한 부분은 함께 고칩니다.

처음 만나는 터미널 · 직접 해보면 생각보다 단순합니다

터미널은 컴퓨터에게
글로 부탁하는 창입니다.

마우스로 폴더를 여는 대신 “어디에 있지?”, “어떤 파일이 있지?”를 한 줄로 묻는 방식입니다.
채팅 문장 대신 정해진 명령어를 적고 Enter를 누르면, 결과가 아래에 나옵니다. 여기서 먼저 가볍게 연습해보세요.

터미널명령을 입력하고 결과를 보는 창

PowerShell · Bash · zsh그 명령을 해석해 처리하는 셸

각 환경에서 흔히 쓰는 셸을 예로 들었습니다. 같은 일을 해도 명령과 경로 표기가 조금 다릅니다. PowerShell은 Linux·macOS에도 설치해 쓸 수 있습니다.

가상 터미널에서 직접 입력해보세요실제 내 PC의 파일·설정은 바뀌지 않습니다.

① 예시를 눌러 명령을 넣고
② Enter 또는 실행을 눌러보세요.

직접 쳐도 됩니다.
help로 지원 명령을 보고,
↑ / ↓로 앞서 쓴 명령을 고릅니다.

PowerShell 연습가상 환경

현재 위치C:\AI-practice

첫 화면은 현재 위치를 확인한 결과입니다. 파일 목록 보기부터 해보세요.

브라우저 안의 연습 모형입니다. 예시 명령만 처리하며 출력 형식은 간단히 줄였습니다. 환경을 바꾸면 가상 폴더와 화면도 처음 상태로 돌아갑니다.

같은 일을 하는 명령, 세 환경을 나란히 보면

대표 명령 비교 · 셸의 설정과 설치된 도구에 따라 달라질 수 있습니다.
하고 싶은 일	Windows · PowerShell	Linux · Bash	macOS · zsh
지금 위치 확인	`Get-Location`	`pwd`	`pwd`
파일 이름 목록	`Get-ChildItem -Name`	`ls`	`ls`
문서 내용 읽기	`Get-Content readme.txt`	`cat readme.txt`	`cat readme.txt`
docs 폴더로 이동	`cd docs`	`cd docs`	`cd docs`

명령은 운영체제뿐 아니라 사용 중인 셸에 따라서도 달라집니다. Windows Terminal은 PowerShell이나 다른 셸을 띄우는 창이며, PowerShell 자체와는 구분합니다.

AI가 “터미널에 입력해줘”라고 하면, 이렇게 물어보세요

Windows에서는 시작 메뉴에서 ‘터미널’ 또는 ‘PowerShell’을, Mac에서는 Spotlight에서 ‘터미널’을 찾을 수 있습니다. Linux는 사용하는 배포판의 터미널 앱을 엽니다. AI에게 내 운영체제와 셸을 알려주면 알맞은 명령으로 안내받기 쉽습니다.

나는 터미널을 처음 써.
내 환경은 [Windows PowerShell / Linux Bash / macOS zsh]야.
어느 창을 열고 어디에 입력할지부터 한 단계씩 알려줘.
이 명령이 무슨 일을 하는지, 파일이나 설정을 바꾸는지도 설명해줘.
성공하면 어떤 결과가 보이는지 알려주고,
오류가 나오면 내가 그 내용을 보여줄 테니 다음 행동을 같이 정해줘.

Microsoft · 터미널 PowerShell Ubuntu · 명령줄 기초 Apple · Mac 터미널

입력·요청 구성은 브라우저 안에서 작동합니다. 실제 AI 호출, 저장, 전송을 하지 않습니다.

26 / 28 · 다음 업무에 적용

스스로 공부하기

처음부터 차근차근

배운 내용을 적용할 때는 큰 업무 전체를 한 번에 맡기기보다, 결과를 확인할 수 있는 작은 작업 하나로 시작합니다. “내가 맡길 초안”과 “직접 확인할 기준”을 함께 정하면 AI에게 요구하기도, 받은 결과를 평가하기도 쉬워집니다. 이 화면은 그 첫 요청을 문장으로 만드는 연습입니다. 필요하면 AI에게 역할과 관점을 정해 주는 페르소나를 더해 답변의 방향과 설명 방식을 맞춰 봅니다. 결과가 마음에 들고 같은 일을 반복한다면, 성공한 절차와 확인 기준을 스킬로 남겨 다음에 재사용할 수 있습니다. 터미널은 컴퓨터에게 글로 요청하고 결과를 보는 창입니다. Windows·Linux·macOS 예시를 바꿔 가며 가상 명령을 직접 입력해 볼 수 있습니다.

먼저 알아둘 말

작은 업무: 입력과 결과가 비교적 분명한 범위의 일입니다. 공지 한 건 정리, 설문 문항 초안, 운영 체크리스트처럼 시작과 확인 지점이 있는 일을 고릅니다.
확인 가능한 기준: 직접 비교하거나 실행해 볼 수 있는 조건입니다. 날짜·대상 누락 없음, 유효 응답 수 일치, 버튼 동작 확인 등이 예입니다.
맥락 질문: 바로 만들기 전에 목적·자료·제약 중 빠진 정보를 확인하는 질문입니다. 모르는 조건을 AI가 임의로 채우지 않게 하는 데 도움이 됩니다.
페르소나: AI에게 맡기는 역할과 관점입니다. “처음 배우는 사람에게 설명하는 선생님”, “독자의 눈으로 글을 다듬는 편집자”처럼 누구의 관점에서 어떻게 도울지 알려줍니다.
스킬로 남기기: 성공한 업무의 작업 순서·필요한 자료·결과 형식·확인 기준을 다시 쓸 수 있게 정리하는 일입니다. 결과물 한 개만 보관하는 것에서 한 걸음 더 나아가, 결과를 만드는 방법을 남깁니다.
터미널: 컴퓨터에 글로 명령을 입력하고 결과를 보는 창입니다. 마우스로 누르던 작업을 한 줄로 부탁하는 다른 사용 방식이라고 생각하면 됩니다.
셸·PowerShell·Bash·zsh: 명령을 읽고 처리하는 프로그램을 셸이라고 합니다. PowerShell, Bash, zsh는 그 예입니다. 터미널이라는 창 안에서 셸을 사용합니다.

두 입력칸을 실제로 채워 봅시다

업무에는 “신입 참여자에게 보낼 워크숍 안내문 초안”을, 확인 기준에는 “날짜·장소·준비물·신청 방법이 원자료와 일치하고 세 문단 이내”를 적을 수 있습니다. 단순히 “문서 만들기 / 잘 만들기”라고 쓰는 것보다 결과를 평가하기 쉽습니다.

요청문을 만든 뒤에도 자료와 조건을 보완합니다

생성된 문장에는 바로 만들기 전에 필요한 맥락과 자료를 질문하라는 내용이 들어갑니다. 실제 AI 대화에 붙여 넣고 허용된 원자료를 제공한 뒤 질문에 답합니다. 자료가 없다면 어떤 자료가 필요한지부터 묻고, 업무가 크면 단계와 첫 결과물을 작게 나눠 정합니다.

역할을 정하면 더 잘 맞는 경우도 있습니다

같은 안내문을 보더라도 선생님의 관점에서는 처음 듣는 용어와 쉬운 예시를, 편집자의 관점에서는 문장 길이와 표현을, 검토자의 관점에서는 빠진 조건을 더 분명히 요청할 수 있습니다. 이렇게 원하는 관점과 행동을 구체적으로 정하면 답변의 방향·말투·설명 수준을 맞추는 데 도움이 될 수 있습니다. “최고 전문가가 되어줘”처럼 이름만 붙이기보다 대상과 할 일을 함께 적어 보세요.

페르소나는 선택 사항입니다

예를 들어 “처음 참여하는 직원에게 설명하는 선생님의 관점에서, 어려운 용어를 풀고 신청 순서를 세 단계로 정리해줘”라고 요청할 수 있습니다. 역할을 지정해도 사실과 계산이 항상 정확해지는 것은 아니므로 원자료와 확인 기준은 계속 필요합니다. 이미 원하는 결과가 분명하다면 역할을 비워 두고 업무·자료·결과 형식만 명확히 적어도 됩니다.

결과가 잘 나왔고, 같은 일을 또 한다면 “스킬로 만들어줘”

워크숍 안내문을 함께 고쳐 일정·장소·신청 방법이 정확하고 문장도 마음에 들게 완성했다고 해 봅시다. 다음 달에도 비슷한 안내문을 만든다면 “방금 잘된 과정을 다음에도 다시 쓸 수 있게 스킬로 만들어줘”라고 요청할 수 있습니다. 언제 사용할지, 어떤 자료를 받을지, 어떤 순서로 만들지, 결과를 무엇과 대조할지 정리합니다. 성공한 서식이나 예시를 곁에 두면 원하는 결과를 설명하기도 쉽습니다.

한 번의 내용과 반복할 방법을 나눠 남깁니다

지난 워크숍의 날짜·장소·대상은 다음번에 달라질 수 있으므로 고정된 정답처럼 남기지 않습니다. 스킬에는 새 원자료에서 일정·장소·신청 방법을 확인하는 절차를 적고, 실제 값은 매번 새로 받게 합니다. 만들어진 스킬이 어디에 저장되고 어떻게 다시 쓰이는지는 사용 중인 AI 환경에서 확인합니다. 새 자료 한 건에 적용해 결과를 살펴보고, 빠진 조건이 있으면 지침을 함께 고쳐 갑니다.

AI가 “터미널에 넣어줘”라고 하면

AI에게 “나는 처음 써. 내 환경은 Windows PowerShell이야. 어느 창을 열고 어디에 입력할지, 이 명령이 무엇을 하는지, 성공하면 어떤 결과가 보일지 한 단계씩 알려줘”라고 요청할 수 있습니다. 처음부터 명령을 외울 필요는 없습니다. 입력한 명령과 나온 결과를 함께 보며 배우면 됩니다. 파일이나 설정을 바꾸는 명령이라면 무엇이 바뀌는지 먼저 설명해 달라고 하세요.

세 환경은 비슷하지만 완전히 같지는 않습니다

Windows에서 흔히 쓰는 PowerShell은 위치를 Get-Location, 파일 이름 목록을 Get-ChildItem -Name으로 확인할 수 있습니다. Linux의 Bash와 macOS의 zsh는 pwd, ls 같은 명령을 사용합니다. cd docs처럼 겹치는 명령도 있습니다. 차이는 운영체제뿐 아니라 사용 중인 셸에서도 생깁니다. Windows Terminal은 PowerShell이나 다른 셸을 띄우는 창이고, PowerShell은 Linux·macOS에도 설치할 수 있습니다. 이 자료는 익숙한 세 조합을 예로 들었습니다.

여기서는 파일을 건드리지 않고 직접 해봅니다

가상 터미널의 예시 버튼은 명령을 입력칸에 넣습니다. Enter나 실행을 누르면 결과가 위에 쌓입니다. 먼저 위치와 목록을 보고, readme.txt를 읽고, docs로 이동해 보세요. cd ..는 한 단계 위로 돌아갑니다. 폴더 만들기는 브라우저 안의 가상 폴더만 바꿉니다. 잘못 입력하면 안내를 읽고 고치면 됩니다. 화면에 출력이 없이 위치만 바뀌는 명령도 있습니다. 이 연습은 몇 가지 명령만 흉내 내며 실제 PowerShell·Bash·zsh를 실행하지 않습니다.

화면에서 따라 하기

바꿔볼 업무 하나와 직접 확인할 기준 하나를 입력합니다. 실제 개인·내부 정보를 넣을 필요 없이 연습용 가상 업무로 해도 됩니다. 필요하면 역할 칸에 페르소나를 적거나 선생님·편집자·검토자 예시를 고릅니다. 비워 두어도 요청을 만들 수 있습니다.
“나의 첫 요청 만들기”를 눌러 오른쪽에 정리된 문장을 읽습니다. 둘 중 하나가 비면 두 항목을 모두 적으라는 안내를 확인합니다. 역할을 넣었다면 요청문 맨 앞의 역할 문장이 원하는 관점인지 확인합니다.
요청문을 복사해 사용할 AI에 붙여 넣습니다. 작업 후에는 내가 정한 기준과 비교하고, 차이가 있으면 구체적인 예로 수정 요청을 합니다.
아래 “스킬로 만들어줘” 안내의 요청문을 펼쳐 읽거나 복사합니다. 실제로 성공한 대화에서 사용하고, 성공한 절차·서식·확인 기준과 매번 달라질 값을 구분해 정리하도록 요청합니다.
가상 터미널에서 Windows를 고르고 파일 목록과 문서 읽기를 실행합니다. 명령을 직접 치거나 예시를 눌러 입력한 뒤 Enter를 누릅니다. cd docs와 cd ..로 위치가 바뀌는지 확인합니다.
Linux·macOS로 바꾸어 위치와 목록 명령이 pwd·ls로 달라지는지 비교합니다. 폴더를 만들고 목록에서 확인한 뒤 연습 처음부터로 되돌립니다. 환경을 바꿔도 연습이 초기화됩니다.

결과를 읽는 방법

이 화면은 입력을 요청문으로 조합합니다. 실제 AI에게 전송하거나 업무 파일을 생성하지 않습니다. 복사 뒤 실제 대화를 시작하는 단계는 별도입니다. 역할을 입력한 경우에만 요청 앞에 [AI에게 맡길 역할]이 붙습니다. 예시 버튼은 역할 칸을 채우며, 나의 첫 요청 만들기를 누르면 문장에 반영됩니다. 아래 복사 버튼은 스킬을 만들어 달라는 요청문을 복사합니다. 이 발표 화면이 실제 스킬을 생성하거나 설치하는 것은 아닙니다. 스킬 개념 다시 보기는 10번으로 이동합니다. 터미널 체험은 정해진 명령을 브라우저의 가상 폴더에서 처리합니다. 실제 PC 파일·설정·설치·네트워크 요청에는 영향을 주지 않습니다. 입력을 잘못해도 설명을 보고 다시 시도할 수 있습니다.

헷갈리기 쉬운 점

처음부터 자동화나 큰 시스템을 만들어야 AI를 활용하는 것은 아닙니다. 작은 초안 한 건에서 확인 방법을 익히고, 같은 일이 반복될 때 스킬·도구·자동화를 검토할 수 있습니다.

이해 확인 · 확인 기준으로 “보기 좋은 안내문”만 썼습니다. 무엇을 더할 수 있을까요?

해설 필수 정보 네 가지가 빠지지 않았는지, 원문과 날짜가 맞는지, 초보자가 읽고 준비할 행동을 알 수 있는지처럼 관찰하고 비교할 수 있는 기준을 보탭니다.

다음 화면에서는 원자료와 대화의 결과를 연결해, 다음 작업에 쌓아 쓰는 방법을 정리합니다.

더 읽기 · 원문과 공식 안내OpenAI · 역할·목표·설명 방식을 정하는 프롬프트 ↗OpenAI · 스킬의 구성 ↗Microsoft · Windows Terminal의 역할 ↗Microsoft · PowerShell이란? ↗Ubuntu · 명령줄 처음 배우기 ↗Apple · Mac 터미널 사용 설명서 ↗

27 / 활용과 다음 작업

출처를 남기면,
다음 지식으로 이어집니다

답을 확인하고, 내 자료를 연결하고, 다음 작업의 근거로 키웁니다.

출처가 있으면 세 가지가 가능합니다.

01 / 확인

답을 원문과 대조

LLM이 틀린 내용을 그럴듯하게 말하는 ‘할루시네이션’을 점검합니다. 인용한 자료가 실제로 있고, 그 주장을 뒷받침하는지 확인합니다.

02 / 연결

자료 사이의 관계 찾기

이 결론이 어느 자료에서 나왔고, 어떤 노트·보고서에 쓰였는지 연결합니다. 원자료가 바뀌면 고칠 자료도 찾을 수 있습니다.

03 / 축적

내 결과도 다음의 출처로

대화로 얻은 좋은 분석·비교·아이디어를 이름 있는 자료로 남깁니다. 다음 작업에서 다시 읽고 보완할 수 있습니다.

LLM WIKI · 개념 사례

대화의 결과를, 연결된 지식으로 남깁니다.

LLM이 원자료를 바탕으로 주제별 문서와 연결을 관리하고, 유용한 대화 결과도 새 페이지로 보존하는 방식입니다. 특정 제품명이 아니라 개인 지식 기반을 만드는 패턴입니다.

Andrej Karpathy · LLM Wiki 원문 ↗

같은 워크숍 사례 · 아래 자료를 차례로 눌러보세요

원자료에서 다음 기획안까지

교육용 가상 기록 · 실제 보관 기능 아님

보존할 원자료

A01 · 워크숍 설문 원자료

5, 4, 빈칸, 3, 4, 6

1~5점 만족도 문항의 입력값입니다. 범위를 벗어난 6도 원자료에는 그대로 보존하고, 분석에서 제외한 이유를 따로 남깁니다.

자료 위치: 설문-A01.csv · 응답 열 · 2~7행
기준·버전: 1~5점 척도 · 2026-10-15 수집본

이 자료가 쓰인 곳

내 노트에서도 원문으로 돌아옵니다.

AI 초안과 검증 노트가 모두 A01을 가리킵니다. 나중에 원자료를 보완하면 어떤 분석을 다시 확인할지 찾을 수 있습니다.

파일 이름·주소와 함께 표·페이지·행 같은 위치도 남기면 같은 부분을 다시 확인하기 쉽습니다.

내가 만든 자료에도 출처를. 이름·날짜·버전·근거·검토 상태를 붙여, 다음 작업이 이어받게 합니다.

대화 결과를 보관할 때 남길 항목과 요청문

처음에는 이 항목부터

자료 이름·번호 — 다시 찾을 이름과 A03 같은 고유 번호
날짜·버전 — 작성일·확인일과 수정본 구분
근거·위치 — 원문 주소·파일·페이지·표·행
대화 맥락 — 질문·입력 자료·중요한 조건·AI 활용
관계·상태 — 참고·수정·활용한 자료, 확인됨·가설·제안

원본을 보존하고 요약·해석은 구분합니다. 주소가 바뀌어도 찾을 수 있게 자료 이름과 날짜도 함께 남깁니다.

AI에게 이렇게 요청해 보세요.

이번 대화에서 다음에도 쓸 결과를 지식 노트로 정리해줘.
자료 이름, 작성일·버전, 질문과 조건, 핵심 결과를 적어줘.
각 결과에 원자료와 정확한 위치를 연결하고, 확인한 사실·해석·새 제안을 구분해줘.
앞서 만든 어떤 노트를 참고하거나 수정하는지도 적어줘.
확인되지 않은 내용은 확인 필요로 남겨줘.
다음 작업에서 이 노트를 다시 참고할 수 있도록 관련 자료 목록과 수정 이유를 붙여줘.

교육용 관계 예시: 원자료 A01 → AI 초안 A02(6점 포함 오류) → 검증한 내 노트 A03 v2(유효 4건·평균 4.00) → 기획안 A04(A03 인용, 원자료 A01 연결). 내 자료에도 이름·날짜·버전·근거·검토 상태를 남깁니다.

OpenAI · 언어 모델의 할루시네이션 설명 ↗위 관계도와 보관 항목은 이 교육을 위한 적용 예시입니다.

필요할 때 확인할 공식 안내와 관련 문서

OpenAI · Use ChatGPT

기능, Chat·Work·Codex의 사용 방식과 결과 검토

OpenAI · Skills & Plugins

재사용하는 지침과 설치 가능한 기능 묶음

OpenAI · Plugin architecture

스킬과 선택적인 MCP 도구 연결의 구성

OpenAI · ChatGPT Work

검토 가능한 파일·결과물을 만드는 작업

OpenAI · Permissions

도구·자료 접근과 승인 범위

Git · About Version Control

파일의 변경을 기록하고 이전 버전과 비교하는 개념

GitHub · GitHub flow

branch, commit, push, PR, merge의 협업 흐름

GitHub · Pull requests

변경 사항을 함께 검토하고 통합하는 제안

MDN · 웹·클라이언트·서버 Cloudflare · Pages 배포 Workers D1 OpenAI · Sites Microsoft · DB 정규화 OpenAI · PDF 입력 KORDOC OSI · 오픈소스 디자인 참고 · Sidejob 디자인 참고 · Griflan Labs

자료 확인 기준: 2026년 10월 15일
기능·화면·권한은 계정과 기관 설정, 제품 변경에 따라 달라질 수 있습니다. 해당 기관의 계약·계정·정보 처리 기준은 자료 확인 필요입니다.
모든 센터 업무 사례와 설문 값은 교육용 가상 예시입니다.
퀴즈·요청문 구성기·계산·파싱·자동화의 학습 예시는 브라우저 안에서 작동하며 실제 외부 AI 호출이나 업무 시스템 실행을 하지 않습니다. 전시실 캐릭터의 온라인 공통 카운터는 같은 사이트의 서버에 횟수를 저장합니다. 로컬 미리보기 횟수는 이 브라우저에만 보관합니다. 출처 링크 열기는 인터넷이 필요합니다.
삽화와 페이지의 구성·구현은 AI로 제작했습니다. 사람의 요청과 기준은 제작 과정 화면에서 확인할 수 있습니다.

27 / 28 · 출처 · 아카이브 · LLM Wiki

스스로 공부하기

처음부터 차근차근

출처를 남기면 AI의 답을 확인할 수 있고, 내가 만든 자료가 무엇을 바탕으로 발전했는지도 찾을 수 있습니다. 대화에서 얻은 좋은 분석·비교·아이디어를 이름 있는 노트로 보존하고 원자료와 연결하면 다음 작업의 출발점이 됩니다. 이 화면은 출처를 정확성 확인, 자료 사이의 관계, 지식의 축적이라는 세 가지 관점에서 설명합니다.

먼저 알아둘 말

할루시네이션: LLM이 사실과 다른 내용이나 존재하지 않는 참고문헌을 그럴듯하게 만들어 말하는 현상입니다. 자연스러운 문장이나 출처 모양의 링크만으로 정확함을 판단하지 않습니다.
아카이브: 나중에 다시 찾아 이해하고 활용할 수 있도록 자료를 보존·정리하는 일입니다. 파일뿐 아니라 어떤 질문에서 나왔고 어떻게 확인했는지까지 함께 남기면 쓸모가 커집니다.
LLM Wiki: LLM을 이용해 자료와 요약·주제별 문서를 연결하고 갱신하는 지식 기반의 한 패턴입니다. 여기서는 Karpathy의 개념 사례를 참고하며, 특정 제품을 설치해야만 하는 방식으로 설명하지 않습니다.
내 자료의 출처화: 내 분석 노트에도 자료 이름·고유 번호·날짜·버전·근거·검토 상태를 붙여 다시 찾고 인용할 수 있게 만드는 일입니다. 출처가 된다는 것과 내용이 확인됐다는 것은 따로 기록합니다.

출처는 틀린 답을 발견하고 수정할 길입니다

AI가 실제로 없는 문헌 이름이나 링크를 만들 수도 있습니다. 링크가 열리더라도 내가 주장한 숫자나 결론이 그 자료에 있는지 확인해야 합니다. 원문 제목·작성 주체·날짜·파일 위치·페이지·표·행을 남기면 같은 근거를 다시 대조하기 쉽습니다. 제품 기능은 공식 안내의 버전과 내 사용 환경도 함께 봅니다.

대화 결과가 연결된 지식으로 쌓이게 합니다

LLM Wiki 원문은 원자료를 보존하고 문서 사이의 연결을 관리하며, 유용한 질문의 결과도 지식 페이지로 다시 남기는 흐름을 제안합니다. 이 수업에서는 이를 내 업무의 분석 노트와 기획안으로 바꾸어 보여줍니다. 필요한 자료를 다음 대화에서 AI가 읽을 수 있게 제공하고, 새 근거가 생기면 관련 노트를 함께 갱신하는 것이 핵심입니다.

같은 설문에서 초안과 검증 노트를 구분합니다

A01 원자료는 5·4·빈칸·3·4·6입니다. A02 초안은 6점을 포함해 유효 5건·평균 4.40으로 틀렸습니다. A03 노트 v2는 1~5점 기준으로 빈칸과 6점을 제외해 유효 4건·평균 4.00으로 수정합니다. 원자료를 몰래 고치지 않고, 분석에서 무엇을 제외했고 어떤 초안을 고쳤는지 남깁니다. A02를 보존한다면 수정 전 오류가 있는 상태라는 표시도 필요합니다.

내가 만든 노트도 다음 문서의 출처가 됩니다

A04 기획안에서는 A03 v2를 인용하면서 그 노트의 근거인 A01까지 연결합니다. 다음에 담당자가 평균을 확인하거나 계산 기준을 바꾸려 할 때 처음 자료로 돌아갈 수 있습니다. 만족도 숫자에서 실습 시간을 늘리자는 새 아이디어가 나왔다면 그 부분은 제안으로 구분하고 수요·운영 여건을 추가 확인합니다. 내 해석과 원문에 있는 사실을 섞어 쓰지 않는 것이 중요합니다.

보관할 때는 관계와 수정 이유를 함께 남깁니다

원자료·대화 기록·검증한 노트·다음 문서를 관련 자료 목록으로 묶어보세요. 이름, 작성·확인일, 버전, 질문의 조건, 원자료 위치, 확인 상태, 어떤 노트를 수정했는지를 기록합니다. 이렇게 하면 자료를 다시 쓸 때 무엇을 믿고 무엇을 확인해야 하는지 알 수 있습니다. 중요한 결론의 근거가 바뀌면 그 결론을 인용한 문서도 다시 살펴봅니다.

화면에서 따라 하기

상단의 확인·연결·축적을 읽고, 최근 AI와 만든 결과 하나에 원자료와 확인 기록이 남아 있는지 떠올립니다.
A01 설문 원자료 → A02 AI 초안 → A03 검증한 분석 노트 → A04 다음 기획안을 차례로 누릅니다. 같은 원자료에서 잘못된 초안이 어떻게 수정되고 재사용되는지 읽습니다.
A03에서 근거 A01, 수정한 초안 A02, 활용한 문서 A04 버튼을 눌러 관계를 거슬러 가거나 앞으로 따라가 봅니다. 내 노트가 중간 연결점이라는 것을 확인합니다.
대화 결과 보관 항목을 펼쳐 자료 이름·날짜·버전·근거·관계를 읽습니다. 요청문을 복사해 실제 AI 대화에서 지식 노트의 초안을 만드는 데 사용할 수 있습니다.
아래 공식 안내와 관련 문서를 펼쳐 필요한 근거를 확인합니다. 실제로 보관할 때는 예시의 날짜·자료번호를 복사하는 데서 끝내지 말고 내가 가진 원문과 검토 기록으로 채웁니다.

결과를 읽는 방법

네 자료와 관련 자료 버튼은 이 HTML 안의 가상 기록을 보여줍니다. 실제 대화나 파일을 수집·보관하지 않습니다. 요청문 복사 뒤 노트 작성·저장과 다음 AI에 자료 제공은 별도로 진행합니다. 원문 링크를 읽으려면 인터넷 연결이 필요합니다.

헷갈리기 쉬운 점

내 자료를 출처로 삼았다는 이유로 검증이 끝나지는 않습니다. 확인되지 않은 AI 답을 노트와 보고서가 서로 인용하면 오류도 함께 이어집니다. 확인한 사실·해석·가설·새 제안의 상태와 최초 근거를 남기며, 대화가 저장되어 있다는 사실만으로 다음 작업의 AI가 그 내용을 읽었다고 가정하지 않습니다.

이해 확인 · 내 노트 A03을 세 기획안이 인용했습니다. 평균 4.00의 독립된 근거가 세 개가 된 것일까요?

해설 아닙니다. 세 문서 모두 같은 분석 노트와 원자료 A01을 바탕으로 합니다. 인용 횟수가 근거의 수나 정확성을 늘려주지는 않습니다. A03의 검토 상태와 원자료 위치를 유지하고, 새로운 자료를 추가했을 때 무엇이 달라졌는지 구분합니다.

최근 AI와 만든 유용한 결과 하나를 원자료와 연결해 보세요. 마지막 화면에서는 모든 내용을 외우려는 부담을 내려놓고 첫 대화를 시작합니다.

더 읽기 · 원문과 공식 안내Andrej Karpathy · LLM Wiki 원문 ↗OpenAI · 언어 모델의 할루시네이션 ↗

28 / 나가며

배운 내용을 상징하는 종이 길을 따라 사람과 붉은 AI 커서가 빛나는 노란 문 앞에 함께 선 AI 생성 개념 삽화

내용이 많아서, 어렵게 느껴졌나요?

다 기억하지
않아도 괜찮아요.

자세한 내용을 지금 다 알 필요는 없습니다.
“이런 것도 있구나.”
한 번 들어본 것만으로도 충분한 시작입니다.

지금의 AI는 우리가 미처 떠올리지 못한
조건과 방법까지 함께 챙겨줄 수 있습니다.
놓친 내용은, AI와 함께 다시 찾으면 됩니다.

요청하세요.질문하세요.협업하세요.

방향을 정하고, 결과를 확인하며.
이제, 당신의 첫 질문으로.by Stoom

첫 마디가 막힌다면, 이 문장으로 시작해 보세요

나는 AI를 처음 활용해 봅니다. 지금 하고 싶은 일은 [내가 하고 싶은 일]입니다. 바로 만들기 전에 인터뷰어가 되어 필요한 질문을 하나씩 해주세요. 내 답변을 바탕으로 작은 첫 결과물을 함께 만들고, 빠진 조건과 확인할 점도 챙겨주세요.

28 / 28 · 이제 AI와 함께 시작하세요

스스로 공부하기

처음부터 차근차근

내용이 많아 낯설게 느껴졌다면, 지금 모든 용어를 외우거나 모든 기술을 이해하려고 하지 않아도 괜찮습니다. “이런 것도 있구나” 하고 들어본 경험은 다음에 AI에게 무엇을 물어볼지 떠올리는 단서가 됩니다. 이제는 내가 하고 싶은 작은 일 하나를 골라 AI에게 요청하고, 질문하고, 함께 만들어 보면 됩니다.

먼저 알아둘 말

요청하기: 내가 하고 싶은 일과 원하는 결과를 말하는 것입니다. “잘해줘” 대신 누구를 위한 일인지, 어떤 결과를 원하는지부터 이야기합니다.
질문하기: 모르는 용어의 뜻뿐 아니라 어떤 방법이 있는지, 왜 그 방법을 쓰는지, 나에게 무엇이 필요한지도 묻는 것입니다.
협업하기: 한 번에 완성품을 받는 데서 끝내지 않고 질문에 답하고, 나온 결과를 보고, 원하는 방향으로 함께 고쳐 나가는 것입니다.

전부 기억하기보다, 필요할 때 다시 찾으면 됩니다

DB·벡터·스킬·플러그인이 정확히 무엇인지 지금 설명하지 못해도 괜찮습니다. “전에 그런 방법을 들어봤는데, 내 일에도 쓸 수 있을까?”라고 AI에게 물을 수 있다면 시작할 준비가 된 것입니다. 이 자료의 목차와 키워드 찾기도 필요할 때 돌아와 쓰면 됩니다.

AI에게 빠진 조건을 함께 챙겨 달라고 요청합니다

지금의 AI는 목적과 자료를 알려주면 우리가 미처 떠올리지 못한 조건·방법·확인할 점을 제안할 수 있습니다. 내가 모든 항목을 먼저 나열해야만 대화할 수 있는 것은 아닙니다. “빠진 것이 있다면 먼저 질문해 줘”라고 요청해 보세요. 다만 알려주지 않은 내 사정이나 연결되지 않은 자료를 저절로 알고 있는 것은 아니므로, 질문에 답하며 맥락을 채워갑니다.

첫 대화는 인터뷰에서 시작해도 좋습니다

예를 들어 “처음 워크숍을 맡았는데 어디서부터 준비할지 모르겠어. 인터뷰어가 되어 필요한 질문을 하나씩 해줘”라고 말할 수 있습니다. AI가 대상·목표·일정·자료를 물으면 아는 범위에서 답합니다. 그런 뒤 운영 체크리스트 한 장처럼 작고 확인하기 쉬운 첫 결과물을 함께 만듭니다.

좋은 협업은 결과를 보며 다음 말을 이어갑니다

초안을 읽고 빠진 날짜를 알려주거나, 표현을 쉽게 바꿔 달라고 하거나, 근거를 보여 달라고 할 수 있습니다. 처음 요청이 완벽하지 않아도 대화를 통해 구체화할 수 있습니다. 방향을 정하고 중요한 사실과 결과를 확인하는 일은 사람이 맡고, 정리·초안·대안 찾기는 AI의 도움을 받습니다.

화면에서 따라 하기

지금 해보고 싶은 일 하나를 떠올립니다. 공지 초안, 일정 정리, 새 용어 이해처럼 작은 일이어도 충분합니다.
ChatGPT·Claude·Gemini 중 사용하려는 서비스 바로가기를 선택합니다. 링크는 해당 공식 서비스의 새 창을 열며 이 페이지의 대화를 전송하지 않습니다.
첫 마디가 막히면 접힌 안내를 펼쳐 첫 질문을 복사하고, 대괄호 부분을 내 일로 바꾸어 AI에게 말해 봅니다. “바로 만들기 전에 필요한 질문부터 해줘”라는 요청을 활용합니다.
질문에 답한 뒤 작은 결과 하나를 받아 읽고, 좋았던 부분과 고칠 부분을 말합니다. 필요한 근거를 확인하고 유용한 결과는 다시 찾을 수 있도록 보관합니다.

결과를 읽는 방법

이 마지막 화면의 세 링크는 공식 AI 서비스를 엽니다. 첫 질문 복사는 대화의 시작 문장을 준비하는 기능입니다. 복사한 내용이 자동으로 제출되거나 AI 답변이 이 HTML 안에 생성되지는 않습니다.

헷갈리기 쉬운 점

“모든 기술을 다 알아야 시작할 수 있다”는 부담도, “AI가 아무 설명 없이 모든 것을 알아서 해준다”는 기대도 내려놓습니다. 모르는 상태에서 질문하고, 필요한 정보를 주고, 나온 결과를 함께 고치는 과정으로 시작할 수 있습니다.

이해 확인 · 하고 싶은 일은 있지만 무엇을 준비해야 할지 모르겠습니다. 첫 마디를 어떻게 시작할까요?

해설 “나는 이 일을 하고 싶어. 바로 만들기 전에 인터뷰어가 되어 필요한 질문을 하나씩 해줘. 내 답변을 바탕으로 작은 첫 결과물을 함께 만들자”라고 요청합니다. 모르는 조건은 모른다고 말하고, 필요한 자료와 다음 행동을 함께 정합니다.

지금 떠오르는 작은 질문 하나로 시작해 보세요. 우측 하단의 나가기를 누르면 개념 전시실로 돌아가 필요한 내용을 다시 찾을 수 있습니다.

더 읽기 · 원문과 공식 안내ChatGPT · 공식 서비스 ↗Claude · 공식 서비스 ↗Gemini · 공식 서비스 ↗

AI와 함께일하는 법.

AI는 넓은 범주,GPT는 모델 계열입니다.

AI · 인공지능

초안은 맡기고, 해석은 함께.최종 판단은 사람이 합니다.

AI에게 맡기기

AI와 함께하기

사람이 책임지기

요약에서 도구 제작까지,확인 가능한 초안을 맡깁니다.

“이 공지를 세 줄로 줄여줘.”

자료·도구·권한이 있어야실제로 일할 수 있습니다.

미공개 내부 사실을근거 없이 알 수 없습니다.

AI의 제안에 현장 맥락을 더하고,함께 고쳐 완성합니다.

맡기는 기준을 정하면협업이 쉬워집니다

이 단계는누가 주도하면 좋을까요?

대화할 때도,일을 맡길 때도.

Chat

Work

Codex

작업 전에는 토론하고,모르면 방법까지 묻습니다.

스킬은 지침,플러그인은 묶음.

반복할 업무 방식을 적습니다.

“규정을 찾아줘”가 실제 조회로 이어지는 길

원문 파일을 준비합니다

좋은 요청에는 목표와검증 기준이 함께 들어갑니다

말로 만들고,결과로 확인.

이런 도구를만들고 싶어요.

빈칸까지 세었네요.이렇게 고쳐주세요.

이미 있는도구에서시작하세요.

예시로 살펴보기

MIT·Apache 2.0은코드를 쓰는 조건입니다.

MIT

Apache 2.0

원래 저작권 표시와 MIT 허가문을 남깁니다.

HTMLCSSJS.

워크숍 관심 표시

AI와 함께
일하는 법.

AI는 넓은 범주,
GPT는 모델 계열입니다.

초안은 맡기고, 해석은 함께.
최종 판단은 사람이 합니다.

요약에서 도구 제작까지,
확인 가능한 초안을 맡깁니다.

자료·도구·권한이 있어야
실제로 일할 수 있습니다.

미공개 내부 사실을
근거 없이 알 수 없습니다.

AI의 제안에 현장 맥락을 더하고,
함께 고쳐 완성합니다.

맡기는 기준을 정하면
협업이 쉬워집니다

이 단계는
누가 주도하면 좋을까요?

대화할 때도,
일을 맡길 때도.

작업 전에는 토론하고,
모르면 방법까지 묻습니다.

스킬은 지침,
플러그인은 묶음.

좋은 요청에는 목표와
검증 기준이 함께 들어갑니다

말로 만들고,
결과로 확인.

이런 도구를
만들고 싶어요.

빈칸까지 세었네요.
이렇게 고쳐주세요.

이미 있는
도구에서
시작하세요.

MIT·Apache 2.0은
코드를 쓰는 조건입니다.