simzard

[회고] 중견기업 인턴, 대기업 인턴에서 정규직 전환까지 - 백엔드 개발자 취준 기간의 기록

simzard — Sun, 26 Jul 2026 16:07:08 +0900

정말 열심히 살았던 2025년, 2026년 상반기다.

이 글은 2024년(대학교 3학년)부터 시작된 취준 준비와 본격적으로 취준을 했던 과정을 담은 글이다.

요약보다는 흐름을 한 번 쭉 정리해보고 싶어서, 두서없이 그냥 그때의 느낌 그대로 적는다.

취준 팁이라기보다는 그냥 네이버 블로그식 사진 정리에 가깝다.

큰 흐름은 3학년 → 4학년 1학기 SW캡스톤디자인 → 4학년 2학기 안랩 인턴 → 졸업 이후 넷마블 인턴 순이다.

타임라인

서류 준비와 인턴 지원은 3학년 여름방학부터 시작했다.

취준 전에 3가지를 목표로 삼았다.

4학년 때 취준에만 집중할 수 있도록 학점을 미리 들어두고 평점 3.8 이상 유지 (졸업 학점이 140학점이라 부담이 컸다)
프로젝트 하나를 꾸준히 이어가며 의미 있는 성과나 실제 사용자 수를 만들어보기 (가능하면 수익까지)
인턴 경험 쌓기

1번 덕분에 3학년 2학기와 4학년 1·2학기에는 각각 12학점씩만 들으면서 사이드 프로젝트, SW캡스톤디자인, 인턴, 취업 준비에 시간을 쏟을 수 있었고, 적은 수강 학점 덕분에 학점도 잘 유지되어 장학금도 받을 수 있었다.

2번 덕분에 포트폴리오를 스토리와 함께 더 풍부하게 채울 수 있었고,

3번 덕분에 신입 채용에서 가장 중요한 직무 경험을 갖출 수 있었다.

(2024년) 정병의 3학년

지금 생각해보면 어떻게 했지?

2학년 2학기와 3학년 1학기 때는 각각 24학점씩 들으며, 나중에 취업 준비 시기가 오면 오직 취준에만 집중할 수 있도록 미리 대비했다.

물론 그 대가로 학점은 말아먹었다.

3학년 1학기부터는 정말 도서관에 살았다고 해도 무방할 정도였다. 본가도 학교 앞이라 방학 때도 빠짐없이 개근했다.

2024년에는 소프트웨어학과 학술소학회 회장도 맡았는데, 돌이켜보면 이게 나를 더 빨리 지치게 만든 이유 중 하나였던 것 같다.

그래도 소학회 회장하면서 새내기 시절 코로나 때문에 못 갔던 새내기 배움터도 가봤다.

다음년도 동아리방도 배정 받았다.

(2024년 겨울 방학) SW융합교육원 방학 코테 강의

SW융합교육원 2024-동계 코딩집중교육(코딩테스트 집중 훈련)

3학년에서 4학년으로 올라가는 겨울방학만큼은 좀 더 의미 있게 보내고 싶었다.

특히 코딩테스트를 제대로 준비해본 적이 없어서 이 부분에 대한 대비가 필요하다고 느꼈다.

그리고 방학 때마다 기상 시각이 규칙적이지 않은 것도 고민이었는데,

코딩테스트 준비 프로그램 덕분에 일찍 일어나는 습관도 만들고, 덕분에 알찬 방학을 보낼 수 있었다.

(물론 결과론적으로 코딩테스트 없이 취업을 하긴했다.)

(2025년 1학기) 4학년, 휴학 없이 달리다

휴학 안하길 잘했다!

이 시점에 고민이 정말 많았다. 휴학을 할 것인가, 그냥 이대로 달릴 것인가.

많이 지쳐있던 상태라 쉬고 싶은 마음도 컸지만, 막상 쉰다고 해도 교환학생이나 부트캠프, 워홀처럼 구체적인 계획이 없다면 그 시간이 그냥 의미 없이 흘러가 버릴 것 같았다.

만약 휴학하지 않고 계속 달린다면 SW캡스톤디자인을 수강해야 했는데, 마침 현지 누나가 같이 하자고 제안이 왔다.

솔직히 SW캡스톤디자인은 졸업 작품이기도 하고 포트폴리오에 무조건 들어갈 프로젝트였기 때문에, 여기에 100%를 갈아넣고 싶어서 오히려 고민이 더 깊어졌다.

그래도 함께할 사람이 있을 때 해야 한다고 생각했고, 결국 달리기로 결정했다.

뒤돌아보면 이때 멈추지 않고 그냥 달렸던 게 정말 좋은 선택이었다.

(2025년 1학기) 마지막 코딩 트레이너 활동

3학기 동안 진행한 SW융합교육원 코딩 트레이너

2024년 1학기부터 이어오던 코딩 트레이너 활동도 2025년 1학기를 끝으로 마무리하게 되었다(아래에 나오는 인턴 이슈로).

SW캡스톤디자인 기간에 담당했던 실습반은 제대로 챙겨주지 못한 것 같아서 그 부분은 아쉬움으로 남는다.

학교를 다니는 동안 따로 알바는 하지 않았는데, 나름의 대안이 되어주었고 뿌듯함도 느낄 수 있었던 활동이었다.

자세한 후기는 아래 블로그 글에도 남겨두었다.

아주대학교 SW중심대학 코딩 트레이너 후기 (2024-1학기 ~ 2025-1학기)

2024-1학기부터 2025-1학기까지, 총 3학기 동안 아주대학교 객체지향프로그래밍 및 실습(Java)강의에서 코딩 트레이너로 활동했습니다.앞으로 이 활동을 해보고 싶은 후배들이나, 관심 있는 분들에

simzard.tistory.com

(2025년 1학기) SW캡스톤디자인

오전 4시에 팀원 모두가 답장을 보는… / 내가 봐도 초췌하다…

우리 팀은 소상공인 사장님을 위한 알바생 관리 솔루션을 주제로 프로젝트를 진행했다.

근태, 근로계약서, 정산, 업무 인수인계 등 여러 재미있는 기능들이 많아서 개발하는 입장에서도 즐거웠다.

특히 팀원들이 다들 알바 경험이 많아서, 다 같이 즐기면서 개발할 수 있었다.

그리고 Ajou Softcon 대회에도 참가했는데, 사실 최우수상(1위)은 일찌감치 포기했다.

이미 1등이 정해져 있다고 느낄만큼 압도적인걸 들고온 팀이 있어서… (윈도우 서버 취약점 분석으로 65,000$ 버그바운티를 받은 팀… 환율 올랐으니까 더 받았겠네)

그래도 우수상은 받을 줄 알았는데 살짝 아쉬움은 있었다.

중간 자랑 타임

2024-2학기(3학년), 2025-1학기(4학년) 학업우수자 선정

https://sw.ajou.ac.kr/sw/introduction/honor03.do

2학년 2학기, 3학년 1학기에 24학점씩 들으며 학점을 망치긴했지만,

그때 학점을 미리 채워둔 덕분에 3학년 2학기와 4학년 1학기에는 12학점씩만 들으면서 학점 4.5를 받을 수 있었다.

그 결과 학업우수자로 선정되어 단과대 홈페이지에 이름이 걸렸다.

(2025년 여름방학) 저 또 달려요? - 안랩 인턴 합격

당시 상황이 뚜렷하게 기억이 난다. 1차 합격 문자는 명건이랑 같이 교직원 식당에서 밥 먹다가 받았고, / 최종 합격 문자는 배드민턴 과목 기말고사 끝난 뒤 체육관에서 나오고 받았다.

SW캡스톤디자인을 하면서 가장 힘들었던 점은, 동시에 4학년 2학기 인턴도 지원해야 했다는 것이다.

특히 안랩은 학점연계도 가능했고, 마침 과 후배(나현이)가 상반기 인턴을 하고 있었는데 추천해서 꼭 넣어야겠다고 생각했다.

다만 인턴 시작일이, 종강 바로 다음주부터라 전형 과정이 너무 빡셌다.

서울로 이사하면서 학교랑 거리도 멀어진 데다, 6/10 Ajou Softcon 대회, 6/12 안랩 인턴 면접이 연달아 잡혀있었고, 중간에 가족 일도 있어서 이때가 진짜 힘들었다.

그래도 나름대로 잘 준비한 덕분에 면접에 합격할 수 있었고, 본의 아니게 1학기가 끝나자마자 곧바로 또 한 번 달리게 되었다.

(2025년 여름방학 ~ 2학기) 안랩 체험형 인턴 6개월(막학기)

판교역에서 가까워서 좋았다.

인턴이 금턴인 만큼, 소중한 기회였기 때문에 주도적으로 팀에 기여하기 위해 노력했다.

태도 부분에 대해서는 긍정적인 피드백을 많이 받아서, 이 자세를 계속 가져가면 되겠다는 생각이 들었다.

안랩 체험형 인턴을 하면서는 여러 컨퍼런스랑 행사도 다니면서 나름 회사원 코스프레를 하려고했다.

여러 컨퍼런스와 행사 참여

카카오 컨퍼런스(운좋게 추첨에서 당첨이 되었다) / 안랩 인턴십 당시 사내 개발자 컨퍼런스

잡코리아 퇴근 후 밋업 / 밋업 이후 네트워킹 시간에 같은 테이블에서 인턴이라고 말씀드리니까 다들 많은 조언을 해주셨다.

다양한 회사 이벤트

복날에는 치킨 기프티콘을 받았다. / 여름에 하는 아이스크림데이 (층마다 아이스크림 냉장고가 비치되었다)

회사 생활은 매일매일이 단조로울줄 알았는데, 나름 가끔씩 이벤트도 있어서 재밌었다.

알고보니까 하반기에 행사가 많아서 상반기 인턴보다 하반기 인턴이 좀 더 즐길게 많다고 하셨다.

러닝 열풍 동참

온러닝 클라우드몬스터 보이드

이사한 동네가 흑석동인데, 한강이랑 가까워서 러닝하기 너무 좋았다.

퇴근하고나서도 노들섬, 여의도, 반포한강공원 등 다양한 루트로 많이 뛰었다.

SW중심대학 연합 SW페스티벌 참여

형모 생각이 나서 전화했는데, 진짜 우연히 형모도 행사장인 도서관을 나가는 중이었다.

SW캡스톤디자인 수상팀들 대상으로 신청을 받았다.

경희대학교 국제캠퍼스(영통)에서 행사를 했는데, 같은 팀에서 직장인 2명이 반차를 쓰고 참석하게 되었다.

하지만 아쉽게도 무관에 그쳤다.

오랜만에 캠퍼스 분위기를 느끼고 싶어서 그냥 반차 쓰고간건데, 쓰지말걸…

그래도 우연히 군대 동기 형모도 만나고 재밌었다.

팀 워크샵

대하가 철이었는데, 너무 맛있었다

인턴이지만 팀에서 많이 챙겨주셨고, 워크샵도 같이 다녀왔다.

안랩 인턴 합격할때 만해도 내가 워크샵에서 노래 부를 줄은 상상도 못했다.

황금 연휴 때 돈 받고 쉬기 - 미국 동부 여행(워싱턴DC, 나이아가라, 뉴욕 - 10박 12일)

사실 2025년 2학기에 꼭 인턴을 하고 있어야겠다고 생각했던 이유 중 하나는 추석 황금연휴 때문이었다.

아직도 기억나는 게, 고등학교 시절 친구들끼리 "2025년 이맘때는 무조건 일하고 있어야 한다"고 이야기했던 기억이 있다.

이 기간을 백수로 보내고 싶지는 않았다. 돈을 받으면서 쉬고 싶었고, 안랩 인턴 덕분에 그 목표를 이룰 수 있었다.

진짜 다시봐도 엄청난 연휴였다.

워싱턴DC 내셔널 갤러리 오브 아트 - 모네, 양산을 든 여인 / 워싱턴DC 국회의사당 앞 / 나이아가라 폭포뷰 호텔

메디슨 스퀘어 가든 - 뉴욕 닉스 NBA 프리시즌 경기(이 시즌에 우승할 줄은 몰랐다) / 뉴욕 양키 스타디움 - MLB 포스트시즌 / 뉴욕 센트럴파크

연휴 기간은 통째로 미국 여행에 썼는데, 정말 알차게 활용했다.

연휴가 끝나고 월요일 새벽 비행기로 인천에 도착해서, 반반차를 쓰고 바로 출근했다(면접 잡힐까봐 연차를 최대한 아꼈는데, 결국엔 안랩 인턴 기간 동안 반차나 반반차 쓰고 면접 볼 일은 없었다).

시차 적응이 안 돼서 잠와 죽는 줄 알았다.

이때 제대로 해외여행을 다녀온 덕분인지, 지금까지도 딱히 해외여행 생각이 나지 않는다.

콘서트(잔나비, 오아시스, 한로로)

잔나비 앵콜 콘서트 ‘모든소년소녀들 2125’.

오아시스 콘서트. 반반차 쓰고 고양까지 갔다. GTX는 혁명이다.

한로로 자몽살구클럽 콘서트. 한로로 붐은 왔다.

2023년 군대를 다녀온 뒤에 코로나가 끝나고 복학하면서 콘서트도 다니기로 마음먹었는데,

하지만 막상 수원에서 가기엔 공연장도 멀고 티켓값도 부담스러워서 그냥 그렇게 흘러갔다.

그러다 서울로 이사 온 뒤, 마침 가고 싶었던 콘서트들의 티켓팅이 연달아 열리면서 보고 싶었던 공연을 하나씩 다 다녀올 수 있었다.

특히 한로로 콘서트에서는, 3학년 때 매일 도서관을 다니며 밤늦게 집으로 돌아오던 길에 듣던 ‘거울’을 라이브로 듣는데, 그때 생각이 많이 났다.

인턴 끝, 대학 생활 끝

판교 이가네양꼬치를 접한 이후로 양꼬치 + 맥주는 최애 회식 메뉴가 되었다.

이렇게 안랩 인턴의 끝과 함께 내 대학생활도 끝났다는 것을 수료증을 받으면서 실감했다. 막학기 종강도 같이 한 것이구나…

그래서 한 가지 아쉬운 부분이 있다면, 그냥 기숙사 생활이나 자취를 하면서 좀 더 대학생활을 마지막까지 즐겼어야 했나? 싶기도 하다.

막상 회사생활에 집중한다고 또 못 즐겼을 수도 있지만.

근데 사실 회사 생활 자체보다, 판교로 출퇴근하며 9호선과 신분당선 지옥철에서 겪었던 기 빨림이 더 힘들었다(직장인 분들 리스펙합니다…).

그래도 안랩 인턴을 하면서 회사 생활이 나름 잘 맞는다는 걸 느꼈고, 개발자를 목표로 삼아도 되겠다는 확신도 얻을 수 있었다.

(2026년 시작) 취준 정병...

캡디 후반부에 이사를 하게 되어서 남은 기간 동안 고통 받았다 / 왜 중앙대는 안돼요... / 중앙대 앞 할리스 2층 뷰

캡스톤디자인 기간(2025년 1학기)에 본가가 수원에서 서울, 중앙대 근처로 이사를 갔었다.

안랩 인턴 중에는 못 느꼈는데, 막상 백수가 되니까 중앙대 앞을 지나다니며 살짝 기분이 이상했다.

대학 입시 때 1지망 학교여서 그런가?

*TMI로 입시 때 중앙대, 건국대, 동국대, 숭실대, 아주대, 서울과기대 컴공으로 6학종 수시를 넣었다.

아주대학교 중앙도서관 커뮤니티라운지(일명 커라)에서 코딩, 공부할 때는

아무래도 다른 열람실과 다르게 커라가 노트북을 사용할 수 있다보니까, 소프트웨어학과 학우가 많아서 묘한 동질감이 느껴졌는데

흑석에서는 구립도서관에서 하다보니 좀 외롭기도했다.

구립도서관에서 취준하는 사람은 나혼자라 더 외로웠다.

저 기간 동안 만나는 사람이 1주일에 4명을 안넘어 갔었다(가족 포함).

(2026년 2월) 넷마블 채용전환형 인턴 시작

나름 한 달 정도 취준정병을 겪다가, 2025년 하반기에 넣었던 기업들은 다 떨어지고

넷마블만 유일하게 붙었다.

넷마블은 솔직히 아예 기대를 하지 않았었는데, 갑자기 서류에 합격해서 AI역량검사를 보라고 하는 연락이 오고, 역량검사 이후에는 면접 보러 오라는 메일이 와서 좀 당황스러웠다.

그래도 기회가 주어진 만큼 정말 열심히 준비했고, 후회없이 면접을 보았다.

솔직히 이렇게까지 면접을 잘 봤는데도 떨어지면 얼마나 더 잘 봐야하지 싶을 정도로 나의 입장에서는 후회가 없었다.

사실 채용검진 이후의 최종 인턴십 안내 메일인데, 채용검진에서도 떨어질까봐 살짝 불안했다. 진짜 쫄보인가. / 구로에서 제일 높은 건물이어서 너무 잘보였다.

안랩 첫 출근 때도 그렇고, 첫 날에는 거의 잠을 못 자고 간다. / 노란색 목걸이를 인턴 기간 동안 차고 다녔다. 병아리가 된 느낌….

인턴십 면접을 본 이후 1주일 동안은 잠도 제대로 못 자고 살도 계속 빠지는, 또 한 번의 '정병' 기간을 거쳤다.

그리고 결국 인턴십에 합격했다.

사실 안랩 인턴 이후 실업급여를 받으려면 한 달 정도 아르바이트 같은 걸로 조건을 채워야 했는데, 그 공백을 넷마블 인턴으로 자연스럽게 채울 수 있어서 다행이었다.

