처음에는 참가자들이 5인이내로 구성된 팀을 꾸려오면 선착순으로 받아 진행되는 방식이였으나, 고학년과 저학년의 격차를 고려해 모집 이전에 고학년 3명 저학년 3명의 팀으로 수정되어 모집되었다.

우리 처음의 팀은 4명이었으나 어쩔수 없이 3명이서 나가게 되었다.

4학년이라 고학년으로 참여를 하였고 저학년 팀은 자동으로 매칭되는 시스템이였다.

사실 고학년 팀중에서도 해커톤의 경험이있는건 나뿐이여서 걱정이많았다. 저학년의 스펙도 궁금하였고, 어떤 프레임워크를 사용해야하고, 서로의 역할분배가 제일 걱정되었다.

이전에 참여했던 해커톤에서는 역할분배가 적절히 되지않아 고생했던 기억이있어서.. 바이브 해커톤 대회라서 사실 혼자 개발하는게 더 나을지도 모르겠다는 생각을 한두번 한게 아니였기 때문이다. 그래서 이번 대회에서는 서로의 의사소통과 기준이되는 하나의 md 파일을 먼저 만드는것을 계속 중점으로 가지고 갔다.

서로 각자 다른 에이전트를 사용하기에 소통에서 하나의 문제라도 있으면 병합과정에 그것을 해결하는데 많은 시간을 쏟아야 하기 때문이다.

이번 해커톤에서는 중간에서 진행사항을 계속 물어보고 뭐해야하고 공유 파일 정리하고 .env 파일이나 통합 .md파일 공유 및 소통역할을 많이 하였다.

저학년친구들에게 깃헙 사용법을 알려주고 싶었지만 세명이 하나의 노트북에 붙어 기획에서 만들어진 요구서를 바탕으로 front ui 를 맡겼다.

깃헙을 대신해 작성된 코드파일을 .zip 파일로 요청을했고..ㅎㅎ. 나머지는 디자인과 발표자료를 부탁했다.

고학년중 클로드 결제를 한 친구가 .zip 파일을받아 처음에 아키텍처를 기획한대로 supabase 와 채팅을 위한 firebase 에 맡게 수정을 하였고 프론트 배포를 vercel 로 작업을 끝냈다.

기획에서 탄탄하게 팀원들과 맞춰갔기 때문에 개발 단계에서 별 문제없이 진행되었다 vercel 배포중에 한번 conflict가 났는데 이유는 중간에 한번 주제를 바꿈으로 인해 안쓰는 lib 파일이 배포중에 충돌이나 삭제만 해주고 바로 배포를 성공적으로 하였다.

시간이 다른조들보다 조금 남아 발표자료와 발표스크립트 등에 시간을 좀 더 쓸 수 있었다.

조원들이 잘 봐주어 발표를 담당한 나도 별 긴장없이 잘 준비할 수 있었다.

많은 사람들 앞에서 발표하는건 적응이 안되는 거 같다

다른 조분들이 발표를 너무 잘하여서 더 긴장했던 거 같다. 사실 3팀분의 발표가 너무 인상깊어 수상은 기대도 안했었다..

15팀의 모든 발표가 끝나고, 15분간의 심사봐주시는 교수님분들이 심사시간을 가졌다.

그리고 ..

감사하게도 좋게 봐주셔서 대상을 할 수 있었다. 팀원분들도 다들 밤샘 고생해줘서 얻을 수 있는 갚진 결과인 거 같았다.

해커톤은 이번이 두번째인데 항상 나가면서 드는 생각이 바이브코딩의 시대인 만큼 뛰어난 실력과 코딩 수준도 중요하지만 기획단계가 너무 중요한 거 같았다. 기획과 발표와 바로 보여지는 발표자료또한 중요한 거 같다.

그리고 우리 서비스를 설명할 수 있는 한문장으로 심사하시는 분들에게 어?라는 생각을 들게 해야한다

좋은 경험하고 다시는 밤샘은 못할 거 같다.. 아직도 패턴이 안돌아와..

혼자하는 러닝앱은 많은데 친구와 같이하는 러닝앱이 없어 개발해서 가능하면 배포(런칭) 까지 해보고싶다는 욕심이 생겨서 개발을 하게되었다.

가능하면 오늘 하루안에 다 해보고싶다.. 이후 저녁약속이있어 7시 전까지 개발 완료 목표로 잡고 배포는 내일해도되니까

우선 매니페스트에 입력해 기능명세서와 유저플로우, 와이어프레임을 뽑았다. 와이어프레임은 베타버전이긴하나 하나하나 세부수정이 가능해 개발자가 원하는대로 뽑을 수 있었다.

이 기획을 토대로 google ai studio 랑 제미나이 클로드 중 어느 에이전트를 사용해 개발할까 고민하다 둘다 구글이랑 클로드를 사용해보기로 했다.

클로드에게 맡겼을 때는 PRD 만 보고서는 잘 못짜서 더 요구사항을 넣으려다 내 토큰을 위해 아껴두었고

나머지를 google ai studio 한테 맡겼다.

지금 듣고있는 노래플리 : https://www.youtube.com/watch?v=Ckwc2PwMjPk

오래걸려서 노래 든는중..

오 예쁘게 된 거 같다. 한번 배포까지 노력하고 다시 작성하겠다.

거기에 빠지지않는 여러 다이어그램중 하나인 아키텍처 다이어그램을 msa 기반으로 만들어보려한다.

근데 msa 랑 soa 두개의 정의가 모호해 한번 내친구에게 물어보고 답을 얻었다.

① 중앙 집중형 통신(ESB) vs 가볍고 단순한 통신(Smart Endpoints)
SOA (ESB 중심): SOA는 ESB(Enterprise Service Bus)라는 강력하고 지능적인 중앙 미들웨어를 둡니다. 이 ESB가 서로 다른 서비스 간의 프로토콜 변환, 메시지 라우팅, 데이터 포맷 변환 등을 전부 처리합니다. 시스템 전체의 비즈니스 오케스트레이션(흐름 제어)을 ESB가 쥐고 있기 때문에, ESB가 죽으면 시스템 전체가 마비되는 단점(Single Point of Failure)이 있습니다.

MSA (Dumb Pipes, Smart Endpoints): 반면 MSA는 "통로(Pipe)는 가볍게 만들고, 끝단(Endpoint)을 똑똑하게 만들자"는 철학을 가집니다. 중앙 버스 미들웨어 없이, 서비스들이 가벼운 HTTP REST API나 gRPC를 통해 직접 혹은 API Gateway를 거쳐 최소한의 규격으로 통신합니다.

② 데이터베이스 공유 vs 데이터베이스 격리 
SOA: 대개의 경우 서비스들은 쪼개져 있지만, 백엔드의 데이터베이스는 하나로 공유합니다. 이 때문에 특정 서비스의 스키마를 변경하려면 다른 서비스 개발팀과 상의해야 하며, DB 병목 현상이 발생하면 전체 시스템 성능이 저하됩니다.

MSA: "Database Per Service" 원칙을 고수합니다. 각 마이크로서비스는 자신만의 전용 데이터베이스를 가집니다. 서비스 A는 PostgreSQL을 쓰고, 서비스 B는 MongoDB를 써도 무방합니다. 서로의 DB에 직접 쿼리를 날릴 수 없고 오직 API를 통해서만 데이터를 주고받기 때문에 영속성 레이어의 독립성이 완벽히 보장됩니다.

간략히 보면 msa 는 말그대로 micro 단위까지 독립적으로 설계된 아키텍처인 거 같았습니다.

그래서 msa하면 떠오르느 대표적인 회사인 Netflex의 아키텍처를 보면

이게 아키텍처 구조이다..

토나오는 비주얼

어쩄든 가트너가 제시한 msa 아키텍처 표준안을 살펴보고 내 서비스에 맞는 미들웨어들을 넣어 내 아키텍처를 작성해보았다.

