로그인을 비밀번호 없이 이메일 인증코드로..

기존 답변의 로그인 입구 추가 방식에 보완할 점을 적습니다. 실제 견적에서는 화면과 코드 발송 외에 기존 회원 연결과 실패 상황 처리도 범위에 넣는 것이 좋겠습니다. 같은 이메일을 쓰는 기존 회원이 있는지, 탈퇴·차단된 계정은 어떻게 처리할지, 메일이 늦거나 도착하지 않을 때 어떤 방법으로 다시 로그인할지부터 정해야 합니다.

인증코드는 추측하기 어려운 방식으로 생성하고 안전하게 보관하며, 해당 사용자와 연결해 한 번 사용한 뒤 재사용되지 않게 해야 합니다. 기존 답변의 만료·시도횟수 제한에 더해 발송 요청 자체의 횟수 제한도 필요합니다. 가입된 이메일인지 여부가 응답 문구로 노출되지 않도록 하는 것도 검토해 주세요. 이는 OWASP의 이메일 코드·토큰 보호 원칙을 이 로그인 방식에도 적용한 제안입니다.

코어 수정량이 적더라도 이 부분을 빠뜨리면 운영 중 문제가 생길 수 있어, 사용 중인 버전·기존 로그인 종류·메일 발송 환경을 확인한 뒤 작업량을 정하는 편이 좋겠습니다.

참고: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

어떤 홈페이지인지 몰라도
 그러게 로그인 하는데 1~5분걸리면 사람들이 올까요?

코어를 크게 뜯을 필요는 없습니다. 로그인 "입구"만 하나 더 붙이는 방식이 안전합니다. 그누보드5는 로그인할 때 비밀번호 해시(mb_password)만 비교하는데, 비밀번호 대신 "이메일로 보낸 6자리 코드가 맞으면 그누보드 로그인 세션을 세워 주는" 입구를 추가하면 됩니다.

뼈대는 이렇습니다.
1) 인증코드 테이블 1개 추가(email·code·만료시각·시도횟수) — 코어 테이블은 건드리지 않습니다.
2) 코드 발송: 이메일을 입력받아 6자리 코드를 생성·저장한 뒤 그누보드 메일 발송 기능을 그대로 사용합니다.
3) 코드 확인: 코드가 일치하고 만료 전이면, 기존 회원은 로그인 세션을 세우고(그누보드 로그인 처리를 재사용), 신규는 회원을 생성한 뒤 로그인시킵니다.
4) 비밀번호는 내부적으로 임의값으로 채워 둡니다(구조상 필드가 있어야 할 뿐, 사용자는 몰라도 됩니다).

주의할 점: 코드 만료(3~5분), 시도 횟수 제한, 재발송 쿨타임은 꼭 넣으세요(무차별 입력 방지). 기존 비밀번호 로그인·소셜 로그인과 병행도 가능합니다.

정리하면 코어 대수술이 아니라 "로그인 입구 1개 + 테이블 1개 추가" 수준이라, 뜯어고칠 양은 많지 않습니다.