안랩은 체험형 인턴이었지만, 넷마블은 채용전환형 인턴이었기 때문에 임하는 마음가짐 자체가 달랐다.

'올인하자'는 마음으로, 주말에도 온통 과제 생각만 하며 지냈다.

약속도 잡지 않고, 주말에는 구립도서관에 가서 공부했다.

기회가 주어졌다고 생각했고, 꼭 잡고 싶었다.

넷마블 인턴 기간 동안은 AI를 최대한 활용하면서 정말 많이 성장할 수 있었다.

동기들과 함께 열심히 달리다 보니 시간도 유독 빨리 갔다.

인생에서 가장 빠르게 지나간 8주였다.

(2026년 2월) 졸업식

현수막 해준 휘래 + 한터 임원진들 감사합니디.

넷마블 인턴 기간에 졸업식 일정도 있었는데, 연차를 쓰고 마음 편하게 다녀왔다.

오랜만에 동기들도 보고 아는 얼굴도 보니까 좋았다.

최종 전환이 되어서 왔으면 조금 더 마음이 편했겠지만, 그래도 주어진 기회를 잡아보자는 동기부여를 얻고 갔다.

(2026년 4월) 실업급여 요건 충족, 진짜 백수

8주 간의 넷마블 인턴 생활

온 세상이 토스다

넷마블 인턴 기간이 끝나고…

안랩 6개월 + 넷마블 인턴 8주까지 합산해서 실업급여 요건을 충족했다.

그리고 이제 졸업도 해버려서 진짜 백수였다.

인턴 전환 결과까지는 1주일 정도 걸린다고 들었는데, 이 기간 동안은 정말 오만 상상을 다 했었다. 떨어지면 어떨지, 뭘 할지 등등…

그래도 인턴 끝나고 나니까 벚꽃이 만개하고 날씨도 좋아서 열심히 돌아다녔다.

흑석동 주민이 추천하는 야경 명소 - 용양봉저정 공원

동작구에 사육신공원이 있는데, 홍보 차원에서 무료 관람을 신청 받았다.

취소표로 용아맥 겨우 잡았다 / 영화 시작 전 나왔던 반가운(?) 넷마블 로고… / 왜 용아맥용아맥하는지 알겠더라

4D ‘입체기동장치관’에서 땅울림, 조사병단 체험

보고 싶었던 영화들도 몰아서 봤다.

특히 혼자 일본 여행(도쿄, 가마쿠라)을 갈 것인가, 집에서 진격의 거인을 정주행할 것인가를 두고 고민이 많았는데,

진격의 거인을 선택한 게 하나도 후회되지 않았다. 마지막 시즌은 영화관에서 봤는데, 정말 최고의 선택이었다.

진격의 거인은 역사가 맞다…

(2026년 4월) 최종합격 및 신입사원 입사

다시 출근하게 되어서 너무 좋았다(이제 구로 사옥은 팔렸고, 2028년 과천 신사옥으로 이전한다).

결국 1주일의 기다림 끝에 최종합격 소식을 듣게 되었다.

회사 입장에서는 3년 만의 기술직군 신입이었고, 역시나 입사하고 보니 내가 막내였다.

최종합격 소식을 듣기 직전에는 다른 기업의 AI 역량검사를 보던 중이었다.

전화가 한 통 와 있길래 살짝 기대를 했는데, 역량검사 설문이 끝나자마자 '잠깐 쉴게요' 버튼을 누르고 핸드폰 알림을 확인해보니 합격 메일이 와 있었다.

보던 역량검사는 곧바로 닫아버리고, 마침 부모님이 집에 계셔서 함께 합격의 기쁨을 나눴다.

그날은 날씨도 유독 좋았고, 세상이 아름다워 보였다.

꽃다발과 선물을 집으로 보내주셨는데 진짜 뽕차더라...

생각보다 빠르게 달성했다.

(2026년 4월 ~ 7월) 수습기간

입사하고 '몬길: STAR DIVE' 론칭이 바로 있었다.

학교 다닐 때는 한 번도 안왔는데... 졸업하니까 바로 오는 잔나비 / '꿈과 책과 힘과 벽'도 새벽 도서관에서 집으로 돌아가는 길에 정말 많이 들었는데, 학교 축제에서 들으니 그때 생각이 많이 났다.

넷마블 개발자 포럼 후드티 굿즈 / 사내 카페(ㅋㅋ다방) 망고빙수 / 동기들이랑 같이 찍은 포토이즘&넷마블 콜라보

채용전환형 인턴에서 정규직으로 전환된 이후에도 3개월간의 수습 기간을 거쳤다.

이 기간 동안 간단한 게임을 직접 개발해보고, 사내 SDK와 플랫폼을 연동하는 온보딩 프로젝트를 진행했다.

내부 테스트용이었지만 실제로 구글 플레이에 올려보기까지 했는데, 그 과정 자체가 정말 재미있었다.

특히 게임 산업의 구조, 게임 퍼블리싱 사업, 플랫폼과 SDK, 마켓 정책 등 글로벌 게임을 운영하기 위한 대규모 시스템이 어떻게 구축되어 있는지를 배울 수 있었던 값진 경험이었다.

졸업하고 취업한 뒤 다시 학교를 찾으니 기분이 색달랐다.

특히 학교 앞에 살던 시절, 도서관에서 집으로 걸어가던 그 길을 자주 듣던 노래를 들으며 다시 걸으니 감회가 새로웠다.

그리고 수습 기간 동안 여러 컨퍼런스와 사내 AI 교육에도 참석하면서 많은 인사이트를 얻었다.

많이도 돌아다녔다.

(2026년 7월) 수습 끝, 부서 배치

귀여운 넷마블 명함

딱히 실무를 하진 않았지만 그래도 무사히(?) 수습 기간을 통과하고 정식으로 부서 배치를 받았다!

지금은 정말 너무 바쁘다… 하루하루가 빠르게 지나가고, 일주일이 순식간에 지나간다.

그만큼 일이 재미있고 배우는 것도 많으며, 실제 실무에 기여할 수 있어서 뿌듯하다.

신입 때는 마음껏 굴러보고 싶었는데, 정말 잘 구르고 있다고 생각한다.

합격한 공고

안랩 현장실습인턴(6개월) - 모바일 서버 개발

안랩 인턴은 매 상반기/하반기마다 뽑는다. 현장실습 학점연계도 가능하다.

넷마블 채용전환형 인턴(8주) - SW개발

넷마블은 2022년 이후로 3년 만에 기술직군 신입사원 공채를 진행했다.

잘했던 점/좋았던 점

꾸준히 한 가지 프로젝트를 오래한 것

‘아주대학교 공지사항 알림 서비스’라는 프로젝트를 3학년 1학기 첫 프로젝트로 시작해서(파란학기제) 지금까지 계속 운영했던 것이 포트폴리오나 자기소개서 스토리를 만들어나가는 데 좋았다.

역시 직접 서비스를 운영해보는 경험은 무조건 의미 있다고 생각한다. 만약 추가적으로 욕심을 낸다면 정말 쌩판 모르는 사람이 결제를 해줘서 돈을 벌어보는 경험도 해보면 많은 걸 느낄 수 있을 거 같다.

주어진 상황에서 최선을 다했다.

위의 프로젝트 뿐만 아니라 코딩 트레이너, 안랩 체험형 인턴, 넷마블 채용전환형 인턴과 같은 주어진 상황, 기회에서 최선을 다하는 습관이 좋은 결과로 연결되었다고 생각한다.

사실 최선을 다 안했을 때 나중에 후회하는게 두려워서 더 열심히했던 것도 있다.

그래도 하나씩 스펙을 쌓아가는 과정이 있었다.

중간중간 인턴 합격이라는 성과를 통해서 그래도 조금씩 나아가고 있다는 느낌을 받을 수 있었다.

만족할만한 결과를 가지고 취준판을 떠나다.

그리고 취업이 정말 어렵다고 자부(?)할 수 있는 시기에 대기업 백엔드 개발자로 취업한 게 스스로도 대단하다고 생각한다.

물론 운이 좋았지만.

대학 입시 때도 그렇고, 남과의 비교 없이 본인이 만족할 수 있는 결과를 가지고 판을 떠나는 게 중요하다고 생각하는데,

그걸 달성해서 미련이 없다.

아쉬웠던 점

너무 혼자하려고 했던 것?

안랩 인턴 기간에는 소중한 기회인 만큼 거기에만 온전히 몰입하고 싶었고, 괜히 민폐를 끼칠까 봐 다른 활동은 일부러 하지 않았다.

그래도 돌이켜보면 주말 정도는 프로젝트가 아니더라도 네트워킹 정도는 시도해볼 수 있었을 텐데 하는 아쉬움이 남는다.

연합동아리도 하고 싶었지만 결국 지원하지 않았는데, 취준을 길게 놓고 봤을 때는 멘탈 관리 측면에서도, 네트워킹 측면에서도 도움이 되었을 것 같다.

물론 막상 인턴에 합격하고 나니 연합동아리 자기소개서를 쓰는 게 귀찮아진 것도 사실이지만.

이사를 하면서 혼자 취업 준비를 이어갔던 것도 멘탈적으로 쉽지 않은 시기였다. 그래서 러닝과 헬스를 열심히 했던 것 같다.

조급함

특히 넷마블 인턴을 하면서 조급함을 많이 느꼈다.

기간이 짧기도 했고, 여기서 성과를 보여주지 못하면 다음은 없다는 생각에 스스로를 몰아붙였던 것 같다.

이런 조급함은 과제를 진행하는 과정에서도 그대로 드러났고, 관련된 피드백을 받기도 했다.

나는 조급한 마음에 군 휴학을 제외하고는 따로 휴학 없이 졸업했지만,

돌이켜보면 진로를 찾고 교환학생이나 좋아하는 것, 재밌는 것을 하고 찾아가는 과정이 더 소중하다고 생각한다.

느낀점

운이 좋았다.

경쟁률이 기본적으로 100대 1을 넘는 시장에서 합격한다는 건 '운' 없이는 불가능하다고 생각한다.

진부하게 들릴 수도 있지만, 나 역시 실력이 특별히 뛰어나서라기보다는 운이 좋았다.

복권 당첨자들의 공통점은 복권을 구매했다는 것

다만 운이 작용하려면 그만큼 시행 횟수를 늘려야 한다.

예전에 어떤 취업 수기에서 봤던 문장 중, "복권 당첨자들의 공통점은 복권을 구매했다는 것"이라는 문장이 유독 기억에 남는다.

IT업계는 참 좁구나

- 인턴 생활을 하며 만난 사람들 중에 의외로 겹치는 지인이 많았다.

- 대학교 학술소학회 회장을 하던 시절, 세미나 연사로 섭외드렸던 선배가 넷마블에 재직 중이셨는데, 2년 뒤 넷마블 면접을 준비하며 그 인연으로 도움을 받게 될 줄은 전혀 몰랐다.

대학 입시 이후로 이렇게까지 간절했던 순간이 있었나 싶다.

물론 회사 생활을 하고 연차가 쌓이면 마음가짐도 달라지겠지만, 지금 이 초심만큼은 기억하고 싶다.

중고신입이 못 들어오는 영역 → 채용전환형 인턴

중고신입이 판치는 지금의 취업 시장에서, 채용전환형·채용연계형 인턴을 선택하는 건 나쁘지 않은 선택지라고 생각한다.
물론 채용전환형 인턴에만 집중하다 보면 다른 곳에 지원하지 못하게 되고, 떨어졌을 때의 리스크가 커지는 것도 사실이다. 하지만 채용전환형 인턴 경험 역시 하나의 경력이자 차별점이 된다고 생각하고,
무엇보다 지금은 가릴 상황이 아니다.

중요한 것은 태도

AI 시대에 오히려 더 중요해진 건 '태도'라고 생각한다.

진정성은 어떻게든 티가 나기 마련이고, 면접관 분들은 몇 년간 수백 명을 면접 봐온 사람들이다.

이런 태도는 취업 준비 기간에 벼락치기로 만들어지는 게 아니라, 평소 학교 생활이나 프로젝트에서 최선을 다하고 협력하는 과정에서 자연스럽게 쌓이는 것이라고 생각한다.

최선을 다하는 자세만 잃지 않는다면, 언젠가는 반드시 빛을 볼 수 있다고 믿는다.

도전적인 상황을 만들자

평소에는 PPT도 잘 만들지 못하고 발표도 서툴다고 생각했는데, 인턴 기간 동안 도전적인 상황들과 마주하면서 많이 발전할 수 있었다.

기회가 있다면 자주 부딪혀보고, 그 상황에 익숙해지는 것이 중요하다는 걸 다시 한번 느꼈다.

한 챕터의 끝, Next?

흑석동은 바로 앞이 한강이라 러닝하기 너무 좋은 동네다.

한때 도시공학과를 꿈꿨었다.

동네북인 컴공...

이렇게 정리하고 보니, 정말 숨 가쁘게 달려왔다. 어떻게 보면 인생의 한 챕터가 끝난 것 같기도 하다.

하지만 이게 끝이라고는 생각하지 않는다. 당장 언제 대체될지 모르는 AI시대이니까…

그래서 자기계발, 특히 영어는 꾸준히 하려고 한다. 운동도 열심히 하고.

앞으로도 다양한 경험을 쌓고 싶다.

위에서 말했던 것 처럼 회사 안에서도 주니어 때는 정말 굴려지면서 열심히 배우고 싶다.

물어보는걸 주저하지말기로!

Appendix

신인류

날씨의 요정, 미완성 효과, 송곳니, 이상하고 아름다운, 푸른 공상 등 노래가 다 좋다

'정면돌파'는 인턴 기간 동안 출퇴근하면서 가장 많이 들었던 곡이다.

한국대중음악상에서 ‘신인류’의 ‘빛나는 스트라이크’가 최우수 얼터너티브 록 음반을 수상했다는 걸 알게되고 들었는데,

정면돌파 말고도 ‘이상하고 아름다운’, ‘일인칭 관찰자 시점’, ‘Huf’ 등 전반적으로 곡들이 너무 좋고 명반이다.

개인적으로 잔나비 특유의 얼터니티브 록 음악을 좋아하는데, 내가 좋아하는 장르의 노래였다.

최종합격 이후에 한대음 페스티벌에 가서 라이브도 들었다!

한대음 페스티벌에서 마지막 아티스트 공연 전에 미리 나왔는데, 우연히 멤버들과도 만나서 사진도 찍었다.

쿵야

회사 깃허브, JIRA 프사를 양파쿵야로 해놓으신 직원 분들이 엄청 많다.

쿵야가 넷마블 IP인걸 들어가서 알게 되었다.

나도 직장인 밈으로 알고 있었는데, 입사하고 나니까 더 애착이 간다.

넷마블과의 인연

초등학교 3학년 때 가입한 넷마블 아이디. 인턴 면접 '마지막 한마디'에서 넷마블 계정 가입일자와 마구마구 이야기도 했다. / 진짜 초딩이 지을법한 닉네임이다 ㅋㅋ

넷마블 마구마구가 첫 PC게임이었는데, 이렇게 다시 만나게 되어서 너무 반갑다!

그때 저금통 뒤져서 현질도 꽤 했었는데, 이제 월급으로 페이백 받을 수 있겠다.

유튜브처럼, 구독한 공지사항별 알림 설정 기능을 도입해보자

simzard — Thu, 2 Oct 2025 15:49:58 +0900

기능 개발 배경 - 푸시 알림이 너무 많이 와요…

아주대학교-일반 공지사항은 하루에도 30~50건씩 올라온다. "구독"탭에서는 구독한 공지사항 글을 확인할 수 있다.

아주대학교 '일반 공지사항'을 구독한 사용자들로부터 “하루 30~50건씩 올라오는 공지로 인해 푸시 알림이 너무 자주 와서 부담스럽다”는 피드백이 왔다.

흥미로운 부분은, 사용자들이 그렇다고 해서 구독을 완전히 취소하고 싶어하지는 않는다는 것이었다.

구독을 취소하면 '구독 탭'에서 새 글을 바로 확인할 수 없고, 필요할 때마다 '검색 탭'에서 직접 찾아야 하는 불편함이 생기기 때문이다.

실제로 구독 탭의 네비게이션 바에 표시되는 '배지'를 통해 사용자가 구독한 새로운 공지사항이 올라왔다는 소식을 알려주고 있었다.

사용자 입장에서는 특정 공지사항에 대해 “구독은 유지하고, 알림만 끄고 싶어요”라는 니즈가 존재했다.

기존 구조는 Topic(공지사항) 구독 = 푸시 알림 수신이었다.

따라서 사용자가 알림을 끄려면 선택지는 두 가지뿐이었다.

1. 핸드폰 앱 설정에서 ajouevent.com 서비스의 모든 알림을 차단하기

2. 부담스러운 공지사항의 구독을 취소하기

하지만 서비스를 운영하는 나의 입장에서는 두 선택지 모두 리스크가 컸다.

특히 1번 선택지의 경우, 앱 설정에서 전체 알림을 꺼버리면 다시 켜는 경우가 드물기 때문에, 특정 공지사항 단위로 알림을 제어할 수 있도록 하는 것이 더 합리적이었다.

결국 서비스 차원에서 구독한 공지사항별 알림 설정 기능을 제공하는 것이 사용자 경험(UX) 측면에서도 필요하다고 판단했다.

목표: 구독한 공지사항의 푸시 알림 설정 기능을 추가하자

공지사항별로 알림 설정을 따로 둘 수 있어야 했다.

이 부분에서 유튜브의 채널별 알림 설정 기능이 생각났다.

유튜브가 채널 "구독"과 "알림 설정"(전체/맞춤설정/끔)으로 분리하는 것에서 힌트를 얻어 동일한 UX를 목표로 했다.