많이 비슷한 다이어그램의 모형인데, 똑같이 중요한 6가지가 있다. 오른쪽에 Outer Architecture Capability라고 적혀있는데

1. External Gateway
2. Service Mesh
3. Runtime Platform
4. Backing Services
5. Tlelmetry
6. CI/ CD Automation

이 6가지를 고수하며 작성해 보았다

무료 미들웨어들을 고집했고, 많이 추상적이라 개발하려고 하는 서비스 입에 맞춰서 수정이 더 필요하다..

더 수정이 필요한 부분은 수정해 다시 게시하도록 하겠다.

카페에서 공부하다 내가 좋아하는 빈지노의 aquaman 노래가 나오는데 가사가 생각이 안나서 네이버에 aquaman 가사를 검색했다. 프로젝트 공부를 하며 가사를 보고싶었는데 네이버창을 계속 띄워두자니 내 작은 16인치의 노트북 화면을 가리는데 충분해서 그냥 미니앱과같은 서비스형식의 토이프로젝트를 바로 하려했다.

2. 어떤 기술

어떻게 구현을 할까 고민을 하다 요전에 학교에서 진행한 p-project 에서 다른팀이 Electron 을 이용해 프론트를 구현한 기억이 나를 스쳤다.

바로 Electron 공부를 들어가려 했다가 머리가 아파 .. 클로드와 함께하는 개발시간.. 바로 가이드라인 제시해서 만들어줘 시전했다.

기술 스택은 Electron, Node.js, Main/Render 프로세스와 IPC 흐름으로 구현을 했고 , 가사 수집을 어떻게 할까 크롤링이나 공식 API 고민중 그냥 딸깍으로 만드려고 크롤링을 선택했다. 어짜피 나만 쓸 서비스니.. ui는 backdrop-filter와 프레임이거슬려 프레임이스창으로 만들었다

3. 트러블 슈팅?

이라고 할게 있나? 클로드가 너무 잘짜줬다 한번에 ui 부분에서 가사와 아티스트명을 너무 길게 입력하면 화면이 오른쪽으로 쏠려 가사부분 왼쪽이 짤림 현상이 있었는데 overflow: hidden 속성으로 고쳐주었다.

4. 실행

바로 필요한 라이브러리들을 npm install 로 설치를 해주고 npm start 로 실행을 해보자.

위와 같은 창이 내 노트북 오른쪽 화면에 생긴다.

검색을 하면 위와 같이 가사를 보며 공부를 같이 할 수 있게 되었다. 결코 공부하기 싫어서 만든게아니ㅑ

나도 처음엔 “또 하나의 보안 사고인가 보다” 하고 넘기려다가, 내용 좀 보니까 생각보다 가볍게 넘길 일은 아니더라고요. 그래서 이걸 계기로 느낀 점이랑 정리 좀 해보려고 글 씁니다.

사건 배경 (간단 정리)

최근에 Anthropic의 Claude 관련 내부 코드나 프롬프트 일부가 외부로 유출됐다는 얘기가 돌면서 꽤 이슈가 됐습니다. 정확히 어떤 경로로 유출됐는지는 아직 명확하게 다 공개된 건 아니지만, 핵심은 이거 하나예요.

“AI 서비스도 결국 사람이 만드는 소프트웨어고, 보안이 뚫리면 똑같이 위험하다”

사실 GPT든 Claude든 다들 되게 ‘대단한 AI’라고 생각하는데, 그 내부를 보면 결국 코드 + 프롬프트 + 데이터의 조합이거든요. 그게 유출됐다는 건 생각보다 큰 문제입니다.

내가 느낀 포인트

1. 프롬프트도 ‘자산’이다

이거 이번에 제일 크게 느낀 부분.

예전에는 그냥 “프롬프트 잘 짜면 좋다~” 정도였는데, 이제는 기업 입장에서는 프롬프트 자체가 거의 핵심 기술이에요.

• 어떻게 답변하게 만드는지
• 어떤 방식으로 안전하게 필터링하는지
• 어떤 구조로 추론하게 만드는지

이런 게 다 프롬프트에 녹아있거든요.

즉, 코드만 중요한 게 아니라 “AI를 어떻게 다루는 방식 자체”가 유출된 거라서 더 의미가 큼.

2. 결국 보안은 기본 중의 기본

이거 보면서 든 생각 하나.

“아무리 AI 시대라도, 기본적인 보안 못 하면 끝이다”

요즘은 다들 AI, 모델, 성능 이런 얘기만 하는데 막상 서비스 터지는 건 항상 보안 쪽에서 터짐.

• API 키 관리
• 접근 권한 관리 (IAM 같은 거)
• 내부 코드 관리

이거 하나라도 삐끗하면 바로 사고로 이어지는 구조임.

나도 AWS 쓰면서 느끼는 건데, 권한 설정 조금만 잘못해도 바로 위험해지는 게 이쪽임.

3. “클로즈드 vs 오픈” 논쟁 더 커질 듯

이 사건 이후로 또 나올 얘기 뻔함.

• “어차피 유출될 거면 오픈소스가 낫다”
• “그래도 기업 기술은 보호해야 한다”

개인적으로는 둘 다 맞는 말 같음.

근데 확실한 건, 클로즈드 모델이라고 해서 완전히 안전하지 않다는 건 이번에 확실히 보여준 사례라고 생각함.

개발자로서 느낀 점

솔직히 이거 보면서 좀 현실적으로 와닿은 게 하나 있음.

“대단한 기술도 결국 관리 못 하면 무너진다”

우리는 지금 AI 공부하고, 프로젝트 만들고, 서버 올리고 이런 거 하잖아요.

근데 그 과정에서

• .env 그냥 공유하고
• 키 그대로 올리고
• 권한 대충 주고

이러면… 규모만 커졌을 때 똑같은 사고 나는 거임.

결국 중요한 건

• 기술 잘 쓰는 거 +
• 안전하게 쓰는 거

이 두 개를 같이 가져가야 한다는 거.

마무리

이번 클로드 코드 유출 사건은 단순한 “사고 하나”라기보다, AI 시대에서 우리가 뭘 중요하게 봐야 하는지 다시 보여준 케이스 같음.

정리하면 딱 이거:

• 프롬프트도 자산이다
• 보안은 선택이 아니라 필수다
• AI도 결국 소프트웨어다

나도 이번 기회에 .env 관리, AWS 권한, 키 관리 이런 거 다시 한 번 점검해봐야겠다는 생각 들었음.

괜히 큰 서비스만의 문제가 아니라 우리 같은 개인 프로젝트에서도 충분히 터질 수 있는 문제니까.

다음에는 이거 이어서 “개발하면서 실제로 보안 어떻게 챙겨야 하는지”도 정리해볼까 생각 중.

프로젝트를 시작하면서 가장 먼저 진행했던 작업은 요구사항 분석이었다. 기능 정의를 구체화하는 과정에서 예상보다 다양한 의견이 나왔는데, 그중에서도 가장 크게 의견이 갈렸던 부분은 사용자 인증 방식 선택이었다.

문제 상황

처음에는 단순히 “로그인 기능을 구현한다” 정도로 생각했지만, 구체적인 구현 방식을 논의하면서 자연스럽게 인증 방식에 대한 이야기가 나왔다.

팀 내에서는 크게 두 가지 의견으로 나뉘었다.

• JWT 기반 인증을 사용하자는 의견
• 세션 기반 인증을 사용하자는 의견

처음에는 단순한 기술 선택처럼 보였지만, 이야기가 깊어질수록 각 방식의 장단점이 부각되면서 쉽게 결론이 나지 않았다.

논쟁의 핵심

JWT를 사용하자는 쪽에서는 다음과 같은 이유를 들었다.

• 서버 상태를 최소화할 수 있어 확장성에 유리하다
• MSA 구조를 고려하면 더 적합하다
• 최근 많이 사용되는 방식이라 학습 가치가 있다

