계정 생성 시 고려해야 하는 점

feat. 추천하는 계정 생성 규칙

계정 생성의 필수 요소

계정 생성을 할 때 필수적으로 입력하게 되는 요소는 사용자 정보 3가지와 초기 비밀번호입니다.

사용자 정보 3가지는 다음과 같습니다.

  • 성 (last name)

  • 이름 (first name)

  • 기본 이메일 (ID)

계정 생성 시 무엇을 고려해야 하나요?

아래에 계정 생성시 고려해야 하는 많은 요소들을 정리해 보았습니다.
저 요소 중 한두가지만 너무 강조하거나, 반대로 한두가지를 너무 간과해서 계정 생성 후 어려움을 겪게되는 경우가 많습니다.
주의깊게 살펴보시고 학교 실정에 가장 알맞은 생성 규칙을 정하시기 바랍니다.

학생의 이름과 현 학년 학번이 사용자 정보 중 어딘가에 들어가야 한다.

구글 워크스페이스를 운영하게 되면, 클래스룸 초대나 문서 권한 부여 등 개별 학생을 호출하게 되는 일이 많습니다.
이때 교사들이 학생의 이메일주소를 기억하고 입력하는 것은 매우 불편하겠죠?

아래 사진들은 클래스룸에서 학생 초대를 위해 학생을 검색하는 다양한 방법들입니다.
관리자가 조직에 사용자검색을 허용한 경우, 학생의 성, 이름, ID 중 하나만 입력해도 학생을 검색하고 호출할 수 있습니다.

따라서 교사가 학생을 쉽게 검색할 수 있도록 하려면 학생의 이름과 학번 정보사용자정보 3개 중 한 곳에는 반드시 들어가야 합니다.

기본 이메일(ID)은 최대한 학생이 기억하기 쉽게 만드는 것이 좋다.

사실 이 문제 때문에 펜데믹 초반에 아이디 생성규칙의 춘추전국시대가 열렸었습니다. 학교마다 생각하는 '기억하기 쉬운'방법이 달랐거든요.

  • 학생들이 자신의 학번은 잘 까먹지 않을 것이다.

  • 한번 만든 아이디를 끝까지 유지해야 잘 까먹지 않을 것이다

  • 자신이 직접 아이디명을 만들어야 잘 까먹지 않을 것이다, 등등

학생이 자신의 학번은 잘 안 까먹을 것이다. 라는 이유 때문에 많은 학교에서 ID에 입학 학번, 혹은 현 학년도 학번 정보를 넣는 것을 선호했습니다.
하지만 이 방법은 바로 아래 설명할 '진급'을 쉽게 하는데 방해 요소로 작용합니다.
또한 구글 계정의 특성상, 초반에 주로 사용하는 디바이스에 아이디를 등록하고 난 이후에는 아이디를 입력하여 로그인 할 일이 적어지게 되기 때문에 '기억하기 쉽게'라는 원칙에 너무 집착하기 보다는 '까먹었을 경우 빠르게 알려줄 수 있는'대책을 강구하는 것이 더 효과적일 수 있습니다.

진급을 고려해서 현 학년도 학번 정보는 업데이트하기 쉬운 곳에 위치해야 한다.

상당히 중요합니다.
꽤 많은 학교들이 이 이슈를 다루지 못해서 진급을 포기하고 새 학년도가 시작될 때 마다 모든 계정을 삭제하고 다시 만드는 어마무시한 작업을 하고 있습니다. (충격)

사용자정보 3개 중 가장 업데이트 하기 어렵고 번거로운 것이 기본이메일(ID)입니다. 진급 시 변경할 현 학번 정보는 기본이메일(ID)이 아닌 다른 곳에 위치하는 것이 좋습니다.

진급 후 기존 학번과 새 학번이 중복되는 혼란이 있어서는 안된다.

22년에 1학년 5반 21번 학생을 호출하려는데 21학년도 1학년 5반 21번 학생이 검색되면 매우 혼란스럽겠죠?

혼란을 방지하기 위한 방법은 크게 2가지가 있습니다.

  • 학번정보 앞에 연도를 붙인다
    2210521, 2110521과 같이 연도를 붙여서 서로 구분되게 하는 방법입니다.

  • 진급 시 모든 학생의 학번 정보를 반드시 업데이트한다.

학번정보 앞에 연도가 붙으면, 그만큼 학생을 호출할 때 번거롭습니다. 검색을 할 때에 앞 글자부터 검색 되어 연도부터 넣고 학번 정보를 넣어야 되기 때문입니다.

※ 우측 사진은 ID에서 211이라는 앞 부분의 정보부터 검색되고 있는 모습입니다.

따라서 가능한 경우, 학번 정보에 연도를 붙이기 보다는, 진급 프로세스를 간편하게 만든 후 진급 시 모든 학번 정보를 다 업데이트 해 주시는 것이 좋습니다.

학생들이 클래스룸에서 학번 순으로 정렬되어야 한다.

20명이 넘는 학생들을 클래스룸에 모아서 관리하게 되면 학생들이 학번 순으로 정렬될 필요가 있다고 느끼게 됩니다.
사용자정보 3개 중 정렬의 최 우선순위를 가지는 것은 성(last name)입니다.
따라서 특별한 이슈가 없다면 현 학번 정보는 성(last name)에 위치하는 것이 좋습니다.

