잉여개발자

[경제] 월가아재 - 한국은행 총재가 말하는 환율이 위험한 진짜 이유 요약

yubi5050 — Sat, 27 Jun 2026 17:31:29 +0900

1. 환율 상승, 수출 호재라는 상식이 위험한 이유

환율 상승이 무조건 수출에 좋다는 기존의 상식이였음.

한국 경제에서는 오히려 금융 시스템에 압력을 가해 경제를 위축시킬 수도 있다는

신현송 한국은행 총재의 시각

금융 시스템이 실물 경제를 증폭시킨다는 이론

글로벌 게임 이론: 사람들이 한 방향으로 쏠리는 현상을 수학적으로 설명
아드리안-신 모형: 금융 시스템이 경기 사이클을 증폭시킨다는 이론
1. 전통 경제학은 은행을 실물 경제에 따라가는 조연으로 보지만, 신 총재는 금융 행위 자체가 실물 경제를 바꾼다고 주장
2. 금융은 호황을 더 뜨겁게, 불황을 더 차갑게 만드는 역할을 한다

1.2. 은행의 자산 조절 메커니즘과 레버리지 효과

전통 경제학: 돈이 들어갈 곳(실물 경제)이 먼저 정해지고, 은행은 자금을 조달하는 조연 역할
- 은행의 자산 규모는 기업이나 개인의 대출 수요에 따라 결정되며,
- 은행의 레버리지(자기 자본 대비 부채 비율) 변화는 자산 총량에 영향을 주지 않는다
- 100억을 넣어 부채 레버리지 30% 이면 총 자산이 130억 임은 변하지 않음
신현송 총재: 자본이 고정되어 있고 자산이 유동적이며, 은행은 자산을 조절하는 주체
- 은행의 자기 자본은 단기적으로 고정되어 있지만, 채권 매매나 대출 조절을 통해 자산은 유동적으로 변한다
- 은행은 BAR (위험 가치) 지표를 기준으로 목표 레버리지를 일정하게 유지하려 한다
목표 레버리지 유지로 인한 자산 시장 증폭 메커니즘 (아래 4. 5. )
- 레버리지(Leverage) : 내 자본에 빌린 돈(부채)을 더해 투자 규모와 수익률을 극대화하는 투자 전략
- 초기 자본 (자기 자본 100억, 부채 레버리지 30%, 총 운용 자산 130억원)
자산 가격 상승 시:
- 은행 자산 가치 상승 → 자기 자본 증가 (100억 -> 110억)
- 목표 레버리지 유지(30%, 110억이므로 33억원)를 위한 '리밸런싱' (추가 대출(3억원) 및 자산 매입)
- 총 자기 자본 110억, 시장에 주입된 총 유동성(부채) 33억 (은행이 레버리지로 일으킨 신용 규모)로 / 총 운용 자산 143억
- 자기 자본은 10억이 증가 레버리지로 유동성 33억원 증가, 유동성 팽창 배수(시장의 총 부채/초기 가격 상승분)는 3.3배
- 즉 자산 가격 상승이 금융기관의 대출 여력을 높이고, 그것이 다시 추가 자산 매입으로 이어지며 시중 유동성을 가격 상승분의 수 배 이상으로 증폭시키는 현상을 '레버리지 사이클' 혹은 '신용 팽창'이라고 함.
- 이는 시중에 도는 유동성을 정상에 대한 가격 상승분의 몇 배로 팽창시키는 효과를 낳는다
자산 가격 하락 시:
- 자산 가격 하락시 위험함
- 은행 자산 가치 하락 → 자기 자본 감소 (100억 -> 90억)
- 목표 레버리지 초과(30%, 90억의 30%에서 27억원)를 위한 '추가 자산 매도' → 자산 가격 추가 하락
- 이러한 은행들의 동시 매도 물량 증가는 자산 가격을 더욱 떨어뜨리고, 앞선 지점이 반복됨. 이는 2008년 리먼 사태의 원인
- 디레버리징이라고 함
핵심: 은행의 탐욕이 아닌, 시스템적으로 정해진 목표 레버리지를 지키려는 행동이 금융 시장의 변동성을 증폭시킨다
결론: 작은 자산 시장 변동이 은행의 레버리지 조정을 통해 자산 규모를 몇 배로 키우거나 줄이며, 금융 시스템이 경기를 증폭시킨다

2. 환율의 두 얼굴: 무역 경로와 금융 경로

환율 상승은 수출 증대라는 전통적인 무역 경로의 이점과 함께,

기업의 달러 부채 증가 및 금융 시스템 불안을 야기하는 금융 경로의 위험을 동시에 가진다.

왼 : 원화약세의 양면성 / 오 : 환율 상승시 흐름

2.1. 환율의 무역 경로: 수출 호재

원화 약세의 의미: 1달러 구매에 더 많은 원화 필요
외국인 입장: 한국 물건이 더 싸게 느껴짐
수출 증대 효과: 삼성 반도체, 현대차 등 해외 판매 증가
경제 성장: 수출 증가 → 공장 가동률 상승 → GDP 증가
결론: 원화 약세는 수출 국가에 호재라는 기존 공식

2.2. 환율의 금융 경로: 경제 위축 요인

원화 약세의 금융 경로: 호재가 아닌 경제를 옥죄는 요인
대차대조표 흔들림: 환율 변동이 앞선 은행의 대출 조절을 유발
한국 기업의 달러 부채 증가:
- 10억 달러 대출 시, 환율 1,300원에서 1,500원으로 상승하면 원화 환산 빚이 2천억 원 증가
- 기업의 재무 상태 악화, 회수 불가능 리스크 증가
글로벌 은행의 자산 가치 삭감 및 디레버리징:
- 빌려준 달러의 회수 불가능 리스크 증가 → 은행은 장부상 대출 가치 삭감 → 자기 자본 감소
- 자기 자본 감소 → 목표 레버리지 초과 → 규칙에 따라 자산 청산(매도) 및 대출 축소 (디레버리징)
금융 시스템 전반의 위축:
- 한 기업뿐 아니라 다수 기업에 동시 다발적 영향 → 돈줄이 마르고 경제 전체 위축
- 원화 약세로 인한 수출 증대 효과보다 돈줄 마르는 손해가 더 클 수 있다
외국인 투자 자산 통한 경로:
- 외국인 투자자의 달러 기준 손실:
- 한국 주식/채권에 10억 달러 투자 시, 환율 상승으로 달러 환산 가치 하락 (예: 8.7억 달러)
- 한국 자산 가격 변동 없이도 환율 때문에 1.3억 달러 손실 발생
- 자산 매도 및 원화 약세 심화:
- 외국인, 추가 손실 우려 → 한국 자산 매도 → 주가/채권 가격 하락 및 원화 추가 약세
- 이는 매도가 매도를 부르는 악순환으로 이어짐
- 포트폴리오 리밸런싱 유인 증가:
- 코스피 상승으로 외국인 보유 원화 자산 비중 증가 → 차익 실현 및 포트폴리오 재조정 필요성 증대
- 최근 외국인의 한국 주식 연속 매도는 이러한 금융 경로의 현실적 작동을 보여준다
되살아난 원죄: 위험의 전가
- 과거: 한국이 직접 달러 빚을 져 원화 폭락 시 직접적 타격 (IMF 외환 위기)
- 현재: 원화 국채 발행으로 환율 위험이 외국인 투자자에게 전가됨
- 원화 약세 시 외국인이 달러 손실을 보고 채권을 팔고 이탈 → 원화 추가 하락 압력 발생
- 결론: 위험의 형태(달러 빚 -> 국채)만 바뀌었을 뿐, 외부 충격이 한국을 흔드는 본질은 동일
신흥국에서의 금융 경로 우위:
- 한국과 같은 신흥국에서는 금융 경로가 무역 경로의 이득을 상쇄하거나 압도할 수 있다
- 원화 약세로 인한 수출 이득보다 돈줄 마르는 손해가 더 클 수 있다
- 약한 통화가 무조건 수출 호재라는 공식은 신흥국에서 깨진다

3. 환율 상승의 네 가지 원인과 대응 방안

현재의 가파른 환율 상승은 지정학적 위기, 구조적 요인, 투기적 움직임, 주변국 변수 등 복합적인 원인에 기인하며, 이에 대한 단기 및 장기적 대응 방안이 제시된다.

환율 상승의 네 가지 주요 원인

3.1 트리거: 지정학적 위기와 유가 상승

이란 전쟁 발발 및 호르무즈 해협 봉쇄 우려 → 유가 급등 (두바이유 2월 68달러 → 3월 128달러)
한국은 원유 수입 의존도가 높아 유가 상승 시 달러 수요 증가 → 원화 약세 압력

3.2 구조적 압력: 만성적인 요인

한미 금리차: 미국 금리가 한국 금리보다 높아 달러로 자금 이동 유발 (22년부터 40개월 이상 지속)
수출 기업의 달러 보유 증가:
- 과거와 달리 수출 기업이 받은 달러를 원화로 바꾸지 않고 미국 현지 투자 등에 사용
- 특히 3,500억 달러 규모의 대미 투자 약속은 달러 수요 폭발 요인
- 이는 한국은행의 금리 조절이나 구두 개입으로 해결하기 어려운 국제 정치적 문제
국내 달러 수요 증가:
- 국민연금, 개인 투자자들의 해외 자산 투자 증가 → 원화 매도, 달러 매수 수요 발생
투기적 요소: NDF 시장
- NDF (차액결제선물환): 원화 실물 거래 없이 차익만 정산하는 해외 원화 베팅 시장
- 꼬리가 몸통을 흔드는 현상: 서울 외환 시장 폐장 시간 동안 NDF 시장에서 결정된 원화 가치가 다음날 서울 시장에 영향을 미침
주변국 변수: 엔화 약세
- 엔화 약세가 원화 약세와 동반되는 경향
- 일본 정부의 소극적인 엔화 방어 스탠스 → 원화 약세에 부정적 영향 가능성
- BOJ 금리 인상 시점(6월 예상)이 엔화 및 원화 강세에 미칠 영향 주목
- 최근 원화는 엔화와 더 밀접하게 움직이는 경향 (과거 위안화와 움직임)

3.3 한국은행의 대응 방안: 단기 카드와 장기 카드

단기 카드 (일시적 쏠림 대응)
- 외환보유액 달러 매도 (스무딩 오퍼레이션): 원화 가치 지지
- 외환당국 간 달러 융통: 국민은행, 외환은행 등과 협력
- 구두 개입: 시장에 경고 메시지 전달
신현송 총재 취임 후 "환율 쏠림 용인 불가, 수단과 의지 있다" 강경 발언
금리 동결 및 긴축 신호 병행 (물가, 경기, 환율 모두 조여야 하는 방향)
단기 카드의 한계: 구조적 압력 앞에서는 효과 미미 (6월에도 환율 1,500원 상회)
장기 카드 (근본적 해결)
- 금리와 금융 안정을 분리하여 관리:
금리는 물가와 경기에 집중, 가게 부채 및 금융 불안은 거시 건전성 정책으로 관리
거시 건전성 정책 예시: DSR 규제 등 소득 대비 무리한 대출 억제
- 과거 성공 경험 기반 규제:
2010년 해외 단기 달러 부채 한도 설정 및 비용 부과 → 2008년 위기 대비 금융 안정성 강화
은행 외 사모펀드, 부동산 PF, 증권사, 암호자산 등 감시 확대
원화의 국제화:
- 24시간 외환 시장 운영: NDF 시장의 영향력 축소 및 국내 시장 가격 결정력 강화
- 해외 원화 결제 시스템 구축 및 디지털 화폐 준비 → 원화 사용 증대 → 달러 의존도 감소
- 신현송 총재, 통화정책 부서보다 지급결제 부서 먼저 방문 → 국제화 중요성 시사
- 한계: 원화 국제화는 장기적 과제이며 즉각적 환율 안정 효과는 제한적

4. 신현송 총재 체제의 딜레마와 투자자의 관점

커뮤니케이션 딜레마:

시스템 안정 중시 발언: 학자적 관점에서는 옳으나, 시장은 원화 약세 용인으로 오독 가능성
과거 발언: "환율 수준 자체에 큰 의미를 두지 않는다" → 고환율 압력 지속 속 시장 불안 야기
결론: 이론적 처방이 시장의 즉각적 반응을 기다려주지 않음

투자자가 주목해야 할 점:

환율을 금융 시스템 압력계로 인식: 수출 호재가 아닌 금융 시스템의 스트레스 지표로 봐야 함
주요 관찰 지표:
- NDF와 서울 현물 환율 차이: 투기 세력의 영향력 파악
=> 새벽 2시 및 평일 24시간 가동 체제로 전면 전환 (07.06)
- 외국인 채권/주식 자금 흐름:
주식 매도 vs. 채권 매수 (국채 지수 편입으로 장기 자금 유입)
채권 매수는 환율 방패 역할하나, 환율 급락 시 위험 요인으로 작용 가능
=> WGBI(세계국채지수) 편입(안정적 장기 채권 자금) 효과 보는 중
- 한미 금리차: 격차 축소 시 원화에 숨통 트임
- 달러 및 엔화 동향: 달러는 공포 지표, 엔화는 주변국 변수
향후 시나리오:
- 이란 전쟁 완화 → 유가 하락 → 금융 압력 완화 → 환율 안정
- 전쟁 장기화 → 달러 강세 지속 → 외국인 매도 악순환 심화
- 중간 시나리오: 높은 환율대에서 큰 폭의 출렁임 지속
대미 투자 등 구조적 압력은 국제 정치 영역: 한국은행 단독 해결 불가

긍정적 전환 가능성 (선순환)

양방향 메커니즘: 원화 강세 전환 시 금융 시스템 안정 및 투자 유입 기대
MSCI 선진 시장 승격 기대: 6월 리뷰 결과에 따라 패시브 자금 유입 가능성

결론 : 환율은 더 이상 단순한 수출 지표가 아닌, 한국 금융 시스템의 취약성을 보여주는 지표

약한 원화는 수출 호재보다 금융 긴축을 먼저 불러옴
신현송 총재는 금융 증폭 원리, 통화 약세의 돈줄 조이는 메커니즘 등을 연구해 온 전문가
그의 처방이 통할지는 향후 몇 달간 지켜봐야 할 것

