누가 접속했을까?
어디서 일하고,
무엇을 남길까?

로그인은
‘내 기록의 주인’을 찾는 기준

“오늘 온 민수와 어제 온 민수는
같은 사람일까요?”

가장 익숙한 로그인은 ID와 비밀번호(PW)를 입력하는 방식입니다. ID는 “어느 계정인가”, 비밀번호는 “그 계정을 사용할 사람인가”를 확인하는 데 씁니다. 앱 안에서는 학생 번호처럼 고유한 계정 번호로 기록을 구분합니다.

ID·PW에서
OAuth 소셜 로그인으로

ID/PW 방식에서는 우리 앱이 아이디와 비밀번호를 확인합니다. 소셜 로그인에서는 Google 같은 곳이 본인을 확인하고, 우리 앱이 그 결과를 받아 입장시킵니다. Google 비밀번호는 Google 화면에 입력합니다.

입장한 뒤에는? 앱이 로그인 상태를 유지해 주는 것은 ‘입장 팔찌’, 관리자 기능을 따로 제한하는 것은 ‘직원 전용 출입구’입니다. 소셜 로그인을 붙여도 내 기록과 권한은 우리 앱이 관리합니다.

흔히 ‘OAuth 소셜 로그인’이라고 부릅니다. OAuth는 접근 권한을 맡기는 약속이고, Google 로그인 같은 사용자 확인에는 OIDC도 사용합니다. 소셜 로그인이 모든 보안 문제를 대신 해결하는 것은 아닙니다.

출처: Google · 소셜 로그인 개요, OIDC Core. 회원증·학생증은 이해를 돕는 비유입니다.

코드는 레시피,
로컬은 우리 집 주방, 서버는 가게

오늘의 경기: 강사가 혼자 시험하면 우리 집 주방에서 맛보기, 참가자들의 질문을 받으면 가게 운영입니다. 질문은 주문, 응답은 음식, 경기 기록은 장부에 해당합니다. 오늘은 강사 PC가 서버 역할을 합니다.

서버를 끄면 가게가 문을 닫듯 접속이 멈춥니다. 파일로 보관한 코드와 경기 장부는 다시 켜도 이어 읽을 수 있습니다.

출처: MDN · 웹 서버, Git · 버전 관리

IP는 실제 주소,
도메인은 기억하기 쉬운 이름

가게의 숫자 주소를 외우기보다 이름으로 찾는 편이 쉽습니다. 인터넷에서도 사람은 도메인 이름을 쓰고, 컴퓨터는 IP 주소를 찾아 접속합니다.

오늘은 같은 공유기 안에서 접속합니다

오늘은 별도 도메인 없이 강사가 안내한 IP와 포트로 접속합니다. game.example은 설명용이며 실제 게임 주소가 아닙니다. 친구 기기에서 localhost를 열면 친구 자신의 컴퓨터로 갑니다.

192.168.0.0/24는 오늘 사용하는 대역 이름입니다. 192.168.0.까지가 같은 건물, 마지막 숫자가 방 번호라고 생각해 보세요. 192.168.0.1은 공유기 주소로 자주 쓰입니다.

현재 실제 IP를 확인해 사용합니다. 같은 공유기여도 게스트망·연결 차단 설정 때문에 접속이 막힐 수 있습니다. /24의 마스크는 255.255.255.0이며 자세한 숫자 계산은 오늘 생략합니다.

출처: MDN · 도메인과 DNS, Microsoft · 주소와 서브넷

배포의 마지막은
다른 사람 기기에서 확인하기

03에서 레시피·주방·가게가 무엇인지 배웠고, 04에서 찾아갈 주소를 배웠습니다. 이제 만든 앱을 다른 사람이 실제로 쓰게 하는 순서를 봅니다. 이것이 배포입니다.

1. 앱을 실행할 자리를 정한다

   오늘은 강사 PC입니다. 인터넷 서비스라면 계속 운영할 컴퓨터나 서비스를 준비합니다.

2. 코드와 필요한 설정을 넣고 실행한다

   가게에 레시피와 재료를 준비하고 불을 켜듯, 앱을 켜고 저장소·클라우드 AI 연결을 확인합니다.

3. 사람들이 찾아올 주소를 안내한다

   오늘은 강사 IP와 포트를 보냅니다. 도메인을 쓰는 서비스라면 이름이 올바른 서버로 연결되게 설정합니다.

4. 다른 사람 기기에서 끝까지 써 본다

   참가자가 별명으로 들어가 질문하고 응답을 받는지, 자기 기록이 남는지 확인합니다.