반면, 세션 기반을 선호한 쪽에서는 이런 의견이 나왔다.

• 구현이 단순하고 안정적이다
• 로그아웃이나 인증 관리가 직관적이다
• 현재 프로젝트 규모에서는 과한 선택일 수 있다

결국 이 논쟁의 본질은 단순히 기술의 문제가 아니라 “개발 속도를 우선할 것인지, 확장성과 구조를 고려할 것인지”에 대한 방향성 차이였다.

해결 과정

이 상태로는 아무리 토론을 이어가도 결론이 나기 어렵다고 판단했고, 기술 자체가 아니라 프로젝트의 목표를 기준으로 의사결정을 해야 한다고 생각했다.

그래서 팀원들과 함께 다음과 같은 기준을 먼저 정리했다.

1. 이번 프로젝트의 목적은 단순 기능 구현이 아니라 학습과 경험에 있다
2. MSA 구조를 일부라도 경험해보는 것이 중요하다
3. 일정 내 구현 가능한 수준이어야 한다

이 기준을 바탕으로 다시 논의를 진행한 결과, 확장성과 학습 측면에서 장점이 있는 JWT 방식이 더 적합하다는 결론을 내릴 수 있었다.

다만, JWT의 단점으로 언급되었던 토큰 관리 문제는 그대로 두지 않고, Redis를 활용해 보완하기로 했다.

결과

결과적으로 JWT 기반 인증을 도입하면서 구조적인 설계 경험을 가져갈 수 있었고, 단순 구현을 넘어 실제 서비스 구조를 고민해볼 수 있는 계기가 되었다.

무엇보다 의미 있었던 점은, 기술 선택을 개인의 선호가 아닌 명확한 기준을 바탕으로 결정했다는 것이었다.

이 경험 이후로는 새로운 기능이나 기술을 선택할 때도 자연스럽게 “이 선택이 프로젝트 목표에 맞는가?”를 먼저 고민하게 되었다.

마무리

요구사항 분석 단계는 단순히 기능을 나열하는 과정이 아니라, 프로젝트의 방향을 결정하는 중요한 단계라는 것을 느꼈다.

그리고 그 과정에서 발생하는 논쟁은 피해야 할 문제가 아니라, 오히려 더 나은 결정을 위한 필수적인 과정이라고 생각하게 되었다.

나는 원래 이런 식으로 작업했다.

1. 아이폰으로 사진을 찍는다.
2. 카카오톡 나에게 보내기로 사진을 보낸다.
3. 노트북에서 카카오톡을 열어 사진을 저장하거나 복사한다.
4. 다시 노션을 열어서 붙여넣거나 업로드한다.

사진 한 장만 옮길 때는 큰 문제가 아닌 것처럼 보이지만, 수업 시간 동안 이 과정을 반복하다 보면 수업을 이해하는 도중 흐름이 자꾸 끊겼다.
특히 여러 장을 연속으로 찍는 날에는, 사진 촬영보다 전송과 정리가 더 귀찮게 느껴졌다.

문제 상황

내 환경은 다음과 같았다.

• 휴대폰: 아이폰
• 노트북: LG 노트북
• 운영체제: Windows 11
• 정리 도구: Notion

이 조합에서 내가 원했던 것은 단순했다.

방금 찍은 사진을 가능한 바로 노트북에서 쓰고 싶다.

하지만 실제 사용 경험은 그렇지 않았다.

불편했던 점

• 아이폰과 Windows 노트북 사이 사진 전달이 자연스럽게 이어지지 않는다.
• 매번 카카오톡이나 메신저를 중간 매개로 써야 한다.
• 사진을 전송한 뒤에도 다시 노션에 업로드하는 단계가 남아 있다.
• 수업 흐름 중간에 앱을 여러 번 오가야 해서 집중이 깨진다.
• 사진을 “찍는 행위”보다 “정리해서 옮기는 행위”가 더 피곤해진다.

문제 정의

이 프로젝트에서 정의한 핵심 문제는 아래와 같다.

1. 촬영과 정리 사이의 단계가 너무 많다

사용자는 단지 수업 사진을 기록하고 싶을 뿐인데,
실제로는 촬영 → 전송 → 저장 → 업로드라는 여러 단계를 거쳐야 한다.

즉, 정보를 기록하는 행위보다 전달 과정이 더 무거운 문제가 있었다.

2. 아이폰 + Windows 조합에서는 즉시성이 부족하다

애플 생태계 안에서는 비교적 자연스럽게 이어질 수 있는 기능들이 있지만,
아이폰과 Windows 노트북 조합에서는 사진을 바로 활용하기 위한 연결이 매끄럽지 않다.

즉, 기기 조합 때문에 작업 흐름이 끊기는 문제가 있었다. 이는 안그래도 허약한 내 수업 집중상태를 끊는데 충분했다.

-> 물론 이미 상용화된 많은서비스들이 있었겠지만 시장조사보다 내가 그냥 한번 만들어보고 싶다는생각이 더 컸던 거 같다.

내가 원한 해결 방향

이 프로젝트를 만들면서 내가 원한 경험은 명확했다.

• 아이폰으로 사진을 찍는다.
• 그 사진이 바로 노트북으로 전달된다.
• 필요하면 노트북 클립보드에서도 바로 쓸 수 있다.
• 동시에 노션에도 자동으로 정리된다.
• 수업 시간에만 활성화되도록 해서 실제 사용 맥락에 맞춘다.

즉, 내가 원한 것은 단순한 “사진 업로드 기능”이 아니라
수업 기록 흐름을 끊지 않는 자동화된 연결 경험이었다.

이 프로젝트의 목표

이 프로젝트의 목표는 다음과 같다.

아이폰으로 찍은 수업 사진을, Windows 노트북과 Notion으로 최대한 즉시 연결해
중간 전달 과정을 줄이고 기록 흐름을 단순화하는 것

정리하면, 이 서비스는 “사진을 잘 올리는 앱”이 아니라
수업 중 기록 과정에서 발생하는 불필요한 전송 마찰을 줄이기 위한 도구로 시작했다.

한 줄로 정리하면

카카오톡 나에게 보내기 -> 노트북 저장 -> 노션 업로드
이 반복 작업이 너무 귀찮아서,

아이폰에서 찍은 수업 사진이 노트북과 노션으로 바로 이어지는 흐름을 만들고 싶었다.

위 사진처럼 잘 사진이 인식이 된다 다만 한가지 문제는 학교 와이파이는 보안이 심해서 연동이 안되어 내 핫스팟을 이용을 해야한다. 집 와이파이는 문제없이 구현이 된다.

깃헙 링크 : https://github.com/0798JiHyuk/class-photo-notion

로그 찍어서 보는 건 한계가 있어서 찾아보다가 Grafana를 알게 됐다.

1. Grafana? 처음엔 이게 뭔지 몰랐다

처음엔 그냥 “그래프 그려주는 툴인가?” 정도로 생각했는데

써보니까 느낌이 좀 다르다.

데이터를 예쁘게 보여주는 도구인데 문제는 “데이터는 알아서 안 가져온다”는 거

이걸 모르고 한참 헤맸다...

2. 일단 설치부터

복잡할 줄 알았는데 Docker로 바로 띄웠다.

docker run -d -p 3000:3000 --name grafana grafana/grafana

켜고 나서 http://localhost:3000 들어가니까 바로 화면 나옴

3. 여기서부터 막혔다

들어가보니까 “그래서 뭘 해야 하지?” 상태됨

아무 그래프도 안 보임 이유는 아무런 데이터가 없었기 떄문이다

Grafana는 혼자서는 아무것도 못하는 애였다...

4. Prometheus 연결하면서 이해됨

찾아보니까 다들 Prometheus랑 같이 쓰길래 연결해봄

이때 깨달음

👉 Prometheus = 데이터 모으는 역할 👉 Grafana = 그걸 보여주는 역할