아주이벤트에서도 “구독은 유지하면서 알림만 끌 수 있는 구조”를 구현하고자 했다.

유튜브 vs 아주이벤트

알림 설정 - 유튜브

알림 설정 - 아주이벤트

지금은 구독/구독 취소 밖에 없으며, 구독일 때만 알림을 받을 수 있다

구독 탭 - 유튜브

유튜버 채널에 들어가면 유튜버의 동영상을 볼 수 있다

자신의 구독 페이지에서는 구독한 유튜버의 업로드한 동영상을 볼 수 있다

구독 탭 - 아주이벤트

구독탭에서 구독한 공지사항을 볼 수 있는데, 지금은 구독을 하면 무조건 알림을 받는 구조다(따로 앱 설정에서 알림을 끄지 않는 이상)

*우선 FCM의 Token과 Topic이란?

우선 https://www.ajouevent.com 서비스의 푸시 알림은 FCM의 Topic을 사용한다.

FCM Token과 Topic의 차이는 아래와 같다.

FCM Token

출처: https://zuminternet.github.io/FCM-PUSH/

앱이 FCM 서버와 통신하기 위해 사용되는 고유한 식별자
앱은 서버와 통신할 때 토큰을 사용하여 FCM 서버에서 앱을 식별하고, 이를 통해 메시지 전송을 할 수 있다.
FCM의 토큰은 앱이 설치된 디바이스마다 고유하다. 앱이 설치된 디바이스를 추가하거나 삭제할때 토큰이 변경될 수 있다. (refresh)
서버는 이러한 FCM 토큰을 사용하여 특정 디바이스에 메시지를 전송할 수 있다.

즉, Token은 Firebase에서 관리하는 프로젝트별 접속하는 기기의 고유 ID로 볼 수 있다.

FCM Topic

출처: https://zuminternet.github.io/FCM-PUSH/

FCM의 Topic(토픽)은 일종의 채널로서, 미리 Topic을 구독한 사용자(토큰)들에게 메시지를 전송할 수 있다.
Topic을 구독, 구독 취소 요청시에, FCM은 구독한 유저들을 내부적으로 관리한다.
FCM의 subscribe, unsubscribe 메서드를 통해 구독과 구독 취소 요청을 FCM에 전송할 수 있다.
Topic을 통해서 푸시 알림을 발송하면, Topic을 구독한 사용자들에게만 메시지를 전송할 수 있도록 한다.

FCM 개념 정리 (Token vs Topic)

FCM Token: 디바이스(앱 설치 단위) 식별자. 서버는 이 토큰으로 특정 기기에 보낸다.
FCM Topic: 채널 개념. 토픽을 구독한 모든 기기에 보낸다. 구독/해지는 FCM이 내부적으로 관리한다.

Topic 방식에선 서버가 반드시 FCM 라이브러리를 사용해 대상 Token과 구독할 Topic 정보를 담아 subscribeToTopic() / unsubscribeFromTopic()를 호출해 토큰-토픽 관계를 FCM에게 알려줘야 한다. 이후 푸시 메시지를 발송할 때 해당 Topic 정보를 포함해 FCM으로 요청하면, FCM이 사전에 해당 Topic을 구독한 모든 Token으로 알림을 전송하는 구조이다.

고민한 방법들

방법1 - 알림 여부를 저장하는 필드 추가(기존 구조 유지)

현재 구조에서, TopicMember에 receiveNotification 필드를 추가
- receiveNotification 필드: 사용자가 구독하고 있는 특정 Topic에 대한 알림 수신 여부를 설정하는 필드
  - receiveNotification == true: 푸시 알림 수신
  - receiveNotification == false: 푸시 알림 거부 (구독만 한 상태, 구독한 공지사항 글은 볼 수 있음)
알림 해제 시 FCM unsubscribeFromTopic()을 호출하여 푸시 자체를 차단

상황별 정리 ( A → B, 즉 A 상태에서 B 상태가 될 때 변경 사항들)

상태전환	FCM 동작	DB 필드 변화	TopicMember 변화
구독 X → 새로 구독	FCM subscribeToTopic() 호출 - Software 구독	receiveNotification = true	새로 생성
구독 상태 → 알림 해제 (알림만 끄고 싶을 때)	FCM unsubscribeFromTopic() 호출 - Software 구독 해제	receiveNotification = false	유지
알림 해제 → 알림 설정	FCM subscribeToTopic() 호출 - Software 구독	receiveNotification = true	유지
구독 상태(알림 해제) → 구독 취소	(이미 해제된 상태, FCM 호출 없음)	TopicMember 삭제	삭제
구독 상태(알림 설정) → 구독 취소	FCM unsubscribeFromTopic() 호출 - Software 구독 해제	TopicMember 삭제	삭제

장점
- 기존 구조 변경 최소화 (필드 하나 추가만으로 구현 가능)
- 여전히 Topic 기반 전송이라 대량 전송 성능 우수
문제점
1. FCM 구독 상태와 DB 간 동기화 위험(정합성 일치 X)
  - 서버(DB)의 receiveNotification = false만으로는 FCM 알림 차단이 되지 않는다
  - FCM의 unsubscribeFromTopic() 호출이 누락되거나 실패할 경우, 알림을 꺼둔 사용자에게도 알림이 전송될 수 있다
  - 스프링 서버에서 알림 수신 여부를 통제하는 것이 아니라 FCM이 알림 설정을 통제
  - 로직 자체가 복잡하다…
2. 사용자별 맞춤 데이터 포함 불가
  - FCM 토픽 메시지는 모든 사용자에게 동일한 메시지만 전송됨
  - 사용자별 맞춤 알림 (예: 읽지 않은 개수에 따른 badge 수 전달)은 불가능
3. 상태 검증 어려움
  - Firebase에서는 “누가 어떤 토픽에 구독돼 있는지”를 조회하는 API를 제공하지 않음
  - DB 상태와 FCM 서버 상태의 불일치를 감지하거나 복구하기 어려움

방법 2 - 알림 여부를 다루는 Topic 추가 & FCM 조건식

각 공지사항마다 *_NoNotify Topic을 추가해, 알림을 끄고 싶을 때는 두 토픽을 동시에 구독하도록 설계.
- 기존 Topic: Software → 모든 소프트웨어 공지사항 구독자.
- 알림 제외 Topic: Software_NoNotify → 소프트웨어 공지사항을 구독하지만 알림은 받지 않으려는 사용자.
알림 전송 시 조건식을 사용하여 NoNotify 구독자를 제외.
- https://firebase.google.com/docs/cloud-messaging/ios/topic-messaging?hl=ko#node.js_3
- FCM의 조건식 (Condition)을 활용해 Software 토픽을 구독하지만 Software_NoNotify를 구독하지 않은 사용자에게만 알림 전송.
```
{
  "condition": "'Software' in topics && !('Software_NoNotify' in topics)",
  "notification": {
    "title": "새로운 공지사항",
    "body": "소프트웨어학과 공지사항이 올라왔습니다!"
  }
}.
```

구독 로직:

알림 받기: Software만 구독
알림 끄기: Software + Software_NoNotify 모두 구독

알림 해제/받기:

알림 해제: Software_NoNotify를 구독
알림 받기: Software_NoNotify를 구독 해제

구독 취소:

알림을 받고 있는 사용자: Software만 구독해제
알림을 끄고 있는 사용자: Software, Software_NoNotify를 모두 구독해제

상태	구독 Topic 조합	조건식 매칭	전송 방식	비고
구독 중 + 알림 받기	Software	✅	Condition → Topic 전송	기본
구독 중 + 알림 없음	Software + Software_NoNotify	❌ 제외	조건식에 의해 미전송	상태 표현을 토픽 조합으로
구독 취소	(둘 다 해제)	(무관)	없음	관리 복잡도↑

장점:
- Topic 기반의 전송 성능 유지
문제점
- 토픽 관리 증가:
  - 사용자 수가 많아지면 토픽 관리가 복잡해질 수 있음.
  - 각 토픽마다 알림 비활성 토픽을 추가해야함
- 조건식 복잡성:
  - 알림 전송 시 FCM 조건식이 복잡해지고, 조건식 작성 오류 시 의도치 않은 사용자에게 알림 발송 가능

방법 3 - 알림 여부를 저장하는 필드 추가 + Topic → Token 구조로 변경

사용자가 구독하고 있는 TopicMember 엔티티에 receiveNotification 필드를 추가하여, 알림 수신 여부를 사용자 별로 설정할 수 있게 한다.
공지사항 알림을 발송할 때, 구독 중이면서 receiveNotification == true인 사용자만 필터링 → Token 기반 개별 메시지를 전송한다.
더 이상 Fcm subscribe / unsubscribe 호출에 의존하지 않는다

이 방식은 FCM Topic 발송과 달리, 토큰이 어떤 토픽을 구독하는지 FCM에 따로 알려줄 필요가 없다. (즉, subscribeToTopic() / unsubscribeFromTopic() 호출이 필요 없음. 전송 대상은 DB에서 직접 필터링한다.)

상태	DB TopicMember	receiveNotification	FCM Topic 구독	전송 방식	비고
구독 중 + 알림 받기	✅ 존재	true	(무관)	Token 개별 전송	개인화 데이터 가능 (예: unread_count)
구독 중 + 알림 없음	✅ 존재	false	(무관)	미전송	FCM 구독/해지 호출 불필요
구독 취소	❌ 삭제	(삭제)	(무관)	없음	단일 소스(DB)로 정합성↑

장점
- 정합성 맞추기 용이하다.
- 사용자별 맞춤 알림 가능
  - 읽지 않은 알림 수와 같은 사용자별 데이터를 메시지에 포함 가능
- 발송 결과에 대한 개별 토큰 결과 확인 가능
- FCM이 알림 설정을 통제하는 것이 아니라, 스프링 서버에서 알림 수신 여부 통제 (DB에서 알림을 받는 사용자만 필터링해서 FCM으로 전달) → 정합성 리스크가 줄어듦
  - FCM에게 구독 정보를 전달할 필요가 없다. (subscribeToTopic() / unsubscribeFromTopic() 호출 x)
문제점
- 공지사항을 Topic으로 보내지 못함 → 지금은 공지사항을 보낼 때 Topic만 담아서 보내고, 따로 사용자 Token이나 TopicMember를 확인하지 않음→ 공지사항을 보내는 로직을 Token 구조로 수정해야 함
- Token 구조로 수정하게 되면, 공지사항 푸시 알림을 보낼 때 서버에서 검증하는 시간이 길어짐 (반면 Topic은 이미 구독을 FCM 서버에서 관리했다고 가정해서 그냥 Topic으로 보내면 됨)
- FCM 전송 성능 저하:
  - 토픽을 사용하지 않고 FCM Token으로 개별 전송하면 다수의 사용자에게 알림을 보낼 때 비효율적.
  - 사용자 수가 많아질수록 처리 비용 증가.
- 추가 로직:
  - 알림 전송 시 사용자 데이터를 필터링하고 토큰 리스트를 생성하는 추가 작업 필요.
- FCM 토픽의 장점 포기:
  - FCM 토픽의 전송 효율성과 단순함을 활용하지 못함.

방식별 장단점 정리

방식	장점	단점
방법 1(Topic 유지 + receiveNotification)	- 기존 구조 변경 최소화 - 구현 간단 - 여전히 Topic 기반이라 대량 전송 성능 우수	- DB ↔ FCM 상태 불일치 가능 - 사용자 맞춤 데이터 불가 - 상태 검증 어려움
방법 2(알림 전용 Topic 추가 + 조건식)	- Topic 기반 성능 활용 - 알림 여부를 Topic 조합으로 단순히 표현	- 토픽 관리 복잡도 ↑ - 조건식 작성 번거로움/실수 위험
방법 3(Token 전송 + DB 필터링)	- 사용자별 맞춤 데이터 가능 (unread_count 등) - 전송 결과 추적 용이 - 단일 소스(DB)로 정합성 확보	- Topic 기반보다 성능 저하 - 토큰 필터링/조회 로직 추가 필요 - 대량 전송 시 서버 부하 ↑

최종 선택 및 구현 방향

1차: receiveNotification 필드 추가 → Topic 기반 유지하면서 알림 ON/OFF 기능 제공

2차: Token 기반 전송으로 전환 → 사용자별 맞춤 알림(배지 수, 통계) + 정합성 개선

1차 채택 - 방법1: 기존 Topic 구조 + receiveNotification 필드 추가

당장 사용자에게 기능을 빠르게 제공해야 했기 때문에, 기존 구조를 크게 바꾸지 않고도 구현 가능한 방법 1을 우선 적용했다.

TopicMember 엔티티에 receiveNotification 필드를 추가하여, 사용자가 알림을 해제하면 FCM에 토픽 구독 해제 요청(unsubscribeFromTopic)을 보내고, 해당 필드 값만 false로 바꾸도록 했다.

공지사항이 기존처럼 FCM Topic으로 전송되더라도, 알림을 해제한 사용자는 실제로 푸시를 받지 않게 된다

즉, FCM 서버에서 구독이 해제되어 있기 때문에, 동일한 Topic으로 발송하더라도 알림을 받는 사용자와 받지 않는 사용자를 구분할 수 있게 되었다.

2차 채택 - 방법3: Topic → Token 구조로 변경

하지만 실제 운영 중에 정합성 문제가 터졌다. 구독을 했는데도, 푸시 알림이 오지 않는 사례가 발생했다.

정합성 이슈의 원인

FCM Token의 특성
- FCM Token은 기기마다 발급되며, PWA 재설치나 토큰 만료 시 새로 발급된다.
구독 정보 갱신 과정
- 새 Token이 발급되면(아이폰에서 우리 서비스를 쓰다가, 아이패드에서도 쓰기 위해 로그인하는 경우), 기존에 구독하던 Topic들을 다시 FCM 서버로 subscribeToTopic()를 호출해서 연결해야 한다.
- 이 과정이 로그인 시점에 처리되었는데 사용자가 기존에 구독한 공지사항, 키워드가 많을수록 호출이 많아져 로그인 속도가 느려졌다.
사용자 새로고침 문제
- 로그인 도중 사용자가 새로고침을 해버리면, 일부 subscribeToTopic() 요청이 끝나기 전에 끊겨버린다.
- 이 때문에 DB에는 구독 상태로 기록됐지만, FCM 서버에는 구독 정보가 반영되지 않아 푸시 알림이 오지 않는 현상이 발생했다.

→ 즉, 처음 우려했던 알림 ON/OFF 정합성 문제와 유사한 문제이다. 구독 상태를 FCM에서 제어·관리하는 구조 자체가 정합성 리스크를 안고 있음을 확인할 수 있었다.

추가 요구사항

이와 더불어 새로운 요구사항도 생겼다.

앱 뱃지 적용

FCM 메시지에 “사용자별로 읽지 않은 알림 개수”를 data에 담아 전송한 뒤, PWA 앱 배지 UI에 띄워야 한다.

하지만 FCM Topic 전송 방식은 모든 사용자에게 동일한 메시지만 전송할 수 있기 때문에, 사용자별 맞춤 데이터 전송이 불가능했다. 클릭률, 수신율 같은 사용자별 통계와 개별 토큰에 대한 푸시 전송 결과와 같은 로그를 수집하는 것에도 한계가 있었다.

구조 전환

이 두 가지 이유(정합성 리스크 + 맞춤 데이터 요구)로 인해, 기존 Topic 중심 구조에서 Token 기반 전송 방식으로 전환했다.

항목	이전(Topic 전송)	이후(Token 전송)
전송 단위	Topic	Token
알림 ON/OFF	FCM 토픽 구독/해지 필요	DB receiveNotification으로 필터링 (FCM 호출 없음)
정합성	DB ↔ FCM 상태 불일치 가능	단일 소스(DB)로 정합성 확보
개인화 데이터	불가(동일 메시지)	가능(ex: unread_count)
전송 성능	대량에 유리	배치/비동기로 보완

각 사용자별로 읽지 않은 알림 개수를 계산하고, 해당 값을 담은 메시지를 Token을 통해 개별 전송함으로써 프론트엔드 앱의 배지 UI에 정확한 정보를 반영할 수 있도록 했다.
물론 Topic 방식이 성능적으로는 더 뛰어나지만, 전체 사용자 수가 감당 가능한 수준이고, 비동기 + 논블로킹 방식의 ThreadPool 구조를 도입하여 전송 성능을 충분히 최적화할 수 있었다.
구조 변경 이후에도 TopicMember 엔티티의 receiveNotification 필드는 유지되며, 공지사항 크롤링 → 구독 사용자 조회 → 푸시 전송 로직에서 해당 필드(receiveNotification)가 false인 사용자에겐 알림을 보내지 않도록 분기 처리하고 있다.

*Topic → Token으로의 푸시 알림 구조 전환 과정은 따로 글을 작성해 보겠다.

최종 구현 정리: 알림 설정 추가 및 Token 기반 전송

알림 설정 추가

TopicMember에 receiveNotification 필드 도입

@Column(nullable = false, columnDefinition = "TINYINT(1)")
private boolean receiveNotification;

receiveNotification: 사용자의 알림 수신 여부를 나타내는 필드
구독 시 기본값은 **true**이며, 사용자가 알림을 해제하면 **false**로 설정

사용자가 구독한 Topic에 대해 알림 설정을 ON/OFF할 수 있도록 API를 제공

public record NotificationPreferenceRequest(String topic, boolean receiveNotification) {
}