운영을 계속하려면 서버를 켜 두고, 데이터 보관과 사용자별 권한도 준비합니다. 인터넷으로 공개할 때는 HTTPS 주소 같은 추가 준비가 필요합니다.

한 문장으로 · “배포는 실행하고, 주소를 알려 주고, 다른 사람이 실제로 쓸 수 있는지 확인하는 일이다.”

오늘은 같은 공유기 안에서 사용합니다. 실제 소셜 로그인 연결과 인터넷 공개 배포는 별도 실습에서 다룹니다.

출처: Render · 웹 서비스 배포, 데이터 영구 저장

에이전트에게 맡기는
공유 서버 탐정 미션

에이전트가 서버에 있는 행사 조건과 장소 정보를 읽고, 모두 만족하는 장소를 골라 제출합니다. 여러 학생이 서버 한 대에 각자 에이전트로 접속해 언제든 자기 속도로 도전합니다.

가상의 행사 조건과 장소 자료로 API 요청과 응답, 참가별 기록을 익히는 연습입니다.

별명으로 참가하고,
에이전트가 서버 자료 읽기

1. 실습 화면을 열고 별명을 입력합니다

   서버가 참가 번호와 개인 입장 키를 발급합니다. 같은 별명을 써도 참가 번호와 기록은 따로 만들어집니다.

2. 에이전트 요청문을 복사합니다

   참가자 본인의 키만 사용하고, 다른 사람의 기록이나 키를 찾지 말라고 안내합니다.

3. 에이전트가 API 안내를 읽습니다

   /labs/gandalf/api/docs에서 서버와 대화하는 주소와 방법을 확인합니다.

4. 행사 조건과 장소 목록을 비교합니다

   /api/challenge와 /api/venues 자료를 읽고 조건을 모두 만족하는 장소를 찾습니다.

5. 선택을 제출하고 기록을 확인합니다

   /api/submit으로 장소 ID를 제출합니다. 참가자마다 최대 10번까지 시도할 수 있습니다.

정답을 찍기보다
자료를 확인하고 근거를 설명하기

화면의 요청문을 복사해 사용하세요. 아래는 에이전트가 맡을 일의 예입니다.

너는 공유 서버 탐정 미션을 돕는 에이전트야.
내가 제공한 참가자 키만 사용해. 다른 참가자의 정보나 기록을 찾거나 사용하지 마.

1. /labs/gandalf/api/docs를 읽고 API 사용법을 확인해.
2. /api/challenge에서 행사 조건을 읽어.
3. /api/venues에서 장소 목록을 읽어.
4. 인원, 예산, 실내 여부, 계단 없는 접근, 종료 시각을 하나씩 비교해.
5. 조건을 모두 만족하는 장소가 있으면 그 이유를 간단히 설명하고 /api/submit에 장소 ID를 제출해.
6. 확실하지 않은 조건은 추측하지 말고 어떤 자료가 부족한지 말해.

내가 직접 제공한 입장 정보와 실습 API만 사용해. 서버 파일이나 다른 참가자의 기록을 조사하지 마.

학생은 자기 입장 정보로 접속하고, 에이전트는 공개된 문서·조건·장소 목록을 읽습니다. 참가 키는 다른 사람과 공유하지 마세요.

한 걸음씩 읽고
근거를 확인합니다

정답을 빠르게 맞히는 것보다, 어떤 조건을 읽고 왜 그 장소를 골랐는지 설명할 수 있는지가 중요합니다.

방금 해 본 일에서
서버와 API를 찾아봅니다

서버는 여러 사람의 요청을 받고, 각자 기록을 따로 보관하는 공동 작업대와 같습니다.

작은 변경으로
서버의 일을 살펴봅니다

화면의 안내를 보고
한 가지씩 확인합니다

실습은 항상 열려 있습니다. 강사의 시작 신호를 기다릴 필요가 없습니다.

요청이 어디를 거쳐
결과가 되었을까요?

오늘 다룬 범위와
참고 자료

1. MDN · HTTP 개요 · 브라우저와 서버가 요청과 응답을 주고받는 방식
2. MDN · 웹 서버란? · 서버가 요청을 받아 자료를 보내는 기본 역할
3. MDN · API · 프로그램끼리 정해진 약속으로 정보를 교환
4. Git · 버전 관리 · 소스코드 변경 기록을 보관하는 방법

실습은 가상의 행사 조건과 장소 정보를 사용합니다. 실제 개인정보를 입력하지 마세요. 한 서버를 공유하지만 참가자별 입장 정보와 제출 기록은 분리됩니다.