영상 링크

https://www.youtube.com/watch?v=f_VrReDU3rk&list=PL6-7dDwF-6L_VOzT-JmTFiwpXYUXj-jFA&index=15

월가아재 영상 링크

[프로젝트 회고] 퀘스트마인 리워드 앱 리뉴얼 개발

yubi5050 — Mon, 1 Jun 2026 09:13:04 +0900

개요

아이브 코리아에서 진행한 '퀘스트마인(리워드 앱)' 리뉴얼 프로젝트에 대한 회고 입니다.

약 1년 4개월(25년 1월 ~ 26년 4월) 동안 기존 앱 서비스 코드와 DB를 전면 재구축하고, 수년 간 쌓인 레거시 데이터의 마이그레이션 작업을 진행했습니다. 이후 베타테스트를 거쳐 리뉴얼 된 정식 버전을 출시하였고, 안정화 된 제품을 바탕으로 최근까지도 서비스 고도화를 진행하였습니다.

프로젝트 진행 과정을 되돌아보면, 순탄치 않다고 느꼈던 순간이 여러번 있었던 것 같습니다. 초기 방향성이 제대로 잡히지 않은채 시작된 프로젝트는 중반에 많은 흔들림이 있었고, 리뉴얼 중단 논의 등과 같은 극단적인 위기도 발생하게 되었습니다. 당시에 그런 부정적인 이슈들로 인해 팀원 모두가 답답함을 느끼며 힘들어 했었는데 서로 격려해가며 조금씩 나아갔고, 결국엔 마침표를 찍을 수 있었습니다.

1년여 기간 동안 겪은 당시의 상황, 좋았거나 아쉬웠던 점 들을 글로 남기고 싶었고, '어쨌든 버티면 결말엔 도달한다', '완료를 하지 못했을 때를 생각하면, 어떻게든 완료 해 결과를 낸 것은 잘한일..' 이라는 그런 가치가 저에겐 남은 것 같습니다. 만약 이후 비슷한 어려운 상황을 마주하는 상황이 오더라도 묵묵히 같이 노력해 완료한 이때의 기억을 떠올리면, 다시 이겨 낼 에너지를 얻을 수 있지 않을까 생각합니다.

퀘스트마인 서비스 개요

한 줄 소개: 게임 미션 수행부터 플레이 타임 측정기반 보상 까지, 유저의 활동을 포인트로 전환하는 리워드 앱테크 플랫폼

주요 기능

미션형 리워드 시스템 : 게임 설치, 사전예약, 특정 컨텐츠 참여 등의 수행을 통해 포인트 적립
실시간 플레이 타임 측정 : 유저의 게임 플레이 시간을 트래킹하여 시간 비례형 보상 지급
다양한 몰입형 콘텐츠 : 채굴, 일일 미션, 뽑기 등 유저 참여를 유도하는 게이미피케이션 콘텐츠
미션 기반 리워드 : 앱 설치, 사전예약, 특정 미션 클리어 등 다양한 활동을 통해 점수 및 포인트 획득
보상 교환 : 적립된 포인트를 기프티콘 및 다양한 상품권으로 즉시 교환 가능한 리워드 시스템
랭킹 시스템 : 앱 내 활동 데이터 기반의 랭킹 시스템을 통해 경쟁 요소를 통한 리텐션 강화 및 추가 보상 제공

https://play.google.com/store/apps/details?id=kr.ive.quest_mine&hl=ko

리뉴얼 프로젝트 배경

리뉴얼 프로젝트는 다음에 배경과 여러 긍정적인 목적성을 가지고 시작 되었습니다.

프로젝트 배경

기술 부채 및 운영 효율성 저하: 기존 안드로이드/PHP 레거시는 타 메인 서비스의 코드/DB 테이블 등과 결합되어 강한 의존성 구조를 가지고 있었으며, 또한 전담 관리자 부재와 맞물려 작은 수정에도 사이드 이펙트 발생이나 기술적 의사결정 및 서비스 개선이 장기간 정체되는 구조였음
서비스 정체와 플랫폼 확장 니즈: 5년 이상 된 앱의 발전이 없다보니, 지속적인 유저 감소가 이루어지는 추세였고, 추세를 반전시키기 위한 사용자 경험 개선과 iOS 플랫폼 확장 및 앱 서비스의 지속적인 운영 등이 필수적인 상황이였음
비즈니스 연속성 위기 : 구글 스토어 정책 변화(라이브러리 지원 중단 등)로 인해 앱 서비스 중단이라는 구체적인 데드라인이 명시되었고, 이에 따라 신규 앱 개발 혹은 기존 서비스 업데이트에 대한 전략적 결정이 필수가 됨
우리팀의 제품 : 개발실 팀 자체에서 빠르고 민첩하게 주도하여 사이클을 운영할 수 있는, 개발실 내의 제품을 확보 해보면 좋겠다의 내부 의견과 목표가 있었음

프로젝트 진행

1. 프로젝트 초기 설계 및 핵심 기능 개발

기간 : 25년 1월 ~ 25월 4월

사용 기술 : Python (FastAPI), MySQL

핵심 내용

코어 도메인 재설계 및 로직 고도화 : 유저, 퀘스트, 사전예약, 랭킹 등 서비스의 핵심 도메인의 모델과 복잡한 비즈니스 로직을 재설계하여 구현함. 특히 기존 구조의 한계점 등을 고려하여 로직을 재구성함으로써, 향후 서비스 확장시에도 유연하게 대응 가능하도록 설계를 진행함
배치 프로세스 설계 및 서비스 분리 : 서비스 운영을 위한 다양한 배치성 작업을 재설계 하고, 배치 로직 실패/실패 후 복구 등의 상황이 고려된 코드로 작성함. 또한 파일 관리 서비스등 여러 공통된 기능들을 Lambda 환경으로 분리하여 서버 부하를 분산하고 안정적인 서버 환경이 되도록 구성함
기존 몰입형 콘텐츠 고도화 : 채굴, 일일 미션, 뽑기 등 유저 참여를 유도하는 게이미피케이션 콘텐츠들을 기존에 누적되어 있던 유저 요구사항들을 함께 개발을 진행 하여, 유저 중심의 편의성 개선으로 긍정적인 리뉴얼 경험을 유도 하고자 함
어드민 시스템 독립 및 운영 효율 개선 : 타 서비스와 결합되어 있던 어드민 도메인을 독립적으로 분리하여, 유지보수 독립성을 확보하고자 함. 또한 CS 처리 과정에서 도출 된 운영팀의 페인포인트를 참고하여 API 맟 자동화 기능 등을 추가해, 이전의 비효율적인 CS 처리 업무에 대한 생산성을 확보하고자 함

회고

프로젝트 초반은 다들 열정이 넘쳐, 새 제품에 대해 적극적으로 아이디어도 내며 임하는 등 활발하게 진행되었었다.
개발 협업 및 속도 : 백엔드는 나 포함 2명이서 진행하게 되었는데, 약 4개월 간 밀도 높게 개발을 진행하였다. 개발 극 초기 단계에서 프로젝트 구조나 스타일을 맞추기 위해 PR을 몇 번 만 진행하였고, 이후에는 셀프 머지(Self-merge) 및 핵심 내용 중심의 간결한 공유를 하는 방식으로 진행해 많은 양의 코드를 속도감 있게 큰 문제 없이 모을 수 있었다. (사실 직전 프로젝트에서의 협업 경험도 있어, 서로의 작업 스타일, 생각 등이 많이 공감대가 있어 조금 더 수월했던 것 같다. )
레거시 '블랙박스' 서비스: 기존 프로젝트 코드베이스는 히스토리가 소실되어 있거나, 특정 사람에게만 정보가 종속되어 있어, 히스토리 추적 및 분석에 어려움이 있었다. 이에 담당자에게 양해를 구하고 2~3시간 씩 붙잡고 물어보고 정리해서 팀에 공유하는 등의 작업을 여러번 진행했다. 또 리뉴얼 제품으로서의 유저의 추가 요구/개선 사항들도 같이 반영 하려다 보니, 다소 정리가 복잡한 경우도 더러 있었다.
프로젝트 초기 앱과 어드민을 포괄한 전체 시스템에 대한 충분한 정리 없이 앱 쪽의 개발 위주로 먼저 착수되었었다. 그러다 보니, 앱과 어드민 간의 기능 동기화가 이루어지지 않는 문제가 종종 발생하였고, 또한 아무래도 어드민보다 앱쪽에 팀 논의 중심이 관성적으로 맞춰 진행되다 보니, 어드민 제품 개발시 진행에 다소 어려움이 있었다. (ex. 앱에는 있는 기능인데, 어드민에는 관련 개념이 없다거나, 기능 공유가 안되어 있다거나 등)
콘텐츠 개선 과정에서는 팀원들이 더 좋은 제품을 만들기 위해 많이 고민하였던 것 같다. 예를 들어 액션 인터렉션의 밀리초 단위의 시간 조절에 대해 토론이 벌어졌었고 (ex. 액션 중에 돌덩이 굴러오는게 있는데, 2초가 낫냐, 1.5초가 낫냐 등) 고갱님께서는 최종 내 의견을 반영 해주셨다.
차후 지속적인 서비스 운영을 위해, 프로젝트 진행 도중 발견된 기획적·기술적 개선 사항을 모두 백로그로 기록해 두었다. (이것은 리뉴얼 런칭 이후 서비스 고도화 과정에서 귀한 자산으로 쓰이게 되었었다.)

2. 프로젝트 과도기 및 위기

프로젝트 과도기 기간 이자, 프로젝트 중단 논의까지 갔었던 모두가 가장 힘들어했던 기간이였다.

기간 : 25년 5월 ~ 25월 6월

핵심 내용

제품 정체성에 대한 인식 격차와 의사결정 혼란 : 리뉴얼이란 목표에 대해 경영진은 기존 데이터 흐름, 다운로드 수, 디자인 스타일 모두를 그대로 유지하는 '리뉴얼' 관점의 제품을 지향한 반면, 실무진은 기존 데이터, 히스토리와 단절된 새로운 UX와 디자인 스타일을 적용한 ‘복제 성격의 신규 제품’으로 방향을 목표하고 있었음. 이 같은 인식 차이가 조율되지 못한 채 체류되자, 뱃사공이 점점 많아지며, 개발 방향이 수시로 번복되게 되었고 프로젝트 자체가 장기간 정체되는 상황을 맞이하게 됨.
레거시 '블랙박스'의 문제점 : 개발이 심화될수록, 기존 시스템의 복잡하게 얽힌 '블랙박스'형태의 레거시 로직들이 발견되었고, 문서화되지 않은 레거시 설계와 비즈니스 로직은 당초 예상한 이전 규모 비용을 한참 상회 만들었으며, 이는 전체 프로젝트 일정에 큰 부담으로 작용하게 됨
정보 파편화와 과도한 소통 비용: 잦은 방향성 수정은 정보의 파편화를 초래하게 되었고,.구 버전과 신규 버전 사이의 차이를 팀 외부의 QA 담당자에게 설명하고 조율하는 과정에서도 막대한 커뮤니케이션 비용이 발생하여, 실무진에게 업무 부하가 가중되었음
이러한 혼란을 해결하기 위해, 실무진이 직접 전면에 나서 파편화된 비즈니스 로직과 히스토리를 문서화하고, 이를 바탕으로 체계적인 QA 가이드 등을 수립하였음. 또한 정체된 의사 결정 문제를 해결하고자 ‘베타 테스트’를 제안하였고, 때마침 기존 앱 서비스가 8월 말 부로 종료된다는 구글 측의 데드라인 통보가 더해지며, 최종 베타 테스트를 통한 피드백 수렴 후 개선사항 반영 및 런칭하는 것으로 방향성이 합의 정리 되었음

회고