@PreAuthorize("isAuthenticated()")
@PostMapping("/subscriptions/notification")
public ResponseEntity<ResponseDto> updateNotificationPreference(
			@AuthenticationPrincipal CustomUserDetails userDetails,
			@RequestBody NotificationPreferenceRequest request) {
	topicService.updateNotificationPreference(request);
	return ResponseEntity.ok().body(ResponseDto.builder()
		.successStatus(HttpStatus.OK)
		.successContent(request.getTopic() + " 알림 수신 설정이 " + request.isReceiveNotification() + "로 변경되었습니다.")
		.build()
	);
}

@Transactional
public void updateNotificationPreference(
							CustomUserDetails userDetails,
							NotificationPreferenceRequest request) {
	Member member = memberRepository.findByEmail(userDetails.getEmail())
		.orElseThrow(() -> new CustomException(CustomErrorCode.USER_NOT_FOUND));

	Topic topic = topicRepository.findByDepartment(request.getTopic())
		.orElseThrow(() -> new CustomException(CustomErrorCode.TOPIC_NOT_FOUND));

	TopicMember topicMember = topicMemberRepository.findByMemberAndTopic(member, topic)
		.orElseThrow(() -> new CustomException(CustomErrorCode.SUBSCRIBE_FAILED));

	topicMember.changeReceiveNotification(request.isReceiveNotification());
}

요청 시 NotificationPreferenceRequest로 topic 이름과 알림 여부를 전달받아, 해당 TopicMember의 receiveNotification 필드를 갱신한다.

Token 기반 발송 로직

알림 전송 전 사용자 필터링

// Topic을 구독 중이고, 알림을 수신 허용한 TopicMember 조회
List<TopicMember> topicMembers = topicMemberRepository
    .findByTopicWithNotificationEnabledAndTokens(topic);

receiveNotification = true인 사용자만 필터링하여 알림 전송 대상으로 지정

// PushClusterTokens 생성
List<PushClusterToken> clusterTokens = topicTokens.stream()
	.map(token -> PushClusterToken.builder()
		.pushCluster(pushCluster)
		.token(token.getToken()) // TopicToken에 연결된 Token 가져오기
		.jobStatus(JobStatus.PENDING) // 초기 상태: PENDING
		.requestTime(LocalDateTime.now()) // 요청 시간 기록
		.build())
	.collect(Collectors.toList());
pushClusterTokenBulkRepository.saveAll(clusterTokens);

위에서 필터링된 사용자들의 유효한 FCM 토큰을 바탕으로, 실제 알림 전송 대상인 PushClusterToken을 생성하고 저장

사용자 개별 푸시 메시지를 생성

@Transactional
public void sendNoticeNotification(NoticeDto noticeDto, Long eventId, Long pushClusterId) {
    PushCluster pushCluster = pushClusterRepository.findById(pushClusterId)
        .orElseThrow(() -> new CustomException(CustomErrorCode.PUSH_CLUSTER_NOT_FOUND));

    List<PushClusterToken> clusterTokens = pushClusterTokenRepository.findAllByPushClusterWithTokenAndMember(pushCluster);

    // 사용자별 읽지 않은 알림 개수 조회
    Map<Long, Long> unreadCountMap = pushNotificationRepository.countUnreadNotificationsForTopic(noticeDto.getKoreanTopic())
        .stream()
        .collect(Collectors.toMap(UnreadNotificationCountDto::getMemberId, UnreadNotificationCountDto::getUnreadNotificationCount));

    sendPushClusterNotification(
        clusterTokens,
        pushCluster,
        composeMessageTitle(noticeDto),
        composeBody(noticeDto),
        getFirstImageUrl(noticeDto),
        getRedirectionUrl(noticeDto, eventId),
        unreadCountMap
    );
}

사용자의 FCM 토큰별로 읽지 않은 알림 수를 함께 포함해 전송하기 위해, unreadCountMap을 생성
이후 각 사용자에게 전송할 메시지를 PushClusterToken 기준으로 구성

FCM으로 전송

public void sendPushClusterNotification(List<PushClusterToken> clusterTokens, PushCluster pushCluster, String title, String body, String imageUrl, String clickUrl, Map<Long, Long> unreadCountMap) {
    List<List<PushClusterToken>> batches = splitIntoBatches(clusterTokens, 400);

    // 메시지에 알림 수를 담음
    List<Message> messages = batch.stream()
        .map(token -> buildMessage(pushCluster.getId(), token, title, body, imageUrl, clickUrl, unreadCountMap))
        .collect(Collectors.toList());

    // 푸시 알림 FCM 발송 로직
    ApiFuture<BatchResponse> responseFuture = FirebaseMessaging.getInstance().sendEachAsync(messages);
    /*
    	..
    */
}

private Message buildMessage(Long pushClusterId, PushClusterToken token, String title, String body, String imageUrl, String clickUrl, Map<Long, Long> unreadCountMap) {
    Long unreadCount = unreadCountMap.getOrDefault(token.getToken().getMember().getId(), 0L);

    return Message.builder()
        .setToken(token.getToken().getTokenValue())
        .setNotification(Notification.builder()
            .setTitle(title)
            .setBody(body)
            .setImage(imageUrl)
            .build())
        .putData("click_action", clickUrl)
        .putData("push_cluster_id", String.valueOf(pushClusterId))
        .putData("unread_count", String.valueOf(unreadCount)) // 사용자 맞춤 badge 수
        .build();
}

메시지는 FCM의 data 필드에 사용자 맞춤 정보(클러스터 ID, 알림 수 등)를 담아 개별적으로 생성
프론트엔드에서는 받은 메시지의 unread_count 값을 기반으로 배지를 정확히 렌더링 가능

UI 반영

앱 뱃지 적용

공지사항별 알림 설정 적용 / 알림 없음을 하더라도 구독 탭에서는 구독한 글을 볼 수 있다.

결론

특정 공지사항의 푸시 알림이 너무 많다는 사용자 피드백이 있었고, 이를 해결하기 위해 처음에는 구독한 공지사항의 알림 설정 필드(TopicMember.receiveNotification)를 추가해 기존 Topic 구조 내에서 알림 ON/OFF를 제어했다.

그러나 운영 과정에서 FCM Topic 방식의 정합성 리스크가 드러났고,

결국 Token 기반 전송 구조로 리팩토링하여,

DB에서 알림 수신 여부(receiveNotification)를 직접 관리
사용자별 unread_count 등을 메시지에 담아 맞춤 푸시 제공
발송 로그 및 통계 수집

부분이 가능해졌다.

사용자는 이제 앱 전체 알림을 끄지 않고도, 구독한 특정 공지사항에 대한 알림만 제어할 수 있으며, 구독 탭에서는 푸시 알림을 끈 상태에서도, 새 글을 확인할 수 있다.

느낀 점

이번 경험을 통해 사용자 경험(UX)을 세심히 이해하는 것과, 요구사항을 빠르게 반영할 수 있는 확장성 있는 코드 구조의 중요성을 다시금 깨달았다.

또한 기능 설계 시 상용 서비스를 벤치마킹하는 것이 큰 도움이 된다는 것도 배웠다.

키워드 알림은 당근마켓·번개장터, 공지사항별 알림 설정은 유튜브를 참고해 구현했는데, 실제 운영 서비스에서 얻은 아이디어가 프로젝트 완성도를 높이는 데 많은 역할을 했다.

아주대학교 SW중심대학 코딩 트레이너 후기 (2024-1학기 ~ 2025-1학기)

simzard — Sun, 10 Aug 2025 19:36:07 +0900

2025-2학기 코딩 트레이너 모집 공고

2024-1학기부터 2025-1학기까지, 총 3학기 동안 아주대학교 객체지향프로그래밍 및 실습(Java)강의에서 코딩 트레이너로 활동했습니다.

앞으로 이 활동을 해보고 싶은 후배들이나, 관심 있는 분들에게 도움이 되고 싶어 글을 작성하게 되었습니다.

코딩 트레이너란?

아주대학교가 2022년 SW중심대학 사업에 신규 선정되면서, 신설된 SW융합교육원에서 진행하는 활동입니다. 매 학기마다 아래 두 과목(2025-2학기 기준)에서 코딩 트레이너를 모집하고 있습니다.

컴퓨터프로그래밍 및 실습 - 주로 1학년 대상, C언어로 실습 진행
객체지향프로그래밍 및 실습 - 주로 2~3학년 대상, JAVA로 실습 진행

각 과목의 여러 강의(ex.컴프실 - F026, 컴프실 - F027)와 실습 반(ex.F026-1반, F026-2반)마다 코딩 트레이너를 모집하여 배정합니다. 두 과목 모두 1학기가 정규 과정이라서 보통 2학기는 1학기에 비해 강의 수가 적기 때문에 모집하는 코딩 트레이너 수도 적은 편입니다.

시급 13,000원!

근무 시간은 월 최대 40시간이며, 기본 20시간은 실습 준비와 참여로 채워지고(실습 시간과 휴일이 안 겹친다는 가정) 나머지 20시간은 수강생과의 튜터링을 통해 채울 수 있습니다.

모집 공고상 코딩 트레이너 역할은 다음과 같습니다.

“코딩 과목 수강에 어려움이 있거나, 코딩 과제를 완성하지 못한 학생의 코드 점검 및 해결 가이드 / 실습수업 참여 필수”

좀 더 자세하게 설명하면,

실습 준비: 매주 실습 시간 전에 조교님께 해당 주 실습 과제를 미리 받아 문제를 검토하고 풀어봅니다. 이때 실습 문제 오류를 찾거나 난이도 측면에서 피드백을 제공하기도 합니다.
실습 시간 참여: 실습 과제 수행에 어려움을 겪는 학생들에게 문제 해결을 조언해 줍니다.
튜터링(과제 코드 리뷰): 과제 제출에 실패한 학생들에게는 원할 경우 코드의 오류를 검토하고 해결 방안을 조언해 줍니다.
기타 업무: 외국인 교수님 강의의 경우 과제 번역 업무도 수행했습니다. 다른 코딩 트레이너 중에서는 시험 감독으로 들어간 경우도 있었습니다.

이외에도 교수님에 따라, 실습 시간 또는 특정 기간 내에 과제를 완료하지 못한 경우 코딩 트레이너와의 상담을 통해 실습 점수의 일부/전체를 복구할 수 있는 제도를 운영하기도 했습니다.

이런 경우 별도의 튜터링 시간을 마련해, 실습 과제를 해결하지 못한 학생들에게 피드백을 제공하고, 강의 자료를 바탕으로 이해하지 못한 개념에 대해서는 보충 설명도 진행했습니다.

코딩 트레이너를 하려고 했던 이유

2학년 2학기 무렵 백엔드 개발자로 직무를 정하고 Java와 객체지향을 계속 공부해야 하는 시점에서 코딩 트레이너 활동을 알게 되었습니다.

공부를 하는데 동기부여 측면에서, 또 최저시급을 주는 알바가 아니라 기본 시급도 13,000원 정도라 나름 꿀 알바라고 생각했습니다.

또한, 활동을 하면서 돈도 벌고 개인적으로 성장할 수 있을 거 같아 지원하게 되었습니다.

사실 시급 없이 그냥 무료 봉사였어도 신청했을 것 같다는 생각이 들 정도로 매력적인 활동이었습니다.

코딩 트레이너 꿀팁?

상담 횟수를 늘리자!

코딩 트레이너는 월 최대 40시간까지 활동할 수 있는데, 이 중 절반인 20시간은 실습 준비와 실습 시간 참여로 자연스럽게 채워집니다.

나머지 20시간은 학생들과의 튜터링 상담을 통해 채울 수 있기 때문에, 상담 횟수를 늘리는 것이 중요합니다.

학생들과의 관계 형성 - 열심히 실습실을 돌아다니자 (적극적인 자세)

저도 모르는 부분이 있어도 교수님께 잘 안 물어보는 것처럼, 학생들도 모르는 부분이 있어도 질문하는 것을 두려워하는 학생들이 많습니다.

따라서 먼저 다가가 도움이 필요한지 물어보고, “여기 구현 부분 이해하셨어요?” 같이 자연스럽게 말을 걸며, 질문을 유도하고, 수강 학생들이 코딩 트레이너에게 질문하는 것을 어렵지 않게 하는 것이 중요하다고 생각합니다.

그리고 안면을 트며 친해지는 것이 중요합니다. 편하게 코딩 트레이너에게 물어볼 수 있고 코딩 트레이너를 통해 과제 해결에 도움을 받을 수 있다는 인식을 실습실 전체에 심어주는 것이 중요한 거 같습니다.

실습을 따라가기 어려워하고, 수강에 어려움을 겪는 학생들의 경우에는 1주일에 1번 시간을 잡아서 주기적으로 튜터링을 통해 개념 복습을 위해 도움을 주는 방법도 학생에게 큰 도움을 줬던 거 같습니다.

아무래도 과개총, 소학회나 동아리에서 만난 1, 2학년 친구들이 컴퓨터프로그래밍 및 실습이나 객체지향 프로그래밍 및 실습 강의를 많이 듣다 보니, 안면이 있는 친구들이 있으면 좀 더 상담하기 쉬웠습니다.

실습 시간 튜터링 홍보

학생과의 상담 예약에 사용했던 클래스 커넥트 사이트(현재 운영 X)

첫 실습 시간에 코딩 트레이너 운영과 활용 방법에 대해 잘 설명해 주는 것이 중요합니다.

튜터링의 경우에는 https://class-connect.kr를 사용해서 진행하는데, 아무래도 처음 사용해 보면 어려울 수도 있기 때문에, 실습 끝나고 실습실에서 ClassConnect 신청을 도와주던가,

전화번호를 주고 받든 튜터링의 물꼬를 트는 것이 중요합니다.

일단 한 번 튜터링을 진행하고 나면 이후에는 계속 많이 신청했던 거 같습니다.

*2025-1학기를 마지막으로 https://class-connect.kr 서비스가 종료되었습니다. 따라서 https://whattime.co.kr/ (되는시간, 유료), 구글 워크스페이스를 활용하여 상담 예약을 하거나 아니면 첫 시간에 본인의 전화번호를 알려주거나 카카오톡 1:1 오픈채팅방을 만들어서 홍보한 다음, 조교님이나 교수님께 부탁드려 아주BB 공지사항에 올리는 것도 좋은 방법입니다.

교수님, 조교님과의 소통

또 중요한 부분이 교수님, 조교님과의 소통입니다.

코딩 트레이너를 시작하기 전에 담당 교수님, 조교님들과 회의를 하게 됩니다. 이때 실습 제출 마감 시간이나 점수 기준을 정하게 되는데, 실습 제출 시간까지 제출하지 못하거나 감점된 학생들에게 점수 복구 제도를 도입하자고 어필하는 것이 좋습니다.

학생들이 코딩 트레이너 상담을 신청할 명분이 있으면 상담을 하기 수월합니다(점수 복구는 해야 하니까).

교수님, 조교님들께서도 코딩 트레이너를 많이 배려해 주시고 적극적으로 의견을 반영하려고 하십니다. 실습 점수에 큰 변별력을 두지 않으려는 분들도 많아 괜찮은 전략?이라고 생각합니다.

실제로 점수 복구 제도가 있을 때 평균 상담 횟수가 훨씬 많았습니다.

코딩 트레이너를 하면서 느낀 점

객체지향프로그래밍및실습 4수강…

코딩 트레이너를 하면서 어떻게 보면 저는 객체지향프로그래밍 및 실습 강의를 4번 수강했다고 느낍니다.

2024-1학기부터 2025-1학기까지 3학기 동안 활동하며, 매 학기마다 제 자신이 성장하고 있다는 것을 확실히 느꼈습니다.

실습 과제를 풀고, 학생들과 튜터링을 진행하면서 매번 내용을 복습하게 되었고, 그 과정에서 객체지향 프로그래밍과 Java에 대한 이해를 더 깊게 다질 수 있었습니다.

처음 코딩 트레이너를 맡았을 땐, 마치 객체지향프로그래밍 및 실습 강의를 재수강하는 기분이었습니다.

아직 완벽히 이해하지 못한 부분도 있었고, 수강생들의 질문에 제대로 답변하지 못해 당황했던 순간도 많았습니다. 그래서 처음 한 학기는 수강생들보다 더 열심히 공부했던 시기였습니다.

실습 과제에서 나온 개념들을 정리한 글

이후에는 상담 자료를 더 꼼꼼하고 체계적으로 준비했습니다.

과제 관련해서 상담을 신청한 학생들에게는 준비한 자료를 활용해 과제의 전체적인 흐름을 설명하고, 특히 JVM 메모리 같은 부분도 설명해 주면서 학생들의 이해를 높였습니다.

이 과정에서 Java와 객체지향에 대한 이해가 점점 깊어졌고, 또한 학생들이 제출한 다양한 코드들을 분석하고 피드백을 주면서 문제를 바라보는 시야가 훨씬 넓어졌습니다.

흔히 “남들이 이해하기 쉽게 설명할 수 있다는 것이 진짜 아는 것”이라고 많이들 표현합니다.

학생들에게 설명해 주기 위해 자료를 정리하고, 어떻게 하면 내가 이해한 내용을 상대방이 이해하기 쉽게 설명할지 고민하는 과정은 개념 정리와 말하는 방식에도 큰 도움이 되었습니다.

또 튜터링을 통해 학생들과 자연스럽게 친분을 쌓을 수 있었고, 수업 외적으로도 진로나 대학생활 이야기를 나누며 네트워크를 형성할 수 있었던 점도 좋았습니다.

무엇보다 나의 성장과 함께 다른 학생들의 성장을 도울 수 있어서 큰 보람을 느낄 수 있는 의미 있는 활동이었습니다.

무조건 추천하는 활동!

3학기 동안의 코딩 트레이너 활동 참여

(추가) 2025-2학기 코딩트레이너 오리엔테이션에 내가 작성한 후기가 올라갔다.