이거 이해하니까 갑자기 전체 흐름이 보였다

5. 대시보드 만들기 (재밌는 구간)

데이터 연결하고 나서 Dashboard 만들어봤는데

이때부터 좀 재밌어짐

쿼리 하나 넣었는데 그래프 바로 뜨는 거 보고 약간 감탄함

rate(http_requests_total[1m])

👉 “아 이래서 쓰는구나” 싶었다

6. 써보면서 느낀 점

좋았던 점

• 생각보다 금방 익숙해짐
• 시각화가 진짜 직관적임
• 디버깅할 때 도움 많이 될 듯

어려웠던 점

• 처음에 개념 이해가 제일 어려움
• 데이터 없으면 아무것도 못함 (이거 핵심)

7. 한 줄 정리

👉 Grafana는 혼자 쓰는 게 아니라 👉 다른 도구랑 같이 써야 의미 있음

8. 다음에 해볼 거

• 서버 CPU / 메모리 모니터링 붙이기
• API 응답속도 그래프로 보기
• 알림 설정까지 해보기

마무리

처음엔 좀 막막했는데 구조 이해하고 나니까 왜 쓰는지 알겠다

👉 로그만 보는 거랑은 차원이 다름

다음엔 Prometheus까지 같이 정리해볼 생각 할게 너무 많긴해

처음에는 단순히

"같은 기능을 Java로 다시 구현하면 되겠지"

라고 생각했다.

하지만 막상 시작해보니 단순한 언어 변경이 아니라 아키텍처와 개발 방식 자체가 달라지는 작업이었다.

이번 글에서는 TypeScript 프로젝트를 Spring Boot로 다시 만들면서 생겼던 기술적인 고민과 해결 과정을 정리해보려고 한다.

왜 TypeScript → Spring Boot로 다시 만들었을까

처음 프로젝트는 다음과 같은 스택으로 만들어졌다.

Node.js
TypeScript
Express
MySQL

빠르게 기능을 만들기에는 좋았지만 프로젝트가 커지면서 몇 가지 아쉬움이 생겼다.

• 서비스 구조 관리
• 인증 처리
• 코드 구조 유지보수

그래서 백엔드 구조를 다시 고민하게 되었고 결국 Spring Boot 기반으로 다시 구현해보기로 했다.

문제 1. 프로젝트 구조를 어떻게 설계할 것인가

TypeScript 프로젝트는 비교적 단순한 구조였다.

controllers
services
routes
models

하지만 Spring Boot 프로젝트는 일반적으로 이런 구조를 사용한다.

controller
service
repository
entity

여기서 고민이 생겼다.

TypeScript 프로젝트 구조를 그대로 가져갈까? 아니면 Spring 방식으로 새로 설계할까?

결론적으로 Spring의 레이어드 아키텍처를 따르기로 했다.

Controller
Service
Repository
Entity

이렇게 구조를 정리하면서 코드의 역할이 더 명확해졌다.

문제 2. 비동기 처리 방식 차이

TypeScript에서는 대부분 비동기 처리를 이렇게 했다.

async / await

예를 들어

const user = await userRepository.findById(id)

하지만 Spring Boot에서는 기본적으로 동기 방식으로 동작한다.

그래서 처음에는 이런 고민이 생겼다.

Node는 비동기 기반인데 Spring은 왜 동기 방식일까?

Spring은 멀티스레드 기반으로 요청을 처리하기 때문에 대부분의 경우 동기 방식으로도 충분한 성능을 낼 수 있다는 것을 알게 되었다.

문제 3. 인증 처리 방식

TypeScript 프로젝트에서는 JWT 인증을 직접 구현했다.

구조는 대략 이렇게 되어 있었다.

login
↓
JWT 발급
↓
middleware 인증

하지만 Spring Boot에서는 보통

Spring Security

를 사용한다.

여기서 또 고민이 생겼다.

기존 JWT 로직을 그대로 사용할까? 아니면 Spring Security를 사용할까?

결국 Spring Security + JWT 방식으로 구현했다.

이 과정에서 가장 어려웠던 부분은

Security Filter
JWT Filter

구조를 이해하는 것이었다.

문제 4. ORM 사용 방식 차이

TypeScript 프로젝트에서는 보통 이런 방식으로 DB를 사용했다.

SQL 직접 작성

또는

TypeORM

하지만 Spring Boot에서는 보통

JPA
Hibernate

를 사용한다.

여기서 또 고민이 생겼다.

SQL 중심으로 갈까? ORM을 사용할까?

결론적으로 JPA를 사용하되 복잡한 쿼리는 직접 작성하는 방식으로 정리했다.

문제 5. 에러 처리 구조

TypeScript에서는 보통 이렇게 에러 처리를 했다.

try / catch

하지만 Spring에서는

@ControllerAdvice
@ExceptionHandler

같은 전역 에러 처리를 사용할 수 있었다.

이 구조를 적용하면서 코드가 훨씬 깔끔해졌다.

문제 6. 환경 설정 관리

TypeScript 프로젝트에서는 환경변수를 보통 이렇게 관리했다.

.env

Spring Boot에서는

application.yml
application.properties

를 사용한다.

처음에는 설정이 많아 복잡하게 느껴졌지만 서비스 설정을 한 곳에서 관리할 수 있다는 장점이 있었다.

다시 만들면서 느낀 점

같은 기능을 구현하는 프로젝트라도

Node.js
Spring Boot

는 개발 방식 자체가 많이 다르다는 것을 느꼈다.

특히 다음 부분에서 차이를 크게 느꼈다.

• 프로젝트 구조
• 인증 처리 방식
• ORM 사용 방식

처음에는 단순한 언어 변경이라고 생각했지만 결과적으로는 백엔드 아키텍처를 다시 고민하는 과정이 되었다.

마무리

기존 TypeScript 프로젝트를 Spring Boot로 다시 만들면서 단순히 코드를 옮기는 작업이 아니라 서비스 구조를 다시 설계하는 경험을 할 수 있었다.

특히 Spring의 구조적인 설계 방식이 프로젝트가 커질수록 유지보수에 유리하다는 것을 느꼈다.

다음 글에서는

• Spring Boot + JWT 인증 구현
• AWS 서버 배포 과정

도 정리해볼 예정이다.

하지만 막상 구현해보니 단순히 로그인 기능을 만드는 것보다 토큰 관리와 보안 문제에서 생각보다 많은 고민이 생겼다.

이번 글에서는 JWT 로그인 구조와 Access Token / Refresh Token을 사용하면서 고민했던 점들을 정리해보려고 한다.

JWT란 무엇인가

JWT(Json Web Token)는 사용자 인증 정보를 토큰 형태로 전달하는 방식이다.

기존 세션 방식과 가장 큰 차이는 이것이다.

세션 인증
서버에 로그인 상태 저장

JWT 인증
토큰 안에 사용자 정보를 담아서 인증

즉 서버가 로그인 상태를 저장하지 않아도 된다.

그래서 Stateless 인증 방식이라고 부른다.

JWT 구조

JWT는 크게 3가지로 구성된다.

Header
Payload
Signature

예시

xxxxx.yyyyy.zzzzz

각 역할은 다음과 같다.

Header

토큰 타입과 암호화 알고리즘 정보

Payload

사용자 정보

예시

userId
email
role

Signature

토큰 위조 방지를 위한 서명

JWT 로그인 흐름

JWT 로그인 과정은 보통 다음과 같다.

1. 사용자 로그인 요청
2. 서버에서 사용자 인증
3. JWT 토큰 발급
4. 클라이언트가 토큰 저장
5. API 요청 시 토큰 전달

API 요청 시 보통 이렇게 전달한다.

Authorization: Bearer {JWT}

서버에서는 토큰을 검증한 후 요청을 처리한다.

Access Token / Refresh Token 구조

JWT 인증을 구현할 때 가장 많이 사용하는 방식이

Access Token
Refresh Token

구조이다.

Access Token