이 과도기는 사실 초기부터 느끼던 모호함/불편함 등을 제대로 짚고 넘어가지 못한 것들이, 쌓이고 쌓여 결국 수면 위로 드러나게 된 것 이라 생각한다.
가장 아쉬웠던 건, 제품의 방향성을 동기화 하고, 경영진과 실무진 사이의 의도를 명확하게 조율해 줄 ‘중간 관리자’ 혹은 ‘책임자’의 부재였다. (별개로 프로젝트 합류 초기에 '무언가 잘못되었다' 는 불안함을 느껴 팀 리더에게 조언을 구하기도 했으나, 결과적으로 명확한 R&R이 조정 되지 않고 방치 진행되다 보니 결국 나중엔 소모적인 논쟁 과정으로 많은 비용이 소모되었다.
또한 배에 이상한 사공들이 늘어나면서 혼란은 중첩되었고, 투입된 사람 대비 작업 진행이 계속 지지부진한 상황이 되어, 이는 팀의 실무진의 의지를 크게 꺾어놓음과 더불어 작업자로서도 성취감보다 회의감이 많이 드는 기간이였다. (+팀 내 다른 프로젝트를 진행하는 인원들도 이로 인해 제대로 된 지원을 못 받는 등의 여파가 전달됬다.)
결국 문제를 해결하기 위해 실무진들이 많이 전면으로 나서게 되었고, 요구사항의 본질적인 부분을 이해하여 우선순위를 직접 조율하는 등 한참을 고생 하고서야 다음 단계로 넘어 갈 수 있었다.

3. 베타 테스트 및 정식 출시 (+데이터 마이그레이션)

기간 : 25년 7월 ~ 25년 9월

핵심 내용

베타 테스트를 통한 최종 방향성 확립 : 약 100명의 기존 유저들을 대상으로 내부 테스트를 진행하고 의견을 수렴한 결과 대부분 많은 유저들이 트렌디한 UI와 앱 방향성에 만족도를 보였음. 다만 촉박한 데드라인으로 인해, 반영 사항에서는 디테일한 부분은 우선 제외됨. 최종 의사 결정은 기존 서비스의 히스토리와 데이터 흐름은 유지하되, UI/UX등은 개선된 형태의 리뉴얼로 진행하는 것으로 최종 정리됨.
데이터 마이그레이션 : 기존 시스템의 데이터를 신규 플랫폼으로 안전하게 이전하기 위해선 정교한 마이그레이션 전략이 요구되었음. 약 100여개의 DB를 일일이 분석하여 최종 서비스 연속성에 필요한 유저 정보, 포인트, 핵심 콘텐츠(퀘스트) 참여 내역 등은 이전 대상으로 분류하고, 불필요 로그성 데이터인 알림 내역 등의 정보는 과감히 제외하여 데이터 효율화를 높임. 이후 각 테이블별로 맞춤형 마이그레이션 스크립트를 작성하고, 데이터 정합성 검증(ex. 데이터 개수, 테이블 관계 정합 등)을 여러번 진행하며 런칭을 준비함
정식 런칭 : 서비스의 연속성을 위해 런칭은 포인트 정산이 종료되는 8월 마지막주 토요일 18시를 기점으로 진행. 세부 타임테이블을 수립하고, 진행할 스크립트를 리허설 하며 위험요소를 반복적으로 점검함. 18시 기존 앱에 서비스 점검 화면 처리 후 ~ 0시 신규 버전 업데이트를 진행 및 오전 2시까지 모니터링 및 테이블 로그를 모니터링하며 서비스 전환을 최종 완료함
안정화 작업 및 운영 지원 : 런칭 후 9월 한 달 간은 서비스 안정화에 집중하며 라이브 환경에서 발생하는 각종 변수에 대응함. 마이그레이션 과정에서 발생한 데이터 정합성 이슈, 서비스 이용자 증가에 따른 데드락 분석, 기타 버그 제보등을 개선하며 시스템 가용성을 확보하고자 함. 또한 촉박한 데드라인으로 어드민에서 지원하지 못했던 기능을 CS 등을 쿼리로 지원하며, 기능화 하여 운영 효율을 빠른 시일 내 보완함

회고

긴 과도기를 거치며 많이 소진 되었던 팀 분위기는 유저들의 베타 피드백 의견을 받아보며 많이 회복되었다. 유저들이 생각보다 열심히 의견을 남겨주기도 했었고, 팀 모두가 같이 회의실에 모여 수집된 베타 피드백을 리뷰하며, 더 나은 서비스를 고민했던 시간은 좋은 동기 부여가 됬었다. (재미로 고갱님(FE)께서는 맘에 안드는 일부 유저의 피드백을 보고는 우스겟소리로 부정하며 팽하자고도 했었음)
마이그레이션을 준비 하는 기간은 정말x100 개발자란 직업을 한 이래로, 가장 어려웠던 기간이였던 것 같다. 수십개의 테이블이 6시간 안에 안정적으로 이관이 완료될 수 있게 테이블마다 스크립트를 작성하고 검증이 필요했고, 런칭 날이 가까워 질 수록 홀로 시스템을 책임져야 하다 보니 외로운 순간도 있었고, 부담도 많이 되어 심적 부담감이 점점 커졌었던 것 같다.
함께 고생한 동료 백엔드 개발자가 불가피하게 휴직을 하게 되었는데, 마지막 까지 정말 최대한 애쓰고 간게 나중에 남겨진 코드에서도 티가 났다. 그래서 그 동료가 나중에 돌아왔을 때, 이 제품이 일하기 좋은 환경으로 만들어 두고 싶다는 개인적인 책임감도 가지게 되었었다. (이 프로젝트에 대해 많이 하고 싶어 했었기도 하고, 가기 전까지 무리해서 고생을 많이 했었다.)
정식 런칭 당일(주말 회사 출근은 또 처음이라 카드키를 안 챙겨서 밖에 한 2시간 서있었는데 팀 리더님이 기꺼이 출근해서 구해주심..) 그동안의 수 번의 리허설 과정에도 불구하고, 문제점이 발견되어 끙끙대다, 점검 시간을 30분 연장해야 했을 때, 그리고 그 30분 간의 긴장감은 아직도 생생하다... 새벽 2시 까지 로그를 확인하다, 택시를 타고 퇴근 하던 길에서는 후련함과 '어쨌든 끝내서 다행이다' 라는 안도감이 많이 들었던 것 같다.
이 기간을 돌이켜봤을 때 개인적으로 큰 도전 이였던 것 같고. '어쨌든 버티면 결말엔 도달한다', '어떻게든 끝까지 해낸다'는 그런 목표가 성취로 돌아오며, 느낀점이 참 많았던 것 같다.

4. 추가 리뉴얼 및 수익화 모델 확장

기간: 25년 10월 ~ 25년 12월

핵심 내용

UX 추가 개편 : 초기 리뉴얼에서 부족했던 디테일 사항들을 페이지별로 보완하고, 경영진이 강조하는 서비스 핵심 요소등을 좀 더 부각하기 위한 추가 개편을 약 2개월 간 진행하였음.
수익화 모델 구축 및 제품 고도화 : 광고 SDK를 연동하여 수익 창출 기반을 마련하고, 또한 신규 몰입형 컨텐츠들을 배포함. 12월에는 크리스마스 등의 대규모 이벤트 시스템 개발을 지원하며 서비스 활성화를 도모함
운영 체계의 효율화 : UX 개편과 신규 컨텐츠 추가 등이 맞물리며, 백엔드에서는 짧은 시간 동안 많은 API들이 deprecated 및 신규 개발 되었고, 늘어난 API 버전들을 관리하기 위해 'API 하위 호환 지원 정책', 기술 부채의 주기적인 청산을 위한 'API 최소 버전 지원' 등 현 조직 규모에 맞는 지속 가능한 API 관리 체계등을 주도적으로 수립함

회고

이번 기간은 '두 번째 리뉴얼'이라 정의할 만큼, 초기 데드라인 등으로 생략되었던 디테일을 개선하고 시스템의 코어 안정성을 확보하는 과정이였다. 특히 앱 서비스의 특성상 강제 업데이트가 어려운 환경에서 API의 버전이 빠르게 올라가고 교체 되다 보니, 버전마다 배수로 증가하는 유지보수 리소스가 생기게 되었다. 이를 해결하고자 프론트팀과 긴밀히 협력하여 하위 호환성 정책, API의 주기적인 청산 반영 등을 정립하게 되었고, 그 논의 과정에서 앱 서비스 생태계에 대한 이해도가 많이 높아졌던 것 같다.
런칭 후 발생한 기술적 이슈나, 어드민 기능 보완 등 11월까지 서비스의 근간을 견고히 다지었다. 두 번에 걸친 변경에 대해 '지속적인 개선'에 대해 긍정적인 리뷰를 남겨주는 유저도 있었지만, 잦은 변경으로 인한 적응의 어려움등으로 지표의 하락을 겪기도 했었다. 이후 근간을 바탕으로 12월에는 크리스마스 이벤트를 진행했는데, 이후 유저가 소폭 반등하며 제품의 성장 가능성을 확인한 것은 좋은 보람이였다.
아쉬웠던 점은 개발 과정에서 제품의 본질적인 경쟁력(광고 없는 환경, 합리적인 포인트 지급 등)과 전략적 운영 방향(과도한 광고 유도와(1분~2분 광고 위주, 광고 중간 클릭 필수), 비효율적인 포인트 지급/회수 구조 등 공감하기 어려운 의사결정이 몇 번 나왔고, 이에 대해선 아쉬움이 많이 느껴졌다.
결과적으로 이 기간은 짧은 시간 동안 압축적인 경험을 통해 개발자로서 앱 서비스에 대해 이해하고 기술적 고민도 많이 해 보고 배울 수 있었던 기간 같았다. 비록 전략적 의사결정에 대해 개인적인 아쉬움은 있었지만, 그런 걸 생각하는 과정에서도 배운게 있어 전체적으로 성장이 많이 된 기간이였던 것 같다.

5. 자유로운 서비스 확장 및 효율성 개선

기간: 26년 1월 ~ 25년 4월

핵심 내용

서비스 확장 및 콘텐츠 고도화 : 프로젝트 초기 목표였던 '유연한 서비스 확장'이 본격적으로 구현던 기간. '매치퍼즐', '카드 맞추기' 등 게임형 콘텐츠를 빠르게 추가하였고, '모으기 탭'의 API화 및 플레이 타임 기반의 보상 로직을 설계하여 유저 리텐션(Retention)을 강화하는 등의 고도화를 진행함
정교한 푸시 타겟팅 시스템 : 기존 푸시 로직을 세분화하여 타겟팅 로직을 고도화하고, 예약 발송 기능 및 제약 조건 설정 등을 통해, 랭킹전 시작, 신규 콘텐츠 알림 등 서비스 상황별로 최적화된 푸시 수신/발송 체계를 구축함.
개발 생산성 향상 : 팀에 Claude 등 AI 도구를 적극적으로 도입하여 개발 업무의 효율을 높이는 시도를 진행함. AI를 사용하더라도 팀 내 일관된 코드 스타일과 패턴을 유지하기 위해 rules.md를 설계하는 등, 협업 효율을 높이고 코드 퀄리티를 다듬음
PM/기획 관리 역량 수행: 개발 업무와 더불어 팀의 전체적인 생산성을 높이기 위해 스프린트 관리 및 PM 역할을 주도적으로 수행하게됨. 운영팀의 요구사항이나 파편화 된 기술적 백로그를 체계적으로 분류 및 우선순위를 조율하였고, 팀 내에서 유휴 자원 없이 속도감 있게 개발이 진행이 될 수 있도록 보조 역할을 수행함 (Jira 티켓과 Slack 등에 파편화된 요구사항을 통합 관리하고, 팀 내외부의 스프린트 규칙을 보다 명확하게 정리함)

회고

이번 기간은 팀이 프로젝트 시작 시점부터 목표했던 '자유로운 서비스 확장'이 마침내 기술적/조직적으로 구현된 느낌의 시기였다. 지난 1년 간 겪었던 레거시 문제와 의사결정의 혼란과 불안정한 시기를 거쳐, 이제는 기획 요구사항이 빠르게 서비스로 구현 될 수 있는 시스템과 프로세스가 어느정도 완성된 기간이였다.
특히 이 기간에서는 개발자로서의 역할 외에도, 스프린트 관리 등의 PM 업무를 수행하며, 산재해 있는 일감 들을 한데 모으고, 구조화하여 관리한 결과, 처리 속도와 전체적인 진행 효율 면에서 팀의 높은 생산성이 발현 되어 개인적으로도 속시원 하기도 했고, 뿌듯하기도 했던 것 같다.
또한 휴직을 마치고 복귀한 동료와 함께 AI 도구를 적극적으로 활용하며, 생산적인 티키타카를 주고 받으며 AI 환경에서도 협업 안정성을 높이며 개발해 나갔던 과정도 인상적인 경험이였다.

마치며

앞선 프로젝트 할 때도 마찬가지였지만 지난 1년 4개월 간의 시간은 개발자로서 단순 기술적인 성장을 넘어, 팀으로서 함께 위기를 마주하고 이겨낸 의미있는 시간인 것 같습니다. 개인적으로는 리뉴얼 출시일에 마이그레이션이라는 거대한? 과업을 완수하며 느꼈던 어떤 긴장감과 해방감. 그리고 최근 4개월 간의 '자유롭고 속도감 있는 개발' 실현이 가장 기억에 남는 것 같고, 앱 서비스의 전 과정을 온몸으로 겪어내며, 제품의 탄생부터 안정화, 고도화에 이르는 모든 과정을 배울 수 있었던 것도 많이 성장의 계기가 된 것 같습니다.

복귀한 동료와 비록 함께 더 긴 시간을 나누지 못한 것은 아쉽지만, 그동안 함께 만든 서비스를 바탕으로, AI를 도입하여 협업을 하는 등 마지막에 그래도 같이 다시 보고 일하고 갈 수 있어서 좋았던 것 같습니다.

지난 1년간 스스로가 너무 치열하게 몰입했는지 번아웃이 왔다고 느껴지기도 했고, AI 시대에 개발자 커리어를 한 번 돌아보며 깊이 있게 고민해 보고도 싶어, 이 프로젝트를 마지막으로 회사를 떠나게 되었습니다. 마지막에 어느정도 적정한 시점에 떠나는 것 같았고, 그동안 숱한 시행착오를 겪으며 미션을 완료 하기 위해 열심히 노력했던 모든 시간이, 다음 여정을 위한 좋은 자산이 되지 않을까 싶습니다.

결론은 많이 배우고, 성장한 좋은 시간이였던 듯 합니다! 이만 끝!

[결제서비스] 결제 시스템 유형 및 설계 이해

yubi5050 — Fri, 22 May 2026 16:00:02 +0900

1. 결제 서비스 카테고리 분류

비즈니스 모델에 따른 결제 서비스의 카테고리 비교

카테고리	핵심 로직	기술적 특징	예시
직불/구매형 (Direct Payment)	결제 즉시 재화나 서비스가 제공됨	결제 성공률과 응답 속도가 중요 (동기식)	쇼핑몰 상품 결제, 배달 주문
충전/예치형 (Prepaid/Wallet)	먼저 결제해서 계좌에 돈을 담아두고(충전) 서비스 이용 시마다 잔액에서 차감	데이터 정합성과 히스토리 관리가 핵심	카카오페이 머니, 네이버페이 포인트, 찾아옥외 광고비 충전
구독/정기형 (Subscription)	카드 등록 및 주기적 자동 결제 권한 제어	빌링키 관리와 보안이 핵심	넷플릭스, 쿠팡 와우 멤버십
후불/신용형 (Postpaid)	서비스 이용 후 나중에 대금을 정산함	한도 관리 및 리스크 통제가 핵심	신용카드, 통신비, 배달 결제

2. 결제 수단별 특징 및 처리 방식

사용자가 대금을 지불하는 도구에 따라 기술적 과제가 상이함.

결제 수단	특징	처리 방식 (시스템 관점)
신용카드	결제 즉시 승인, 부분 취소 가능	동기식(Sync) 처리 (결제 즉시 결과 반환) 가장 표준적인 결제 방식
가상계좌	발급 후 실제 입금 대기	비동기(Async) 처리 (웹훅(WebHook)을 통한 입금 확인 필수) '발급' 상태와 '입금 완료' 상태를 명확히 구분
휴대폰 결제	월 한도 및 익월 합산 청구	월별 한도가 존재하며 익월 합산 청구. 결제 요청 전 통신사 한도 조회 선행 필요
간편결제	플랫폼(카카오/네이버 등) 인증 기반	SDK 연동을 통한 토큰 기반 인증 처리가 중심 각 플랫폼의 연동 규격 준수가 중요

3. 결제 시스템의 기술 키워드 이해

1) 웹훅(WebHook)과 결제 검증 (Verify)

결제 성공 여부를 외부(PG사)로부터 통보받는 핵심 통로입니다.

유효한 검증인지 확인 : 클라이언트가 전달한 값은 언제든 위변조가 가능하므로, 웹훅을 받으면 반드시 실제 결제 금액이 일치하는지 재검증(Verify)하는 요청을 보내야 함 (예시: 해커가 결제 금액을 10,000원에서 100원으로 조작해서 서버로 보내도, 우리 서버가 다시 PG사에 "10,000원 결제된 거 맞지?"라고 물어봐서 가짜 결제를 차단)
멱등성(Idempotency) : 동일한 웹훅이 중복 수신되어도 머니가 두 번 충전되지 않도록, 결제 고유 ID를 기준으로 이미 처리된 상태인지 확인하는 로직이 필수 (예시: 네트워크 오류로 똑같은 입금 완료 웹훅이 3번 도착해도, 시스템이 "이미 1번째 요청 때 충전했네!"라고 판단해 2, 3번째 요청은 무시)

2) 데이터 정합성 (Transaction & Lock)

