브라우저에서 코드를 실행하게 만들었는데 사용자가 새로고침 한 번으로 작성 내용을 잃는다면, 학습 서비스의 핵심 경험은 무너집니다. 반대로 제출 결과만 남고 사용자가 어떤 오류를 보고 무엇을 고쳤는지 알 수 없다면, 제품팀은 사용자가 학습한 것인지 우연히 정답을 맞힌 것인지 판단하기 어렵습니다.
설치 없는 개발 학습 서비스의 우선 과제는 언어나 개발 도구를 웹으로 옮기는 일이 아닙니다. 사용자의 작업을 안전하게 이어 주고, 학습자가 문제를 푸는 과정에서 남긴 판단의 흔적을 필요한 범위에서 보존하는 일입니다. 그 다음에 자동화가 판정할 영역과 사람이 읽어야 할 영역을 분리해야 합니다.
이 글은 온라인 실습 서비스를 구축하는 제품 관리자가 요구사항, 구현, 검증, 운영 순서로 결정할 수 있도록 정리한 청사진입니다.
요구사항은 ‘계정 상태’와 ‘작업 상태’를 분리하는 데서 시작한다
게스트 사용자는 가입 전에 실습을 시작할 수 있어야 하지만, 그 기록이 로그인 사용자의 기존 초안과 섞여서는 안 됩니다. 같은 사람이 브라우저에서 게스트로 작성한 뒤 로그인할 수 있고, 로그인 계정에도 이전 실습 기록이 있을 수 있기 때문입니다.
초기 요구사항에서는 아래 두 공간을 별도로 정의하는 편이 좋습니다.
- 게스트 작업 공간: 로그인 전 현재 기기와 세션에서 작성한 코드, 쿼리, 노트, 실행 상태를 임시 보관한다.
- 계정 작업 공간: 로그인한 사용자의 과제별 초안, 제출 이력, 실행 기록, 학습 진행 상태를 보관한다.
여기서 중요한 결정은 로그인 순간에 게스트 기록을 어떻게 다룰지입니다. 자동 병합은 편해 보이지만, 계정에 이미 진행 중인 초안이 있을 때 어느 내용을 기준으로 삼을지 불명확해집니다. 사용자가 가져오기를 선택하게 하고, 계정에 더 최근의 초안이 있다면 그 사실을 보여 준 뒤 복구 기준을 정하는 방식이 안전합니다.
이 단계의 산출물은 화면 설계서보다 먼저 나와야 합니다. 제품, 개발, 교육 운영 담당자가 함께 다음을 명시한 작업 보존 정책을 작성하십시오.
| 결정 항목 | 먼저 정할 질문 |
|---|---|
| 게스트 데이터 | 어떤 시점까지 임시 보관하며, 로그인 전에는 어디까지 복구할 수 있는가 |
| 가져오기 | 게스트 기록을 계정으로 옮길 때 사용자의 명시적 선택이 필요한가 |
| 충돌 처리 | 게스트 초안과 계정 초안이 모두 있을 때 최근 수정본, 사용자 선택, 별도 사본 중 무엇을 우선하는가 |
| 제출 후 수정 | 제출본과 이후 수정본을 구분해 남길 것인가 |
| 삭제와 초기화 | 사용자가 실습을 다시 시작할 때 코드, 실행 결과, 노트 중 무엇을 지우는가 |
이 문서는 개인정보 처리 고지와 별개로 제품 동작을 정하는 문서입니다. 사용자가 “내가 쓴 내용은 어디에 남는가”, 운영자가 “어떤 기록을 학습 판단에 써도 되는가”를 같은 기준으로 이해하게 합니다.
저장 구현에서는 늦게 도착한 요청이 최신 내용을 덮지 않게 한다
자동 저장은 저장 요청을 보냈다는 사실만으로 충분하지 않습니다. 네트워크나 서버 처리 순서에 따라 먼저 보낸 요청의 응답이 나중에 도착할 수 있습니다. 이때 과거 내용이 최신 편집본을 덮어쓰면, 사용자는 저장 기능을 신뢰하기 어렵습니다.
따라서 초안 데이터에는 최소한 다음 식별 정보를 둬야 합니다.
- 과제와 작업 공간을 구분하는 식별자
- 저장 요청마다 증가하는 편집 버전 또는 순서값
- 클라이언트가 마지막으로 확정한 저장 버전
- 수정 시각과 제출 시각
- 게스트 기록인지 계정 기록인지 나타내는 상태
구현 방식은 팀의 기술 선택에 따라 달라질 수 있지만, 검증해야 할 원칙은 같습니다. 서버는 이전 버전의 저장 요청이 최신 버전을 덮지 않도록 막아야 하고, 클라이언트는 늦은 응답을 받은 뒤 화면 상태를 과거 내용으로 되돌리지 않아야 합니다.
이 단계의 테스트 시나리오는 기능 단위보다 사용자의 실패 장면을 중심으로 작성하는 편이 낫습니다.
- 같은 과제를 빠르게 연속 편집한 뒤 저장 응답 순서를 의도적으로 뒤집는다.
- 게스트로 작성한 뒤 로그인하고, 계정에 기존 초안이 있는 상황을 재현한다.
- 실행 직후 브라우저를 닫고 다시 열어 초안과 실행 상태가 정책대로 복구되는지 확인한다.
- 제출 후 코드를 수정했을 때 제출본과 현재 초안이 혼동되지 않는지 확인한다.
여기서 발견되는 오류는 편집기의 작은 결함이 아닙니다. 이후 피드백, 평가, 학습 분석이 의존하는 원자료가 흔들리는 문제입니다.
학습 데이터는 ‘얼마나 오래 머물렀나’보다 ‘어디까지 시도했나’를 기록한다
가입자 수나 문제 열람 수만으로는 실습 서비스의 상태를 판단하기 어렵습니다. 사용자가 첫 실행까지 도달했는지, 실패한 결과를 본 뒤 코드를 고쳐 다시 실행했는지, 자신의 판단을 노트로 남겼는지가 더 직접적인 신호일 수 있습니다.
제품팀은 모든 클릭을 수집하려 하기보다, 학습 흐름을 판단할 수 있는 사건을 먼저 정의해야 합니다. 예를 들면 다음과 같습니다.
| 학습 단계 | 보존할 수 있는 기록 | 제품 판단에 쓰는 질문 |
|---|---|---|
| 시작 | 과제 열람, 편집 시작 | 과제 설명만 읽고 이탈하는가 |
| 실행 | 첫 실행, 실행 결과 상태 | 사용자가 실행 환경까지 도달하는가 |
| 수정 | 실행 뒤 편집, 재실행 | 오류 결과를 보고 다시 시도하는가 |
| 설명 | 노트 작성, 이유 입력 | 결과의 이유를 언어로 설명하는가 |
| 제출 | 제출본, 제출 시각, 판정 결과 | 어떤 상태에서 답안을 제출하는가 |
이 기록은 학습자를 감시하기 위한 목록이 아니라, 다음 개선 우선순위를 정하기 위한 관측 장치입니다. 첫 실행 이전 이탈이 많다면 문제 설명, 시작 화면, 실행 버튼 주변을 살펴볼 근거가 생깁니다. 재실행 없이 곧바로 제출하는 흐름이 많다면 자동 피드백이 수정 행동을 돕는지 확인해야 합니다.
다만 이 데이터만으로 학습 효과를 단정해서는 안 됩니다. 첫 실행, 재시도, 노트 작성은 유용한 행동 신호이지만 이해도 자체와 같지는 않습니다. 운영 화면에서도 “학습 완료” 같은 결론보다 “첫 실행 도달”, “재실행 발생”, “노트 작성”처럼 관찰한 사실을 분리해 표시하는 편이 좋습니다.
자동화는 정답 판정과 다음 행동 안내에 집중한다
프로그래밍 교육의 자동 채점은 보통 단위 테스트, 실행 결과, 기준 답안과의 비교를 활용합니다. 이런 방식은 빠른 피드백과 반복 제출을 지원하는 데 적합합니다. 특히 SQL 결과가 조건에 맞는지, 프로그램 출력이 기대값과 일치하는지, 필수 명령을 수행했는지처럼 명확한 조건을 확인할 때 효과적입니다.
반면 자동 판정 결과를 코드 품질 전체에 대한 평가로 확대하면 문제가 생깁니다. 같은 결과를 내는 코드라도 읽기 쉬운지, 설명이 충분한지, 다른 사람이 유지보수하기 좋은지는 별도 판단이 필요합니다. 코드 가독성 평가는 자동화뿐 아니라 사람의 평가에서도 일관성을 확보하기 어렵다는 연구 결과도 있습니다.
그래서 평가 설계서는 채점 항목을 아래처럼 나누는 편이 현실적입니다.
- 자동 판정: 실행 가능 여부, 정해진 입력과 출력의 일치, 필수 조건 충족, 제출 형식
- 자동 피드백: 실패한 조건, 기대 결과와 실제 결과의 차이, 재실행이나 수정이 필요한 위치
- 사람 검토: 문제 해석의 타당성, 코드와 노트에 담긴 이유, 여러 해결안 사이의 선택, 협업 맥락에서의 설명
- 검토 보류: 가독성처럼 기준과 평가자 합의가 충분하지 않은 항목
사람 검토를 넣는다고 해서 모든 제출물을 사람이 읽어야 한다는 뜻은 아닙니다. 과제 자체가 정답 확인 중심인지, 사용자가 자신의 접근을 설명해야 하는지에 따라 검토 대상을 좁혀야 합니다. 예컨대 결과가 맞는지만 확인하면 되는 기초 연습과, 왜 특정 조건을 제외했는지 설명해야 하는 데이터 과제는 같은 평가 흐름을 쓰기 어렵습니다.
출시 전에는 기능 완성보다 복구와 판정의 경계부터 검증한다
첫 출시에서 제품팀이 확인할 것은 “코드가 실행된다”만이 아닙니다. 아래 두 질문에 답할 수 있어야 합니다.
첫째, 사용자가 중간에 나가도 돌아와서 자신의 작업을 이어 갈 수 있는가.
둘째, 자동 결과가 알려 주는 것과 사람이 판단해야 하는 것이 화면과 운영 절차에서 구분되는가.
이를 위해 출시 후보 버전에서 게스트 시작, 로그인 전환, 동시 저장, 제출 후 재수정, 자동 판정 실패, 검토 요청의 흐름을 하나의 시나리오로 연결해 점검하십시오. 특히 운영 담당자가 제출본, 현재 초안, 실행 기록, 학습 노트를 서로 다른 데이터로 구별해 볼 수 있어야 합니다. 이 구분이 없으면 사용자에게는 복구 문제로, 운영자에게는 평가 오류로 나타납니다.
제품이 안정화된 뒤에야 어떤 데이터를 더 수집할지 늘리는 편이 낫습니다. 먼저 정할 일은 많지 않습니다. 다음 스프린트에서 과제 하나를 골라 게스트 초안, 계정 초안, 제출본, 실행 기록, 노트의 관계를 한 장의 상태 전이도로 그려 보십시오. 그 그림에서 사라지는 작업과 자동 판정으로 설명할 수 없는 판단이 보이면, 그것이 구현 우선순위입니다.