코딩 트레이너를 고민하는 분들에게 꼭 전하고 싶은 것은, 적극적인 자세로 임한다면 본인에게도 정말 큰 도움이 될 것이라는 점입니다.

따라서 실습 시간이 맞는다면 꼭 한 번 해보시길 권하고 싶습니다.

앞서 말씀드린 것처럼, 활동비도 받고, 실력도 키우고, 학생들에게 보람까지 느낄 수 있는 기회를 놓칠 이유가 없다고 생각합니다.

저는 이번 2025-1학기를 마지막으로, 2학기에는 인턴십을 하게 되어 더 이상 코딩 트레이너 활동을 이어가진 못하지만, 주변 후배들에게는 꼭 추천하고 싶은 정말 값진 경험이었습니다.

실제로 인턴 면접에서도 이 활동에 대해 질문을 받은 적이 있었고, 면접관 분들도 매우 흥미롭게 들어주셨습니다.

코딩 트레이너 활동을 고려하고 있는 분들께 도움이 되었으면 좋겠습니다. 궁금한 점이 있으시면 언제든지 연락 주세요! (jysim0326@ajou.ac.kr)

[MySQL] URL 저장을 위한 데이터 타입 VARCHAR vs TEXT

simzard — Sun, 19 Jan 2025 20:01:59 +0900

문제 상황 - URL 길이 초과로 인한 에러 발생

[MYSQL] “Data truncation: Data too long for column”

ajouevent.com 서비스에서 학교 공지사항을 크롤링하던 중, 데이터베이스에 이미지 URL을 저장하는 과정에서 다음과 같은 에러가 발생했다.

2025/01/03 16:11:24 utils.go:156: {"timestamp":"2025-01-03T07:11:24.327+00:00","message":"could not execute statement [Data truncation: Data too long for column 'url' at row 1] [insert into club_event_image (club_event_id,url) values (?,?)]; SQL [insert into club_event_image (club_event_id,url) values (?,?)]","details":"uri=/api/webhook/crawling"}

크롤링 중 에러가 발생한 이미지 URL은 다음과 같다.

https://job.ajou.ac.kr/upload/Recruit/20250103_96001865/250103%20[%EC%A0%95%EA%B7%9C,%EA%B3%84%EC%95%BD][%EB%B8%8C%EB%A6%BF%EC%A7%95%EA%B7%B8%EB%A3%B9%EC%BD%94%EB%A6%AC%EC%95%84]%20%ED%95%B4%EC%99%B8%EC%98%81%EC%97%85%ED%8C%80(MICE)%20%EC%B1%84%EC%9A%A9%EA%B3%B5%EA%B3%A01.jpg

원인 분석

varchar(255) 타입으로 url을 저장하고 있었다.

이미지 URL의 길이가 총 276자로 VARCHAR(255)의 최대 길이를 초과했기 때문에 “Data truncation: Data too long for column ‘url’ at row1” 에러가 발생한 것이다.

해결 방안

따라서 URL 저장 시 데이터 타입과 길이를 재설정해야 했다.

이를 위해 URL 저장 방식, 데이터 타입, 그리고 URL의 길이 제한을 다시 고려했다.

URL 저장 방식

공지사항 크롤링을 통해 가져온 이미지 URL

학교 공지사항 글에 포함된 이미지는 이미 학교 서비스를 통해 URL 형태로 생성된 상태다.
- ex) https://www.ajou.ac.kr/_attach/ajou/editor-image/2024/12/lwDjcIfEGlYfXOdCCNwsPtkhVK.png
- *학교 공지사항 글을 크롤링 하고, 이미지를 따로 AWS S3, Google Cloud Storage, Firbase Storage 같은 스토리지 서비스를 통해 저장하지는 않았다. 학교 공지사항 글에 포함된 이미지는 이미 학교 서비스를 통해 URL 형태로 생성된 상태다.

https://www.ajou.ac.kr/_attach/ajou/editor-image/2024/12/lwDjcIfEGlYfXOdCCNwsPtkhVK.pngaj

ajouevent.com에서 게시글을 작성하면서 첨부하는 이미지

사용자가 ajouevent.com에서 게시글을 작성할 때, 이미지는 Presigned URL을 통해 AWS S3에 업로드된다.
업로드된 이미지는 S3의 객체 URL을 통해 조회가 가능하다.
- ex) https://{버킷이름}.s3.ap-northeast-2.amazonaws.com/img-symbol.png

DB에 이미지 URL 저장 vs 이미지 데이터 직접 저장

이미지 데이터를 직접 저장하려면 BLOB, LONGBLOB과 같은 데이터 타입을 사용해야 하지만, 이는 아래와 같은 문제를 유발한다.

데이터베이스 크기 증가: 이미지 파일이 데이터베이스의 크기를 증가시킴
데이터베이스 성능 저하: 이미지를 바이너리 데이터로 변환하여 데이터베이스에 저장하고 읽는, 이미지 읽기와 쓰기 과정에서 느려질 가능성이 높다.

→ 이미 학교 서비스를 통해 만들어진 URL, S3를 통해 만들어진 이미지 URL을 바로 MySQL DB의 column으로 저장하는 방식을 택했다.

데이터 타입 결정: CHAR vs VARCHAR vs TEXT

URL을 DB column으로 저장할 때 데이터 타입을 어떻게 할지 고민이 있었다.

CHAR vs VARCHAR

CHAR: 고정 길이 데이터(고정형) 저장에 적합.
VARCHAR: 가변 길이 데이터(가변형) 저장에 적합하며, 길이에 따라 메모리 공간을 효율적으로 사용.

→ URL의 길이는 고정되지 않는 가변 길이이므로, VARCHAR가 더 적합하다.

VARCHAR vs TEXT

VARCHAR와 TEXT의 차이에 대해서는 Real MySQL 8.0의 저자인 이성욱 당근 DBA께서 잘 설명해놓으신 글이 있다.

https://medium.com/daangn/varchar-vs-text-230a718a22a1

VARCHAR vs TEXT

개요

medium.com

요약하자면

MySQL 서버는 레코드의 컬럼 데이터를 B-Tree(Clustering Index)에 Inline으로 저장한다. 만약 레코드의 전체 크기가 InnoDB 스토리지 엔진의 최대 레코드 크기 제한(16KB 페이지에서는 8,117 바이트)을 초과하면, 길이가 긴 컬럼을 선택해서 off-Page로 저장하게 된다. (*이때, VARCHAR, TEXT 두 타입의 컬럼 모두 컬럼에 저장된 값으로 인해 최대 레코드 크기 제한을 넘어서면 off-page로 저장된다)
- → VARCHAR 컬럼에 너무 큰 길이를 사용하면, off-Page에 저장될 수 있고, 이는 성능 이슈와 직결된다.
VARCHAR 타입은 최대 크기가 설정되기 때문에, 메모리 공간을 records[2] 버퍼에 최대 크기로 미리 할당해두어 메모리를 활용한다. records[2] 메모리 버퍼에 할당되면 많은 커넥션에 의해 재사용된다. 반면에 TEXT는 실제 최대 크기만큼 메모리를 할당해두면 메모리 낭비가 너무 심해진다.
- 대신, VARCHAR 타입에 저장된 값이 길어서 off-Page로 저장된 경우 MySQL 서버는 records[2] 버퍼를 사용하지 못하고 새롭게 메모리 공간을 할당해서 사용한다. 그래서 VARCHAR 타입에 매우 큰 값이 빈번하게 저장되는 경우는 주의가 필요하다.

→ 따라서 VARCHAR에 저장되는 URL의 최대 길이를 정하고, VARCHAR 컬럼이 추가되면서 레코드의 크기가 InnoDB 스토리지 엔진의 최대 레코드 크기 제한을 넘는지 비교해야했다.

URL 길이 제한

MySQL DB의 column으로 저장되는 URL의 길이가 어느정도인지에 따라 VARCHAR를 쓸지 TEXT를 쓸지 정해진다고 판단했다.

일반적인 브라우저 지원 길이

출처: Chronium 공식 문서

출처: https://support.microsoft.com/ko-kr/topic/internet-explorer%EC%9D%98-%EC%B5%9C%EB%8C%80-url-%EA%B8%B8%EC%9D%B4%EB%8A%94-2-083%EC%9E%90%EC%9E%85%EB%8B%88%EB%8B%A4-174e7c8a-6666-f4e0-6fd6-908b53c12246

출처: https://saturncloud.io/blog/what-is-the-maximum-length-of-a-url-in-different-browsers/, 출처: https://serpstat.com/blog/how-long-should-be-the-page-url-length-for-seo/

크롬, 인터넷 익스플로러, 엣지의 경우는 2,083자 Firefox는 65,536자, Safari는 80,000자까지 허용한다.

Presigned URL 및 CDN URL

Presigned URL

AWS S3 Presigned URL, Google Cloud Storage와 같은 스토리지에서 생성되는 URL은 보안 토큰, 만료 시간, 키 경로 등을 포함하여 길이가 길어질 수 있다.
- 따라서 복잡한 쿼리 파라미터가 추가되면 더 늘어날 가능성은 있다.

기존 DB에 저장된 이미지 URL과 비교

왼쪽: DB에 저장된 이미지 URL 길이 탑10, 오른쪽: 현재 DB에 저장되어있는 이미지 URL

기존에 DB에 저장된 2016년부터의 아주대학교 공지사항의 20만 개 이미지 URL을 분석했을 때, 2025년 1월 18일 기준 가장 긴 URL의 길이는 291자다.

이미지 생성 패턴

아주대 도메인(ajou.ac.kr)
- 이미지가 아주대 도메인(ajou.ac.kr)의 다양한 하위 도메인에서 업로드 됨.
  - 아주대 공식 홈페이지 - https://www.ajou.ac.kr/_attach/ajou/editor-image/2024/12/lwDjcIfEGlYfXOdCCNwsPtkhVK.png
  - 아주대 소프트웨어학과 홈페이지 - http://software.ajou.ac.kr/smart_editor/upload/20241211161530891547026.jpg
  - 아주대 일자리센터 홈페이지 -https://job.ajou.ac.kr/upload/Recruit/20250107_40001543/250107%20[%EC%A0%95%EA%B7%9C][%EC%97%A0%EB%84%A5%EC%8A%A4]%20%EC%83%9D%EC%82%B0%EA%B4%80%EB%A6%AC,%EC%97%B0%EA%B5%AC%EA%B8%B0%ED%9A%8D%ED%8C%80%20%EC%B6%94%EC%B2%9C%EC%B1%84%EC%9A%A9.jpg
- URL 구조:
  - 저장 디렉토리
    - 대부분 /_attach/editor-image/나 /_resources/_upload_image/ 디렉토리 하위에 저장됨. 공지사항 작성 시스템에서 자동으로 지정된 경로로 업로드.
  - 파일 이름 규칙
    - 랜덤 ID 방식: 난수 조합으로 파일 이름이 자동 생성되어 중복 방지 (lwDjcIfEGlYfXOdCCNwsPtkhVK.png).
    - 제목 포함 방식: 제목이나 작성자 정보를 인코딩 (250107 [%EC%A0%95%EA%B7%9C] [%EC%97%A0%EB%84%A5%EC%8A%A4] 생...jpg).
Google Drive 링크
- 공지사항에 Google Drive에서 공유된 이미지를 포함.
  - https://ci6.googleusercontent.com/proxy/HBt0wkH6g5gZgygDhf34URNhDNIMK3OcGm76gQx8DLM8DzCHPcYpX98oNaQE_WXp8JZLimBQXKUCa32Na4wT44Mt2abONYNQbfYNz3MYVGbRCjoQB51-Uf2qRrIbvw=s0-d-e1-ft#<http://drive.google.com/uc?export=view&id=1LsA9ZoYfcBS5zRtEmo2nxtUzthBMjeAU >
- 링크에 export=view&id=<파일ID>와 같은 매개변수가 포함됨.
- 외부 클라우드 기반 스토리지를 이용하는 방식으로, 학교 서버에 이미지를 저장하지 않는 경우 사용.
외부 도메인 (sktelecom.com)
- 외부 협력업체나 제휴 프로그램(예: SK텔레콤)과 관련된 이미지.
  - https://www.raoncorp.com/data/eDM/220530/02/img/main.png
  - http://hrd.sktelecom.com/Tearning/T_earning_mail/AI_Live/001.png
- 외부 도메인의 리소스를 직접 참조.
- URL은 외부 시스템에서 관리됨.

그래서 DB column에 저장되는 URL 길이 제한은 얼마로?

따라서 URL의 길이 제한은

지금까지 저장된 아주대학교 공지사항의 이미지 URL 길이가 300자를 넘지 않았다.
외부 URL을 가져오는 경우는 드물며, 가져오더라도 길이가 짧은 편이다.
URL에 쿼리 매개변수가 과도하게 포함되거나, 이미지 데이터를 base64로 인코딩하거나, AWS S3, 구글 드라이브처럼 외부 서비스에서 생성된 링크가 길고 복잡하더라도 브라우저에서 지원하는 URL 길이 제한을 초과하는 경우는 거의 없다는 점을 고려하여

→ 점유율이 가장 높은 크롬 브라우저의 URL 길이 제한과 동일하게 2083자로 설정했다.

*그래도 추가적으로 백엔드 로직에서 URL 길이가 2,083자를 넘으면 로그를 기록하거나 에러 메시지를 반환하도록 처리했다.

결론 - VARCHAR(2083) 선택

결론적으로 VARCHAR(2083)를 선택한 이유는 아래와 같다.

이미지 url을 사용하는 이미지 테이블의 레코드가 image_id(bigint), url(VARCHAR(2083), post_id(bigint)로 설정하면 기타 오버헤드를 포함해도 2100바이트 정도로, 현재 InnoDB 스토리지 엔진의 최대 레코드 크기 제한(16KB 페이지에서는 8,117 바이트)을 넘어서지 않는다
- club_event_image 테이블에 추가적인 컬럼이 들어갈 가능성이 낮다
- 추가되더라도 VARCHAR(2083) 같은 긴 컬럼이 3개~4개 추가될 가능성이 적기 때문에, 컬럼이 추가되면서 레코드 용량을 넘어설 가능성이 적다.

CREATE TABLE club_event_image (
    image_id BIGINT AUTO_INCREMENT PRIMARY KEY, -- 8바이트
    club_event_id BIGINT NOT NULL, -- 8바이트
    url VARCHAR(2083) NOT NULL -- 최대 2083바이트 + 2바이트(길이 오버헤드)
);
image_id (8) + club_event_id (8) + url(2085) + 기타 오버헤드 <= 8117바이트

InnoDB 스토리지 엔진의 레코드 크기 제한은 페이지 크기의 약 절반. 즉 현재 DB에서 페이지 크기 = 16KB, 최대 레코드 크기 ≈ 8,117 바이트

URL의 길이는 일반적으로 2,083자를 넘지 않는다. → VARCHAR(2083)을 사용하면 “inline” 방식으로 데이터를 저장하여 효율적인 처리가 가능
- 매우 긴 URL이라고 하더라도 브라우저에서 지원하는 URL을 넘길 가능성이 적다.
게시글을 조회할 때마다 이미지 테이블을 조회하고, 항상 URL(이미지) 컬럼의 데이터가 필요하다. (자주 접근) → TEXT보다 VARCHAR가 효율적

글을 작성하며 알게 된 사실

VARCHAR라고 무조건 Inline으로 저장하고, TEXT라고 무조건 off-Page 저장 X
- InnoDB 스토리지 엔진은 레코드의 전체 크기가 제한을 초과하면 길이가 긴 컬럼을 선택해서 Off-Page로 저장하게 된다 → VARCHAR 컬럼에 저장된 값이 큰 경우에도 off-Page로 저장된다
- VARCHAR를 사용한다고 하더라도 off-Page로 넘어가면(off-page 저장소로 분리 저장되는 순간) 메모리 버퍼를 사용할 수 없기 때문에 조심해야 한다. (매번 매모리를 새로 할당 및 해제)
VARCHAR를 쓰면 실제 저장되는 데이터 크기 만큼 메모리 공간을 차지함
- ex) VARCHAR(2083) 컬럼에 “Hello”라는 5글자를 저장하면: 저장 공간 = 5(데이터) + 1(오버헤드) = 6바이트만 사용.
- 다만 TABLE 구조체의 records[2] 버퍼를 이용하는 과정에서 실제 레코드의 데이터 크기에 관계 없이 최대 크기로 메모리 할당을 해두기 때문에 VARCHAR(255)와 VARCHAR(2083)의 성능 차이가 발생한다.
VARCHAR는 index를 생성할 수 있고, TEXT는 index를 생성할 수 없다. X
- 둘 다 최대 크기 길이 제한만 충족 시키면 인덱스 생성 가능
- B-Tree 인덱스뿐만 아니라 전문 검색 인덱스도 TEXT 타입과 VARCHAR 타입 컬럼 모두 동일하게 생성할 수 있음

-- // 컬럼 그대로 사용시, 인덱스 생성 불가
mysql> ALTER TABLE tb_varchar ADD INDEX ix_fd (fd);
ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes

mysql> ALTER TABLE tb_lob ADD INDEX ix_fd (fd);
ERROR 1170 (42000): BLOB/TEXT column 'fd' used in key specification without a key length

-- // 컬럼 값의 길이(프리픽스)를 지정하면, 인덱스 생성 가능
mysql> ALTER TABLE tb_varchar ADD INDEX ix_fd ( fd(50) );
mysql> ALTER TABLE tb_lob ADD INDEX ix_fd ( fd(50) );

참고

https://medium.com/daangn/varchar-vs-text-230a718a22a1

VARCHAR vs TEXT

개요

medium.com

FCM 키워드 알림 기능 개발기 feat. FCM Topic 한글, 특수문자 사용 가능 여부