머니 충전과 소진이 빈번한 시스템에서는 정합성이 최우선

동시성 제어 : 잔액 조회 후 차감하는 과정에서 레이스 컨디션(Race Condition)이 발생하지 않도록, DB 락(Pessimistic/Optimistic Lock)을 사용하여 데이터 일관성을 유지해야함 (예시: 잔액 5,000원인 유저가 3,000원짜리 결제를 광클해서 2번 시도할 때, 한쪽 결제가 처리되는 동안 다른 쪽을 대기시켜 잔액이 마이너스가 되는 대참사를 막음)
원자적 처리 : 머니 증감과 히스토리 기록은 반드시 하나의 트랜잭션 내에서 처리되어야 함.

3) 장애 대응 및 방어적 설계

웹훅 유실 대비 : 네트워크 장애로 웹훅이 유실될 가능성을 열어두어야 하며, 이를 위해 PG사 어드민을 통한 수동 재전송 기능이나, 주기적으로 미처리 내역을 확인하는 조회 API(Polling) 로직을 함께 구현하는 것이 안전함 (예시: 분명 입금했는데 웹훅이 안 온다면? 주기적으로 우리 서버가 결제 상태를 직접 조회(Polling)해서 입금된 내역을 찾아서 정보를 재구성해 다시 호출하는 등 으로 해결함)
로그와 모니터링 : 결제 과정에서 발생하는 에러(Traceback)는 즉시 알림을 받을 수 있도록 시스템화, 관리자가 수동으로 결제 상태를 교정할 수 있는 관리자 페이지(Admin Dashboard) 내 결제/환불 기능이 필요 (PG 사 같은데서도 화면을 제공하여 최소한 방어 가능)

4) 결제 서비스 고도화

빌링키(Billing Key)와 토큰화: 실제 카드 정보를 내 서버에 보관하는 것은 위험하므로, 유저에게 카드 번호를 매번 묻지 않고, 보안이 뛰어난 PG사 서버에 카드를 저장한 뒤 우리는 결제 권한인 '빌링키'만 보관해 안전하게 정기 결제를 진행함
부분 취소(Partial Refund): 단순 취소보다 복잡하며 잔액 관리가 필수 (예시: 10만 원을 결제하고 3만 원만 환불해야 할 때, 남은 7만 원의 흐름을 히스토리 테이블에 정교하게 기록하여 결제 금액의 투명성을 보장)
분산 트랜잭션(Saga 패턴): 결제 서버와 등록 서버가 분리된 경우의 보정 작업. 시점(Timing)'과 '보상 작업(Compensation)':시점: 등록이 실패했다고 확정되는 '즉시' 트리거되어야 함 (예시: 식당에서 계산(결제 승인)은 이미 했는데, 주방에서 요리 재료가 다 떨어져 요리(광고 등록)를 못 하는 상황. 이때 서버는 즉시 계산대로 달려가서 "방금 결제하신 거 취소해 주세요"라고 외쳐야함)
분산 트랜잭션(Saga 패턴) 방법 : 소스(방법): 이벤트 기반 처리 (Message Queue): 광고 서버가 "등록 실패" 이벤트를 발행(Publish)하고, 결제 서버는 이 메시지를 구독(Subscribe)하고 있다가 즉시 환불 로직을 실행 (가장 많이 쓰이는 방식) / API 호출 (Sync/Async): 광고 서버가 에러를 감지한 직후, 결제 서버의 취소 API를 동기적으로 직접 호출 / 상태 기록 (Outbox Pattern): 결제 서버가 결제 성공 직후 '미확정' 상태로 기록하고, 광고 서버로부터 '성공' 응답을 받으면 최종 '확정' 처리 + 응답이 없거나 실패하면 보상 트랜잭션을 실행.

[프로젝트 회고] 옥외 광고 중개 플랫폼 개발

yubi5050 — Wed, 20 May 2026 18:16:15 +0900

개요

아이브 코리아 입사 후 첫 진행한 프로젝트(옥외 광고 중개 플랫폼)에 대한 회고입니다.

약 1년 3개월(23년 3월 ~ 24년 5월) 동안 동안의 신규 웹 서비스 설계 및 구축부터 배포, 유지보수 및 안정화 과정을 기록하였습니다.

평소 일하며 매일의 데일리를 메모에 적어두는데, 그 내용을 바탕으로 + 머리 구석구석의 작은 메모리 파편들을 영끌하여.. 역 구성? 하였습니다. 그래서 다만.. 현재는 시간이 좀 지났다 보니, 다수의 메모리들이 기억 왜곡 등으로 인해 살짝 미화? 되어 있을 수 있음은 감안을... 필요할 것 같습니다.

개인적으로는 우리팀이 꾸려진 후 모두의 첫 프로젝트라 모든 팀원들이 서비스의 성공을 위해, 한 마음으로 큰 열정을 다 같이 쏟았던 그런 뜻 깊은 시간으로 기억하고 있습니다 (물론 이것도 저만의 '기억 왜곡에 의한 미화' 일 수도 있음)

찾아옥외 프로젝트 개요

한줄소개 : 옥외 광고 시장의 정보 비대칭 문제를 해결하고, 광고 청약부터 운영·관리까지의 전 과정을 디지털화한 옥외 광고 중개 플랫폼

주요 대상 사용자 : 광고대행사, 광고주, 일반 사용자 / 매체사 / 운영자

주요 기능

옥외 광고 매체 탐색: 지도 기반 UI를 통해 광고 가능한 전국 옥외 매체 한눈에 확인, 위치·조건별 손쉽게 탐색
간편 견적 및 청약 프로세스 지원: 광고주는 여러 매체에 대한 견적을 한 번에 요청하고 비교, 청약 과정 간편하게 진행 가능
매체 소개서 및 견적서 생성 기능: 매체사는 손쉬운 등록·수정 UI를 통해, 매체 소개서 및 견적서를 손쉽게 제안·관리 (+PDF 화)
매체 운영 및 빈 시간대 관리: 매체사는 CMS를 통해 광고 가능 빈 시간대를 확인하고, 효율적인 운영 관리
어드민 운영 관리 플랫폼 : 유저 회원 가입 승인 및 반려, 대용량 CSV 파일을 활용한 매체 일괄 등록 등 서비스 전반을 통합 관리

프로젝트 진행

1. 서비스 기반 구축 및 팀 ground rules 정립

기간 : 23년 3월 ~ 6월 (4개월)

사용 기술 : Django, Django Ninja, PostgreSQL

핵심 내용

도메인 모델링: 유저, 캠페인, 광고주 캠페인, 매체 정보(위치·조건), 견적 등 핵심 비즈니스 도메인 간의 데이터 모델링 설계
기능 구현 : 지도 기반 탐색의 바탕이 되는 전국 옥외 매체 정보와 하위 모델들의 핵심 CRUD 개발
기능 구현 : 광고주가 여러 매체를 묶어 한 번에 견적을 요청하고 청약을 진행할 수 있는 로직 구축
개발 문화 및 협업 기틀 마련: 초기 코드 베이스가 없는 백지상태였기에 프로젝트 구조 설계와 Git PR 프로세스 정립을 진행, 팀 내 소통 비용과 혼선을 최소화하기 위한 문서화 작업을 수행

회고

초반에 막 열심히 달렸던 기억.
당시 광고 도메인에 대한 경험이 없어, 가끔 기획서에서 모델간의 관계를 잘못 이해하여 어제 작성한 걸 다음날 고치는 재작업 등을 하기도 했었다. 아! 하면서 많이 깨달았던 시기로 이후에는 내가 이해한 것이 맞는지 기획자에게 물어보는 시간도 많이 갖고, 설명도 직접 해보며 이해한 것이 맞는지 확인하는 시간을 항상 가졌던 것 같다. 그로 인해 역으로 놓쳤던 예외사항들도 발견되고 보완될 수 있었다.
파이썬으로 기존에 작성된 코드가 없었다 보니, '우리 팀'이 쓸 프로젝트 구조를 잡고, 코드 스타일 등을 맞추기 위해 소통하는 것이 좋았지만, 한편으로는 다소 비용이 좀 들기도 했던 것 같다. 평소 나만의 어떤 방식이나 주관도 있는 편이라, 많이 꺼내놓고 얘기하게 되었는데. 결론적으로 상대방의 생각을 이해하는 과정에서 유연하게 사고 하는 것에 대해 많이 돌아보게 되는 계기가 된 것 같다.

2. 배포 환경 개선 및 어드민 시스템 구축

기간 : 23년 7월 ~ 8월 (2개월)

사용 기술 : Reflex, Jenkins, AWS ECR

핵심 내용

Reflex 기반 어드민 시스템 구축: Reflex를 활용해 대시보드 UI/UX를 구현하고, 대용량 Excel 업로드 기능 및 매체 그룹 관리 CRUD를 완성하여 운영 효율성 제고를 수행함
CI/CD 파이프라인 자동화 및 API 고도화: Jenkins와 AWS ECR을 연동하여 기존의 수동 배포 과정을 자동화 파이프라인으로 전환하였으며, 지속적인 API 유지보수와 문서 고도화를 진행함

회고

가벼운 운영/CS 처리를 위해서 왠만한 서비스는 어드민 제품이 꼭 필요한 것 같다. 이왕이면 서비스 API 만들 때 예상되는 부분은 같이 만들어 두는 것도 좋은 것 같음
첨엔 파이썬 기반 UI도 써볼겸, 받아와서 백엔드에서 진행하였는데 (작성하다가 마가 꼈는지, 컴포넌트 가운데 정렬이 안먹길래 야근했는데, 옆에서 보던 프런트 개발자가 딸깍 해결해 버려서 현타옴) 바쁜 FE 개발자 일정 기다려 받느니, 어차피 어드민 도구 없으면 백엔드로 CS 처리 요청이 오니까. 그냥 스스로를 위해 백엔드에서 가볍게 만들어서 기능으로 빨리 내 주어 업무 요청이 안오게 처리하는 것도 좋은 것 같다. (버그 수정 등에도 추가 소통 비용 등 없이 바로바로 하면 되니까)
Reflex와 Streamlit 중에 고민했는데, 개인적으론 다음 부턴 Streamlit 쓸 것 같다. (한창 하다가 Reflex 버전이 0.2.0 매우 초기라 제공 기능이 적음을 너무 늦게 알아서, 쉬운 것도 어렵게 같던..)

3. 맵 성능 개선 및 리팩토링

기간 : 23년 9월 ~ 11월 (3개월)

핵심 내용

지도(Map) 서비스 성능 최적화: 빠른 매체 데이터 증가(15,000개 이상의 마커) 증가로 인한 쿼리 속도 저하 문제를 해결하기 위해 Query Debugger 데코레이터 및 미들웨어를 직접 구현하여 병목 지점 모니터링 및 쿼리 최적화를 진행함
기술적 한계 극복을 위한 UX 중심의 대안 제안: 단순 쿼리 개선만으로는 대량의 마커를 한 번에 내리는 부하를 완벽히 해결하기 어렵다고 판단. 이를 극복하기 위해 초기 로딩 데이터 반경 축소(20km → 5km) 및 네이버 지도를 벤치마킹한 페이지네이션 기반 UI 도입을 제품 팀에 선제적으로 제안하여 반영하였다.
DB 스키마 개선 및 API 버저닝 규칙 수립: 데이터 정합성 확보를 위해 Null 표현 및 Required 필드를 재정립하는 전면 리팩토링 진행. 기존 API 사용 혼선을 줄이기 위해 토스페이먼츠 등의 레퍼런스를 참고하여 팀 내 API 버저닝 규칙을 새롭게 확립하고 합의를 도출하였다.

회고

광고 도메인 특성상 '매체 그룹(1) > 매체(N) > 주소(N)'로 이어지는 복잡한 모델 관계가 있었다. 심지어 매체 1개에 주소가 100개씩 엮여 있는 경우도 있었다. (예를 들면 지하철 7호선 출구마다 설치된 디지털 매체들은 1000개에 달함)
이러다 보니 데이터 수가 예상보다 빠르게 불어났고, 결국 지도 API 호출 응답 시간에 극심한 병목 현상이 발생했고, 백엔드 쿼리 개선만으로는 근본적인 해결이 불가능한 한계 상황이었다.
이때 무조건 "기술적으로 안 될 것 같아요"라고 하기보다 해결을 위해서, 타 서비스들 (중 네이버 지도)은 이 문제를 어떻게 풀었을지 레퍼런스들을 이해해보게 되었고, 그리고 초기 반경 축소와 페이지네이션이라는 대안을 준비해 기획자분을 조심스레 설득했고, 감사하게도 아이디어가 채택되어 최종 반영까지 이어졌다 => 이건 평소 습관으로 가지면 좋을 것 같아서, 다른 서비스 개발자 입장에서 '그들은 왜 이렇게 만들었을까?', '기술적 한계를 어떻게 우회했을까?'를 넓은 시선으로 바라보면 좋을 것 같다 => 이 뒤로 서비스를 보면 뽀개보려는? 분석? 부터 하려는 뇌의 트랜지스터가 먼저 튀어 나오는 직업병 같은게 생긴 것도 같다.
초반에는 기능 구현 속도와 백엔드 팀 내부 협업에만 너무 몰두했던 것 인지, 그러다 보니 API 개수가 늘어남에 따라 관리 (문서화)가 아쉽다는 피드백을 FE(프론트엔드) 개발자분들로부터 받게 되었다. 더불어 특히 FE 파트와 'Null 처리' 관점에 대해 여러번 토론하면서 프론트 개발자 입장을 이해하게 되었다. => 이 때 부터 백엔드의 첫번째 우선 고객은 프론트이다라는 생각이 있다. 고객놈?을 만족 시키면 내 자아가 만족을 느끼더라는 (이 사람이 API 짜주면 좀 편하던데의 평가를 받는 것 또한 나름 개인의 목표, 이젠 근데 AI 때매 살짝 글른 것 같기도 하다.)