특징

• 짧은 유효시간
• API 요청 시 사용

예

15분
30분

Refresh Token

특징

• Access Token 재발급
• 긴 유효시간

예

7일
14일

로그인 구조는 보통 이렇게 된다.

로그인
↓
Access Token 발급
Refresh Token 발급
↓
Access Token 만료
↓
Refresh Token으로 재발급

JWT를 사용하면서 생긴 고민

JWT 인증을 구현하면서 몇 가지 고민이 생겼다.

1. 토큰 저장 위치

토큰을 어디에 저장할 것인가?

대표적인 선택지는

LocalStorage
Cookie

이다.

하지만 LocalStorage는 XSS 공격 위험이 있다.

그래서 최근에는

HttpOnly Cookie

방식을 많이 사용한다.

2. 로그아웃 처리

JWT는 Stateless 방식이라 서버에 세션이 없다.

그래서 로그아웃을 해도 토큰이 살아있다.

이 문제를 해결하기 위해 보통

토큰 블랙리스트
Redis 관리

같은 방법을 사용한다.

3. Payload에 어디까지 넣어야 할까

JWT Payload에는 사용자 정보를 넣을 수 있다.

예

userId
email
role

하지만 데이터를 많이 넣으면 토큰이 커진다.

그래서 보통

userId
role

정도만 넣는 경우가 많다.

4. Refresh Token 저장 위치

Refresh Token을 어디에 저장할지도 고민이었다.

대표적인 방법은

DB 저장
Redis 저장

이다.

팀 프로젝트에서는 관리 편의성을 위해 DB에 저장하는 방식을 사용했다.

JWT를 사용하면서 느낀 점

JWT는 확실히 확장성과 분산 시스템에서 장점이 있는 인증 방식이다.

하지만 단순히 로그인 기능을 구현하는 것만 보면

Session 방식이 더 단순할 수도 있다.

특히 토큰 관리와 보안 문제까지 고려하면 JWT 구조를 제대로 설계하는 것이 중요하다고 느꼈다.

마무리

JWT 인증을 구현하면서 느낀 점은 이것이다.

JWT는 단순한 토큰 인증이 아니라 토큰 관리 구조를 설계하는 문제에 가깝다.

Access Token / Refresh Token 구조와 토큰 보안 문제까지 고려해야 안정적인 인증 시스템을 만들 수 있다.

다음에는 실제로 Spring Security에서 JWT 인증을 구현하는 과정도 정리해볼 예정이다.

4년 전에 만들었던 프로젝트라 그런지 구조도 꽤 낡아 있었고, 요즘 기준으로 보면 유지보수가 쉽지 않은 구조였다.

그래서 자연스럽게 이런 생각이 들었다.

"이 프로젝트를 Spring Boot로 옮겨볼까?"

Spring Boot는 요즘 대부분의 프로젝트에서 사용되고 있고 설정도 훨씬 간단해졌기 때문에 리팩토링 겸 마이그레이션을 해보려고 했다.

하지만 막상 시작해보니 생각보다 고민거리가 많았다.

1. XML 설정을 어떻게 처리해야 할까?

예전 프로젝트를 열어보자마자 가장 먼저 보였던 건 엄청난 양의 XML 설정 파일이었다.

applicationContext.xml
dispatcher-servlet.xml
mybatis-config.xml
security-context.xml

Spring Boot는 기본적으로 Java Config 기반으로 동작하는데 이걸 전부 옮겨야 할까?

처음에는 단순하게 생각했다.

"XML을 그냥 import 하면 되는 거 아닌가?"

하지만 문제가 있었다.

Spring Boot는 Auto Configuration 기반으로 돌아가는데 기존 XML 설정이 충돌할 가능성이 있었다.

그래서 고민이 생겼다.

• 기존 XML을 유지할까?
• 아니면 Java Config로 전부 바꿀까?

지금 고민 중인 방향은 이렇다.

핵심 설정만 Java Config로 옮기고 나머지는 점진적으로 제거하는 방식

한 번에 다 바꾸면 리스크가 너무 커질 것 같다.

2. WAR 프로젝트를 JAR로 바꿔야 할까?

예전 프로젝트는 Tomcat에 배포하는 WAR 구조였다.

mvn package
→ war 파일 생성
→ tomcat/webapps 배포

하지만 Spring Boot는 보통 이렇게 사용한다.

java -jar application.jar

여기서 고민이 생겼다.

WAR 구조를 유지해야 할까 아니면 Boot 스타일 JAR로 바꿔야 할까?

JAR로 바꾸면 장점이 많다.

• 내장 Tomcat
• 배포 간단
• Docker 사용 쉬움

하지만 기존 프로젝트 구조가 WAR 기준으로 만들어져 있어서 생각보다 수정해야 할 부분이 많았다.

특히 다음 부분이 걸렸다.

web.xml
Servlet 설정
Filter 설정
Listener 설정

이걸 전부 Spring Boot 방식으로 바꿔야 한다.

그래서 지금은 이 부분을 어떻게 정리할지 고민 중이다.

3. 로그 시스템을 그대로 써도 될까?

기존 프로젝트는 로그를 이렇게 사용하고 있었다.

log4j

하지만 요즘 Spring Boot에서는 대부분

logback

을 사용한다.

그래서 또 고민이 생겼다.

기존 log4j를 유지할까? 아니면 Boot 기본 로그 시스템을 사용할까?

문제는 log4j 설정 파일이 꽤 많이 커스터마이징 되어 있다는 점이다.

log4j.xml

이걸 그대로 유지하면 빠르게 마이그레이션할 수 있지만 장기적으로 보면 Boot 기본 구조를 따르는 게 맞을 것 같기도 하다.

4. MyBatis 설정은 그대로 써도 될까?

이 프로젝트는 ORM 대신 MyBatis를 사용하고 있었다.

구조는 이런 식이었다.

mapper.xml
SqlSessionFactory
SqlSessionTemplate

Spring Boot에서는 mybatis-spring-boot-starter를 쓰면 설정이 훨씬 단순해진다.

하지만 또 고민이 생긴다.

기존 설정을 보면 이런 코드가 많다.

SqlSessionFactoryBean
MapperScannerConfigurer

Boot에서는 이런 설정이 대부분 필요 없어진다.

그래서 고민 중이다.

기존 설정을 유지하면서 옮길까 아니면 Boot 방식으로 새로 구성할까

5. 패키지 구조를 바꿔야 할까?

예전 프로젝트의 패키지 구조는 이랬다.

controller
service
dao
vo
util
common

전형적인 레이어드 구조다.

하지만 요즘은 이런 구조도 많이 보인다.

user
order
payment

즉 도메인 중심 구조

그래서 또 고민이 생겼다.

마이그레이션하면서 구조까지 바꿀까?

하지만 지금 생각은 이렇다.

구조까지 바꾸면 리팩토링 범위가 너무 커진다.

그래서 일단은

• Boot 마이그레이션 먼저
• 구조 리팩토링은 나중

이 방향으로 가는 게 맞을 것 같다.

6. 의존성 충돌 문제

마이그레이션을 하다 보니 가장 예상되는 문제는 이것이다.

dependency 충돌

예전 프로젝트는 이런 라이브러리를 사용하고 있었다.

spring 4.x
jackson 2.x
commons-fileupload

Spring Boot로 넘어오면 대부분 Boot가 버전을 관리한다.

그래서 이런 문제가 생길 수 있다.

ClassNotFoundException
NoSuchMethodError

이 문제는 실제로 꽤 많이 발생한다고 한다.

그래서 dependency를 하나씩 확인하면서 Boot 기준으로 정리할 필요가 있을 것 같다.

아직 해결하지 못한 고민

지금 이 마이그레이션을 하면서 여전히 고민 중인 것들이 있다.

• XML 설정을 어디까지 제거할까?
• WAR 구조를 유지할까?
• 로그 시스템을 바꿀까?
• MyBatis 설정을 다시 짤까?