우측의 사진은 클래스룸에서 학생들이 학번순으로 정렬된 모습입니다. 성에 학번 정보를 넣었기 때문에 정렬이 되었습니다.

추천하는 계정 생성 규칙

22년도 1학년 5반 21번 홍길동 학생을 생성한다면...

입학생 명단 상 138번째에 위치한 학생이라고 가정합니다.

기본이메일(ID): 입학년도+일련번호 (22138@도메인명)

학생의 입장에서 처음 지급받았을 때 당장 기억하기 좋은 방법은 아닙니다. 하지만 길이가 짧고, ID가 변경되지 않고 졸업 때 까지 유지되기 때문에 장기적으론 기억하기 좋은 방법이 될 수 있습니다. 또한 전입생이 오면 그 다음 일련번호를 부여하면 되기 때문에 전입생과 관련한 혼란이 매우 적습니다.

  • 변형: 22_138, 22.138, 220138 등 좀 더 연도와 학번이 구분되게 변형이 가능합니다.

(last name): 현 학년도 학번 (10521)

클래스룸에서 학번 순으로 정렬이 됩니다. 또한 진급시 업데이트가 용이합니다.

이름(first name): 성명 (홍길동)

성과 이름을 함께 넣습니다. 검색시 성과 이름을 함께 입력해야 검색이 됩니다.

진급 시에는?

모든 정보를 그대로 두고 성(last name)만 새 학년도 학번으로 일괄 업데이트합니다. 안 어렵습니다. 튜토리얼과 도우미 시트를 이용해 도와드립니다.

그 밖의 여러 계정 생성 규칙

기본이메일(ID): 입학년도+입학학년도 학번
성(last name): 현 학년도 학번
이름(first name): 성명
진급시: 성(last name)을 새 학년도 학번으로 업데이트

현재 가장 많은 학교에서 사용되고 있는 방식입니다. 추천하는 생성 규칙과 비교해 학생들이 아이디를 더 쉽게 기억할 수 있다는 장점이 있습니다.
학번 정보가 ID에도 있고 성에도 있기 때문에 약간 혼란스럽습니다.
진급 후에는 진급 전 학년도 학번 정보가 ID에 남아있어 추가적인 혼란이 있습니다.
전학 온 학생들은 ID를 전학년도+전학시 학번으로 보통 생성합니다.
전학자 진급 시 담당 교사가 통일되지 않은 ID로 약간의 혼란이 있을 수 있습니다.
요약: 추천방식보다 ID기억에 용이하나 혼란이 좀 있다.

기본이메일(ID): 영문 성명, 혹은 원하는 아이디
성(last name): 현 학년도 학번
이름(first name): 성명
진급시: 성(last name)을 새 학년도 학번으로 업데이트

추천하는 생성규칙과 비교해 학생들이 아이디를 매우 쉽게 기억할 수 있다는 장점이 있습니다.
관리자가 영문 성명 정보나 희망 아이디를 추가로 수집해야 하는데, 이 과정이 매우 번거롭고 입학 전 이루어지는 것이 사실상 불가능합니다.
다른 생성규칙을 사용한 후 아이디를 업데이트 하여 이 방식으로 가는 것은 가능합니다.
요약: 입학 전 미리 생성 불가능, 관리자 번거로움

기본이메일(ID): 입학년도+학번
성(last name):

이름(first name):
이름
진급시:
ID를 새 학년도+ 새 학번으로 업데이트

성에 학번 정보가 들어가지 않았기 때문에 클래스룸에서 학번 정렬이 되지 않습니다.
학생을 검색할 때 성, 혹은 이름으로 따로 검색이 되는 점은 유용합니다.
다만 학번을 검색할 때에는 앞에 연도를 함께 검색해야 합니다.
진급 시 ID를 업데이트 해야 합니다.
이는 관리자 입장에서 상당한 난이도를 요구하는 작업입니다.
다만 ID 업데이트 후에는 기존 ID가 별칭으로 들어가기 때문에 전 학년도 정보를 가지고도 학생을 호출할 수 있게 됩니다.
요약: 장점이 별로 없다

기본이메일(ID): 학번(10521@도메인명)
성(last name):

이름(first name):
이름
진급시:
ID를 새 학번으로 업데이트

성에 학번 정보가 들어가지 않았기 때문에 클래스룸에서 학번 정렬이 되지 않습니다.
학생을 검색할 때 성, 혹은 이름으로 따로 검색이 되는 점은 유용합니다. 학번 검색시 바로 학생이 호출되는 장점
있습니다.
진급 시 ID를 업데이트 해야 합니다.
위의 방식보다 복잡한데, 이유는 기존 ID가 삭제되지 않고 별칭으로 들어가 새로 진급하려는 학생의 ID 업데이트를 막기 때문입니다. (ID중복)
고학년부터 차례로 진급처리 후 별칭을 삭제하는 매우 번거롭고 힘든 작업을 관리자가 해야합니다.
요약: 관리자 죽습니다.

이 외에도 학번으로 별칭ID를 만드는 등 여러 다른 방법이 있습니다.