4. 패키지 매체 확장 및 결제/프로모션 기능 개발

기간 : 23년 12월 ~ 24년 1월 (2개월)

핵심 내용

제품 고도화 : 비즈니스 모델 확장(패키지/종속 매체 등) 발맞추어 웹서비스 및 어드민 제품을 확장 및 수정함
결제 및 프로모션 시스템 도입: 포트원(PortOne) API를 연동한 충전형 결제 시스템과 프로모션 기능을 신규 도입
테스트 코드 추가 신뢰성 확보 : 복잡한 비즈니스 로직(예산 및 포인트 검증, 결제/정산 로직 등 예외 케이스가 많은)을 안전하게 유지 하기 위한 테스트 코드 작성, 외부 API 통신 격리한 Mocking 기반 단위 테스트 구축
테스트 프레임워크 효율화: 효율적인 테스트 환경을 위해 Fixture(가짜 데이터) 관리 책임을 각 앱 단위로 위임 및 서비스 시나리오와 테스트 시나리오 간의 차이를 정립하여 전체 테스트 수행 속도 및 작성 비용 효율화 등

회고

서비스 규모가 커지면서 제품 안정화를 위해 테스트 코드가 필요하다는 니즈가 생겼다. 하지만 모든 API의 모든 예외 케이스를 다 작성하기에는 비용이 컸기에, "무엇을 우선순위로 두고 먼저 작성할 것인가"에 대해 팀원과 논의했고, 그 결과 우리 팀만의 '테스트 코드 작성 규칙 문서'를 정립할 수 있었다. 결론적으로는 핵심 코어 로직들에 대해서 우선 코드 신뢰성을 확보하는 방향으로 진행하게 되었다. 그 과정에서 같이 고민하고 배운 것들이 많아 블로그에도 정리하게 되었다.
관련 블로그 정리 내용 : https://yubi5050.tistory.com/322

5. 비동기 처리 아키텍처 및 CMS 설계·개발

기간 : 24년 2월 ~ 3월 (2개월)

사용 기술 : RabbitMQ, Celery

핵심 내용

비동기 메시지 큐(MQ) 및 Celery 도입 : 메인 서버의 부하를 경감하고 알림 시스템(알림톡, 문자, Slack, 메일)의 실시간 비동기 처리를 위해 AWS의 RabbitMQ 및 docker 기반의 Celery 환경을 설계하여 도입함
CMS(콘텐츠 관리 시스템) 일정 동기화: 매체사 운영을 위한 CMS 개발의 일환으로, 매체 일정 생성 시 이와 엮인 세부 견적들의 일정까지 자동으로 연동 동기화 되는 다소 복잡한 연쇄 로직을 구현함

회고

API 만 만들다가, 추가 기술 공부하고, 그걸로 시스템 설계하고 구현해서 붙이는게 꽤 재밌었다.

6. 플랫폼 운영 안정화 및 프로젝트 마무리

기간 : 24년 4월 ~ 5월 (2개월)

핵심 내용

포트원 결제/환불 연동 및 웹훅 중복 방어: 가상(Stage) 및 실제(Live) 결제 환경을 철저히 분리 / 부분 환불 발생 시 내부 포인트 시스템에 반영 되도록 로직 개선 / 외부 PG사에서 불규칙 수신 웹훅(Webhook) 중복 호출 문제 방어등 멱등성 로직 구현등을 함
지속적인 테스트 코드 작성 : 정한 우선순위를 바탕으로 테스트 코드 일정을 틈틈히 확보해, 핵심 비즈니스 코드 거의 95% 이상 달성 및 전체 개수 200+ 달성함
배치(Cron) 작업 장애시 백업 개발 : 자동 배치 작업이 예기치 못하게 중단/실패를 대비 하여, 정산 데이터등을 수동으로 복구할 수 있는 백업 API 개발함
내부 복잡한 로직 시퀀스 플로우 차트 문서화 하여

회고

추후 다른 프로젝트에 팔려 갔다, 유지보수 하러 누가 돌아오더라도, 흐름이 이어서 진행될 수 있도록. 마무리 작업의 느낌 (노션의 mermaid)로 작업

시퀀스 플로우 차트

마치며

이 회사에서 처음으로 마주한 프로젝트 였던 만큼, 무엇보다 여러 사람들이랑 같이 고민하고 협업하는 과정이 가장 기억에 남는다. 서로 소통하고 입장을 이해하면서, 하나하나씩 차근히 정리하며 뿌셔 가는 과정이 재미있었던 것 같다. 서비스가 비즈니스 적으로 조금 더 성공했으면 좋았겠지만, 그래도 오프라인 세계에 머물러 있던, 옥외 광고 도메인을 온라인으로 전환하고 디지털 화 하는 과정 속에서 개발자로서 긍정적인 가치를 느낄 수 있었던 것 같음.

1년 넘는 기간 동안 많이 고생한 팀원들에게 큰 respect를!

[DB 마이그레이션] Alembic 도구

yubi5050 — Tue, 19 May 2026 17:47:46 +0900

1. Alembic이란?

Alembic은 SQLAlchemy 모델의 변화(컬럼 추가, 타입 변경 등)를 추적하여

데이터베이스 스키마를 안전하게 버전 관리(Migration)할 수 있도록 도와주는 도구

Alembic을 초기화하면 프로젝트에 alembic/ 이라는 관리 폴더가 생기며,

그 내부에 있는 versions/ 디렉터리 안에서 마이그레이션 파일들이 순차적으로 생성 및 관리 됨

2. Alembic 초기 세팅

1) 패키지 설치
- 파이썬 패키지 매니저(Poetry)를 사용해 SQLAlchemy와 Alembic을 설치

poetry add sqlalchemy alembic

2) Alembic 초기화

- 설치가 완료되면 Alembic 초기화 명령어를 실행

- 뒤에는 관리할 폴더명을 지정 (보통 관례상 alembic으로 지정함)

alembic init alembic

실행 후

- 프로젝트 루트에 alembic.ini (환경 설정 파일) 생성됨

- 프로젝트 루트에 alembic/ 폴더 및 하위 파일(env.py, versions/ 등) 생성됨

3) 데이터베이스 연결 정보 설정 (alembic.ini)

- alembic.ini 파일을 열어 내 데이터베이스 URL 주소를 입력

# alembic.ini 파일 내부
sqlalchemy.url = mysql+pymysql://root:password@localhost:3306/your_db_name

4) 모델 메타데이터 연결 (alembic/env.py)

- Alembic이 SQLAlchemy 모델을 인식할 수 있도록 alembic/env.py 파일을 수정

- target_metadata 부분을 찾아 내 모델의 Base.metadata와 연결

# alembic/env.py 내부

# 1. 작성한 모델 파일에서 Base 혹은 metadata 임포트
from myapp.database import Base 

# 2. target_metadata 설정 변경
target_metadata = Base.metadata

3. 운영 간 명령어 및 참고사항

1) 마이그레이션 파일 생성 (--autogenerate)

- SQLAlchemy 모델과 실제 DB 스키마를 비교하여 변경 사항을 추적하는 파일(revision)을 자동으로 생성됨

- m 뒤에는 변경 내용을 식별할 메시지를 작성

- 아래 명령어를 실행하면 alembic/versions/ 폴더 내부에 c7aa4c4_initial_migration.py 같은 고유 버전 ID의 파일이 생성됨

alembic revision --autogenerate -m "Initial migration"

2) 마이그레이션 적용 (upgrade)

- 생성된 마이그레이션 파일을 실제 데이터베이스에 실행하여 테이블을 생성하거나 수정함

- head는 가장 최신의 버전을 뜻하며, 아직 반영되지 않은 최신 변경 사항까지 모두 DB에 적용하라는 의미

alembic upgrade head

실행 후 (alembic_version)

- 최초로 실행시 데이터베이스에 내가 만든 테이블 외에 'alembic_version' 이라는 테이블이 자동으로 생성됨

- alembic_vesion 테이블은 "현재 실제 DB에 적용된 스키마 버전이 어디까지인지"를 나타내는 역할

3) 마이그레이션 히스토리 확인 (history)

- 생성된 마이그레이션 파일들의 이력과 순서를 확인

alembic history

4) --autogenerate를 맹신 하지 말 것

- 테이블 이름 변경, 컬럼 이름 변경 등 일부 복잡한 작업은 --autogenerate가 정확히 감지 못하고 '기존 컬럼 삭제 후 새 컬럼 추가'로 오인할 수 있음

- 마이그레이션 파일을 생성한 후에는 반드시 적용하기 전 versions/ 내부의 upgrade()와 downgrade() 함수 코드를 확인 필수

참고 문서

Alembic 프로덕션에서 안 쓰는 이유(견해)
Alembic DB Migration 버전 rollback
Alembic 대안 atlas
Alembic 한계 (공식문서) : 자동으로 캐치 하지 못하는 것들에 대한 설명 (ex. alter field name 등)
Alembic db 버전 관리 관련 tip

[푸시 알림 서비스] 시스템 설계 전략 A to Z

yubi5050 — Mon, 18 May 2026 16:57:55 +0900

1. 푸시 알림 서비스에 대한 이해

푸시 서비스는 모바일 앱 서비스를 개발할 때 푸시 알림은 유저 리텐션을 높이는 가장 강력한 도구로

기본 구조부터 실제 데이터가 오고 가는 전체 아키텍처 흐름까지 하나로 묶어 정리하였다.

용어 및 역할

Client App
- 유저가 사용하는 모바일 기기
- 자신을 식별할 수 있는 고유한 푸시 토큰을 발급받아(by Notification Server) 백엔드 서버로 전달
Provider (BE / API Server)
- 유저의 토큰 정보를 DB에 저장하고 관리
- 알림 발송 조건이 충족되었을때, 메시지와 토큰을 담아 Notification Server에 전송을 요청
Notification Server (FCM, APNs)
- FCM (Firebase Cloud Messaging): 구글이 제공하는 중재 서버 안드로이드 기기에는 직접 푸시를 쏘고, iOS 기기 요청은 APNs로 토스해 주는 중간 교량 역할을 함
- APNs (Apple Push Notification service): iOS 기기에 안전하게 푸시를 찔러 넣어주는 Apple 고유의 전송 서버

2. 푸시 알림의 6단계 기본 구동 과정

기기가 등록되고 푸시가 가기까지의 정석적인 메커니즘은 다음과 같은 순서로 진행

등록: Client App에서 Notification Server에 기기를 등록합니다.
토큰 발급: Notification Server는 각 Client App을 식별하는 Token을 발급
토큰 전송: Client App은 이 Token을 백엔드 서버(Provider)로 전송
토큰 저장: 백엔드 서버(Provider)는 이 유저가 누구인지 매핑하여 DB에 Token을 안전하게 저장(업데이트)함
발송 요청: 알림을 보낼 이벤트가 발생하면, 백엔드 서버는 저장해 둔 Token 값과 메시지를 실어 Notification Server에 요청
최종 수신: Notification Server가 타겟 기기를 찾아, 최종적으로 푸시 알림이 수신

시퀀스 플로우 차트

FCM/APNS 푸시 서버 및 흐름

3. 푸시 기능 옵션 규격서

- 다음 표는 기술적으로 조정 가능한 옵션에 대한 것.

- FCM을 통해 푸시를 보낼 때 사용하는 핵심 페이로드(Payload) 옵션 리스트

id	항목	설명	입력값 예시
1	제목 (title)	알림 창에 표시될 상단 제목	"새로운 이벤트가 도착했습니다!"
2	본문 (body)	알림 창에 표시될 본문 내용	"지금 확인하고 특별한 혜택을 받아보세요!"
3	이미지 (image)	알림 창에 첨부할 이미지 URL 단 푸시 이미지는 1mb 이하만 가능	["https://example.com/image.png"]
4	딥링크 (deep_link)	알림 클릭 시 앱 내 특정 화면으로 이동시킬 주소	"myapp://detail?id=12345"
5	데이터 (data)	내부 로직 처리를 위한 JSON 형태의 커스텀 데이터	{ "type": "NEW_QUEST", "deeplink": "myapp://detail?id=123" }
6	푸시 표시 여부(백그라운드) (content_available)	앱이 백그라운드/종료 상태 일 때 푸시 표시 여부 (기본값 O)	true (기본값) / false
7	푸시 표시 여부(포그라운드) (content_available)	앱이 켜져 있을 때 (실행중) 푸시 알림 수신 여부	true (앱이 켜져 있어도 데이터 수신 가능)
8	소리 (sound)	알림이 울릴 때 재생할 사운드 파일명	"default" or "custom_sound.mp3"
9	진동 패턴 (vibrate_timings)	알림 수신 시 진동 패턴 패턴 설정	["0.5s", "1s", "0.5s"]
10	잠금 화면 표시 방식 (visibility)	잠금 화면에서 알림 내용 숨김/표시 여부 설정	"public", "private", "secret"
11	배지 (badge)	앱 아이콘 우측 상단에 표시될 미확인 알림 숫자	5 (읽지 않은 알림 수)
12	클릭 액션 (click_action)	알림을 클릭했을 때 트리거할 프레임워크 액션	"FLUTTER_NOTIFICATION_CLICK"
13	우선순위 (priority)	알림의 발송 속도 및 우선순위 대역 설정	"high" (즉시 발송) / "normal"
14	채널 ID (android_channel_id)	Android 8.0 이상에서 특정 알림 채널 지정	"promo_notifications"
15	라이트 컬러 (light_color)	스마트폰 하드웨어 LED 알림 색상 지정	"#FF0000" (빨강)
16	자동 제거 (ttl 또는 expiration)	디바이스가 오프라인일 때 푸시가 유지되는 만료 시간	"3600s" (1시간 후 알림 자동 소멸)

