안녕하세요! 그로스로그 입니다!😊 🌱
늘 쓰던 서비스의 로그인 방식이 궁금해 직접 만들어본 기록, 프로젝트 구조를 정하기 전에 먼저 공부한 기록, 그리고 만든 것을 어떻게 살아남게 할지 고민한 기록. 2기 11회차입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
01
🔑 비밀번호 없이 회원가입, 로그인 구현
오연수 님
벨로그를 쓰다가 로그인 방식이 독특하다는 걸 발견합니다. 이메일만 넣으면 링크가 오고, 그 링크를 누르면 로그인이 되는 방식이요. 비밀번호를 한 번도 묻지 않습니다.
"그러면 DB에 비밀번호를 저장하지 않고도 인증이 되겠구나" 싶어 직접 만들어봅니다. Kotlin + Spring Boot로요.
메일 발송 설정부터 인증 코드 생성, 회원가입 링크와 로그인 링크의 분기, JWT 발급까지. 그리고 마지막에 이 방식의 장단점을 스스로 정리합니다.
매일 쓰는 서비스에서 "어? 이거 왜 이렇게 되어 있지"를 발견하고, 그걸 만들어본 글입니다. 배움의 출발점으로 아주 좋은 형태예요.
조금 더 들어가 보면
비밀번호 없는 로그인을 패스워드리스(passwordless) 또는 매직 링크(magic link)라고 부릅니다.
원리는 생각보다 단순합니다. 기존 로그인은 "당신만 아는 것(비밀번호)"으로 본인을 확인합니다. 매직 링크는 "당신만 받을 수 있는 것(이메일)"으로 확인해요. 확인 수단이 바뀐 겁니다.
흐름은 이렇습니다.
1. 사용자가 이메일을 입력합니다.
2. 서버가 한 번만 쓸 수 있는 코드를 만들어 저장합니다.
3. 그 코드가 담긴 링크를 이메일로 보냅니다.
4. 사용자가 링크를 누르면 서버가 코드를 확인하고 로그인 처리합니다.
5. 쓴 코드는 즉시 삭제합니다.
글이 벨로그에서 관찰한 디테일이 좋습니다. 가입된 회원이면 로그인 링크, 아니면 회원가입 링크가 온다는 것. 사용자 입장에서는 로그인과 회원가입을 구분할 필요가 없습니다. 이메일만 넣으면 서버가 알아서 판단해요. 입력 폼이 하나로 줄어드는 설계입니다.
📝 원문에서는 이렇게 구현합니다
이메일 발송 설정부터 시작합니다.
spring:
mail:
host: smtp.gmail.com
port: 587
username: ${emailUsername}
password: ${emailPassword}
properties:
mail:
smtp:
auth: true
starttls:
enable: true
required: true
connectiontimeout: 5000
timeout: 5000
writetimeout: 5000
auth-code-expiration-millis: 86400000 # 24 hour
짚어둘 만한 부분이 두 가지 있습니다.
먼저 password에 들어가는 값입니다. 글에 정확히 적혀 있어요. 구글 계정 비밀번호가 아니라 "앱 비밀번호" 16자리를 넣어야 합니다. 구글은 2단계 인증을 쓰는 계정에서 외부 앱이 직접 로그인하는 걸 막고, 대신 앱 전용 비밀번호를 따로 발급해줍니다. 이걸 모르면 인증 오류에서 한참 막혀요.
두 번째는 auth-code-expiration-millis, 24시간짜리 유효기간입니다. 이게 왜 필요할까요. 메일함은 오래 남기 때문입니다. 한 달 전 메일의 링크가 아직도 로그인된다면 그건 사실상 만료되지 않는 열쇠예요. 시간을 걸어두는 게 안전장치입니다.
핵심 로직은 이 메서드에 담겨 있습니다.
override fun sendVerificationEmail(email: String): Boolean {
// 인증 코드 생성
val code = EmailUtil.generateCode(emailConstant.CODE_LENGTH)
val user = userRepository.getByEmail(email)
if (user != null) {
// 이미 가입된 회원이면 로그인 링크가 포함된 이메일 발송
sendLoginEmail(email, code)
} else {
// 가입된 회원이 아니면 회원가입 링크가 포함된 이메일 발송
sendRegistrationEmail(email, code)
}
// 영속화
val newEntity = EmailVerificationEntity().apply {
this.email = email
this.code = code
this.expiredAt = LocalDateTime.now()
.plus(Duration.ofMillis(emailProperties.authCodeExpirationMillis))
}
emailVerificationJpaRepository.save(newEntity)
return true
}
가입 여부로 갈라지는 부분이 명확합니다. 그리고 어느 쪽이든 함수는 true를 돌려줍니다.
이건 의도된 설계예요. 만약 "가입된 회원이 아닙니다"를 화면에 알려주면, 누구나 이메일을 넣어보며 가입 여부를 알아낼 수 있게 됩니다. 회원 목록이 새어 나가는 셈이죠. 그래서 화면에는 늘 "메일을 보냈습니다"만 띄우고, 실제 내용만 다르게 보냅니다. 보안에서 흔히 쓰는 방식입니다.
메일 전송은 두 방식을 다 다룹니다.
fun sendEmail(email: String, title: String, text: String) {
try {
val message: MimeMessage = javaMailSender.createMimeMessage()
val helper = MimeMessageHelper(message, true)
helper.setTo(email)
helper.setSubject(title)
helper.setText(text, true) // true는 html 형식을 의미
javaMailSender.send(message)
} catch (e: MessagingException) {
e.printStackTrace()
}
}
SimpleMailMessage는 순수 텍스트만 보낼 수 있고, MimeMessage를 쓰면 HTML 메일이 가능합니다. 매직 링크는 "여기를 눌러 로그인" 같은 버튼이 필요하니 후자가 맞죠.
🧭 그리고 장단점을 스스로 정리한 것
이 글에서 가장 좋았던 건 마지막 정리입니다. 만들어보고 나서 이 방식이 좋기만 한 게 아니라는 걸 짚어요.
장점으로는 비밀번호를 저장하지 않으니 유출돼도 인증 정보가 새지 않는다는 점, 그리고 사용자가 비밀번호를 기억·재설정·변경할 필요가 없다는 점을 듭니다.
단점은 더 날카롭습니다.
· 이메일 계정 의존성 — 이메일이 털리면 이 서비스 계정도 함께 털립니다. 보안의 무게가 전부 이메일 한 곳에 실립니다.
· 기억력 문제 — "내가 어느 이메일로 가입했더라?" 여러 개를 쓰는 사람에겐 실제 불편입니다.
· 번거로움 — 로그인할 때마다 메일함을 열어야 합니다.
그리고 마지막 단점에 해결 방향까지 붙여뒀어요. "액세스·리프레시 토큰의 기한을 적절히 설정해 사용성을 개선할 수 있다"고요.
정확한 답입니다. 매직 링크는 로그인 자체가 무거우니 자주 안 하게 만드는 것이 해법이에요. 토큰 유효기간을 넉넉히 잡아 한 번 로그인하면 오래 유지되게 하면, 메일함을 여는 일이 몇 달에 한 번으로 줄어듭니다. 실제 서비스들이 쓰는 방식입니다.
큐레이터 노트
"왜 이렇게 되어 있지?"에서 시작해 직접 만들어봤기 때문에 뽑았습니다.
우리는 매일 수많은 서비스를 씁니다. 그런데 그 안의 설계를 눈여겨보는 일은 드물어요. 이 글은 벨로그의 로그인 모달 하나에서 "비밀번호를 저장하지 않는 구조가 가능하겠구나"를 읽어냈습니다. 관찰이 곧 학습 주제가 된 경우예요.
그리고 만들어보고 나서 단점까지 정리한 것이 이 글을 완성시킵니다. 새 기술을 배우면 대개 좋은 점만 보이거든요. 이 글은 "이메일이 털리면 어떡하지", "사용자가 귀찮아하지 않을까"까지 갔습니다. 쓸지 말지를 판단할 수 있는 지식이 된 겁니다.
"부족한 점이 많다, 아직 손봐야 할 부분이 많다"고 겸손하게 적으셨지만, 예외 처리가 덜 된 습작이라도 끝까지 동작하게 만들어본 경험은 그대로 남습니다. 깃허브 저장소까지 공개해두신 것도 좋았어요.
02
🏛️ 클린 아키텍처를 적용한 스프링 기반 애플리케이션
이태형 님
동아리 운영 앱을 만들기 전에 프로젝트 구조를 어떻게 잡을지 먼저 고민한 기록입니다.
클린 아키텍처의 기본 원칙(외부 → 내부로만 호출), 인터페이스로 의존을 뒤집는 방법, 그리고 JPA를 쓸 때의 구조를 정리했어요.
그리고 스스로 던진 질문이 좋습니다. "서비스 로직과 비즈니스 로직은 왜 나눠야 하지?" 은행 송금 기능을 예로 들어 직접 갈라봅니다.
시작 문장이 이 글의 성격을 말해줍니다. "만들기 전에 구조를 어떻게 잡을지 생각했어야 했다." 코드부터 쓰지 않은 겁니다.
조금 더 들어가 보면
클린 아키텍처의 규칙은 한 줄로 요약됩니다. 바깥에서 안으로만 호출할 수 있고, 안에서 바깥을 참조하면 안 된다.
가장 안쪽에 비즈니스 로직이 있고, 바깥쪽에 컨트롤러, 리포지토리, 보안, 외부 API 호출 같은 것들이 놓입니다.
그런데 바로 의문이 생깁니다. 안쪽 로직도 DB 데이터가 필요한데, 바깥을 못 부르면 어떻게 하지?
글이 이 답을 정확히 짚습니다. 안쪽에는 인터페이스만 두고, 실제 구현은 바깥에 두는 것.
예를 들어 안쪽에 UserRepository라는 인터페이스가 있고 "ID로 사용자를 찾아오라"는 선언만 있습니다. 실제로 JPA를 써서 DB를 조회하는 코드는 바깥에 있고요. 안쪽은 그게 MySQL인지 몽고DB인지 파일인지 모릅니다.
이게 왜 좋을까요. 글의 설명이 명료합니다. "외부가 어떻게 변하든 동일한 응답값을 주면 내부는 변경할 이유가 없어진다."
DB를 바꿔도, 외부 API를 다른 걸로 갈아타도, 라이브러리를 업그레이드해도 핵심 로직은 그대로입니다. 바깥쪽 구현체 하나만 새로 쓰면 되죠.
🧭 SRP와 OCP가 여기서 만납니다
글이 관심사의 분리를 SOLID 원칙과 연결하는 부분이 좋습니다.
한 클래스가 여러 책임을 지고 있으면(SRP 위반), 라이브러리가 바뀔 때 그 클래스를 고쳐야 하고, 그 클래스를 쓰는 다른 클래스들까지 줄줄이 영향을 받습니다. 기존 코드를 건드리지 않고 확장할 수 없으니 OCP도 함께 무너져요.
반대로 책임이 잘 나뉘어 있으면 라이브러리를 담당하는 클래스 하나만 바뀝니다. 나머지는 그대로예요.
두 원칙이 따로 있는 게 아니라 이어져 있다는 걸 짚은 셈입니다. 책임이 잘 나뉘어야(SRP) 변경에 닫혀 있을 수 있습니다(OCP).
🏦 은행 송금으로 갈라본 것
이 글에서 가장 값진 부분입니다. 저자는 "서비스 로직과 비즈니스 로직은 뭐가 다르지?"라는 애매한 질문을 예제로 갈라봅니다.
송금 절차를 이렇게 나눕니다.
1. 계좌 잔액 확인
2. 잔액이 있으면 송금, 없으면 불가를 표시
3. 송금 수수료 계산
4. 사용자의 잔액 감소
5. 잔액을 DB에 저장
그리고 1·3·4를 비즈니스 로직, 2·5를 서비스 로직으로 판단합니다.
기준이 명확합니다. "어떤 은행 앱을 써도 반드시 있는 것"이 비즈니스 로직이에요. 잔액을 확인하고, 수수료를 계산하고, 잔액을 줄이는 건 은행이라면 다 합니다. 여기엔 변경이 거의 없어요.
반면 잔액이 부족할 때 무엇을 하는가는 서비스마다 다릅니다. 어떤 앱은 알림을 보내고, 카카오페이는 자동 충전을 합니다. 같은 상황에 다르게 대응하죠. 그래서 서비스 로직입니다.
5번(DB 저장)에 대한 판단이 특히 좋았습니다. 얼핏 보면 핵심 같지만, 저자는 이렇게 정리해요. "저장하는 행위는 도메인 규칙보다는 애플리케이션 레이어에서 처리하고 DB와 상호작용하는 역할"이라고요.
정확합니다. "잔액이 줄어든다"는 은행의 규칙이지만, "그 결과를 MySQL에 넣는다"는 기술적 선택이에요. 규칙과 기술을 갈라본 겁니다.
"조금은 애매하지만 이렇게 이해하기로 했다"고 적어두신 것도 좋았습니다. 실제로 이 경계는 사람마다 조금씩 다르게 그어요. 정답을 외운 게 아니라 자기 기준을 세운 상태라는 게 드러납니다.
🧭 그리고 테스트로 이어지는 이유
글의 마지막이 좋습니다. 이 구조를 지향하는 이유로 테스트를 듭니다.
비즈니스 로직이 외부 라이브러리에 의존하지 않으면, DB도 서버도 없이 순수한 함수처럼 테스트할 수 있습니다. 8회차에서 이 저자가 정리했던 @Mock과 @MockBean 이야기와 정확히 이어지는 지점이에요.
목(mock)을 잘 쓰는 것도 방법이지만, 애초에 목이 필요 없는 구조로 만드는 게 더 낫습니다. 아키텍처와 테스트가 별개의 주제가 아니라는 걸 보여줍니다.
큐레이터 노트
만들기 전에 멈춰서 공부한 기록이라 뽑았습니다.
프로젝트를 시작할 때 대부분은 바로 코드를 씁니다. 구조는 나중에 생각하죠. 그런데 나중이 되면 이미 고치기 어려운 상태가 되어 있어요. "만들기 전에 구조를 생각했어야 했다"로 시작하는 이 글은 그 순서를 지킨 기록입니다.
질문을 스스로 만들어낸 점도 좋았습니다. 클린 아키텍처 설명 자료는 많지만, "서비스 로직과 비즈니스 로직은 왜 나누지?"까지 묻는 자료는 드물어요. 읽다가 걸린 지점을 그냥 넘기지 않고 예제로 풀어본 것이 이 글의 핵심입니다.
은행 송금 예제도 좋은 선택이었습니다. 누구나 아는 절차라 판단 기준이 뚜렷하게 드러나거든요. 추상적인 개념을 익숙한 사례로 옮겨 검증하는 방식은 어디에나 쓸 수 있는 학습법입니다.
03
💼 아이디어와 BM 그리고 마케팅
이민경 님
8회차에서 베타 서비스를 출시했던 그분의 두 달 뒤 기록입니다.
이번엔 개발이 아니라 아이디어, 비즈니스 모델, 마케팅, 그리고 팀에 대한 고민을 적었어요.
"시장에서 가장 중요한 건 뭘까? 획기적인 아이디어? 혁신적인 기술? 아닌 것 같다." 만들고 나서야 보이는 질문들입니다.
기술 글이 아닙니다. 그런데 무언가를 만들어본 사람이라면 문장마다 짚이는 데가 있을 거예요.
조금 더 들어가 보면
글의 첫 문단이 아프면서 웃깁니다. "AWS 월말 예상 비용이 두 자릿수로 올라버렸다. 지금은 사용자도 없는데..."
서비스를 배포해둔 사람이 겪는 현실입니다. 사용자는 없어도 서버는 돌아가고, 요금은 나옵니다. 만드는 것과 유지하는 것은 다른 일이라는 걸 청구서가 알려줘요.
(참고로 글 마지막에 짚어두신 IPv4 요금 짐작이 맞습니다. 2024년 2월부터 AWS는 사용 중인 공인 IPv4 주소에 시간당 요금을 매기기 시작했어요. EC2 하나만 켜둬도 매달 4달러 가까이 나갑니다. 프리티어 계정이라도 이 항목은 별도예요. 안 쓰는 탄력적 IP는 반드시 해제하는 게 좋습니다.)
🧭 PMF라는 벽
본론은 여기서 시작됩니다. PMF(Product Market Fit)요.
글의 문장이 정확합니다. "늘 시장이, 고객이 원하는 게 먼저라고 배웠는데, 이제야 그 말이 무슨 뜻인지 깨닫고 있는 중이다."
이 문장이 좋은 이유는 "배웠는데"와 "이제야" 사이의 간격을 드러내기 때문입니다. 학교에서 배울 때는 당연한 말이었을 거예요. 그런데 직접 3개월을 들여 만들고 내놓은 다음에야 몸으로 알게 되는 종류의 지식이 있습니다.
그리고 스스로 답을 냅니다. "그건 그냥 행동력인 것 같다."
"고객 반응이 어느 정도 와야 시작할 수 있나"라는 질문에 대한 답이에요. 10명이 와도 일단 시작해서 발전시키고, 1000명이 오면 빨리 만들어야 하는 것. 기준선을 기다리는 게 아니라 움직이면서 판단하는 쪽입니다.
💰 비즈니스 모델과 수익 모델을 나눈 것
이 글에서 가장 실용적인 정리가 여기 나옵니다.
정확한 구분입니다. 비즈니스 모델은 "누구에게 어떤 가치를 주는가"이고, 수익 모델은 "그 가치를 어떻게 돈으로 바꾸는가"예요.
둘은 자주 어긋납니다. 사용자에게 분명한 가치를 주는데도 아무도 돈을 안 내는 서비스가 있고, 반대로 가치가 애매한데 결제가 잘 되는 서비스도 있어요. 그래서 글이 던진 세 질문이 핵심입니다.
· 사용자가 많다고 해서 돈을 벌 수 있는가?
· 사용자에게 어떤 가치를 제공할 수 있을까?
· 그 가치는 사용자가 기꺼이 돈을 내고 얻고 싶은 것일까?
세 번째가 가장 어렵습니다. "있으면 좋은 것"과 "돈을 내서라도 갖고 싶은 것" 사이에는 큰 간격이 있거든요.
그리고 이어지는 자기 관찰이 솔직합니다. "결국 이것도 행동력에 달리지 않았나 생각하지만, 그 전에 내가 완벽하게 설계해놓지 않으면 무슨 의미일까..."
빨리 움직이고 싶은 마음과 제대로 준비하고 싶은 마음 사이의 갈등이요. 무언가를 시작해본 사람이라면 이 사이에서 오래 서성여봤을 겁니다.
🤝 그리고 결국 팀
마지막에 도달한 결론이 팀입니다. "이렇게 나온 것을 나 혼자 개발까지 할 수 있다면 상관없겠지만 나는 스티브 잡스가 아니다. 스티브 잡스도 워즈니악과 함께 했다."
좋은 비유입니다. 그리고 이어지는 문장이 실제 상황을 정확히 그려요. "시장 검증까지 다 마쳤는데, 만들 수 없으면 어떡해...?"
기획과 구현 중 하나만 있으면 반쪽입니다. 아이디어만 있으면 만들 사람을 찾아야 하고, 만들 줄만 알면 무엇을 만들지 정해줄 사람이 필요해요. 혼자 다 하려다 아무것도 못 하는 경우가 그래서 많습니다.
그리고 "우리 팀원분들은 이걸 안 보겠지만 일단 이 여정을 함께 해줘서 고맙다"는 문장. 아무도 안 볼 거라 생각하고 쓴 감사 인사인데, 이렇게 큐레이션되어 읽히게 됐네요. 😊
큐레이터 노트
개발자가 개발 바깥을 고민한 기록이라 뽑았습니다.
성장일지에 이런 글이 올라오는 게 반갑습니다. 코드를 잘 짜는 것과 그 코드로 만든 걸 살아남게 하는 것은 다른 일이에요. 둘 다 겪어본 사람의 시야는 넓어집니다.
"사실 개발 관련해서 적을 게 떠오르지 않는다"로 시작한 글이지만, 결과적으로 개발자에게 필요한 이야기가 됐습니다. PMF, 비즈니스 모델과 수익 모델의 구분, 팀의 필요. 언젠가 자기 서비스를 만들고 싶은 사람이라면 반드시 마주할 질문들이니까요.
그리고 8회차의 그 글과 이어서 읽으면 더 좋습니다. 12월에 "기운이 빠져서 일기처럼 적어둔다"고 했던 사람이, 2월에는 다음 단계의 고민을 하고 있어요. 지쳐 있던 자리에서 한 걸음 나아간 게 기록으로 남았습니다.
"곧 개강이기도 하고 개발 공부를 다시 시작해야 한다"는 마무리도 좋았습니다. 돌고 돌아 다시 공부로 오는 것 — 그게 계속하는 사람의 리듬이죠.
💡 세 편을 겹쳐 읽으며
세 글이 서 있는 자리가 다릅니다. 하나는 구현, 하나는 설계, 하나는 사업이요.
그런데 셋을 나란히 놓으면 하나의 서비스가 살아가는 순서가 됩니다.
무엇을 만들지 정하고(이민경) → 어떻게 구조를 잡을지 정하고(이태형) → 실제로 만든다(오연수). 그리고 다시 처음으로 돌아가죠. 만들고 나면 "이게 팔릴까"라는 질문이 다시 옵니다.
더 흥미로운 건 세 글 모두 "무엇을 안쪽에 두고 무엇을 바깥에 둘 것인가"를 다룬다는 점입니다.
이태형 님의 글은 명시적으로 그렇습니다. 변하지 않는 핵심을 안쪽에, 변하는 기술을 바깥에요. 오연수 님의 글도 같습니다. 인증이라는 핵심은 그대로 두고, 확인 수단만 비밀번호에서 이메일로 바꿨어요. 이민경 님의 글은 사업의 언어로 같은 말을 합니다. 가치 제공이 안쪽이고, 수익 모델은 그 바깥이라고요.
변하지 않는 것과 변하는 것을 갈라두면, 변할 때 흔들리는 범위가 줄어듭니다. 코드에서도, 서비스에서도 그렇습니다.
이번 회차에서 가져갈 것
1. 매일 쓰는 서비스를 관찰하기. 벨로그의 로그인 모달 하나가 한 편의 구현 기록이 됐습니다. "어? 이거 왜 이렇게 되어 있지"가 가장 좋은 학습 주제예요.
2. 만들어봤으면 단점까지 적기. 새 기술은 장점부터 보입니다. "이메일이 털리면", "사용자가 귀찮아하지 않을까"까지 가야 쓸지 말지 판단할 수 있는 지식이 됩니다.
3. 코드보다 구조를 먼저. 나중에 바꾸기 가장 어려운 게 구조입니다. "이건 변하지 않을 핵심인가, 언젠가 바뀔 기술인가"를 한 번 가르고 시작하면 나중이 훨씬 편해요.
4. 개념이 애매하면 익숙한 예로 갈라보기. "비즈니스 로직과 서비스 로직"처럼 경계가 흐린 개념은 은행 송금 같은 아는 절차에 대입해보세요. 자기 기준이 생깁니다.
5. 클라우드 요금은 켜둔 만큼 나갑니다. 사용자가 없어도 인스턴스와 IPv4 주소는 과금됩니다. 예산 알림을 걸어두고, 안 쓰는 자원은 지우세요. 청구서로 배우면 비쌉니다.
좋은 글 남겨주신 오연수 님, 이태형 님, 이민경 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.