simzard — Sun, 12 Jan 2025 23:58:07 +0900

이 푸시 알림을 받기 위해 ajouevent.com 서비스를 만들었다고 해도 과언이 아니다...

현재 아주대학교 공지사항을 유튜브처럼 구독하여 푸시 알림을 받을 수 있는 https://www.ajouevent.com 서비스를 운영중이다.

아주대학교의 공지사항 ex) 아주대학교 일반, 소프트웨어학과, 경영대학, 기숙사 등등 다양한 학과/단과대/장학 공지사항을 구독할 수 있다.

추가로 장학, 공모전, 인턴, 수강신청 같은 키워드를 구독해서 키워드 푸시 알림을 받을 수 있는데,

ajouevent 서비스의 키워드 알림 기능을 개발하면서 겪은 시행착오를 이 글에 적어보려고 한다.

개발배경

키워드 알림은 https://www.ajouevent.com 서비스를 만들게 된 가장 큰 이유다.

2023년 1학기 복학 후 학교에서 일본(도쿄)을 보내준다는 해외현장연수 프로그램이 있다는 것을 알게 되었다.

겨울 방학 때 오사카, 교토를 다녀온 뒤에 도쿄를 가고 싶다는 생각이 계속 들었기 때문에 공지가 올라올 날만을 기다렸다.

여느 때와 같이 강의가 끝나고 동기들이랑 쓰리팝에서 롤을 하고 있었는데,

5인큐가 끝난 이후에 다른 친구의 카톡을 통해 선발 공지사항이 올라왔다는 걸 알게 되었다.

신청은 2인 1팀으로 나는 지석이와 같이 신청을 했다. 나와 지석이는 군대 전역 후 복학한 직후라 활동을 한 것이 없었다.

지원 신청서에도 적을만한 내용이 없어 선발 인원 중 20%를 뽑는 선착순을 노려야 했는데 이미 늦은 뒤였다.

조회수가 3700이 넘어가는, 학교에서 인기가 많은 프로그램이었다.

그리고 24년 1학기 다시 공지사항이 올라올 시기가 되었다. 이때는 사실 ajouevent를 파란학기로 개발하고 있는 시점이었지만, 아직 개발이 완성되지 않았다. 그래서 시간만 나면 소프트웨어융합대학 공지사항에 들어가 선발 공지사항이 올라왔는지 확인했다.

모집공고가 2023년과 다르게 2024년에는 좀 더 늦게 올라왔고, 나의 노가다 기간도 길어졌다.

이런 비효율적인 일을 반복하면서 키워드 알림 기능이 반드시 필요하구나라는 것을 깨달았다.

아쉬운 부분이 있으면 직접 만들어야겠다고 생각해서, 기존에 파란학기제를 같이 하기로 한 동기 2명에게 아이디어를 말했고,

2024-1학기 파란학기제 도전 과제로 제출했다.

레퍼런스

(왼쪽부터) 당근, 번개장터, 네이버카페의 키워드 알림

(왼쪽부터) 당근, 당근, 번개장터, 번개장터, 네이버카페의 키워드 구독 목록

당근, 번개장터, 네이버 카페의 키워드 알림을 참고했다.

3가지 앱 모두 자주 접속하기보다는, 내가 등록한 키워드에 해당하는 판매글이 올라오면 들어가서 확인하는데,

https://www.ajouevent.com 서비스도 사용자가 구독한 공지사항이나 키워드에 대한 알림이 올라오면 사용자들이 이를 확인하기 위해 주로 클릭(접속)하는 특성과 유사하다고 생각하여 구조를 비슷하게 가져갔다.

생각했던 방식

우선 https://www.ajouevent.com 서비스의 푸시 알림은 FCM의 Topic을 사용한다.

FCM Token과 Topic의 차이는 아래와 같다.

FCM Token

출처: https://zuminternet.github.io/FCM-PUSH/

앱이 FCM 서버와 통신하기 위해 사용되는 고유한 식별자
앱은 서버와 통신할 때 토큰을 사용하여 FCM 서버에서 앱을 식별하고, 이를 통해 메시지 전송을 할 수 있다.
FCM의 토큰은 앱이 설치된 디바이스마다 고유하다. 앱이 설치된 디바이스를 추가하거나 삭제할때 토큰이 변경될 수 있다. (refresh)
서버는 이러한 FCM 토큰을 사용하여 특정 디바이스에 메시지를 전송할 수 있다.

즉, Token은 Firebase에서 관리하는 프로젝트별 접속하는 기기의 고유 ID로 볼 수 있다.

FCM Topic

출처: https://zuminternet.github.io/FCM-PUSH/

FCM의 Topic(토픽)은 일종의 채널로서, 미리 Topic을 구독한 사용자(토큰)들에게 메시지를 전송할 수 있다.
Topic을 구독, 구독 취소 요청시에, FCM은 구독한 유저들을 내부적으로 관리한다.
FCM의 subscribe, unsubscribe 메서드를 통해 구독과 구독 취소 요청을 FCM에 전송할 수 있다.
Topic을 통해서 푸시 알림을 발송하면, Topic을 구독한 사용자들에게만 메시지를 전송할 수 있도록 한다.

*Topic 이름의 유일성

Topic 이름의 경우 유일성을 가져야하는데, 만약 유일성을 확보하지 못하면, 같은 이름의 Topic으로 인해 중복 구독 문제가 발생할 수 있다.

이를 방지하기 위해 중복되지 않는 학과/단과대의 영문 표기를 Topic 이름으로 사용하여 식별 가능하도록 했다.

공지사항마다 Topic명은 겹치지 않게 학과의 영문 표기로 설정했다

학교 공지사항마다 Topic을 두고 사용자가 Topic을 구독하면, 해당 Topic의 공지사항이 올라올 때 푸시 알림을 받을 수 있다.

기존에 학교 공지사항은 fcm에서 topic 이름으로 소프트웨어학과면 Software , 간호학과면 Nursing 으로 설정하여 사용자들이 topic을 구독할 수 있도록 했다.

학교 공지사항마다 Topic을 두고, Topic을 구독하면 해당 Topic에 대한 푸시 알림과 글을 확인할 수 있다

사용자는 구독한 Topic에 대해서 공지사항이 올라오면 알림을 받을 수 있다.

FCM Topic (키워드)

DB에서 소프트웨어학과 Topic에 등록된 키워드를 가져오고, 공지사항의 제목에 키워드가 포함되어있는지 확인하는 과정이 추가됐다

키워드 알림도 마찬가지로 Topic을 활용해서,

사용자가 구독한 키워드가 공지사항 제목에 포함된 경우, 해당 키워드와 연계된 푸시 알림을 받을 수 있는 구조를 생각했다.

이를 위해 DB에서 소프트웨어학과 Topic에 등록된 키워드를 가져온 뒤, 공지사항의 제목에 키워드가 포함되어 있는지 확인하는 과정만 추가하면 됐기 때문에 확장성 측면에서도 좋다고 판단했다.

시스템적 한계

하지만 Fcm Topic을 구독할 때 한글이 안된다는 것이 가장 큰 한계였다. “해외현장연수”, “아르바이트”. “장학”, “대회”, “프로젝트”, “공모전” 처럼 대부분의 공지사항들이 한글로 올라오고, 사용자들이 등록하는 키워드들도 한글이라 반드시 해결해야하는 문제였다.

앱 서버 전송 요청 작성 | Firebase Cloud Messaging

2024년 데모 데이에서, Firebase를 사용하여 AI 기반 앱을 빌드하고 실행하는 방법에 관한 데모를 시청하세요. 지금 시청하기 의견 보내기 앱 서버 전송 요청 작성 컬렉션을 사용해 정리하기 내 환경

firebase.google.com

“topics/[a-zA-Z0-9-_.~%]+" 정규표현식을 해석해보자면

해석

[a-zA-Z0-9-_.~%]+:
a-z: 소문자 알파벳
A-Z: 대문자 알파벳
0-9: 숫자
-: 하이픈(-)과 언더스코어()
.: 마침표
~%: 물결표(~)와 퍼센트(%)

따라서 이 표현식에 따르면 /topics/ 경로 뒤에 오는 문자열에는 +는 사용할 수 없고, 지정된 문자만 포함할 수 있다.

이외에도

토픽 이름은 유일해야합니다. 같은 이름의 토픽이 이미 존재하면 새로운 토픽을 생성할 수 없습니다.
토픽 이름은 900자를 넘길 수 없습니다.

가 있었다.

900자가 넘는 Topic 이름으로 구독할 시에 오류가 발생한다

한글은 FCM Topic으로 사용할 수 없다

가장 큰 문제는 한글을 사용할 수 없다는 점이다.

기존의 공지사항마다 구독은 공지사항별로 학과 이름을 영어로 번역하거나 공지사항 홈페이지의 이름을 따와서 Topic으로 설정했다.

예를 들어, 소프트웨어학과는 Software, 간호학과는 Nursing과 같이 Topic 이름을 부여했다.

이 방식은 새로운 학과나 단과대가 추가되더라도 해당 Topic만 추가하면 되기 때문에 큰 문제가 없었다.

공지사항마다 구별할 수 있는 Topic 이름을 영어로 부여했다

문제는 키워드였다.

키워드의 경우에는 사용자들이 주로 한글로 키워드를 등록하며, 사람마다 등록하는 키워드가 모두 다르다.

그리고 한글로 등록한 키워드를 영어로 번역해서 하기에는 현실적으로 어려웠다.

해결 방법

결국 사용자가 등록하는 키워드를 어떻게 영어로 저장할 것인가에 대한 문제를 해결해야했다.

그래서 생각한 방법이 총 3가지가 있었다.

방법1 - 한글 → 영타 변환 라이브러리 사용

그냥 한글로 입력한 키워드를 그대로 영타로 바꿔주는 방식을 생각해봤다.

예를 들어, 사용자가 “해외현장연수”를 키워드로 등록하면 이걸 그대로 영타로 바꿔서 godhlguswkddustn으로 변환하는 방식이다.

또한, 한글 쌍자음의 경우에는 영어의 대문자를 활용하면 된다. ex) “빨강색” → Qkfrkdtor

문제는 이 기능을 어떻게 구현할 것인가였는데. 다행히 이와 같은 기능을 지원하는 라이브러리를 개발한 분이 계셨다.

https://github.com/738/inko

GitHub - 738/inko: 영타를 한글로, 한타를 영어로 변환해주는 자바스크립트 오픈소스 라이브러

영타를 한글로, 한타를 영어로 변환해주는 자바스크립트 오픈소스 라이브러리. Contribute to 738/inko development by creating an account on GitHub.

github.com

영타->한타, 한타->영타 전부 다 지원하고

파이썬, 자바스크립트, 코틀린 등 다양한 곳에서 사용이 가능하다.

단점

한글과 영어를 같이 사용할 수 없다 - ex) ICT 학점연계 프로젝트
라이브러리 의존성 추가 - 특정 라이브러리에 의존하므로 추가적인 유지보수 부담이 생긴다.
가독성이 좋지 않음

방법2 - 해시값 사용

사용자가 입력한 키워드를 받아 해시 알고리즘(SHA-1, SHA-256 등)을 통해 고유값을 가지는 고정된 길이의 문자열로 변환해 관리하는 방식이다.

그리고 생성된 해시값을 FCM Topic의 식별자로 사용한다.

장점

고유성 보장: 해싱 알고리즘은 동일한 입력에 대해 항상 같은 출력을 생성하므로, 키워드 충돌 가능성이 극히 낮음.
보안성: 키워드가 해시값으로 변환되므로 원본 데이터가 외부로 노출되지 않음.
한글, 영어 혼용 지원: 원본 데이터의 언어와 무관하게 항상 동일한 방식으로 처리 가능.

문제점

가독성 저하
- 해시값은 사람이 읽을 수 있는 형태가 아니며, 원본 데이터를 직관적으로 알 수 없음.
- 예를 들어, “해외현장연수”가 e89f29d...로 변환되면 해당 키워드가 무엇을 의미하는지 알 수 없음.
추가 연산 비용
- 해시값 생성에는 알고리즘에 따라 추가적인 연산이 필요하며, 많은 키워드를 한 번에 처리할 경우 연산 부담이 커질 수 있음.
- 특히 SHA-256이나 SHA-512 같은 복잡한 알고리즘은 연산량이 많음.
복원 불가능
- 해시값은 일방향 암호화로, 원본 데이터를 복원할 수 없음. 원본 키워드가 필요한 경우, 별도의 데이터베이스에 키워드와 해시값을 매핑해 저장해야 함.
- 이로 인해 저장소 관리 및 추가 연산이 필요함.

키워드 원본 데이터의 암호화가 딱히 중요하지 않고,

키워드를 구독할 때 공지사항을 지정한다는 점, 중복이 되더라도 상관이 없다는 점 때문에 해시값 사용은 고려하지 않았다.

방법3 - URL 인코딩 사용

키워드를 URL-safe 방식으로 인코딩해 ASCII 문자열로 변환하는 방식이다

ex) “해외현장연수” → %ED%95%B4%EC%99%B8%ED%98%84%EC%9E%A5%EC%97%B0%EC%88%98

장점

간단한 구현 - 한글을 한글을 인코딩하여 ASCII 문자로 변환하므로 별도 라이브러리가 없어도 구현 가능.
한글과 영어 같이 사용 가능
가독성 유지 가능: 인코딩 전후가 유사하게 보여 사람이 직관적으로 이해 가능.

단점

길이 증가: 한글 문자 하나가 %ED%95%9C처럼 길게 변환되므로 결과 문자열의 길이가 길어짐.
- → 인코딩된 결과가 너무 길면 FCM 주제 제한(최대 900자)을 초과할 가능성이 있음.
복원 필요: 원본 데이터를 다시 사용할 때 디코딩 과정이 필요.
충돌 가능성

키워드의 길이는 키워드를 구독할 때 글자수를 제한을 두면 된다.

원본 데이터에 대해서는 따로 DB에 해외현장연수라는 키워드와 Topic용으로 인코딩한 키워드인 %ED%95%B4%EC%99%B8%ED%98%84%EC%9E%A5%EC%97%B0%EC%88%98_ComputingInformatics를

저장해 복원에 대해서는 문제가 없다.

충돌 가능성에 대해서는 아래에서도 설명하지만, 키워드 알림을 받을 공지사항을 지정해서(ex. 소프트웨어학과) Topic의 명칭이 유일성을 가지도록 했다.

1차 채택: 방법1 - 한글 → 영타 변환 라이브러리 사용

사실 처음에는 한글 -> 영타 변환 라이브러리를 활용하는 방식을 선택했고, 이를 적용하고 배포까지 완료했다.

그러나 이후에 URL 인코딩을 사용하면 된다는 사실을 뒤늦게 알았다.

왜냐하면 Fcm Topic을 다루는 대부분의 블로그에서 Topic의 이름에 특수문자를 사용할 수 없다고 언급했기 때문이다.

이로 인해 %가 포함되는 URL 인코딩 방식은 배제하고 생각했다.

(특수문자를 못 쓰는줄 알고 한글 -> 영타 변환 라이브러리를 사용할 때도 키워드마다 Topic을 구별하기 위해 특수문자 대신 숫자 8을 써서(ex. 장학 - wkdgkr8Software) 공백을 대체했다...)

이번 경험을 통해 공식 문서를 꼼꼼히 확인하는 것이 얼마나 중요한지, 테스트를 직접 해봐야한다는 점,

그리고 블로그 글을 무조건 신뢰해서는 안된다는 교훈을 얻었다.

나도 블로그 글을 작성하면서 잘못된 정보를 주지 않기 위해 최대한 검토를 잘해야겠다는 생각이 들었다.

한글 → 영타, 한글 → 영타 변환 라이브러리라서 한글과 영어가 섞인 키워드는 구독하지 못했다.

최종 채택: URL 인코딩 사용

FCM 공식 문서에서 나와있는 topic 정규 표현식

추후에 FCM 공식문서를 다시 읽으며 FCM topic의 정규식을 찾을 수 있었고, 결국 URL 인코딩 방식으로 다시 리팩토링을 했다.

이 글을 작성하면서 다시 한 번 테스트를 해보았다.

실제로 정규식에 따라 topic에 특수문자(%, _)를 넣어도 구독이 되었고, 정상적으로 알림을 받을 수 있었다.

특수문자 %, _가 들어간 Topic이 정상적으로 구독이 된다

키워드 Topic 이름 중복 관련

예를 들어 “공모전”이라는 키워드를 소프트웨어학과 학생은 소프트웨어학과 공지사항에 올라오는 “공모전” 키워드만 받고 싶을 것이다.

건축학과의 “공모전” 키워드 알림은 받고 싶지 않을 것이다.

만약, 그냥 키워드로 공모전을 등록한다면 모든 종류의 공지사항에 공모전이 들어갈 때마다 푸시 알림을 받게 된다.

따라서 FCM Topic으로 구독할 때, 단순히 공모전 → %EA%B3%B5%EB%AA%A8%EC%A0%84 으로 인코딩해서 등록하는게 아니라,

뒤에 %EA%B3%B5%EB%AA%A8%EC%A0%84_Software 식으로 키워드 알림을 받는 공지사항 종류(Topic)를 덧붙힌 뒤 Topic을 등록해서 구분을 지었다. 대신 사용자가 키워드를 등록할 때, 어느 공지사항의 키워드를 등록할지는 정해줘야 한다.

사용자는 어느 공지사항의 키워드 알림을 받을지 선택해야한다.

프론트에서 백엔드로 구독 요청

{
	"koreanKeyword": "장학",  // 알림을 받을 키워드
	"topicName": "Software" // 알림을 받을 키워드의 공지사항 종류 Topic
}