생각보다 단순한 작업이 아니었다.

하지만 이런 고민을 하다 보니 예전에 아무 생각 없이 쓰던 Spring 구조를 다시 이해하게 되는 계기가 된 것 같다.

앞으로 해보고 싶은 것

Spring Boot로 옮기면서 다음 것들도 같이 해보고 싶다.

• Docker 배포
• CI/CD 구축
• 서버 구조 개선

단순히 "Spring Boot로 옮겼다"가 아니라 프로젝트 구조 자체를 한번 정리하는 과정이 될 것 같다.

아직 마이그레이션은 진행 중이다.

이 과정에서 생기는 문제들을 하나씩 기록해보려고 한다.

하지만 프로젝트가 커지면서 문제가 발생했다.

서비스 구조는 대략 이랬다.

• Backend: Spring Boot
• Database: MySQL
• AI Model: Python 기반 모델
• Infrastructure: AWS EC2 (Free Tier)

처음에는 모든 것을 하나의 서버에서 같이 실행했다.

Spring Boot
MySQL
AI Model

결과는 예상보다 빠르게 나타났다.

서버 다운.

문제 상황

처음에는 단순히 서버가 느려지는 수준이었다.

• API 응답이 느려짐
• MySQL 쿼리 지연
• AI 모델 inference 시간이 길어짐

하지만 어느 순간부터는 아예 서버가 멈췄다.

SSH 접속도 안 되고, EC2 상태를 보면 메모리 부족(OOM) 상황이었다.

1GB 메모리 환경에서 동시에 돌아가고 있던 것들:

• Spring Boot JVM
• MySQL
• Python AI 모델

특히 Spring Boot의 JVM + Python 모델 메모리 사용량이 생각보다 컸다.

결국 구조 자체를 다시 고민하게 됐다.

고민: 서버를 업그레이드할까? 아니면 구조를 바꿀까?

가장 쉬운 방법은 EC2 인스턴스를 업그레이드하는 것이었다.

하지만 프로젝트 특성상 프리티어 환경에서 최대한 해결해보고 싶었다.

그래서 두 가지 접근을 했다.

1️⃣ 백엔드와 DB의 메모리 사용량을 줄인다 2️⃣ AI 모델을 서버에서 분리한다

1. Spring Boot 메모리 튜닝

Spring Boot는 기본 설정 그대로 실행하면 JVM 메모리를 꽤 많이 사용한다.

그래서 JVM 옵션을 조정했다.

-Xms256m
-Xmx512m

초기 메모리와 최대 메모리를 제한해서 Spring이 서버 메모리를 과도하게 점유하지 않도록 설정했다.

또한 불필요한 dependency를 제거하고 로깅 레벨도 최소화했다.

2. MySQL 메모리 튜닝

MySQL 역시 기본 설정으로 두면 메모리 사용량이 꽤 높다.

그래서 다음 설정을 조정했다.

대표적으로:

• innodb_buffer_pool_size
• max_connections

프리티어 서버 환경에 맞게 버퍼 크기를 줄이고 연결 수를 제한했다.

결과적으로 MySQL 메모리 사용량을 꽤 줄일 수 있었다.

3. AI 서버 분리 (FastAPI)

가장 큰 문제는 AI 모델이었다.

Python 기반 모델은 메모리를 꽤 많이 사용하고, 특히 모델이 로드될 때 메모리를 크게 차지했다.

그래서 구조를 다음처럼 변경했다.

기존 구조

Client
   ↓
Spring Server
   ↓
AI Model (same server)

변경된 구조

Client
   ↓
Spring Server
   ↓
FastAPI AI Server

AI 모델은 별도의 서버에서 FastAPI로 운영했다.

Spring에서는 AI 요청이 필요할 때

POST /predict

API를 호출하도록 만들었다.

이렇게 하면서 얻은 장점은 명확했다.

• AI 모델이 Spring 서버 메모리를 사용하지 않음
• AI 서버를 독립적으로 확장 가능
• 서비스 구조가 마이크로서비스 형태로 분리

결과

구조를 변경한 이후

• 서버 다운 문제 해결
• API 응답 안정화
• AI inference 요청도 안정적으로 처리

무엇보다 좋았던 점은 인프라 구조에 대해 더 깊이 고민하게 됐다는 것이다.

단순히 "서버 사양을 올리는 것"보다

• 메모리 사용 구조
• 서비스 분리
• API 기반 통신

같은 것들을 실제로 경험해 볼 수 있었다.

배운 점

이번 경험을 통해 느낀 점은 하나였다.

"문제가 생기면 서버를 키우기 전에 구조를 먼저 고민해보자."

특히 AI 서비스는

• Backend
• Database
• AI Inference

를 분리하는 구조가 훨씬 안정적이라는 걸 직접 체감했다.

AWS 프리티어 같은 제한된 환경에서도 구조를 잘 설계하면 충분히 운영할 수 있다는 것도 배웠다.

다음 목표

다음에는 다음 부분도 개선해보고 싶다.

• Docker 기반 서비스 분리
• Nginx Reverse Proxy 적용
• AI 서버 GPU 환경 실험

아직 작은 프로젝트지만 이런 기술 고민들이 쌓여서 더 좋은 구조를 만들 수 있다고 생각한다.

처음 해커톤에 나갔다. 결과는 장려상.

상보다 더 의미 있었던 건 “지금 시대에 개발자는 어떤 사람이 되어야 하는가”에 대한 생각이었다.

📌 1. 주제 선정

GDGoC 연합동아리에서 주최한 해커톤의 주제는 취업난이었다.

취준생인 나에게 이 주제는 멀지 않았다.

정보는 넘쳐난다.

하지만 정리할 시간은 없다.

뉴스는 보지만 면접 답변으로 연결하지 못한다.

우리는 여기서 문제를 정의했다.

“취준생은 정보가 부족한 게 아니라, 정보를 ‘면접에서 쓸 수 있는 형태’로 가공할 시간이 부족하다.”

💡 우리가 만든 서비스 – 스포일러 (Spoiler) 한 줄 설명

관심 기업과 직무를 설정하면 AI가 면접 관점으로 요약해 푸시 알림으로 전달하는 초개인화 면접 비서

🔎 문제 정의

기업 분석은 중요하지만 지속하기 어렵다.

뉴스는 많지만 “면접 답변용”으로 정리되지 않는다.

앱을 매번 열어 확인하는 행동 자체가 피로하다.

🚀 해결 전략

우리는 역설적인 UX를 택했다.

“사용자가 앱을 켜지 않게 만드는 앱”

잠금화면 푸시 알림에서 1줄 핵심 요약

탭하면 3줄 요약 + 면접 활용 포인트

직무별 예상 질문 자동 생성

🧠 기술 설계

나는 팀에서 백엔드를 맡았다.

🔹 왜 Node.js를 선택했는가?

해커톤은 속도가 생명이라도 들었다 빠른 개발, JS 생태계 활용, 비동기 처리를 통한 뉴스 수집, 데이터 가공을 위해 선택했다.

🔹 왜 Express 기반 구조를 사용했는가?

빠른 REST API 구성

미들웨어 구조로 확장 가능

데모에 최적화된 가벼운 구조

해커톤에서는 “완벽한 아키텍처”보다 빠르고 안정적인 MVP 구현이 더 중요했다.

사실 익숙한 언어는 java 프레임워크는 Spring Boot 이였지만 처음이라 멋도 모르고 Node.js 로시작하였다.. 그러고 후회는 엄청했다.

🔹 AI 파이프라인 설계

우리는 단순 요약이 아니라 “면접형 재해석”을 목표로 했다.

처리 흐름

1. 뉴스 수집 (API 기반)

2. 필터링 (중복/광고 제거)

3. LLM 호출

4. 직무별 질문 생성

5. DB 저장

6. 푸시 전송

여기서 핵심은 프롬프트 설계였다.