4. (광고) 푸시 메시지 표기 규제 가이드라인

KISA 지침에 따라 혜택, 보상, 이벤트 등 유저의 행동을 유도하는 푸시에는 반드시 (광고) 문구와 수신거부 방법을 명시가 필요

판단 기준

서비스 안내 (광고 표현 X): 필수 서비스 정보 안내, 진행 알림, 시스템 상태 변경 알림
유저 행동 유도 (광고 표현 O): 혜택·보상 홍보, 구매 유도, 이벤트 참여 유도
필수 서비스 안내면 광고 아님 / 유저 행동 유도면 광고

✍️ 실제 적용 예시

일반 알림 : "랭킹전 시작! 랭킹전 종료까지 2시간 남았습니다"
광고성 알림 : "(광고) 사전예약하고 1,000G 보상 획득하세요 (수신거부:마이>설정>푸시 알림 받기 off)"

관리 기준 가이드 문서

5. 발송 주체(Who)와 타이밍(When)에 따른 알림 전략

서비스 규모가 커지면 알림 시스템은 단순히 메시지를 보내는 것을 넘어,

"누가(Who) 어떤 타이밍(When)에 어떤 규모로 보내는가"에 따라 시스템과 발송 전략을 분리해야 함

주체(Who) × 타이밍(When)

발송 주체 (Who) / 발송 타이밍 (When)	어드민 발송 (Admin-Driven)	시스템 발송 (System-Driven)
즉시 발송 (Immediate)	[긴급 및 수동 공지] • 치명적인 장애로 인한 긴급 점검 공지 • 운영자가 지금 바로 쏘는 기습 쿠폰 알림	[이벤트 기반 실시간 알림] • 누군가 내 글에 댓글을 달았을 때 • 결제 및 충전이 완료되었을 때 • 랭킹전 종료 즉시 정산 보상 지급
예약 / 스케줄 발송 (Scheduled / Cron)	[마케팅 예약 푸시] • "내일 오전 10시 이벤트 오픈" 예약 • 주말 프로모션 대상자 사전 추출 후 예약	[시간 기반 자동 배치 알림] • 매일 아침 9시 만보기 리마인더 • 랭킹전 종료 2시간 전 임박 알림 (Cron) • 퀘스트 보상 미수령 유저 당일 밤 리마인더

1. 발송 주체 (Who) - 운영자 or 시스템

어드민 발송 (Admin-Driven / 운영자 개입)
- 관리자가 개입한 "비정기적 대량 발송"
- 동작 방식: 백오피스(Admin)에서 관리자가 대상을 타겟팅하여 수동으로 발송 버튼 또는 특정 시간에 발송 예약
- 수백만 명에게 동시에 발송되는 경우가 많아 서버와 FCM에 순간적인 부하(Spike Traffic)를 줌
- 동기(Sync) 처리가 불가능하므로, 메시지 큐(Message Queue)를 활용한 비동기 분산 처리 아키텍처를 구축
- 영리 목적의 마케팅성 알림이 많아 (광고) 표기 및 수신거부 문구 가이드라인이 엄격하게 적용됩니다.
시스템 발송 (System-Driven / 기계 자동화)
- 유저의 특정 행동(Trigger)이나, 서버의 비즈니스 로직 조건이 충족되었을 때 시스템이 알아서 발송하는 자동화 알림
- 유저마다 행동 시점이 다르고 스케줄이 쪼개져 있어 트래픽이 골고루 분산됩니다.
- 기술적 특징: 유저마다 행동 시점이 다르고 스케줄이 쪼개져 있어 트래픽이 골고루 분산됩니다.
- 유저가 서비스를 이용하며 받아야 하는 필수 정보성 알림이 주를 이루어 광고성 규제에서 비교적 자유로움

2. 발송 타이밍 (When) - 즉시 or 예약/배치

발송 타이밍은 '알림이 유저에게 도달하는 시점'을 결정하며, 백엔드에서 API 엔드포인트 트리거로 처리할지, 정기 배치(Cron/Worker)로 처리할지를 결정
즉시 발송 (Immediate)
- 이벤트가 발생하는 그 순간 실시간으로 발송되어 유저에게 즉각적인 인터랙션을 유도
- 백엔드에서 API 엔드포인트 트리거로 구현
예약 / 스케줄 발송 (Scheduled)
- 미래의 특정 시점을 타겟팅하거나, 주기적인 배치 작업을 통해 조건에 맞는 대상자들을 긁어모아 발송
- 백엔드에서 Cron 으로 구현

6. 로컬 알림(Local) vs 푸시 알림(Push) 선택 기준

모바일 알림은 크게 네트워크 연결이 필요 없는 로컬 알림과 서버 기반의 푸시 알림으로 나뉨.

선택 기준

선택 기준	로컬 알림 (Local Notification)	푸시 알림 (Push Notification)
발생 주체	디바이스 내부 자체 발송	서버에서 발송
네트워크 의존성	인터넷 연결이 없어도 작동 가능	실시간 네트워크 동기화 필수
⭐️ 데이터 동기화	푸시 알림 메시지가 고정/미리 정의됨	서버에서 내려준 최신 데이터 반영 가능
유저 경험(UX)	개인화된 습관, 리마인더, 타이머	다른 유저와의 인터랙션, 외부 시스템 연동
구현 예시	기상 알람, 만보기 아침/저녁 리마인더, 스케줄러	메신저 채팅, 결제/거래 완료 알림, 실시간 랭킹전 시작 안내
⭐️ 한계점	OS 스케줄링에 대해 정확한 시간에 알림이 울리는 것을 보장 X (배터리 절약 모드, 앱 백그라운드 상태)	서버에서 알림 시간을 스케줄링하고, 정확한 타이밍에 FCM을 통해 푸시를 발송 앱 상태와 무관하게 가장 실시간
⭐️ DB 저장 및 알림함	기본적으로 DB 저장 안 함 (휘발성 리마인더)	서버 DB 동기화 필수 (유저가 확인 필요한 중요한 알림)

요약 및 결론

결국 로컬 알림과 서버 푸시를 선택하는 최종 기준은 다음 3가지로 압축할 수 있음

데이터의 동적 변화 여부: 알림 메시지가 고정되어 있다면 로컬, 서버의 최신 데이터를 실시간으로 반영해야 한다면 푸시를 선택
시간의 정확도와 서비스 중요도: 단순 습관성 리마인더는 기기 자체 로컬로 처리하고, 지연 없이 정확한 타이밍이 중요한 핵심 비즈니스 알림은 서버 푸시를 이용
앱 내 알림함(이력 조회) 필요 여부: 유저가 앱 내 알림 탭에서 지난 내역을 다시 조회해야 하는 기획이라면, 발송과 동시에 서버 DB에 이력을 적재할 수 있는 서버 푸시 방식이 필수적입니다.

7. FCM 대량 발송 방식 비교: Multicast vs Topic

수많은 유저에게 동시에 푸시를 보낼 때 사용하는 대표적인 두 가지 방식으로, 상황에 맞는 전략적 선택이 필요

비교 항목	멀티캐스트 (send_multicast)	토픽 구독 (subscribe_to_topic)
보낼 대상	직접지정한특정유저 군 (FCM 토큰리스트)	특정 주제(Topic)를 구독한 모든 유저
토큰 관리 주체	백엔드 서버에서 토큰 리스트 직접 관리	FCM 서버가 구독 명단을 자동 관리 (백엔드는 온/오프 상태만 동기화 - 동기화시 추가/삭제만)
확장성/제한	1회 발송당 토큰 개수 제한 (최대 500개)	제한 없음 (수백만 명에게 동시 발송 가능)
주요 활용 예시	친구 요청, 개인 맞춤형 리워드 알림, 일회성 타겟팅 마케팅	전체 공지사항, 전체 이벤트 공지, 아침/저녁 만보기 리마인더

실무 프로세스 (Sync)

유저가 앱 설정에서 '만보기 알림'을 켰을 때
1. 앱이 백엔드로 알림 ON API를 쏩니다.
2. 백엔드는 DB의 pedometer_agreed를 true로 바꾸고, 동시에 FCM Admin SDK에 함수 호출 (토픽에 유저 추가)
유저가 '만보기 알림'을 껐을 때 (또는 토큰갱신시)
1. 앱이 백엔드로 알림 OFF API를 쏩니다.
2. 백엔드는 DB를 pedometer_agreed를 false로 갱신하고, 동시에 FCM Admin SDK에 함수 호출 (토픽에 유저 제외)
토큰갱신시
1. 토큰은 유저가 앱을 재설치하거나 기기를 바꾸면 변함.
2. 토큰 갱신 될 떄마다 기존 토큰의 토픽들 구독 해제 => 새 토큰으로 구독 신청 스케줄 처리 필요
[멀티캐스트 사례] 일회성 마케팅 타겟팅
1. 상황 예시) 지난주 가입했으나 아직 재로그인 하지 않은 유저 3,500명에게 보상을 주는 푸시를 보내는 기획
2. 이 유저 군은 고정된 채널이 아니라, 매번 조건에 따라 달라지는 일회성 그룹으로, 이걸 위해 매번 새로운 토픽 채널을 만드는 것은 비효율적입니다. => 멀티캐스트로 처리
3. 백엔드 DB에서 조건에 맞는 유저 3,500명의 토큰 리스트를 쿼리로 추출 후, 멀티캐스트로 500개씩 나누어 7번 발송

[좋은 DB 설계하기] DB 커넥션과 어플리케이션 worker에 대한 이해

yubi5050 — Sun, 17 May 2026 16:57:44 +0900

1. 용어 정의

워커(worker)=프로세스

정의 : 서버(예: Gunicorn, Fastapi 등)에서 실제로 사용자의 요청(Request)을 받아 처리하는 독립적인 프로세스(or 스레드)
특징: 서버 스펙에 따라 워커 개수를 여러 개(예: 4개, 8개) 띄워 동시에 여러 요청을 처리합니다.

커넥션 (Connection)

정의: 애플리케이션 서버가 데이터베이스(DB)에 접근해 데이터를 읽고 쓰기 위해 연결한 통신 통로
특징: DB와 연결을 맺고 끊는 작업은 비용(시간/자원)이 많이 듬

커넥션 풀 (Connection Pool)

정의: 매번 요청 마다 DB 커넥션을 만들면 느려지니까, 워커가 미리 여러 개의 커넥션을 만들어 재활용하는 바구니(Pool)

2. 애플리케이션(Worker)의 커넥션 관리 구조

1개의 worker는 하나의 커넥션 풀을 관리함

동작 방식

요청이 들어오면 풀에서 커넥션을 꺼내 쓰고, 사용이 끝나면 재사용을 위해 풀에 반드시 반환(Return)함
생성 시 초기 비용이 크기 때문에 이렇게 재활용하는 구조를 가집니다.

커넥션 보유량 계산

기본 유지 개수(pool_size) : n개
최대 초과 허용 개수(max_over_flow) : m개
최대 사용 가능 커넥션 수 : n + m 개

3. DB 스펙 및 상태 확인 명령어

이해 (DB 와 어플리케이션)

DB 레벨 커넥션 수: DB가 감당할 수 있는 최대 수신 용량 (서버 인프라의 한계)
애플리케이션 레벨 커넥션 수: 서버가 효율을 위해 DB에 연결해 놓는 송신 전화기 개수 (개발자의 설정 영역)

따라서 [애플리케이션의 총 커넥션 개수]가 [DB의 최대 커넥션 수 용량]보다 무조건 작게 설계를 맞춰야 안전

목적	명령어	설명	사용 DB
최대 커넥션 제한 확인	SHOW VARIABLES LIKE 'max_connections';	DB 자체가 허용하는 최대 커넥션 수	1000개
실시간 커넥션 수 확인	SHOW STATUS LIKE 'Threads_connected';	현재 DB에 연결되어 자리를 점유 중인 세션 수	90 ~ 120
세션별 상세 상태 분석	SHOW PROCESSLIST;	현재 연결된 커넥션들이 무엇을 하고 있는지 확인

4. 커넥션 점유와 에러 (Too Many Connections)의 이해

핵심: 점유(Connected) vs 실제 사용 중(Active)

현재 Threads_connected가 90개(점유된)라고 해서 90개가 동시에 쿼리를 던지고 있는 것은 아님
대부분은 다음 요청을 기다리며 자리를 점유(Keep-Alive)하고 있는 상태
점유된 수치가 max_connections에 도달시, 1040 (Too many connections) 에러가 발생

5. 실무 참고 이해용 ⭐️

1. SHOW PROCESSLIST; 결과 - Command가 대부분 Sleep인 경우 (메모리 낭비)

원인 : 프로세스가 일을 안 하고 커넥션만 붙잡고 있는 상태
진단 : 애플리케이션의 기본 커넥션 풀(Pool) 설정이 과다하게 잡혀있을 확률이 높음.
진단 : Sleep, pool_size, max_connections는 CPU를 거의 쓰지 않기에, CPU는 평온 / 메모리(RAM)만 과다

2. SHOW PROCESSLIST; 결과 - Command가 대부분 Query인 경우

원인 : 쿼리 수행 시간이 너무 길거나 락(Lock)이 걸려 병목이 생긴 상태
진단 : 쿼리 튜닝이나 인덱스 확인(인덱스가 없어서 Full Table Scan을 하느라 CPU가 100%를 찍음)
진단 : 데드락(Deadlock) 검사가 필요 락 경합(Lock) 때문에 쿼리 하나당 실행 시간이 길어짐
결과 : DB CPU가 치솟으며, 뒤에 들어오는 커넥션들이 처리 못받고 줄을 서다가 결국 Too many connections 발생 (CPU 병목이 커넥션 폭발을 유발하는 구조)

3. 크론탭 (Cron Job/Batch)

크론은 실행될 때마다 새로운 프로세스로 독립적인 커넥션을 먹음
여러 크론이 동시에 돌면 순간적으로 커넥션 수가 치고 올라가며 Too many connections를 유발하기 쉬움.