프론트에서 백엔드로 구독 취소 요청

{
	"encodedKeyword": "%EC%9E%A5%ED%95%99_Software" // Topic으로 등록된 키워드
}

또한 키워드 정보를 DB에 등록할 때 어느 공지사항의 키워드인지 같이 매핑을 해준다

keyword 테이블에 Topic을 같이 매핑한다

그리고 공지사항을 크롤링하면 해당 공지사항 (ex. Software)에 등록된 키워드(ex. 공모전, 해외현장연수, 장학, 자격증)를 가져와서,

공지사항 제목에 키워드가 포함되어있는지 확인 후에 해당 키워드를 Topic으로 하여 FCM 푸시 알림을 요청한다.

예시 로직

사용자가 소프트웨어학과 공지사항의 해외현장연수 키워드를 구독
- → DB에 키워드를 알림 받는 공지사항(Topic, 예시에서는 Software)과 키워드인 해외현장연수, 검색용 키워드인 해외현장연수_Software, Topic 등록용 인코딩 키워드인 %ED%95%B4%EC%99%B8%ED%98%84%EC%9E%A5%EC%97%B0%EC%88%98_Software를 저장 후 인코딩 키워드 이름으로 Topic을 구독
소프트웨어학과 공지사항이 올라오고 크롤링을 함 - 이때 제목은 2024-하계 소프트웨어융합대학 IP-IT해외현장연수 모집 공고
소프트웨어학과 Topic에 등록된 키워드 확인(ex. 장학, 실전코딩, 해외현장연수.. 등등)
해외현장연수 키워드가 등록되어있으므로, 해당 키워드를 구독하는 사용자들에게 푸시 알림
FCM 메시지를 구성할 때 Topic에 %ED%95%B4%EC%99%B8%ED%98%84%EC%9E%A5%EC%97%B0%EC%88%98_Software 를 지정

// FCM 푸시 알림 메시지 구성
private Message createFcmMessage(String topic, String messageTitle, String body,
    String imageUrl, String url) {
    return Message.builder()
        .setTopic(topic)
        .setNotification(Notification.builder()
            .setTitle(messageTitle)
            .setBody(body)
            .setImage(imageUrl)
            .build())
        .putData("click_action", url)
        .build();
}

*인코딩시 유의사항

공백 문자 +, %20

URL 인코딩을 보면 보통 공백을 + 또는 %20로 표현한다.

스프링-자바에서 인코딩을 할때 공백이 +가 되는경우가 있는데,

“동계 현장실습”을 키워드로 구독할 때 java.net.URLEncoder 라이브러리를 import하여 .encode()를 사용했다. 인코딩 직후에 공백은 “+”로 치환된다

위의 정규식 topics/[a-zA-Z0-9-_.~%]+에서 볼 수 있듯이 +는 topic이름으로 쓸 수 없다.

따라서 encodedKeyword = encodedKeyword.replace("+", "%20"); 이런식으로 공백을 +가 아닌 %20로 대체해야한다.

공백을 +로 인코딩해서 구독 요청을 하면 구독이 되지 않는다

공백을 인코딩 할 때 +가 아닌 %20로 대체하는 부분을 추가한다.

코드

키워드 푸시 알림 발송

// FCM 메시지 생성 - topic
Message message = createFcmMessage(topicName, messageTitle, body, imageUrl, url);
send(message);

// 공지사항에 해당하는 토픽 찾기
Topic topic = topicRepository.findByDepartment(topicName)
    .orElseThrow(() -> new CustomException(CustomErrorCode.TOPIC_NOT_FOUND));

// 공지사항에 해당하는 토픽을 구독 중인 모든 키워드 찾기
List<Keyword> keywords = keywordRepository.findByTopic(topic);

for (Keyword keyword : keywords) {
    String koreanKeyword = keyword.getKoreanKeyword();

    // 공지사항의 제목이나 본문에 키워드가 포함되어 있는지 확인
    if (noticeDto.getTitle().contains(koreanKeyword)) {
        messageTitle = koreanKeyword + "-" + messageTitle;
        String encodedKeyword = keyword.getEncodedKeyword();
        
        // FCM 메시지 생성 - keyword
        Message keywordMessage = createFcmMessage(encodedKeyword, messageTitle, body, imageUrl, url);
        
        // 비동기적으로 알림 전송
        send(keywordMessage);
    }
}

키워드 구독

// 키워드 구독 - 키워드 하나씩
// KeywordRequest 예시
// 소프트웨어학과(topicName) 공지사항의 
// 해외현장연수(koreanKeyword) 키워드 구독
@Transactional
public void subscribeToKeyword(KeywordRequest keywordRequest) { 

	// URL 인코딩과 Topic ID 결합하여 고유한 formattedKeyword 생성
	String encodedKeyword = URLEncoder.encode(koreanKeyword, StandardCharsets.UTF_8);
	String searchKeyword = koreanKeyword + "_" + topicName;
	encodedKeyword = encodedKeyword.replace("+", "%20"); // 인코딩시 공백을 +로 하는 경우를 %로 대체
	String formattedKeyword = encodedKeyword + "_" + topicName;

	Topic topic = topicRepository.findByDepartment(topicName)
		.orElseThrow(() -> new CustomException(CustomErrorCode.TOPIC_NOT_FOUND));

	// 입력된 키워드가 존재하는지 확인하고, 없다면 새로 생성
	Keyword keyword = keywordRepository.findByEncodedKeyword(formattedKeyword)
		.orElseGet(() -> createNewTopic(keywordRequest, searchKeyword, formattedKeyword, topic));

	// 이미 해당 키워드를 구독 중인지 확인
	if (keywordMemberRepository.existsByKeywordAndMember(keyword, member)) {
		throw new CustomException(CustomErrorCode.ALREADY_SUBSCRIBED_KEYWORD);
	}

	// 사용자가 이미 구독한 키워드 개수를 확인
	long subscribedKeywordCount = keywordMemberRepository.countByMember(member);
	if (subscribedKeywordCount >= 10) {
		throw new CustomException(CustomErrorCode.MAX_KEYWORD_LIMIT_EXCEEDED);
	}

	List<Token> memberTokens = member.getTokens();
	KeywordMember keywordMember = KeywordMember.builder()
		.keyword(keyword)
		.member(member)
		.isRead(false)
		.lastReadAt(LocalDateTime.now())
		.build();
	keywordMemberRepository.save(keywordMember);

	// 토픽과 토큰을 매핑하여 저장 -> 사용자가 가지고 있는 토큰들이 topic을 구독
	List<KeywordToken> keywordTokens = memberTokens.stream()
		.map(token -> new KeywordToken(keyword, token))
		.collect(Collectors.toList());
	keywordTokenBulkRepository.saveAll(keywordTokens);

	// FCM 서비스를 사용하여 토픽에 대한 구독 진행
	List<String> tokenValues = memberTokens.stream()
		.map(Token::getTokenValue)
		.collect(Collectors.toList());
	fcmService.subscribeToTopic(formattedKeyword, tokenValues);
}

// 새로운 키워드 생성 메서드
private Keyword createNewTopic(KeywordRequest keywordRequest, String searchKeyword, String formattedKeyword, Topic topic) {
	// 새로운 토픽 생성 로직
	Keyword newKeyword = Keyword.builder()
		.encodedKeyword(formattedKeyword)
		.koreanKeyword(keywordRequest.getKoreanKeyword())
		.searchKeyword(searchKeyword)
		.topic(topic)
		.build();
	keywordRepository.save(newKeyword);

	keywordLogger.log("새로운 키워드 생성 : " + newKeyword.getKoreanKeyword());
	return newKeyword;
}

FcmService.java

public void subscribeToTopic(String topicName, List<String> tokens) {
	try {
		TopicManagementResponse response = FirebaseMessaging.getInstance().subscribeToTopicAsync(tokens, topicName).get();
		topicLogger.log("Subscribed to topic: " + topicName);
		topicLogger.log(response.getSuccessCount() + " tokens were subscribed successfully");
		if (response.getFailureCount() > 0) {
			topicLogger.log(response.getFailureCount() + " tokens failed to subscribe");
			response.getErrors().forEach(error -> {
				String failedToken = tokens.get(error.getIndex());
				topicLogger.log("Error for token at index " + error.getIndex() + ": " + error.getReason() + " (Token: " + failedToken + ")");
			});
		}
	} catch (InterruptedException | ExecutionException e) {
		// 구독에 실패한 경우에 대한 처리
		throw new CustomException(CustomErrorCode.SUBSCRIBE_FAILED);
	}
}

키워드 구독 취소

// 키워드 구독 취소 - 키워드 하나씩
@Transactional
public void unsubscribeFromKeyword(UnsubscribeKeywordRequest unsubscribeKeywordRequest) {
	String memberEmail = SecurityContextHolder.getContext().getAuthentication().getName();
	String encodedKeyword = unsubscribeKeywordRequest.getEncodedKeyword();

	Member member = memberRepository.findByEmailWithTokens(memberEmail)
		.orElseThrow(() -> new CustomException(CustomErrorCode.USER_NOT_FOUND));

	Keyword keyword = keywordRepository.findByEncodedKeyword(encodedKeyword)
		.orElseThrow(() -> new CustomException(CustomErrorCode.KEYWORD_NOT_FOUND));

	// 유저가 설정한 키워드를 찾아서 삭제
	keywordMemberRepository.deleteByKeywordAndMember(keyword, member);

	// 해당 키워드에 관련된 토큰을 찾아서 삭제
	List<Token> memberTokens = member.getTokens();
	keywordTokenRepository.deleteByKeywordAndTokens(keyword, memberTokens);

	// FCM 서비스를 사용하여 키워드에 대한 구독 취소 진행
	List<String> tokenValues = memberTokens.stream()
		.map(Token::getTokenValue)
		.collect(Collectors.toList());
	fcmService.unsubscribeFromTopic(encodedKeyword, tokenValues);
	keywordLogger.log("키워드 구독 취소 : " + keyword.getKoreanKeyword());
}

FcmService.java

public void unsubscribeFromTopic(String topicName, List<String> tokens) {
	try {
		TopicManagementResponse response = FirebaseMessaging.getInstance().unsubscribeFromTopicAsync(tokens, topicName).get();
		topicLogger.log("Unsubscribed to topic: " + topicName);
		topicLogger.log(response.getSuccessCount() + " tokens were unsubscribed successfully");
		if (response.getFailureCount() > 0) {
			topicLogger.log(response.getFailureCount() + " tokens failed to unsubscribe");
			response.getErrors().forEach(error -> {
				String failedToken = tokens.get(error.getIndex());
				topicLogger.log("Error for token at index " + error.getIndex() + ": " + error.getReason() + " (Token: " + failedToken + ")");
			});
		}
	} catch (InterruptedException | ExecutionException e) {
		// 구독 해지에 실패한 경우에 대한 처리
		throw new CustomException(CustomErrorCode.SUBSCRIBE_CANCEL_FAILED);
	}
}

아직 남은 개선점

현재 공지사항을 크롤링할 때 키워드 알림의 로직은

사전에 사용자가 소프트웨어학과 공지사항의 해외연장연수 키워드를 구독
학교 소프트웨어학과 홈페이지 공지사항에 새로운 글이 올라옴 - 이때 제목은 2024-하계 소프트웨어융합대학 IP-IT해외현장연수 모집 공고
크롤링 서버에서 새로운 글이 올라왔다는 사실을 알고, 소프트웨어학과 공지사항 글을 크롤링 함
해당 소프트웨어학과 공지사항(Topic)을 구독하고 있는 사용자에게 푸시 알림
소프트웨어학과 공지사항(Topic)에 등록된 키워드 확인(ex. 장학, 실전코딩, 해외현장연수.. 등등)
공지사항의 제목에 키워드가 포함되어있는지 확인
포함되어있다면 해당 키워드를 구독하는 사용자에게 푸시 알림
- → 해외현장연수 키워드가 등록되어있으므로, 해당 키워드를 구독하는 사용자들에게 푸시 알림

구조다.

위의 5, 6, 7 과정에서 특정 공지사항에 키워드가 많이 구독되어있을 수록,

공지사항의 제목에 키워드가 포함되어있는지 확인하는 로직과 푸시 알림을 보내주는 과정에서 로직이 오래 걸린다. 이 부분에 대해서 개선이 필요하다.

또한 지금은 Topic으로 푸시 알림을 보내는 방식이라 전송 시간이 덜 걸리지만,

추후 푸시 알림 모니터링으로 인해 Token 방식으로 전환 한다면(특정 토큰에 대한 푸시 알림 성공/실패 확인을 하려면 Token 방식으로 해야한다)

성능 개선이 더욱 필요해진다.

후기

키워드 푸시 알림, 키워드 구독 화면, 구독한 키워드 관련 글 모음 탭

후배, 동기들의 키워드 알림 기능 후기

정상적으로 키워드 알림 기능이 작동하는 것을 확인할 수 있었고, ajouevent.com의 키워드 알림 기능을 통해

동기와 후배들이 유용하게 활용했다는 말을 듣고 큰 보람을 느꼈다.

나 또한 키워드 알림 기능 덕분에 학교에서 지원하는 클라이밍 클래스(선착순)와 면접 스태프를 빠르게 신청할 수 있었다.

에브리타임의 키워드 알림 기능

특히, ajouevent.com에서 키워드 알림 기능을 개발한 뒤, 에브리타임에도 비슷한 키워드 알림 기능이 도입된 것을 보고 흥미로웠다. 에브리타임의 키워드 알림은 어떻게 개발되었는지 궁금하며, 에브리타임을 개발하는 VINU팀 개발 블로그가 있는걸로 아는데 빨리 관련 글이 올라왔으면 좋겠다.

결론

FCM에서 한글 토픽(topic)을 사용하고 싶으면 인코딩을 해서 쓰자. FCM topic 이름으로 +를 쓸 수 없으니 인코딩을 할때 공백은 + 가 아닌 %20 로 replaceAll()을 해줘야한다.
현재 FCM topic 이름에 적용되는 정규식은 다음과 같다 (24년 12월 기준) (이것도 바뀔 수도 있으니 직접 테스트해보자)
- [a-zA-Z0-9-_.~%]+
FCM 공식 문서를 참고하자(영어 문서를 참고하는게 좋다)

FirebaseMessaging

firebase.google.com

Firebase 클라우드 메시징 | Firebase Cloud Messaging

Firebase Cloud Messaging

Firebase 클라우드 메시징(FCM)은 무료로 메시지를 안정적으로 전송할 수 있는 크로스 플랫폼 메시징 솔루션입니다.

firebase.google.com

앱 서버 전송 요청 작성 | Firebase Cloud Messaging

firebase.google.com

그림 출처

https://zuminternet.github.io/FCM-PUSH/

FCM 푸시 파헤치기

파일럿부터 적용까지 진행했던 FCM 푸시를 파헤치며 기초 가이드북처럼 정리해보았습니다.

zuminternet.github.io

ajouevent.com 소개 - 아주대 공지사항 및 이벤트 알림 웹앱(PWA, FCM)

simzard — Sun, 5 Jan 2025 16:11:06 +0900

서비스 소개

2024년 1학기부터 2학기까지 개발한 서비스를 소개하려고 합니다!

아주대학교 공지사항을 유튜브처럼 구독할 수 있는 서비스인데요,

핵심 기능은 학교 공지사항과 키워드를 구독해서 푸시 알림을 받을 수 있습니다.

일반, 장학/학과/단과대/기숙사 공지사항 푸시 알림을 제공해주는 것 외에도

이벤트 배너, 이번주 인기글, 찜하기, 구독한 공지사항&키워드 글 확인, 구글 캘린더 연동을 도입해서

최대한 사용자들이 교내 공지사항이나 이벤트들을 놓치지 않도록 제작했습니다.

거두절미하고, 사이트 링크와 서비스 화면을 보여드리겠습니다.

(아래 설명부터는 편의상 반말로 작성하겠습니다... ㅎㅎ)

https://ajouevent.com

아주대학교 이벤트 알림 웹앱

팀 이쿠죠

www.ajouevent.com

아이폰에서 받은 ajouevent.com의 푸시 알림

푸시 알림

(왼쪽부터) 아이폰, 갤럭시, 맥북, 윈도우 노트북에서의 푸시 알림 화면

(왼쪽부터) 구독 탭, 구독 설정 창, 키워드 탭, 키워드 설정 창

홈화면, 검색, 찜하기

(왼쪽부터) 홈, 검색, 찜

상세페이지 & 바로가기 & 구글 캘린더 연동

(왼쪽부터) 게시글 상세페이지, 바로가기 클릭시 기존 공지사항 이동, 캘린더에 추가 버튼 클릭 시 구글 캘린더 연동

설치

(왼쪽부터) 안드로이드, 아이폰, 노트북에서의 설치 안내 화면 (PWA 기반)

아이폰, 갤럭시, 맥북, 윈도우 노트북 모두 설치가 가능하다

구글 로그인

개발 배경

기존에 학교 공지사항을 올려주는 오픈채팅방이 있었고, 이미 많은 분들이 사용을 하고 계시지만

일반 공지사항만 제공하는 점,

학과, 단과대, 기숙사 등의 공지사항은 제공해주지 않아 아쉬움이 있었다.

또한 카카오톡 오픈채팅방의 참가 인원수는 1500명으로 제한되어 있다.

그리고 카카오톡은 주로 메신저로 사용하는 만큼, 학교 공지사항을 따로 알림 받을 수 있는 앱이 있으면 좋겠다는 생각이 들었다.

무엇보다 키워드 알림이 https://www.ajouevent.com 서비스를 만들게 된 가장 큰 이유다.

2023년 1학기 복학 후 학교에서 일본(도쿄)을 보내준다는 해외현장연수 프로그램이 있다는 것을 알게 되었다.