“이 뉴스를 면접관 관점에서 재해석하라.”

단순 요약이 아니라 질문으로 변환시키는 로직이 우리 서비스의 차별점이었다.

[회고록]

🔥 인상 깊었던 순간

해커톤 리더 분이 이런 말을 했다.

“이제는 코더가 아니라 리뷰어가 살아남는다.”

그 말이 머리에 계속 맴돌았다.

AI가 코드를 작성하는 시대에 개발자는 점점 코드 작성자에서 의사결정자, 검증자, 구조 설계자로 이동하고 있다.

이미 이전부터 느꼈지만 이번 해커톤에서 더 느낀거 같다.

AI가 코드 초안을 만들고

우리는 그걸 다듬고

구조를 설계하고

트레이드오프를 판단했다

이게 바로 “리뷰어로서의 개발”이 아닐까 생각했다.

🤝 팀 구성과 협업

총 4명 팀

나는 백엔드

해커톤은 첫 경험

처음이라 긴장도 많이 했다.

하지만:

역할 분배

API 스펙 정리

빠른 피드백 루프

이 과정을 겪으며 “개발은 혼자가 아니라 팀 스포츠”라는 걸 실감했다.

사실 고난도 있었다. 처음 해커톤이라 아키텍처 설계부터 시간분배 등등 빵꾸가 너무나도 많았다 솔직히 처음 기획한 api를 다 만들지도 못했다. 그래도 문제정의에서 해결하고자 한 기능들은 구현을 했고 핵심 로직또한 구현은 완료하였다. 그저 아쉬울뿐..

이번 해커톤을 통해 위처럼 힘든점도 있었지만 얻은것 또한 많았다

짧은시간안에 AI 파이프라인 설계하는 경험을 하였고 개인화 데이터 설계 직무 기반 동적 콘텐츠 설계등을 해볼 수 있었다.

두번쨰로는

나는 그동안 “기능 구현” 중심으로 생각했다. 이번에는 달랐다. 왜 이 기능이 필요한가? 사용자 행동은 어떻게 바뀌는가? 이 서비스가 실제 취준생에게 의미 있는가?

문제 정의 → 해결 설계 → 구현

이 흐름을 처음으로 제대로 경험했다.

🏆 그리고 결과

장려상 수상.

물론 대상은 아니었지만, 처음 해커톤에서 이 정도 결과는 충분히 의미 있었다고 생각한다.

하지만 상보다 더 값진 건

“나는 단순 코더가 아니라 문제를 정의하려는 개발자가 되고 있다”

는 확신이었다.

🎯 앞으로의 방향

이번 해커톤을 통해 느꼈다.

AI 시대에 살아남는 개발자는:

코드를 많이 치는 사람이 아니라

구조를 설계하는 사람

문제를 정의하는 사람

AI를 도구로 활용하는 사람

나는 이제 코더가 아니라 리뷰어이자 설계자가 되기 위한 준비를 시작하려 한다.

마무리

취업난 속에서 우리는 또 하나의 취업 준비 서비스를 만들었다.

아이러니하지만, 그 과정이 나를 더 단단하게 만들었다.

다음 해커톤에서는 더 깊은 설계와 더 강한 문제 정의로 도전해보고 싶다.

notion : https://www.notion.so/GDGoC-2ff3762acb5c80f99e2ff0ff6ca51043

github : https://github.com/nalleum/nalleum_backend

데이콘(공모전 주최) 링크 : https://dacon.io/competitions/official/236666/overview/description 공용문서 링크 : https://www.notion.so/2fd189dee3ba80fb8e4ed264bd944ea2 깃헙 링크 : https://github.com/0798JiHyuk/-repository (추후 조직링크로 변경..)

한 줄 소개

실전형 보이스피싱 대응 학습을 위해, 숏폼/롱폼 훈련 결과를 자동 집계하고 주간 리포트까지 생성하는 백엔드 기능을 고도화했다.

프로젝트 배경

이번 작업의 목표는 크게 두 가지였다.

1. 사용자 훈련 데이터를 끝나자마자 요약해 리포트로 제공하기
2. 롱폼 시뮬레이터 답변 품질을 높이기 위해 대화 맥락(history)을 안정적으로 전달하기

기존에는 weekly_reports 조회 API는 있었지만, 실제 리포트 생성 로직이 비어 있어 체감 가능한 피드백 경험이 약했다. 또한 롱폼 응답 생성 시 직전 맥락 반영이 제한적이라 답변 일관성이 흔들리는 문제가 있었다.

이번에 구현한 핵심 작업

1) 주간 리포트 생성 서비스 구현

파일: src/services/reports.service.ts

기존 export const reportsService = {}; 상태에서 실제 생성 로직을 완성했다.

• 최근 7일 기준 기간 계산 (from_date, to_date)
• training_results 기준 훈련 횟수/평균 점수/정확도 집계
• 모드별 취약 유형 추출
  • short: training_shorts.category_code
  • long: training_scenarios.category
• OpenAI Responses API를 호출해 한국어 요약 생성
  • one_line_feedback
  • weak_patterns[]
  • action_guides[]
• weekly_reports upsert 처리 (ON CONFLICT)
• FK 이슈(에러코드 23503) 발생 시 top_wrong_type_code=null로 재시도하는 안전장치 추가

핵심 포인트는 "집계 SQL + AI 요약 + DB upsert"를 한 사이클로 묶어, 조회 전에 데이터가 만들어지는 구조를 만든 것이다.

2) 훈련 종료 시 자동 리포트 생성 연결

파일:

• src/routes/trainingShort.routes.ts
• src/routes/trainingLong.routes.ts

숏폼/롱폼 세션 finish 시점에 generateWeeklyReport(userId, mode)를 호출하도록 연결했다.

• 학습 직후 리포트 최신화
• 리포트 생성 실패가 학습 완료 응답 자체를 막지 않도록 try/catch + warn 처리

즉, 사용자 경험 관점에서 "훈련 완료 -> 바로 리포트 확인" 흐름이 자연스럽게 이어지게 했다.

3) 리포트 조회 API 안정성 개선

파일: src/routes/reports.routes.ts

/api/reports/weekly에서 다음을 개선했다.

• 정렬 기준을 generated_at DESC로 변경해 가장 최근 생성본을 확실히 반환
• 요청/결과 로그 추가 ([reports/weekly] request/result)
• 예외 발생 시 503 + 구조화된 에러 코드(REPORT_QUERY_FAILED) 반환

운영 중 장애 분석을 빠르게 하려는 목적이 컸다.

4) 롱폼 대화 맥락 전달(History) 개선

파일:

• src/routes/trainingLong.routes.ts
• src/services/ai.service.ts
• src/services/simulator.service.ts
• scripts/simulator_bridge.py

변경 내용:

• 서버가 longform_messages에서 기존 대화를 조회해 history 배열로 구성
• aiGenerateLongformReply 및 시뮬레이터 클라이언트 계층에 history 파라미터 추가
• Python 브리지에서 받은 history를 시뮬레이터 메시지 컨텍스트로 재구성

효과:

• 턴이 누적되어도 답변 문맥 일관성 향상
• 역할(role) 매핑 정리(ai -> assistant)로 모델 입력 안정화

5) 텍스트 인코딩/음성 생성 품질 보강

파일:

• feedback_agent.py
• simulator_test_2.py

주요 개선:

• UTF-8 안전 정제 함수 추가로 깨진 문자열/서로게이트 문자 대응
• TTS 입력 텍스트 전처리 강화(기호 정리, 문장부호 정돈)
• 프롬프트 메시지를 JSON 형태로 stderr 출력해 디버깅 가시성 확보

트러블슈팅에서 배운 점

1. 리포트 기능은 "조회 API"만 만들면 끝이 아니었다. 실제 생성 트리거를 사용자 행동 지점(finish)에 붙여야 데이터가 살아 움직인다.