4. API 동시 호출 (Traffic Spike)

트래픽이 순간적으로 몰리면 설정된 max_overflow(m)까지 커넥션 수가 확 올라감.
초기 생성 비용을 치르고 나면, 이후에 오는 요청들은 기존에 생성된 커넥션을 재활용하여, 커넥션 수가 더 늘어나지 않고 안정화

5. ❌ 장애 시나리오 예시

DB 설정 (max_connections): 100개
애플리케이션 설정: Gunicorn Worker 10개 구동 / Worker당 최대 커넥션 15개
결과: 트래픽이 몰려서 모든 Worker가 풀 가동되면 애플리케이션은 DB에 총 150개의 커넥션을 요청.
100개까지는 연결, 101번째 요청부터는 DB가 커넥션을 거부하여 Too Many Connections 에러가 발생

6. DB CPU를 갉아먹는 주범들

Threads_connected 수치가 높아졌을 때, SHOW PROCESSLIST를 통해 내부를 들여다보면 CPU를 쓰는 주범들을 진단

1. 실행 중인 비효율적 쿼리 : 복잡한 JOIN, SUBQUERY, GROUP BY, 대량 데이터 정렬(ORDER BY) 및 집계 작업

2. 인덱스 미스

인덱스가 없거나 잘못 잡혀서 테이블 전체를 읽는 Full Table Scan, 혹은 지나치게 넓은 범위의 Range Scan
디스크와 메모리에서 데이터를 찾기 위해 CPU가 미친 듯이 연산하며 사용량이 급증

3. 락(Lock) 경합

여러 트랜잭션이 동일한 데이터에 접근할 때 발생하는 Row Lock, Gap Lock 등
결과: 실제 일은 안(못) 하는데 CPU는 세션 대기를 처리하느라 계속 도는 비효율적인 자원 소모가 발생

4. InnoDB 내부 작업

다중 버전 동시성 제어(MVCC)를 위한 Undo 로그 정리, Purge 작업, Buffer Pool 관리 등 DB 자체의 백그라운드 연산

5. CPU랑 거의 무관한 것 (CPU가 아닌 메모리 소모)

Sleep 상태의 커넥션
애플리케이션의 pool_size
DB의 max_connections

[전시회,세미나] 원티드 하이파이브 2024

yubi5050 — Sun, 17 May 2026 15:53:53 +0900

(UX) 원티드랩 - 디자이너, 벽을 넘어서

UX 설득

원티드 북마크/지원 버튼 비율을 5:5 → 1:9로 변경 제안
결정권자/동료를 설득하기 위해, 타 서비스 레퍼런스를 기반으로 “지원 CTA 강화” 트렌드임을 설명
UX는 디자인보다 사용자 행동 유도가 중요

좋은 회의 방법

회의 전 아젠다 및 예상 반대 의견 사전 준비
필요 시 사전 공감대 형성
회의에서는 정답보다 내 발표 흐름·전달력·분위기가 중요
로 인해 이해 관계자들에게 어떠한 영감이라도 주었다면 잘한 것

조직 설득 / TO 확보

“인력이 부족하다”가 아닌: 매출 / 제작 시간 = 투입 대비 효율 등을 근거로 설득
부서 협업 기반으로 데이터 확보
최종적으로 TO 5명 추가 확보 성공

명언

내가 말했다고 상대가 들은 것은 아니며
상대가 들었다고 상대가 이해한 것은 아니다.
상대가 이해했다고 해서 상대가 받아들인 것도 아니며,
상대가 받아들였다고 해서 그렇게 하겠다는 것 또한 아니다.

(UX) 토스뱅크 - 또 혁신하기

1. 토스뱅크가 이뤄낸 혁신 (UX 최우선)

실적 폐지: 체크카드 전월 실적 조건 삭제
수수료 폐지: 환전 수수료 무료화
이자 혁신: 30일 주기 이자 받기 -> '매일 이자 받기', '먼저 이자 받기' 도입
포용 금융: 자체 신용평가 기준 수립으로 대출 범위 확장
일단 불편한게 있다면 부시고 없앰 -> '유저경험' 최우선

2. 조직 문화 및 일하는 방식 (Q&A 요약)

'길드' 단위의 자발적 미션 수행
ex) 어버이날 부모님 사진 송금, 청소년 안심 계약서 등 소소하고 다양한 미션 해결.
영리 기업으로서의 리소스 낭비 우려 : '해도 될까'보다 '일단 해'를 지향. (물론 시간적 제한은 두는편, 길드 단위의 작은 작업들이 시행 회수가 높아질 수록 성공률이 높아질 것이고 (양으로 밀어붙임), 작은 실패들이 쌓이면 도움이 될 것. 빨리 하는 건 의사결정 구조를 컴팩트하게 함을 지향하기 위해)
즉 시간 제한을 두고 작은 실패를 많이 반복하며 성공 확률을 높임. (팀별 의사결정이 매우 컴팩트함)

3. 고객 피드백 수집

고객센터, 스토어 리뷰, 앱 내 리뷰 등 모든 채널 동원.
무엇보다 피드백 채널을 담당 스쿼드(실무 팀)와 최대한 가깝게 배치하여 즉각 반영.

4. 혁신의 동기부여

보상 이전에 '메이커(Maker)로서의 재미와 즐거움'이 가장 큰 원동력.

(Tech) 토스증권 - 기술 혁신 증권사의 미래

1. 기술적 혁신: 국내 최초 MSA 기반 클라우드 네이티브 원장

패러다임 전환: 기존 증권사의 트랜잭션 안정성 중심 '모놀리식(Monolithic)' 구조를 과감히 탈피하고 MSA(마이크로서비스 아키텍처) 채택.
안정성 보완: 트랜잭션 이슈는 외부 툴 및 최신 기술을 활용해 보완.
효과: MSA를 채택하면서, 각 모듈별 담당자의 집중도 향후 기능 추가·확장 시 생산성 극대화. (자기 모듈만 알면되니까)

2. 대용량 데이터 및 인프라 처리 기술

비동기 큐(Queue)를 통한 트래픽 제어
사전 등록 유저 100만~200만 명의 신분증 인증 필요.
- 행안부·경찰청 등 외부 기관 망의 한계로 병목 발생 위험. (모든 증권사가 사용하는 거니까)
- 메시지 큐(Queue)를 도입해 속도를 조절하며 24시간 동안 분산 처리 -> 유저는 끊김 없는 비동기 서비스로 체감.
망 분리 및 Active-Active 서버 구성
- 보안을 위해 개발/업무/인터넷망 등을 철저히 분리.
- 안전성을 위해 Active-Standby가 아닌 Active-Active 구조로 서버 이원화.
- 한국거래소(KRX) 연동 최적화: AWS와 한국거래소 간 직접 터널링을 연결하여 클라우드 환경에서 데이터 처리 속도 증대. (토스가 aws니까, 한국거래소랑 aws랑 가까이 해놓으면 도움 됨)

3. 블리츠스케일링(Blitzscaling) 전략 & 조직 문화

속도 > 효율: 불확실한 상황에서도 속도를 효율보다 우위에 두는 전략 실행.
몰입 환경 조성: 개발자가 의식주에 신경 쓰지 않도록 최고 수준의 복리후생 제공.
단기 집중과 보상: 6개월 단위의 명확한 목표를 세워 온전히 몰입하게 하고, 달성 시 확실한 보상 지급.

4. Q&A: 개발자의 마인드셋

Q. 공감되지 않는 서비스를 개발해야 해서 힘들 때, 어떤 마음가짐을 가져야 할까?
A. "개발자는 아이디어를 구체화해 주는 실행자다." 비즈니스 방향성에 맞춰 아이디어를 완벽한 기술로 구현해 내는 역할에 집중하는 것이 중요

(Tech) 라인플러스 - TPM-Compassion 리더쉽

1. TPM(Technical PM)의 정의와 역할

개념: 국내외에서 아직 대중적이지는 않으나, 점차 중요성이 커지는 직무 ('CTO의 오른팔'로 불림).
핵심 임무: 기술적·제품적으로 복잡하고 다양한 팀이 참여하는 교차 기능(Cross-functional) 프로젝트 리딩.
존재 이유: 지지부진하고 멈춰 있는 프로젝트에 투입되어 다시 윤활유처럼 잘 굴러가게 만드는 해결사 역할.

2. PM/PO 직무를 수행하는 이의 '신념'

개인의 가치관 중요성: 워크숍 중 카페 벽면을 포스트잇으로 가득 채울 만큼, PM은 늘 신념과 가치에 대해 깊이 고민하는 직업.
PM에게 필요한 마인드셋 : 남을 도와주고 서포트하는 것 자체에서 보람을 느끼는 성향.
PM에게 필요한 마인드셋 : "최종 트로피(공로)를 다른 사람에게 양보하더라도" 프로젝트 성공과 다른 영역에서 스스로 만족과 보람을 찾을 수 있는 이타적인 리더십.

3. 조직 운영 및 R&R(역할과 책임)에 대한 현실

모호한 R&R의 인정: "내가 이것까지 해야 하나요?"라는 의문이 들 수 있지만, 현실적으로 모든 직무에서 R&R이 무 자르듯 명확할 수는 없음.
목적 중심 조직 활용: R&R의 모호함을 해결하고 과제를 효율적으로 수행하기 위해 '스쿼드(Squad)' 형태의 목적형 조직을 적극 활용함 (ex. 오퍼월 스쿼드 등).

(Tech) 현대오토에버 - 지속 성장하는 조직 만들기

1. 조직과 조직원이 함께 성장하는 법

의미 부여와 가치 리마인드: 조직원이 하는 일이 어떤 일인지 지속적으로 알려주고, 업무의 가치를 일깨워주어 동기부여를 극대화함.
건강한 감시 체계 (리뷰의 중요성): 사람은 누군가 지켜봐 주는 사람이 없을 때 나태해지기 쉬움.
예시 (코드 리뷰): 아무도 리뷰하지 않으면 대충 짜게 되고 결국 시스템과 조직이 부패함. 감시자 없이 온전히 맡기는 것은 '타락할 기회'를 주는 것과 같음.

2. 채용의 중요성과 '오염' 방지

채용이 전부다: 개인이 조직을 긍정적으로 변화시키는 것은 어렵지만, 개인이 조직을 망가뜨리는 것은 한순간임.
비유: 팝콘 박스 안에 들어간 바퀴벌레 한 마리가 박스 전체를 망칠 수 있음.

3. 리더십 및 조직 관리 Q&A

주니어(신입) 위주 조직에서 성장 및 자존감 케어법

핵심: 허드렛일이 아닌 '책임을 동반한 역할'을 부여할 것.
방법: 본인이 한 일이 사용자에게 어떤 경험을 주는지 직접 체감하게 하고,
아주 작은 성공일지라도 전체와 공유하여 성취감을 느끼게 해줌.

이미 조직 내에 '문제 인물(바퀴벌레)'이 존재할 때 (HR 관점)

리더가 문제를 인지하고 있고, 이를 해결하기 위해 노력 중임을 다른 구성원들에게 솔직하게 공유해야 함.
리더의 이러한 액션마저 없다면 남은 구성원들이 감내해야 할 고통과 피로감이 너무 커짐.

문제 인물을 판단하는 리더만의 기준

객관적 자료 검증: 한쪽 말만 듣지 않고 최대한 객관적인 데이터와 자료를 확보함.
과감한 결정과 책임: 판단 과정을 너무 오래 끌지 않음.
리더 본인도 틀릴 수 있음을 인정하되, 종합적인 판단이 서면 신속히 결정을 내리고 그 결과에 대해 리더가 책임을 짐.

참고

- https://event.wanted.co.kr/highfive2024: 2024 원티드 하이브이브

원티드 하이파이브 컨퍼런스

‘하이파이브 2024’는 HR 담당자를 비롯해 개발자, 디자이너, 마케터 등 다양한 직군의 직장인을 대상으로 하는 오프라인 컨퍼런스입니다. 2024년 5월 28일 ~ 29일 코엑스에서 만나요!

event.wanted.co.kr

[AI] 개발 AI 도구들 정리

yubi5050 — Sat, 16 May 2026 21:11:56 +0900

개발 관련 AI 도구 이해 (기준별)

구분	역할	대표 서비스/제품	세부 모델/버전	만든 회사	파일 시스템 접근	특징
AI 모델	추론·생성 두뇌	GPT Claude Gemini Llama Grok DeepSeek	GPT-5.5 GPT-5-mini Claude Sonnet 4.5 Claude Opus 4 Gemini 2.5 Pro Llama 4 Grok 4 DeepSeek R1	OpenAI Anthropic Google Meta xAI DeepSeek	없음	텍스트·이미지·코드 생성 엔진
AI 앱 (Chat App)	사용자 대화 인터페이스	ChatGPT Claude.ai Gemini Perplexity Grok Microsoft Copilot	내부적으로 여러 모델 선택 가능	OpenAI Anthropic Google Perplexity xAI Microsoft	제한적	채팅, 이미지, 파일, 웹검색 등 범용 기능
AI Agent	목표 기반 작업 수행	Codex Claude Code	GPT·Claude 계열 사용	OpenAI Anthropic	가능	파일·터미널·API 등을 직접 다룸
AI IDE	AI 통합 개발 환경	Cursor Windsurf Antigravity	GPT·Claude·Gemini 계열 사용	Anysphere Codeium Google	가능	IDE 안에서 프로젝트 전체 이해
AI 코딩 보조	개발 생산성 지원	GitHub Copilot	경량 모델 위주 사용	GitHub	부분적	자동완성·추천 중심

개발 관련 AI 도구 이해 (회사별)