겨울 방학 때 오사카, 교토를 다녀온 뒤에 도쿄를 가고 싶다는 생각이 계속 들었기 때문에 공지가 올라올 날만을 기다렸다.

여느 때와 같이 강의가 끝나고 동기들이랑 쓰리팝에서 롤을 하고 있었는데,

5인큐가 끝난 이후에 다른 친구의 카톡을 통해 선발 공지사항이 올라왔다는 걸 알게 되었다.

신청은 2인 1팀으로 나는 지석이와 같이 신청을 했다. 나와 지석이는 군대 전역 후 복학한 직후라 활동을 한 것이 없었다.

지원 신청서에도 적을만한 내용이 없어 선발 인원 중 20%를 뽑는 선착순을 노려야 했는데 이미 늦은 뒤였다.

조회수가 3700이 넘어가는, 학교에서 인기가 많은 프로그램이었다.

그리고 24년 1학기 다시 공지사항이 올라올 시기가 되었다.

이때는 사실 ajouevent를 파란학기로 개발하고 있는 시점이었지만, 아직 개발이 완성되지 않았다.

그래서 시간만 나면 소프트웨어융합대학 공지사항에 들어가 선발 공지사항이 올라왔는지 확인했다.

모집공고가 2023년과 다르게 2024년에는 좀 더 늦게 올라왔고, 나의 노가다 기간도 길어졌다.

이런 비효율적인 일을 반복하면서 키워드 알림 기능이 반드시 필요하구나라는 것을 깨달았다.

아쉬운 부분이 있으면 직접 만들어야겠다고 생각해서, 기존에 파란학기제를 같이 하기로 한 동기 2명에게 아이디어를 말했고,

2024-1학기 파란학기제 도전 과제로 제출했다.

알림 수단에 대한 고민

크롤링 부분은 이전에 장원이형이 GO로 만들어놓은 크롤링 프로그램을 물려받았다.

처음 장원이형이 만든 공지사항 크롤링 프로그램은 공지사항을 슬랙 채널로 올려서 알림을 띄우는 방식이었다.

아무래도 슬랙에 익숙하지않은 사람도 많았고, 설치부터 사용까지 다소 러닝커브가 있었다.

그래서 ajouevent.com 을 개발할 때는 사용자들에게 익숙한 수단으로 알림을 제공하고자했다.

아주대 장원영이 개발한 아주대 공지사항 알리미 by Slack

후보에는 카카오톡, 텔레그램, 디스코드, 메일, PWA(Progressive Web App)+FCM(Firebase Cloud Messaging)이 있었다.

카카오톡은 이미 공지사항 오픈채팅방이 있었고, 비즈니스 채널로 하기엔 사업자 등록번호가 있어야 해서 제외했다.

텔레그램/디스코드는 사용자들이 익숙하지 않다고 판단하여 제외했다.

메일의 경우에는 사용자 수가 1000명, 2000명이 커질수록 메일 전송에 제약이 생길 수 있다는 문제가 있었다.

최종적으로 PWA+FCM 조합을 선택했다.

PWA를 통해 사용자들이 앱처럼 쓸 수 있고, 브라우저 기반으로 동작해 다양한 플랫폼에서 접근성을 높일 수 있다는 장점이 있다.

또한 PWA는 푸시 알림을 지원하고, 서비스 워커(Service Worker)를 통해 오프라인 상태에서도 알림을 처리할 수 있다.

다만, 사용자가 브라우저에서 ‘홈화면에 추가’를 통해 설치 과정을 거쳐야 하므로 이 점이 생소할 수 있는데,

설치 가이드를 명확히 제공하고 노트북과 갤럭시에서는 클릭을 통한 설치 팝업, iOS에서는 '홈화면에 추가' 방식을 설명하는 팝업을 통해 보완하고자 했다.

(왼쪽부터) 안드로이드, 아이폰, 노트북에서의 설치 안내 화면 (PWA 기반)

푸시 알림 방식으로 FCM(Firebase Cloud Messaging)을 선택한 이유

푸시 알림을 구현하는 방법으로는 주로 SSE(Server-Sent-Events)와 FCM(Firebase Cloud Messaging)을 사용하는 방식이 있다.

SSE(Server-Sent-Events)

일반적인 HTTP 통신에서는 클라이언트가 서버에 요청을 보내야만 서버가 응답을 보낼 수 있다. 그러나 푸시 알림 시스템에서는, 클라이언트의 요청이 없이도 공지사항이 등록되면 서버에서 클라이언트로 즉시 알림을 보내야 한다.

SSE는 서버에서 클라이언트로 데이터를 실시간으로 전송하는 기술이다. 일반적으로 HTTP 연결을 유지하며, 서버가 새로운 데이터를 생성할 때마다 클라이언트로 전송할 수 있다.

단점으로, 모바일 기기에서는 브라우저가 백그라운드로 전환되거나 클라이언트가 애플리케이션을 닫으면 알림을 수신할 수 없다. 또한 서버와 지속적으로 연결을 유지해야 하므로 네트워크 비용이 증가한다.

FCM(Firebase Cloud Messaging)

FCM은 교차 플랫폼 메시징 솔루션으로

Web, iOS, Android 등의 특정 플랫폼에 종속되지 않고 메시지를 전송할 수 있다.

애플리케이션 서버가 아니라 클라우드 메시징 서버가 메시지 전송의 역할을 담한다. 따라서 애플리케이션이 계속 실행 중일 필요 없이 낮은 배터리 소모와 네트워크 사용만으로도 실시간 메시지 송수신이 가능하다.

그래서 FCM을 이용하면 사용자가 앱을 실행하고 있지 않을 때에도 푸시 알림을 받을 수 있다.

물론 FCM 서버에 의존하기 때문에, FCM 서버 상태에 따라 지연이나 장애가 발생할 수 있는건 단점이다. SSE의 실시간성에 비해서도 느린 편이다.

우리 서비스는 웹 브라우저 뿐만 아니라, iOS, Android 등 모바일 기기까지 다양한 기기에서 사용될 것을 고려하여, 많은 플랫폼을 수용할 수 있는 FCM을 선택했다.

특히, 주로 모바일 기기에서 푸시 알림을 확인한다고 생각하여 배터리를 크게 소모하지 않으면서, PWA가 실행 중이지 않더라도 알림을 받을 수 있는 FCM이 적합하다고 판단했다.

FCM은 무료로 제공된다

FCM에서 제공하는 여러 기능들도 활용했다.

Topic 기능을 활용해 학교 공지사항이나 사용자 맞춤형 키워드마다 별도의 Topic을 생성했다.

FCM에서 발급하는 Token을 활용해 사용자 1명이 여러 개의 토큰을 가질 수 있도록 하여 여러 기기에서 푸시 알림을 받을 수 있도록 했다.

아키텍처

인프라는 비용 최적화를 중점으로 설계했다. AWS 프리티어를 최대한 활용한 아키텍처다.

VPC와 서브넷 구축, 백엔드 CI/CD 파이프라인 구성은 영준이 형과 함께했다. 서비스로 아키텍처까지 그려줬는데 너무 마음에 든다.

템플릿도 받았는데 앞으로 요긴하게 활용할 예정이다.

Fronted CI/CD pipeline

프론트엔드 배포에서도 Vercel 무료 플랜을 최대한 활용했다.

GitHub Organization의 레포지토리를 Vercel에 배포하려면 유료 플랜인 Team Plan을 써야 한다.

비용 절감을 위해 팀 레포지토리를 나의 개인 레포지토리로 fork(public) 한 뒤, Vercel에 배포하는 방식을 선택했다.

단, 이 방식은 팀 레포지토리와 개인 레포지토리 간의 싱크가 맞지 않는 문제가 발생할 수 있다.

이를 위해 Github Actions를 설정해서 팀 레포지토리의 main 브랜치에 commit이나 push가 발생하면,

자동으로 개인 레포지토리로 변경 사항을 push 하도록 구현했다.

prod와 dev 환경을 나누기 위해 Vercel의 브랜치별 배포 기능도 활용하여 dev 브랜치에도 Github Actions을 적용했다

React+PWA를 선택한 이유

파란학기제를 함께하는 석찬이가 아무래도 React를 주로 개발해 왔기 때문에 React Native, Flutter나 Swift, 코틀린을 새로 배우기에는 러닝 커브가 크고 무리라고 판단했다.

대신 React + PWA(Progressive Web Application) 조합을 채택해서 앱 형태로 제공할 수 있도록 하여 사용자 경험을 향상하기로 했다.

특히, PWA는 브라우저 기반으로 작동하면서도 네이티브 앱과 유사한 UX를 제공하며, 알림 기능까지 구현할 수 있었다.

또한, iOS의 경우, 기존에는 웹 푸시 알림 기능을 지원하지 않았지만, iOS 16.4 버전부터 웹 푸시 알림 기능을 지원하게 되었고, 이 점이 PWA 선택에 큰 영향을 주었다.

iOS는 Safari 16.4 버전부터 PWA에서 푸시 알림을 지원한다

Safari 16.4 Release Notes | Apple Developer Documentation

Released March 27, 2023 — Version 16.4 (18615.1.26)

developer.apple.com

Sending web push notifications in web apps and browsers | Apple Developer Documentation

Update your web server and website to send push notifications that work in Safari, other browsers, and web apps, following cross-browser standards.

developer.apple.com

그러다 개강하기 전 2024년 2월, iOS 17.4 버전부터 PWA 지원을 중단한다는 애플의 발표를 듣고 심장이 철렁했다.

iOS 17.4 Update Ends PWA Support in the European Union

In the latest iOS 17.4 beta update, Apple made a significant move by disabling the functionality of...

dev.to

하지만 유럽에서 보이콧이라는 강수를 둔 바람에 지원 철회를 철회했고(?) 무사히 프로젝트를 진행할 수 있었다.

Update on apps distributed in the European Union - Support - Apple Developer

Update on apps distributed in the European Union

developer.apple.com

스프링을 선택한 이유

파란학기제를 같이하는 나와 은정이 둘 다 스프링을 주력으로 개발했기 때문에 스프링 + JPA를 선택했다. 개발한 뒤에 이유를 덧붙이자면, 위의 아키텍처에서 볼 수 있듯이 스프링이 크롤링 서버가 보낸 공지사항을 특정 API로 받는 역할도 하고, 일반 API 서버로서의 역할도 하고, FCM으로 푸시 요청도 해주는 여러 가지 역할을 수행한다.

따라서 이렇게 여러 역할을 수행하고, 크롤링한 공지사항을 받아서, DB에 저장하고, FCM에 푸시 알림 요청까지 하는 과정이, 동시에 일어나는 경우도 있기 때문에 멀티스레드로 다루는 것이 적합하다고 생각했다.

나중에는 이를 분리할 계획이지만, 단일 서버로 다루기에는 스프링이 적합하다고 생각했다.

현황

2024년 6월 파란학기제 성과 발표제에서 배포한 이후로 지금까지 계속해서 운영 중이다.

가입자 수는 2024년 12월 18일 기준 240명이며, 단과대 축제 부스 이후에 MAU가 170명은 찍힌다.

실제 사용자가 있으니까 더 잘 운영하고 싶고, 리팩토링 할 욕심이 생긴다.

Google Analytics

앞으로의 계획

서버비 충당: 현재 월 3만원 정도의 AWS 서버비가 나가는데(prod + dev) 이 돈을 충당할 방법을 강구 중이다… 도와줘요 아주대…
- 예산을 충분히 지원 받는다면, 쿠버네티스, Kafka, ELK 같은 오픈스택도 마음껏 써보고 싶다. 그전까지 리팩토링을 통해 코드를 유지보수하기 좋게 만들려고한다.
신설학과, 단과대 추가: -자유전공학부, 프런티어과학학부, 경제정치사회융합학부, 응용화학과, 첨단바이오융합대학이 추가되었다. 서비스의 구독 목록에 추가해야 한다.
알림 ON/OFF 옵션 추가: 현재는 구독 탭에서 구독한 공지사항에 대해서는 무조건 푸시 알림을 받는다. 특히 아주대학교-일반 공지사항은 하루에 30개가 넘게 공지사항이 올라와 너무 자주 알림이 온다는 의견을 반영하여 결정했다.
- 유튜브의 구독 기능처럼, 구독은 하고 알림은 받지 않는 기능을 추가할 생각이다. 구독한 공지사항에 푸시 알림이 오지 않더라도 , 네비게이션바의 구독탭에 뱃지가 바뀌기 때문에 종종 올라오면서 확인을 할 것이라고 생각했다.

유튜브의 알림 옵션

알림 목록 구현: 현재 사용자들은 푸시 알림을 받을 수 있지만, 앱 내부에서 알림 목록을 따로 확인할 수 있는 페이지는 없다. 따라서 알림 목록 페이지를 구현하고, PWA에서 뱃지 기능을 구현해서 사용자가 알림 몇 개를 읽지 않았는지 확인할 수 있게할 예정이다.

일반 앱처럼 PWA에서도 뱃지 API를 지원한다

Display a badge on the app icon - Progressive web apps | MDN

Applications native to mobile and desktop operating systems can display badges on top of their app icons to inform users that new content is available. For example, an email client application can display the total number of unread messages in a badge and

developer.mozilla.org

푸시 알림 및 크롤링 모니터링: FCM을 사용하기 때문에 현재 Firebase 콘솔을 통해 메시지의 전송량은 모니터링할 수 있지만, 클릭률이나 수신률에 대해서는 모니터링이 되지 않는다. 따라서 클릭률과 수신률 같은 푸시 알림 데이터를 모니터링하는 시스템을 구축할 계획이다. 또한 크롤링을 할때도 실패 처리, 누락 처리와 같은 예외처리를 정교화하고 안정적인 서비스 운영을 위한 모니터링을 구축할 계획이다.

Firebase의 푸시 알림 모니터링

simzard

[회고] 중견기업 인턴, 대기업 인턴에서 정규직 전환까지 - 백엔드 개발자 취준 기간의 기록

타임라인

(2024년) 정병의 3학년

(2024년 겨울 방학) SW융합교육원 방학 코테 강의

(2025년 1학기) 4학년, 휴학 없이 달리다

(2025년 1학기) 마지막 코딩 트레이너 활동

(2025년 1학기) SW캡스톤디자인

중간 자랑 타임

(2025년 여름방학) 저 또 달려요? - 안랩 인턴 합격

(2025년 여름방학 ~ 2학기) 안랩 체험형 인턴 6개월(막학기)

여러 컨퍼런스와 행사 참여

다양한 회사 이벤트

러닝 열풍 동참

SW중심대학 연합 SW페스티벌 참여

팀 워크샵

황금 연휴 때 돈 받고 쉬기 - 미국 동부 여행(워싱턴DC, 나이아가라, 뉴욕 - 10박 12일)

콘서트(잔나비, 오아시스, 한로로)

인턴 끝, 대학 생활 끝

(2026년 시작) 취준 정병...

(2026년 2월) 넷마블 채용전환형 인턴 시작

(2026년 2월) 졸업식

(2026년 4월) 실업급여 요건 충족, 진짜 백수

(2026년 4월) 최종합격 및 신입사원 입사

(2026년 4월 ~ 7월) 수습기간

(2026년 7월) 수습 끝, 부서 배치

합격한 공고

안랩 현장실습인턴(6개월) - 모바일 서버 개발

넷마블 채용전환형 인턴(8주) - SW개발

잘했던 점/좋았던 점

꾸준히 한 가지 프로젝트를 오래한 것

주어진 상황에서 최선을 다했다.

그래도 하나씩 스펙을 쌓아가는 과정이 있었다.

만족할만한 결과를 가지고 취준판을 떠나다.

아쉬웠던 점

너무 혼자하려고 했던 것?

조급함

느낀점

운이 좋았다.

복권 당첨자들의 공통점은 복권을 구매했다는 것

IT업계는 참 좁구나

대학 입시 이후로 이렇게까지 간절했던 순간이 있었나 싶다.

중고신입이 못 들어오는 영역 → 채용전환형 인턴

중요한 것은 태도

도전적인 상황을 만들자

한 챕터의 끝, Next?

Appendix

신인류

쿵야

넷마블과의 인연

유튜브처럼, 구독한 공지사항별 알림 설정 기능을 도입해보자

기능 개발 배경 - 푸시 알림이 너무 많이 와요…

목표: 구독한 공지사항의 푸시 알림 설정 기능을 추가하자

유튜브 vs 아주이벤트

알림 설정 - 유튜브

알림 설정 - 아주이벤트

구독 탭 - 유튜브

구독 탭 - 아주이벤트

*우선 FCM의 Token과 Topic이란?

FCM Token

FCM Topic

FCM 개념 정리 (Token vs Topic)

관련 테이블

Topic - 구독할 수 있는 공지사항 단위

TopicMember - Topic과 Member를 매핑 (사용자가 어떤 공지사항을 구독하는지)

Token - 기기마다 부여되는 고유한 식별자, 사용자 1명이 여러개를 가질 수 있음

TopicToken - Topic과 Token을 매핑

고민한 방법들

방법1 - 알림 여부를 저장하는 필드 추가(기존 구조 유지)

방법 2 - 알림 여부를 다루는 Topic 추가 & FCM 조건식

방법 3 - 알림 여부를 저장하는 필드 추가 + Topic → Token 구조로 변경

방식별 장단점 정리

최종 선택 및 구현 방향

1차 채택 - 방법1: 기존 Topic 구조 + receiveNotification 필드 추가

2차 채택 - 방법3: Topic → Token 구조로 변경

정합성 이슈의 원인

추가 요구사항

구조 전환

최종 구현 정리: 알림 설정 추가 및 Token 기반 전송

알림 설정 추가