2. AI 요약은 항상 실패 가능성을 전제로 설계해야 한다. API 키 누락, 파싱 실패, DB 제약 이슈를 각각 분리해 fallback/재시도를 넣어야 운영이 안정된다.

3. 대화형 시스템에서 문맥(history)은 품질의 핵심이다. 한 턴의 입력만 보내는 구조보다, 정돈된 대화 이력을 전달할 때 응답 품질이 확실히 좋아진다.

현재 아키텍처 흐름(요약)

1. 사용자가 숏폼/롱폼 훈련 진행
2. 세션 종료 API 호출
3. 서버가 최근 7일 학습 데이터를 집계
4. AI가 취약 패턴/행동 가이드를 요약
5. weekly_reports upsert
6. /api/reports/weekly에서 최신 리포트 조회

기술 스택과 선택 이유

사용 언어

• TypeScript (Node.js): API 서버의 핵심 로직(라우팅, 서비스, DB 연동)을 타입 안정성 있게 운영하기 위해 선택했다. DTO/응답 스키마가 많은 백엔드에서 런타임 오류를 줄이고 리팩터링 안정성을 높이는 데 유리했다.
• Python: 시뮬레이터 브리지와 피드백/음성 관련 실험 코드에 사용했다. AI/오디오 처리 라이브러리 생태계가 강하고, 프로토타이핑 속도가 빨라 모델 연동 실험에 적합했다.

사용 프레임워크/라이브러리

• Express: REST API를 빠르게 구성하고 미들웨어 기반으로 인증, 에러 핸들링, 라우트 분리를 명확히 하기 쉬워서 사용했다.
• PostgreSQL(pg): 훈련 결과 집계, 주간 리포트 upsert, 조인 기반 통계 쿼리가 핵심이라 관계형 DB가 적합했다.
• Zod: 요청 유효성 검증을 스키마로 명시해 입력 신뢰도를 높이고, 잘못된 요청을 초기에 차단하기 위해 사용했다.
• express-session: 로그인 기반 사용자 식별(req.session.user.id)이 필요해 세션 인증 구조를 적용했다.
• AWS S3 SDK(@aws-sdk/client-s3, @aws-sdk/s3-request-presigner): 음성 파일 업로드/조회 URL을 안전하게 관리하기 위해 presigned URL 방식을 사용했다.
• OpenAI API(Responses/Chat): 주간 리포트 요약 생성, 대화형 시뮬레이터 응답, 피드백 분석 등 생성형 AI 기능을 백엔드 서비스 계층에 통합했다.

백엔드 관점에서의 선택 포인트

1. 유지보수성: TypeScript + 계층형 구조(routes/services/repositories)로 기능 확장 시 영향 범위를 예측하기 쉬웠다.
2. 운영 안정성: 리포트 생성 실패를 업무 실패로 전파하지 않고 fallback/재시도를 넣어 사용자 플로우를 보호했다.
3. 데이터 신뢰성: PostgreSQL 집계 + ON CONFLICT upsert로 주간 리포트 생성의 중복/정합성 문제를 줄였다.
4. 확장성: Express 라우트 분리와 서비스 모듈화 덕분에 숏폼/롱폼/리포트/업로드 기능을 독립적으로 진화시키기 좋았다.
5. 실험 속도: AI 실험 영역은 Python으로, 운영 API는 TypeScript로 분리해 개발 속도와 안정성의 균형을 맞췄다.

마무리

이번 작업으로 guardian-server는 단순 훈련 제공 백엔드에서, "학습 결과를 자동으로 요약하고 다음 행동까지 제시하는 피드백 백엔드"로 한 단계 올라갔다.

다음 단계로는 리포트 정확도 개선(카테고리 정규화), 장기 추세 리포트(4주/8주), 사용자별 개인화 코칭 템플릿을 확장해볼 계획이다.

2026년, 컴퓨터공학과 4학년이 되었다.

예전에는 “컴공이면 취업은 걱정 없다”는 말이 있었다. 하지만 지금은 다르다.

ChatGPT, Copilot, Claude 같은 AI가 코드를 대신 짜고, 리팩토링하고, 심지어 설계까지 제안한다.

나는 지금 이런 질문을 스스로에게 던지고 있다.

“내가 4년 동안 배운 것들이 AI보다 가치 있을까?”

📌 현재 나의 스펙 정리

FE 국비 수업 6개월 (NCS 과정)

BE·AI 개발자 취업 준비 국비 7개월

공모전 장려상

해커톤 장려상

포토샵 자격증

교내 프로제트 장려상

외 여러 토이 프로젝트 경험 등

나쁘지 않다. 하지만 솔직히 말하면 차별화는 부족하다.

요즘 신입 지원자들은:

토이 프로젝트 다수

깃허브 잔디 빽빽

블로그 운영

AI 활용 경험

단순히 “웹 서비스 만들어봤습니다”는 더 이상 경쟁력이 되지 않는 시대다.

🔎 문제 정의

1️⃣ 단순 코더의 가치 하락

CRUD 구현 로그인 기능 게시판 만들기

이제는 AI가 몇 분이면 만든다.

내가 “기능 구현자”로 남는다면 나는 대체 가능한 인력이 된다.

2️⃣ 설계 경험의 부재

학교에서는 이론을 배웠다. 국비에서는 기능을 만들었다.

하지만 나는 아직:

대규모 트래픽을 설계해본 적 없다.

장애 대응 경험이 없다.

실제 서비스 운영 경험이 없다.

즉, “문제 해결자”라기보다는 “문제 수행자”에 가깝다.

3️⃣ AI를 경쟁자로 볼 것인가, 도구로 볼 것인가

AI는 이미 개발자의 일부 업무를 대체하고 있다.

하지만 동시에 개발자의 생산성을 폭발적으로 올려주고 있다.

결국 질문은 이것이다.

AI를 쓰는 개발자가 될 것인가, AI에게 밀리는 개발자가 될 것인가?

🎯 앞으로 해결해야 할 것들

1️⃣ 기능 구현자 → 문제 정의자

코드를 짜는 사람이 아니라

왜 이런 구조가 필요한지 설명할 수 있는 사람

트레이드오프를 말할 수 있는 사람

기술 선택의 근거를 제시할 수 있는 사람

이 되어야 한다.

2️⃣ CS 기초를 다시 잡기

운영체제

네트워크

데이터베이스 인덱스

트랜잭션

동시성

이걸 모르면 설계를 할 수 없다.

“프레임워크 사용자”에서 “시스템 이해자”로 가야 한다.

3️⃣ AI 활용 능력 키우기

AI를 금지하는 게 아니라 AI를 지휘하는 개발자가 되어야 한다. 요즘은 AI오케스트레이션이라 한다고한다..

코드 리뷰에 AI 활용

리팩토링 보조

테스트 코드 생성

아키텍처 초안 설계

AI는 내 대체자가 아니라 내 생산성을 3배 올려주는 도구가 되어야 한다.

🚀 단기 목표 (1년 이내)

기술 블로그 주 1회 작성

단순 기능 프로젝트가 아닌 “구조 중심 프로젝트” 진행

백엔드 심화 학습 (DB 설계, 캐싱, 동시성)

코드 리뷰 습관화

기술 면접 대비 CS 정리

📈 중기 목표 (3~5년)

서비스 운영 경험 쌓기

트래픽 처리 경험

설계 참여

아키텍처 이해

기술 의사결정 경험

“시킨 것만 하는 개발자”가 아니라 “방향을 제시하는 개발자”가 되는 것.

🧠 결론

AI는 개발자를 없애지 않는다. 그러길 빈다.

하지만 평범한 개발자는 빠르게 줄어든다.

나는 지금 갈림길에 서 있다.

튜토리얼 개발자로 남을 것인가

문제 해결형 개발자로 성장할 것인가

이 블로그는 내 일자리를 지키기 위한 기록이다.

그리고 앞으로 성장 과정을 증명하는 공간이 될 것이다.