회사	대표 모델/버전	AI 앱 (Chat App)	AI Agent (개발/작업)	AI IDE	특징
OpenAI	GPT-5.5, GPT-5-mini 자체모델 O	ChatGPT	Codex	-	모델 + 앱 + Agent 모두 보유
Anthropic	Claude Sonnet 4.5, Claude Opus 4 자체모델 O	Claude.ai	Claude Code	-	긴 문맥·코딩 Agent 강세
Google	Gemini 2.5 Pro, Gemini Flash 자체모델 O	Gemini	Gemini Agent	Antigravity	검색·멀티모달·IDE 확장
Meta	Llama 4 자체모델 O	Meta AI	-	-	오픈소스 모델 생태계 중심
xAI	Grok 4 자체모델 O	Grok	Grok Agent Grok Code	-	X(Twitter) 생태계 연동
Anysphere	GPT·Claude·Gemini 연결자체모델 X	-	Cursor Agent	Cursor	AI IDE 중심 회사
DeepSeek	DeepSeek R1 자체모델 O	DeepSeek Chat	-	-	추론·코딩 특화 모델
Microsoft	GPT 기반 자체 모델 △ (OpenAI 활용)	Microsoft Copilot	Copilot Agent Copilot Studio		OpenAI 협력 기반 AI 서비스 확장
Cognition AI	Devin SWE Agent 자체모델 △ (멀티모델 orchestration)	Devin	Devin	-	autonomous software engineer 포지션, 실제 개발 업무 수행 중심
GitHub	OpenAI 기반 자체 모델 X		GitHub Copilot (코딩 보조)	-	AI 코딩 보조 대표주자

기타 AI 도구 이해

영역	툴역할	강점	확인
사고 / 기획	ChatGPT + Claude	요구사항 정의, 사용자 플로우, 핵심 UX, 정보 구조(IA), 기능 명세(PRD)	✅
디자인	v0 by Vercel	실제 구현 가능한 React/Tailwind UI 생성, shadcn/ui 기반, 개발 연결 쉬움	✅
디자인	Lovable	startup 감성 UI, landing page, modern UI, 디자인 영감
디자인	Canva AI	간단한 디자인, 마케팅 이미지, SNS 콘텐츠 제작
이미지 제작	Midjourney	고퀄리티 컨셉 이미지·아트워크 생성
이미지 제작	Nano Banana	캐주얼 이미지·캐릭터·SNS 스타일 생성
자동화	n8n	AI workflow 자동화, API 연결, Slack/Gmail/DB 연동	✅
발표 PPT	Gamma	PPT·소개서·문서 자동 생성
발표 PPT	Genspark	조사 + 요약 + 발표자료 생성 workflow
AI 음성	ElevenLabs	최고 수준 TTS·voice cloning
AI 음성	PlayHT	자연스러운 음성 생성·다국어 지원
음악 제작	Suno	AI 음악 생성, 보컬 포함 곡 제작
음악 제작	Udio	고품질 음악·배경음악 생성
문서 자동화	Notion AI	문서 정리, 회의록, 팀 위키, 지식 관리

[전시회,세미나]원티드 하이파이브 2026

yubi5050 — Thu, 14 May 2026 15:58:27 +0900

Tech 세미나

주제 : AI 시대에도 커리어가 계속 쌓이는 엔지니어의 비밀

발표자 : 이승준 / Apple

좋은 문제 정의자가 되는 것이 가장 중요하다.
코드는 나중 plan을 먼저 세운 후 작업해라
document를 LLM wiki를 구축해, 팀의 질문과 업무 맥락이 자연스럽게 축적되고 검색 될 수 있도록, 문맥을 문서로 남길 수 있는 개발자가 되어라
아침에 일어나 어제의 일과와 오늘의 흐름을 정리하며 하루를 예측하는 personal assistant 루틴을 만든다.
오래가는 사람은 결국 의지가 아니라 시스템을 가진 사람이다.
주니어 3가지 명심사항
- 문제를 잘개 쪼개는 능력 (내가 어디서 막히었는가)
- 좋은 질문을 던지고 끊임없이 의심하는 태도
- 남에게 설명할 수 있는 수준의 이해력이다.
다음 스프린트를 미리 준비하고 사전에 검증해보는 과정(미리 맞아보기)이 중요하다.
코드 검증 범위를 명확히 설정하고, 부모 위키 기반으로 테스트 하네스를 구성하며 unittest로 테스트 케이스를 구축한다.
md 문서는 점점 방대해지기 때문에, 최대한 작은 단위로 분리하여 lazy loading 처럼 컨텍스트 오염을 최소화해야 한다.
어떤 문서를 남기고 어떤 문서를 삭제할지는 직접 관리하기보다 배치 방식으로 정리하는 것이 효율적이다.
R&R 경계 넘나드는 사례에 대한 의견 : 대기업에서는 R&R 경계를 넘나드는 일이 상대적으로 적고 역할이 명확하게 분리되어 있다.
트렌드는 계속 변하지만 펀더멘탈(개발의 본질적인 역량과 원리)은 바뀌지 않음

주제 : 토스 프론트엔드, 1명부터 260명까지. 앞으로는?

발표자 : 박서진, 한재엽 / 비바리퍼블리카

프론트엔드 조직이 1명 → 260명으로 성장하며, “일관된 확장”이 핵심 과제가 됨.
잘하는 사람도 더 잘하기 위해 코치가 필요함. (메타인지, 큰 그림, 방향성 보정)
국가대표에도 코치는 있다 / (잘하는데 있으면 더 잘한다, 메타인지 상승 등)
리더의 역할은 실무보다도 “큰 그림 정렬”에 가까워짐. (업무 완료 보고 등 안받음)
플레잉 코치의 코치까지 필요한 구조로 확장됨.
개개인의 시간을 아끼기 위해 플랫폼을 만들어 운영한다.
코드리뷰 단계에서 5개의 AI Agent를 활용
AI 활용도 개인 역량보다 조직 차원의 표준화로 이동 중.
개발자가 직접 Skill 쇼핑하지 않아도 최신 활용법이(팀원)에 의해 플랫폼에 반영됨.
Claude 활용 방식도 중앙 조직(Tab39 위원회 등)에서 지속 업데이트.
PRD는 .md 더 있고 디자인 문서일수도 있고
260명이나 있는 이유는. 모-든-걸 다 만들기 때문에
결국 방향성은 “일관된 개발 인원 확장”.

주제 : Inside Out: Agent Platform 개발기

발표자 : 정기수 / 원티드랩

자료 : 링크

LLM 기반 플랫폼, RAG 기반 플랫폼, Agent Builder 플랫폼 등을 직접 구축한 사례를 공유
데이터를 잘게 구조화하고 적절한 input으로 연결하는 능력이 중요하며, 이를 통해 지식 검색 품질이 크게 향상된다.
기업 내부 데이터를 지식 구조로 정리해 내부 사용자들이 AI 제품을 자연스럽게 활용할 수 있도록 만드는 것이 핵심
UI 자체보다 내부 데이터 구조와 Agent 동작 구조를 설계하는 역량에 더 집중한다.
Agent의 오답 여부, 권한 범위, 행동 로그 등을 지속적으로 모니터링하며 피드백 루프를 관리해야 한다.
고객 확장에서 중요한 것은 단순 기능 추가보다 데이터 구조화와 입력 설계였다.
실제 운영에서는 데이터 권한 관리 이슈가 생각보다 훨씬 중요했고, 많은 부분을 커스터마이징으로 해결했다.
전체 방향은 단순 SaaS보다는 “기업 내부 업무 패키지”와 고도화된 Admin 플랫폼에 가까운 형태다.
핵심 지표는 단순 생성된 Agent 수가 아니라, 지속적으로 운영되고 고도화되는 Agent 수다.
대화형으로 생성된 결과를 다시 구조화된 View 형태로 검증하는 과정이 중요하다.
결국 기업 내부의 AX(AI Transformation) 전환을 촉진하는 플랫폼을 만드는 방향이다
미래 방향은 Hyper Agent 기반으로 운영 개선 체계를 더욱 탄탄하게 만드는 것이다.
Agent가 읽을 수 있는 Knowledge Layer와 중앙집중형 LLM Wiki 구조가 매우 중요하다.
지식을 잘 축적하고 연결해 플랫폼 형태로 운영해야 한다.
조직 내에서 Agent가 어떤 역할과 정책으로 운영되어야 하는지까지 설계해야 한다.
자가 개선(Self-improving) 워크플로우 구조가 핵심 방향 중 하나다.
기업 환경에서는 정책, 권한, 거버넌스 설계가 특히 중요하다.
플랫폼을 만드는 과정에서 가장 어려운 점 중 하나는 시장의 기대 수준을 맞추는 일이었다.
결국 플랫폼 구축은 체력 싸움에 가까운 지속적인 운영과 개선 과정이다.
실제로 지속 운영되는 Agent 플랫폼이 존재하는지가 플랫폼 성공의 중요한 지표다.
앞으로는 사람이 직접 '운영'하는 시간이 줄고, Agent들이 운영 업무를 점점 더 많이 수행하게 될 것이다.
기업 내 AX 전환을 촉진하기 위해서는 공유 문화와 동기부여 체계가 중요하다.
전사 채널 공유, 매달 시상, 후속 활동 장려 등을 통해 AI 활용 문화를 확산시킨다.
비용 최적화를 위해 멀티 에이전트 구조로 저가 모델과 고성능 모델을 적절히 혼합 사용한다.
핵심 방향은 AI 기반의 전사 워크플로우 최적화다. 이를 위해 누구나 직접 AI Agent를 만들 수 있는 환경을 제공해야 한다.
Vibe Infra는 비개발자도 보안이 격리된 샌드박스 환경에서 쉽게 개발할 수 있도록 만드는 개념이다.
인프라 설정 부담을 플랫폼이 대신 처리해 개발 경험을 단순화한다.
누구나 서비스를 만들 수 있게 되면서 전체 서비스 생성량 자체가 증가하게 된다.
동시에 중앙집중형 관리 구조를 통해 안정성과 운영 효율도 확보한다.
궁극적인 목표는 일관성 있게 확장 가능한 플랫폼 구조를 만드는 것이다.
AI 결과물은 까나리(Canary) 방식으로 점진 검증 및 단계적 적용을 수행한다.
수천 줄 규모의 PR도 AI와 플랫폼 기반으로 리뷰 효율화를 진행한다.
특히 안정성을 위해 E2E 테스트를 매우 강하게 반복 수행한다고 한다.
기업 내에서 비용 최적화할 때 멀티에이전트로 싼 모델들 비싼 모델들 사용

주제 : 레트로 지향 엔지니어의 AI시대 적응기

발표자 : 정찬훈 / 센드버드

Anthropic의 Claude는 여러 작업 흐름을 하나의 메모리처럼 통합해 기억하는 특성이 있다.
실제 작업 시 체감상 워크트리를 3개 정도로 분리해서 작업했고, 원래라면 각각의 워크트리는 서로 다른 문맥과 메모리를 가져야 하지만, Claude는 이를 하나의 연속된 기억처럼 합쳐 처리하는 경향이 있었음.
그 결과 과거에 잘못 이해했거나 실패했던 맥락이 이후 작업에서도 반복적으로 다시 등장하는 문제가 발생했다.
즉, 메모리 통합이 항상 장점만 있는 것은 아니며, 문맥 분리(Context Isolation)의 중요성이 함께 드러난 사례였다.
AI 시대에는 단순히 “기억을 많이 하는 것”보다, 어떤 기억을 어떻게 분리하고 관리할지가 점점 더 중요해지고 있다.

UX / UI 세미나

주제 : AI 페르소나, 어떻게 하면 믿을 수 있을까요?

발표자 : 양희연, 이호동 / 네이버

자료 : 링크

AI를 단순 도구가 아니라, 가상의 디자이너·개발자 페르소나와 함께 협업하는 팀원처럼 사용하는 UX를 지향했다.
실제 사람과 함께 일하는 것과 유사한 협업 경험(UX)을 만드는 것이 핵심 목표였다.
ex) 4명의 팀에서의 회의록이 기획자, 디자이너, pm, 백엔드 개발자 역할의 AI 팀을 구성해 회의록 기반 협업을 실험했다.
AI 신뢰도 평가가 매우 중요 기존 대화나 보고서에 대한 비평을 다시 수행하게 하여 LLM 기반 점수 체계로 측정
사람은 일반적으로 능력이 보일 때, 나에게 실제 도움이 될 때, 일관된 원칙을 지킬 때 신뢰를 형성하고, 동료를 믿기 시작한다.
모델의 언어 능력(발화 능력)이 뛰어난 것과, 실제 프로젝트와 서비스에 도움이 되는 것은 별개의 문제였다.
단순 모델 성능뿐 아니라, 실제 협업 상황 전체에 대한 효과성과 신뢰성을 함께 평가했다.
책임감과 협업 태도, 강한 비판 상황에서의 반응도 중요한 평가 요소였다.
결국 핵심은 “이 AI를 정말 팀원처럼 받아들일 수 있는가”에 대한 질문이었다.
Solo Founder 관점에서 AI 팀원을 구성해보았지만, 아직은 실제 동료 수준에는 부족함이 있었다.
원하는 협업 스타일과 결과 품질을 Persona 설계를 통해 조정(세밀하게 튜닝하면)할 수 있다는 가능성(통제가능)을 확인했다.
UX 관점에서는 AI의 말투와 캐릭터(Persona)가 매우 중요한 요소로 작용했다.
긍정적이고 공감적인 발화를 가진 Persona는 아이디어 발산형 대화에서 높은 평가를 받았다.
반면 합의와 조율이 필요한 수렴형 대화에서는 다소 약하거나 회피적인 태도를 보였다.
기존 HCI(Human-Computer Interaction)는 시각적 UI 중심이었지만, 이제는 “대화를 통한 경험” 자체도 중요한 UX 요소로 본다.
고객 Persona를 만들 때는 실제 사용자 인터뷰 데이터와 서브 데이터를 함께 활용했다.
Persona가 실제 사용자와 지나치게 달라지지 않도록 다양한 가이드와 제약을 지속적으로 주입했다.
“LLM as a Judge” 기반 평가 결과가 실제 사용자 반응 데이터와 얼마나 상관관계가 있는지도 중요한 연구 주제였다.
내부에서 Persona 시스템이 얼마나 활용되고 있는지는 보안상 자세히 공개되지 않았다.
기존에 정의된 Persona 외에도 다양한 유형과 역할을 조합해 새로운 Persona를 확장 가능하게 생성할 수 있도록 설계했다. -> B2B / 내부 팀 공유
사용자가 직접 결과를 피드백받고 Persona 학습 방향을 조정할 수 있도록 하는 구조도 함께 고려했다.

참고 자료

원티드 하이파이브 2026 : https://event.wanted.co.kr/highfive/2026?tab=Makers