MK 실험실

경제금융용어 공부 592 : 토빈세(Tobin Tax)

MKISOS — Sat, 15 Aug 2026 21:00:45 +0900

토빈세(Tobin Tax)

국제 금융시장은 막대한 자금이 순식간에 국가 간을 이동할 수 있다. 이러한 단기 투기자금은 환율과 금융시장을 크게 흔들어 경제위기를 유발하기도 한다. 토빈세는 이러한 투기성 자금의 과도한 이동을 막기 위해 단기 외환거래에 세금을 부과하자는 아이디어에서 출발한 제도이다.

1. 한 줄 정의

토빈세는 단기 외환거래에 세금을 부과하여 국제 투기자본의 급격한 이동을 억제하려는 제도이다.

2. 기본 개념

토빈세(Tobin Tax)는 미국 경제학자 제임스 토빈(James Tobin)이 1978년에 제안한 개념이다.

국가 간 외환거래에 매우 낮은 세율의 세금을 부과하여 단기 차익만을 노리는 투기성 자금의 이동을 줄이자는 것이 핵심이다.

토빈세는 일반적인 무역이나 장기 투자에는 큰 영향을 주지 않으면서, 짧은 기간 동안 반복적으로 이루어지는 외환거래에는 비용을 증가시켜 투기적 거래를 줄이는 것을 목표로 한다.

쉽게 말하면 "돈이 너무 쉽게 드나들지 못하도록 작은 통행료를 부과하는 제도"라고 이해하면 된다.

3. 왜 중요한가

국제 금융시장에서 막대한 자금이 한 국가로 갑자기 유입되면 자산가격과 환율이 급등할 수 있다.

반대로 투자자들이 동시에 자금을 회수하면 환율이 급등하고 금융시장이 크게 흔들리며 외환위기로 이어질 가능성도 있다.

토빈세는 이러한 급격한 자금 이동의 속도를 늦춰 금융시장의 안정성을 높이기 위해 제안되었다.

또한 세금을 통해 발생한 재원을 국제 빈곤 해결이나 개발 지원 등에 활용할 수 있다는 주장도 있다.

4. 쉽게 이해하는 예시

실생활 예시

고속도로에 통행료가 없다면 많은 차량이 자유롭게 드나들면서 교통 혼잡이 심해질 수 있다.

하지만 소액의 통행료를 부과하면 꼭 필요한 차량만 이용하게 되어 혼잡이 줄어든다.

토빈세도 국제 자금 이동에 작은 비용을 부과해 불필요한 단기 투기거래를 줄이려는 개념이다.

투자 예시

한 투자자가 하루에도 여러 번 원화를 달러로 바꾸었다가 다시 원화로 환전하며 환차익을 노린다고 가정해보자.

거래할 때마다 토빈세가 부과된다면 거래 비용이 증가하여 단기 투기의 매력이 줄어들게 된다.

반면 해외 공장 설립이나 장기적인 해외투자는 거래 횟수가 적기 때문에 영향이 상대적으로 작다.

경제 예시

외국인 투자자들이 갑자기 수십조 원 규모의 자금을 국내에 투자했다가 한꺼번에 빠져나가면 환율과 금융시장이 크게 흔들릴 수 있다.

토빈세는 이러한 급격한 자금 이동을 완화하여 금융시장 안정을 높이는 역할을 기대한다.

5. 핵심 특징

5-1. 단기 투기자금을 억제한다

토빈세의 가장 큰 목적은 단기간에 반복되는 외환거래를 줄이는 것이다.

투기성 자금의 이동 비용을 높여 금융시장 변동성을 낮추려 한다.

5-2. 장기 투자에는 영향이 상대적으로 적다

장기적인 해외 직접투자나 일반 무역거래는 거래 횟수가 적기 때문에 토빈세의 부담이 크지 않다.

반면 단기 차익거래는 반복적인 거래가 많아 상대적으로 부담이 커진다.

5-3. 금융시장 안정성을 높이는 것이 목적이다

토빈세는 환율 급등락과 금융위기 가능성을 줄여 국제 금융시장의 안정성을 높이기 위한 정책이다.

5-4. 새로운 세수 확보 효과도 기대된다

거래 규모가 매우 큰 국제 외환시장에 낮은 세율만 적용해도 상당한 세수가 발생할 수 있다.

이 재원을 국제 개발이나 빈곤 퇴치 등에 활용하자는 의견도 제기되고 있다.

6. 관련 개념과의 차이

토빈세 vs 양도소득세

토빈세

외환거래 자체에 세금을 부과함
단기 자본 이동 억제가 목적
국제 금융시장 안정이 핵심 목표

양도소득세

자산을 팔아 얻은 이익에 세금을 부과함
투자소득 과세가 목적
주식, 부동산 등의 자본이득에 적용됨

토빈세는 거래 자체에 부과되는 세금이고, 양도소득세는 거래를 통해 발생한 이익에 부과되는 세금이다.

토빈세 vs 외환규제

토빈세

거래를 허용하되 비용을 부과함
시장원리를 활용하여 투기를 억제함

외환규제

특정 거래를 제한하거나 금지함
정부가 직접 자본 이동을 통제함

토빈세는 거래를 막는 것이 아니라 거래 비용을 높여 시장 참여자의 행동을 변화시키는 방식이다.

토빈세 vs 핫머니

토빈세

핫머니를 억제하기 위한 정책수단

핫머니

단기 차익을 목적으로 빠르게 이동하는 국제 투기자금

즉, 핫머니가 규제 대상이라면 토빈세는 이를 억제하기 위한 정책이다.

7. 경제적 의미

국가경제 관점

토빈세는 급격한 자본 유출입을 완화하여 환율 안정과 금융위기 예방에 도움이 될 수 있다.

특히 신흥국처럼 외국인 자금의 영향을 많이 받는 국가에서는 금융안정 수단으로 논의된다.

기업 관점

환율 변동성이 줄어들면 수출입 기업의 경영 불확실성이 감소할 수 있다.

반면 국제 금융거래 비용이 증가할 가능성도 존재한다.

금융시장 관점

토빈세는 단기 투기거래를 줄이고 금융시장의 변동성을 낮추는 효과가 기대된다.

그러나 거래량 감소로 시장 유동성이 줄어들 수 있다는 우려도 함께 제기된다.

투자 관점

장기 투자자에게는 영향이 제한적일 가능성이 크지만, 단기 환율 차익거래를 반복하는 투자자에게는 거래 비용이 크게 증가할 수 있다.

또한 토빈세 도입 여부는 외환시장과 국제 자금 흐름에 영향을 미치는 중요한 정책 변수로 평가된다.

8. 정리

토빈세는 단기 외환거래에 소액의 세금을 부과하여 국제 투기자본의 급격한 이동을 억제하기 위해 제안된 제도이다. 장기 투자나 일반 무역에는 영향을 최소화하면서 단기 투기거래의 비용을 높여 금융시장 안정성을 높이는 것이 핵심 목적이다. 아직 전 세계적으로 보편화된 제도는 아니지만, 국제 금융위기와 환율 변동성이 커질 때마다 다시 논의되는 대표적인 국제 금융정책 가운데 하나이다.

[미국 초단기 국채 ETF] SGOV와 USFR, 같은 달러 파킹인데 왜 둘로 나눴을까?

MKISOS — Sat, 15 Aug 2026 11:53:04 +0900

주식을 계속 모아가는 투자자에게 현금은 생각보다 애매한 자산이다.
주식이 크게 하락했을 때는 현금이 있어야 추가 매수를 할 수 있다. 반대로 너무 많은 현금을 그냥 들고 있으면 상승장에서 투자하지 못한 돈이 된다.
특히 미국 주식을 중심으로 투자하다 보면 원화를 달러로 환전한 뒤 아직 주식을 사지 않은 돈을 어디에 둘지도 고민하게 된다.

나는 그동안 이런 달러 대기자금을 SGOV에 넣어두는 방식을 사용해왔다.
그런데 앞으로는 한 가지 ETF만 사용하는 대신,

A = SGOV
B = USFR

두 개의 버킷으로 나눠서 운용해보려고 한다.

테스트용 사진

수익률 몇 bp를 더 얻기 위해서라기보다는 각각의 돈에 역할을 부여하고, 증권앱에서도 두 자금을 눈으로 명확하게 구분하기 위해서다.
그리고 SGOV는 이미 직접 사용해봤으니, 이번에는 미국의 변동금리 국채를 담는 USFR도 실제로 보유하면서 그 구조를 경험해보고 싶었다.

먼저 두 ETF가 무엇인지부터 하나씩 정리해보자.

1. SGOV란 무엇인가?

SGOV의 정식 명칭은 iShares 0-3 Month Treasury Bond ETF다.
세계 최대 자산운용사 중 하나인 BlackRock의 iShares가 운용하며, 이름 그대로 잔존 만기가 0~3개월인 미국 국채(Treasury Bill)에 투자한다.
SGOV가 추종하는 지수 역시 ICE 0-3 Month US Treasury Securities Index다. iShares는 SGOV를 자본 보존과 유동성 관리, 그리고 최소한의 금리 위험을 추구하는 상품으로 설명하고 있다.
쉽게 생각하면 이런 구조다.

달러를 가지고 있다
→ 아주 짧게 만기가 남은 미국 국채를 산다
→ 국채가 만기된다
→ 다시 새로운 단기 미국 국채를 산다
→ 이를 반복한다

그래서 SGOV는 주식처럼 높은 자본차익을 기대하는 ETF라기보다 미국 단기금리를 받으면서 달러를 잠시 주차하는 장소에 가깝다.

SGOV의 현재 주요 수치

2026년 8월 11~12일 iShares 공식 자료 기준으로 보면 다음과 같다.

항목	SGOV
투자 대상	미국 0~3개월 Treasury
운용보수	0.09%
30일 SEC Yield	3.59%
Effective Duration	0.10년
Weighted Avg Maturity	0.10년
순자산	약 1,022억 달러
30일 Median Bid/Ask Spread	0.01%
분배 주기	월 단위

SGOV 포트폴리오의 약 99.4%가 미국 재무부 채무로 구성되어 있고, 만기 구성도 대부분 90일 이내다.
여기서 내가 특히 중요하게 보는 것은 0.10년이라는 매우 짧은 듀레이션이다.
채권은 일반적으로 금리가 변하면 가격이 움직인다. 그런데 만기가 몇 년, 몇십 년 남은 장기채와 달리 SGOV는 몇 주에서 몇 달짜리 국채를 보유한다.

따라서 금리가 움직여도 가격 변동이 매우 제한적이다.
물론 SGOV도 ETF이기 때문에 은행 예금처럼 가격이 완전히 고정되어 있는 상품은 아니다. 하지만 투자 목적 자체가 자본차익보다는 단기 미국 국채에서 발생하는 이자를 확보하면서 높은 유동성을 유지하는 것에 있다.
그래서 나는 그동안 SGOV를 사실상 달러 파킹 ETF처럼 활용해왔다.

2. 그렇다면 USFR은 무엇인가?

USFR의 정식 명칭은 WisdomTree Floating Rate Treasury Fund다.
여기서 가장 중요한 단어가 바로 Floating Rate Treasury 다.

SGOV가 만기가 아주 짧은 일반 미국 국채를 계속 교체해서 보유한다면, USFR은 미국 정부가 발행한 변동금리 국채(Floating Rate Notes, FRN)를 보유한다.
USFR는 Bloomberg U.S. Treasury Floating Rate Bond Index를 추종한다. WisdomTree 역시 이 ETF를 최근 3개월 미국 국채 금리 움직임을 따라가는 단기 미국 국채 솔루션으로 설명하고 있다.

이 부분이 처음에는 조금 헷갈렸다.
USFR의 평균 만기를 보면 약 1.52년이다. SGOV는 불과 약 0.10년인데 USFR은 1년이 넘는다.
그렇다면 USFR가 SGOV보다 금리 변화에 훨씬 민감해야 할 것 같지만 실제 수치는 반대다.

2026년 8월 12일 기준 USFR의 Effective Duration은 0.02년에 불과하다.

그 이유가 바로 변동금리에 있다.

3. USFR의 금리는 왜 계속 바뀔까?

미국 재무부가 발행하는 FRN은 기본적으로 2년 만기 국채다.
하지만 일반적인 2년물 국채처럼 처음 정해진 금리를 2년 동안 계속 지급하는 것이 아니다.
미국 재무부에 따르면 FRN의 금리는 Index Rate + Spread 형태로 결정된다.
여기서 Index Rate는 가장 최근에 실시된 13주 만기 Treasury Bill 경매 금리를 기준으로 한다.
그리고 미국 재무부는 13주 T-Bill을 매주 경매하기 때문에 FRN의 기준금리도 매주 리셋된다.

예를 들어 아주 단순하게 표현하면,

13주 T-Bill 금리 3.7%

FRN 고정 Spread 0.1%
= 약 3.8%

같은 구조다.

다음 주 13주물 금리가 올라가면 FRN의 금리도 올라가고, 반대로 단기금리가 내려가면 FRN의 금리도 빠르게 내려간다.
따라서 채권 자체의 만기는 2년이어도 금리가 계속 시장 수준으로 조정된다.

이 때문에 USFR는 만기는 SGOV보다 길지만 금리 변화에 대한 가격 민감도는 오히려 매우 낮다.
현재 USFR의 주요 수치는 다음과 같다.

항목	USFR
투자 대상	미국 Treasury FRN
운용보수	0.15%
30일 SEC Yield	3.71%
Distribution Yield	3.80%
Effective Duration	0.02년
Average Years to Maturity	1.52년
순자산	약 187억 달러
30일 Median Bid/Ask Spread	0.02%

2026년 8월 11일 기준 실제 보유종목도 2027~2028년 만기의 미국 Treasury FRN 네 종목으로 구성되어 있다.
참고로 미국 재무부 FRN 자체는 이자를 분기마다 지급하지만, USFR ETF의 최근 분배 기록을 보면 4월, 5월, 6월, 7월 모두 분배가 이루어져 ETF 투자자는 월 단위 분배 형태를 경험하고 있다.

4. SGOV와 USFR의 핵심 차이

둘을 한 번에 비교하면 훨씬 이해하기 쉽다.

구분	SGOV	USFR
핵심 자산	0~3개월 T-Bill	2년 만기 Treasury FRN
금리 구조	단기 국채를 계속 교체	변동금리
시장금리 반영	만기·재투자 과정에서 반영	매주 리셋
Effective Duration	약 0.10년	약 0.02년
운용보수	0.09%	0.15%
현재 SEC Yield	3.59%	3.71%
내 관점	가장 단순한 달러 파킹	단기금리 추종형 달러 파킹

수익률 숫자만 보면 현재 USFR가 아주 조금 높다.
하지만 이 차이는 시장금리에 따라 계속 바뀐다.
그래서 나는 0.1% 정도의 금리 차이를 맞히려고 SGOV와 USFR를 구분하려는 것은 아니다.
둘의 구조 자체가 다르다는 점이 더 중요하다.

금리가 올라간다면

USFR의 기준금리는 매주 새로운 13주 T-Bill 금리를 반영한다.
따라서 단기금리가 상승할 때는 새로운 금리를 비교적 빠르게 따라갈 수 있다.
반면 SGOV는 이미 가지고 있는 T-Bill이 만기되고 새로운 T-Bill로 교체되면서 금리가 반영된다.

금리가 내려간다면

반대로 USFR는 기준금리가 계속 재설정되기 때문에 떨어진 단기금리도 빠르게 반영된다.
SGOV는 기존에 매입했던 T-Bill이 만기되기 전까지는 해당 국채의 수익 구조가 유지된다.
다만 SGOV 역시 최대 3개월 수준의 초단기 국채이기 때문에 그 차이가 장기간 지속되는 것은 아니다.

결국 둘 다 미국 단기금리를 따라가는 자산이지만,
SGOV는 초단기 T-Bill을 계속 교체하는 방식,
USFR는 금리 자체가 계속 움직이는 FRN을 보유하는 방식
이라는 차이가 있다.

5. 그렇다면 왜 둘 다 보유하려고 할까?

여기서 중요한 점이 있다.
나는 SGOV와 USFR를 동시에 보유한다고 해서 이것을 대단한 자산 분산이라고 생각하지 않는다.

둘 다 결국

미국 정부가 발행한 채권에 투자하고
달러로 거래하며
미국 단기금리의 영향을 크게 받는다.

신용위험이나 환율 측면에서 완전히 다른 자산 두 개를 보유하는 것이 아니다.
내가 두 ETF를 구분하는 가장 큰 이유는 자산의 역할을 분리하기 위해서다.
내 투자에서 앞으로 현금성 자산은 다음 두 가지 역할을 맡는다.

6. A 버킷 = SGOV, 기본적립을 위한 돈

A 기본적립 버킷

SGOV

미래 QLD 매일매수 보장

A 버킷은 내가 시장을 예측하지 않고 계속 투자하기 위한 돈이다.
QLD가 오르든 내리든 정해놓은 기본 매수는 계속할 생각이다.
그런데 아무리 장기 적립식 투자라고 해도 계좌에 현금이 없으면 매수를 지속할 수 없다.
그래서 앞으로의 기본 적립에 사용할 달러를 미리 확보해두고, 아직 사용하지 않는 동안에는 SGOV에 두는 방식이다.

내게 SGOV는 단순히 수익률을 얻기 위한 ETF가 아니라,

앞으로의 매수를 보장하기 위한 준비된 현금

에 더 가깝다.

시장 상황이 어떻든 정해진 매수를 계속할 수 있다는 것이 A 버킷의 목적이다.
SGOV는 이미 실제로 사용해본 경험도 있고, 규모와 거래 유동성이 크며 구조 역시 매우 단순하다.
그래서 앞으로도 기본 적립을 위한 핵심 현금 버킷은 SGOV로 가져가려고 한다.

7. B 버킷 = USFR, 급락을 기다리는 기회 자금

B 기회 버킷

USFR

향후 시장 급락 시 추가매수

B 버킷은 성격이 다르다.
평소에 반드시 사용해야 하는 돈이 아니다.
시장이 정상적으로 움직인다면 계속 USFR에 있을 수도 있다.
대신 시장에 큰 조정이나 급락이 찾아오고 내가 미리 정해둔 조건에 해당한다면 그때 꺼내서 추가 매수에 사용하는 기회 자금이다.

즉,

A는 '계속 사기 위한 돈'
B는 '크게 떨어졌을 때 더 사기 위한 돈'

으로 역할을 나눈 것이다.

그리고 이 B 버킷에 굳이 SGOV가 아니라 USFR를 선택한 이유도 있다.
USFR가 SGOV보다 반드시 더 좋은 ETF라서가 아니다.
SGOV는 이미 꽤 오랫동안 달러 파킹용으로 직접 사용해봤다.

이번에는 미국 변동금리 국채라는 구조도 직접 경험해보고 싶었다.
책이나 글로

“FRN은 13주 T-Bill을 기준으로 금리가 매주 리셋된다.”

라고 공부하는 것과 실제 내 돈을 넣어두고,

가격이 어떻게 움직이는지
분배금은 어떻게 들어오는지
금리 변화가 수익률에 어떻게 반영되는지
SGOV와 실제 체감 차이가 있는지

관찰하는 것은 또 다르다고 생각한다.
나는 투자하면서 이렇게 작은 금액이라도 직접 경험해보는 과정 역시 공부라고 생각한다.

8. 증권앱에서 굳이 두 종목으로 나누는 이유

사실 수학적으로만 생각한다면 모든 대기자금을 SGOV 하나에 넣어놓고 엑셀이나 노션에서

이 중 얼마는 기본매수용
이 중 얼마는 급락매수용

이라고 구분할 수도 있다.

그런데 나는 그렇게 하지 않으려고 한다.
투자는 계산만큼이나 행동 관리가 중요하다고 생각하기 때문이다.

한 종목에 돈이 전부 섞여 있으면 어느 순간부터 경계가 흐려질 수 있다.
“이 정도는 미리 써도 되지 않을까?”
“조금 떨어졌으니까 기회자금도 그냥 써버릴까?”
같은 판단이 들어오기 시작한다.

그래서 아예 증권앱을 열었을 때
SGOV = A
USFR = B
라고 두 눈으로 구분되어 있는 편이 나에게는 더 직관적이다.

SGOV를 보면

“이건 앞으로 계속 투자하기 위한 돈.”

USFR를 보면

“이건 정말 기회가 왔을 때 사용할 돈.”

이라고 바로 인식할 수 있다.

수익률 최적화보다는 돈에 이름표를 붙이는 것에 가깝다.

9. 앞으로의 내 달러 파킹 시스템

결론적으로 앞으로는 이렇게 운영해보려고 한다.

A. 기본적립 버킷 — SGOV

목적 : 미래 QLD 매일매수 보장
시장 방향과 관계없이 지속해야 하는 기본 매수를 위한 자금이다.
평소에는 SGOV에서 단기 미국 국채 수익을 받으면서 대기하고, 실제 적립에 필요한 시점이 되면 순차적으로 사용한다.

B. 기회 버킷 — USFR

목적 : 향후 시장 급락 시 추가매수
평소에는 사용할 필요가 없는 돈이다.
USFR에 두면서 미국 변동금리 국채를 직접 경험하고, 시장이 충분히 크게 하락해 내가 정해놓은 기준을 충족했을 때 추가 매수 재원으로 사용한다.
정확한 금액이나 비율을 공개할 필요는 없다고 생각한다.
더 중요한 것은 각각의 돈이 어떤 역할을 가지고 있느냐다.

내 계좌에서 현금은 이제 단순히 '아직 투자하지 않은 돈'이 아니다.

A는 미래의 기본 매수를 보장하는 돈이고,
B는 미래의 기회를 기다리는 돈이다.

SGOV와 USFR 역시 어느 것이 절대적으로 우월하다고 생각하지 않는다.

둘 다 미국 국채를 활용한 훌륭한 현금성 ETF이고, 구조가 조금 다를 뿐이다.
나
는 이미 SGOV라는 방식을 경험했다.
이번에는 USFR까지 직접 보유해보면서 두 상품이 실제 시장에서 어떻게 움직이는지 기록해볼 생각이다.

결국 이번 변경의 핵심은 ETF 하나를 더 사는 것이 아니다.
현금을 목적에 따라 나누고, 미래의 행동까지 미리 정해놓는 것.
내 투자에서 A와 B라는 두 버킷을 만드는 이유다.

참고 자료

1. SGOV — BlackRock/iShares 공식 페이지
SGOV 공식 상품 페이지
Key Facts, Portfolio Characteristics, Maturity 부분을 캡처하면 SGOV가 실제로 얼마나 짧은 미국 국채를 보유하는지 보여주기 좋다. 2026년 8월 현재 공식 페이지에는 운용보수 0.09%, Effective Duration 0.10년, 월 분배 등의 정보가 공개되어 있다.
2. USFR — WisdomTree 공식 페이지
USFR 공식 상품 페이지
Fund Overview와 Holdings 부분을 캡처하면 좋다. Average Years to Maturity가 1.52년인데 Effective Duration은 0.02년이라는 점을 함께 보여주면 USFR의 변동금리 구조를 설명하기 좋다.
3. 미국 재무부 — Floating Rate Notes 설명
U.S. TreasuryDirect FRN 공식 설명
특히 How we calculate the floating interest rate 부분을 캡처하는 것을 추천한다.

※ 이 글은 특정 ETF의 매수 추천이 아니라 개인적으로 달러 대기자금을 어떻게 관리하고 있는지 기록하기 위해 작성했다. ETF 역시 시장가격 변동이 있으며, 원화 기준 투자자에게는 환율 변동의 영향도 존재한다.

경제금융용어 공부 591 : 텔레뱅킹(폰뱅킹)

MKISOS — Fri, 14 Aug 2026 21:00:06 +0900

텔레뱅킹(폰뱅킹)

텔레뱅킹(폰뱅킹)은 은행 창구를 직접 방문하지 않고 전화만으로 다양한 금융업무를 처리할 수 있는 서비스이다. 인터넷과 스마트폰이 보급되기 전에는 대표적인 비대면 금융서비스였으며, 현재의 인터넷뱅킹과 모바일뱅킹의 기반이 된 금융기술이라고 볼 수 있다.

1. 한 줄 정의

텔레뱅킹은 전화기를 이용해 은행 방문 없이 송금, 조회, 공과금 납부 등의 금융업무를 처리하는 비대면 금융서비스이다.

2. 기본 개념

텔레뱅킹(Tele Banking)은 고객이 전화기를 이용해 은행의 자동응답시스템(ARS)이나 상담원과 연결되어 금융업무를 처리하는 서비스이다.

은행 창구를 직접 방문하지 않아도 계좌조회, 송금, 예·적금 가입 및 해지, 공과금 납부, 분실신고 등의 업무를 처리할 수 있다.

과거에는 집 전화나 유선전화를 이용하는 경우가 많았지만, 이후 휴대전화가 보급되면서 서비스 이용이 더욱 편리해졌다.

현재는 인터넷뱅킹과 모바일뱅킹 이용이 크게 늘면서 사용 비중은 감소했지만, 여전히 일부 고객들은 텔레뱅킹 서비스를 이용하고 있다.

3. 왜 중요한가

텔레뱅킹은 은행을 직접 방문해야 했던 금융거래를 비대면으로 전환한 최초의 금융서비스 중 하나이다.

이를 통해 고객은 시간과 장소의 제약 없이 금융업무를 처리할 수 있게 되었고, 은행은 창구 업무와 인력 운영 비용을 줄일 수 있었다.

또한 텔레뱅킹은 이후 등장한 인터넷뱅킹과 모바일뱅킹으로 이어지는 디지털 금융서비스의 출발점이라는 의미도 가진다.

4. 쉽게 이해하는 예시

실생활 예시

예전에는 부모님이나 조부모님이 은행에 가지 않고 전화로 계좌 잔액을 확인하거나 다른 계좌로 송금하는 경우가 많았다.

은행 대표번호로 전화를 걸어 주민등록번호나 계좌번호, 비밀번호를 입력하면 원하는 업무를 처리할 수 있었다.

직장인 예시

퇴근 시간이 늦어 은행 영업시간에 방문하기 어려운 직장인이 전화로 공과금을 납부하거나 계좌이체를 할 수 있었다.

금융서비스 예시

오늘날 모바일뱅킹으로 몇 번만 터치하면 송금이 가능한 것처럼, 과거에는 같은 업무를 전화와 ARS를 이용해 처리했다고 이해하면 된다.

5. 핵심 특징

5-1. 전화만으로 금융업무를 처리한다

컴퓨터나 스마트폰 없이 전화기만 있으면 다양한 은행 업무를 이용할 수 있다.

5-2. 은행 방문이 필요 없다

창구를 직접 방문하지 않아도 계좌조회, 송금, 예·적금 가입 및 해지 등 다양한 금융서비스를 이용할 수 있다.

5-3. 시간과 장소의 제약이 적다

은행 영업시간 외에도 서비스를 이용할 수 있어 고객의 편의성이 크게 향상되었다.

5-4. 디지털 금융의 출발점이다

텔레뱅킹은 인터넷뱅킹과 모바일뱅킹이 등장하기 전 대표적인 비대면 금융서비스였다.

현재의 디지털 금융환경을 만드는 기반 기술 중 하나로 평가된다.

6. 관련 개념과의 차이

텔레뱅킹 vs 인터넷뱅킹

텔레뱅킹

전화와 ARS를 이용함
음성 안내를 통해 거래를 진행함
컴퓨터가 필요하지 않음

인터넷뱅킹

인터넷과 웹사이트를 이용함
컴퓨터를 통해 금융업무를 처리함
화면을 보며 다양한 서비스를 이용할 수 있음

인터넷뱅킹은 컴퓨터 기반이고, 텔레뱅킹은 전화 기반이라는 차이가 있다.

텔레뱅킹 vs 모바일뱅킹

텔레뱅킹

전화 통화를 이용한 금융서비스
음성 안내 중심

모바일뱅킹

스마트폰 앱을 이용함
송금, 투자, 대출 등 다양한 금융서비스 제공
현재 가장 많이 이용되는 비대면 금융서비스

모바일뱅킹은 텔레뱅킹보다 훨씬 다양한 기능과 편의성을 제공한다.

텔레뱅킹 vs 은행 창구

텔레뱅킹

비대면 서비스
전화로 업무 처리
언제 어디서나 이용 가능

은행 창구

대면 서비스
직원과 직접 상담
복잡한 금융상품 상담에 적합

간단한 업무는 텔레뱅킹이 편리하지만, 복잡한 금융상품 상담은 창구 이용이 더 적합할 수 있다.

7. 경제적 의미

국가경제 관점

텔레뱅킹은 금융서비스의 디지털화를 촉진하며 금융 접근성을 높이는 데 기여했다.

비대면 금융서비스 확산의 시작점으로 평가된다.

기업 관점

은행은 창구 운영 비용과 인력 부담을 줄일 수 있었으며, 더 많은 고객에게 금융서비스를 제공할 수 있게 되었다.

금융시장 관점

텔레뱅킹은 인터넷뱅킹과 모바일뱅킹으로 이어지는 금융 디지털 전환의 중요한 단계였다.

이를 통해 금융기관들은 다양한 비대면 금융서비스를 개발하게 되었다.

투자 관점

현재는 모바일뱅킹이 중심이지만, 텔레뱅킹은 핀테크와 디지털 금융산업이 발전하는 과정에서 중요한 전환점이었다.

투자자는 금융회사의 디지털 서비스 경쟁력이 기업 가치에 큰 영향을 미친다는 점을 이해할 필요가 있다.

8. 정리

텔레뱅킹은 전화기를 이용해 은행 방문 없이 다양한 금융업무를 처리하는 비대면 금융서비스이다. 계좌조회, 송금, 예·적금 가입 및 해지, 공과금 납부 등 다양한 업무를 전화만으로 처리할 수 있어 금융서비스의 편의성을 크게 높였다. 현재는 인터넷뱅킹과 모바일뱅킹이 주류가 되었지만, 텔레뱅킹은 우리나라 디지털 금융의 시작을 이끈 중요한 서비스로 평가된다.

경제금융용어 공부 590 : 테일러 준칙(Taylor's Rule)

MKISOS — Thu, 13 Aug 2026 21:00:45 +0900

테일러 준칙(Taylor's Rule)

중앙은행은 기준금리를 올릴지 내릴지를 어떻게 결정할까? 단순히 물가만 보고 결정하는 것이 아니라 물가와 경기 상황을 함께 고려한다. 이를 하나의 공식으로 정리한 것이 바로 테일러 준칙(Taylor's Rule)이다. 실제 정책을 자동으로 결정하는 공식은 아니지만, 중앙은행이 적정 기준금리를 판단할 때 참고하는 대표적인 경제모형이다.

1. 한 줄 정의

테일러 준칙은 물가상승률과 경기 상황을 함께 고려해 적정 기준금리를 계산하는 경제학 이론이다.

2. 기본 개념

테일러 준칙은 미국 경제학자 존 테일러(John Taylor)가 1993년에 제안한 금리 결정 원칙이다.

중앙은행은 경제가 과열되거나 침체될 때 기준금리를 조정하는데, 테일러 준칙은 이러한 기준금리의 적정 수준을 계산하는 하나의 기준을 제시한다.

테일러 준칙은 크게 세 가지 요소를 고려한다.

중립금리
물가상승률(인플레이션)
경기 상황(생산갭)

즉, 물가가 목표보다 높거나 경기가 과열되면 금리를 올리고, 물가가 낮거나 경기가 침체되면 금리를 내리는 것이 기본 원리이다.

3. 왜 중요한가

기준금리는 경제 전체에 매우 큰 영향을 미친다.

금리가 너무 낮으면 물가가 급등하거나 자산가격 거품이 발생할 수 있고, 반대로 너무 높으면 소비와 투자가 위축되어 경기침체가 심해질 수 있다.

테일러 준칙은 이러한 문제를 줄이기 위해 경제 상황에 맞는 적정 금리 수준을 제시하는 역할을 한다.

비록 실제 중앙은행이 공식대로만 금리를 결정하지는 않지만, 시장에서는 현재 기준금리가 적절한지 평가할 때 자주 활용된다.

4. 쉽게 이해하는 예시

실생활 예시

자동차를 운전할 때 오르막길에서는 속도를 조금 높이고 내리막길에서는 브레이크를 밟는다.

경제도 마찬가지이다.

경기가 너무 뜨거우면 금리를 올려 속도를 줄이고, 경기가 너무 침체되면 금리를 내려 경제활동을 촉진한다.

경제 예시

현재 물가상승률이 5%인데 중앙은행의 목표는 2%라고 가정해보자.

또한 경제성장률도 잠재성장률보다 높아 경제가 과열되고 있다.

이 경우 테일러 준칙은 기준금리를 인상하는 방향을 제시한다.

반대로 물가가 낮고 경기가 침체되어 있다면 기준금리를 인하하는 것이 적절하다고 판단한다.

투자 예시

투자자들은 현재 기준금리가 테일러 준칙이 제시하는 적정 금리보다 낮다면 앞으로 금리 인상 가능성이 있다고 예상할 수 있다.

반대로 적정 금리보다 높다면 금리 인하 가능성을 예상하기도 한다.

5. 핵심 특징

5-1. 물가와 경기를 함께 고려한다

테일러 준칙은 물가만 보는 것이 아니라 경제성장과 경기 상황도 함께 반영한다.

따라서 균형 있는 통화정책을 제시하려는 것이 목적이다.

5-2. 적정 기준금리를 계산하는 기준이다

현재 경제 상황에서 어느 정도의 기준금리가 적절한지 판단하는 참고 기준을 제공한다.

5-3. 중앙은행의 정책을 예측하는 데 활용된다

시장에서는 현재 기준금리가 테일러 준칙과 얼마나 차이가 나는지를 분석하여 향후 통화정책 방향을 예측하기도 한다.

5-4. 실제 정책을 그대로 결정하지는 않는다

현실 경제는 매우 복잡하기 때문에 중앙은행은 금융시장 상황, 환율, 금융안정, 국제경제 등 다양한 요소를 함께 고려한다.

따라서 테일러 준칙은 참고자료일 뿐 절대적인 기준은 아니다.

6. 관련 개념과의 차이

테일러 준칙 vs 기준금리

테일러 준칙

적정 기준금리를 계산하는 이론
경제학적 참고 기준
중앙은행이 반드시 따를 의무는 없음

기준금리

중앙은행이 실제 결정하는 정책금리
금융시장과 경제에 직접 영향을 줌

즉, 테일러 준칙은 기준금리를 계산하는 참고 모델이고, 기준금리는 실제 정책 결정 결과이다.

테일러 준칙 vs 물가목표제

테일러 준칙

물가와 경기 모두 고려
적정 금리를 계산하는 규칙

물가목표제

물가안정을 가장 중요한 목표로 설정
일정 수준의 물가상승률을 유지하는 것이 목적

물가목표제는 정책 목표이고, 테일러 준칙은 금리를 결정하는 방법론에 가깝다.

테일러 준칙 vs 양적완화

테일러 준칙

기준금리를 어떻게 조정할지 판단하는 기준

양적완화(QE)

기준금리가 거의 0%까지 내려간 이후에도 경기부양을 위해 국채 등을 매입하는 정책

즉, 테일러 준칙은 금리정책이고, 양적완화는 금리정책만으로 부족할 때 사용하는 비전통적 통화정책이다.

7. 경제적 의미

국가경제 관점

테일러 준칙은 물가안정과 경제성장을 동시에 고려하는 통화정책의 기준을 제시한다.

경제가 과열되거나 침체되는 상황에서 정책 방향을 판단하는 중요한 참고자료가 된다.

기업 관점

기준금리 변화는 기업의 대출금리와 투자비용에 직접 영향을 준다.

기업들은 중앙은행의 정책 방향을 예측하기 위해 테일러 준칙을 참고하기도 한다.

금융시장 관점

채권시장과 외환시장, 주식시장에서는 테일러 준칙이 제시하는 적정 금리와 실제 기준금리를 비교하여 향후 통화정책을 전망한다.

투자 관점

투자자는 물가상승률과 경제성장률을 함께 살펴보면 향후 금리 방향을 예측하는 데 도움이 된다.

다만 실제 중앙은행은 금융안정, 환율, 국제경제 상황 등 다양한 요소를 함께 고려하기 때문에 테일러 준칙만으로 정책을 단정해서는 안 된다.

8. 정리

테일러 준칙은 물가상승률과 경기 상황을 함께 고려하여 적정 기준금리를 계산하는 경제학 이론이다. 경제가 과열되면 금리를 올리고, 침체되면 금리를 내리는 원칙을 수식으로 정리한 것이 핵심이다. 현재도 세계 여러 중앙은행과 금융시장에서는 통화정책을 분석하는 중요한 참고지표로 활용되고 있다. 다만 현실 경제는 매우 복잡하기 때문에 중앙은행은 테일러 준칙뿐 아니라 금융안정, 환율, 국제경제 등 다양한 요소를 함께 고려하여 기준금리를 결정한다.

경제금융용어 공부 589 : 테이퍼링(Tapering)

MKISOS — Wed, 12 Aug 2026 21:00:46 +0900

테이퍼링(Tapering)

테이퍼링은 중앙은행이 경기 부양을 위해 시행했던 양적완화 정책의 규모를 점진적으로 줄여나가는 것을 의미한다. 쉽게 말해 시중에 풀던 돈의 양을 갑자기 끊는 것이 아니라 조금씩 줄이는 과정이다. 미국 연준(Fed)의 테이퍼링은 전 세계 금융시장에 큰 영향을 미치기 때문에 투자자라면 반드시 알아야 하는 경제 용어 중 하나이다.

1. 한 줄 정의

테이퍼링은 중앙은행이 양적완화 정책에서 자산 매입 규모를 점진적으로 축소하는 통화정책이다.

2. 기본 개념

2008년 글로벌 금융위기 이후 미국 경제는 심각한 침체를 겪었다.

미국 연방준비제도(Fed)는 기준금리를 거의 0% 수준까지 낮췄지만 경기 회복이 충분하지 않았다.

이에 연준은 국채와 주택저당증권(MBS)을 대규모로 매입하여 시중에 돈을 공급하는 양적완화(QE, Quantitative Easing) 정책을 시행했다.

하지만 경제가 점차 회복되면서 무한정 돈을 공급할 수는 없었다.

그래서 연준은 자산을 계속 사들이되 그 규모를 조금씩 줄이기 시작했는데, 이를 테이퍼링(Tapering)이라고 한다.

즉, 테이퍼링은 돈을 풀던 속도를 줄이는 것이지, 당장 시중의 돈을 회수하는 정책은 아니다.

3. 왜 중요한가

테이퍼링은 미국의 통화정책이 완화 국면에서 정상화 국면으로 전환된다는 신호로 받아들여진다.

시중에 공급되는 유동성이 줄어들면 시장금리가 상승할 가능성이 높아지고, 주식이나 부동산처럼 풍부한 유동성의 영향을 받던 자산시장도 영향을 받을 수 있다.

특히 미국의 정책 변화는 달러 가치와 글로벌 자금 이동에 영향을 주기 때문에 신흥국 금융시장까지 큰 영향을 미친다.

4. 쉽게 이해하는 예시

실생활 예시

환자에게 링거를 맞추고 있다고 생각해보자.

환자가 회복되기 시작하면 링거를 갑자기 빼는 것이 아니라 조금씩 투여량을 줄인다.

테이퍼링도 경기 회복에 따라 시중에 공급하던 돈의 양을 서서히 줄여가는 과정과 비슷하다.

투자 예시

연준이 매달 1,000억 달러 규모의 국채를 매입하고 있었다고 가정해보자.

테이퍼링을 시작하면 다음 달에는 900억 달러, 이후에는 800억 달러처럼 매입 규모를 단계적으로 줄인다.

여전히 돈은 공급하지만 이전보다 공급 속도가 느려지는 것이다.

경제 예시

미국이 테이퍼링을 발표하면 미국 국채금리가 상승하는 경우가 많다.

그러면 글로벌 투자자들이 미국으로 자금을 이동시키면서 신흥국에서는 외국인 자금이 빠져나가고 환율과 금융시장이 흔들릴 수 있다.

5. 핵심 특징

5-1. 양적완화를 중단하는 첫 단계이다

테이퍼링은 양적완화를 갑자기 종료하는 것이 아니라 자산 매입 규모를 점진적으로 줄이는 정책이다.

시장 충격을 최소화하기 위해 단계적으로 시행된다.

5-2. 돈은 계속 공급된다

테이퍼링 기간에도 중앙은행은 국채 등을 계속 매입한다.

다만 이전보다 적은 규모로 매입하기 때문에 유동성 증가 속도가 둔화된다.

5-3. 금리와 금융시장에 큰 영향을 준다

테이퍼링이 시작되면 시장은 향후 기준금리 인상 가능성을 예상하기 시작한다.

이 때문에 채권금리, 주가, 환율 등이 함께 움직이는 경우가 많다.

5-4. 글로벌 금융시장에도 영향을 미친다

미국 연준의 테이퍼링은 달러 가치와 국제 자금 흐름을 변화시킨다.

특히 외국인 자금 의존도가 높은 신흥국은 영향을 크게 받을 수 있다.

6. 관련 개념과의 차이

테이퍼링 vs 양적완화(QE)

테이퍼링

자산 매입 규모를 점진적으로 줄임
유동성 공급 속도가 감소함
통화정책 정상화의 시작 단계

양적완화(QE)

국채와 MBS 등을 적극적으로 매입함
시중에 대규모 유동성을 공급함
경기 부양이 목적임

테이퍼링은 양적완화를 되돌리는 첫 단계라고 이해하면 쉽다.

테이퍼링 vs 기준금리 인상

테이퍼링

자산 매입 규모를 줄이는 정책
기준금리는 그대로 유지될 수 있음

기준금리 인상

중앙은행의 정책금리를 직접 올림
대출금리와 예금금리에 직접적인 영향을 줌

일반적으로 테이퍼링이 먼저 시행되고 이후 기준금리 인상이 이어지는 경우가 많다.

테이퍼링 vs 양적긴축(QT)

테이퍼링

자산을 계속 매입하지만 규모만 줄임
중앙은행의 자산은 계속 증가할 수 있음

양적긴축(QT)

보유한 채권을 매각하거나 만기 도래 시 재투자하지 않음
중앙은행의 자산 규모 자체가 감소함

즉, 테이퍼링은 자산 증가 속도를 늦추는 것이고, 양적긴축은 자산 규모 자체를 줄이는 정책이다.

7. 경제적 의미

국가경제 관점

테이퍼링은 경기 회복에 맞춰 통화정책을 정상화하는 과정이다.

과도한 유동성으로 인한 물가 상승과 자산가격 버블을 완화하는 데 도움이 될 수 있다.

기업 관점

시장금리가 상승하면 기업의 자금조달 비용이 증가할 가능성이 있다.

특히 부채가 많은 기업은 이자 부담이 커질 수 있다.

금융시장 관점

테이퍼링 발표는 채권금리 상승, 주식시장 변동성 확대, 달러 강세 등의 변화를 가져오는 경우가 많다.

2013년에는 연준의 테이퍼링 가능성 언급만으로도 금융시장이 크게 흔들렸는데, 이를 테이퍼 텐트럼(Taper Tantrum)이라고 부른다.

투자 관점

투자자는 테이퍼링이 시작되면 금리 민감주, 성장주, 채권시장, 환율 변화를 함께 살펴야 한다.

또한 신흥국 투자 비중이 높은 경우에는 외국인 자금 유출 가능성도 고려할 필요가 있다.

8. 정리

테이퍼링은 중앙은행이 양적완화 정책에서 자산 매입 규모를 점진적으로 줄여나가는 통화정책이다. 이는 시중의 돈을 즉시 회수하는 것이 아니라 유동성 공급 속도를 늦추는 과정이며, 일반적으로 기준금리 인상 이전에 시행된다. 미국 연준의 테이퍼링은 글로벌 자금 흐름과 금리, 주식시장, 환율에 큰 영향을 미치기 때문에 세계 금융시장에서 매우 중요한 정책으로 평가된다.

[UNIKER] AI 서비스는 배포가 끝이 아니었다 | 운영·검증·Physical AI 커리어까지 배운 마지막 라이브 강의 | 경험한 뒤 더 나은 선택을 하자.

MKISOS — Wed, 12 Aug 2026 13:38:45 +0900

커널아카데미 대학생 AI 크루 UNIKER 1기 활동도 어느덧 마지막을 향해 가고 있다.
8월 11일에는 한서우 강사님과 함께하는 마지막 라이브 강의가 진행됐다. 이번 강의의 주제는 「AI 서비스 운영 가이드」였다. 앞선 회차에서 문제를 정의하고, 화면을 만들고, Codex와 API를 활용해 실제 기능을 연결했다면 이번에는 그다음 단계인 “만든 AI 서비스를 실제 사용자에게 보여주려면 무엇을 준비해야 하는가?”를 다뤘다.

우리 팀 ‘핏줄’도 현재 대학생의 경험을 기록하고 필요할 때 다시 활용할 수 있도록 돕는 AI 경험 관리 서비스 CampusLog를 개발하고 있다. 경험 CRUD부터 AI 경험 분석, 경험 추천, 자기소개서·면접·JD 분석 기능까지 구현하고 Vercel을 통해 공개한 상태다.
그래서 이번 강의는 단순히 새로운 기술을 배우는 시간이라기보다, 지금까지 우리가 만든 CampusLog를 ‘작동하는 프로토타입’에서 ‘실제 사람이 사용하는 서비스’로 바라보게 만든 시간이었다.

로컬에서 한 번 성공하는 것과 공개 서비스는 전혀 달랐다

이번 강의에서 가장 먼저 와닿았던 내용은 로컬 프로토타입과 공개 서비스의 차이였다.
혼자 개발할 때는 입력값도 알고 있고, 문제가 발생하면 바로 콘솔을 확인하거나 다시 실행하면 된다. 하지만 여러 사용자가 이용하는 공개 서비스에서는 예상하지 못한 입력이 동시에 들어오고, 문제가 발생했을 때 운영자가 나중에 원인을 찾아야 한다.

강의 자료에서도 이를 명확하게 구분했다.
Codex exec는 로컬 파일을 읽고 코드나 문서를 생성하며 개발·자동화 작업을 수행하는 데 적합하고, 실제 웹이나 모바일 서비스에서는 백엔드에서 인증·검증·요청 제한 등을 거친 뒤 Responses API를 서비스 런타임으로 활용하는 구조가 필요하다.
이 부분을 듣고 CampusLog 역시 단순히 “OpenAI API를 사용했다”에서 끝나는 것이 아니라,
사용자 입력 → 백엔드 검증 → AI 호출 → 구조화된 결과 → 화면 출력
이라는 전체 데이터 흐름을 팀이 정확히 이해해야 한다는 생각이 들었다.

최종 발표에서도 “어떤 API를 썼나요?”라는 질문보다 “왜 이 API와 모델을 선택했고, 데이터가 어떤 흐름으로 처리되나요?”라는 질문에 답할 수 있어야 한다.

“응답을 기다리는 동안도 서비스입니다”

CampusLog를 개발하면서 실제로 고민했던 부분 중 하나가 AI 응답 시간이었다.
경험을 분석하거나 추천을 요청하면 결과가 나오기까지 시간이 걸리는데, 그동안 사용자가 아무것도 하지 못하고 기다리는 경험이 생각보다 길게 느껴졌다.

이번 강의에서는 이를 Streaming과 Background라는 두 방식으로 설명했다.
짧은 생성 작업은 Streaming을 통해 결과가 만들어지는 과정을 조금씩 보여줄 수 있고, 오래 걸리는 작업은 Background로 넘겨 완료된 결과를 나중에 확인하게 만들 수 있다.

하지만 기술적인 방법보다 더 기억에 남은 문장은 따로 있었다.
“응답을 기다리는 동안도 서비스입니다.”
AI 응답 시간이 존재한다면 그 시간을 없애는 것만 고민할 것이 아니라, empty → loading → error → success 상태를 하나의 사용자 경험으로 설계해야 한다는 것이다.
우리 팀도 중간 피드백 이후 AI가 작업 중인 화면은 유지하면서 사용자가 다른 기록이나 활동을 확인할 수 있도록 UX를 개선하고 있었기 때문에 지금 진행하고 있는 고민과 정확하게 맞닿아 있었다.

여러 사람이 동시에 AI 추천을 누르면 어떻게 될까?

강의를 듣다가 CampusLog에서 아직 제대로 확인하지 않았던 문제가 하나 떠올랐다.
현재 사용자 한 명이 경험 분석이나 추천 기능을 사용하는 것은 정상적으로 동작한다. 그런데 유저테스트를 진행하면서 여러 사람이 동시에 AI 추천 버튼을 누르면 어떻게 될까?
지금의 서버와 API 구조가 그 요청을 모두 감당할 수 있을까?

강의에서는 이러한 상황을 위해 Concurrency, Queue, Timeout, Cancel을 다뤘다.
사용자별 호출 횟수와 중복 클릭을 제한하고, 동시에 처리할 수 있는 요청 수만 실행하고, 나머지는 대기열로 보내는 방식이다.
너무 오래 걸리는 요청은 계속 기다리게 할지, 취소할지, 완료되면 나중에 보여줄지도 결정해야 한다.
CampusLog도 앞으로 단순히 “기능이 된다”를 확인하는 테스트에서 한 단계 더 나아가,
1명 → 5명 → 10명 → 여러 명이 동시에 AI 요청 처럼 실제 사용 상황을 가정한 테스트를 해보고 싶다.
그 과정에서 평균 응답 시간, 실패율, 중복 요청, API 비용 등을 함께 기록하면 서비스 운영 측면에서도 의미 있는 데이터가 될 것 같다.

“별로예요”라는 피드백을 받았을 때 원인을 찾을 수 있는가

AI 서비스에서는 결과의 품질 문제도 발생한다.
사용자가 “추천 결과가 별로예요”라고 했다고 가정했을 때, 어떤 요청에서 어떤 모델과 프롬프트를 사용했고 얼마나 오래 걸렸는지 알 수 없다면 원인을 찾기가 어렵다.
그래서 로그에는 request_id, 모델, 프롬프트 버전, latency, 오류, feedback과 같은 정보를 남기는 것이 중요하다.
대신 무엇이든 저장하는 것도 정답은 아니다.
특히 CampusLog는 프로젝트와 대외활동, 지원 경험 등 사용자의 개인적인 정보를 저장하기 때문에 개인정보와 로그의 경계도 신경 써야 한다.
어떤 데이터를 저장하고, 언제 삭제하며, 사용자가 자신의 데이터를 지우면 어디까지 삭제되는지까지 생각해야 비로소 실제 서비스에 가까워진다.

여기에 비용까지 연결된다.
강의 자료의 “한 번의 무료 체험도 운영비입니다”라는 문장이 이 부분을 정확하게 설명했다.
사용자에게 무료로 제공하더라도 서비스 운영자에게는 API 비용이 발생한다. 그래서 일일 사용 횟수, 최대 출력 길이, timeout, API 호출 수, 프로젝트 spend limit 등을 설정하고 반복 클릭이나 동일 요청 폭주 같은 남용도 감지해야 한다.
우리 역시 어떤 AI 모델을 사용할지 결정할 때 단순히 가장 성능이 좋은 모델을 선택할 것이 아니라 CampusLog에서 필요한 품질과 실제 비용을 함께 비교해 선택해야 한다.

그리고 최종 발표에서 “왜 이 모델을 사용했나요?”라는 질문이 나왔을 때도 가격이 싸다거나 유명한 모델이라는 답이 아니라 우리 서비스의 입력 크기, 출력 형태, 추천 품질과 비용을 고려한 선택이었다고 설명할 수 있어야 한다.

Local 성공 후 Preview와 실제 서비스에서 다시 확인하기

이번 강의에서는 Local 성공 후 반드시 공개 환경에서 다시 확인해야 한다고 강조했다.
Vercel을 예로 들면 Local → Preview → Production 환경이 분리돼 있고 환경변수나 API Key도 각각 다르게 설정될 수 있다. 로컬에서는 정상인데 Production에 환경변수가 빠져 기능이 동작하지 않는 문제도 충분히 발생할 수 있다.
따라서 로그인·로그아웃, AI 요청·로딩·오류, 저장·새로고침·복원 등을 Preview와 실제 Domain, 다른 기기에서 반복해서 확인해야 한다.

여기서 한 가지 더 적용해보고 싶은 것이 생겼다.
기능 명세와 테스트 시나리오를 문서로 작성하고 Codex에게 반복적인 테스트를 맡기는 것이다.
단순히 “전체 테스트해줘”가 아니라,
기능 명세 → 정상 케이스 → 오류 케이스 → 경계 조건 → 완료 기준을 먼저 문서화한 뒤 Codex가 테스트 코드를 작성하고 실행하게 한다. 실패한 테스트가 있다면 코드를 수정하고 같은 조건에서 다시 검증한다.

지금까지 Codex를 주로 구현 속도를 높이는 도구로 사용했다면, 남은 기간에는 구현한 기능을 검증하는 도구로도 적극적으로 활용해보고 싶다.

최종 발표에서는 “얼마나 만들었는가”보다 “얼마나 이해했는가”

이번 강의를 통해 최종 데모데이 준비 방향도 훨씬 명확해졌다. 최종 발표에서는 크게 문제, 제품, 검증, 설명을 본다고 했다.
누구의 어떤 문제를 해결하는지 실제로 확인했는가. 핵심 사용자 흐름이 처음부터 끝까지 동작하는가. 실사용자의 피드백이 있었고 그것을 통해 실제로 무엇을 수정했는가. 마지막으로 왜 이 구조와 규칙, 모델을 선택했는지 설명할 수 있는가.
특히 CampusLog는 AI 추천이 핵심 기능 중 하나이기 때문에 마지막 항목이 중요하다.
“AI가 알아서 좋은 경험을 추천합니다.” 라고 말하는 것으로는 부족하다.
왜 경험 세 가지를 추천하는지, 각 경험을 추천한 근거는 무엇인지, 사용자의 어떤 데이터가 입력되는지, 경험 요약은 어떤 방식으로 생성되는지, 자소서와 JD 분석 시 어떤 기준으로 경험을 비교하는지 등을 설명할 수 있어야 한다.
별도의 학습된 추천 모델을 사용한 것이 아니라 LLM과 프롬프트 기반 추천이라면 그것 역시 정확하게 설명해야 한다.

AI가 만든 코드를 많이 보유하는 것과 우리가 그 코드를 이해하고 있는 것은 다른 문제다.
최종 발표 전에는 CampusLog의 코드, 프롬프트, 데이터 흐름, 모델 선택 근거를 다시 확인하면서 팀원 모두가 자신이 만든 기능을 직접 설명할 수 있도록 준비하려고 한다.

강의에서 발표 자료에 넣어야 할 증거로 제시한 것도 인상적이었다.
한 사용자 → 실제 피드백 → 개선 전후 → 백업
새로운 기능 하나를 더 넣는 것보다 실제 사용자가 어디에서 막혔고, 그 문제를 어떻게 개선했는지 보여주는 것이 더 강한 증거가 될 수 있다.

마지막 Q&A, 내가 가장 궁금했던 Physical AI 이야기를 물었다

마지막 30분은 사전 질문과 현장 질문을 중심으로 Q&A가 진행됐다.
나는 곧 컴퓨터비전 분야에서 학부연구생 활동을 시작할 예정이고, 최근 Physical AI와 VLM·VLA, Embodied AI에 관심이 생기면서 어떤 방식으로 공부해야 할지 고민하고 있었다.
아직 논문을 체계적으로 읽은 경험도 많지 않았기 때문에 컴퓨터비전 기초 → VLM → Embodied/Physical AI 로 공부하려면 어떤 순서로 접근해야 하는지, 논문은 어떻게 공부해야 하는지 질문했다.
여기에 개발자·AI 엔지니어 취업, 그리고 장기적으로 창업까지 생각하는 대학생이라면 3학년 시점에서 무엇에 집중할지도 함께 질문했다.

강사님의 첫 번째 조언은 내가 예상했던 논문 리스트가 아니었다.
“논문보다 먼저, 움직여 보기.”
Physical AI에 관심이 있다면 우선 관련 회사의 채용공고를 많이 살펴보라고 하셨다.
여러 회사의 직무 요구사항과 우대사항을 모아보면 반복해서 등장하는 역량이 보인다. 그 교집합을 찾고, 이후 각각의 회사가 실제로 무엇을 만들고 어떤 문제를 해결하는지도 공부해보는 것이다.
그리고 우대사항은 말 그대로 ‘우대’이기 때문에 모든 조건을 만족할 때까지 기다릴 필요도 없다.
“아직 부족하니까 공부를 조금 더 하고…” 를 반복하기보다 인턴이나 실제 조직에 들어가 실무 경험을 해보는 것도 중요하다는 이야기가 기억에 남았다.
Physical AI라면 논문을 읽는 것도 중요하지만 실제 로봇을 다뤄보고, 작은 로봇이라도 직접 움직이고 데이터를 다뤄보는 경험이 훨씬 많은 것을 알려줄 수 있다.

논문 여러 편을 요약하기보다 한 편을 직접 재현해보기

논문 공부에 대한 답변도 내 생각을 많이 바꿨다.
AI를 이용해 논문을 빠르게 요약하고 여러 편을 블로그나 GitHub에 정리하는 것보다, 논문 한 편을 선택해서 실제로 재현해보는 것이 훨씬 가치 있는 경험이 될 수 있다는 이야기였다.

논문을 하나 선택한다.
코드와 데이터가 존재하는지 확인한다.
논문의 수치와 결과를 직접 재현한다.
그다음 데이터, 조명, 모델 등 조건 하나를 변경한다.
그리고 마지막에 “왜 결과가 달라졌지?” 라는 새로운 질문을 만들어본다.

논문을 읽는 사람이 아니라 연구를 조금씩 시작하는 사람의 방식에 더 가까운 접근이라고 느꼈다.
앞으로 학부연구생 활동을 시작하면 처음부터 많은 논문을 읽어야 한다는 압박을 가지기보다, 하나의 논문을 제대로 이해하고 직접 실행해보는 것부터 시작해보고 싶다.

이것저것 해보며 ‘내 감각’을 기르라는 답변

마지막으로 “대학교 3학년 2학기로 다시 돌아간다면 무엇을 하시겠냐”는 질문에 대한 답변도 기억에 많이 남았다.
정답은 하나의 분야에 모든 시간을 투자하는 것이 아니었다.
인턴, 연구, 행사, 프로젝트 등 다양한 경험을 해보고 학교 밖의 다양한 사람을 만나보라는 것이었다.
그리고 경험을 할 때마다 결과만 기록하는 것이 아니라,
나는 이 경험이 좋았는가.
싫었다면 무엇이 싫었는가.
어떤 일을 할 때 시간이 빠르게 지나갔는가.
를 스스로 확인하는 것이다.

결국 여러 경험을 거쳐야 자신의 감각이 생기고 그다음에야 무엇을 선택하고 무엇을 버릴지 결정할 수 있다는 이야기였다.
요즘은 AI를 통해 과제를 빠르게 끝내고 새로운 기술을 계속 따라갈 수 있다. 하지만 그럴수록 AI에게 생각까지 맡기지 않고 자신의 생각을 직접 해보는 것이 중요하다는 조언도 해주셨다.

이 부분이 특히 마음에 들었다.
내가 평소 중요하게 생각하는 가치 중 하나가 Fail Fast이기 때문이다.
처음부터 완벽한 선택을 하려고 오래 고민하기보다 직접 경험해보고, 실패하면 거기에서 배운 뒤 다음 선택을 더 잘하는 방식.
이번 답변을 들으면서 서비스 개발뿐 아니라 연구와 커리어에서도 결국 같은 태도가 필요하다는 생각이 들었다.

마지막 강의를 듣고, CampusLog의 목표도 조금 달라졌다

이번 UNIKER 마지막 라이브 강의 전까지 가장 큰 목표는 최종 데모데이에서 CampusLog를 잘 보여주는 것이었다.
물론 지금도 당장의 목표는 최종 발표다.
하지만 이번 강의를 들으며 이 프로젝트를 UNIKER의 10주짜리 결과물로 끝내고 싶지 않다는 생각이 더 강해졌다.

올해 안에 부족한 구조를 정리하고 CampusLog를 실제 앱으로 발전시켜보는 것이 다음 목표다.
그리고 이후에는 학교라는 실제 사용자 환경에서 직접 서비스를 배포해보고 싶다.
사람들이 실제로 사용하기 시작하면 지금까지 경험하지 못했던 문제가 생길 것이다.
동시에 AI 요청이 들어올 수도 있고, 예상하지 못한 오류가 발생할 수도 있다. 사용자 문의가 들어오고, API와 서버 비용을 직접 확인해야 하며, 장애가 발생하면 원인을 찾아 다시 배포해야 한다.
그 과정까지 직접 경험해보고 싶다.

최종적으로는 Google Play와 App Store에 CampusLog라는 이름을 실제로 올려보는 것이 하나의 목표가 됐다.
그렇게 된다면 CampusLog는 단순히 포트폴리오에 적는 “AI 프로젝트를 개발했다.” 라는 한 줄을 넘어,
문제 발견 → 기획 → 구현 → AI 연결 → 배포 → 사용자 테스트 → 피드백 → 운영 → 비용 관리 → 장애 대응 → 개선
까지 직접 경험한 하나의 제품이 될 수 있을 것 같다.

마지막 강의를 마치며

UNIKER 활동을 처음 시작했을 때는 AI 서비스를 만드는 과정에서 “무엇을 구현할 것인가?”가 가장 큰 고민이었다.
하지만 실제로 CampusLog를 만들고 배포하고 사용자에게 보여주기 시작하면서 질문이 바뀌었다.
“사람들이 실제로 사용할 수 있게 하려면 무엇이 더 필요한가?”

이번 강의 자료의 전체 흐름도 결국 이 질문에 답하고 있었다. 프로토타입에서 공개 서비스로 넘어가는 순간 인증, 입력 검증, 동시 요청, Queue, 오류 처리, 로그, 개인정보, 비용, QA, 운영 책임이라는 새로운 문제가 등장한다.
그리고 마지막 Q&A를 통해 기술이나 커리어에서도 비슷한 결론을 얻었다.

모든 것을 완벽하게 준비한 뒤 시작하려고 하지 말 것.
논문만 읽지 말고 직접 코드를 돌려볼 것.
채용공고만 고민하지 말고 실제 회사와 프로젝트를 경험해볼 것.
여러 경험 속에서 내가 좋아하는 것과 싫어하는 것을 확인하고, 그 뒤에 선택과 집중을 할 것.

이번 마지막 강의에서 가져가는 가장 큰 문장은 두 가지다.
만든 것을 직접 설명할 수 있을 만큼 이해하자.
그리고, 일단 움직이고, 경험한 뒤 더 나은 선택을 하자.

남은 UNIKER 기간에는 새로운 기능의 개수보다 CampusLog의 핵심 흐름을 더 안정적으로 만들고, 실제 사용자 피드백을 반영하며, 우리가 선택한 AI 추천 구조와 모델을 스스로 설명할 수 있을 정도로 프로젝트를 다시 들여다볼 예정이다.

처음에는 하나의 아이디어였던 CampusLog가 어느새 실제 사용자가 접속할 수 있는 서비스가 됐다.
이제 마지막 데모데이에서는 ‘무엇을 만들었는가’뿐 아니라 ‘왜 이렇게 만들었고, 실제 사용자를 통해 무엇을 배웠는가’까지 보여주고 싶다.

라이브강의

[UNIKER] 지인 테스트를 시작하고, CampusLog의 ‘개발 이후 운영’을 고민하다

MKISOS — Wed, 12 Aug 2026 09:16:38 +0900

커널아카데미 대학생 AI 크루 UNIKER 1기 활동도 어느덧 후반부로 들어가고 있다.

지난 8월 2일 중간 데모데이에서는 팀 핏줄의 AI 경험 관리 서비스 CampusLog를 실제 크루들과 멘토님들 앞에서 시연했다. 경험 기록부터 AI 분석, 부족 정보 보완, 자기소개서·면접·JD 기반 경험 추천까지 지금까지 구현한 전체 흐름을 직접 보여드릴 수 있었다.

중간 발표를 마친 뒤에는 멘토님께 받은 피드백을 반영하고 실제 사용자 테스트를 빠르게 진행하려고 했다.

하지만 이번 주에는 팀원들의 개인 일정과 다른 대회 일정이 겹치면서 큰 기능 개발을 진행하지는 못했다.

대신 지금까지 팀 내부에서만 반복하던 테스트를 벗어나, 실제 대학생 지인을 대상으로 CampusLog 사용자 테스트를 시작했다.

이번 주는 새로운 기능을 많이 추가한 주라기보다, 지금까지 만든 서비스를 실제 사람이 사용했을 때 어떤 문제가 생기는지 확인하고, 앞으로 CampusLog를 단순한 프로젝트가 아니라 실제 운영 가능한 서비스로 발전시키기 위해 무엇을 준비해야 하는지 고민한 한 주였다.

STEP 1. 이번 주 목표 — 개발보다 실제 사용자를 만나보기

중간 데모데이 이전까지는 서비스의 핵심 흐름을 만드는 것이 가장 중요했다.

기록하고, 분석하고, 추천받는 전체 과정이 실제로 연결되어야 했기 때문에 개발팀 내부에서 더미 데이터를 넣고 기능을 반복해서 실행하는 방식으로 테스트했다.

하지만 중간 발표 이후에는 상황이 달라졌다.

팀원들에게는 이미 익숙한 서비스이기 때문에 버튼의 위치나 용어가 조금 이상해도 자연스럽게 다음 화면으로 넘어갈 수 있다.

반대로 처음 CampusLog를 접한 사람은

어디에서 경험을 추가해야 하는지
‘오늘의 기록’과 ‘나의 활동’의 차이가 무엇인지
AI 분석을 왜 해야 하는지
부족 정보에는 무엇을 입력해야 하는지
AI 추천 기능에서 어떤 질문을 입력해야 하는지

자체를 이해하지 못할 수 있다.

그래서 이번 주에는 가까운 지인 중 몇 명을 먼저 선정해 작은 규모로 테스트를 진행하기로 했다.

불특정 다수에게 바로 공개하는 대신, 피드백을 편하게 받을 수 있는 사람들을 대상으로 오픈채팅방을 만들고 테스트 링크를 전달했다.

[CampusLog 사용자 테스트 오픈채팅방 화면]

테스트를 시작한 지 오래되지 않았지만 벌써 팀 내부에서는 발견하지 못했던 여러 오류와 사용성 문제가 나오고 있다.

이 부분들은 단순히 버그 목록으로 끝내지 않고, 이번 주부터 우선순위를 정해 하나씩 수정할 예정이다.

STEP 2. 지인 테스트를 통해 발견하기 시작한 실제 문제

이번 테스트의 가장 큰 목적은 “서비스가 실행되는가?”를 확인하는 것이 아니다.

이미 개발팀 환경에서는 로그인, 경험 기록, AI 분석, 경험 추천 등의 주요 흐름이 작동하는 것을 반복해서 확인했다.

이제 확인해야 하는 것은

처음 사용하는 대학생도 설명 없이 CampusLog의 가치를 이해하고 사용할 수 있는가?

이다.

그래서 지인들에게 단순히 링크만 전달하고 끝내기보다 실제 서비스를 사용해보면서 불편했던 부분, 이해하기 어려웠던 기능, 오류가 발생한 상황을 자유롭게 전달해달라고 요청하고 있다.

현재 테스트를 통해 발견된 문제들은 이번 주부터 팀 회의를 통해 정리할 예정이다.

특히 지난 중간 데모데이에서 받은 피드백 중 아직 반영하지 못한 부분도 남아 있어,

사용자 테스트 피드백 + 중간 데모 멘토 피드백 + 기존 QA 이슈

를 하나의 개선 목록으로 합쳐 우선순위를 다시 정하려고 한다.

이번 과정에서 느낀 것은 개발자가 직접 테스트하는 것과 실제 사용자가 테스트하는 것은 정말 다르다는 점이다.

개발자는 기능이 어떻게 만들어졌는지 알고 있기 때문에 자연스럽게 서비스가 의도한 흐름을 따라간다.

하지만 사용자는 개발자의 의도를 알 필요가 없다.

화면만 보고 다음 행동을 이해할 수 있어야 한다.

결국 사용자 테스트는 단순히 버그를 잡기 위한 과정이 아니라 우리가 만든 사용자 흐름 자체가 실제로 통하는지 검증하는 과정이라는 생각이 들었다.

8월 9일 멘토링 — “이제 실제 서비스로 공개하면 무엇을 준비해야 할까?”

8월 9일 UNIKER 멘토링에서는 중간 데모 이후의 진행 상황을 공유했다.

이번 주에는 일정 문제로 큰 개발은 진행하지 못했고, 중간 데모에서 발생했던 오류를 우선 수정한 뒤 지인 테스트를 시작했다고 말씀드렸다.

그리고 이번에는 기능 구현 자체보다 조금 더 먼 질문을 드렸다.

“지인 테스트 인원이 많아지고, 나중에는 학교 학생들에게까지 서비스를 공개하고 싶다면 OpenAI API 비용이나 서버 비용은 어떻게 예상해야 할까요?”

현재 CampusLog는 AI 분석과 추천 과정에서 LLM API를 호출한다.

소수의 팀원과 지인이 사용하는 단계에서는 비용이 크지 않지만, 사용자가 늘어났을 때 한 명이 평균적으로 얼마나 많은 토큰을 사용하는지, 동시에 많은 요청이 들어오면 어느 정도까지 감당할 수 있는지에 대한 기준은 아직 없었다.

멘토님께서는 먼저 대표적인 사용자 흐름을 하나 정하고 실제로 한 명이 해당 흐름을 끝까지 사용했을 때 소비되는 토큰과 요청 횟수를 측정해보는 것이 좋다고 조언해주셨다.

예를 들어 CampusLog 사용자가 다음 행동을 한다고 가정할 수 있다.

경험 3개 등록
→ 경험별 AI 분석
→ 부족 정보 보완
→ 자기소개서 문항 입력
→ 경험 추천
→ 답변 초안 생성

이 한 사이클에서 사용하는 입력·출력 토큰과 API 호출 횟수를 측정하면,

사용자 10명, 100명, 1,000명으로 확대했을 때 대략 어느 정도의 비용이 발생할지 추정할 수 있다는 것이다.

LLM 서비스도 결국 ‘모니터링’이 필요하다

멘토링에서는 자연스럽게 LLMOps와 서비스 모니터링에 대한 이야기로 이어졌다.

단순히 OpenAI API를 호출하고 결과를 화면에 보여주는 것을 넘어,

요청마다 얼마나 많은 토큰을 사용하는지
AI 응답까지 얼마나 걸리는지
첫 응답이 나오기까지 시간이 얼마나 걸리는지
어느 API에서 오류가 많이 발생하는지
특정 사용자가 비정상적으로 많은 요청을 보내지는 않는지

등을 확인할 수 있어야 실제 서비스를 운영할 수 있다는 이야기였다.

멘토님께서는 LLM 호출 흐름을 관리하고 관찰하는 도구들과 함께, 웹 서비스 운영에서 사용되는 여러 모니터링 도구를 소개해주셨다.

특히 기억에 남았던 것은 다음과 같다.

Sentry

웹 애플리케이션 내부의 오류와 성능 문제를 추적할 수 있는 APM(Application Performance Monitoring) 도구로 소개해주셨다.

사용자가 어떤 흐름에서 오류를 만났는지, 특정 API 요청에서 어떤 문제가 발생했는지를 개발자가 추적하는 데 활용할 수 있다.

Prometheus + Grafana

CPU, 메모리, 네트워크, 서버 상태와 같은 시스템 지표를 수집하고 이를 Grafana 대시보드로 시각화할 수 있다고 설명해주셨다.

Grafana에는 이미 다른 사람들이 만든 다양한 대시보드 템플릿도 존재하기 때문에 필요한 환경에 맞게 가져와 수정해 사용할 수도 있다고 했다.

nGrinder

모니터링과는 조금 다른 영역으로, 많은 사용자가 동시에 서비스에 접속하는 상황을 가정한 부하 테스트에 활용할 수 있다고 설명해주셨다.

예를 들어 동시에 수백~수천 개의 요청을 발생시키고,

로그인 → 메뉴 이동 → 특정 API 호출

같은 실제 행동 흐름을 반복하게 만들어 어느 정도의 트래픽까지 서비스가 버틸 수 있는지 확인할 수 있다.

지금 당장 CampusLog에 이 모든 운영 시스템을 붙여야 하는 것은 아니다.

하지만 지금까지는

“기능이 잘 동작하는가?”

만 생각했다면,

이번 멘토링을 통해 처음으로

“실제 사용자가 늘어나도 안전하고 안정적으로 동작하는가?”

라는 다음 단계의 질문을 생각하게 되었다.

불특정 다수에게 공개하는 순간 생기는 새로운 문제

특히 멘토님께서는 소수 지인을 대상으로 테스트하는 것과 서비스를 불특정 다수에게 공개하는 것은 전혀 다른 문제라고 강조하셨다.

현재처럼 지인을 한 명씩 선정해서 테스트한다면 어느 정도 사용량을 통제할 수 있다.

하지만 학교 커뮤니티나 학과 단체방 등에 링크를 공개한다면 서비스는 외부 공격과 비정상적인 사용에도 노출된다.

예를 들어 누군가 AI API를 반복해서 호출한다면 짧은 시간 안에 API 비용이 급격하게 증가할 수 있다.

따라서 실제 공개 서비스에서는

사용자별 호출 제한
API 요청 횟수 제한
입력 길이 제한
지나치게 큰 출력 요청 제한
인증된 사용자만 AI 기능 사용
비정상적인 반복 요청 탐지
Prompt Injection 대응
예상 비용 초과 시 차단 또는 알림

등도 함께 고민해야 한다.

CampusLog를 만들면서 이미 로그인과 사용자별 DB, 기본적인 AI API 요청 제한을 구현했지만, 실제 운영 관점에서는 더 많은 검증이 필요하다.

이야기를 들으며 프로토타입을 개발하는 것과 서비스를 운영하는 것은 완전히 다른 단계라는 것을 다시 느꼈다.

서비스 개발과 운영은 다르다

멘토님께서는 인프라나 DevOps, MLOps, LLMOps 분야를 진로로 생각한다면 모니터링은 기본적인 역량 중 하나라고 설명해주셨다.

개발자에게도 APM이나 로그 분석 능력은 도움이 되지만, 운영 분야에서는

서버
네트워크
OS
가상화
VM과 Container
Docker
Kubernetes
모니터링
Alert
장애 대응

같은 기반 지식이 더욱 중요하다고 했다.

CampusLog는 현재 Vercel과 Supabase 같은 관리형 서비스를 활용하고 있어 직접 서버를 운영하는 부분은 많지 않다.

하지만 사용자가 늘어나는 상황을 고민하다 보니 자연스럽게 백엔드 개발을 넘어 서비스 운영, 트래픽, 비용, 보안까지 관심 범위가 넓어지고 있다.

UNIKER 프로젝트 하나를 진행하면서 프론트엔드와 AI API뿐 아니라 인증, DB, 운영과 모니터링까지 연결해서 생각해볼 수 있다는 점도 이번 프로젝트의 재미있는 부분이다.

엔지니어도 결국 많은 사람과 협업한다

멘토링 후반에는 멘토님의 실제 업무에 대해서도 질문했다.

현재는 금융권에서 AI 관련 업무를 하고 계시지만, 단순히 모델이나 시스템을 개발하는 일만 하는 것은 아니라고 했다.

특히 금융권에서는 서비스를 하나 도입하기 위해서도 보안, 준법, 컴플라이언스, 클라우드 사용 정책 등 여러 조건을 확인해야 한다.

그래서 실제 업무에서는 개발만큼이나 다른 부서와 회의하고, 요구사항을 정리하고, 문서를 작성하고, 내부 심사를 준비하는 일이 많다고 했다.

기술적으로 좋은 서비스를 만드는 것만으로 실제 서비스가 바로 운영되는 것은 아니다.

회사 규모가 커질수록 보안과 정책, 규정, 조직 간 협업까지 함께 고려해야 한다.

CampusLog에서도 이미 팀원 사이의 문서화와 GitHub 협업이 중요했는데, 실제 회사에서는 이런 협업 능력이 훨씬 더 중요해질 수 있다는 것을 느꼈다.

회의 많이 했는데 사진이 없네...

STEP 3. 이번 주 Key Takeaways

이번 주에는 새로운 기능을 많이 만들지는 못했다.

하지만 프로젝트 단계가 바뀌고 있다는 것은 느낄 수 있었다.

초반에는

“CampusLog를 실제로 만들 수 있을까?”

가 가장 큰 고민이었다.

중간에는

“AI 분석과 경험 추천이 제대로 작동할까?”

를 고민했다.

그리고 이제는

“실제 사람들이 이 서비스를 사용할 수 있을까?”

를 고민하고 있다.

이번 주 가장 크게 배운 점은 세 가지다.

1. 팀 내부 테스트만으로는 사용성을 검증하기 어렵다

개발자는 이미 서비스 구조를 알고 있기 때문에 사용자가 느끼는 진입 장벽을 발견하기 어렵다.

실제 사용자를 최대한 빨리 만나야 한다.

2. AI 서비스의 비용은 감이 아니라 측정해야 한다

대표 사용자 흐름을 정의하고 한 명이 사용하는 토큰과 호출 횟수를 실제로 측정한 뒤 규모에 따라 비용을 예측해야 한다.

3. 개발 완료와 서비스 운영 가능은 다르다

사용자가 증가하면 보안, API 제한, 장애 추적, 모니터링, 부하 테스트와 비용 관리까지 새로운 문제가 발생한다.

이번 멘토링을 통해 CampusLog를 단순한 UNIKER 프로젝트가 아니라 작은 서비스라는 관점에서 한 번 더 바라보게 되었다.

Next Step — 이번 주부터 다시 개발 집중

이번 주부터는 지인 테스트에서 들어오는 피드백을 본격적으로 개발에 반영할 예정이다.

우선순위는 다음과 같다.

1. 지인 테스트 오류 수정

오픈채팅방에서 전달받은 오류를 하나씩 재현하고, 사용자 흐름을 막는 문제부터 수정한다.

2. 중간 데모 피드백 반영

중간 발표 이후 아직 반영하지 못한 항목들을 다시 정리한다.

특히

AI 응답 대기 경험 개선
백그라운드 처리와 진행 상태
완료 알림
경험 입력 부담 감소
멀티모달 경험 입력
면접 단계까지의 활용

을 다시 검토할 예정이다.

3. 사용자 테스트 체계화

단순히 “써보고 알려주세요”에서 끝내지 않고 주요 사용 과업을 정리해볼 계획이다.

예를 들어

로그인 → 경험 등록 → AI 분석 → 부족 정보 답변 → 자기소개서 문항 입력 → 경험 추천

의 흐름을 실제 사용자가 끝까지 수행할 수 있는지 확인한다.

4. API 사용량과 오류 모니터링

현재 사용자 한 명이 대표 흐름을 수행했을 때 몇 번의 AI 요청을 하고 얼마나 많은 토큰을 사용하는지 측정해볼 예정이다.

Sentry를 비롯해 이번 멘토링에서 알게 된 모니터링 도구들도 CampusLog 규모에서 어떤 방식으로 적용할 수 있을지 공부해보려고 한다.

5. 최종 데모를 위한 서비스 안정화

이제 새로운 기능의 개수를 늘리는 것보다 실제 사용자가 안정적으로 서비스를 이용할 수 있도록 만드는 것이 더 중요하다.

최종 발표 전에는 사용자 테스트와 반복적인 시연 리허설을 통해 이전 중간 데모에서 발생했던 것과 같은 돌발 오류를 최대한 줄일 계획이다.

마무리

이번 주는 개발량만 보면 지난주보다 조용한 한 주였다.

팀원들의 일정이 겹치면서 계획했던 기능을 모두 진행하지는 못했다.

하지만 가까운 지인들에게 CampusLog를 처음 공개하고, 개발팀 밖에서 서비스를 바라보기 시작했다는 점에서는 중요한 전환점이었다.

실제로 사용해보는 사람이 생기자 지금까지 발견하지 못했던 오류가 나오기 시작했고, 사용자가 서비스를 이해하는 방식 역시 우리가 생각했던 것과 다를 수 있다는 것을 확인하고 있다.

8월 9일 멘토링에서는 그보다 더 먼 단계인 서비스 운영에 대해서도 생각해볼 수 있었다.

사용자가 몇 명까지 늘어날 수 있는지, AI API 비용은 어떻게 계산할지, 오류는 어떻게 추적할지, 악의적인 요청을 어떻게 막을지.

아이디어를 구현하는 것에서 출발했던 CampusLog가 이제는 이런 질문까지 고민하게 되었다.

남은 UNIKER 기간에는 새로운 기능을 계속 추가하기보다,

실제 대학생이 CampusLog를 편하게 사용할 수 있는가

를 검증하는 데 집중하려고 한다.

지인 테스트에서 발견한 문제와 지난 중간 데모 피드백을 하나씩 정리하면서, 최종 데모에서는 지금보다 훨씬 안정적이고 자연스러운 CampusLog를 보여줄 수 있도록 준비해보겠다.

경제금융용어 공부 588 : 탄소배출권

MKISOS — Tue, 11 Aug 2026 21:00:57 +0900

탄소배출권

기업이나 국가는 경제활동 과정에서 이산화탄소를 비롯한 온실가스를 배출한다. 탄소배출권은 이러한 온실가스를 일정한 범위 안에서 배출할 수 있도록 부여된 권리이다. 배출량을 줄여 배출권이 남은 기업은 이를 판매할 수 있고, 감축 목표를 달성하지 못한 기업은 배출권을 구매해야 한다. 환경문제 해결에 시장의 가격과 거래 원리를 활용한 제도라고 할 수 있다.

1. 한 줄 정의

탄소배출권은 기업이나 국가가 정해진 기간 동안 일정량의 온실가스를 배출할 수 있도록 인정받은 권리이다.

2. 기본 개념

탄소배출권은 정부나 국제기구가 기업 또는 국가에 허용한 온실가스 배출 한도를 권리의 형태로 만든 것이다.

일반적으로 탄소배출권 1단위는 이산화탄소 1톤 또는 이와 같은 온실효과를 일으키는 다른 온실가스의 양을 배출할 수 있는 권리를 의미한다.

정부는 온실가스 감축 목표에 따라 기업별 배출 허용량을 정한다.

기업이 할당량보다 적게 배출하면 남은 배출권을 다른 기업에 판매할 수 있다. 반대로 허용량을 초과해 온실가스를 배출한 기업은 부족한 배출권을 시장에서 구매해야 한다.

이처럼 배출권에 가격을 부여하고 거래할 수 있게 만든 제도를 배출권거래제라고 한다.

3. 왜 중요한가

온실가스는 배출 과정에서 기업이 직접 비용을 부담하지 않더라도 기후변화와 환경오염이라는 사회적 비용을 발생시킨다.

기업이 이러한 비용을 고려하지 않으면 온실가스를 지나치게 많이 배출할 가능성이 있다.

탄소배출권 제도는 온실가스 배출에 경제적 비용을 부과한다. 배출량이 많을수록 더 많은 배출권을 구매해야 하므로 기업은 자연스럽게 에너지 효율을 높이고 배출량을 줄이려 한다.

반대로 온실가스를 적게 배출한 기업은 남은 배출권을 판매해 추가 수익을 얻을 수 있다.

따라서 탄소배출권은 규제와 시장원리를 결합해 온실가스 감축을 유도하는 제도이다.

4. 쉽게 이해하는 예시

실생활 예시

학교가 동아리별로 한 달 동안 사용할 수 있는 전력량을 정했다고 가정해보자.

A동아리는 허용량보다 전기를 적게 사용해 사용권이 남았다. 반면 B동아리는 행사를 많이 열어 전력 사용량이 허용량을 초과했다.

A동아리가 남은 전력 사용권을 B동아리에 판매할 수 있도록 한 구조가 탄소배출권 거래와 비슷하다.

기업 예시

정부가 A철강회사에 연간 100만 톤의 탄소배출권을 할당했다고 가정해보자.

A회사가 친환경 설비를 도입해 실제로 90만 톤만 배출했다면 10만 톤에 해당하는 배출권이 남는다.

이 배출권을 감축 목표를 달성하지 못한 다른 기업에 판매해 수익을 얻을 수 있다.

투자 예시

탄소배출권 가격이 상승하면 온실가스를 많이 배출하는 기업의 비용 부담이 커질 수 있다.

반대로 신재생에너지, 전기차, 에너지효율 기술을 보유한 기업은 탄소 감축 수요가 늘면서 새로운 사업 기회를 얻을 수 있다.

경제 예시

온실가스 감축비용이 낮은 기업은 적극적으로 배출량을 줄인 뒤 남은 배출권을 판매한다.

감축비용이 매우 높은 기업은 당장 설비를 모두 교체하기보다 배출권을 구매해 규제를 충족할 수 있다.

그 결과 경제 전체에서는 상대적으로 적은 비용으로 온실가스를 줄일 수 있다.

5. 핵심 특징

5-1. 온실가스 배출에 가격을 부여한다

탄소배출권 제도에서는 온실가스를 배출하는 행위가 기업의 비용으로 연결된다.

탄소배출권 가격이 높아질수록 기업이 온실가스를 줄일 경제적 유인도 커진다.

5-2. 배출권을 사고팔 수 있다

배출량을 많이 줄인 기업은 남은 배출권을 판매할 수 있다.

배출 허용량을 초과한 기업은 부족한 배출권을 시장에서 구매해야 한다.

5-3. 기업마다 다른 감축비용을 활용한다

모든 기업이 같은 비용으로 온실가스를 줄일 수 있는 것은 아니다.

감축비용이 낮은 기업이 더 많이 줄이고 배출권을 판매하도록 하면 경제 전체의 온실가스 감축비용을 낮출 수 있다.

5-4. 정책에 따라 가격이 크게 변할 수 있다

탄소배출권의 공급량은 정부의 할당정책과 감축 목표에 영향을 받는다.

배출 한도가 강화되거나 공급량이 줄어들면 배출권 가격이 상승할 수 있다.

6. 관련 개념과의 차이

탄소배출권 vs 탄소세

탄소배출권

정부가 전체 배출 허용량을 정함
기업이 배출권을 서로 거래함
시장의 수요와 공급으로 가격이 결정됨
배출량을 직접 관리하는 방식임

탄소세

온실가스 배출량에 따라 세금을 부과함
정부가 탄소 가격을 직접 결정함
기업은 배출량만큼 세금을 납부함
가격을 통해 배출 감축을 유도하는 방식임

탄소배출권은 배출량을 먼저 정하고 가격을 시장에 맡기는 방식이다. 탄소세는 가격을 먼저 정하고 기업이 그 가격에 반응하도록 만드는 방식이다.

탄소배출권 vs 탄소크레딧

탄소배출권

정부가 정한 배출 한도 안에서 온실가스를 배출할 수 있는 권리임
주로 배출권거래제 참여 기업에 할당됨

탄소크레딧

산림 조성, 신재생에너지 사업 등으로 온실가스를 감축하거나 흡수한 실적을 인증한 것임
감축사업을 통해 새롭게 만들어질 수 있음

탄소배출권은 배출할 수 있는 권리에 가깝고, 탄소크레딧은 온실가스를 실제로 줄인 성과를 증명하는 단위에 가깝다.

탄소배출권 vs 신재생에너지 인증서

탄소배출권

온실가스 배출량을 관리함
탄소 감축이 핵심 목적임

신재생에너지 인증서

신재생에너지로 전력을 생산했다는 사실을 인증함
재생에너지 보급 확대가 핵심 목적임

둘 다 친환경 정책에 활용되지만 관리하는 대상과 정책 목적이 다르다.

7. 경제적 의미

국가경제 관점

탄소배출권은 국가가 온실가스 감축 목표를 달성하기 위한 핵심 정책수단이다.

배출량을 줄이는 동시에 기업들이 가장 효율적인 방식으로 감축하도록 유도해 사회 전체의 비용을 낮출 수 있다.

기업 관점

온실가스를 많이 배출하는 기업에는 탄소배출권 구입이 새로운 생산비용이 된다.

반대로 친환경 설비에 투자해 배출량을 줄인 기업은 배출권 판매수익과 비용 절감 효과를 얻을 수 있다.

금융시장 관점

탄소배출권이 거래되면서 환경정책이 금융상품과 연결된다.

배출권 가격은 정부 정책, 경기, 에너지 가격, 기업 생산량 등에 따라 변하며 새로운 원자재 성격의 시장을 형성한다.

투자 관점

탄소배출권 가격 상승은 철강, 시멘트, 정유, 발전처럼 탄소배출량이 많은 산업에 부담이 될 수 있다.

반면 신재생에너지, 탄소포집·저장, 전기차, 에너지효율 기술 관련 기업에는 성장 기회가 될 수 있다.

투자자는 기업의 현재 배출량뿐 아니라 감축설비 투자계획과 배출권 구매비용도 함께 살펴봐야 한다.

8. 정리

탄소배출권은 기업이나 국가가 일정 기간 동안 정해진 양의 온실가스를 배출할 수 있도록 부여된 권리이다. 배출량을 줄여 배출권이 남은 기업은 이를 판매하고, 허용량을 초과한 기업은 배출권을 구매해야 한다. 이 제도는 온실가스 배출에 경제적 비용을 부과해 기업의 자발적인 감축과 친환경 투자를 유도한다. 탄소배출권은 기후변화 대응뿐 아니라 기업의 비용구조와 산업 경쟁력, 투자환경에도 큰 영향을 미치는 중요한 경제제도이다.

[랭플릭스(LangFlix) 서포터즈 1기] 유튜브·넷플릭스로 영어 공부? 랭플릭스란 무엇인가 | AI 쉐도잉 영어 학습 시작하기

MKISOS — Tue, 11 Aug 2026 13:19:18 +0900

본 포스팅은 2026 랭플릭스 서포터즈 1기 활동의 일환으로 작성되었으며, 활동을 위해 랭플릭스 프리미엄 이용권을 제공받았습니다. 직접 서비스를 사용하면서 느낀 점을 바탕으로 솔직하게 기록합니다.

요즘 다시 영어 공부를 제대로 해봐야겠다는 생각을 많이 하고 있다.
사실 영어 공부 자체는 예전부터 계속 해야 한다고 생각했는데, 항상 문제가 하나 있었다.

꾸준히 하기가 어렵다.
단어장도 사보고, 영어 회화 영상도 찾아보고, 유튜브도 영어로 봐보려고 했는데 결국 어느 순간부터 안 하게 된다. ~~(루틴화 시키면 금방이긴한데 너무 핑계를 대자면 너무 해야 할 것들이 많다...)~~

특히 나는 앞으로 개발자로 일하면서 해외 취업에도 한번 도전해보고 싶고, 영어 면접도 준비해야 한다.
가까운 목표로는 OPIc IH 이상도 받아보고 싶다. 그러다 보니 단순히 시험 문제를 잘 푸는 것보다 “실제로 영어를 듣고, 이해하고, 내 입으로 말할 수 있는 능력” 을 만들고 싶다는 생각을 많이 하고 있었다.

그러던 중 이번에 운 좋게 랭플릭스(LangFlix) 서포터즈 1기로 활동하게 됐다.
약 두 달 동안 프리미엄 기능을 직접 사용해볼 수 있게 됐는데, 기왕 하는 거 그냥 몇 번 사용하고 홍보 글 몇 개 쓰는 것보다는 아예 이 기간 동안 내 영어 공부 루틴을 한번 만들어보기로 했다.

그래서 첫 번째 글은 가볍게, “그래서 랭플릭스가 뭔데?” 부터 정리해보려고 한다.

랭플릭스(LangFlix)가 뭔데?

랭플릭스를 아주 간단하게 설명하면
유튜브나 넷플릭스 같은 영상 콘텐츠를 활용해서 영어를 공부할 수 있게 만들어주는 서비스다.
처음 이름을 들었을 때 나도 “Lang + Netflix인가?” 싶었는데 거의 비슷한 느낌이었다.
우리가 평소에 보는 영상들을 그냥 재미로 보고 끝내는 게 아니라, 영상 속에서 실제 영어 표현을 배우고
→ 자막으로 다시 확인하고
→ 직접 따라 말해보고
→ 나중에 복습까지 하는 식으로
영어 공부와 연결해주는 방식이다.

보통 영어 공부라고 하면 교재를 펴고 단어를 외우거나 문제를 푸는 모습부터 떠올리게 된다.
물론 그런 공부도 필요하다.
그런데 나는 개인적으로 관심 없는 영어 지문을 억지로 읽는 것보다 내가 원래 보고 싶었던 콘텐츠를 영어 공부에 활용할 수 있다는 점이 꽤 마음에 들었다.

내가 보고 싶은 유튜브 영상이 영어 교재가 된다

내가 가장 먼저 관심이 갔던 기능이다. 랭플릭스에서는 유튜브 콘텐츠를 가지고 영어 공부를 할 수 있다.
이게 왜 좋냐면 굳이 “영어 공부를 위한 영상” 만 봐야 하는 게 아니다.
예를 들어 내가 평소 관심 있는 걸 생각해보면

개발
AI
스타트업
해외 개발자 인터뷰
테크 유튜브
운동
여행
브이로그

이런 영상이 엄청 많다.

나는 개발이나 AI 관련 해외 영상을 꽤 자주 찾아보는데, 지금까지는 대부분 그냥 내용을 이해하는 데 집중해서 봤다.
그러다 보면 “방금 저 표현 괜찮은데?” 싶다가도 그냥 영상이 넘어가 버린다.
결국 내용은 기억나는데 영어 표현은 하나도 안 남는 경우가 많았다.

랭플릭스를 잘 활용하면 앞으로는 개발 공부하면서 영어 공부까지 같이 하는 방식 을 만들어볼 수도 있을 것 같다.
이건 나한테 꽤 큰 장점이다. 어차피 볼 영상이라면 영어 공부까지 같이 하면 효율이 좋으니까.

그냥 영상만 보는 건 아니다

사실 여기까지만 들으면 “그냥 영어 유튜브 자막 켜고 보면 되는 거 아니야?” 라고 생각할 수도 있다.

나도 처음에는 비슷하게 생각했다.
그런데 랭플릭스에서는 단순히 영상을 보여주는 게 아니라 학습 과정을 어느 정도 나눠놓았다.
큰 흐름은 레슨 → 영상 시청 → 연습 이라고 보면 된다.

먼저 영상에 등장하는 주요 단어나 표현을 공부하고,
그다음 실제 영상을 보면서 “아, 아까 공부한 표현이 여기서 이렇게 쓰이는구나.” 를 확인한다.
그리고 거기서 끝나는 게 아니라 직접 영어를 따라 말하거나 문제를 풀면서 다시 연습할 수 있다.
나는 영어 공부할 때 이 부분이 꽤 중요하다고 생각한다.
영어 표현을 보고 “아 이거 알아.” 하는 것과 실제로 대화 중에 그 표현을 내 입으로 바로 꺼내는 것은 완전히 다르기 때문이다.
나도 읽으면 아는 표현인데 막상 말하려고 하면 생각 안 나는 경우가 진짜 많다.
그래서 이번에는 최대한 눈으로만 공부하지 않고 입으로 직접 말하는 시간을 많이 가져보려고 한다.

내가 가장 기대하고 있는 기능, AI 쉐도잉

개인적으로 이번에 제일 많이 써보고 싶은 게 쉐도잉이다.
쉐도잉은 영어 음성을 들으면서 바로 따라 말하는 공부법이다.
원어민이 어디서 끊어서 말하는지, 어디에 강세를 주는지, 어떤 리듬으로 말하는지 그대로 따라 해보는 거다.

나도 예전에 유튜브로 몇 번 해봤는데 생각보다 귀찮다.

영상을 재생했다가, 멈추고, 따라 말하고, 다시 듣고, 또 돌려보고... 몇 번 하다 보면 그냥 영상을 보고 싶어진다ㅋㅋ
랭플릭스에서는 이런 쉐도잉 연습을 서비스 안에서 할 수 있고, 내가 말한 영어에 대해서 AI 피드백도 받을 수 있다.

이건 앞으로 직접 여러 번 사용해보고 별도로 후기를 남겨볼 생각이다.
특히 내 목표 중 하나가 나중에 영어 면접에서 내 프로젝트와 경험을 자연스럽게 설명하는 것이라서 듣기보다 말하기를 많이 연습해보고 싶다.
영어는 결국 머릿속에 얼마나 많이 알고 있느냐보다 필요한 순간에 입 밖으로 얼마나 잘 꺼낼 수 있느냐 가 더 중요한 것 같다.

넷플릭스 볼 때 이중자막도 가능하다

그리고 이름이 랭플릭스인 만큼 넷플릭스와 연결해서 사용할 수도 있다.
PC에서는 크롬 확장 프로그램을 이용해서 넷플릭스를 볼 때 한국어와 영어 자막을 같이 보면서 학습할 수 있다.
이 기능도 꽤 유용해 보였다.

나는 평소 영어 콘텐츠를 볼 때 항상 애매했던 게
영어 자막만 켜면 내용을 제대로 이해하지 못하고, 한국어 자막만 켜면 어느 순간 영어는 하나도 안 듣고 한국어만 읽고 있다는 점이었다.

아마 영어 공부하려고 미드 틀어본 사람이라면 한 번쯤 공감할 것 같다.
이중자막을 활용하면 처음에는 한국어로 내용을 따라가면서 실제 영어 표현도 같이 확인할 수 있다.
그리고 점점 익숙해지면 한국어 자막을 덜 보는 식으로 연습해볼 수도 있을 것 같다.
이것도 앞으로 넷플릭스 작품 하나 정해서 실제로 공부해볼 예정이다.

배운 표현은 다시 복습하기

그리고 개인적으로 영어 공부하면서 정말 많이 느끼는 게 있다. 분명히 공부했는데 며칠 뒤에 보면 처음 보는 것 같다.
진짜 신기하다. 분명히 외웠는데 없다. 내 머릿속에서 삭제돼 있다.
그래서 요즘은 새로운 걸 계속 공부하는 것보다 이미 배운 걸 얼마나 다시 보는지가 더 중요할 수도 있겠다는 생각을 한다.

랭플릭스에서도 영상에서 발견한 표현을 저장해두고 다시 복습할 수 있다.
영상에서 한번 보고, 표현을 공부하고, 직접 말해보고, 나중에 또 복습하는 식이다.
이번 활동 동안 이 기능도 적극적으로 써볼 생각이다. 실제로 내가 처음보다 알고 있는 표현이 얼마나 늘었는지도 한번 확인해보고 싶다.

일단 직접 써보겠습니다

아직 첫 번째 글이라서 오늘은 랭플릭스가 어떤 서비스인지 전체적으로만 살펴봤다.
지금까지 사용해본 느낌으로 한 문장으로 표현하면 “내가 원래 보던 영상들을 영어 공부 콘텐츠로 바꿔주는 서비스” 라는 표현이 가장 잘 맞는 것 같다.
물론 앱 하나 쓴다고 갑자기 영어를 잘하게 될 리는 없다.
결국 내가 실제로 얼마나 꾸준히 듣고, 따라 말하고, 복습하고, 다시 사용하는지가 중요할 거다.

경제금융용어 공부 587 : 타행환공동망

MKISOS — Mon, 10 Aug 2026 21:00:33 +0900

타행환공동망

오늘날에는 은행이 달라도 몇 초 안에 계좌이체가 가능하다. 하지만 과거에는 송금인과 수취인의 거래은행이 다르면 자금이체가 불편하고 처리 시간도 오래 걸릴 수 있었다. 타행환공동망은 서로 다른 은행의 전산망을 연결해 전국 어디서나 빠르게 송금할 수 있도록 만든 금융 인프라이다.

1. 한 줄 정의

타행환공동망은 서로 다른 금융기관 사이에서도 송금과 조회 업무를 처리할 수 있도록 은행 전산망을 연결한 시스템이다.

2. 기본 개념

타행환공동망은 금융결제원과 여러 금융기관의 전산시스템을 서로 연결한 금융공동망이다.

송금인과 수취인이 같은 은행을 이용하지 않더라도 전국의 금융기관 점포에서 송금 업무를 처리할 수 있도록 만든 시스템이다.

우리나라에서는 1989년 12월부터 가동되었다.

타행환공동망이 도입되기 전에는 다른 은행으로 돈을 보내는 과정이 지금보다 복잡하고 시간이 오래 걸릴 수 있었다. 그러나 금융기관의 전산망이 연결되면서 다른 은행 계좌로도 신속하게 자금을 이체할 수 있게 되었다.

타행환공동망을 통해 처리할 수 있는 대표적인 업무는 다음과 같다.

다른 은행 계좌로 송금
자기앞수표 조회
송금 수취 여부 조회
다양한 예금계좌로 자금이체

3. 왜 중요한가

경제활동에서는 서로 다른 은행을 사용하는 사람과 기업 사이에서도 자금이 원활하게 이동해야 한다.

만약 같은 은행끼리만 송금할 수 있다면 개인과 기업은 여러 은행에 계좌를 만들어야 하고 금융거래 비용도 크게 증가할 것이다.

타행환공동망은 은행 간 장벽을 낮추고 자금이체를 빠르게 만들어 금융서비스의 편의성을 크게 높였다.

또한 전국 어느 지역에서나 금융기관을 이용할 수 있도록 해 금융서비스의 장소적 제약을 줄였다.

4. 쉽게 이해하는 예시

실생활 예시

A는 국민은행 계좌를 사용하고 B는 신한은행 계좌를 사용한다고 가정해보자.

A가 B에게 10만 원을 송금하면 서로 다른 은행을 이용하지만 돈은 빠르게 이동한다.

이 과정에서 은행의 전산망을 연결해주는 기반이 타행환공동망이다.

대학생 예시

대학생이 아르바이트비를 우리은행 계좌로 받고, 생활비는 카카오뱅크 계좌로 옮긴다고 가정해보자.

은행이 달라도 즉시 이체할 수 있는 이유는 금융기관 사이에 공동망이 구축되어 있기 때문이다.

기업 예시

기업이 여러 거래처에 대금을 지급할 때 거래처마다 사용하는 은행이 다를 수 있다.

타행환공동망을 이용하면 하나의 거래은행을 통해 다양한 은행의 거래처 계좌로 송금할 수 있다.

5. 핵심 특징

5-1. 서로 다른 은행을 연결한다

타행환공동망은 금융결제원을 중심으로 여러 금융기관의 전산시스템을 연결한다.

이를 통해 은행이 달라도 송금과 조회 업무를 처리할 수 있다.

5-2. 즉시 자금이체를 가능하게 했다

타행환공동망이 가동되면서 다른 금융기관으로 보내는 송금도 빠르게 처리할 수 있게 되었다.

지급결제 업무의 속도와 편의성이 크게 향상되었다.

5-3. 금융서비스의 지역적 제약을 줄였다

과거에는 특정 은행의 점포가 없는 지역에서 금융서비스를 이용하기 어려울 수 있었다.

공동망 구축 이후에는 전국의 금융기관을 통해 다양한 송금 업무를 처리할 수 있게 되었다.

5-4. 여러 종류의 계좌를 지원한다

보통예금과 저축예금뿐 아니라 당좌예금, 기업자유예금, 적금, 신탁, 투자자예탁금 등 다양한 계좌가 이용 대상에 포함될 수 있다.

6. 관련 개념과의 차이

타행환공동망 vs 같은 은행 계좌이체

타행환공동망

서로 다른 금융기관 사이의 이체를 처리함
금융결제원이 중계 역할을 수행함
은행 간 자금이체에 해당함

같은 은행 계좌이체

동일한 금융기관 내부에서 처리됨
해당 은행의 자체 전산망을 이용함
은행 간 중계가 필요하지 않음

즉 같은 은행 이체는 은행 내부 거래이고, 타행환공동망은 서로 다른 은행을 연결하는 거래이다.

타행환공동망 vs 전자금융공동망

타행환공동망

금융기관 점포 등을 통한 타행 송금 업무에서 시작됨
송금과 자기앞수표 조회 등을 처리함

전자금융공동망

인터넷뱅킹, 모바일뱅킹, 텔레뱅킹 등 전자적 채널을 통한 금융거래를 지원함
비대면 금융거래에 초점이 있음

두 시스템 모두 은행 간 거래를 지원하지만 이용 채널과 발전 배경에 차이가 있다.

타행환공동망 vs 소액결제시스템

타행환공동망

타행 송금과 조회 업무를 처리하는 구체적인 금융공동망임

소액결제시스템

개인과 기업의 소액·대량 지급거래를 처리하는 전체 시스템을 의미함
타행환공동망, 지로, 카드결제망 등이 포함될 수 있음

타행환공동망은 소액결제시스템을 구성하는 하나의 세부 시스템이라고 볼 수 있다.

7. 경제적 의미

국가경제 관점

타행환공동망은 금융기관 사이의 자금이동을 원활하게 하여 경제활동의 효율성을 높인다.

개인과 기업이 거래은행에 관계없이 송금할 수 있어 전국적인 지급결제 인프라가 구축된다.

기업 관점

기업은 여러 은행을 사용하는 거래처에도 신속하게 대금을 지급할 수 있다.

이를 통해 자금관리 업무가 간소화되고 거래비용도 줄어든다.

금융시장 관점

타행환공동망은 금융기관의 전산망을 연결해 소액결제시스템의 효율성과 안정성을 높인다.

은행 간 거래가 원활해지면서 금융서비스 경쟁과 접근성도 개선된다.

투자 관점

개인투자자가 타행환공동망을 직접 분석할 일은 많지 않지만, 증권계좌와 은행계좌 사이의 자금이체가 원활하게 이루어지는 기반이 된다.

금융기관과 핀테크 기업의 서비스를 평가할 때 이러한 지급결제 인프라의 안정성과 연결성이 중요하다.

8. 정리

타행환공동망은 금융결제원과 금융기관의 전산시스템을 연결하여 서로 다른 은행 사이에서도 송금과 조회 업무를 처리할 수 있도록 만든 시스템이다. 1989년 가동 이후 타행 송금이 빠르고 편리해졌으며 금융서비스의 지역적 제약도 크게 줄어들었다. 타행환공동망은 개인과 기업의 일상적인 계좌이체를 뒷받침하고 소액결제시스템의 효율성을 높이는 핵심 금융 인프라이다.

LG Aimers 9기 프로젝트 : 모델 개발부터 코드 제출까지 전체 과정 정리

MKISOS — Mon, 10 Aug 2026 10:14:35 +0900

지난 글에서는 LG Aimers 9기 프로젝트의 문제와 데이터, 앞으로 공부해야 할 내용을 전체적으로 정리했다.

이번 글에서는 실제로 모델을 개발하고 제출하기 위해 어떤 파일을 만들어야 하는지, 로컬에서 학습한 모델이 평가 서버에서 어떻게 실행되는지 정리해보려고 한다.

이번 대회는 예측 결과 CSV를 직접 제출하는 일반적인 대회와 다르다.

모델 파일과 추론 코드를 ZIP으로 압축해서 제출하면, 데이콘 평가 서버가 비공개 테스트 데이터로 직접 코드를 실행한다.

그래서 모델 성능뿐 아니라 다음 요소도 중요하다.

학습 환경과 평가 환경의 라이브러리 버전
학습과 추론에서 동일한 전처리를 사용하는지
제출 ZIP의 디렉터리 구조
평가 서버에서의 실행 시간
외부 인터넷 없이 실행 가능한지
결과 파일이 정해진 경로에 생성되는지

이번 글에서는 이 과정을 처음부터 하나씩 정리한다.

1. 이번 대회는 무엇을 제출하는가

보통 데이터 경진대회에서는 테스트 데이터로 예측한 submission.csv를 직접 제출한다.

하지만 이번 대회는 코드 제출 방식이다.

참가자는 다음 세 가지를 ZIP 파일에 넣어 제출한다.

학습이 끝난 모델 파일
모델을 실행하는 script.py
필요한 패키지를 적은 requirements.txt

제출 후 평가 서버에서는 비공개 테스트 데이터를 추가하고 script.py를 실행한다.

전체 과정은 다음과 같다.

로컬 환경에서 모델 학습
→ 학습된 모델 저장
→ 모델과 추론 코드 압축
→ 데이콘에 ZIP 제출
→ 평가 서버가 비공개 테스트 데이터로 추론
→ output/submission.csv 생성
→ Brier Skill Score 계산

여기서 중요한 점은 학습 코드를 평가 서버에서 실행하는 것이 아니라는 것이다.

모델 학습은 로컬에서 미리 끝내고, 제출 ZIP에는 학습 결과인 모델 파일과 추론에 필요한 코드만 포함한다.

2. 학습 파일과 추론 파일은 왜 분리하는가

프로젝트를 시작할 때는 학습 코드와 추론 코드를 따로 만드는 것이 좋다.

학습 파일은 다음 작업을 담당한다.

train.csv 읽기
피처 생성
결측값과 범주형 변수 처리
학습 데이터와 검증 데이터 분리
모델 학습
Brier Score 계산
최종 모델 저장

추론 파일은 다음 작업만 담당한다.

평가 서버의 test.csv 읽기
저장된 모델 불러오기
학습할 때와 동일한 피처 생성
control_success 확률 예측
output/submission.csv 저장

따라서 로컬 프로젝트에는 다음과 같이 두 종류의 파일이 존재하게 된다.

학습용 파일

train_v1.py

제출용 파일

script.py

train_v1.py는 모델을 만들기 위한 개발 파일이므로 제출 ZIP에 넣지 않는다.

script.py는 평가 서버가 자동으로 실행하는 파일이므로 제출 ZIP에 반드시 포함해야 한다.

3. 베이스라인은 그대로 보존한다

처음 모델을 수정할 때 베이스라인 파일을 바로 덮어쓰는 것은 좋지 않다.

코드를 여러 번 수정하다 보면 어떤 변경 때문에 성능이 달라졌는지 확인하기 어려워지고, 오류가 생겼을 때 정상적으로 작동했던 상태로 돌아가기 힘들어진다.

그래서 베이스라인은 그대로 보관하고 실험 버전을 새로 만드는 방식으로 진행한다.

예를 들면 다음과 같다.

open/
├── data/
├── baseline_submit/
├── experiments/
│   ├── train_v1.py
│   ├── train_v2.py
│   └── experiment_results.csv
└── submissions/
    ├── v1/
    └── v2/

experiments에는 학습과 검증 코드를 저장한다.

submissions에는 실제 제출할 파일만 버전별로 저장한다.

실험 결과도 함께 기록해두는 것이 좋다.

실험 버전
사용한 피처
모델과 주요 파라미터
학습 기간
검증 기간
Brier Score
Brier Skill Score
학습 시간
추론 시간
모델 파일 크기
실제 리더보드 점수

한 번에 여러 가지를 수정하기보다 한 가지씩 바꾸면서 결과를 기록해야 어떤 변경이 효과가 있었는지 확인할 수 있다.

4. 로컬에서는 어떻게 모델을 검증하는가

학습 데이터는 2019년부터 2024년까지의 투구 기록으로 구성되어 있다.

실제 평가 대상은 이후 시점의 비공개 데이터이므로 학습과 검증 데이터를 무작위로 섞는 것보다 시간 순서를 고려하는 것이 중요하다.

현재 베이스라인은 다음과 같이 검증한다.

2019~2023년 데이터로 학습
2024년 데이터로 검증
검증이 끝나면 2019~2024년 전체 데이터로 최종 학습

이렇게 하면 과거 시즌을 이용해 새로운 시즌을 예측하는 실제 평가 상황과 비슷한 조건을 만들 수 있다.

현재 데이터의 시즌별 제구 성공률도 일정하지 않다.

2019년: 약 56.5%
2020년: 약 53.3%
2021년: 약 53.3%
2022년: 약 52.9%
2023년: 약 50.0%
2024년: 약 48.6%

시즌이 지날수록 평균 제구 성공률이 변하고 있기 때문에 랜덤 분할 점수만 믿으면 실제 비공개 데이터에서 성능이 크게 달라질 수 있다.

조금 더 안정적으로 검증하려면 다음 두 가지 분할을 함께 확인할 수 있다.

2019~2022년 학습, 2023년 검증
2019~2023년 학습, 2024년 검증

두 검증 기간에서 모두 좋아지는 변경을 우선적으로 선택하는 것이 안전하다.

5. 이번 대회에서는 확률이 중요하다

이번 프로젝트의 평가 지표는 Brier Skill Score다.

모델이 출력한 제구 성공 확률과 실제 정답의 차이를 이용해서 점수를 계산한다.

예를 들어 실제 제구에 성공한 투구가 있다고 가정해보자.

모델 A의 예측 확률: 0.9
모델 B의 예측 확률: 0.6

두 모델 모두 최종 분류는 성공으로 볼 수 있지만, 실제 정답에 더 가까운 확률을 출력한 모델 A의 Brier Score가 더 좋다.

반대로 모델이 틀린 결과를 지나치게 확신하면 손실이 크게 증가한다.

따라서 이번 프로젝트에서는 다음을 함께 확인해야 한다.

분류 성능
Brier Score
평균 예측 확률
실제 성공률
예측 확률 분포
Calibration Curve
과도하게 0이나 1에 가까운 예측이 많은지

모델이 복잡하다고 항상 좋은 것은 아니다.

새로운 시즌에서도 안정적으로 작동하고, 예측 확률을 신뢰할 수 있는 모델이 좋은 모델이다.

6. 첫 번째로 어떤 코드를 수정할 것인가

현재 베이스라인은 Random Forest를 사용한다.

top_bottom, game_type, base_state는 범주형 변수로 처리하지만, 투수와 타자 ID 등은 숫자형 데이터처럼 들어갈 수 있다.

하지만 선수 ID의 숫자 크기에는 특별한 순서나 의미가 없다.

예를 들어 투수 ID 100이 투수 ID 10보다 열 배 좋은 선수를 의미하지 않는다.

따라서 첫 번째 실험에서는 다음 변수를 범주형으로 처리하는 방법을 비교할 예정이다.

pitcher_id
batter_id
pitcher_team_id
batter_team_id
pitcher_hand
batter_hand

그다음에는 경기 상황을 조합한 피처를 추가할 수 있다.

볼과 스트라이크를 합친 카운트 상태
투수와 타자의 좌우 조합
투수와 타자의 과거 성공률 차이
주자 수와 아웃 카운트 조합
점수 차와 경기 중요도 조합
최근 1경기와 5경기 성공률 차이
과거 표본 수에 따른 성공률 신뢰도

첫 실험부터 모든 변경을 적용하지는 않는다.

범주형 처리, 조합 피처, 모델 변경, 확률 보정을 각각 분리해서 비교해야 점수 상승의 원인을 알 수 있다.

7. 평가 서버 환경

실제 제출 코드는 다음 환경에서 실행된다.

OS: Ubuntu 22.04.5 LTS
Python: 3.11.15
CPU: 6 vCPU
RAM: 28GB
GPU: NVIDIA L4
GPU 메모리: 22.4GiB
CUDA: 12.8
실제 테스트 데이터: 245,789개
패키지 설치 제한: 10분
추론 실행 제한: 10분
ZIP 파일 크기: 최대 10GB
압축 해제 후 크기: 최대 32GB
추론 중 외부 인터넷 사용 불가

주요 기본 패키지는 다음과 같다.

pandas==2.0.3
numpy==1.26.4
scipy==1.15.3
scikit-learn==1.8.0
joblib==1.5.3
torch==2.7.1+cu128

현재 프로젝트의 기존 로컬 가상환경은 다음 버전을 사용하고 있었다.

Python 3.12.10
pandas 3.0.5
numpy 2.5.1
scikit-learn 1.9.0
joblib 1.5.3

평가 서버와 로컬 환경의 버전이 다르다는 것을 확인할 수 있다.

특히 scikit-learn 모델을 joblib으로 저장하면 학습 환경과 추론 환경의 버전 차이로 모델 로드 오류가 발생할 수 있다.

따라서 새로운 모델은 가능하면 평가 서버와 동일한 환경에서 학습해야 한다.

Python 3.11
pandas 2.0.3
numpy 1.26.4
scikit-learn 1.8.0
joblib 1.5.3

모델 성능이 아무리 좋아도 평가 서버에서 모델을 불러오지 못하면 점수를 받을 수 없다.

코드 제출 대회에서는 모델 성능과 실행 환경의 재현성을 함께 관리해야 한다.

8. requirements.txt는 어떻게 관리하는가

평가 서버에는 주요 머신러닝 패키지가 이미 설치되어 있다.

서버에 설치된 패키지를 다른 버전으로 다시 설치하면 설치 시간이 증가하거나 의존성 충돌이 발생할 수 있다.

따라서 requirements.txt에는 추론에 실제로 필요한 추가 패키지만 포함하는 것이 좋다.

확인해야 할 내용은 다음과 같다.

Python 3.11에서 설치 가능한가
Ubuntu 환경에서 설치 가능한가
설치 시간이 10분을 넘지 않는가
추론 이후 별도 모델 다운로드가 필요하지 않은가
학습에만 필요하고 추론에는 필요 없는 패키지가 포함되지 않았는가
평가 서버의 기본 패키지와 충돌하지 않는가

현재 베이스라인 requirements.txt에는 평가 서버 기본 버전과 다른 pandas 버전이 적혀 있다.

특별히 새로운 버전이 필요한 기능을 사용하지 않는다면 평가 서버 기본 버전을 활용하는 방향이 더 안전하다.

9. 제출 ZIP은 어떻게 만드는가

제출 파일의 내부 구조는 반드시 다음과 같아야 한다.

submit.zip
├── model/
│   └── model.pkl
├── script.py
└── requirements.txt

ZIP 파일을 열었을 때 가장 바깥에 model, script.py, requirements.txt가 바로 보여야 한다.

다음과 같이 프로젝트 폴더 전체가 한 번 더 들어가면 안 된다.

submit.zip
└── submissions/
    └── v1/
        ├── model/
        ├── script.py
        └── requirements.txt

제출 폴더 안으로 이동한 뒤 필요한 파일만 압축하는 방식이 가장 안전하다.

cd submissions/v1

zip -r ../../submit_v1.zip \
  model \
  script.py \
  requirements.txt \
  -x "*.DS_Store" "__MACOSX/*"

macOS에서는 .DS_Store나 __MACOSX 같은 파일이 함께 들어갈 수 있기 때문에 압축 대상에서 제외한다.

압축 후에는 반드시 내부 구조를 확인한다.

unzip -l submit_v1.zip

10. script.py는 무엇을 해야 하는가

평가 서버는 제출 ZIP에 실제 평가 데이터를 추가한 뒤 script.py를 실행한다.

추론 코드는 다음 순서로 동작해야 한다.

./data/test.csv를 읽는다.
./data/sample_submission.csv를 읽는다.
./model/model.pkl을 불러온다.
학습 때와 동일한 전처리를 적용한다.
control_success = 1일 확률을 예측한다.
row_id 순서에 맞게 결과를 정리한다.
./output/submission.csv로 저장한다.

여기서 중요한 것은 학습 코드와 추론 코드의 피처 생성 방식이 같아야 한다는 것이다.

학습할 때 조합 피처를 만들었는데 script.py에서 해당 피처를 만들지 않으면 모델 입력 컬럼이 달라져 오류가 발생한다.

반대로 추론 코드에서만 새로운 피처를 추가해도 모델이 학습할 때 본 적 없는 컬럼이기 때문에 정상적으로 예측할 수 없다.

가능하면 피처 생성 함수를 하나로 관리하고 학습 코드와 추론 코드가 동일한 로직을 사용하도록 만들어야 한다.

11. 테스트 데이터에서 하면 안 되는 것

평가 서버에서는 전체 비공개 test.csv를 읽을 수 있다.

하지만 테스트 데이터의 다른 행을 이용해 현재 행의 피처를 만들면 안 된다.

금지되는 방식은 다음과 같다.

테스트 데이터 전체의 평균이나 분포 사용
테스트 데이터에서 선수별 투구 수 집계
테스트 데이터에서 팀별 빈도 계산
테스트 데이터 내부 Target Encoding
테스트 행 순서를 이용한 Rolling Feature
평가 데이터 전체를 본 뒤 확률을 보정하는 방식
현재 투구 이후에 알 수 있는 정보 사용
2025년 Trackman 정보 사용

운영진이 제공한 asof_ 피처는 현재 투구 직전까지의 과거 기록으로 만들어졌기 때문에 사용할 수 있다.

새로운 피처를 만들 때는 항상 다음 질문을 먼저 해야 한다.

“이 정보는 해당 투구가 시작되기 전에 실제로 알 수 있었는가?”

이 질문에 확실하게 답하기 어렵다면 사용하지 않는 것이 안전하다.

12. 제출 전에 확인해야 할 것

제출 전에는 로컬의 샘플 테스트 데이터로 script.py를 처음부터 끝까지 실행해야 한다.

확인할 내용은 다음과 같다.

script.py가 오류 없이 실행되는가
모델 파일을 정상적으로 불러오는가
학습과 추론의 입력 컬럼이 같은가
테스트 데이터와 제출 파일의 행 개수가 같은가
row_id 순서가 같은가
control_success에 결측값이 없는가
모든 예측값이 0부터 1 사이인가
결과가 output/submission.csv에 생성되는가
외부 인터넷에 접속하는 코드가 없는가
추론 과정에서 모델을 다시 학습하지 않는가
전체 추론 시간이 10분을 넘지 않는가
제출 ZIP의 최상위 구조가 정확한가
ZIP에 학습 데이터와 불필요한 파일이 들어 있지 않은가

설치 오류는 일일 제출 횟수에 포함되지 않지만, script.py 실행 이후 발생하는 제출 오류는 제출 횟수에 반영될 수 있다.

따라서 ZIP 파일을 만들었다고 바로 제출하지 않고, 압축을 풀어 새로운 환경에서 실행해보는 과정이 필요하다.

13. 팀원들과 무엇을 공유할 것인가

팀 프로젝트에서는 최종 점수만 공유하면 어떤 실험이 효과가 있었는지 알기 어렵다.

각 실험마다 다음 내용을 기록할 예정이다.

실험 이름과 버전
작성자
사용한 학습 데이터
검증 데이터 기간
추가하거나 제거한 피처
모델 종류와 파라미터
확률 보정 방식
로컬 Brier Score
로컬 Brier Skill Score
학습 시간
추론 시간
모델 파일 크기
리더보드 점수
사용한 라이브러리 버전
규정과 데이터 누수 확인 결과

실험은 다음 순서로 진행할 수 있다.

베이스라인 재현
→ 범주형 변수 처리 개선
→ 상황 조합 피처 추가
→ 모델 파라미터 변경
→ 다른 모델 비교
→ 확률 보정
→ 모델 앙상블

한 번에 하나씩 변경하고 결과를 남겨야 팀원도 같은 실험을 재현할 수 있다.

14. 현재 정리된 다음 작업

현재 가장 먼저 해야 할 일은 베이스라인 점수를 정확하게 재현하는 것이다.

그다음 다음 순서로 진행할 예정이다.

기존 베이스라인을 수정하지 않고 보존한다.
평가 서버와 동일한 Python 3.11 환경을 만든다.
베이스라인 학습 코드를 train_v1.py로 분리한다.
2019~2023년 학습, 2024년 검증 점수를 기록한다.
투수·타자·팀 ID의 범주형 처리를 첫 번째 실험으로 진행한다.
조합 피처와 확률 보정을 각각 별도 실험으로 비교한다.
성능이 개선된 모델을 전체 데이터로 다시 학습한다.
모델과 script.py를 제출 구조에 맞게 정리한다.
로컬 샘플 데이터로 추론을 테스트한다.
ZIP 내부 구조를 확인하고 제출한다.

마무리

처음에는 베이스라인 코드를 조금 수정하고 ZIP으로 압축하면 끝나는 과정이라고 생각했다.

하지만 실제로는 모델 학습, 시간 기준 검증, 확률 보정, 라이브러리 호환성, 추론 속도, 제출 파일 구조까지 모두 연결되어 있었다.

이번 대회에서 좋은 결과를 만들기 위해서는 점수가 높은 모델만 필요한 것이 아니다.

다른 환경에서도 같은 결과를 만들 수 있어야 하고, 사용한 데이터와 피처가 규정을 지켜야 하며, 비공개 테스트 데이터에서도 제한 시간 안에 안정적으로 실행되어야 한다.

앞으로는 모델을 수정할 때마다 다음 질문을 함께 확인하려고 한다.

이 변경은 2024년 검증 데이터에서 실제로 성능을 높였는가?
새로운 시즌에서도 사용할 수 있는 정보인가?
데이터 누수 없이 만든 피처인가?
평가 서버와 같은 환경에서 실행할 수 있는가?
팀원이 같은 결과를 다시 재현할 수 있는가?

이 질문에 답할 수 있는 실험을 하나씩 쌓아가는 것이 이번 프로젝트의 다음 목표다.

참고:

LG Aimers 9기 프로젝트 : 데이터로 야구를 이해하고 예측하는 방법

MKISOS — Mon, 10 Aug 2026 09:45:38 +0900

1. 이번 프로젝트는 어떤 프로젝트인가

이번 프로젝트의 목표는 야구 경기에서 투수가 공을 던지기 직전의 상황을 보고, 해당 투구가 제구에 성공할 확률을 예측하는 것이다.

한 행은 하나의 투구를 의미한다. 모델은 다음과 같은 정보를 입력으로 받는다.

현재 이닝과 경기 유형
볼·스트라이크·아웃 카운트
양 팀의 점수와 점수 차이
주자 상황
홈팀의 기대 승률과 상황 중요도
투수와 타자의 정보
투수가 과거에 보여준 제구 성공률과 투구 특성
타자가 과거에 경험한 제구 패턴
투수의 구종 사용 비율

그리고 최종적으로 해당 투구가 제구에 성공할 확률을 0부터 1 사이의 값으로 출력한다.

이 프로젝트는 단순히 “공이 스트라이크였는가”를 맞히는 문제가 아니다. 투구 직전의 경기 상황, 투수와 타자의 과거 기록, 최근 컨디션, 투구 선택 경향을 종합해서 불확실한 결과를 확률로 예측해야 한다는 점이 핵심이다.

즉, 이번 프로젝트는 야구 도메인 지식과 데이터 분석, 피처 엔지니어링, 확률 예측, 모델 검증, 제출 시스템 구현을 함께 경험하는 프로젝트라고 볼 수 있다.

2. 데이터는 어떻게 구성되어 있는가

학습 데이터는 2019년부터 2024년까지의 투구 기록으로 구성되어 있다. 약 147만 개의 투구 데이터가 있으며, 각 투구에는 제구 성공 여부를 나타내는 control_success 정답이 포함되어 있다.

평가 데이터는 2025년 투구 데이터다. 실제 평가용 테스트 데이터는 공개되지 않고, 제출 서버에서 모델을 실행할 때 제공된다.

또 하나 중요한 데이터가 trackman_history.csv다. 이 파일에는 2019년부터 2024년까지의 Trackman 투구 로그 약 179만 건이 들어 있다. 여기에는 다음과 같은 상세 투구 정보가 포함되어 있다.

구종
구속
회전수
수직·수평 무브먼트
릴리스 위치
투구 확장 거리
타석 내 투구 순서

현재 제공된 베이스라인에서는 이 Trackman 데이터를 사용하지 않는다. 따라서 이 데이터는 이후 성능을 높일 수 있는 핵심 재료가 될 수 있다.

다만 Trackman 데이터는 학습·평가 데이터와 row_id 기준으로 일대일 매칭되는 테이블이 아니다. 직접 결합하는 것이 아니라, 과거 시즌의 투구 특성을 선수별·구종별·팀별로 집계해서 새로운 피처를 만들어야 한다.

3. 현재 베이스라인은 어디까지 구현되어 있는가

현재 베이스라인은 RandomForest 모델을 사용한다.

전처리 방식은 다음과 같다.

top_bottom, game_type, base_state 같은 범주형 변수는 정수 형태로 인코딩
수치형 결측값은 중앙값으로 대체
row_id는 식별자이므로 모델 입력에서 제외
나머지 47개 입력 피처를 모델에 사용

검증은 시간 순서를 고려해서 진행한다.

2019~2023년 데이터로 학습
2024년 데이터를 검증
검증 후에는 전체 학습 데이터로 다시 학습
최종 모델을 저장해 평가 서버에서 실행

모델의 평가지표는 Brier Skill Score다. 이 지표는 단순히 정답과 오답을 세는 것이 아니라, 모델이 출력한 확률이 실제 결과와 얼마나 가까운지를 평가한다.

예를 들어 제구 성공 가능성이 80%인 투구를 실제로 성공했다고 예측했다면 좋은 예측이다. 반대로 성공 확률을 99%라고 예측했는데 실패했다면 큰 오차로 평가된다.

따라서 이번 프로젝트에서는 높은 정확도뿐 아니라, 신뢰할 수 있는 확률을 출력하는 것이 중요하다.

4. 이 프로젝트에서 가장 중요하게 공부해야 할 것

첫 번째는 문제 정의와 데이터 이해다

모델을 바로 학습시키기보다 먼저 “투구 직전 시점에 어떤 정보가 존재하는가”를 이해해야 한다.

현재 투구가 끝난 뒤 알 수 있는 정보를 모델에 넣으면 미래 정보를 미리 사용하는 데이터 누수가 발생한다. 예를 들어 다음 정보는 사용할 수 없다.

현재 투구의 실제 구종
실제 투구 위치
현재 투구의 판정 결과
현재 투구의 Trackman 측정값
평가 데이터의 다른 행을 활용한 통계

이번 프로젝트에서 가장 먼저 배워야 할 것은 단순한 모델 사용법보다 “현실적인 예측 시점에서 정말 사용할 수 있는 정보인가”를 판단하는 능력이다.

두 번째는 시간 순서를 고려한 검증이다

일반적인 랜덤 분할은 과거와 미래 데이터를 섞을 수 있다. 하지만 실제 목표는 과거 데이터로 미래 시즌을 예측하는 것이다.

따라서 2019~2023년으로 학습하고 2024년으로 검증한 현재 방식은 현실적인 평가에 가깝다. 이후에도 다음과 같은 검증을 시도해볼 수 있다.

2022년까지 학습하고 2023년 검증
2023년까지 학습하고 2024년 검증
시즌별 성능 비교
선수별·팀별·상황별 성능 비교

이 과정을 통해 모델이 단순히 학습 데이터를 외운 것인지, 실제로 새로운 시즌에도 일반화되는지 확인할 수 있다.

세 번째는 피처 엔지니어링이다

현재 데이터에는 이미 asof_로 시작하는 과거 이력 피처가 제공된다. 하지만 이것만 사용하는 것이 최종 목표는 아니다.

Trackman 과거 로그를 활용하면 다음과 같은 피처를 만들 수 있다.

투수의 과거 구종 사용 비율
구종별 평균 구속
구종별 평균 회전수
투수의 릴리스 위치
최근 시즌의 투구 특성 변화
타자 유형별 투수 성적
좌·우 투수와 타자의 상대 성과
특정 카운트에서의 구종 선택 경향
투구 순서에 따른 제구 성공률
경기 초반과 후반의 차이
주자 상황이 중요한 순간의 제구 성능

특히 중요한 것은 단순한 평균을 계산하는 것이 아니라, 현재 투구 시점 이전에 알 수 있는 정보만 사용해 피처를 만드는 것이다.

네 번째는 확률 예측과 모델 평가다

이번 프로젝트는 0과 1을 맞히는 분류 문제처럼 보이지만, 실제로는 확률 예측 문제에 더 가깝다.

따라서 다음 내용을 공부할 필요가 있다.

Brier Score
Brier Skill Score
확률 보정
calibration curve
Log Loss
예측 확률의 분포
과도하게 확신하는 모델의 문제

예측 확률이 실제 발생 비율과 잘 맞는 모델이 좋은 모델이다. 예를 들어 성공 확률이 70%라고 예측한 투구 100개 중 실제로 약 70개가 성공한다면 모델의 확률 해석력이 좋다고 볼 수 있다.

5. 앞으로 진행할 수 있는 작업

앞으로의 작업은 크게 네 단계로 나눌 수 있다.

1단계: 베이스라인 재현과 평가 구조 이해

먼저 현재 RandomForest 베이스라인을 직접 실행하고, 학습부터 추론, 제출 파일 생성까지의 전체 흐름을 이해한다.

이 단계에서는 다음을 확인한다.

데이터가 어떤 구조로 읽히는가
어떤 컬럼이 모델에 들어가는가
결측값은 얼마나 존재하는가
범주형 변수는 어떻게 처리되는가
검증 점수는 어떻게 계산되는가
제출 코드는 평가 서버에서 어떻게 실행되는가

2단계: 데이터 탐색과 오류 확인

그다음에는 데이터를 다양한 관점에서 분석한다.

시즌별 제구 성공률
투수별 투구 수와 성공률
타자별 상대 기록
카운트별 성공률
이닝별 성공률
주자 상황별 성공률
좌·우 조합별 성능
결측값이 많은 선수와 상황
cold-start 선수의 처리 방식

이 단계의 목표는 모델 성능을 바로 높이는 것이 아니라, 데이터 안에 어떤 패턴과 한계가 있는지 이해하는 것이다.

3단계: Trackman 기반 피처 확장

이 프로젝트의 가장 큰 개선 기회는 Trackman 로그 활용이다.

과거 로그에서 투수별·시즌별·구종별 특징을 만들고, 이를 메인 데이터에 누수 없이 연결한다.

예를 들면 다음과 같은 질문을 검증할 수 있다.

구속이 일정한 투수가 제구에도 강한가
특정 투수는 특정 구종을 많이 던질 때 제구력이 변하는가
최근 구속이나 회전수가 평소와 다를 때 제구 성공률이 떨어지는가
특정 타자 유형을 상대로 투수의 제구 성공률이 달라지는가
경기 상황이 중요할수록 제구 패턴이 달라지는가

4단계: 여러 모델과 확률 보정 비교

RandomForest 외에도 다음 모델을 비교할 수 있다.

Logistic Regression
XGBoost
LightGBM
CatBoost
HistGradientBoosting
앙상블 모델

모델의 복잡도가 높다고 항상 좋은 것은 아니다. 중요한 것은 시간 기준 검증에서 안정적인 성능을 내고, 확률이 잘 보정되는지 확인하는 것이다.

6. 반드시 고민해야 할 문제

이번 프로젝트에서 가장 중요한 고민은 “더 많은 데이터를 넣는 것”이 아니다. 어떤 정보가 예측 시점에 실제로 이용 가능한지, 그리고 그 정보가 모델에 어떤 의미를 갖는지를 판단하는 것이다.

특히 다음 문제를 계속 확인해야 한다.

과거 데이터를 현재 투구에 안전하게 연결했는가
현재 투구 이후의 정보가 섞이지 않았는가
평가 데이터의 다른 행을 이용하지 않았는가
표본 수가 적은 선수의 통계를 어떻게 처리할 것인가
처음 등장한 선수나 새로운 조합을 어떻게 예측할 것인가
선수별 평균값이 실제 실력인지 단순한 표본 편향인지
특정 시즌이나 팀에만 맞춰진 모델은 아닌가
높은 성능이 실제로 재현 가능한가
예측 확률이 지나치게 극단적이지 않은가

이런 고민을 통해 단순히 점수가 높은 모델이 아니라, 왜 그렇게 예측했는지 설명할 수 있는 모델에 가까워질 수 있다.

7. 이 프로젝트에서 기대할 수 있는 결과

최종 결과는 단순한 제출 파일 하나가 아니다.

이번 프로젝트를 통해 다음과 같은 결과물을 만들 수 있다.

투구 단위 제구 성공 확률을 예측하는 머신러닝 모델
과거 Trackman 로그를 활용한 피처 엔지니어링 과정
시간 순서를 고려한 검증 체계
Brier Skill Score 기반 확률 예측 평가
데이터 누수를 방지하는 설계 원칙
평가 서버에서 재현 가능한 추론 코드
실험 결과와 모델 선택 근거가 정리된 프로젝트 기록

결국 좋은 결과는 “점수가 몇 점 올랐다”에서 끝나지 않는다. 어떤 가설을 세웠고, 어떤 데이터를 사용했으며, 어떤 실험을 했고, 그 결과 무엇을 배웠는지를 설명할 수 있어야 한다.

8. 내가 이 프로젝트를 통해 배우게 될 것

이 프로젝트를 통해 가장 먼저 성장할 역량은 데이터를 보는 관점이다.

처음에는 “어떤 모델을 쓰면 점수가 높아질까?”라는 생각에서 시작하겠지만, 프로젝트가 진행될수록 다음과 같은 질문을 하게 될 것이다.

이 데이터는 어떤 과정을 통해 만들어졌을까?
이 변수는 예측 시점에 알 수 있는 정보일까?
이 피처는 실제 선수의 능력을 나타내는가?
검증 점수가 실제 성능을 의미하는가?
이 모델의 확률을 믿어도 되는가?
성능 향상이 우연이 아닌가?

이 과정을 통해 다음과 같은 역량을 기를 수 있다.

대규모 CSV 데이터 처리 능력
도메인 지식을 데이터 문제로 바꾸는 능력
시간 순서를 고려한 머신러닝 설계 능력
데이터 누수와 과적합을 판단하는 능력
의미 있는 피처를 설계하는 능력
확률 예측 모델을 평가하는 능력
실험 결과를 비교하고 기록하는 능력
실제 제출 환경을 고려한 재현 가능한 코드 작성 능력
복잡한 프로젝트를 문서화하고 설명하는 능력

특히 야구라는 도메인을 통해 데이터가 단순한 숫자의 집합이 아니라, 경기 상황과 선수의 의사결정이 기록된 결과라는 점을 배울 수 있다.

9. 앞으로의 성장 모습

이 프로젝트를 마친 뒤에는 단순히 RandomForest를 사용할 줄 아는 사람이 아니라, 실제 문제를 데이터 분석 문제로 구조화할 수 있는 사람에 가까워질 것이다.

문제를 정의하고, 데이터를 확인하고, 누수를 막고, 적절한 검증 방식을 설계하고, 피처를 만들고, 모델을 비교하고, 결과를 설명하는 전체 과정을 경험하기 때문이다.

또한 이번 프로젝트는 “모델 성능을 높이는 것”과 “믿을 수 있는 결과를 만드는 것”이 다르다는 점을 알려줄 것이다.

좋은 데이터 과학자는 가장 복잡한 모델을 만드는 사람이 아니라, 문제의 본질을 이해하고 올바른 정보를 사용하며 결과를 재현 가능하게 설명하는 사람이다. 이번 LG 프로젝트는 그 역량을 연습할 수 있는 좋은 기회가 될 것이다.

마무리

이번 프로젝트의 최종 목표는 제구 성공 확률을 잘 예측하는 모델을 만드는 것이다. 하지만 개인적으로 더 중요한 목표는 데이터를 통해 야구를 이해하고, 현실적인 예측 문제를 끝까지 해결해보는 경험을 쌓는 것이다.

이번 프로젝트를 진행하면서 나는 다음과 같은 질문에 답할 수 있어야 한다.

어떤 상황에서 투수의 제구 성공률이 달라지는가?
과거 기록은 미래 투구를 얼마나 설명할 수 있는가?
데이터로 만든 확률을 실제로 얼마나 신뢰할 수 있는가?
그리고 나는 이 문제를 해결하는 과정에서 어떤 분석가와 개발자로 성장했는가?

이 질문에 대한 답을 하나씩 기록해나가는 것이 이번 프로젝트의 가장 큰 성과가 될 것이다.

[주간회GO 26년 8월 2주차] 수강신청 스트레스, ISA 개편안 만기 연장, 비욘드 부산 온라인 회의, FLY ASIA 팀장 탈주, 달서 AI 대회 입상(?),

MKISOS — Mon, 10 Aug 2026 09:36:58 +0900

[주간회GO 26년 8월 2주차]

26년 8월 2주차

다음주에는 그래도 달달한 휴식이 있으니 보상을 받기 전 저번주와 이번주는 지옥주를 보내야한다.
사실 어제도 유니커 데모데이 다녀와서 많은 에너지를 받아왔기에 그 에너지로 이번주를 살아야 할 것 같다.
몸과 정신이 피로하고 일정 관리와 업무로 스트레스도 받지만 그 와중에 운동도 하고 루틴을 지키면서 내 삶을 내가 통제하는 사람으로 나아가고 있다고 느낀다.

26년 8월 3일 월요일

어제 11시면 잘 시간인데 집에 도착해서 배고파서 막 먹어서 ㅋㅋ
아침에 겨우 다녀왔다.

수강신청마다 스트레스 어쩔거야
그래도 내가 컨트롤 할 수 있는 곳 까지는 다 했고 이제 일어나는 일들에 대해서 하나씩 대응하면 별 거 없을 것이다.

인샌니 그렇던데?!

화분에 물이나 주고 심신 안정했다. (매주 월요일 물주는 날)

카카오 왜 연기되었지 스케줄 크게 조정해야한다ㅠㅠ
이제 얼마안남은 구청에 체단실 ㅋㅋㅋ
불끄고 가끔 혼자 운동하면 낭만 미쳤음

내일 바로 전화해서 만기 다시 연장하고 조취 취해야겠다
스트레스 받네 ^^
다들 올해 가입하세요. 아직 안한 분들 모르면 디엠해도 됩니당

26년 8월 4일 화요일

화요일 오운완

하 스트레스 받지만 내가 할 수 있는데까지는 다 했으니…
증권사도 지금 제대로 공지 받은게 없다고 하셔서..

내 블로그 글 일부 :
최근 발표된 ISA 개편안을 보며 적지 않은 아쉬움이 남았다. 지금까지는 계좌 만기를 최대한 길게 설정해 지수 ETF를 장기간 보유하고, 필요할 때까지 복리 효과를 누리다가 만기에는 연금계좌로 이전해 투자와 세제혜택을 이어가는 전략을 생각하고 있었다.

하지만 이번 개편안이 그대로 통과된다면 계약기간이 제한되고 기존처럼 장기간 계좌를 유지하는 전략이 어려워질 수 있다. 또한 연간 납입한도 이월도 사라져 한 해 2,000만 원을 채우지 못하면 그 기회를 다시 활용할 수 없게 된다.

혹시나 하는 마음에 오늘 증권사에 직접 전화해 만기를 더 길게 변경할 수 있는지도 확인해봤지만 이미 변경은 불가능했다. 결과적으로 나는 2031년 만기 이후에는 기존에 계획했던 장기 운용 전략을 그대로 이어가기 어려울 가능성이 생겼다. 물론 아직 국회 통과 전인 개편안이지만, 투자자는 제도가 바뀐다고 투자를 멈추는 것이 아니라 바뀐 환경 안에서 다시 최선의 전략을 찾아가는 것이 중요하다고 생각한다.

밥 먹고 너무 피곤해서 커피사서 들어왔다.
요즘 퇴근하고 여러 대외활동 회의 그 와중에 자격증 공부도 해야해서 몸이 좀 피곤하다.
자격증은 따로 지금 블로그 작성중이라서 이번주에 시험치고 올릴 예정.
좀만 고생하자 어차피 준비하는 거 다 해낼건데 할만하자나

밥 먹고 충동으로 시킨 라라스윗 택배 받음 ㅋㅋㅋㅋㅋ 내년까지 먹을 듯 ㄷ

비욘드 부산 비대면 회의
진짜 릴스 찍어야 할 것 같은데 큰일이다…

26년 8월 5일 수요일

오늘은 짧게
요즘 너무 피곤해

기대하던 행사가 연기되었는데 일정이 안맞을까봐 이것도 스트레스 ㅋㅎㅋㅎㅋ

수강신청으로 이번주 극심한 스트레스 다음주 정정기간까지 엄청 스트레스 받을 예정이다. 진짜 평범하고 싶다

으아 이번 활동은 진짜 스트레스;;; 열정이 조금 아쉽당

갑자기 저녁 인증 ㅋㅋㅋㅋㅋㅋ 윳기다

퇴근 후 요즘 유튜브 보는게 소원이야;;
가볍게 한 회 풀기

26년 8월 6일 목요일

전화로 문의하면 또 잘 모른다고 하고 내가 스트레스 받을 거 같아서 문의 남겨둠 제발 빨리 답장 오길^^

오운완 등 뿌셨음

돈 나가는 건 잘 챙겨야지~

오랜만에 뉴욕에서 온 연락
형이랑 소통 열심히 해야겠다. 어릴때부터 멋진 형인데 열심히 사니까 이렇게 연락도 닿았다.

Gpt plus, edu, pro 다 모았다…
내 돈은 아니지만 왜 모두 지피티만 지원해주실까라는 살짝의 아쉬움 그래도 감사합니다!!!

미리예약 했다 마음이 편하다

26년 8월 7일 금요일

스트레스 받아도 노력하고 있는 보람이 있다…!

갤러리보니 당연한 결과인가 싶다

근데 식단이 진짜 돈 모으고 건강챙기고 너무 좋은 거 같은데 너무 늦게 알아서 아쉽다

결국 수강신청 성공적이다.
월공강 ㄷㄷ 재수강하면 학점 0.03정도 오르던데 그냥 안하지 뭐 사실 못하는 거긴해 노력했지만…
성공하고 느낌점은 이렇게 비교적 잘 풀릴 예정이였는데 너무 걱정이 많아서 내 시간을 허비한 느낌? 이제 이런 멘탈적인 부분 잘 보완해서 한 가정을 지킬 남자로 거듭나야지.

이번에는 제발 저번 7차도 튕김…

이게 붙다니
발표 열심히 준비해야지

퇴근 후 바로 서울

건우 집에서 힐링 식단 + 같이 시험 전날 공부

https://mkisos.tistory.com/entry/adsp50

[ADsP] 책 한권, 16시간 30분 합격 도전 (50회)

이번에는 데이터분석 준전문가 ADsP 자격증에 도전하게 되었다.정보처리기사와 SQLD를 준비할 때도 인강보다는 책과 무료 자료를 활용해 독학했다. 강의를 처음부터 끝까지 듣기보다는 필요한 개

mkisos.tistory.com

26년 8월 8, 9일 토,일요일 주말

건우랑 같은 시험, 같은 학교, 같은 고사실 ㄷㄷ

점심 해 먹기 ~

LG Aimers 회의 (동현이가 사온 제니쿠키와 함께)

홈플러스 장보고 저녁 먹고 왔다

월곡역 진짜 살기 너무 좋은 것 같다.

6호선이 좋아진다.

만취 숙취 엔딩...

이번주 열심히 살았으니 좀 흐트러지자...

숙취와 함께 인생 첫 오마카세, 그리고 도요스 스시다온의 마지막날을 함께했다.

너무 너무 만족

엔트리급 경험했으니

나중에 부모님이나 사랑하는 사람과 더 좋은 곳 다녀보고 싶다.

(건우랑 황준이는 숙취가 너무 심해서 나랑 동현이가 하나씩 더 먹었다...ㅎ 2배 이벤트)

조금 쉬다가 멘토링까지 했다.

그리고 서울에서 청주 내려오기 바빴고 내려오는 길에 여러 업무를 했다. 월요일이 무서웠다.

할 게 너무 많아...

경제금융용어 공부 586 : 크라우드펀딩

MKISOS — Sun, 9 Aug 2026 21:00:25 +0900

크라우드펀딩

좋은 아이디어가 있어도 사업을 시작할 자금이 부족하면 실행하기 어렵다. 크라우드펀딩은 은행이나 대형 투자기관을 거치지 않고 온라인 플랫폼을 통해 다수의 사람에게 소액 자금을 모으는 방식이다. 창업자는 자금뿐 아니라 시장 반응과 초기 고객까지 확보할 수 있지만, 투자자는 정보 부족과 사업 실패 위험을 함께 부담해야 한다.

1. 한 줄 정의

크라우드펀딩은 온라인 플랫폼을 통해 다수의 개인으로부터 자금을 모으는 자금조달 방식이다.

2. 기본 개념

크라우드펀딩(Crowd Funding)은 대중을 뜻하는 크라우드(Crowd)와 자금조달을 뜻하는 펀딩(Funding)이 결합한 용어이다.

즉, 한 명의 큰 투자자나 금융기관으로부터 자금을 받는 대신 많은 사람이 소액씩 참여하여 필요한 자금을 마련하는 방식이다.

크라우드펀딩은 일반적으로 다음 세 주체로 구성된다.

자금수요자: 아이디어나 프로젝트를 실행하려는 개인 또는 기업
자금공급자: 프로젝트에 후원하거나 투자하는 다수의 사람
플랫폼: 자금수요자와 자금공급자를 연결하는 온라인 중개기관

자금수요자는 플랫폼에 프로젝트의 목적, 목표금액, 진행계획, 보상방식 등을 공개한다. 참여자들은 이를 확인한 뒤 후원, 대출 또는 투자 형태로 자금을 제공한다.

3. 왜 중요한가

초기 창업기업이나 개인 창작자는 사업 실적과 담보가 부족해 은행대출이나 기관투자를 받기 어려운 경우가 많다.

크라우드펀딩은 이러한 자금조달의 문턱을 낮춘다. 아이디어와 계획만으로도 대중의 공감을 얻으면 사업에 필요한 초기자금을 마련할 수 있기 때문이다.

또한 크라우드펀딩은 단순히 돈을 모으는 역할만 하지 않는다.

프로젝트에 실제로 돈을 낼 사람이 얼마나 있는지를 확인할 수 있어 시장 수요를 미리 검증하는 수단이 된다. 참여자들의 의견을 제품 개발에 반영할 수 있고, 펀딩 자체가 홍보와 마케팅 효과를 만들기도 한다.

4. 쉽게 이해하는 예시

대학생 예시

대학생이 분실물을 쉽게 찾을 수 있는 스마트 태그를 개발했다고 가정해보자.

제품 아이디어는 있지만 초기 생산비 2,000만 원이 부족한 상황이다.

학생은 크라우드펀딩 플랫폼에 제품 설명과 시제품 사진을 공개하고, 5만 원을 후원한 사람에게 완성된 제품을 제공하겠다고 약속한다.

400명이 참여하면 필요한 생산비를 마련할 수 있다.

창업 예시

스타트업이 친환경 텀블러를 개발했지만 대량생산 전에 실제 구매 수요가 있는지 확신하지 못하고 있다.

크라우드펀딩을 진행해 목표금액을 빠르게 달성했다면 시장에 관심 있는 고객이 충분하다는 신호로 볼 수 있다.

반대로 참여가 거의 없다면 제품을 대량생산하기 전에 디자인이나 가격을 수정할 수 있다.

문화예술 예시

독립영화 제작자가 영화 제작비를 마련하기 위해 후원자를 모집할 수 있다.

참여자에게 영화 엔딩크레디트 이름 등록, 시사회 초대권, 굿즈 등을 제공하는 방식이다.

투자 예시

초기 스타트업이 투자형 크라우드펀딩을 통해 주식이나 채권을 발행할 수 있다.

투자자는 해당 기업의 성장 가능성을 보고 자금을 제공하고, 이후 지분가치 상승이나 이자수익을 기대한다.

5. 핵심 특징

5-1. 다수의 사람이 소액으로 참여한다

크라우드펀딩은 한 명의 대형 투자자에게 의존하지 않고 많은 사람으로부터 자금을 모은다.

개별 참여금액은 작아도 참여자가 많으면 큰 자금을 마련할 수 있다.

5-2. 온라인 플랫폼을 통해 진행된다

프로젝트 공개, 참여자 모집, 결제, 진행상황 공유가 대부분 온라인에서 이루어진다.

이로 인해 지역과 시간의 제약이 줄어들고 자금수요자와 공급자가 쉽게 연결될 수 있다.

5-3. 자금조달과 시장검증이 동시에 가능하다

후원자가 많다는 것은 해당 제품이나 서비스에 실제 수요가 있다는 의미가 될 수 있다.

따라서 창업자는 본격적인 생산 전에 시장 반응을 확인할 수 있다.

5-4. 정보 비대칭 위험이 존재한다

투자자는 프로젝트 운영자의 역량과 실제 진행상황을 완전히 알기 어렵다.

계획이 지연되거나 제품이 기대와 다르게 완성될 수 있으며, 프로젝트 자체가 실패할 가능성도 있다.

6. 관련 개념과의 차이

크라우드펀딩 vs 일반 은행대출

크라우드펀딩

다수의 개인에게 자금을 모집함
아이디어와 프로젝트의 매력이 중요함
담보 없이도 자금조달이 가능할 수 있음
후원, 대출, 투자 등 다양한 방식이 존재함

은행대출

금융기관이 차주의 신용과 담보를 심사함
원금과 이자를 상환해야 함
사업성과 상환 능력이 중요함

크라우드펀딩은 대중의 참여를 통해 자금을 모으지만, 은행대출은 금융기관의 심사를 통해 돈을 빌리는 방식이다.

크라우드펀딩 vs 벤처캐피털 투자

크라우드펀딩

다수의 개인이 소액으로 참여함
온라인 플랫폼을 통해 공개적으로 모집함
초기 제품과 아이디어 검증에 유용함

벤처캐피털 투자

전문 투자기관이 비교적 큰 금액을 투자함
사업성, 팀 역량, 성장 가능성을 전문적으로 심사함
경영권과 지분 조건이 중요함

크라우드펀딩은 대중의 폭넓은 참여가 특징이고, 벤처캐피털은 전문 투자기관의 집중적인 심사와 투자가 특징이다.

크라우드펀딩 vs P2P대출

크라우드펀딩

후원형, 기부형, 대출형, 투자형을 모두 포함하는 넓은 개념임

P2P대출

개인이나 사업자에게 자금을 빌려주고 이자를 받는 대출형 방식임
크라우드펀딩의 한 유형으로 볼 수 있음

즉 P2P대출은 크라우드펀딩 전체가 아니라 그중 대출형에 해당한다.

7. 경제적 의미

국가경제 관점

크라우드펀딩은 기존 금융기관이 충분히 지원하지 못했던 초기 창업기업과 소규모 프로젝트에 자금을 공급한다.

새로운 아이디어와 창업을 활성화하고 금융 접근성을 높이는 역할을 한다.

기업 관점

기업은 자금조달과 동시에 제품 홍보, 고객 확보, 수요 검증을 진행할 수 있다.

특히 초기 스타트업에는 자금보다 시장의 반응을 확인할 수 있다는 점이 더 큰 가치가 될 수 있다.

금융시장 관점

크라우드펀딩은 자금수요자와 공급자를 온라인으로 직접 연결하여 금융중개의 방식을 다양화한다.

빅데이터와 디지털 신용평가 기술이 결합되면 새로운 금융서비스로 발전할 가능성도 있다.

투자 관점

투자자는 초기 기업이나 새로운 프로젝트에 소액으로 참여할 수 있다.

하지만 공개된 정보가 제한적이고 원금 손실 가능성이 높기 때문에 사업계획, 운영자 경력, 자금 사용처, 투자조건을 꼼꼼히 확인해야 한다.

8. 정리

크라우드펀딩은 온라인 플랫폼을 통해 다수의 개인으로부터 자금을 조달하는 방식이다. 후원형, 기부형, 대출형, 투자형 등 목적에 따라 다양한 형태로 운영된다. 창업자는 초기자금을 마련하는 동시에 시장 반응과 고객의 피드백을 확인할 수 있다. 다만 프로젝트 실패, 정보 비대칭, 지적재산권 노출 등의 위험이 존재하므로 자금수요자와 참여자 모두 신중한 판단이 필요하다.

경제금융용어 공부 585 : 콜옵션(Call Option)

MKISOS — Sat, 8 Aug 2026 21:00:06 +0900

콜옵션(Call Option)

콜옵션은 미래에 특정 자산을 미리 정한 가격으로 살 수 있는 권리를 거래하는 금융상품이다. 투자자는 자산 가격이 오를 것으로 예상할 때 주로 활용하며, 실제로 사는 것이 아니라 '살 수 있는 권리'를 사는 것이 핵심이다. 주식뿐 아니라 환율, 금리, 원자재 등 다양한 자산에도 활용된다.

1. 한 줄 정의

콜옵션은 미래에 미리 정한 가격으로 특정 자산을 살 수 있는 권리를 사고파는 계약이다.

2. 기본 개념

콜옵션(Call Option)은 일정한 수수료(프리미엄)를 지급하고 미래의 특정 시점이나 그 이전에 정해진 가격(행사가격)으로 자산을 매수할 수 있는 권리를 얻는 금융상품이다.

콜옵션을 매수한 사람은 권리를 행사할지 말지를 선택할 수 있지만, 반드시 매수해야 하는 의무는 없다.

반대로 콜옵션을 매도한 사람은 매수자가 권리를 행사하면 약속한 가격에 자산을 반드시 판매해야 할 의무를 가진다.

즉, 매수자는 권리를 사고, 매도자는 의무를 파는 구조이다.

3. 왜 중요한가

콜옵션은 적은 금액으로 큰 투자 효과를 얻을 수 있는 대표적인 파생상품이다.

투자자는 자산 가격 상승에 베팅하거나 기존 투자자산의 위험을 관리(헤지)하기 위해 활용한다.

또한 옵션시장은 투자자들의 미래 가격 전망이 반영되는 시장이기 때문에 금융시장에서도 중요한 역할을 한다.

4. 쉽게 이해하는 예시

실생활 예시

신축 아파트 분양권을 생각해보자.

계약금만 먼저 내고 나중에 정해진 가격으로 아파트를 살 수 있는 권리를 확보했다고 가정하자.

나중에 아파트 가격이 크게 오르면 처음 약속한 가격으로 구매해 큰 이익을 얻을 수 있다.

반대로 가격이 떨어졌다면 계약금을 포기하고 구매하지 않을 수도 있다.

콜옵션도 이와 매우 비슷한 원리이다.

투자 예시

A주식의 현재 가격이 10만 원이다.

행사가격이 10만 원인 콜옵션을 프리미엄 5천 원에 매수했다고 가정해보자.

만기 시 주가가 13만 원이 되었다면 10만 원에 살 권리를 행사해 3만 원의 차익을 얻을 수 있다.

반대로 주가가 9만 원이라면 권리를 행사하지 않고 옵션만 포기하면 된다.

이 경우 손실은 처음 지급한 프리미엄인 5천 원으로 제한된다.

5. 핵심 특징

5-1. 가격 상승을 기대할 때 활용한다

콜옵션은 기초자산 가격이 오를 것으로 예상할 때 투자하는 상품이다.

가격이 많이 오를수록 수익 가능성이 커진다.

5-2. 권리만 있고 의무는 없다

콜옵션 매수자는 손해가 예상되면 권리를 행사하지 않아도 된다.

반면 콜옵션 매도자는 상대방이 권리를 행사하면 반드시 약속을 이행해야 한다.

5-3. 손실과 수익 구조가 다르다

매수자의 최대 손실은 처음 지급한 프리미엄으로 제한된다.

하지만 매도자는 자산 가격이 크게 상승하면 손실이 매우 커질 수 있다.

5-4. 레버리지 효과가 크다

적은 금액으로 큰 규모의 자산 가격 변동에 투자할 수 있다.

그만큼 높은 수익을 기대할 수 있지만 위험도 함께 커진다.

6. 관련 개념과의 차이

콜옵션 vs 풋옵션

콜옵션

자산을 살 권리
가격 상승 시 수익 가능
상승장에 유리

풋옵션

자산을 팔 권리
가격 하락 시 수익 가능
하락장에 유리

즉, 콜옵션은 상승에 투자하고 풋옵션은 하락에 투자하는 상품이다.

콜옵션 vs 선물거래

콜옵션

권리만 존재
행사 여부를 선택할 수 있음
손실이 프리미엄으로 제한됨

선물거래

반드시 거래해야 하는 의무가 있음
만기에 계약을 이행해야 함
손실 규모가 매우 커질 수 있음

옵션은 선택권이 있지만 선물은 의무 계약이라는 점이 가장 큰 차이이다.

7. 경제적 의미

국가경제 관점

옵션시장은 금융시장의 위험을 효율적으로 분산시키고 다양한 투자 전략을 가능하게 한다.

기업 관점

기업은 원자재 가격이나 환율 변동 위험을 줄이기 위해 옵션을 활용하기도 한다.

금융시장 관점

콜옵션은 대표적인 파생상품으로 시장의 미래 가격 전망과 투자심리를 반영하는 중요한 지표가 된다.

투자 관점

개인투자자는 상승장에서 적은 자금으로 높은 수익을 기대할 수 있지만, 옵션의 가치가 빠르게 감소할 수 있어 충분한 이해가 필요하다.

8. 정리

콜옵션은 미래에 특정 자산을 미리 정한 가격으로 살 수 있는 권리를 거래하는 금융상품이다. 투자자는 가격 상승을 예상할 때 활용하며, 손실은 프리미엄으로 제한되는 반면 높은 수익을 기대할 수 있다. 다만 레버리지 효과가 큰 만큼 위험도 높아 옵션의 구조와 손익 계산 방식을 충분히 이해한 뒤 투자하는 것이 중요하다.

[ADsP] 책 한권, 16시간 30분 합격 도전 (50회)

MKISOS — Sat, 8 Aug 2026 13:08:40 +0900

이번에는 데이터분석 준전문가 ADsP 자격증에 도전하게 되었다.
정보처리기사와 SQLD를 준비할 때도 인강보다는 책과 무료 자료를 활용해 독학했다. 강의를 처음부터 끝까지 듣기보다는 필요한 개념을 확인하고 문제를 반복해서 푸는 방식이 나에게 더 잘 맞았다.

다만 여러 자료를 찾아다니며 공부하다 보니 실제 공부보다 자료를 찾고 비교하고 정리하는 데 시간이 더 많이 들기도 했다.
이번에는 이런 과정을 줄이기 위해 한 권의 교재를 정하고, 처음부터 끝까지 활용해보기로 했다.
그래서 선택한 책이 바로 미어캣 이지패스 ADsP 교재다.
ADsP 교재로 유명한 민트책과 고민했지만, 미어캣 교재에 수록된 문제와 모의고사가 더 많다는 후기를 보고 선택했다.
소프트웨어 전공자로서 데이터베이스, 통계, 인공지능과 관련된 개념을 일부 접해본 경험이 있기 때문에 긴 개념 설명보다는 문제를 많이 풀면서 시험 유형을 익히는 방식이 더 잘 맞을 것이라고 판단했다.

이번 목표는 여러 강의와 요약 자료를 동시에 보는 것이 아니다. (예전에는 공짜 자료로 자격증을 취득하는 맛을 즐겼는데 바빠지니 그게 더 피로한 것 같다는 판단.)
미어캣 이지패스 한 권을 중심으로 약 10일 동안 공부해 ADsP 자격증을 취득하는 것이 목표다.

공부 전, ADsP란?

ADsP는 Advanced Data Analytics Semi-Professional의 약자로, 우리말로는 데이터분석 준전문가라고 한다.
데이터에 대한 기본적인 이해를 바탕으로 데이터 분석을 기획하고, 통계와 데이터 마이닝 기법을 활용할 수 있는지를 평가하는 국가공인 자격시험이다.

단순히 특정 프로그램을 사용할 수 있는지 확인하는 시험은 아니다.
데이터가 무엇인지 이해하는 것부터 분석 과제를 기획하는 방법, 통계 분석, 데이터 마이닝과 머신러닝의 기초 개념까지 데이터 분석의 전반적인 흐름을 다룬다.

ADsP에서 다루는 주요 내용은 다음과 같다.

데이터와 정보의 개념
데이터베이스와 빅데이터
데이터 분석 기획과 방법론
통계의 기초와 가설검정
회귀분석과 시계열 분석
분류·군집·연관분석
데이터 마이닝과 머신러닝 기초

개발자가 반드시 취득해야 하는 자격증은 아니지만, 데이터와 AI를 활용한 서비스를 만들고 싶은 나에게는 데이터 분석의 전체적인 흐름을 정리할 수 있는 기회라고 생각했다.

ADsP 시험 개요

ADsP 시험은 총 3과목으로 구성된다.

과목	문항 수	배점
1과목 데이터 이해	10문항	20점
2과목 데이터 분석 기획	10문항	20점
3과목 데이터 분석	30문항	60점
합계	50문항	100점

시험은 객관식 50문항으로 출제되며 시험시간은 90분이다.
1과목과 2과목은 각각 10문항이고, 3과목은 30문항이다.
전체 시험의 60%가 3과목에서 출제되기 때문에 통계 분석과 데이터 마이닝을 다루는 3과목의 비중이 가장 크다.
그렇다고 1과목과 2과목을 포기할 수는 없다. ADsP에는 과목별 과락 기준이 있기 때문이다.

ADsP 합격 기준

ADsP에 합격하려면 다음 두 가지 조건을 모두 충족해야 한다.

총점 100점 중 60점 이상
각 과목에서 40% 이상 득점

과목별 문항 수를 기준으로 보면 다음과 같다.

과목	전체 문항	과락을 피하기 위한 최소 정답 수
1과목 데이터 이해	10문항	4문항
2과목 데이터 분석 기획	10문항	4문항
3과목 데이터 분석	30문항	12문항

전체 점수가 60점을 넘더라도 특정 과목에서 40% 미만을 받으면 불합격한다.
예를 들어 1과목에서 3문제만 맞히고 나머지 과목에서 높은 점수를 받아 총점이 60점을 넘더라도 과락으로 불합격할 수 있다.
따라서 특정 과목을 완전히 포기하기보다는 모든 과목에서 기본 점수를 확보해야 한다.
그 위에 출제 비중이 가장 높은 3과목에서 점수를 끌어올리는 전략이 필요하다.

공부를 시작하기 전 세운 전략

처음부터 개념서를 정독하지는 않을 생각이다.

우선 늘 하던대로 아무 준비 없이 기출문제 한 회분을 먼저 풀어볼 예정이다.
정보처리기사와 SQLD를 준비하면서 느낀 점은 시험공부를 시작하기 전에 실제 문제를 먼저 보는 것이 공부 방향을 잡는 데 도움이 된다는 것이다.

기출문제를 먼저 풀어보면 다음 내용을 확인할 수 있다.

현재 실력으로 몇 점 정도 나오는지
이미 알고 있는 개념은 무엇인지
처음 보는 개념은 무엇인지
문제가 암기형인지 이해형인지
선택지가 어떤 방식으로 출제되는지
어떤 과목부터 집중해야 하는지

첫 기출문제의 점수가 낮아도 크게 신경 쓰지 않을 생각이다.
처음 푸는 문제의 목적은 합격 점수를 받는 것이 아니라 현재 위치와 시험 유형을 확인하는 것이기 때문이다.
첫 기출문제 결과를 확인한 뒤 본격적인 공부 전략을 정할 예정이다.

기초 점수가 낮다면

기출문제를 풀어본 결과 개념이 거의 없는 상태라면 미어캣 이지패스의 이론 부분부터 빠르게 읽을 예정이다.
처음부터 세부 내용을 모두 암기하기보다는 전체 범위가 어떻게 구성되어 있는지 먼저 파악할 생각이다.
어떤 개념이 어느 과목에 속하는지, 비슷한 용어가 어떻게 구분되는지, 반복해서 출제되는 개념이 무엇인지 확인할 예정이다.
전체 흐름을 잡은 뒤 단원별 문제와 기출문제를 풀면서 암기 내용을 보완하려 한다

기본 점수가 어느 정도 나온다면

전공 지식이나 기존 공부 경험을 바탕으로 어느 정도 점수가 나온다면 개념 정독보다 문제 풀이 비중을 높일 예정이다.
문제를 계속 풀면서 틀린 개념만 교재에서 다시 확인하고, 반복해서 틀리는 내용만 따로 정리하는 방식이다.
이미 알고 있는 내용을 처음부터 다시 읽는 데 시간을 쓰기보다는 실제로 부족한 부분을 빠르게 찾아 보완하는 것이 더 효율적이라고 생각한다.
결국 첫 기출문제 결과에 따라 두 가지 전략 중 하나를 선택할 예정이다.

개념을 먼저 잡고 문제를 풀 것인지,
문제를 풀면서 부족한 개념만 채울 것인지 결정한다.

미어캣 이지패스 한 권으로 공부할 예정이다

이번에는 공부 자료를 최대한 단순하게 가져갈 예정이다.
기본적으로 사용할 자료는 다음과 같다.

개념 학습: 미어캣 이지패스
단원별 문제: 교재 수록 문제
실전 연습: 교재 수록 모의고사
복습 자료: 교재에 표시한 내용과 오답
보조 자료: 꼭 필요한 경우에만 검색

처음부터 유튜브 강의, 블로그 요약, 무료 PDF를 모두 찾아보기 시작하면 자료만 계속 늘어날 가능성이 크다.
자료가 많다고 반드시 공부가 잘되는 것은 아니다.

이번에는 우선 책 한 권을 기준으로 공부하고, 책만으로 이해되지 않는 개념이 있을 때만 추가 자료를 찾아볼 예정이다.
공부 과정에서 다른 자료가 정말 필요하다고 판단되면 활용하겠지만, 기본 원칙은 교재 한 권을 끝까지 반복하는 것이다.

공부 과정을 블로그에 기록할 예정이다

이번에도 합격 결과만 작성하지 않고 공부 과정도 블로그에 조금씩 기록할 예정이다.
잘 정리된 합격 후기만 남기기보다는 실제로 공부를 시작했을 때 몇 점이 나왔는지, 어떤 부분에서 막혔는지, 점수가 어떻게 변했는지를 투명하게 공개하려 한다.

공부 기록에는 다음 내용을 담을 예정이다.

하루에 공부한 범위
실제 공부 시간
기출문제와 모의고사 점수
과목별 정답률
헷갈렸던 개념
반복해서 틀린 문제
공부 방법의 변경 사항
시험 전까지의 점수 변화

처음 세운 계획이 실제 공부 과정에서 달라질 수도 있다.
개념 공부보다 문제 풀이가 더 필요할 수도 있고, 생각보다 통계 부분에서 시간이 오래 걸릴 수도 있다.
계획대로 되지 않는 과정까지 포함해 가능한 한 솔직하게 기록할 생각이다.

학습 기록

아래 자세한 과정들이 있다.

26/07/22 수요일 - 30분

책에 45회 기출 문제가 있어서 그냥 대충 읽고 빠르게 풀어보았다. 뭔가 어디서 들어본 내용들이 가득했는데 2개중에 헷갈리는게 많았다. 결국 채점 해보았다. (오답하지 않고 그냥 채점만하고 끝!)

과목	맞은 개수	점수
1과목 (10문항)	5개	50점
2과목 (10문항)	5개	50점
3과목 (30문항)	8개	26.7점

전체 점수

맞은 문제: 18/50문항
전체 점수: 36점(100점 만점)

합격 기준과 비교

총점 60점 이상
과락: 각 과목 40점 이상

현재는

✅ 1과목: 과락 통과 (50점)
✅ 2과목: 과락 통과 (50점)
❌ 3과목: 과락 (26.7점)
❌ 총점: 36점

점수가 내 생각보다 낮고 또 개념 공부를 할 필요를 느꼈다.
우선 개념 공부하고 해당 문제를 좀 풀어보아야겠다. 그리고 기출을 많이 풀어야지...
이거 설마 좀 더 시간을 투자해야하려나;;;

26/07/24 금요일 - 1시간 10분

공부내용

책 빠르게 수박 겉핥기 식으로 읽어보기
P.5 ~ 63
1과목, 책 기준 3장까지 후딱 읽고 거기에 있는 문제들 풀었다. 외우기 보다는 그냥 앞으로 많은 문제 만나면서 익숙해져야지 생각하며 지나갔다.

그리고 뒤에 1과목 기출문제랑 예상문제 총 50문제 있어서 풀었다.
기출문제 : 15/20
예상문제 : 21/30

26/07/27 월요일 - 1시간 30분

P.80 ~ 149

진짜 개념파트는 대애애애애애충 읽음
그 이유는 차피 무슨 내용 다루는지만 체크하고 문제를 풀어야 그 개념을 외울지 말지 판단이 서는 타입이라서
후딱 읽고 문제 풀려고 좀 급하게 큰 글자 위주로 읽음.

그리고 2과목 기출, 예상 문제 풀었음
기출 유형 문제 : 13/20
예상 문제 : 16/26

처참했다…
대충 읽은 값을 치뤘다…

26/07/28 화요일 - 2시간

P.150 ~ 224
3과목 R문법은 우선 진짜 초반 파트의 기본은 언어랑 비슷하니까 대애충 이런거 있구나 하고 넘기고
낯선 것들은 좀 읽으면서 문제 풀면서 진행했다.

26/07/29 수요일 - 1시간 40분

P. 226 ~ 294
여기 파트는 읽다가 이해도 잘안되고 와닿지도 않아서 3과목이니 대충 지나가서 문제 풀고 유튜브 영상으로 학습할까? 생각하면서 넘겼다. (9 to 6 끝나고 읽으려니 오늘따라 진짜 죽을맛…)
읽다가 고득점을 노리는 부분, 출제 빈도가 낮다면 과감히 패스 했다. 문제에서 만나자고 생각하고…

26/07/30 목요일 - 2시간

P.296 ~ 369
진짜 기준 없이 막 읽히는 부분만 읽으면서 진도만 빼려고 노력했다. 항상 수박겉핥기 마인드로 범위를 우선 다 보고 문제를 풀면서 중요도를 파악해서 개념을 공부하는게 전체 다 공부하는 것보가 에너지를 덜 쓴다고 생각해서 막 읽었다.

P.370 ~ 377
개념 이제 한파트 남았길래 후딱 읽고 어서 기출 풀면서 모르는 부분, 빈출 부분 파악해서 개념 보충하려고 마저 공부 시작함.

26/07/31 금요일 - 2시간

3과목 기출 유형 문제 : 24/40
처참한 결과이다. 귀신같이 60%이긴하네
찍은 것도 너무 많고 그냥 키워드가 익숙한 거 고르는 게임한 느낌이다.

3과목 예상문제 : 65/90

3과목네서 이제 절반은 알겠고 나머지는 잘 찍으면 될 것 같다. 백점을 위한 시험이였으면 바로 유튜브 강의 등을 통해 개념을 보충하겠지만 우선 문제를 좀 더 풀고자 한다.

1회 모의고사 : 32/50
1과목 6/10
2과목 6/10
3과목 20/30

우선 1,2과목 안 본 지 오래라서 전체적으로 시험을 한번 보았다.
그래도 풀면서 익숙해지고 있는데 최대한 많이 풀면 좀 더 정답률이 오르지 않을까?
그래도 책을 사 놓으니 문제 구하려고 서치안해도 되어서 좋다.

2회 모의고사 : 32/50
1과목 8/10
2과목 5/10
3과목 19/30

과락는 면했는데 처음보는 유형이나 개념나오면 그냥 틀려버린다… 대충 찍긴해도 아쉽네
우선 책에 있는 모의고사랑 기출 풀어도 점수 안오르면 강의를 보던 개념을 좀 채워야겠다.

나중에 한번 시간 나면 볼 유튜브도 찾았다. 볼 시간이 있을까 이거말고도 여러 프로젝트 공모전 대외활동 출퇴근 때문에 바쁘다 ㅠㅠ

26/08/03 월요일 - 40분

3회 모의고사 : 30/50
1과목 7/10
2과목 5/10
3과목 18/30

회차	총점	1과목	2과목	3과목	결과
1회	32/50	6/10	6/10	20/30	합격권(64점)
2회	32/50	8/10	5/10	19/30	합격권(64점)

3회	30/50	7/10	5/10	18/30	합격권(60점)

분석

* 1과목: 6 → 8 → 7
    * 안정적으로 과락 걱정은 없음.
    * 7~8개 정도는 꾸준히 맞히고 있다.
* 2과목: 6 → 5 → 5
    * 가장 불안한 과목.
    * 항상 5개 정도라 1~2문제만 틀려도 과락 위험이다.
* 3과목: 20 → 19 → 18
    * 점수가 조금씩 떨어지고 있지만 아직 60% 수준은 유지.
    * 계산 문제와 통계 개념을 조금 더 다듬으면 20~22개까지 올릴 수 있다.

현재 실력
모의고사 3회 평균
* 총점 31.3/50 = 약 62.7점
* 실제 시험 기준으로는 합격권 턱걸이 수준이다.

26/08/04 화요일 - 1시간

45회 기출 문제 : 39/50
1과목 8/10
2과목 9/10
3과목 22/30

아직까지 계속 찍는 느낌이 있어서 오답하고 기출 하나만 더 풀어보고 개념 정리하고 계속 기출 이어서 풀 생각이다

46회 기출 문제 : 38/50
1과목 8/10
2과목 9/10
3과목 21/30

이상하다 뭔가 감으로 풀고 익숙한 거 체크하는데 그래도 항상 합격선이긴한데 풀면서 찝찝합이 너무 기분이 좋지 않아서 이쯤에서 개념을 다시 잡고 가야겠다.

26/08/05 수요일 - 1시간 00분

https://www.youtube.com/watch?v=zYTBA76aUCw&list=PLWtr7MRpQi5BZK0Riu7tf5gspu2nDTgUp&index=2

여기 무료 강의 발췌해서 필요한 부분만 2배속으로 읽으면서 넘겼다.
1,2과목도 점수 안나오면 바로 영상으로 공부하면 될 듯?

(수강신청이랑 다른 대외활동 회의들, 그리고 마감인 활동들 때문에 오늘은 공부를 많이 못했다.)

26/08/06 목요일 - 1시간 30분

이제 이 책에 마지막 문제들
47회 기출 문제만 남았다.

47회 기출 문제 : 39/50
1과목 7/10
2과목 7/10
3과목 25/30

오답하고 개념 조금 공부했다.

(구청 일이랑, 수강신청, 퇴근 후 대외활동 등 시험 막바지에 공부할 시간 부족이슈…)

그래도 자기전에 하나 후딱 풀었다

운이 좋았다. 즐겨찾기 한게 많다…
이거 아침에 헬스장에거 유산소 하면서 풀면 효율적일 거 같다. 하루 정도 가능하겠네…

26/08/07 금요일 - 1시간 30분

퇴근하고 바로 서울로 올라가야해서 서울가는 버스에서 멀미를 참으며 모고 1개 풀고 끝이다.
(서울에서 시험을 응시해서 근처 친구 자취방에서 자고 함께 시험보러 가기로했다. )

서울 친구집 도착 후 같이 저녁 먹으면서 같이 문제 모고 하나 풀었다 전날에는 서버가 터진다…

그래서 백업페이지 이용해야했다.

시험 당일 26/08/08

(지금 응시하고 나와서 친구 기다리면서 적는중이다.)

수험표 안챙겨갔지만 수험번호만 알고 가거나 직전에 수험번호 보여주셔서 딱히 필요는 없었다.
실물 신분증 정도?

컴싸도 편의점에서 급하게 사서 갔는데
감독관님이 여분도 주신다고 하셔서 이것도 어찌보면 필요없었다

50회 시험인데 어렵지 않았다. 3과목 조금 헷갈린 정도?
느낌은 1,2과목 하나씩 틀릴 것 같은 느낌…?
다 푸니까 30분정도 지나있었고 시계열 AR, MA 엄청 나와서 다 찍었다 그래서 3과목은 어느정도 틀리겠지만
합격하겠지 뭐~

이 글 읽는 모두 무난하게 합격하실겁니다!!

결론적으로 베이스가 있고 시간이
앖으면 요약본 구매하거나 개념요약 유튜브 3시간짜리 보고 기출 계속 풀면서 오답할 것 같다!

+

이번에 시험을 보고 나와서 사실 이렇게 50회 시험 난이도가 핫해지기 전까지는 어렵다는 생각을 못했습니다.

제 생각에 어렵지 않았다가 아니라 기준이 낮아서 그런 것 같습니다.

자격증 시험이 100점을 맞는 시험이 아니다 보니까

60점만 넘기자는 마인드인 전공자였어요. 공부 시간이 많지 않다보니,,,

1,2과목을 푸는데 한 7분안에 20문제가 풀렸고 1,2개? 틀리겠다는 생각이 들다보니

3과목을 들어갈때 여유롭게 들어간 것 같습니다.

물론 시계열 하나도 풀 줄 모르고 시계열 관련 문제가 너무 많아 당황했지만 1, 2과목 점수를 확보해두니 3과목은 그냥 모르면 잘 읽고 찍자고 생각하니 풀면서 부담이 드는 시험은 아니였습니다.

알고보니 비전공자 입장에서는 엄청 어려웠다는 평이 많았다…

경제금융용어 공부 584 : 콜시장

MKISOS — Fri, 7 Aug 2026 21:00:59 +0900

콜시장

은행들도 하루하루 자금이 남거나 부족한 상황이 자주 발생한다. 이때 금융기관들이 매우 짧은 기간 동안 서로 돈을 빌리고 빌려주는 시장이 바로 콜시장(Call Market)이다. 콜시장은 금융기관의 유동성을 조절하는 역할뿐 아니라 한국은행의 기준금리가 금융시장 전체로 전달되는 핵심 통로이기도 하다.

1. 한 줄 정의

콜시장은 금융기관들이 일시적인 자금 부족이나 여유를 해결하기 위해 초단기로 자금을 거래하는 시장이다.

2. 기본 개념

콜시장(Call Market)은 은행 등 금융기관들이 서로 매우 짧은 기간 동안 자금을 빌리거나 빌려주는 단기 금융시장이다.

은행은 고객으로부터 예금을 받고 기업과 개인에게 대출을 해주는 과정에서 하루에도 자금이 남거나 부족한 상황이 발생한다.

이러한 일시적인 자금 부족이나 여유를 해결하기 위해 금융기관들은 콜시장에서 서로 자금을 거래한다.

콜거래의 만기는 최대 90일까지 가능하지만 실제 거래의 대부분은 하루 동안만 돈을 빌리는 익일물(1일물) 거래가 차지한다.

또한 은행들은 지급준비금을 맞추기 위해 콜시장을 적극 활용하기 때문에 콜시장을 지준시장이라고도 부른다.

3. 왜 중요한가

콜시장은 금융기관들의 자금 흐름을 원활하게 만들어 금융시스템 전체의 안정성을 높인다.

만약 콜시장이 제대로 작동하지 않으면 일시적으로 자금이 부족한 은행이 다른 은행으로부터 돈을 빌리지 못해 금융시장 전체에 불안이 확산될 수 있다.

또한 한국은행이 결정한 기준금리는 가장 먼저 콜금리에 영향을 주고, 이후 예금금리와 대출금리, 채권금리 등으로 전달된다.

즉 콜시장은 통화정책이 실제 경제에 전달되는 첫 번째 단계라고 할 수 있다.

4. 쉽게 이해하는 예시

실생활 예시

친구들이 하루 동안만 서로 돈을 빌려주는 상황을 생각해보자.

오늘 급하게 돈이 필요한 친구는 하루만 빌리고 내일 갚는다.

콜시장은 이러한 거래가 금융기관 사이에서 이루어지는 시장이다.

은행 예시

A은행은 오늘 고객들의 예금 인출이 많아 자금이 부족해졌다.

반면 B은행은 오늘 예금이 많이 들어와 자금이 남는다.

이때 A은행은 콜시장에서 B은행으로부터 하루 동안 자금을 빌리고 다음 날 갚는다.

통화정책 예시

한국은행이 기준금리를 인상하면 가장 먼저 콜금리가 상승한다.

이후 은행들은 자금조달 비용이 높아져 예금금리와 대출금리도 점차 상승하게 된다.

5. 핵심 특징

5-1. 초단기 자금시장이다

콜시장은 금융기관들이 매우 짧은 기간 동안 자금을 거래하는 시장이다.

실제로는 하루 만기의 익일물 거래가 대부분을 차지한다.

5-2. 금융기관만 참여한다

일반 개인이나 기업은 콜시장에 직접 참여할 수 없다.

은행과 증권사 등 금융기관들이 일시적인 자금 부족을 해결하기 위해 이용한다.

5-3. 지급준비금 조절에 활용된다

은행들은 지급준비금을 맞추기 위해 콜시장에서 자금을 빌리거나 운용한다.

그래서 콜시장은 지준시장으로도 불린다.

5-4. 기준금리 전달의 출발점이다

한국은행의 기준금리 변화는 가장 먼저 콜금리에 반영된다.

이후 예금금리, 대출금리, 채권금리 등 금융시장 전반으로 영향을 미친다.

6. 관련 개념과의 차이

콜시장 vs 기준금리

콜시장

금융기관들이 실제로 자금을 거래하는 시장
콜금리가 거래를 통해 결정됨
초단기 자금시장

기준금리

한국은행이 결정하는 정책금리
통화정책의 기준이 되는 금리
콜금리에 직접 영향을 미침

즉 기준금리는 정책의 기준이고, 콜금리는 실제 시장에서 형성되는 금리이다.

콜시장 vs 예금시장

콜시장

금융기관끼리 거래
초단기 자금거래
유동성 조절 목적

예금시장

개인이나 기업이 은행에 돈을 맡김
장단기 예금상품 거래
자산 운용과 저축 목적

콜시장은 금융기관 사이의 시장이고, 예금시장은 일반 고객과 은행 사이의 시장이라는 차이가 있다.

콜금리 vs 대출금리

콜금리

금융기관 간 초단기 거래금리
기준금리의 영향을 가장 먼저 받음

대출금리

은행이 개인이나 기업에게 적용하는 금리
콜금리를 비롯한 여러 시장금리와 비용을 반영하여 결정됨

콜금리는 금융기관끼리의 거래금리이고, 대출금리는 일반 고객에게 적용되는 금리이다.

7. 경제적 의미

국가경제 관점

콜시장은 금융기관 간 자금 흐름을 원활하게 하여 금융시스템의 안정성을 유지하는 중요한 역할을 한다.

기업 관점

콜금리 변화는 기업대출 금리에도 영향을 미친다.

콜금리가 상승하면 기업의 자금조달 비용도 점차 증가할 가능성이 있다.

금융시장 관점

콜시장은 단기금융시장의 중심이며 한국은행의 통화정책이 금융시장 전체로 전달되는 핵심 경로이다.

한국은행은 공개시장운영 등을 통해 콜금리가 기준금리 수준에서 크게 벗어나지 않도록 관리한다.

투자 관점

투자자는 한국은행의 기준금리 발표 이후 콜금리의 움직임을 살펴볼 필요가 있다.

콜금리 변화는 채권시장, 주식시장, 예금금리, 대출금리 등 금융시장 전반의 방향을 예측하는 중요한 단서가 된다.

8. 정리

콜시장은 금융기관들이 일시적인 자금 부족이나 여유를 해결하기 위해 초단기로 자금을 거래하는 시장이다. 실제 거래는 하루 만기의 익일물이 대부분이며, 은행들은 지급준비금을 맞추기 위해 콜시장을 적극 활용한다. 또한 한국은행의 기준금리는 가장 먼저 콜금리에 영향을 미치고 이후 예금금리와 대출금리 등으로 전달된다. 따라서 콜시장은 금융기관의 유동성을 관리하고 통화정책이 실물경제로 전달되는 핵심 역할을 수행하는 중요한 금융시장이다.

경제금융용어 공부 583 : 코리보(KORIBOR)

MKISOS — Thu, 6 Aug 2026 21:00:27 +0900

코리보(KORIBOR)

은행들도 개인처럼 서로 돈을 빌리고 빌려주는 거래를 한다. 이때 은행 간 자금거래의 기준이 되는 금리가 바로 코리보(KORIBOR)이다. 우리나라 금융시장에서 단기 기준금리 역할을 수행하기 위해 도입되었으며, 다양한 금융상품의 기준금리로 활용될 수 있는 중요한 지표이다.

1. 한 줄 정의

코리보(KORIBOR)는 국내 은행들이 서로 단기 자금을 거래할 때 기준이 되는 금리이다.

2. 기본 개념

코리보(Korea Inter-Bank Offered Rate)는 국내 은행 간 단기 자금거래의 기준금리이다.

영국의 LIBOR처럼 국내에도 대표적인 은행 간 기준금리가 필요하다는 의견이 커지면서 2004년 7월 도입되었다.

코리보는 여러 은행이 제시한 금리를 바탕으로 산출된다. 참여 은행들이 제시한 금리 가운데 가장 높은 금리와 가장 낮은 금리를 일부 제외한 후 나머지 금리를 평균하여 최종 금리를 결정한다.

만기는 1주일부터 12개월까지 다양하며, 매 영업일 오전 11시에 공표된다.

3. 왜 중요한가

금융시장에서는 대출금리, 채권금리, 파생상품 가격 등을 정할 때 공통으로 사용할 기준금리가 필요하다.

코리보는 이러한 기준 역할을 수행하여 금융상품의 가격 결정 기준을 제공한다.

또한 금융기관들이 자금을 조달하거나 운용할 때 참고하는 중요한 금리이므로 금융시장 전체의 효율성과 투명성을 높이는 데 기여한다.

4. 쉽게 이해하는 예시

실생활 예시

아파트 가격을 판단할 때 실거래가가 기준이 되는 것처럼, 은행들도 서로 돈을 빌릴 때 기준이 되는 금리가 필요하다.

코리보는 은행 간 거래에서 이러한 기준 역할을 한다.

금융시장 예시

A은행이 하루 동안 필요한 자금을 B은행으로부터 빌린다고 가정해보자.

이때 두 은행은 코리보를 참고하여 실제 거래금리를 결정할 수 있다.

투자 예시

변동금리 채권(FRN)이 '코리보 + 1%'의 금리 조건으로 발행되었다고 가정해보자.

코리보가 상승하면 투자자가 받는 이자도 함께 증가하고, 반대로 코리보가 하락하면 지급되는 이자도 감소한다.

5. 핵심 특징

5-1. 국내 은행 간 기준금리이다

국내 은행들이 단기 자금을 거래할 때 참고하는 대표적인 기준금리이다.

5-2. 여러 은행의 금리를 평균하여 산출한다

참여 은행들이 제시한 금리 가운데 최고와 최저 일부를 제외한 후 평균을 계산하여 객관성을 높인다.

5-3. 다양한 금융상품의 기준금리로 활용된다

변동금리대출, 변동금리채권(FRN), 이자율스왑 등 여러 금융상품의 기준금리로 사용할 수 있다.

5-4. 현재 활용 범위는 제한적이다

은행 간 무담보 단기거래 규모가 크지 않아 일부 은행의 변동금리대출이나 내부 이전금리 등 제한적인 분야에서 활용되고 있다.

6. 관련 개념과의 차이

코리보(KORIBOR) vs LIBOR

코리보(KORIBOR)

국내 은행 간 기준금리
원화 단기자금 거래 기준
한국 금융시장 중심

LIBOR

영국 런던 은행 간 기준금리
국제 금융시장에서 활용
다양한 통화의 기준금리 역할 수행

즉, 코리보는 우리나라 금융시장을 위한 LIBOR와 같은 개념이라고 이해하면 된다.

코리보(KORIBOR) vs COFIX

코리보(KORIBOR)

은행 간 자금거래 기준금리
단기 금융시장 중심
은행들이 제시하는 금리를 기반으로 산출

COFIX(자금조달비용지수)

은행의 실제 자금조달 비용을 반영
주택담보대출 변동금리 기준으로 많이 활용
예금과 금융채 등 실제 조달비용을 기반으로 산출

즉 코리보는 은행 간 거래금리이고, COFIX는 은행이 실제로 돈을 조달하는 비용을 나타내는 지표이다.

7. 경제적 의미

국가경제 관점

코리보는 금융시장 참여자들이 공통으로 활용할 수 있는 기준금리를 제공하여 금융시장의 효율성과 신뢰도를 높이는 역할을 한다.

기업 관점

기업은 코리보를 기준으로 발행되는 변동금리 채권이나 금융상품을 통해 자금을 조달할 수 있다.

금융시장 관점

코리보는 단기금융시장과 채권시장, 파생상품시장을 연결하는 기준금리 역할을 수행한다.

향후 활용 범위가 확대된다면 금융시장 간 연계성도 더욱 높아질 수 있다.

투자 관점

투자자는 변동금리 상품을 선택할 때 기준금리가 코리보인지 COFIX인지 확인할 필요가 있다.

기준금리에 따라 향후 이자 부담이나 투자수익이 달라질 수 있기 때문이다.

8. 정리

코리보(KORIBOR)는 국내 은행들이 서로 단기 자금을 거래할 때 기준이 되는 금리이다. 2004년 도입되어 우리나라 금융시장의 대표적인 단기 기준금리 역할을 수행하고 있으며, 변동금리대출과 채권, 파생상품 등의 가격 결정에 활용될 수 있다. 현재 활용 범위는 제한적이지만 금융시장의 기준금리로서 중요한 의미를 가지며, 금융시장 발전과 함께 활용도가 더욱 확대될 것으로 기대된다.

경제금융용어 공부 582 : 컨트리리스크

MKISOS — Wed, 5 Aug 2026 21:00:34 +0900

컨트리리스크

해외투자는 국내투자보다 더 많은 변수를 고려해야 한다. 기업이나 채권의 상태가 양호하더라도 투자 대상 국가의 정책이 갑자기 바뀌거나 전쟁과 외환위기가 발생하면 큰 손실을 입을 수 있기 때문이다. 이처럼 특정 국가의 정치·경제·제도 변화로 인해 투자자가 손실을 볼 가능성을 컨트리리스크라고 한다.

1. 한 줄 정의

컨트리리스크는 특정 국가의 정책 변화나 정치·경제적 불안으로 해외 투자자가 손실을 입을 가능성을 의미한다.

2. 기본 개념

컨트리리스크(Country Risk)는 해외 투자자가 특정 국가에 투자할 때 그 나라의 정부 정책, 정치 상황, 외환 사정, 제도 변화 등으로 인해 손실이나 불이익을 받을 가능성을 말한다.

해외투자에서는 단순히 투자 대상 기업의 실적이나 신용도만 보는 것으로 충분하지 않다.

기업이 정상적으로 돈을 갚을 능력이 있더라도 해당 국가가 외환 송금을 제한하거나 자산을 강제로 몰수하면 투자자는 원금과 수익을 회수하지 못할 수 있다.

따라서 컨트리리스크는 국가 전체의 투자환경과 대외신인도를 평가하는 개념이라고 할 수 있다.

3. 왜 중요한가

해외투자는 국가 간 제도와 통화가 다르기 때문에 국내투자보다 위험요인이 많다.

투자 대상 국가의 정부가 세금 제도를 갑자기 바꾸거나 외환시장 거래를 제한하면 기업의 수익성과 투자자의 자금 회수가 모두 어려워질 수 있다.

또한 전쟁, 혁명, 쿠데타, 국가부도 같은 상황이 발생하면 투자자산의 가치가 급격히 하락할 수 있다.

따라서 해외투자에서는 기업 분석뿐 아니라 해당 국가의 정치·경제적 안정성까지 함께 살펴봐야 한다.

4. 쉽게 이해하는 예시

실생활 예시

해외에서 작은 가게를 운영하기 위해 1억 원을 투자했다고 가정해보자.

사업은 잘되고 있지만 해당 국가 정부가 외국인의 송금을 제한해 수익금을 한국으로 가져올 수 없게 되었다면 투자자는 손실이나 불편을 겪게 된다.

이것이 컨트리리스크의 한 사례이다.

기업 예시

한국 기업이 해외에 공장을 세웠는데 현지 정부가 갑자기 외국 기업에 높은 세금을 부과하거나 공장을 국유화한다고 가정해보자.

기업의 실적과 상관없이 정부 정책 때문에 손실이 발생한 것이므로 컨트리리스크에 해당한다.

채권 투자 예시

투자자가 외국 정부나 기업이 발행한 채권을 보유하고 있는데 해당 국가가 외화 송금을 중단했다고 가정해보자.

채권 발행자가 원리금을 갚을 의사와 능력이 있어도 투자자는 실제 돈을 받지 못할 수 있다.

전쟁 예시

전쟁이나 내전이 발생하면 공장, 건물, 사회기반시설이 파괴될 수 있다.

이 과정에서 투자자산의 가치가 급락하거나 완전히 사라질 수도 있다.

5. 핵심 특징

5-1. 국가 전체의 위험을 평가한다

컨트리리스크는 개별 기업의 문제가 아니라 국가의 정치, 경제, 법률, 외환제도 전반에서 발생하는 위험을 다룬다.

5-2. 정부의 정책 변화가 큰 영향을 준다

세금 인상, 외환거래 제한, 송금 규제, 자산 몰수 등 정부의 결정이 투자자의 손익에 직접 영향을 줄 수 있다.

5-3. 예측하기 어려운 사건도 포함된다

전쟁, 혁명, 쿠데타, 국가부도처럼 갑작스럽게 발생하는 정치·사회적 사건도 컨트리리스크에 포함된다.

5-4. 해외투자 수익률에 반영된다

컨트리리스크가 높은 국가는 투자 위험이 크기 때문에 투자자들이 더 높은 수익률을 요구하는 경우가 많다.

그 결과 해당 국가의 채권금리와 기업의 자금조달 비용이 높아질 수 있다.

6. 관련 개념과의 차이

컨트리리스크 vs 신용위험

컨트리리스크

국가의 정책이나 정치·경제적 불안에서 발생함
외환 통제, 송금 제한, 자산 몰수 등이 포함됨
국가 전체의 환경이 원인임

신용위험

채무자가 원금과 이자를 갚지 못할 위험임
개인, 기업, 정부의 상환 능력이 핵심임
거래 상대방 자체의 재무상태가 원인임

즉 신용위험은 돈을 빌린 주체가 갚지 못하는 위험이고, 컨트리리스크는 국가의 제도와 상황 때문에 돈을 받지 못할 수 있는 위험이다.

컨트리리스크 vs 환위험

컨트리리스크

정부 정책과 정치·경제 불안에서 발생함
투자금 회수 자체가 어려워질 수 있음

환위험

환율 변동으로 투자수익이 달라지는 위험임
자금 회수는 가능하지만 환산가치가 변함

환율 하락으로 손실을 보면 환위험이고, 정부가 환전을 금지해 돈을 가져오지 못하면 컨트리리스크에 가깝다.

컨트리리스크 vs 국가신용등급

컨트리리스크

특정 국가에 투자할 때 발생할 수 있는 전체 위험을 의미함
정치, 경제, 제도, 외환 상황 등을 폭넓게 포함함

국가신용등급

국가의 채무상환 능력을 등급으로 평가한 지표임
주로 국가부도 가능성과 신용도를 나타냄

국가신용등급은 컨트리리스크를 판단하는 중요한 자료이지만, 두 개념이 완전히 같은 것은 아니다.

7. 경제적 의미

국가경제 관점

컨트리리스크가 높아지면 외국인 투자자들이 자금을 회수하거나 신규투자를 줄일 수 있다.

그 결과 환율이 상승하고 외환보유액이 감소하며 금융시장이 불안해질 가능성이 있다.

기업 관점

해당 국가의 기업은 해외에서 자금을 빌릴 때 더 높은 금리를 부담할 수 있다.

또한 외국 기업의 투자와 기술 이전이 줄어들어 경제성장이 둔화될 수 있다.

금융시장 관점

정치적 불안이나 정부 정책 변화는 주식, 채권, 외환시장에 동시에 영향을 줄 수 있다.

컨트리리스크가 확대되면 국가 위험 프리미엄이 올라가고 자산가격 변동성도 커진다.

투자 관점

해외 투자자는 기업의 실적뿐 아니라 정치 안정성, 외환보유액, 국가부채, 자본통제 가능성, 법적 보호 수준을 함께 확인해야 한다.

수익률이 높다는 이유만으로 위험 국가에 투자하면 예상하지 못한 손실을 볼 수 있다.

8. 정리

컨트리리스크는 특정 국가의 정책 변화, 정치적 불안, 외환 통제, 전쟁 등으로 해외 투자자가 손실을 입을 가능성을 의미한다. 이는 개별 기업의 상환 능력을 평가하는 신용위험과 달리 국가 전체의 제도와 환경에서 발생한다. 컨트리리스크가 높아지면 외국인 자금이 빠져나가고 환율과 금융시장이 불안해질 수 있다. 따라서 해외투자에서는 기업 분석과 함께 투자 대상 국가의 정치·경제적 안정성도 반드시 살펴봐야 한다.

[UNIKER] CampusLog, 중간 데모를 앞두고 제품을 다듬고 실제 크루들 앞에서 시연하다

MKISOS — Wed, 5 Aug 2026 05:52:07 +0900

이번 주 팀 핏줄은 CampusLog의 새로운 기능을 무작정 늘리기보다, 이미 구현한 기능이 하나의 서비스처럼 자연스럽게 연결되도록 화면과 사용자 경험을 다듬는 데 집중했다.

나의 활동과 AI 분석 화면을 정리하고, 추천 결과와 추천 기록의 정보 구조를 통일했다. 여러 기기와 탭에서 같은 계정을 사용할 때 발생하던 세션 문제, 긴 경험을 AI로 분석했을 때 발생하던 저장 오류 등 실제 사용 과정에서 발견한 문제도 수정했다.

그리고 8월 2일에는 서울에서 열린 UNIKER 중간 데모데이에 참여해 CampusLog를 실제 크루들과 멘토님들 앞에서 발표하고 직접 시연했다.

이번 글에서는 7월 27일부터 8월 2일까지 진행한 CampusLog 개발 과정과 중간 데모데이에서 받은 현장 피드백을 함께 정리해보려고 한다.

중간 데모데이 글 :

https://mkisos.tistory.com/entry/uniker10

[UNIKER] AI 서비스를 직접 시연하다, 팀 핏줄 CampusLog 중간 데모데이 후기 (“가장 안전했던 선택이

문서와 코드 안에서만 보던 서비스를 다른 사람들 앞에서 직접 시연하는 순간, 프로젝트는 전혀 다르게 보이기 시작한다. 2026년 8월 2일, 서울 역삼역 인근 센터필드 7층에서 커널아카데미 대학

mkisos.tistory.com

기능을 더하는 단계에서 제품을 정리하는 단계로

CampusLog에는 이미 상당히 많은 기능이 구현되어 있었다.

사용자는 이메일이나 Google 계정으로 로그인하고, 진행 중인 활동과 이미 끝난 경험을 기록할 수 있다. 저장한 경험은 AI로 분석할 수 있으며, 자기소개서·면접·JD 분석 등의 목적에 맞는 경험을 추천받을 수도 있다.

여기에 활동별 날짜 기록, AI 보완 질문, 추천 경험 Top 3, 답변 초안, 이미지 기반 추천까지 추가되면서 기능적인 범위는 빠르게 확장되었다.

하지만 기능이 많아질수록 새로운 문제가 생겼다.

화면마다 다른 스타일이 적용되거나, 같은 종류의 정보가 서로 다른 구조로 나타났다. 사용자가 목록과 상세 화면, AI 분석 결과와 추천 기록 사이를 오갈 때 화면의 기준점이 조금씩 달라지는 문제도 있었다.

이번 주에는 기능 추가보다 다음 질문에 집중했다.

CampusLog의 여러 기능이 하나의 제품 안에 있다는 느낌을 어떻게 만들 수 있을까?

이를 위해 화면 전반의 색상, 표면, 간격, 제목 위치, 목록과 상세 구조를 하나의 디자인 기준으로 다시 정리했다.

CampusLog 전체를 하나의 Liquid Glass 디자인으로 통일하기

이번 주 디자인 작업의 중심은 CampusLog 전체 화면을 쿨 뉴트럴 Liquid Glass 스타일로 통일하는 것이었다.

기존 화면에는 웜 화이트, 크림색, 회색, 투명한 카드와 불투명한 카드가 섞여 있었다. 각각의 화면만 보면 문제가 크지 않았지만, 메뉴를 이동할 때마다 서로 다른 서비스처럼 보일 수 있었다.

그래서 공개 첫 화면과 인증 화면부터 오늘의 기록, 나의 활동, AI 추천, 추천 기록, 경험 작성·상세·분석 화면까지 공통 디자인 토큰을 적용했다.

기능을 조작하는 사이드바, 팝업, 메뉴와 오버레이에는 반투명 Glass 표현을 사용하고, 긴 내용을 읽거나 작성하는 화면은 가독성을 위해 비교적 불투명한 표면을 유지했다.

또한 화면 안에 여러 겹의 흰색 카드가 중첩되어 보이던 구조를 줄였다.

하나의 큰 표면 안에서는 메타 정보, 본문, 근거, 답변 영역을 다시 별도 카드로 감싸지 않고 구분선과 간격으로 연결했다. 이를 통해 화면의 정보량은 유지하면서도 훨씬 단순하게 읽히도록 정리했다.

‘나의 활동’을 목록과 상세가 연결된 작업 공간으로

CampusLog에서 가장 자주 사용하게 될 화면 중 하나는 나의 활동이다.

사용자는 이곳에서 진행 중인 활동과 완료된 경험을 찾고, 내용을 확인하고, AI 분석을 실행한다.

이번 주에는 나의 활동의 페이지 제목과 설명을 목록 패널 밖으로 분리했다. 목록 안에는 전체 활동이라는 별도 제목과 활동 개수, 검색 기능을 배치했다.

왼쪽 목록에서 경험을 선택하면 오른쪽에서 상세 내용을 확인할 수 있는 Split View 구조는 유지하되, 목록과 상세가 동일한 재질과 간격을 사용하도록 조정했다.

선택된 활동도 별도의 흰색 카드처럼 떠 보이지 않도록 바꾸었다. 대신 옅은 차콜 배경과 왼쪽 인디케이터를 이용해 현재 선택된 항목을 구분했다.

스크롤바 역시 평소에는 화면을 방해하지 않도록 숨기고, 실제로 사용자가 스크롤하는 동안에만 표시하도록 수정했다.

데스크톱뿐 아니라 390px 모바일 화면에서도 목록, 상세, AI 분석 결과가 잘리지 않도록 반복해서 확인했다. 7월 27일 작업에서는 관련 구조 테스트와 lint, TypeScript 검사, production build까지 통과했다.

활동과 추천 기록을 빠르게 다시 찾는 즐겨찾기

경험과 추천 기록이 많아지면 사용자는 자주 확인해야 하는 항목을 다시 찾기 어려워질 수 있다.

이를 보완하기 위해 나의 활동과 추천 기록에 즐겨찾기 기능을 추가했다.

사용자가 별을 누르면 해당 활동이나 추천 기록이 목록 위쪽의 즐겨찾기 영역으로 이동한다. 다시 별을 누르면 원래 목록으로 돌아간다.

처음에는 Pin 아이콘을 사용했지만, 사용자가 더 직관적으로 이해할 수 있도록 노란색 별 아이콘으로 변경했다.

즐겨찾기 버튼을 눌렀을 때 상세 화면이 함께 열리지 않도록 항목 선택과 별 조작 영역을 분리했고, 키보드 사용자도 기능을 이용할 수 있도록 접근성 속성과 44px 조작 영역을 유지했다.

진행 중인 활동도 완료 경험과 구분되는 저장 키를 사용해 즐겨찾기에 추가할 수 있도록 확장했다.

화면이 바뀌어도 기준점이 흔들리지 않도록

작은 차이지만 계속 서비스를 사용하면 불편하게 느껴지는 부분도 수정했다.

기존에는 오늘의 기록, 나의 활동, AI 추천, 추천 기록, 활동 추가, 경험 추가 화면마다 제목과 Breadcrumb의 시작 위치가 조금씩 달랐다.

페이지를 이동할 때마다 제목이 미세하게 좌우로 움직였고, 화면에 스크롤바가 있는지에 따라서도 콘텐츠 폭이 달라졌다.

이번 주에는 상위 화면과 하위 화면이 동일한 최대 폭과 여백을 사용하도록 공통 내비게이션 레일을 적용했다.

스크롤바가 나타날 때 화면 폭이 달라지지 않도록 모든 제품 화면에 동일한 스크롤바 공간도 예약했다. 그 결과 메뉴를 이동해도 Breadcrumb와 제목이 같은 위치에 유지되도록 만들었다.

오늘의 기록으로 이동할 때 이전 메뉴와 새 메뉴가 동시에 활성화되어 보이던 문제와 페이지가 부드럽게 미끄러지며 이동하던 현상도 함께 수정했다.

사용자가 메뉴를 누르면 목적지 한 곳만 즉시 활성화되고, 새 화면의 상단에 바로 정착하도록 정리했다.

AI 분석과 추천 결과의 정보 구조 통일

AI 분석 결과와 추천 기록은 모두 AI가 생성한 결과를 읽는 화면이지만, 이전에는 제목과 생성일, 본문 카드의 위계가 서로 달랐다.

이번 주에는 두 화면을 같은 서비스의 결과 화면처럼 보이도록 통일했다.

AI 분석 화면은 다음 순서로 정보를 보여준다.

AI 경험 분석 결과
→ 분석 생성일
→ 대표 제목
→ 요약
→ STAR
→ 주요 성과
→ 부족 정보
→ 키워드

정상적으로 분석된 상태에서 반복적으로 나타나던 안내 문구와 하단의 중복 생성일은 제거했다. 경험 원본이 수정되었거나 다시 분석해야 하는 경우처럼 실제 행동이 필요한 안내만 조건에 따라 표시하도록 했다.

추천 결과 화면도 저장된 질문이나 문항을 대표 제목으로 사용하도록 변경했다.

기존에는 추천된 경험의 이름, 기간, 역할, 사용자가 입력한 질문이 여러 위치에서 반복되었다. 이제 질문을 중심으로 활용 목적과 요구사항 분석, 추천 경험 Top 3, 추천 근거, 답변 생성 흐름이 이어지도록 정리했다.

다양한 전공과 지원 상황을 고려한 추천 예시

CampusLog의 AI 추천 화면에는 사용자가 입력 방식을 이해할 수 있도록 예시 질문이 제공된다.

기존 예시는 개발자 경험과 특정 상황에 치우친 부분이 있었다.

이번 주에는 면접, 자기소개서, JD 분석, 기타 목적마다 대표 질문을 6개씩 구성했다.

면접과 자기소개서 예시는 다음과 같은 공통 역량을 중심으로 정리했다.

자신의 역할과 기여
문제 해결
협업
주도성
성과
실패와 성장

기타 목적에는 포트폴리오, 이력서, 1분 자기소개, 대외활동과 인턴 지원, 발표 준비, 전공과 직무 연결 등의 상황을 포함했다.

JD 분석에는 단순한 짧은 문장뿐 아니라 실제 채용공고에 가까운 형태의 예시도 추가했다. 플랫폼·결제 서버와 커머스 백엔드 직무의 역할, 지원 자격, 기술 스택과 면접 관점이 포함된 샘플을 선택하면 전체 내용이 입력되도록 구성했다.

다양한 전공과 직무를 가진 대학생이 CampusLog의 사용법을 더 쉽게 이해하도록 만드는 작업이었다.

실제 사용 과정에서 발견한 세션과 동시 작업 문제

중간 데모를 준비하면서 여러 기기와 탭에서 같은 테스트 계정을 사용했다.

이 과정에서 refresh token 갱신 오류와 데이터 조회 실패가 연속으로 발생하는 문제가 발견되었다.

한 기기에서 로그아웃하면 다른 기기의 세션까지 영향을 받거나, 오래된 화면에 남아 있던 경험 데이터로 AI 분석을 요청하면서 최신 DB 데이터와 충돌할 가능성도 있었다.

이를 해결하기 위해 로그아웃 범위를 현재 기기의 세션으로 제한하고, 브라우저에서 사용하는 Supabase Client를 하나의 인스턴스로 관리하도록 변경했다.

AI 분석을 실행하기 직전에는 화면에 남아 있는 데이터만 믿지 않고 DB에서 최신 경험과 보완 답변을 다시 조회하도록 했다.

같은 경험을 여러 곳에서 동시에 수정하는 경우에는 한쪽 변경이 조용히 덮어써지지 않도록 updated_at을 기준으로 충돌을 감지했다.

분석 결과 저장 역시 경험별 atomic upsert 방식을 사용해 동일 경험의 분석이 중복 저장되거나 충돌하지 않도록 수정했다.

상세한 역할을 입력했더니 AI 분석이 실패한 문제

실제 데이터로 AI 분석을 테스트하면서 예상하지 못한 오류도 발견했다.

경험 작성 화면에서는 역할을 비교적 길게 입력할 수 있었지만, AI API에서는 역할 길이를 200자로 제한하고 있었다.

테스트 데이터 중 역할 내용이 220자인 경험을 분석하자 OpenAI를 호출하기도 전에 400 BAD_REQUEST가 발생했다.

문제는 화면의 입력 기준과 API의 검증 기준이 서로 달랐다는 점이었다.

이를 해결하기 위해 경험 작성 화면과 AI 분석, 추천, 답변 초안, 보완 질문 API에서 사용하는 역할 입력 한도를 1,000자로 통일했다.

수정 이후에는 동일한 경험으로 AI 분석을 다시 실행해 API 응답, SSE 완료, Supabase 저장과 결과 화면 표시까지 확인했다.

분석 결과 저장 과정에서는 related_links 객체 배열이 [object Object]로 전달되어 PostgreSQL JSON 오류가 발생하는 문제도 이어서 발견했다. 해당 값은 JSON 문자열로 비교하도록 수정했다.

긴 경험을 분석한 뒤 결과가 저장되지 않던 문제

8월 2일에는 긴 경험 원문을 AI로 분석한 뒤 결과 저장 단계에서 400 오류가 발생했다.

원인을 확인해보니 AI 분석 결과를 저장할 때 경험의 제목, 역할, 내용, 성과, 관련 링크 전체를 Supabase URL의 비교 조건으로 전달하고 있었다.

경험 내용이 길어지자 요청 URL이 약 26,000자를 넘어갔고, 결국 결과를 저장할 수 없었다.

이를 해결하기 위해 경험 원문 전체를 비교하는 대신 경험 ID와 updated_at만 사용해 분석 도중 경험이 변경되었는지 확인하도록 수정했다.

경험 내용이 길어도 URL 길이는 일정하게 유지되며, 분석 도중 원본이 수정되는 문제도 계속 감지할 수 있다.

입력 제한도 화면과 네 개의 AI API에서 공통으로 관리하도록 변경했다.

현재 활동 내용은 최대 8,000자, 성과는 최대 4,000자까지 입력할 수 있다. 제한의 90%에 도달하기 전에는 글자 수를 표시하지 않고, 입력량이 많아졌을 때만 카운터와 안내를 보여준다.

제한을 넘긴 내용을 자동으로 잘라버리지 않고, 사용자가 얼마나 줄여야 하는지 알려준 뒤 해당 입력란으로 초점을 이동하도록 했다.

중간 데모 제출 문서와 시연 흐름 준비

중간 데모를 앞두고 코드뿐 아니라 현재 구현 상태를 설명할 문서도 다시 정리했다.

제출용 문서는 다음 세 가지로 구성했다.

요구사항 명세서
WBS 및 마일스톤
시퀀스 플로우

요구사항 명세서에는 CampusLog가 해결하려는 문제와 핵심 사용자, 기능 요구사항, 현재 구현 상태를 정리했다.

WBS에는 문제 정의부터 경험 CRUD, AI 분석·추천, 인증과 Supabase DB, UI 고도화까지 어떤 순서로 개발했는지 기록했다.

시퀀스 플로우에는 사용자의 조작이 CampusLog 화면과 Repository, Supabase, Next.js API Route, OpenAI Responses API로 어떻게 연결되는지를 정리했다.

중간 데모 시점의 대표 흐름은 다음과 같았다.

로그인
→ 경험 기록
→ AI 경험 분석
→ 부족한 정보 보완
→ 자기소개서·면접·JD 입력
→ 적합한 경험 Top 3 추천
→ 목적에 맞는 답변 생성
→ 추천 기록에서 다시 확인

실제 발표에서 오류가 발생할 가능성에 대비해 미리 생성한 분석 결과와 추천 화면도 준비했다. 요구사항 문서에도 중간 데모 이후 최우선 과제로 데모 계정과 샘플 데이터 준비, 대표 시나리오 리허설, 사전 생성 결과와 대체 설명 순서를 명시했다.

8월 2일, UNIKER 중간 데모데이

8월 2일에는 서울 역삼역 인근 센터필드 7층에서 UNIKER 1기 중간 데모데이가 진행되었다.

오후 2시부터 레크리에이션과 팀별 발표, 멘토 피드백이 이어졌고, 공식 발표가 끝난 뒤에는 식사와 네트워킹도 진행되었다. 각 팀은 약 5~10분 동안 자신들이 개발한 AI 서비스를 소개하고, 실제 화면을 보여준 뒤 공개 피드백을 받았다.

웹캠을 활용한 자세 관리 서비스, AI 대화 친구, 연구 주제와 교수 매칭 서비스, 번아웃 예방 스케줄러, 패션 스타일링, 대학생활 AI 비서 등 다양한 프로젝트를 볼 수 있었다.

같은 AI 도구를 사용하더라도 팀마다 문제를 정의하는 방식과 제품의 형태는 전혀 달랐다.

멘토님들은 기능이 얼마나 많은지보다 다음과 같은 내용을 중심으로 질문했다.

누구의 어떤 문제를 해결하는가
사용자가 계속 이용할 이유가 있는가
일반적인 생성형 AI와 무엇이 다른가
서비스의 가설을 어떤 지표로 검증할 것인가

다른 팀의 발표와 피드백을 들으며 CampusLog 역시 기능의 완성도뿐 아니라 실제 사용자 문제를 해결했다는 증거가 필요하다는 점을 다시 느꼈다.

실제 크루들 앞에서 CampusLog 발표하기

우리 팀 핏줄은 대학생의 경험을 기록하고, 필요한 순간에 다시 활용할 수 있도록 돕는 AI 경험 관리 서비스 CampusLog를 발표했다.

CampusLog는 팀원들이 실제로 겪었던 불편함에서 출발했다.

대외활동, 프로젝트, 학교 프로그램, 인턴과 채용에 지원할 때 자기소개서와 면접을 준비해야 하지만, 막상 질문을 받으면 어떤 경험을 활용해야 할지 바로 떠오르지 않는 경우가 많다.

블로그, Notion, GitHub, 갤러리와 AI 대화 기록 등 여러 공간에 기록이 남아 있더라도 지원 시점에는 다시 모든 공간을 뒤져야 한다.

저희는 이 문제를 다음 흐름으로 해결하려고 했다.

경험 기록
→ AI 경험 분석
→ 목적에 맞는 경험 추천
→ 자기소개서·면접·지원에 활용

발표에서는 설명에만 머무르지 않고 실제 배포된 CampusLog를 직접 조작했다.

이메일과 Google 계정으로 로그인한 뒤 새로운 경험을 등록하고, AI 분석을 실행했다.

AI는 경험을 요약하고 STAR 구조와 주요 성과를 정리한다. 기록만으로 판단하기 어려운 내용은 역할 범위, 수치화된 성과, 문제 해결 과정 등의 부족 정보로 구분해 다시 질문한다.

사용자가 기억하거나 확인할 수 있는 내용만 답변하면 그 정보가 이후 추천과 답변 생성에 반영된다.

이미지와 JD를 활용한 경험 추천 시연

CampusLog의 메인 기능인 AI 경험 추천도 함께 시연했다.

사용자는 면접, 자기소개서, JD 분석, 기타 중 활용 목적을 선택하고 실제 질문이나 채용공고 내용을 입력할 수 있다.

직접 입력하기 번거로운 경우에는 자기소개서 문항이나 채용공고를 캡처한 이미지를 첨부할 수도 있다.

AI는 사용자의 저장 경험과 분석 결과, 부족 정보에 대한 보완 답변을 살펴보고 가장 적합한 경험을 최대 세 개까지 추천한다.

추천 결과에는 단순한 경험 제목만 나타나지 않는다.

해당 경험을 추천한 이유
질문과 연결되는 역할과 성과
원본 기록에서 확인되는 직접 근거
현재 기록에서 부족한 부분
과장해서 표현하면 안 되는 내용
자기소개서나 면접에서 강조할 방향

자기소개서 목적이라면 요구 글자 수에 맞는 초안을 생성할 수 있다.

JD 분석에서는 채용공고가 요구하는 역량과 사용자의 경험을 비교해 충족, 부분 충족, 미충족 여부와 앞으로 보완할 부분을 보여준다.

실전 시연 중 발생한 AI 분석 오류

아무리 미리 준비해도 실전 데모에서는 예상하지 못한 문제가 발생한다.

CampusLog 발표 중 AI 분석을 요청했을 때 일시적인 오류가 발생했다.

다행히 사전에 준비한 분석 결과 화면이 있었기 때문에 바로 화면을 전환해 다음 기능 설명을 이어갈 수 있었다.

발표 흐름 자체는 중단되지 않았지만, 실제 시연에서는 기능 구현뿐 아니라 실패했을 때 어떤 화면과 설명으로 넘어갈지를 준비해야 한다는 점을 체감했다.

발표가 끝난 직후에는 오류 코드를 확인하고 원인을 추적했다.

쉬는 시간 동안 문제를 수정한 뒤 다시 배포해 서비스가 정상적으로 동작하는 것도 확인했다.

최종 발표에서는 같은 상황이 반복되지 않도록 단순히 한 번 기능을 눌러보는 수준이 아니라 실제 발표 순서 그대로 여러 차례 시뮬레이션해야겠다고 생각했다.

“기다리는 시간을 또 다른 경험으로 연결해보세요”

발표가 끝난 뒤 멘토님들로부터 공개 피드백을 받았다.

이전 멘토링 때보다 서비스가 많이 발전했고, 팀원들이 실제로 경험한 문제에서 출발했다는 점을 긍정적으로 평가해주셨다.

특히 AI가 경험을 한 번 분석하고 끝나는 것이 아니라, 부족한 정보를 다시 질문하고 사용자가 답변한 내용을 다음 분석과 추천에 반영하는 UX를 좋게 봐주셨다.

가장 구체적인 피드백은 AI 응답을 기다리는 시간에 관한 것이었다.

현재는 분석이나 추천을 요청하면 사용자가 결과가 나올 때까지 해당 화면에서 기다려야 한다.

멘토님께서는 AI 작업을 백그라운드에서 진행하고, 화면에는 프로그레스 바나 현재 처리 단계를 보여주는 방식을 제안해주셨다.

사용자가 기다리는 동안에는 다음 행동으로 연결할 수도 있다.

“분석이 진행되는 동안 다른 경험을 기록해보시겠어요?”

“오늘의 기록을 먼저 작성해보세요.”

작업이 끝났을 때 별도의 알림을 제공하면 사용자는 로딩 화면만 바라보지 않고 CampusLog 안에서 다른 일을 계속할 수 있다.

AI 응답 시간을 기술적으로 줄이는 것도 중요하지만, 사용자가 느끼는 대기 시간을 어떻게 설계할지도 중요한 문제라는 것을 배웠다.

폼을 채우는 서비스에서 자료를 넘기는 서비스로

경험을 입력하는 방식에 대한 피드백도 받았다.

현재 CampusLog는 제목, 기간, 역할, 활동 내용과 성과를 정해진 폼에 맞춰 입력한다.

그러나 사용자가 이미 가지고 있는 문서나 활동 자료가 있다면 이를 다시 하나씩 옮겨 적는 과정도 부담이 될 수 있다.

멘토님께서는 기존 자기소개서, 프로젝트 자료, 활동 기록, 이미지와 문서를 올리면 AI가 CampusLog의 경험 형식에 맞게 자동으로 정리해주는 방식을 고려해보라고 조언해주셨다.

현재 질문과 JD 이미지를 분석하는 기능은 구현되어 있지만, 앞으로는 경험을 등록하는 단계에서도 멀티모달 입력을 활용할 수 있다.

사용자가 완성된 경험을 처음부터 작성하는 대신, 이미 가지고 있는 기록을 전달하면 AI가 초안을 만들고 사용자가 검토하는 방식이다.

이는 CampusLog의 입력 부담을 줄이는 중요한 확장 방향이 될 수 있다.

자기소개서를 대신 작성하는 서비스에서 끝나지 않기

생성형 AI와 취업 준비에 관한 피드백도 기억에 남았다.

최근에는 많은 지원자가 AI를 활용해 자기소개서를 작성한다.

하지만 AI가 만들어준 문장을 그대로 제출해 서류에 합격하더라도, 면접에서 자신의 경험을 제대로 설명하지 못할 수 있다.

CampusLog가 보기 좋은 자기소개서를 대신 작성하는 서비스에서 끝난다면 사용자가 자신의 경험을 실제로 이해하도록 돕지 못할 수도 있다.

멘토님께서는 자기소개서 이후의 면접 과정까지 연결해보면 좋겠다는 의견을 주셨다.

예를 들어 추천된 경험을 기준으로 다음 기능을 연결할 수 있다.

예상 면접 질문 생성
경험의 핵심 행동과 성과 다시 확인
부족한 근거를 묻는 꼬리 질문
사용자가 직접 답변한 뒤 AI 피드백 받기
자신의 언어로 경험을 설명하는 연습

CampusLog가 지향해야 할 방향은 AI가 사용자의 경험을 새로 만들어주는 것이 아니다.

사용자가 이미 가지고 있는 경험을 더 정확하게 기억하고, 자신의 언어로 설명하도록 돕는 것

이번 피드백을 통해 이 가치가 더욱 분명해졌다.

‘오늘의 기록’을 더 가볍고 꾸준한 기능으로

현재 CampusLog에는 진행 중인 활동을 등록하고 날짜별로 한 일을 남기는 오늘의 기록 기능이 있다.

활동을 종료하면 AI가 여러 날짜의 기록을 바탕으로 완료 경험 초안을 생성한다.

발표에서는 이 기능을 앞으로 더 가볍고 자동화된 방식으로 발전시키고 싶다는 방향도 소개했다.

사용자는 매일 긴 경험을 작성하지 않고 다음처럼 짧은 기록만 남길 수 있다.

사용자 흐름 수정
AI 추천 프롬프트 개선
팀 회의에서 기능 우선순위 결정
배포 오류 해결

AI가 여러 기록의 연관성을 파악해 하나의 프로젝트 경험으로 묶고, 사용자의 역할과 문제 해결 과정, 성과를 정리해준다면 경험을 한 번에 작성하는 부담을 크게 줄일 수 있다.

이는 입력 편의성뿐 아니라 사용자가 CampusLog에 꾸준히 방문하도록 만드는 핵심 기능이 될 수 있다.

발표가 끝난 뒤 시작된 네트워킹

공식 발표가 마무리된 뒤에는 피자, 치킨, 떡볶이 등을 함께 먹으며 네트워킹이 이어졌다.

발표 시간에는 각 팀의 기능과 문제 정의를 중심으로 이야기했다면, 식사 시간에는 AI 시대의 개발자, 취업과 포트폴리오, 창업, 해외 커리어 등 더 넓은 주제로 대화했다.

다른 크루들에게 CampusLog를 다시 소개하고, 추후 베타테스트에 참여해달라고 부탁했다.

실제 사용 중 발생하는 오류와 불편한 점을 편하게 알려달라고 이야기했고, 단순히 연락처를 교환한 것을 넘어 앞으로 CampusLog를 사용하고 피드백을 줄 수 있는 잠재 사용자를 만날 수 있었다.

멘토님들과의 대화에서는 AI를 활용해 개발한 프로젝트를 어떻게 자신의 경험으로 설명할 것인지에 대한 이야기도 들었다.

중요한 것은 AI가 코드를 만들었는지가 아니라, 사람이 어떤 문제를 발견했고 어떤 기준으로 결과를 판단하고 검증했는지 설명할 수 있는가였다.

CampusLog 역시 단순히 “Codex로 만들었다”라고 설명해서는 안 된다.

왜 이 기능을 선택했는지, AI가 경험을 과장하지 않도록 어떤 구조를 사용했는지, 추천 결과의 근거를 어떻게 검증했는지, 실제 오류를 어떻게 발견하고 해결했는지를 설명할 수 있어야 한다.

중간 데모 이후의 개발 방향

이번 주에는 많은 화면과 기능을 다듬었지만, 중간 데모를 통해 앞으로 필요한 작업도 더 분명해졌다.

1. AI 작업의 백그라운드 처리와 완료 알림

AI 분석과 추천을 요청한 뒤 사용자가 다른 작업을 계속할 수 있도록 작업 상태를 관리하는 구조를 검토할 예정이다.

단순한 로딩 문구에서 끝나지 않고 진행 단계, 백그라운드 작업, 완료 알림과 실패 후 재시도를 함께 설계해야 한다.

2. 데모 시나리오와 오류 대응 강화

최종 발표 전에는 실제 발표 순서 그대로 반복해서 리허설할 계획이다.

정상 흐름만 확인하지 않고 다음 상황도 준비해야 한다.

OpenAI 응답 지연
Supabase 세션 만료
AI 결과 저장 실패
네트워크 오류
이미지 인식 실패
배포 환경 문제

사전 생성 결과, 화면 캡처와 대체 설명 순서도 함께 준비하려고 한다.

3. 경험 입력 방식의 멀티모달 확장

질문과 JD뿐 아니라 사용자가 가지고 있는 기존 경험 자료도 이미지와 문서로 전달할 수 있도록 입력 방식을 확장할 예정이다.

다만 AI가 자동으로 만든 내용을 바로 저장하지 않고, 사용자가 검토하고 수정한 뒤 경험으로 확정하는 구조는 유지해야 한다.

4. 다양한 전공을 대상으로 한 사용자 테스트

현재까지의 테스트는 개발과 AI 분야의 경험에 치우친 부분이 있다.

앞으로는 기획, 디자인, 마케팅, 경영, 인문·사회 등 다양한 전공의 대학생에게 서비스를 사용해보도록 요청하려고 한다.

단순한 만족도보다 다음 지표를 확인할 계획이다.

첫 경험 등록 완료율
AI 분석까지 도달한 사용자 비율
추천 결과의 납득도
추천 경험을 실제 지원에 활용할 의향
어느 단계에서 사용자가 이탈하는지
다시 방문해 기록할 의향
가장 불편했던 입력 단계

5. 자기소개서 이후 면접 준비까지 연결

추천된 경험을 사용자가 자신의 언어로 설명할 수 있도록 면접 질문과 꼬리 질문, 답변 연습 기능을 검토하려고 한다.

CampusLog의 목표는 완성된 문장을 대신 제출해주는 것이 아니라, 사용자가 자신의 경험을 더 정확하게 이해하고 활용하도록 돕는 것이다.

중간 점검을 넘어 실제 사용자에게

이번 주는 CampusLog의 화면과 기능을 다듬는 일로 시작해, 실제 크루들과 멘토님들 앞에서 서비스를 시연하는 것으로 마무리되었다.

개발 과정에서는 디자인 시스템과 정보 구조를 통일하고, 즐겨찾기와 검색, AI 결과 화면의 위계를 정리했다.

동시에 여러 기기에서 같은 계정을 사용할 때 발생하는 세션 문제와 긴 경험을 분석했을 때 발생하는 저장 오류처럼 실제 데이터에서만 발견할 수 있는 문제도 해결했다.

그리고 중간 데모에서는 준비한 모든 기능을 완벽하게 보여주지는 못했다.

AI 분석 중 오류가 발생했고, 준비해둔 화면으로 발표를 이어간 뒤 쉬는 시간에 문제를 찾아 수정하고 다시 배포했다.

당황스러운 순간이었지만, 오히려 실제 서비스를 운영하고 시연하기 위해 무엇을 준비해야 하는지 배울 수 있었다.

이번 데모데이는 단순히 현재까지의 결과물을 평가받는 자리가 아니었다.

다른 팀의 서비스를 보면서 우리가 놓친 관점을 발견했고, 공개 피드백을 통해 CampusLog가 앞으로 지향해야 할 가치를 다시 확인했다.

기억에 남은 문장도 있었다.

“가장 안전했던 선택이 나를 위험하게 만들었고, 위험한 선택이 나를 안전하게 만들었다.”

무작정 위험한 선택을 하라는 의미라기보다, 감당할 수 있는 범위에서 직접 시도하고 그 결과를 다음 판단의 근거로 만들어야 한다는 이야기로 받아들였다.

CampusLog 역시 아직 완성된 서비스가 아니다.

하지만 아이디어를 문서로만 남기는 데서 멈추지 않고, 실제로 작동하는 서비스를 만들고, 사람들 앞에서 시연하고, 오류와 피드백을 다시 개발에 반영하고 있다.

남은 기간에는 기능의 개수를 늘리는 것보다 CampusLog가 대학생의 경험 관리 문제를 실제로 얼마나 잘 해결하는지 증명하는 데 집중하려고 한다.

대학생이 자신의 경험을 부담 없이 기록하고, 필요한 순간에 가장 적합한 경험을 꺼내 자신의 언어로 설명할 수 있도록 돕는 서비스

중간 데모를 넘어, 이제 실제 사용자가 계속 사용하고 싶은 CampusLog를 만들어가려고 한다.

경제금융용어 공부 581 : 커버드본드(이중상환청구권부 채권)

MKISOS — Tue, 4 Aug 2026 21:00:05 +0900

커버드본드(이중상환청구권부 채권)

은행이 주택담보대출처럼 장기간에 걸쳐 돈을 회수하는 자산을 보유하려면 안정적인 장기자금이 필요하다. 커버드본드는 은행이 보유한 우량 담보자산을 바탕으로 발행하는 채권으로, 투자자가 담보자산과 발행 금융기관 모두에 상환을 요구할 수 있다는 특징이 있다. 상환 안전장치가 두 겹으로 존재하기 때문에 일반 회사채보다 비교적 안전성이 높고 낮은 금리로 발행될 수 있다.

1. 한 줄 정의

커버드본드는 담보자산에 대한 우선변제권과 발행 금융기관에 대한 상환청구권을 동시에 보장하는 채권이다.

2. 기본 개념

커버드본드(Covered Bond)는 은행 등 금융기관이 자신이 보유한 주택담보대출이나 공공부문 대출 같은 우량 자산을 담보로 발행하는 채권이다.

우리나라에서는 2014년 4월 관련 제도가 도입되었다.

커버드본드 투자자는 채권을 발행한 금융기관으로부터 원금과 이자를 받을 권리를 가진다. 동시에 발행 금융기관이 채무를 상환하지 못하면 별도로 관리되는 담보자산에서도 우선적으로 변제받을 수 있다.

즉 투자자가 다음 두 곳에 상환을 요구할 수 있다.

채권을 발행한 금융기관
커버드본드의 담보로 지정된 자산

이처럼 두 가지 상환청구권이 존재하기 때문에 커버드본드를 이중상환청구권부 채권이라고도 한다.

3. 왜 중요한가

은행은 고객의 예금처럼 비교적 만기가 짧은 자금으로 돈을 조달하는 경우가 많다.

반면 주택담보대출은 20년이나 30년처럼 만기가 매우 길다. 은행이 단기자금을 조달해 장기대출을 계속 운용하면 만기 차이와 금리 변동으로 인해 위험이 커질 수 있다.

커버드본드를 발행하면 은행은 장기간 사용할 수 있는 자금을 비교적 낮은 고정금리로 조달할 수 있다.

그 결과 은행은 장기 고정금리 주택담보대출을 더 안정적으로 공급할 수 있고, 가계도 금리 변동 위험을 줄일 수 있다.

4. 쉽게 이해하는 예시

실생활 예시

A은행이 수많은 고객에게 주택담보대출을 제공했다고 가정해보자.

A은행은 이 주택담보대출 채권들을 담보로 커버드본드를 발행하고 투자자로부터 장기자금을 조달한다.

투자자는 A은행이 정상적으로 운영되는 동안에는 은행으로부터 원금과 이자를 받는다.

만약 A은행이 부실해져 상환하지 못하면 투자자는 담보로 지정된 주택담보대출 자산에서 우선적으로 변제받을 수 있다.

대학생 예시

친구에게 돈을 빌려주면서 친구의 상환 약속만 받는 것이 아니라, 친구가 보유한 예금에도 우선적으로 권리를 설정했다고 가정해보자.

친구가 직접 돈을 갚으면 문제가 없고, 갚지 못하면 예금에서 먼저 돌려받을 수 있다.

이처럼 상환 경로가 두 개 존재하는 것이 커버드본드의 핵심이다.

투자 예시

일반 은행채는 은행의 신용에만 의존한다.

반면 커버드본드는 은행의 신용뿐 아니라 주택담보대출 같은 별도 담보자산도 존재한다.

따라서 동일한 금융기관이 발행하더라도 커버드본드 금리가 일반 채권보다 낮게 형성될 수 있다.

5. 핵심 특징

5-1. 이중상환청구권이 존재한다

커버드본드 투자자는 발행 금융기관에 원리금 상환을 청구할 수 있다.

발행기관이 상환하지 못하면 담보자산에도 우선변제를 요구할 수 있다.

5-2. 담보자산이 금융기관의 장부에 남아 있다

커버드본드의 담보가 되는 주택담보대출 등은 원칙적으로 발행 금융기관이 계속 보유하고 관리한다.

기초자산을 별도의 특수목적기구에 넘기는 자산유동화증권과 다른 점이다.

5-3. 비교적 낮은 금리로 발행할 수 있다

상환 가능성을 높이는 안전장치가 두 겹으로 존재하므로 투자자가 요구하는 위험 프리미엄이 낮아질 수 있다.

그 결과 금융기관은 일반 채권보다 낮은 금리로 장기자금을 조달할 수 있다.

5-4. 장기 고정금리 대출 확대에 도움이 된다

은행은 커버드본드를 통해 확보한 장기자금으로 장기 고정금리 주택담보대출을 공급할 수 있다.

이는 은행과 가계 모두의 금리 변동 위험을 줄이는 데 도움이 된다.

6. 관련 개념과의 차이

커버드본드 vs 자산유동화증권(ABS)

커버드본드

담보자산이 발행 금융기관에 남아 있음
발행기관에도 원리금 상환을 청구할 수 있음
담보자산에도 우선변제권을 행사할 수 있음
이중상환 구조임

자산유동화증권(ABS)

기초자산을 특수목적기구에 이전함
기초자산에서 발생하는 현금흐름을 바탕으로 상환함
자산을 이전한 원래 금융기관의 직접적인 상환의무는 일반적으로 제한됨

즉 커버드본드는 발행기관과 담보자산이 함께 책임지는 구조이고, ABS는 별도 기구로 이전된 기초자산의 현금흐름에 주로 의존하는 구조이다.

커버드본드 vs 주택저당증권(MBS)

커버드본드

주택담보대출을 담보로 채권을 발행함
담보대출이 발행기관 장부에 남아 있음
발행기관과 담보자산에 모두 청구 가능함

주택저당증권(MBS)

주택담보대출 채권을 유동화해 발행함
기초자산을 별도 기구 등에 이전함
주택담보대출에서 발생하는 원리금이 주요 상환재원이 됨

둘 다 주택담보대출을 활용하지만 법적 구조와 투자자의 상환청구 대상이 다르다.

커버드본드 vs 일반 은행채

커버드본드

별도의 담보자산이 존재함
이중상환청구권이 있음
상대적으로 발행금리가 낮을 수 있음

일반 은행채

은행의 신용을 바탕으로 발행함
별도의 우선 담보자산이 없음
은행의 재무건전성에 더 크게 의존함

7. 경제적 의미

국가경제 관점

커버드본드는 금융기관의 장기자금 조달을 안정시키고 주택금융시장의 구조를 개선하는 역할을 한다.

장기 고정금리 대출이 확대되면 가계와 금융기관이 금리 변동으로 받는 충격도 줄어들 수 있다.

기업 관점

은행은 비교적 낮은 금리로 장기자금을 조달할 수 있어 자금조달 구조를 안정적으로 관리할 수 있다.

단기 예금에 지나치게 의존하는 문제도 완화할 수 있다.

금융시장 관점

커버드본드는 안전성이 높은 장기채권 상품을 금융시장에 공급한다.

보험사나 연기금처럼 안정적인 장기자산을 원하는 기관투자자에게 적합한 투자대상이 될 수 있다.

투자 관점

커버드본드는 일반 채권보다 상환 안전성이 높을 수 있지만 완전히 위험이 없는 상품은 아니다.

투자자는 발행 금융기관의 신용도, 담보자산의 품질, 주택시장 상황, 금리 변동 위험을 함께 살펴봐야 한다.

8. 정리

커버드본드는 금융기관이 보유한 주택담보대출 등 우량 자산을 담보로 발행하는 채권이다. 투자자는 발행 금융기관에 원리금 상환을 요구할 수 있고, 금융기관이 상환하지 못하면 담보자산에서도 우선적으로 변제받을 수 있다. 이러한 이중상환 구조 덕분에 일반 채권보다 비교적 안전성이 높고 낮은 금리로 발행될 수 있다. 커버드본드는 은행의 안정적인 장기자금 조달과 장기 고정금리 주택담보대출 확대에 기여하는 중요한 금융상품이다.

경제금융용어 공부 580 : 캐리트레이드

MKISOS — Mon, 3 Aug 2026 21:00:31 +0900

캐리트레이드

국가마다 기준금리와 시장금리가 다르기 때문에 자금을 빌리는 비용에도 차이가 발생한다. 캐리트레이드는 금리가 낮은 국가에서 돈을 빌린 뒤 금리가 더 높은 국가의 채권이나 주식 등에 투자해 금리 차이만큼 수익을 얻으려는 전략이다. 다만 실제 수익은 금리 차뿐 아니라 환율 변동에도 크게 영향을 받기 때문에 예상보다 위험한 거래가 될 수 있다.

1. 한 줄 정의

캐리트레이드는 금리가 낮은 통화로 자금을 빌려 금리가 높은 국가의 자산에 투자하는 전략이다.

2. 기본 개념

캐리트레이드(Carry Trade)는 저금리 국가의 통화로 자금을 조달하고, 이를 고금리 국가의 채권·주식·예금 등에 투자하는 거래를 의미한다.

여기서 캐리(Carry)는 자금을 빌리거나 보유하는 것을 의미하고, 트레이드(Trade)는 해당 자금으로 자산을 거래하는 것을 의미한다.

캐리트레이드의 기본 수익 구조는 다음과 같다.

낮은 금리로 자금을 빌린다.
높은 금리를 제공하는 자산에 투자한다.
두 금리 사이의 차이만큼 수익을 기대한다.

예를 들어 연 1% 금리로 돈을 빌려 연 6% 수익률의 채권에 투자한다면 단순 계산상 5%포인트의 수익 차이를 기대할 수 있다.

하지만 국제투자에서는 서로 다른 통화를 사용하기 때문에 환율 변동에 따른 이익이나 손실도 함께 발생한다.

3. 왜 중요한가

캐리트레이드는 국제금융시장에서 대규모 자금의 이동을 만들어내는 대표적인 투자전략이다.

특정 국가의 금리가 다른 국가보다 높아지면 해외 자금이 유입되면서 해당 국가의 주식과 채권 가격이 상승할 수 있다.

반대로 금융시장이 불안해지거나 금리 차이가 줄어들면 투자자들이 캐리트레이드를 한꺼번에 청산할 수 있다.

이 과정에서 신흥국의 주가와 통화가치가 급락하고 국제금융시장의 변동성이 크게 확대될 수 있다.

따라서 캐리트레이드는 단순한 금리 차익 거래가 아니라 세계 자금 흐름과 환율을 이해하기 위한 중요한 개념이다.

4. 쉽게 이해하는 예시

실생활 예시

A은행에서 연 2% 금리로 돈을 빌릴 수 있고, B은행의 예금금리는 연 6%라고 가정해보자.

A은행에서 돈을 빌려 B은행에 예금하면 금리 차이인 4%포인트의 수익을 기대할 수 있다.

캐리트레이드는 이러한 거래를 서로 다른 국가와 통화 사이에서 수행하는 것과 비슷하다.

투자 예시

일본의 금리가 0.5%이고 한 국가의 국채 수익률이 6%라고 가정해보자.

투자자는 일본 엔화를 빌린 뒤 이를 다른 국가의 통화로 환전하여 고금리 국채에 투자할 수 있다.

금리 차이만 보면 높은 수익을 기대할 수 있지만, 투자 기간에 엔화 가치가 상승하면 빌린 엔화를 갚는 비용이 커져 손실이 발생할 수 있다.

엔 캐리트레이드 예시

1990년대 후반 일본은 장기간 낮은 금리를 유지하였다.

국제 투자자들은 낮은 금리로 엔화를 빌린 뒤 금리가 높은 신흥국의 채권과 주식 등에 투자하였다.

이를 엔 캐리트레이드라고 한다.

달러 캐리트레이드 예시

2008년 글로벌 금융위기 이후 미국이 기준금리를 0%대까지 낮추자 달러를 낮은 비용으로 빌릴 수 있게 되었다.

이에 투자자들이 달러를 빌려 더 높은 금리를 제공하는 다른 국가의 자산에 투자하는 달러 캐리트레이드가 확대되었다.

5. 핵심 특징

5-1. 국가 간 금리 차이를 이용한다

캐리트레이드의 기본 수익원은 차입국과 투자국 사이의 금리 차이이다.

차입금리가 낮고 투자수익률이 높을수록 기대수익도 커진다.

5-2. 환율 변동이 수익을 결정한다

금리 차이가 커도 환율이 불리하게 움직이면 손실이 발생할 수 있다.

따라서 캐리트레이드에서는 금리보다 환율이 더 중요한 변수가 되기도 한다.

5-3. 레버리지 효과가 발생한다

투자자는 자기자본이 아니라 빌린 돈으로 투자한다.

따라서 투자 결과가 좋으면 수익률이 커지지만, 예상과 반대로 움직이면 손실도 확대된다.

5-4. 시장 불안기에 급격히 청산될 수 있다

금융시장이 안정적일 때는 캐리트레이드가 확대되기 쉽다.

그러나 위기가 발생하면 투자자들은 위험자산을 매도하고 빌린 통화를 다시 사들여 상환하려 한다.

이 과정에서 환율과 자산가격이 급격하게 움직일 수 있다.

6. 관련 개념과의 차이

캐리트레이드 vs 일반 해외투자

캐리트레이드

낮은 금리로 빌린 자금을 활용함
국가 간 금리 차이가 핵심 수익원임
환율과 레버리지 위험이 큼

일반 해외투자

자기자본으로 투자하는 경우가 많음
기업 성장이나 자산가격 상승이 주요 목적임
반드시 금리 차이를 이용하지는 않음

즉 일반 해외투자는 해외자산 자체의 성장성을 보고 투자하지만, 캐리트레이드는 차입비용과 투자수익률의 차이를 적극적으로 활용한다.

캐리트레이드 vs 금리차익거래

캐리트레이드

서로 다른 국가와 통화 사이의 금리 차이를 활용함
환율 변동 위험에 노출됨
수익이 확정되지 않음

금리차익거래

시장 간 금리 차이를 이용해 위험을 최소화하려는 거래임
거래 구조에 따라 수익을 고정하기도 함
상대적으로 무위험 차익거래에 가까울 수 있음

캐리트레이드는 환율이 변하기 때문에 일반적인 무위험 차익거래와 달리 손실 가능성이 존재한다.

엔 캐리트레이드 vs 달러 캐리트레이드

엔 캐리트레이드

낮은 금리의 엔화를 빌림
고금리 국가의 자산에 투자함
엔화 가치 상승 시 손실 위험이 커짐

달러 캐리트레이드

낮은 금리의 달러를 빌림
미국 외 고금리 자산에 투자함
달러 가치 상승 시 손실 위험이 커짐

두 전략은 구조는 같지만 어떤 통화를 빌리는지가 다르다.

7. 경제적 의미

국가경제 관점

고금리 국가는 캐리트레이드 자금이 유입되면서 환율 안정과 금융시장 상승의 효과를 얻을 수 있다.

하지만 외국 자금 의존도가 높아지면 시장 불안 시 자금이 급격히 빠져나가는 위험도 커진다.

기업 관점

해외 자금이 유입되면 기업의 주가가 상승하고 자금조달 여건이 좋아질 수 있다.

반대로 캐리트레이드 청산이 발생하면 주가 하락과 환율 급등으로 기업의 금융비용이 증가할 수 있다.

금융시장 관점

캐리트레이드는 금리가 낮은 국가의 통화 약세와 고금리 국가의 통화 강세를 유발할 수 있다.

그러나 투자자들이 거래를 동시에 청산하면 차입통화가 급등하고 위험자산 가격이 급락하는 현상이 나타날 수 있다.

투자 관점

투자자는 단순히 금리가 높은 국가의 자산이라고 해서 높은 수익을 보장받는 것은 아니다.

금리 차이, 환율 전망, 차입비용, 시장 변동성, 투자 대상의 신용위험을 함께 고려해야 한다.

특히 차입통화의 가치가 상승하면 금리 수익을 모두 잃고도 추가 손실이 발생할 수 있다.

8. 정리

캐리트레이드는 금리가 낮은 국가의 통화로 자금을 빌려 금리가 높은 국가의 주식이나 채권 등에 투자하는 전략이다. 수익은 국가 간 금리 차이에서 발생하지만 실제 결과는 환율 변동에 크게 좌우된다. 시장이 안정적일 때는 높은 수익을 기대할 수 있지만, 금융위기나 환율 급변이 발생하면 레버리지와 환차손으로 손실이 크게 확대될 수 있다. 따라서 캐리트레이드는 국제금융시장의 자금 흐름과 환율 변동을 이해하는 데 중요한 투자 개념이다.

[UNIKER] AI 서비스를 직접 시연하다, 팀 핏줄 CampusLog 중간 데모데이 후기 (“가장 안전했던 선택이 나를 위험하게 만들었고, 위험한 선택이 나를 안전하게 만들었다.”)

MKISOS — Mon, 3 Aug 2026 13:23:52 +0900

문서와 코드 안에서만 보던 서비스를 다른 사람들 앞에서 직접 시연하는 순간, 프로젝트는 전혀 다르게 보이기 시작한다.

역삼 센터필드 7층 UNIKER 중간 데모데이 현장

2026년 8월 2일, 서울 역삼역 인근 센터필드 7층에서 커널아카데미 대학생 AI 크루 UNIKER 1기 중간 데모데이가 진행됐다. 오후 2시부터 5시 30분까지 레크리에이션과 팀별 발표, 멘토 피드백이 이어졌고, 공식 일정이 끝난 뒤에도 오후 7시 30분까지 식사와 네트워킹이 계속됐다.
이번 데모데이는 지난 몇 주 동안 각 팀이 기획하고 개발한 AI 서비스를 처음으로 한자리에서 공유하는 시간이었다.
우리 팀 ‘핏줄’ 역시 대학생의 경험을 기록하고 활용하도록 돕는 서비스 CampusLog를 직접 시연했다.

처음 만난 크루들과 팀을 이루다

조 구성과 레크레이션 진행

행사는 기존 프로젝트 팀이 아닌 새로운 조로 자리를 섞어 앉는 것부터 시작됐다.
각자 이름과 학교, 전공 등을 간단하게 소개한 뒤 레크리에이션에서 사용할 팀명과 구호를 정했다.
우리 조의 팀명은 ‘소녀시대’, 구호는 노래 ‘Gee’를 연상시키는 “지!”로 정했다. (레크레이션 동안 빠르게 구호를 외치기 위하여..)
처음 만난 사람들과 짧은 시간 안에 이름을 정해야 해서 조금 어색하기도 했지만 이 과정 덕분에 자연스럽게 대화를 시작할 수 있었다.

본격적인 발표 전에 진행된 레크리에이션은 크게 세 가지였다.
첫 번째는 여러 상품이나 메뉴를 보고 가격이 비싼 순서를 추론하는 영수증 프로파일러, 두 번째는 여러 음료가 섞인 음료를 직접 마시고 어떤 재료가 들어갔는지 맞히는 게임이었다.
마지막은 사진 속 단서를 찾아 설명과 실제 상황이 맞지 않는 부분을 발견하는 게임이었다. 휴대전화 화면의 시간, 위치 정보, 사진 속 물건처럼 무심코 지나칠 수 있는 부분을 찾아야 해서 생각보다 집중력이 필요했다. 준비된 게임이 예상보다 빠르게 끝난 뒤에는 노래 맞히기 게임도 추가로 진행됐다.

평소에 할 수 없는 게임들을 진행하면서 생각보다 재미있었고 팀원들이랑 서로 조금씩 친해질 수 있는 계기였다. 게임 중간 중간에 5초간 친목도모 시간이 기억에 남는다.

대학생의 문제를 AI 서비스로 풀어낸 팀들

레크리에이션이 끝난 뒤에는 각 팀이 개발 중인 서비스를 약 5~10분 동안 발표하고, 이어서 두 분의 멘토님으로부터 공개 피드백을 받았다.
웹캠을 활용한 자세 및 집중 관리 서비스, 대학생을 위한 AI 대화 친구, 대학원 연구 주제와 교수 매칭 서비스, 번아웃 예방 스케줄러, AI와 인플루언서를 결합한 패션 스타일링, 대학생활 정보를 연결하는 AI 비서 등 다양한 주제가 등장했다.

같은 UNIKER 프로그램에 참여하고 있지만, 팀마다 문제를 바라보는 방식은 상당히 달랐다. 어떤 팀은 게임 요소와 커뮤니티를 활용했고, 어떤 팀은 개인화된 추천이나 데이터 분석에 집중했다. 발표를 들으며 AI라는 같은 도구도 사용자의 문제와 팀의 관점에 따라 전혀 다른 서비스로 구현될 수 있다는 점이 인상적이었다.

멘토님들은 단순히 화면이 예쁜지, 기능이 많은지만 평가하지 않았다. 해결하려는 문제가 무엇인지 사용자가 계속 서비스를 이용할 이유가 있는지, AI를 사용하지 않았을 때와 비교해 어떤 차별점이 있는지, 실제로 검증할 수 있는 지표가 무엇인지까지 질문했다.
특히 베타테스트를 진행할 때는 단순히 “사용해 보고 의견을 받는다”에서 끝나는 것이 아니라, 누구를 대상으로 어떤 가설을 검증할 것인지를 먼저 정의해야 한다는 조언이 여러 팀의 피드백에서 공통적으로 드러났다.

팀 핏줄의 CampusLog 중간 데모

팀 핏줄 발표 (나)

우리 팀 ‘핏줄’은 대학생의 경험을 기록하고 필요할 때 다시 활용하도록 돕는 AI 경험 관리 서비스, CampusLog를 발표했다.
CampusLog는 우리 팀이 실제로 겪었던 불편함에서 출발했다.
대외활동이나 학교 프로그램, 인턴과 채용에 지원하려면 자기소개서와 면접을 준비해야 한다. 그러나 막상 질문을 받으면 어떤 경험을 활용해야 할지 바로 떠올리기 어렵다.
평소 블로그, 노션, GitHub, 갤러리, AI 대화 기록 등에 경험을 남겨두더라도 실제 지원 시점에는 여러 공간을 다시 뒤져야 한다. 기록은 존재하지만 필요한 순간에 적절한 경험을 찾고 활용하기 어렵다는 것이 우리가 발견한 문제였다.
CampusLog는 이 과정을 다음과 같이 연결한다.

경험 기록 → AI 경험 분석 → 목적에 맞는 경험 추천 → 자기소개서·면접·지원에 활용

대학생이 프로젝트, 공모전, 인턴, 대외활동 등의 경험을 기록하면 AI가 그 경험의 역량과 성과를 정리하고, 자기소개서나 포트폴리오, 면접 준비 상황에 적합한 경험을 다시 추천하는 것이 서비스의 핵심이다.

직접 시연한 CampusLog의 핵심 기능

발표에서는 설명에만 머무르지 않고 실제 배포된 서비스를 직접 조작하며 전체 흐름을 보여드렸다.
먼저 이메일 인증과 구글 로그인을 통해 서비스에 접속한 뒤 새로운 경험을 기록했다. 사용자는 활동 제목과 기간, 역할, 활동 내용, 성과, 관련 링크와 이미지 등을 저장할 수 있다.
저장된 경험에 AI 분석을 요청하면 경험의 핵심 내용과 성과를 요약하고, 면접과 자기소개서에 활용하기 쉽도록 STAR 구조에 맞게 정리한다.
여기서 우리가 중요하게 생각한 부분은 AI가 사용자의 경험을 마음대로 과장하지 않도록 하는 것이었다.
기록된 내용만으로 정확한 분석이 어려운 경우 AI가 역할 범위, 수치화된 성과, 문제 해결 과정 등 부족한 정보를 다시 질문한다. 사용자는 답변할 수 있는 내용만 보완하고, 그 결과까지 저장해 이후 경험 추천에 활용할 수 있다.

메인 기능인 AI 경험 추천에서는 자기소개서, 면접, JD 분석, 대외활동 지원 등 활용 목적과 질문을 입력한다. 이미지로 캡처한 채용공고나 PDF 자료도 함께 첨부할 수 있도록 구성했다.
AI는 저장된 경험과 기존 분석 결과를 함께 살펴본 뒤 가장 적합한 경험 세 가지를 추천한다. 단순히 경험 제목만 보여주는 것이 아니라 다음 내용도 함께 제공한다.

해당 경험을 추천한 이유와 판단 근거
질문과 연결되는 역량 및 성과
현재 기록에서 부족한 부분
자기소개서나 면접에서 강조할 방향

자기소개서 문항이라면 요구되는 글자 수에 맞춰 초안을 생성할 수 있고, JD 분석에서는 채용공고의 요구사항과 사용자의 경험을 비교해 충족, 부분 충족, 미충족 여부를 보여준다. 이를 통해 사용자는 단순히 “지원할 수 있다”는 답변을 받는 것이 아니라, 어떤 경험을 강조하고 어떤 역량을 보완해야 하는지 확인할 수 있다.

시연 중 AI 분석 요청에서 일시적인 오류가 발생하기도 했다. 다행히 준비해둔 분석 결과 화면으로 전환해 발표를 이어갈 수 있었다. 실제 데모에서는 기능 구현뿐 아니라 오류가 발생했을 때 어떻게 다음 흐름으로 넘어갈지도 준비해야 한다는 점을 체감했다.

(이후에 발표 끝나자 마자 시연 중 왜 오류가 발생했는지 오류 코드 찾고 바로 수정해서 발표 쉬는 시간에 배포를 다시 했다.. 최종 발표때는 이런 일이 일어나지 않도록 꼼꼼하게 테스트하고 시뮬레이션 하고 준비해서 와야겠다.)

“기다리는 시간을 또 다른 경험으로 연결해보세요”

발표가 끝난 뒤 멘토님들께서는 이전 멘토링 때보다 서비스가 많이 발전했고 실제로 겪은 불편함에서 출발한 문제 정의가 좋았다고 평가해주셨다.
특히 경험을 한 번 분석하고 끝내는 것이 아니라 AI가 부족한 정보를 질문하고 사용자가 보완한 뒤 다시 분석할 수 있도록 만든 세부적인 UX를 긍정적으로 봐주셨다.

가장 구체적인 피드백은 AI 응답을 기다리는 시간에 관한 것이었다.
현재는 분석이나 추천을 요청하면 사용자가 해당 화면에서 결과가 나올 때까지 기다려야 한다. 멘토님께서는 작업을 백그라운드에서 계속 진행하고, 화면에는 프로그레스 바나 진행 상태를 보여주는 방식을 제안해주셨다.
사용자가 기다리는 동안 다음과 같이 다른 행동을 유도할 수도 있다.

“분석이 진행되는 동안 다른 경험을 기록해보시겠어요?”
“오늘의 기록을 먼저 작성해보세요.”

분석이 끝나면 별도의 알림을 제공하면 사용자는 멈춰 있는 화면을 바라보지 않고 서비스를 계속 이용할 수 있다. 기술적으로 응답 시간을 완전히 줄이는 것뿐 아니라, 사용자가 체감하는 대기 시간을 어떻게 설계할 것인지도 중요하다는 피드백이었다.

경험 입력 화면 역시 정해진 폼만 제공하기보다 기존 문서나 이미지, 활동 기록을 올리면 AI가 CampusLog 형식에 맞게 자동으로 정리해주는 멀티모달 입력 방식을 고려해볼 수 있다는 의견을 받았다.

AI가 대신 작성하는 서비스에서 끝나지 않으려면

또 하나 기억에 남았던 피드백은 생성형 AI와 취업 준비에 관한 것이었다.
최근에는 많은 지원자가 AI를 활용해 자기소개서를 작성한다. 하지만 잘 작성된 서류로 합격하더라도, 면접에서 자신이 수행한 경험을 제대로 설명하지 못하는 경우가 생길 수 있다.
멘토님께서는 CampusLog가 단순히 보기 좋은 자기소개서를 대신 작성해주는 서비스에서 끝나지 않고 사용자가 자신의 경험을 다시 이해하고 말할 수 있도록 면접과 이후 과정까지 연결되면 좋겠다는 의견을 주셨다.

우리 역시 처음부터 사용자의 실제 경험을 기반으로 분석하고, 부족한 정보를 다시 질문하도록 설계했다. 이번 피드백을 통해 이 방향을 더욱 발전시켜야겠다고 생각했다.

AI가 사용자의 경험을 새롭게 만들어주는 것이 아니라,

사용자가 이미 가진 경험을 더 정확히 기억하고, 자신의 언어로 설명하도록 돕는 것

이 CampusLog가 지향해야 할 중요한 가치라고 느꼈다.

과거 경험을 한 번에 적는 부담, ‘오늘의 기록’으로 줄이기

발표 마지막에는 앞으로 개발하고 싶은 ‘오늘의 기록’ 기능도 소개했다.
CampusLog를 직접 사용해보면서 과거의 활동을 한 번에 정리하는 것 역시 적지 않은 일이라는 사실을 확인했다. 아무리 좋은 서비스라도 처음부터 긴 경험 기록을 요구하면 사용자가 부담을 느낄 수 있다.
따라서 매일 짧게 한 일을 남기면 AI가 비슷한 기록을 하나의 활동으로 묶어주는 방식을 구상하고 있다.

예를 들어 며칠 동안 다음 기록을 남겼다고 가정해볼 수 있다.

사용자 흐름 수정
AI 추천 프롬프트 개선
팀 회의에서 기능 우선순위 결정
배포 오류 해결

AI가 이 기록을 하나의 프로젝트 경험으로 묶고, 역할과 문제 해결 과정, 성과를 정리해준다면 사용자는 기억이 흐려지기 전에 경험을 자연스럽게 축적할 수 있다.

이는 기록의 부담을 줄이는 기능인 동시에, 사용자가 CampusLog를 한 번만 쓰고 떠나는 것이 아니라 꾸준히 방문하도록 만드는 핵심 기능이 될 수 있다.

발표가 끝난 뒤 시작된 진짜 네트워킹

피자·치킨·떡볶이와 함께한 식사 및 네트워킹

오후 5시 30분경 공식 발표가 마무리된 뒤에는 피자와 치킨, 떡볶이, 튀김 등을 함께 먹으며 네트워킹을 이어갔다.
발표 시간에는 각 팀의 서비스와 기능을 중심으로 이야기했다면, 식사 시간에는 AI 시대의 개발자, 취업과 포트폴리오, 창업, 해외 커리어 등 더 넓은 주제로 대화가 이어졌다.

다른 크루들과는 학교와 전공, 진행 중인 대외활동과 프로젝트를 공유했다. CampusLog도 다시 소개하며 이후 베타테스트에 참여해달라고 요청했고, 실제 사용 과정에서 발생하는 오류와 불편함을 편하게 알려달라고 부탁했다.

단순히 연락처만 교환하는 네트워킹이 아니라, 앞으로 우리의 서비스를 사용해보고 피드백을 줄 수 있는 잠재 사용자들을 만났다는 점에서 의미가 컸다.

AI 시대에는 ‘무엇을 만들었는지 설명하는 능력’이 더 중요하다

식사 자리에서 가장 인상 깊었던 주제는 AI를 활용한 개발을 현업에서는 어떻게 바라보는가였다.
AI가 보편화되면서 많은 사람이 이전보다 빠르게 코드와 서비스를 만들 수 있게 됐다. 동시에 충분히 검증하지 않은 코드와 Pull Request가 늘어날 수 있다는 우려도 존재한다.
멘토님께서는 이러한 흐름 자체를 막을 수는 없으며, 조직에서는 AI가 만든 결과물을 검토할 수 있는 시스템을 갖춰야 한다고 말씀하셨다. 그러나 도구가 발전하더라도 개발자는 자신이 어떤 코드를 만들었는지 이해해야 한다는 점은 변하지 않는다.

면접에서 문제가 발생했을 때,

“AI가 그렇게 만들어줬습니다.”

라고 답하는 것과,

“이 문제를 이렇게 판단했고, 해당 분석과 구현 과정에서 AI를 활용했습니다.”

라고 답하는 것은 전혀 다르다.

AI가 결과물을 만들었는지가 아니라, 그 과정에서 사람이 어떤 기준으로 판단하고 검증했는지가 중요하다는 이야기였다. 오류가 발생했을 때 원인을 생각하지 않고 AI에 해결을 맡기기만 한다면 그 결과는 온전히 자신의 경험이 되기 어렵다. 반대로 기술을 선택한 이유와 트러블슈팅 과정을 직접 설명할 수 있다면 AI 활용 역시 충분히 강점이 될 수 있다.

이 이야기를 들으며 CampusLog 개발 과정도 단순히 “Codex를 활용해 서비스를 만들었다”로 정리해서는 안 된다고 생각했다.
우리가 어떤 문제를 발견했고, 왜 이 기능을 선택했으며, AI 결과의 과장을 어떻게 막았고, 응답 지연과 사용자 경험을 어떻게 개선했는지를 설명할 수 있어야 한다. 그것이 AI 시대에 프로젝트를 자신의 것으로 만드는 방법이라고 느꼈다.

서비스의 개수보다 실제 사용자가 남긴 지표

포트폴리오에 관한 대화에서는 여러 서비스를 빠르게 만드는 것보다 하나의 서비스를 실제로 운영하며 의미 있는 지표를 만드는 것이 중요하다는 조언도 들을 수 있었다.

AI를 이용하면 짧은 시간 안에 많은 결과물을 생성할 수 있다. 그러나 서비스의 개수가 많다는 사실만으로는 사용자의 문제를 해결했다는 것을 증명하기 어렵다.

한 개의 서비스를 만들더라도 실제 사용자에게 배포하고,

몇 명이 사용했는지
어떤 기능을 반복해서 이용했는지
어느 지점에서 이탈했는지
어떤 피드백이 개선으로 이어졌는지

를 설명할 수 있다면 훨씬 강한 프로젝트가 된다.

공모전이나 지원사업에서 좋은 결과를 얻지 못했다고 해서 서비스 자체가 실패한 것도 아니다. 심사에는 발표 방식과 평가 기준 등 여러 요소가 작용한다. 결국 서비스를 계속할지 중단할지는 실제 사용자에게 공개하고 피드백을 받은 뒤 판단해야 한다는 이야기가 인상 깊었다.
이번 대화를 통해 남은 기간 CampusLog에 필요한 것은 기능의 개수를 늘리는 것만이 아니라는 점을 다시 확인했다.

데모데이 이후 CampusLog가 나아갈 방향

이번 피드백을 바탕으로 최종 발표 전까지 다음 과제를 중점적으로 진행할 예정이다.

첫째, AI 분석과 추천 과정에 스트리밍 또는 명확한 진행 상태를 적용하고, 백그라운드 작업과 완료 알림을 통해 사용자가 기다리는 시간을 줄인다.
둘째, 이미지와 문서 등 다양한 형식의 기존 기록을 경험 데이터로 변환할 수 있도록 입력 방식을 확장한다.
셋째, 매일 짧은 기록을 활동 단위로 묶어주는 ‘오늘의 기록’을 구현해 경험을 작성하는 부담을 줄인다.
넷째, 개발 전공자뿐 아니라 기획, 마케팅, 경영 등 다양한 전공의 대학생을 대상으로 사용자 테스트를 진행한다. 우리가 익숙해서 지나친 부분을 실제 사용자의 관점에서 다시 확인할 계획이다.
마지막으로 자기소개서 초안 생성에서 끝나지 않고, 추천된 경험을 사용자가 직접 이해하고 설명할 수 있도록 면접 준비까지 연결되는 방향을 고민하려 한다.

중간 점검, 방향을 다시 잡는 시간

이번 데모데이는 현재까지 구현한 기능을 보여주는 중간 점검이었지만, 우리에게는 그 이상의 의미가 있었다.
다른 팀의 서비스를 보며 우리가 놓친 관점을 발견했고, 멘토 피드백을 통해 기술적인 개선점과 서비스가 지향해야 할 가치를 다시 생각할 수 있었다. 식사 자리에서는 발표 시간에 다루지 못했던 AI와 개발, 커리어, 창업에 대한 현실적인 이야기도 들을 수 있었다.

그중에서도 멘토님께서 소개해주신 문장이 오래 기억에 남았다.

“가장 안전했던 선택이 나를 위험하게 만들었고, 위험한 선택이 나를 안전하게 만들었다.”

물론 무작정 위험한 선택을 해야 한다는 의미는 아니다. 자신이 감당할 수 있는 범위에서 시도하고, 결과를 통해 다음 판단의 근거를 만드는 태도에 가까웠다.

CampusLog 역시 아직 완성된 서비스가 아니다. 응답 속도와 사용자 경험, 입력 부담, 실제 사용자 검증 등 해결해야 할 문제가 남아 있다.
그러나 아이디어를 문서로 정리하는 데서 멈추지 않고, 직접 작동하는 서비스를 만들어 사람들 앞에서 시연하고, 피드백을 받아 다시 개선하고 있다는 점에서 분명히 앞으로 나아가고 있다.

남은 기간에는 기능을 더 많이 만드는 것보다, CampusLog가 실제 대학생의 경험 관리 문제를 얼마나 잘 해결할 수 있는지 증명하는 데 집중하려 한다.

좋은 자리를 준비해주신 커널아카데미 운영진분들과 긴 시간 동안 각 팀의 발표를 듣고 구체적인 피드백을 전해주신 멘토님들, 그리고 서로의 프로젝트와 고민을 나눠준 UNIKER 1기 크루분들께 감사드린다.

이제 중간 데모를 넘어, 실제 사용자가 계속 사용하고 싶은 CampusLog를 만들어보려 한다.

[주간회GO 26년 7월 5주차] “가장 안전한 선택이 가장 위험한 선택이였고, 가장 위험한 선택이 가장 좋은 선택이였다. ” (스트레스 속에서 살아가기가 제목이였으나)

MKISOS — Mon, 3 Aug 2026 10:13:03 +0900

[주간회GO 26년 7월 5주차]

26년 7월 5주차

이번주에는 학생회 부장 회의 겸 회식 그리고 선임 정모형이 이제 학교가 방학을 해서 밥 사주러 오신다...
그리고 수강신청 장바구니도 있고 fly asia 회의랑 일정있고 토요일 교정과 월치료 가야하고 주말에 서울가서 건우랑 유니커 중간발표 준비하고 일요일에 네트워킹 + 중간 데모데이가 있다. 준비하고 하면 바쁠 것 같지만 내가 안바쁜적이 어딨어 그냥 해내야지 파이팅!

진짜 일정이 너무 많으니 일을 처리하는 것도 힘든데 그 일정들을 조율하는게 다른 여러 사람들이 엮여있으니 많이 죄송하고 힘든 것 같다. 일정이 안맞을 수 있겠다는 불안감도 있고 그게 다 정해지지 않은채 하루 하루 흘러가니 스크레스가 항상 남아있는 것 같다.
거기다가 수간신청도 메일로 빌어서 넣어야해서 정해지지 않아서 너무 스트레스다 미추어버리겠다… (내가 저지른 일이니 참아야지 재입학을 했어야했는데 그냥 학고 반수를 해가지고,,,)

이 사진 하나로 꾸준함 인정?!
미래의 나야 계속 꾸준해라 복학해도 할 수 있지? 새로운 루틴을 잘 만들어보자. 학교 다니더라도 더욱 더 완벽한 루틴 가능할거야.

26년 7월 27일 월요일

월요일은 고정 루틴이 많아 아침에 바쁘다.
점심시간에 약국가서 벌레 물린거 진물 올라와서 밴드하나 샀다.
그리고 정모형 학교 방학해서 구청 놀러와서 후임 4명 밥사주심 ㄷㄷ
오랜만에 봐도 잘생겼더라;;

점심에 같이 이야기하면서 운동도 깔짝했다

요즘 우편 업무 일이 너무 많아서 미쳐버리겠음.
할게 너무 많은데 ㅠㅠ
곧 소해인데 제발,,,

시립대는 ㄹㅈㄷ네 ㅜㅜ

L 학생회 부장모임
+ 진호 주호 생일파티

26년 7월 28일 화요일

술마시고 운동 갈지 말지 오만번 고민하다가 하루 망칠까봐 루틴을 위해서 가서 가볍게 하고 왔다.

아침마다 내가 다 혼동스럽다 ㅜㅠ

최대한 아껴도 살 건 사야지… ㅠ

드디어 제출했네 제출기간 체크 못해서 늦은 제출했다 ㅠㅠ
아 짜증나

2시간만에 주문해서 받았다 진짜 ㄷㄷ 최고

닭가슴살들 정리하고 밥먹고
저렇게만 먹을랬다가 최근에 입터져서 배송받은거 한 5개 더 까먹음 ㅠ

26년 7월 29일 수요일

회의하면서 운동완료~

이거 벌써 4일째인데 진물밴드 붙여도 아직 이러네

아 수강신청 스트레스받아
제발 무사히 지나가길

코덱스앰버서더인 한서우 강사님이 추천해주셔서 지원 완료!

점심 먹고 수박 푸파했다

오후에 갑자기 여유로워서 ADsP 좀 했다.
야호~ 퇴근하고 쉴 수 있었다 ㅎㅎ
오랜만에

26년 7월 30일 목요일

새벽에 일어나자마자 예상했던 일이 일어났네
다행히 금리는 동결..

오운완
넘 피로하다.

갑자기 두부 안먹은 지 일주일이라 집가다가 다시 돌아서서 아침에 두부사서 왔다. 생각해보니 점심때 사도 되는 거였어.

8월 엄청 바쁘고 힘들 것 같다.
그만큼 시간이 빠를 것 같고
무너지지 말고 하던대로 루틴지키고 조금만 고생하자

개강하면 이 루틴 싹 바뀌고 새로운 루틴 정착해야지.

요즘 피로가 쌓여서 매일 점심 이후 카페인 들이 붓는 중… 내일까지만 들이 붓고 다음주는 자제 해볼까 생각중이다.
(저거 먹고 수박에 베이글에 더 먹음 ㅎㅎ)

곧 3천만원 있어야 개별 레버리지 가능해서 호기심 가득했음 + 저 분 하이닉스가 주된 종목인데 저점이라고 생각이 들었다. 앞으로 더 지켜봐야겠지만

퇴근 후 문풀!
일주일 남았네

저녁 먹고 새로운 식단 소분했음
궁금하네

26년 7월 31일 금요일

요즘 새벽에 자주 깨네 인바디 결과도 골격근량 많이 줄어서 우울하다 기계의 오류겠지만.. 그냥 꾸준히 하자

내일부터 규제인 줄 알았는데 오늘부터였어

결국 상 마감

오늘 점심 저 고기 너무 맛도리라 놀랐다.

수박 통 크기에 맞추어 자르기 장인임 ㅎㅎ

26년 8월 1, 2일 토,일요일 주말

오늘 많이 먹을 거 같아서 운동 가기 싫어도 다녀왔다.

치과 월치료 클리어
데스크 쌤들이 칭찬해줬다.

치료가 일찍 끝나서 서울가는 버스 시간 바꿔서 1시간 일찍 출발

건우가 식단 웰컴드링크 해줬다. 집이 야무지다. 이재 냉장고도 알차고

1차 2차 3차 4차 … 어제 몇차까지 한지…

비비큐 신메뉴 먹음. 근데 사실 교정과 다녀온 당일이라서 돌덩이 씹는 느낌이 조금 있었다.

중간에 잠깐 시뮬레이션 돌리고 오류 고치고 발표준비 못했다.

여기서도 수박자르기
남은 건 건우가 맛나게 먹길

커널아카데미 너무 좋은 시간이였다.
멘토님도 좋았고 레크레이션 조원들도 마음에 들었다.
배울 점도 많았고
나도 더 나은 더 멋진 사람이 되어야겠다.
하루 하루 조금씩 더 성장하자.

“가장 안전한 선택이 가장 위험한 선택이였고, 가장 위험한 선택이 가장 좋은 선택이였다. ”

경제금융용어 공부 579 : 카르텔

MKISOS — Sun, 2 Aug 2026 21:00:13 +0900

카르텔

기업들이 경쟁하지 않고 가격이나 생산량을 서로 합의하면 소비자는 더 비싼 가격을 부담하고 선택권도 줄어들 수 있다. 이러한 기업 간 담합 조직을 카르텔이라고 한다. 카르텔은 참여 기업의 이익을 높일 수 있지만 시장 경쟁을 훼손하고 경제 전체의 효율성을 떨어뜨리기 때문에 일반적으로 강하게 규제된다.

1. 한 줄 정의

카르텔은 경쟁 기업들이 가격, 생산량, 판매지역 등을 서로 합의하여 경쟁을 제한하는 기업연합이다.

2. 기본 개념

카르텔(Cartel)은 같은 산업이나 유사한 산업에서 경쟁하는 기업들이 서로 협약을 맺어 시장 경쟁을 줄이는 행위를 의미한다.

기업들은 원래 가격, 품질, 기술력 등을 통해 경쟁해야 한다. 그러나 카르텔에 참여한 기업들은 서로 경쟁하는 대신 다음과 같은 내용을 합의할 수 있다.

제품 가격
생산량
판매지역
거래 상대방
입찰가격
시장점유율

이처럼 기업들이 행동을 공동으로 조정하면 사실상 하나의 독점기업처럼 시장에 영향력을 행사할 수 있다.

카르텔은 공식적인 조직으로 만들어질 수도 있지만, 기업들이 비밀리에 연락해 가격이나 입찰 결과를 정하는 형태로 이루어지는 경우가 많다. 일반적으로 이러한 행위는 담합이라고 부른다.

3. 왜 중요한가

시장경제에서는 기업 간 경쟁이 가격을 낮추고 품질과 기술 발전을 촉진한다.

하지만 기업들이 카르텔을 형성하면 경쟁 압력이 사라진다. 그 결과 기업은 생산비용이 줄지 않았는데도 가격을 높이거나 생산량을 줄여 더 많은 이익을 얻을 수 있다.

반면 소비자는 더 높은 가격을 부담하고 선택할 수 있는 상품도 줄어든다. 신규 기업 역시 시장에 진입하기 어려워질 수 있다.

따라서 카르텔은 단순한 기업 간 협력을 넘어 시장 전체의 공정성과 효율성을 훼손하는 행위로 평가된다.

4. 쉽게 이해하는 예시

실생활 예시

학교 앞에 카페가 세 곳 있다고 가정해보자.

원래는 각 카페가 학생을 유치하기 위해 아메리카노 가격을 낮추거나 서비스를 개선해야 한다.

그런데 세 카페 사장이 몰래 만나 아메리카노 가격을 모두 5,000원으로 정하고 할인도 하지 않기로 합의했다면 카르텔과 비슷한 상황이다.

학생들은 다른 카페를 선택해도 같은 가격을 내야 하므로 경쟁의 혜택을 받지 못한다.

기업 예시

시멘트 회사들이 공급가격을 공동으로 올리고 회사별 생산량까지 미리 나누기로 합의했다고 가정해보자.

각 기업은 가격 경쟁을 피할 수 있어 이익이 증가할 수 있다. 하지만 건설회사는 더 비싼 시멘트를 구매해야 하고, 이는 건축비와 주택가격 상승으로 이어질 수 있다.

입찰 예시

여러 건설사가 공공공사 입찰에 참여하면서 이번에는 A사가 낮은 가격을 쓰고, 다음 사업에서는 B사가 낙찰받도록 순서를 정할 수 있다.

이처럼 낙찰자와 입찰가격을 미리 조정하는 행위를 입찰담합이라고 하며, 대표적인 카르텔 행위에 해당한다.

국제경제 예시

석유를 생산하는 국가들이 원유 생산량을 조절하면 국제 유가에 큰 영향을 줄 수 있다.

석유수출국기구(OPEC)는 산유국들이 생산정책을 협의하는 대표적인 국제 협력체이다. 다만 국가 간 협의체인 OPEC은 일반적인 국내 기업 카르텔과 법적 성격이 완전히 같지는 않다.

5. 핵심 특징

5-1. 경쟁 기업들이 공동으로 행동한다

카르텔은 서로 경쟁해야 할 기업들이 가격과 생산량 등을 함께 결정하는 것이 핵심이다.

겉으로는 별개의 기업이지만 실제 시장에서는 하나의 독점기업처럼 행동할 수 있다.

5-2. 과점시장에서 형성되기 쉽다

시장에 기업이 수백 개 존재하면 모든 기업이 합의하고 이를 감시하기 어렵다.

반면 몇 개 기업이 시장 대부분을 차지하는 과점시장에서는 합의할 상대가 적어 카르텔이 형성되기 쉽다.

5-3. 소비자 후생을 감소시킨다

카르텔은 가격 상승, 생산량 감소, 품질 개선 둔화로 이어질 수 있다.

기업은 이익을 얻지만 소비자와 다른 산업은 비용을 부담하게 된다.

5-4. 내부적으로 불안정할 수 있다

카르텔 참여 기업은 공동으로 가격을 높이면서도 자신만 몰래 가격을 낮춰 더 많은 고객을 확보하려는 유인을 가진다.

따라서 구성원 사이의 감시와 신뢰가 무너지면 카르텔도 쉽게 붕괴할 수 있다.

6. 관련 개념과의 차이

카르텔 vs 독점

카르텔

여러 기업이 존재함
기업들이 경쟁을 제한하기로 합의함
가격과 생산량을 공동으로 조정함

독점

한 기업이 시장을 사실상 지배함
실질적인 경쟁자가 거의 없음
한 기업이 가격과 생산량에 큰 영향력을 행사함

카르텔은 여러 기업이 연합해 독점기업처럼 행동하는 구조이고, 독점은 처음부터 한 기업이 시장을 지배하는 상태이다.

카르텔 vs 과점

카르텔

기업 간 명시적 또는 암묵적 합의가 핵심임
경쟁을 의도적으로 제한함
일반적으로 규제 대상임

과점

소수 기업이 시장 대부분을 차지한 시장구조임
기업 간 합의가 반드시 존재하는 것은 아님
그 자체만으로 불법은 아님

과점은 시장의 형태이고, 카르텔은 과점기업들이 담합하는 행동이다.

카르텔 vs 기업 간 정상적인 협력

카르텔

가격이나 생산량을 공동으로 결정함
시장 경쟁을 제한하는 것이 목적임
소비자 피해 가능성이 큼

정상적인 협력

공동 연구개발이나 기술표준 구축 등을 목적으로 함
생산성과 혁신을 높일 수 있음
경쟁을 부당하게 제한하지 않는 범위에서 이루어짐

기업들이 협력한다고 해서 모두 카르텔은 아니다. 경쟁 제한의 목적과 효과가 있는지가 중요한 판단 기준이다.

7. 경제적 의미

국가경제 관점

카르텔은 시장가격을 왜곡하고 자원이 효율적으로 배분되는 것을 방해한다.

비효율적인 기업도 높은 가격을 유지하며 생존할 수 있어 산업 전체의 생산성과 경제성장이 둔화될 수 있다.

기업 관점

카르텔 참여 기업은 가격 경쟁을 피하고 단기적으로 높은 이익을 얻을 수 있다.

그러나 담합이 적발되면 과징금, 손해배상, 형사처벌과 함께 기업 이미지 훼손이라는 큰 비용을 부담할 수 있다.

금융시장 관점

카르텔 적발은 기업의 수익성과 주가에 직접적인 영향을 줄 수 있다.

대규모 과징금뿐 아니라 향후 가격 인하, 소송비용, 거래처 이탈까지 발생할 수 있기 때문이다.

투자 관점

독과점적 시장지위를 가진 기업은 높은 수익성을 보일 수 있지만, 그 수익이 경쟁력에서 나온 것인지 담합 가능성에서 나온 것인지 구분해야 한다.

투자자는 시장점유율과 이익률뿐 아니라 공정거래 조사, 과징금, 소송과 같은 규제 위험도 함께 살펴봐야 한다.

8. 정리

카르텔은 경쟁 관계에 있는 기업들이 가격, 생산량, 판매지역 등을 합의하여 시장 경쟁을 제한하는 기업연합이다. 주로 소수 기업이 시장을 지배하는 과점산업에서 형성되기 쉽다. 참여 기업은 더 많은 이익을 얻을 수 있지만 소비자는 높은 가격과 제한된 선택권이라는 피해를 입는다. 따라서 카르텔은 시장경제의 효율성과 공정성을 훼손하는 행위로서 대부분의 국가에서 엄격하게 금지하고 규제한다.

경제금융용어 공부 578 : 치킨게임

MKISOS — Sat, 1 Aug 2026 21:00:13 +0900

치킨게임

치킨게임은 서로 양보하지 않고 끝까지 버티면 결국 모두가 큰 피해를 입게 되는 경쟁 상황을 의미한다. 경제에서는 기업 간 가격 경쟁, 국가 간 무역 갈등, 노사 협상 등에서 자주 등장하는 개념이다. 상대를 압박하려다 자신도 함께 손해를 볼 수 있다는 점이 핵심이다.

1. 한 줄 정의

치킨게임은 상대방이 먼저 포기하기를 기대하며 끝까지 버티다가, 모두가 최악의 결과를 맞을 수도 있는 전략적 경쟁 상황이다.

2. 기본 개념

치킨게임(Chicken Game)은 게임이론의 대표적인 사례 중 하나이다.

이 용어는 두 사람이 서로 마주 보고 자동차를 몰다가 먼저 방향을 틀면 겁쟁이(Chicken)로 취급받던 미국의 놀이에서 유래했다.

양쪽 모두 끝까지 버티면 자동차가 충돌하여 둘 다 큰 피해를 입는다.

경제에서도 비슷한 상황이 자주 발생한다. 서로 양보하지 않고 자신의 이익만 추구하면 결국 모두 손실을 입게 되는 상황을 치킨게임이라고 한다.

3. 왜 중요한가

경제는 여러 기업과 국가가 서로 영향을 주고받으며 움직인다.

만약 모든 경제주체가 자신의 이익만을 위해 끝까지 경쟁한다면 시장 전체가 불안정해질 수 있다.

따라서 정부, 기업, 국가들은 협상과 타협을 통해 치킨게임이 실제 충돌로 이어지는 것을 막으려 한다.

치킨게임은 협상의 중요성과 전략적 의사결정을 이해하는 데 매우 중요한 개념이다.

4. 쉽게 이해하는 예시

실생활 예시

친구 두 명이 서로 먼저 사과하지 않겠다고 버틴다고 가정해보자.

한 명이 먼저 사과하면 자존심은 조금 상하지만 관계는 회복된다.

하지만 둘 다 끝까지 버티면 친구 관계 자체가 깨질 수도 있다.

이것이 치킨게임의 구조이다.

기업 예시

두 치킨 프랜차이즈가 경쟁사를 이기기 위해 가격을 계속 낮춘다고 가정해보자.

처음에는 소비자가 혜택을 보지만, 경쟁이 과열되면 두 기업 모두 수익이 감소하여 큰 손실을 입을 수 있다.

국제경제 예시

두 나라가 서로 높은 관세를 부과하며 무역전쟁을 벌인다고 가정해보자.

한 나라가 먼저 양보하면 불리해질 수 있지만, 양국 모두 끝까지 맞서면 교역이 줄어들고 두 나라 경제 모두 피해를 입는다.

5. 핵심 특징

5-1. 서로 양보하지 않는 전략이다

참여자들은 상대방이 먼저 포기하기를 기대하며 자신의 입장을 유지한다.

5-2. 최악의 결과가 발생할 수 있다

양쪽 모두 끝까지 버티면 모두 큰 손실을 입는다.

개인의 합리적인 선택이 전체적으로는 비합리적인 결과를 만들 수 있다.

5-3. 협상과 신뢰가 중요하다

치킨게임이 반복되면 상대방도 손해를 본다는 사실을 알게 되어 타협과 협력이 이루어질 가능성이 높아진다.

6. 관련 개념과의 차이

치킨게임 vs 죄수의 딜레마

치킨게임

서로 양보하지 않으면 모두 피해를 입음
한쪽만 양보하면 다른 한쪽이 가장 큰 이익을 얻음
협상과 압박 전략이 중요함

죄수의 딜레마

서로 협력하는 것이 가장 좋지만
상대를 믿지 못해 결국 둘 다 손해를 보는 결과가 나타남

즉, 치킨게임은 누가 먼저 양보하느냐가 핵심이고, 죄수의 딜레마는 신뢰 부족으로 협력이 실패하는 상황이 핵심이다.

치킨게임 vs 가격경쟁

치킨게임

전략적 대립 상황 전체를 의미
기업, 국가, 정치, 외교 등 다양한 분야에서 사용

가격경쟁

가격 인하를 통한 경쟁 전략
과도한 가격경쟁이 계속되면 치킨게임으로 발전할 수 있음

즉, 가격경쟁은 치킨게임이 나타나는 대표적인 사례 가운데 하나이다.

7. 경제적 의미

국가경제 관점

국가 간 무역분쟁이나 관세 전쟁은 치킨게임의 대표적인 사례이다.

양국이 모두 강경한 태도를 유지하면 결국 세계경제까지 부정적인 영향을 받을 수 있다.

기업 관점

기업들은 시장점유율을 높이기 위해 공격적인 경쟁을 벌인다.

그러나 지나친 가격 인하나 과도한 투자 경쟁은 결국 기업의 수익성과 재무건전성을 악화시킬 수 있다.

금융시장 관점

금융시장에서도 국가나 기업의 강경한 정책 대립은 투자심리를 위축시키고 시장 변동성을 확대할 수 있다.

투자 관점

투자자는 특정 산업에서 치킨게임이 발생하는지 주의 깊게 살펴볼 필요가 있다.

가격 경쟁이 심해질수록 기업의 이익이 감소할 가능성이 높으며, 장기적으로는 주가에도 부정적인 영향을 줄 수 있다.

8. 정리

치킨게임은 상대방이 먼저 포기하기를 기대하며 끝까지 버티는 전략적 경쟁 상황을 의미한다. 하지만 양측 모두 양보하지 않으면 모두가 큰 손실을 입을 수 있다는 점이 특징이다. 경제에서는 가격 경쟁, 무역 분쟁, 노사 협상 등 다양한 상황에서 나타나며, 협상과 타협의 중요성을 설명하는 대표적인 게임이론 개념으로 활용된다.

경제금융용어 공부 577 : 치앙마이 이니셔티브(CMI)

MKISOS — Fri, 31 Jul 2026 21:00:17 +0900

치앙마이 이니셔티브(CMI)

아시아 외환위기 이후 아시아 국가들은 위기가 발생했을 때 서로 도와줄 수 있는 금융안전망의 필요성을 절실히 느꼈다. 그 결과 만들어진 것이 바로 치앙마이 이니셔티브(CMI)이다. 이후 이 제도는 여러 국가가 함께 참여하는 다자간 금융지원 체계인 CMIM으로 발전하면서 아시아를 대표하는 지역 금융안전망으로 자리 잡았다.

1. 한 줄 정의

치앙마이 이니셔티브(CMI)는 아시아 국가들이 금융위기 발생 시 서로 외화를 지원하기 위해 만든 지역 금융협력 체제이다.

2. 기본 개념

치앙마이 이니셔티브(CMI, Chiang Mai Initiative)는 2000년 태국 치앙마이에서 열린 ASEAN+3(아세안 10개국 + 한국·중국·일본) 재무장관회의에서 출범한 금융협력 체제이다.

이 제도는 1997년 아시아 외환위기의 경험을 바탕으로 만들어졌다.

당시 많은 아시아 국가들은 외환보유액이 부족해 국제통화기금(IMF)의 구제금융을 받을 수밖에 없었다.

이러한 상황을 반복하지 않기 위해 아시아 국가들이 서로 외화를 빌려주고 금융위기에 공동 대응하는 체계를 구축한 것이다.

처음에는 국가 간 양자 통화스왑 방식으로 운영되었지만, 이후 여러 한계를 보완하기 위해 CMIM(치앙마이 이니셔티브 다자화 협정)으로 발전하였다.

3. 왜 중요한가

국가도 갑자기 외화가 부족해질 수 있다.

외국인 투자자가 한꺼번에 자금을 회수하거나 환율이 급등하면 외환보유액이 빠르게 감소하면서 금융위기로 이어질 수 있다.

치앙마이 이니셔티브는 이러한 상황에서 아시아 국가들이 서로 외화를 지원하여 위기를 조기에 막기 위해 만들어졌다.

즉, 아시아 지역만의 금융 안전망을 구축하려는 노력이라고 볼 수 있다.

4. 쉽게 이해하는 예시

실생활 예시

친구 10명이 비상금을 함께 모아두었다고 가정해보자.

갑자기 한 친구에게 큰돈이 필요하면 공동으로 모아둔 돈을 빌려주고, 이후 상황이 좋아지면 다시 갚는 방식이다.

치앙마이 이니셔티브도 국가들이 서로 비상시에 외화를 지원하는 원리와 비슷하다.

경제 예시

어느 아시아 국가에서 외국인 투자자들이 대규모로 자금을 빼가면서 달러가 부족해졌다고 가정해보자.

이때 다른 회원국들이 외화를 지원하면 해당 국가는 외환위기를 완화할 수 있다.

한국 예시

우리나라 역시 ASEAN+3 회원국으로 참여하고 있으며, 역내 금융안전망 구축에 중요한 역할을 하고 있다.

5. 핵심 특징

5-1. 아시아 지역 금융안전망이다

CMI는 아시아 국가들이 금융위기에 공동 대응하기 위해 만든 지역 금융협력 제도이다.

국제적인 금융안전망을 지역 차원에서 보완하는 역할을 한다.

5-2. 통화스왑을 기반으로 한다

회원국들은 필요할 경우 서로 외화를 빌려줄 수 있도록 통화스왑 계약을 체결한다.

이를 통해 외환 유동성 부족 문제를 해결할 수 있다.

5-3. CMIM으로 확대·발전했다

초기의 CMI는 국가 간 개별 통화스왑 중심이었다.

하지만 위기 대응 능력을 높이기 위해 2010년 CMIM이 출범하면서 공동기금을 활용하는 다자간 금융지원 체계로 발전하였다.

5-4. AMRO가 경제를 감시한다

2011년에는 AMRO(ASEAN+3 Macroeconomic Research Office)가 설립되어 회원국들의 거시경제와 금융상황을 지속적으로 분석하고 위기 가능성을 점검하고 있다.

6. 관련 개념과의 차이

치앙마이 이니셔티브(CMI) vs CMIM

CMI

2000년 출범
국가 간 양자 통화스왑 중심
초기 금융협력 체제

CMIM

2010년 출범
다자간 공동기금 운영
위기 대응 능력 강화

즉 CMIM은 CMI를 한 단계 발전시킨 제도이다.

치앙마이 이니셔티브 vs IMF

치앙마이 이니셔티브

아시아 지역 국가들의 금융협력
지역 금융안전망
ASEAN+3 중심

IMF

전 세계 국가 대상
국제 금융기구
글로벌 금융안전망

CMI는 지역 단위의 안전망이고, IMF는 전 세계를 대상으로 하는 국제기구라는 차이가 있다.

7. 경제적 의미

국가경제 관점

치앙마이 이니셔티브는 외환위기 발생 시 회원국들이 공동 대응할 수 있도록 하여 아시아 금융시장의 안정성을 높이는 역할을 한다.

기업 관점

외환시장이 안정되면 기업들은 환율 급등에 따른 위험을 줄이고 해외 무역과 투자 활동을 보다 안정적으로 수행할 수 있다.

금융시장 관점

CMI와 CMIM은 외환시장 불안을 완화하고 금융위기의 전염 가능성을 줄이는 중요한 지역 금융안전망으로 평가된다.

또한 AMRO의 경제 감시는 위기 조기 경보 시스템 역할도 수행한다.

투자 관점

투자자는 아시아 금융시장의 안정성을 판단할 때 CMIM과 같은 지역 금융안전망의 존재를 긍정적으로 평가한다.

회원국 간 협력이 강화될수록 외환위기 가능성이 낮아지고 투자심리도 안정될 수 있다.

8. 정리

치앙마이 이니셔티브(CMI)는 1997년 아시아 외환위기의 경험을 바탕으로 아시아 국가들이 금융위기에 공동 대응하기 위해 만든 지역 금융협력 체제이다. 초기에는 국가 간 양자 통화스왑 방식으로 운영되었지만, 2010년에는 공동기금을 기반으로 하는 CMIM으로 발전하면서 위기 대응 능력이 크게 강화되었다. 또한 AMRO가 회원국의 경제와 금융상황을 감시하며 지역 금융안전망을 뒷받침하고 있다. 치앙마이 이니셔티브는 오늘날 아시아 금융안정을 위한 대표적인 협력 제도로 평가받고 있다.

경제금융용어 공부 576 : 출자총액제한제도

MKISOS — Thu, 30 Jul 2026 21:00:48 +0900

출자총액제한제도

대기업이 여러 회사를 계속 사들이거나 계열사를 무분별하게 늘리면 시장 경쟁이 약해지고 경제력이 일부 기업에 집중될 수 있다. 이를 막기 위해 과거 우리나라에서는 대기업의 출자 규모를 제한하는 제도를 운영했다. 이것이 바로 출자총액제한제도이다. 현재는 폐지되었지만, 우리나라 공정거래 정책의 역사를 이해하는 데 중요한 제도이다.

1. 한 줄 정의

출자총액제한제도는 대기업이 다른 회사에 투자할 수 있는 금액을 일정 한도 내로 제한했던 제도이다.

2. 기본 개념

출자총액제한제도는 대기업집단이 계열사나 다른 국내 기업에 과도하게 출자하는 것을 제한하기 위해 도입된 제도이다.

과거 공정거래법에서는 일정 규모 이상의 대기업이 다른 국내 회사에 투자할 수 있는 금액을 순자산의 40% 이내로 제한하였다.

이 제도의 목적은 대기업이 계열사를 무분별하게 늘리거나 경제력을 과도하게 집중시키는 것을 막는 것이었다.

하지만 기업 활동을 지나치게 제한한다는 의견도 있었기 때문에 폐지와 재도입을 반복하다가 2009년에 최종 폐지되었다.

3. 왜 중요한가

대기업은 막대한 자금을 이용해 다른 회사를 계속 인수하거나 계열사를 늘릴 수 있다.

이 과정이 지나치게 확대되면 시장 경쟁이 줄어들고 특정 기업집단의 영향력이 과도하게 커질 수 있다.

출자총액제한제도는 이러한 경제력 집중을 막고 공정한 경쟁 환경을 만들기 위해 도입되었다.

반면 기업 입장에서는 필요한 투자와 인수합병(M&A)이 제한될 수 있어 기업 경쟁력을 떨어뜨릴 수 있다는 비판도 있었다.

4. 쉽게 이해하는 예시

실생활 예시

한 학생이 학교 동아리 대부분에 회장이나 임원으로 참여한다고 가정해보자.

처음에는 문제가 없어 보일 수 있지만, 시간이 지나면 대부분의 의사결정을 한 사람이 좌우하게 될 수 있다.

출자총액제한제도는 이러한 독점을 막기 위한 규칙과 비슷한 역할을 한다.

기업 예시

A그룹이 이미 여러 계열사를 보유하고 있는데 또 다른 회사를 계속 인수하려고 한다.

출자총액제한제도가 시행 중이라면 일정 한도를 초과하는 추가 출자는 제한될 수 있었다.

경제 예시

정부는 특정 대기업이 지나치게 많은 기업을 지배하는 것을 방지하여 다양한 기업이 경쟁할 수 있는 시장을 만들고자 했다.

5. 핵심 특징

5-1. 대기업의 출자 규모를 제한했다

일정 규모 이상의 대기업은 다른 국내 기업에 무제한으로 투자할 수 없었다.

순자산의 일정 비율을 넘는 출자는 제한되었다.

5-2. 경제력 집중을 방지하기 위한 제도였다

소수 대기업이 시장을 과도하게 지배하는 것을 막고 공정한 경쟁을 유도하는 것이 목적이었다.

5-3. 여러 차례 폐지와 재도입을 반복했다

1997년 외환위기 직전 폐지되었다가, 2002년 다시 도입되었으며, 기업 규제 완화 정책에 따라 2009년 최종 폐지되었다.

6. 관련 개념과의 차이

출자총액제한제도 vs M&A

출자총액제한제도

대기업의 출자 규모를 제한하는 규제
경제력 집중 방지가 목적

M&A(인수합병)

기업이 다른 기업을 인수하거나 합병하는 경영 전략
성장과 사업 확장이 목적

즉 M&A는 기업의 경영활동이고, 출자총액제한제도는 이러한 활동을 일정 범위에서 제한하는 규제이다.

출자총액제한제도 vs 기업집단 규제

출자총액제한제도

출자 규모 자체를 제한

기업집단 규제

내부거래, 순환출자, 지배구조 등 다양한 분야를 규제

출자총액제한제도는 기업집단 규제 가운데 하나였다고 볼 수 있다.

7. 경제적 의미

국가경제 관점

출자총액제한제도는 경제력 집중을 완화하고 공정한 시장 경쟁을 촉진하기 위한 정책이었다.

반면 기업의 투자와 성장을 제한할 수 있다는 논란도 함께 존재했다.

기업 관점

대기업은 신규 투자나 계열사 확대에 제약을 받을 수 있었다.

반대로 중소기업은 대기업의 시장 지배력이 완화되는 효과를 기대할 수 있었다.

금융시장 관점

출자 제한은 기업의 인수합병과 투자 규모에 영향을 미쳤으며, 기업집단의 지배구조 변화에도 영향을 주었다.

투자 관점

출자총액제한제도가 시행되면 대기업의 공격적인 M&A와 사업 확장이 제한될 수 있다.

반대로 규제가 완화되면 기업의 투자와 성장 전략이 활발해질 가능성이 있다.

8. 정리

출자총액제한제도는 대기업이 다른 기업에 투자할 수 있는 규모를 일정 한도 내로 제한했던 공정거래 제도이다. 경제력 집중을 방지하고 시장 경쟁을 촉진하기 위해 도입되었지만, 기업의 투자와 인수합병을 제한한다는 비판도 받았다. 우리나라에서는 1987년 도입 이후 폐지와 재도입을 반복하다가 2009년에 최종 폐지되었다. 현재는 시행되지 않지만, 우리나라 대기업 정책과 공정거래 제도의 변화를 이해하는 데 중요한 역사적 제도로 평가된다.

경제금융용어 공부 575 : 출금이체

MKISOS — Wed, 29 Jul 2026 21:00:44 +0900

출금이체

통신비나 보험료, 정기구독료가 매달 자동으로 빠져나가는 경험은 매우 익숙하다. 이처럼 돈을 받는 쪽이 사전 약정에 따라 지급인의 계좌에서 자금을 인출하도록 요청하는 방식이 출금이체이다. 출금이체는 반복적인 대금 수납을 자동화해 기업과 소비자 모두의 편의를 높이는 대표적인 계좌이체 방식이다.

1. 한 줄 정의

출금이체는 수취인이 지급인의 계좌에서 자금을 인출하도록 요청해 자신의 계좌로 이체받는 방식이다.

2. 기본 개념

출금이체(Debit Transfer)는 돈을 받는 사람이 거래 금융기관에 인출을 요청하여 지급인의 계좌에서 자금을 출금하고, 수취인의 계좌로 입금하는 계좌이체 방식이다.

핵심은 거래를 누가 시작하느냐에 있다.

일반적인 송금은 지급인이 직접 돈을 보내지만, 출금이체는 수취인이 사전 약정에 따라 지급인의 계좌에서 돈을 가져오는 방식이다.

대표적인 출금이체에는 다음과 같은 사례가 있다.

수표 추심
지로 자동이체
CMS 출금이체
보험료 자동납부
통신비 자동납부
정기구독료 자동결제

다만 수취인이 마음대로 출금할 수 있는 것은 아니며, 지급인의 사전 동의와 약정이 필요하다.

3. 왜 중요한가

기업이나 기관이 매달 수많은 고객으로부터 대금을 직접 받는다면 많은 시간과 비용이 발생한다.

출금이체를 이용하면 정해진 날짜에 자동으로 대금을 수납할 수 있어 업무 효율성이 높아진다.

소비자도 매번 직접 송금할 필요가 없어 납부기한을 놓치는 실수를 줄일 수 있다.

따라서 출금이체는 정기적이고 반복적인 대금 결제를 처리하는 데 매우 적합하다.

4. 쉽게 이해하는 예시

실생활 예시

매달 25일에 통신비 7만 원이 자동으로 계좌에서 빠져나간다고 가정해보자.

통신사가 사전에 동의받은 약정에 따라 고객 계좌에서 요금을 인출하고 자신의 계좌로 받는다.

이 과정이 출금이체이다.

대학생 예시

대학생이 온라인 강의 서비스를 구독하고 매월 자동결제를 등록했다고 가정해보자.

매달 결제일이 되면 서비스 제공업체가 학생의 계좌에서 구독료를 자동으로 인출한다.

기업 예시

학원이 수백 명의 수강생에게 매달 수강료를 받아야 한다면 CMS 출금이체를 이용할 수 있다.

학원은 등록된 계좌에서 정해진 날짜에 수강료를 자동으로 수납할 수 있다.

5. 핵심 특징

5-1. 수취인이 거래를 시작한다

출금이체는 돈을 받는 사람이 금융기관에 인출지시를 내리는 방식이다.

지급인이 직접 송금하는 입금이체와 가장 큰 차이이다.

5-2. 사전 동의가 필요하다

수취인은 지급인의 동의 없이 임의로 계좌에서 돈을 인출할 수 없다.

자동이체 약정이나 출금동의 절차가 먼저 이루어져야 한다.

5-3. 반복적인 대금 수납에 적합하다

통신비, 보험료, 공과금, 회비, 구독료처럼 정기적으로 발생하는 비용을 자동으로 수납하는 데 유용하다.

6. 관련 개념과의 차이

출금이체 vs 입금이체

출금이체

수취인이 거래를 시작함
지급인의 계좌에서 자금을 인출함
자동이체와 CMS 출금이체가 대표적임

입금이체

지급인이 거래를 시작함
지급인이 수취인 계좌로 직접 송금함
일반 계좌이체가 대표적임

즉 출금이체는 돈을 받을 사람이 당기고, 입금이체는 돈을 줄 사람이 보내는 방식이다.

출금이체 vs 추심

출금이체

계좌에서 자금을 자동으로 인출하는 방식
정기결제와 대량 수납에 많이 활용됨

추심

은행이 어음이나 수표의 대금을 대신 받아주는 절차
지급수단의 대금 회수에 초점이 있음

출금이체는 계좌 기반의 자동 인출이고, 추심은 어음이나 수표 등의 대금을 회수하는 더 넓은 절차이다.

지로 자동이체 vs CMS 출금이체

지로 자동이체

공공요금이나 정기 납부에 많이 활용됨
지로시스템을 통해 처리됨

CMS 출금이체

기업과 기관의 대량 수납에 활용됨
회비, 보험료, 수강료, 렌탈료 등에 널리 사용됨

두 방식 모두 수취인의 인출지시에 따라 지급인의 계좌에서 돈이 빠져나간다는 공통점이 있다.

7. 경제적 의미

국가경제 관점

출금이체는 반복적인 결제를 자동화하여 지급결제시스템의 효율성을 높인다.

현금 사용과 수작업 처리를 줄여 경제 전체의 거래비용을 낮추는 효과도 있다.

기업 관점

기업은 대금 수납 업무를 자동화하고 미수금과 납부 지연을 줄일 수 있다.

특히 정기적인 매출이 발생하는 구독형 사업이나 렌탈업에서 중요하게 활용된다.

금융시장 관점

출금이체는 지로시스템과 CMS공동망 등 소액결제시스템의 주요 기능이다.

안전하고 안정적인 자동이체 처리는 금융 인프라에 대한 신뢰를 높인다.

투자 관점

출금이체 자체가 투자 대상은 아니지만, 자동결제와 정기구독이 확대되면 금융회사와 핀테크 기업의 결제서비스 수요가 증가할 수 있다.

투자자는 관련 기업을 분석할 때 결제 건수, 정기결제 고객, 수수료 구조 등을 함께 살펴볼 수 있다.

8. 정리

출금이체는 수취인이 사전 약정에 따라 지급인의 계좌에서 자금을 인출해 자신의 계좌로 받는 계좌이체 방식이다. 지로 자동이체, CMS 출금이체, 보험료와 통신비 자동납부 등이 대표적인 사례이다. 지급인이 직접 보내는 입금이체와 달리 수취인이 거래를 시작하지만, 반드시 지급인의 사전 동의가 필요하다. 출금이체는 반복적인 대금 수납을 자동화하여 소비자의 편의와 기업의 업무 효율성을 높이는 중요한 지급결제 방식이다.

경제금융용어 공부 574 : 출구전략(Exit Strategy)

MKISOS — Tue, 28 Jul 2026 21:00:57 +0900

출구전략(Exit Strategy)

경제위기가 발생하면 정부와 중앙은행은 금리를 낮추거나 돈을 많이 푸는 등 다양한 경기부양 정책을 시행한다. 하지만 위기가 지나간 뒤에도 이러한 정책을 계속 유지하면 물가 상승이나 자산시장 과열 같은 부작용이 나타날 수 있다. 이때 경제를 정상적인 상태로 되돌리기 위해 완화정책을 단계적으로 종료하는 과정을 출구전략이라고 한다.

1. 한 줄 정의

출구전략은 경제위기 대응을 위해 시행했던 경기부양 정책을 정상 수준으로 되돌리는 과정이다.

2. 기본 개념

출구전략(Exit Strategy)은 경제위기 극복을 위해 시행했던 저금리 정책, 양적완화, 유동성 공급 등의 완화정책을 점진적으로 축소하거나 종료하는 정책을 의미한다.

원래는 군사 용어였지만 현재는 경제 분야에서 더 많이 사용된다.

대표적으로 중앙은행이 기준금리를 다시 인상하거나, 시중에 공급했던 유동성을 회수하거나, 자산매입 규모를 줄이는 정책이 모두 출구전략에 해당한다.

즉, 위기 상황에서는 경제를 살리기 위해 적극적으로 지원하고, 경제가 회복되면 다시 정상적인 정책으로 복귀하는 과정이라고 이해하면 된다.

3. 왜 중요한가

경제위기 때는 돈을 많이 풀어 소비와 투자를 늘리는 것이 필요하다.

하지만 이러한 정책을 너무 오래 유지하면 물가가 급격히 오르거나 부동산과 주식 가격이 과도하게 상승하는 등 새로운 문제가 발생할 수 있다.

반대로 출구전략을 너무 빨리 시행하면 아직 회복되지 않은 경제가 다시 침체될 위험도 있다.

따라서 출구전략은 시기와 속도가 가장 중요한 경제정책 가운데 하나이다.

4. 쉽게 이해하는 예시

실생활 예시

감기에 걸렸을 때 강한 약을 복용한다고 생각해보자.

몸이 회복된 뒤에도 계속 같은 약을 먹으면 오히려 부작용이 생길 수 있다.

경제도 마찬가지로 위기 극복을 위한 정책은 회복 이후에는 점차 줄여야 한다.

경제 예시

2008년 글로벌 금융위기 이후 미국 연방준비제도(Fed)는 기준금리를 거의 0%까지 낮추고 대규모 양적완화를 실시했다.

이후 경제가 회복되자 기준금리를 인상하고 자산매입을 축소하는 출구전략을 추진하였다.

투자 예시

출구전략이 시작되면 시중 유동성이 줄어들 수 있기 때문에 주식시장이나 부동산시장에는 부담으로 작용하는 경우가 많다.

반면 예금금리와 채권금리는 상승하는 경우가 많아 투자환경에도 변화가 나타난다.

5. 핵심 특징

5-1. 경기부양 정책을 정상화한다

출구전략은 위기 대응을 위해 시행했던 비상 정책을 종료하고 평상시 정책으로 복귀하는 과정이다.

5-2. 중앙은행이 주도하는 경우가 많다

기준금리 인상, 양적완화 종료, 유동성 회수 등이 대표적인 출구전략이다.

5-3. 시행 시기가 매우 중요하다

너무 빠르면 경기 회복이 중단될 수 있고, 너무 늦으면 인플레이션과 자산버블이 심해질 수 있다.

6. 관련 개념과의 차이

출구전략 vs 양적완화(QE)

출구전략

경기부양 정책을 정상화하는 과정
금리 인상과 유동성 회수가 포함됨

양적완화(QE)

중앙은행이 채권 등을 매입하여 시중에 돈을 공급하는 정책
대표적인 경기부양 정책

즉 양적완화는 위기 대응 정책이고, 출구전략은 이러한 정책을 종료하는 과정이다.

출구전략 vs 제로금리정책

출구전략

제로금리를 종료하고 정상 금리로 복귀하는 과정

제로금리정책

기준금리를 매우 낮게 유지하여 경기 회복을 지원하는 정책

제로금리정책이 시작이라면 출구전략은 그 정책을 끝내는 단계라고 볼 수 있다.

7. 경제적 의미

국가경제 관점

출구전략은 경기 회복 이후 경제를 정상 궤도로 되돌리고 물가 안정과 금융안정을 유지하는 중요한 정책이다.

기업 관점

금리가 오르면 기업의 대출 부담이 커지고 투자 비용도 증가할 수 있다.

반면 경제가 정상화된다는 신호로 받아들여질 수도 있다.

금융시장 관점

출구전략은 주식시장, 채권시장, 외환시장 모두에 큰 영향을 미친다.

특히 금리 인상과 유동성 축소는 자산가격 변동성을 확대시키는 요인이 될 수 있다.

투자 관점

투자자는 중앙은행의 출구전략 시기와 속도를 매우 중요하게 살펴본다.

금리 상승기에는 성장주보다 가치주가 상대적으로 강세를 보이거나, 채권 수익률이 상승하는 등 투자환경이 크게 변화할 수 있다.

8. 정리

출구전략은 경제위기 극복을 위해 시행했던 저금리, 양적완화 등 경기부양 정책을 정상 수준으로 되돌리는 과정이다. 경제 회복 이후 물가 상승과 자산시장 과열을 막기 위해 시행되지만, 너무 빠르거나 늦으면 경제에 부정적인 영향을 줄 수 있다. 따라서 중앙은행은 경제성장률, 물가, 고용 등을 종합적으로 고려해 출구전략의 시기와 강도를 결정한다. 출구전략은 금융시장과 투자환경에도 큰 영향을 미치는 핵심 경제정책이다.

[UNIKER] CampusLog, AI 추천을 실제 취업 준비 흐름으로 확장하고 사용자 경험을 다듬다

MKISOS — Tue, 28 Jul 2026 06:17:59 +0900

지난 7월 19일 멘토링 이후 CampusLog 팀은 새로운 기능을 계속 추가하는 것보다 지금까지 구현한 기능들이 하나의 사용자 흐름으로 자연스럽게 연결되는지를 다시 점검했다.

CampusLog의 핵심 흐름은 대학생활 중 수행한 활동을 기록하고, 활동에서 얻은 경험을 AI가 분석한 뒤, 자기소개서·면접·채용공고 분석 등에 활용할 수 있도록 돕는 것이다.

기능 자체는 어느 정도 구현되어 있었지만 실제 서비스를 사용한다고 생각해보면 여전히 다듬어야 할 부분이 많았다.

기록을 작성하는 과정이 복잡하지 않은가
활동과 AI 분석 결과를 함께 보기 편한가
AI 추천 결과가 실제 취업 준비에 활용 가능한가
AI 응답을 기다리는 동안 사용자가 불안하거나 지루하지 않은가
모바일에서도 같은 흐름을 사용할 수 있는가

이번 주에는 이러한 질문을 기준으로 기록·분석·추천의 전체 경험을 정리했다.

날짜별 기록 흐름을 다시 설계하다

캘린더와 날짜별 기록 화면

먼저 ‘오늘의 기록’ 화면을 개선했다.

기존에는 캘린더와 기록 작성 기능이 각각 존재했지만, 사용자가 특정 날짜에 무엇을 기록했는지 빠르게 확인하기에는 다소 불편했다.

이를 개선하기 위해 캘린더 옆 영역을 선택한 날짜의 기록을 보여주는 날짜별 이벤트 목록으로 재구성했다. 사용자는 캘린더에서 날짜를 선택한 뒤 해당 날짜에 작성한 기록을 바로 확인하고, + 버튼을 눌러 새로운 기록을 추가할 수 있다.

기록 작성 시에는 진행 중인 활동을 선택하고 그날 수행한 내용을 입력하도록 구성했다. 활동 선택 UI도 검색 기능이 포함된 복잡한 입력창 대신, 현재 진행 중인 활동을 목록에서 선택하는 방식으로 단순화했다.

연도와 월을 직접 선택할 수 있는 기능도 추가했다. 과거 활동 기록을 확인하려는 사용자가 이전 달 버튼을 여러 번 누르지 않아도 원하는 시점으로 바로 이동할 수 있도록 했다.

활동 상태도 조금 더 명확하게 구분했다.

예상 종료일이 지났지만 사용자가 아직 종료 여부를 확정하지 않은 활동은 바로 완료 처리하지 않고 종료 확인 필요로 표시했다. 실제 활동은 끝났지만 아직 경험으로 정리하지 않은 경우에는 경험 정리 필요로 구분했다.

단순히 진행 중과 완료만 나누는 것보다 사용자가 지금 어떤 행동을 해야 하는지 알려주는 방향으로 상태를 재정리했다.

활동과 AI 분석 결과를 한 화면에서 확인하다

다음으로 ‘나의 활동’ 화면을 개선했다.

기존에는 활동 상세와 AI 분석 결과를 각각 다른 화면에서 확인해야 했다. 사용자가 원본 경험과 분석 결과를 비교하려면 화면을 여러 번 이동해야 했다.

이번 주에는 완료 경험을 선택하면 왼쪽에는 활동 상세, 오른쪽에는 AI 분석 결과가 표시되는 스플릿뷰를 구현했다.

이를 통해 사용자는 자신이 작성한 활동 내용과 AI가 정리한 STAR 구조, 주요 성과, 부족한 정보를 한 화면에서 비교할 수 있게 되었다. 화면이 좁은 모바일 환경에서는 두 영역이 세로로 배치되도록 반응형 구조도 적용했다.

페이지마다 제각각이었던 제목과 이동 구조도 정리했다. 오늘의 기록, 나의 활동, AI 추천과 각각의 상세 화면에 Breadcrumb을 적용하고 제목의 크기와 위치를 통일했다.

작은 수정처럼 보이지만 현재 위치와 이전 화면으로 돌아가는 경로가 명확해지면서 서비스 전체가 하나의 제품처럼 연결되기 시작했다.

부족한 경험 정보를 직접 보완하는 기능

AI 분석에서 발견한 부족한 정보도 분석 결과 안에서 바로 보완할 수 있도록 했다.

예를 들어 AI가 다음과 같은 정보를 추가로 요구할 수 있다.

프로젝트에서 본인이 직접 담당한 역할
문제를 해결하기 위해 시도한 구체적인 행동
결과를 확인할 수 있는 수치나 피드백
팀원과 의견이 충돌했을 때 해결한 과정

기존에는 이러한 질문이 모두 펼쳐진 상태로 표시되어 화면이 길고 복잡했다. 이번에는 질문을 하나씩 선택해 답변할 수 있는 형태로 변경했다.

질문을 누르면 같은 카드가 자연스럽게 확장되고, 답변을 작성한 뒤 저장할 수 있다. 한 번에 하나의 질문만 열리도록 하여 사용자가 현재 작성 중인 내용에 집중할 수 있게 했다.

저장된 보완 답변은 원본 경험을 임의로 변경하지 않는다. 대신 이후 AI 추천과 답변 초안을 생성할 때 추가 근거로 활용된다.

AI 추천을 실제 취업 준비 과정에 맞게 재구성하다

이번 주 가장 많은 변화가 있었던 부분은 AI 추천 기능이다.

초기에는 사용자가 질문을 입력하면 관련 경험을 추천하는 기능에 가까웠다. 하지만 실제 취업 준비에서는 면접 질문, 자기소개서 문항, 채용공고와 같이 목적에 따라 필요한 결과가 달라진다.

따라서 AI 추천의 활용 목적을 다음 네 가지로 정리했다.

면접
자기소개서
JD 분석
기타

각 목적에 따라 입력 안내, 예시 질문, 추천 기준, 결과 생성 방식이 달라지도록 구성했다.

면접에서는 질문에 답변하기 적합한 경험을 추천하고, 자기소개서에서는 지원 문항과 연결할 수 있는 경험을 찾는다. JD 분석에서는 채용공고의 담당 업무·필수 요건·우대 사항·기술 스택을 분해한 뒤 사용자의 경험과 비교한다.

AI가 근거가 부족한 경험을 억지로 세 개까지 추천하지 않도록 프롬프트도 수정했다. 추천 결과에는 단순한 적합도 점수뿐만 아니라 다음 내용을 함께 표시하도록 했다.

추천 이유
원본 경험에서 확인되는 직접 근거
아직 부족한 정보
과장해서 작성하면 안 되는 부분
해당 경험을 활용할 수 있는 방향

AI가 그럴듯한 문장을 만들어주는 데서 끝나는 것이 아니라, 사용자가 실제로 보유한 경험과 그렇지 않은 내용을 구분하도록 한 것이다.

AI 응답을 기다리는 과정도 사용자 경험이다

AI 기능을 테스트하면서 응답을 기다리는 시간이 생각보다 길게 느껴지는 문제가 있었다.

구조화된 분석 결과를 생성하려면 일반적인 짧은 텍스트 응답보다 시간이 오래 걸릴 수 있다. 단순한 로딩 스피너만 표시하면 사용자는 서비스가 정상적으로 작동하는지 알기 어렵다.

이를 개선하기 위해 먼저 현재 수행 중인 작업을 단계별로 보여주는 로딩 화면을 구현했다.

이후 답변 초안 생성에는 실제 텍스트가 점진적으로 나타나는 스트리밍 방식을 적용했다. 첫 문장이 생성되기 전에는 분석 중이라는 안내를 표시하고, 텍스트가 도착하기 시작하면 생성되는 답변과 현재 글자 수를 실시간으로 확인할 수 있다.

다만 화면에 표시된 일부 텍스트를 바로 저장하지는 않는다. AI 응답이 정상적으로 완료되고 최종 결과가 검증된 뒤에만 저장하도록 하여 중간에 끊긴 답변이 기록으로 남는 문제를 방지했다.

경험 분석, AI 추천, 활동 완료 경험 합성에서는 서버가 현재 진행 상태를 전달하는 이벤트 스트리밍을 적용했다. 사용자는 단순히 기다리는 것이 아니라 어떤 과정이 진행 중인지 확인할 수 있다.

AI 요청을 취소하는 기능도 추가했다. 취소한 요청은 오류처럼 표시하지 않고 기존 입력 내용을 그대로 유지해 같은 조건으로 다시 실행할 수 있다.

최종적으로 공용 AI 대기 화면에는 움직이는 Strands 배경과 단계별 안내 문구를 적용했다. 화려한 효과 자체가 목적이라기보다, 기다리는 동안 서비스가 정상적으로 처리 중이라는 피드백을 제공하는 데 중점을 두었다.

채용공고와 문항 캡처도 바로 입력할 수 있도록

자기소개서 문항이나 채용공고는 웹페이지에 있는 경우가 많다. 사용자가 내용을 모두 복사하거나 직접 입력해야 한다면 AI 추천 기능을 사용하는 것 자체가 번거로워질 수 있다.

이번 주에는 자기소개서 문항, 면접 질문, JD 캡처 이미지를 AI 추천에 바로 사용할 수 있도록 이미지 입력 기능을 구현했다.

JPG·PNG·WebP 이미지를 최대 3장까지 선택할 수 있으며, 추천 입력창에서 Cmd/Ctrl+V로 클립보드 이미지를 붙여넣는 것도 가능하다. 텍스트만 입력하거나 이미지만 첨부하거나, 두 방식을 함께 사용하는 것도 지원한다.

별도의 OCR 확인 화면을 추가하지 않고 기존 AI 추천 요청 안에서 이미지와 경험 데이터를 함께 처리한다. 원본 이미지는 서버나 데이터베이스에 저장하지 않고 요청이 끝난 뒤 폐기하도록 했다.

이미지 입력 관련 자동 테스트 65개와 데스크톱·모바일 UI 검증을 완료했으며, 실제 로그인 환경에서 추천 결과 저장과 새로고침 후 재조회하는 테스트는 추가로 진행할 예정이다.

활동 사진과 PDF 자료 보관 기능

완료한 활동에는 수료증, 발표 자료, 활동 사진, 결과 보고서처럼 나중에 다시 확인할 자료가 존재한다.

이를 기록할 수 있도록 완료 경험에 사진과 PDF 자료를 첨부하는 기능도 구현했다.

경험 하나당 최대 3개의 파일을 첨부할 수 있으며, 사용자별 비공개 저장 공간을 사용하도록 설계했다. 첨부한 파일은 일정 시간만 유효한 링크를 통해 열 수 있고, 경험을 삭제하면 연결된 파일도 함께 정리되도록 했다.

첨부 자료는 AI 분석 입력과 분리했다. 사용자가 단순히 보관 목적으로 올린 사진이나 PDF가 자동으로 AI에 전달되지 않도록 한 것이다.

관련 자동 테스트 49개와 반응형 UI 검증까지 완료했으며, 실제 Supabase 프로젝트에 마이그레이션을 적용한 뒤 업로드·조회·삭제 흐름을 최종 확인할 예정이다.

문기·건우·동현의 역할과 협업

이번 주에도 각자 맡은 영역을 중심으로 개발을 진행했다. (일주일 중 5일 이상 소통하고 회의 하는 것 같다.)

나는 AI 분석·추천 로직, 스트리밍, 이미지 입력과 데이터 흐름을 중심으로 작업했다. 건우는 전체 화면의 디자인과 인터랙션을 점검하고, 사용자가 기능을 더 자연스럽게 이해할 수 있도록 UI를 개선했다. 동현은 기능별 테스트와 문서 정리, 사용 과정에서 발생할 수 있는 문제를 확인했다.

단순히 기능을 구현하고 끝내지 않고 매 작업마다 다음 내용을 문서에 기록했다.

어떤 문제를 해결했는지
어떤 파일을 수정했는지
무엇을 검증했는지
아직 검증하지 못한 부분은 무엇인지
관련 이슈와 다음 작업은 무엇인지

이번 주에는 기능이 빠르게 늘어난 만큼 문서와 테스트의 중요성을 더 크게 느꼈다. 코드상으로 구현이 끝났다고 해서 실제 서비스에서도 정상적으로 작동한다고 단정할 수 없기 때문이다.

특히 이미지 입력과 파일 첨부처럼 외부 API와 저장소가 연결되는 기능은 자동 테스트뿐 아니라 실제 로그인 계정에서의 통합 테스트가 필요하다. 구현 완료와 검증 완료를 구분하여 기록하는 습관을 계속 유지하고 있다.

7월 26일 멘토링: 개발을 넘어 취업과 커리어를 질문하다

7월 26일 멘토링에는 개인 일정으로 마이크를 사용할 수 없어, 멘토님의 설명을 들으며 채팅으로 참여했다.

이번 멘토링에서는 CampusLog의 개발 내용뿐 아니라 건우·동현·문기가 앞으로 준비해야 할 취업과 커리어에 관한 질문도 함께 나눴다.

나는 다음과 같은 내용을 질문했다.

AI 개발자 직무에서 학사와 석사 학위가 실제로 어느 정도 요구되는지
AI 분야별로 요구되는 학력이나 연구 경험이 다른지
금융권 IT 개발자 공채에서 학교나 학벌이 어느 정도 영향을 미치는지
지방대학교에서 금융권 개발자를 준비하려면 무엇을 중점적으로 준비해야 하는지
수시채용과 팀 단위 채용은 실제로 어떻게 이루어지는지
AI 발전 이후 코딩테스트가 사라질지, 오히려 더 중요해질지
우리가 본격적으로 취업을 준비할 2027~2028년의 채용 방식은 어떻게 달라질지

멘토님께서는 현업 경험을 바탕으로 각 질문에 현실적인 관점에서 답변해주셨다.

매주 프로젝트의 기술적인 문제를 중심으로 이야기를 나누다가, 이번에는 우리가 왜 이 프로젝트를 만들고 있으며 앞으로 어떤 개발자가 되고 싶은지까지 생각해볼 수 있었다.

CampusLog 역시 결국 대학생이 자신의 활동을 기록하는 서비스에서 끝나는 것이 아니라, 기록한 경험을 취업과 커리어에 연결하도록 돕는 서비스다. 이번 멘토링에서 나눈 질문들이 우리가 만들고 있는 서비스의 방향과도 자연스럽게 이어진다는 생각이 들었다.

다음 단계

다음 주에는 새 기능을 무작정 추가하기보다 지금까지 구현한 주요 사용자 흐름을 실제 테스트 계정으로 검증할 예정이다.

우선 확인해야 할 내용은 다음과 같다.

활동 기록부터 AI 분석·추천·답변 생성까지의 전체 흐름
이미지 기반 자기소개서 문항 및 JD 추천 결과
사진·PDF 첨부의 업로드·조회·삭제
모바일 화면과 키보드 접근성
AI 응답 실패·취소·재시도 처리
추천 결과의 근거 일치와 과장 방지
실제 MVP 제출 환경에서의 통합 동작

기능의 개수보다 사용자가 처음부터 끝까지 막히지 않고 서비스를 사용할 수 있는지가 더 중요하다. MVP 제출을 앞둔 만큼 남은 기간에는 테스트와 안정화에 집중할 계획이다.

이번 주를 마치며

이번 주의 가장 큰 변화는 기능이 많아진 것이 아니다.

사용자가 활동을 기록하고, AI 분석을 확인하고, 부족한 정보를 보완하고, 실제 자기소개서와 면접에 활용하는 과정이 이전보다 하나의 흐름으로 연결되기 시작했다는 점이다.

개발을 진행할수록 좋은 서비스는 단순히 기능이 동작하는 서비스가 아니라는 것을 느낀다.

사용자가 무엇을 해야 하는지 이해할 수 있어야 하고, 기다리는 동안에도 현재 상태를 알 수 있어야 하며, AI가 생성한 결과가 어디에서 나온 것인지 확인할 수 있어야 한다.

CampusLog가 단순한 대학생활 기록 서비스를 넘어, 대학생이 자신의 경험을 발견하고 설명할 수 있도록 돕는 서비스가 될 수 있도록 남은 기간에도 계속 개선해나갈 예정이다.

경제금융용어 공부 573 : 추정손실

MKISOS — Mon, 27 Jul 2026 21:00:44 +0900

추정손실

은행은 돈을 빌려준 뒤 차주가 약속대로 갚을 수 있는지를 계속 평가한다. 만약 차주의 재무 상태가 크게 악화되어 돈을 돌려받을 가능성이 거의 없다고 판단되면 해당 대출을 '추정손실'로 분류한다. 이는 금융기관이 대출의 건전성을 관리하고 예상되는 손실을 미리 반영하기 위해 사용하는 가장 위험한 여신 분류 단계이다.

1. 한 줄 정의

추정손실은 대출금을 회수할 가능성이 거의 없어 손실 처리가 불가피하다고 판단되는 대출을 의미한다.

2. 기본 개념

추정손실은 금융기관이 빌려준 돈 가운데 회수가 사실상 불가능하다고 판단되는 대출을 말한다.

예를 들어 차주의 사업이 부도나거나 장기간 연체가 지속되어 정상적인 상환이 어려운 경우 해당 대출은 추정손실로 분류될 수 있다.

우리나라 금융기관은 차주의 상환 능력과 연체 여부 등을 종합적으로 평가하여 여신을 여러 단계로 관리하는데, 추정손실은 가장 위험한 단계에 해당한다.

특히 일반적으로 12개월 이상 연체된 대출이나 회수 가능성이 거의 없는 대출은 추정손실로 분류될 가능성이 높다.

3. 왜 중요한가

은행은 대출을 많이 해주는 것만큼이나 빌려준 돈을 제대로 회수하는 것이 중요하다.

만약 회수하기 어려운 대출을 정상 자산처럼 관리한다면 실제 재무상태보다 은행이 훨씬 건전한 것처럼 보일 수 있다.

추정손실 제도는 이러한 문제를 막기 위해 예상되는 손실을 미리 반영하도록 하는 장치이다.

이를 통해 금융기관의 재무 건전성을 높이고 투자자와 예금자에게 보다 정확한 정보를 제공할 수 있다.

4. 쉽게 이해하는 예시

실생활 예시

친구에게 100만 원을 빌려주었는데 연락이 끊기고 오랫동안 돈을 갚지 않는 상황을 생각해보자.

친구가 파산까지 했다면 돈을 돌려받을 가능성은 매우 낮다.

이 경우 빌려준 돈을 사실상 손실로 생각하는 것과 비슷한 개념이다.

기업 예시

은행이 한 기업에 50억 원을 대출해주었는데 해당 기업이 부도나고 장기간 채무를 상환하지 못하고 있다.

담보를 처분하더라도 대부분의 대출금을 회수하기 어렵다면 남은 금액은 추정손실로 분류된다.

금융시장 예시

경기침체로 기업 부도가 증가하면 금융기관의 추정손실 규모도 커질 수 있다.

이 경우 은행은 충당금을 더 많이 적립해야 하므로 수익성이 악화될 수 있다.

5. 핵심 특징

5-1. 회수 가능성이 거의 없다

추정손실은 단순히 연체가 발생한 것이 아니라 대출금을 돌려받기 어려운 상황으로 판단되는 자산이다.

5-2. 장기 연체가 주요 기준이다

일반적으로 12개월 이상 연체되거나 차주의 상환 능력이 심각하게 악화된 경우 추정손실로 분류될 수 있다.

5-3. 금융기관의 손실로 반영된다

추정손실로 분류되면 은행은 예상되는 손실에 대비해 대손충당금을 적립하거나 손실 처리를 진행한다.

6. 관련 개념과의 차이

추정손실 vs 고정이하여신(NPL)

추정손실

회수 가능성이 거의 없음
가장 위험한 여신 분류 단계

고정이하여신(NPL)

정상적으로 상환되지 않는 부실채권 전체
고정, 회수의문, 추정손실을 모두 포함

즉 추정손실은 고정이하여신 가운데 가장 위험한 단계이다.

추정손실 vs 대손충당금

추정손실

회수가 어렵다고 판단한 대출 자체

대손충당금

예상 손실에 대비하여 미리 쌓아두는 비용

추정손실은 손실이 예상되는 자산이고, 대손충당금은 그 손실에 대비하는 회계 처리이다.

7. 경제적 의미

국가경제 관점

경기침체가 심해질수록 기업과 가계의 상환 능력이 악화되어 추정손실 규모가 증가할 수 있다.

이는 금융시스템의 건전성에도 영향을 미친다.

기업 관점

기업이 부도나거나 재무상태가 악화되면 금융기관은 해당 기업에 대한 대출을 추정손실로 분류할 수 있다.

이는 추가 대출이나 자금조달에도 부정적인 영향을 미친다.

금융시장 관점

은행의 추정손실이 증가하면 대손충당금 적립 부담이 커지고 수익성이 악화될 수 있다.

따라서 금융시장은 은행의 부실채권 규모와 추정손실 비중을 중요한 건전성 지표로 살펴본다.

투자 관점

은행주에 투자할 때는 추정손실과 고정이하여신 비율을 함께 확인하는 것이 중요하다.

추정손실이 급격히 증가하면 향후 실적 악화와 자본 건전성 저하로 이어질 가능성이 있기 때문이다.

8. 정리

추정손실은 차주의 상환 능력이 심각하게 악화되어 대출금을 회수할 가능성이 거의 없는 여신을 의미한다. 일반적으로 장기 연체나 부도 등으로 손실 처리가 불가피한 경우에 적용되는 가장 위험한 여신 분류 단계이다. 금융기관은 추정손실을 통해 예상되는 손실을 미리 반영하고 대손충당금을 적립하여 재무 건전성을 관리한다. 따라서 추정손실 규모는 은행의 건전성과 경기 상황을 판단하는 중요한 지표로 활용된다.

[주간회GO 26년 7월 4주차] 대구-부산-청주-가평, 대외활동들과 휴가 (출퇴근 하면서...) + 내년 학생회 구성원 다 모음!

MKISOS — Mon, 27 Jul 2026 09:35:57 +0900

[주간회GO 26년 7월 4주차]

26년 7월 4주차

휴가 열일 열공 열일 휴가

=> 피곤 + 뿌듯

26년 7월 20일 월요일

월드컵 결승과 오운완
아르헨,,, 0슈팅 우승은 에바긴했다

부산역 도착~

빠르게 광안리 바다구경
근데 최고국밥집 웨이팅 하다가 실패했다.

대외활동 전 초량밀면 뿌수기

비욘드부산 3기 워크숍 마무리!

부부그리다 카페?
ㄹㅈㄷ 느좋인데 오래 못있어서 아쉽다.
라떼에 복숭아향 난다 ㄷ

톤쇼우 첫경험
의외로 사시미카츠가 존맛탱임
훈연이 다르다 ㄷ

하루 길다… ㅠㅠ

26년 7월 21일 화요일

헬스장 오늘까지 휴회라서 홈트완료
오랜만에 출근준비했다… (뭔가 우울)

오랜만에 오니 후임이 일을 많이 안해둬서 할게 천지네^^

점심먹고
이번 주말에 가는 빠지 아쿠아 삭스 배송 받음
형들거까지 내가 시킴. 막내의 숙명

휴가때 기차 버스 등 이동하면서 휴대폰으로 전자책 읽어서 겨우 오늘 제출했다. 이제 시간이 없어서..

곧 소해하는 형이랑 운동도 했다

밥 먹고 lg 몰아듣기
주말 빠지를 위한 노력.

나를 위한 보상으로 수박 시킴

26년 7월 22일 수요일

수박 와서 기분좋았다가
비에 양말 다 젖음 ㅜ

어제 딱 다 들었음 … 남는게 별로 없어서 모델 만들면서 공부 예정 ㅇㅅㅇ

그래도 점심에 기분 좋아졌음. ㅎㅎ

Kt 메가 4천원 할인 받고 아샷추 마시면서 오후 일 엄청 많아서 열심히 했다 ㅠㅠ
할 거 많을때는 구청도 같이 바빠지는 변수가 발생해서 스트레스다…

저녁 닭 300
수박 800 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

퇴근하고 ADsP 기출 하나 처음으로 풀어봄 결과처참하다

이어서 fly asia 회의까지 완료
진짜 시간 엄청내야겠다…

내년 학생회 회의까지하고 12시까지 애들 연락돌리고
취침했다.
멤버가 생각보다 잘 모이고 좋은 것 같다.
너무 잘 풀려서 오히려 걱정된다.

26년 7월 23일 목요일

아침 모닝 회의 카톡으로 하다가 + 디코회의하면서 운동완료

너무 급하게 먹어서 체했음 오랜만에
점심에 개발 몰아서 해야해서 ㅠㅠ

너무 피곤해서 메가 커피 제로에너지 부스트에 투샷추가했다

난 항상 바로 바로 제출하는 중 아니면 불안한 병에 걸림

이번 달도 나이스
네이버페이 소액이지만 현금화해서 수술비에 보태야지..
ㅠㅠ

밥 먹으면서 회의 완료!

+
학생회 회의도 해서 내년 멤버 다 모았다 16명
역대급라인업이지 않을까(매년 스스로 그러나?)

26년 7월 24일 금요일

건우랑 기상하자마자 디코 회의

오운완

수박있을때는 항상 식사가 기대된다.

일 너무 빡세다 요즘

시간표 대충 짜고 금욜 오후 여유로워서 체단실
진짜 얼마 안남았네

학생회 구성 완료라 설렌다…
식구들 생겼다.

26년 7월 25, 26일 토,일요일 주말

팀 청주 가평으로 출발 ~ 열심히 일하고 할 거 거의 끝내고 떠나는 여행은 달다.

인생 첫 가평, 첫 빠지 충월드 멤버 다 모인게 역사적이다. 졸업하고 다들 각자 열심히 살다가 만났는데 진짜 학생때로 돌아간 느낌.

20 8명에 나 혼자 21이지만 형들이 이렇게 잘 챙결줄 수 가 없다~

장보러 갔다가 고기 무제한 술무제한 그리고 숙소 2차 ㄹㅈㄷ 라이어게임했는데 웃겨주글뻔했다.

숙소 떠나기 전~ 찰칵

ㄹㅈㄷ 숯불 닭갈비 해장했다. 치즈 퐁듀에 막국수까지 야무졌다.

번지점프 버킷리스트였는데 결국 해냈음 ㄷㄷㄷ

형들이 영상도 찍어줘서 좋은 추억 남겼다.

진짜 그냥 이까지 왔다가 안할뻔 했는데 동우형의 행동하나로 ,,,

근데 너무 시간이 딜레이 되어서 나 혼자뛰는데 형들이 기다려야해서 너무 미안해 죽을뻔했다...

뛰고 청주 돌아오는길에 유니커 멘토링 참석했다. 차라서 마이크 못키고 그냥 채팅으로 열심히 참여했다.

원래 벨트 안하다가 중간에 비가 너무 많이 와서 앞이 안보여서 다들 벨트 메고 난리 난리

운전해주신 치산형, 태형형 고생많았습니다~

피곤해서 너무 대충대충적었네 ,,

경제금융용어 공부 572 : 추심

MKISOS — Sun, 26 Jul 2026 21:00:55 +0900

추심

어음이나 수표를 받았다고 해서 돈이 자동으로 바로 들어오는 것은 아니다. 실제로는 금융기관이 해당 어음이나 수표의 발행인에게 대금 지급을 요청하고 자금을 받아오는 과정이 필요하다. 이처럼 은행이 고객을 대신해 어음이나 수표 대금을 회수하는 절차를 추심이라고 한다. 기업 간 결제에서 자주 사용되는 중요한 금융 실무 개념이다.

1. 한 줄 정의

추심은 은행이 고객의 위임을 받아 어음이나 수표 대금을 대신 받아주는 절차이다.

2. 기본 개념

추심(Collection)은 어음이나 수표를 보유한 사람이 거래은행에 대금 회수를 맡기고, 해당 은행이 발행인이나 지급은행에 대금 지급을 요청하는 일련의 절차를 의미한다.

쉽게 말하면 어음이나 수표를 받은 사람이 직접 돈을 받으러 가지 않고 은행에 대신 받아달라고 요청하는 것이다.

이때 은행은 추심 권한을 위임받아 어음의 지급인이나 인수인 등 어음채무자에게 대금을 청구한다.

추심 대상이 되는 어음을 추심어음이라고 한다.

3. 왜 중요한가

기업 간 거래에서는 현금 대신 어음이나 수표로 대금을 지급하는 경우가 있다.

하지만 기업이 일일이 상대방을 찾아가 돈을 받아내는 것은 매우 비효율적이다.

추심제도를 이용하면 은행이 대신 대금 회수 업무를 처리해주기 때문에 거래비용과 시간을 줄일 수 있다.

또한 금융기관을 통해 공식적인 절차로 대금이 회수되므로 거래의 안전성과 신뢰성도 높아진다.

4. 쉽게 이해하는 예시

실생활 예시

친구가 돈을 직접 주지 않고 3개월 뒤에 지급하겠다는 약속어음을 건넸다고 가정해보자.

만기가 되면 어음을 들고 친구를 직접 찾아가는 대신 은행에 제출해 대금을 받아달라고 요청할 수 있다.

이 과정이 추심이다.

기업 예시

A기업이 B기업에 물품을 납품하고 1억 원짜리 약속어음을 받았다고 가정해보자.

A기업은 거래은행에 어음을 맡기고 추심을 요청한다.

은행은 어음 만기일에 B기업 측 은행으로 대금 지급을 요청하고, 받은 돈을 A기업 계좌에 입금한다.

수표 예시

수표를 받은 사람이 자신의 거래은행에 수표를 제출하면 은행은 발행은행에 대금을 청구한다.

이 역시 추심 절차에 해당한다.

5. 핵심 특징

5-1. 은행이 고객을 대신해 대금을 회수한다

추심의 핵심은 위임이다.

어음이나 수표 소지자가 은행에 대금 회수 권한을 맡기면 은행이 대신 지급을 요청한다.

5-2. 어음과 수표 거래에서 주로 활용된다

추심은 현금이나 일반 계좌이체보다는 어음과 수표처럼 만기와 지급절차가 필요한 지급수단에서 주로 사용된다.

5-3. 어음 종류에 따라 절차가 다르다

약속어음은 일반적으로 어음교환제도를 통해 추심한다.

환어음은 거래은행이 지급인의 거래은행에 대금을 청구하는 방식으로 처리된다.

6. 관련 개념과의 차이

추심 vs 계좌이체

추심

은행이 상대방에게 대금 지급을 요청
어음이나 수표 회수에 주로 사용
고객의 위임이 필요

계좌이체

지급인이 직접 자금을 송금
일반적인 자금이체 방식
어음이나 수표가 필요하지 않음

즉 계좌이체는 돈을 보내는 사람이 시작하고, 추심은 돈을 받을 사람이 은행에 회수를 요청한다는 차이가 있다.

추심 vs 어음할인

추심

만기일에 어음대금을 회수
은행이 대신 받아주는 절차

어음할인

만기 전에 어음을 은행에 넘기고 현금화
할인료를 제외한 금액을 미리 수령

추심은 만기까지 기다린 뒤 돈을 받는 방식이고, 어음할인은 만기 전에 현금으로 바꾸는 방식이다.

7. 경제적 의미

국가경제 관점

추심제도는 기업 간 거래대금 회수를 원활하게 만들어 상거래의 안정성을 높인다.

기업 관점

기업은 직접 대금을 회수하는 번거로움을 줄이고 자금관리의 효율성을 높일 수 있다.

금융시장 관점

은행이 추심 과정에 참여함으로써 어음과 수표 거래의 신뢰성이 높아지고 지급결제시스템이 안정적으로 운영된다.

투자 관점

투자자가 직접 추심을 활용하는 경우는 많지 않지만, 기업의 매출채권과 현금흐름을 분석할 때 어음 추심 구조를 이해하면 도움이 된다.

특히 어음 의존도가 높은 기업은 대금 회수 지연 위험을 함께 살펴봐야 한다.

8. 정리

추심은 어음이나 수표를 가진 사람이 은행에 대금 회수를 위임하고, 은행이 발행인이나 지급은행으로부터 돈을 받아주는 절차이다. 약속어음은 어음교환제도를 통해, 환어음은 거래은행을 통해 지급은행에 청구하는 방식으로 처리된다. 추심은 기업 간 거래대금 회수를 효율적으로 만들고 어음과 수표 거래의 안전성을 높이는 역할을 한다. 계좌이체나 어음할인과는 절차와 목적이 다르므로 구분해서 이해할 필요가 있다.

경제금융용어 공부 571 : 추가경정예산

MKISOS — Sat, 25 Jul 2026 21:00:34 +0900

추가경정예산

뉴스에서 "정부가 추가경정예산을 편성했다", "추경안이 국회를 통과했다"는 소식을 자주 접할 수 있다. 추가경정예산(추경)은 예상하지 못한 경제위기나 재난이 발생했을 때 정부가 기존 예산을 수정하여 추가로 편성하는 예산이다. 경기 침체를 극복하거나 국민 생활을 지원하기 위한 대표적인 재정정책 수단으로 활용된다.

1. 한 줄 정의

추가경정예산은 이미 확정된 예산으로는 부족한 상황이 발생했을 때 정부가 새롭게 편성하는 추가 예산이다.

2. 기본 개념

추가경정예산(추경)은 정부의 본예산이 확정된 이후 예상하지 못한 경제·사회적 변화가 발생했을 때 기존 예산을 추가하거나 일부 조정하는 예산을 말한다.

정부는 매년 본예산을 편성하지만, 자연재해나 경기침체, 감염병 확산처럼 예측하기 어려운 상황이 발생하면 기존 예산만으로는 대응하기 어려울 수 있다.

이때 정부는 추가경정예산을 편성하여 국회의 심의를 거쳐 필요한 재원을 새롭게 확보하고 집행한다.

쉽게 말하면 '예산의 수정판' 또는 '긴급 예산'이라고 이해하면 된다.

3. 왜 중요한가

경제는 항상 예상대로 움직이지 않는다.

갑작스러운 경기침체가 발생하거나 대형 산불, 태풍, 감염병 같은 재난이 발생하면 정부는 신속하게 재정을 투입해야 한다.

이때 추가경정예산은 국민 지원금 지급, 피해 복구, 기업 지원, 일자리 확대 등 긴급한 정책을 빠르게 추진할 수 있도록 돕는다.

즉 추경은 정부가 경제 상황 변화에 유연하게 대응하기 위한 중요한 재정정책이다.

4. 쉽게 이해하는 예시

실생활 예시

한 가정이 1년 생활비를 미리 계획했다고 가정해보자.

하지만 갑자기 가족이 병원에 입원하면서 큰 의료비가 발생했다.

기존 예산으로는 부족하기 때문에 저축을 꺼내거나 추가 예산을 마련하게 된다.

정부의 추가경정예산도 이와 같은 원리이다.

경제 예시

코로나19가 확산되면서 많은 자영업자가 큰 피해를 입었다.

정부는 본예산만으로는 지원이 부족하다고 판단하여 추가경정예산을 편성하고 재난지원금과 소상공인 지원금을 지급하였다.

국가 예시

대형 산불이나 집중호우로 피해가 발생하면 정부는 복구비와 재난지원금을 마련하기 위해 추경을 편성하기도 한다.

5. 핵심 특징

5-1. 본예산 이후에 편성된다

추가경정예산은 이미 확정된 본예산을 수정하거나 추가하는 예산이다.

예산 편성 단계에서 처음부터 포함되는 것이 아니다.

5-2. 예상하지 못한 상황에 대응한다

경기침체, 재난, 감염병, 금융위기 등 긴급한 상황이 발생했을 때 활용된다.

평상시에는 편성하지 않는 것이 원칙이다.

5-3. 국회의 심의를 거쳐야 한다

정부가 추경안을 마련하더라도 국회의 심의와 의결을 거쳐야 최종적으로 집행할 수 있다.

6. 관련 개념과의 차이

추가경정예산 vs 본예산

추가경정예산

본예산 이후 편성
예상하지 못한 상황 대응
기존 예산 수정 및 추가

본예산

매년 정기적으로 편성
다음 연도 정부 운영 계획
국가 재정의 기본 계획

즉 본예산은 연간 계획이고, 추가경정예산은 긴급 대응을 위한 보완 예산이다.

추가경정예산 vs 예비비

추가경정예산

국회의 심의를 거쳐 새롭게 편성
규모가 큰 재정 지출에 활용

예비비

본예산에 미리 편성
긴급 상황 발생 시 일정 범위 내에서 사용

예비비로 부족할 경우 추가경정예산을 편성하는 경우가 많다.

7. 경제적 의미

국가경제 관점

추가경정예산은 경기침체를 완화하고 재난 피해를 복구하기 위한 대표적인 확장적 재정정책 수단이다.

경제 충격을 줄이고 국민 생활 안정을 지원하는 역할을 한다.

기업 관점

추경을 통해 기업 지원금이나 투자 예산이 확대되면 기업의 자금난을 완화하고 경기 회복에 도움이 될 수 있다.

금융시장 관점

추가경정예산은 경기부양 기대를 높일 수 있지만, 동시에 국가재정 부담과 국가채무 증가에 대한 우려도 함께 발생할 수 있다.

시장에서는 추경의 규모와 재원 조달 방식을 중요하게 살펴본다.

투자 관점

추경이 편성되면 건설, 인프라, 소비, 중소기업 지원 등 관련 산업이 수혜를 받을 가능성이 있다.

반면 대규모 추경이 반복되면 국가채무 증가와 재정건전성 악화에 대한 우려가 커질 수도 있다.

8. 정리

추가경정예산은 본예산이 확정된 이후 예상하지 못한 경제·사회적 변화에 대응하기 위해 새롭게 편성하는 예산이다. 경기침체, 자연재해, 감염병 등 긴급한 상황에서 국민과 기업을 지원하기 위한 대표적인 재정정책으로 활용된다. 본예산과 달리 필요에 따라 편성되며 국회의 심의를 거쳐 집행된다. 추가경정예산은 경제위기 극복과 경기 활성화에 중요한 역할을 하지만, 국가채무 증가와 재정건전성도 함께 고려해야 하는 정책이다.

경제금융용어 공부 570 : 최종수요 / 중간수요

MKISOS — Fri, 24 Jul 2026 21:00:01 +0900

최종수요 / 중간수요

경제에서는 같은 상품이라도 누가, 어떤 목적으로 구매하느냐에 따라 의미가 달라진다. 예를 들어 밀가루를 소비자가 사면 최종수요가 되지만, 제빵회사가 빵을 만들기 위해 사면 중간수요가 된다. 이처럼 재화와 서비스의 사용 목적에 따라 구분한 개념이 바로 최종수요와 중간수요이다. 이 둘을 구분하는 것은 국내총생산(GDP)을 정확하게 계산하기 위해 매우 중요하다.

1. 한 줄 정의

최종수요는 최종 소비나 투자 목적으로 이루어지는 수요이고, 중간수요는 다른 재화나 서비스를 생산하기 위해 발생하는 수요이다.

2. 기본 개념

경제에서 수요는 재화나 서비스를 구매하려는 욕구와 능력을 의미한다.

이러한 수요는 사용 목적에 따라 크게 두 가지로 나뉜다.

최종수요(Final Demand) : 소비나 투자처럼 최종적인 목적을 위해 구매하는 수요
중간수요(Intermediate Demand) : 다른 상품이나 서비스를 생산하기 위한 원재료나 부품으로 사용하는 수요

즉 같은 제품이라도 구매 목적에 따라 최종수요가 될 수도 있고 중간수요가 될 수도 있다.

예를 들어 밀가루를 가정에서 직접 소비하기 위해 구매하면 최종수요가 되지만, 빵을 만드는 제빵회사가 원재료로 구매하면 중간수요가 된다.

3. 왜 중요한가

경제 전체의 생산 규모를 계산할 때 중간수요와 최종수요를 구분하지 않으면 같은 상품의 가치가 여러 번 계산되는 문제가 발생한다.

예를 들어 자동차를 생산하는 과정에서 철강, 부품, 타이어의 가격을 모두 더한 뒤 자동차 가격까지 다시 더하면 동일한 가치가 중복 계산된다.

그래서 GDP는 중간수요를 제외하고 최종수요만 반영하거나, 부가가치만 계산하는 방식을 사용한다.

4. 쉽게 이해하는 예시

대학생 예시

대학생이 마트에서 밀가루를 사서 집에서 직접 빵을 만든다면 밀가루는 최종수요이다.

하지만 빵집 사장이 빵을 만들기 위해 같은 밀가루를 구매했다면 이는 중간수요가 된다.

기업 예시

자동차 회사가 자동차를 생산하기 위해 타이어를 구매하면 타이어는 중간수요이다.

반면 소비자가 완성된 자동차를 구매하면 자동차는 최종수요가 된다.

경제 예시

반도체 회사가 스마트폰 제조사에 반도체를 판매하면 반도체는 중간수요이다.

제조사가 완성된 스마트폰을 소비자에게 판매하면 스마트폰은 최종수요가 된다.

5. 핵심 특징

5-1. 구매 목적에 따라 구분된다

같은 상품이라도 소비자가 사용하는지, 기업이 생산에 사용하는지에 따라 최종수요와 중간수요가 달라진다.

5-2. 최종수요는 GDP 계산에 포함된다

최종 소비와 투자에 사용되는 재화와 서비스는 국민경제의 최종 생산물로 인정되어 GDP 계산에 포함된다.

5-3. 중간수요는 생산 과정에서 사용된다

중간수요는 다른 상품을 만들기 위한 원재료나 부품으로 사용되므로 최종 생산물이 아니다.

중복 계산을 방지하기 위해 GDP 계산에서는 제외된다.

6. 관련 개념과의 차이

최종수요 vs 중간수요

최종수요

최종 소비 또는 투자 목적
가계 소비
정부 소비
설비투자
수출

중간수요

생산 과정에서 사용
원재료
부품
중간재

즉 최종수요는 소비나 투자를 위한 구매이고, 중간수요는 생산을 위한 구매이다.

최종수요 vs 중간소비

최종수요

완성된 재화와 서비스를 구매하는 수요

중간소비

생산 과정에서 중간재를 실제 사용하는 행위

중간수요는 구매의 개념이고, 중간소비는 생산 과정에서 해당 재화를 사용하는 개념이다.

7. 경제적 의미

국가경제 관점

최종수요는 소비와 투자 수준을 보여주는 중요한 경제지표이다.

최종수요가 증가하면 경제성장률이 높아질 가능성이 커진다.

기업 관점

기업은 중간수요를 통해 생산활동을 이어간다.

최종수요가 증가하면 기업의 중간수요도 함께 증가하는 경우가 많다.

금융시장 관점

최종수요 증가는 기업 실적 개선과 경기 회복 기대를 높일 수 있다.

반대로 최종수요가 감소하면 생산과 투자도 위축될 가능성이 있다.

투자 관점

투자자는 소비와 설비투자 등 최종수요의 증가 여부를 통해 경기 흐름을 판단한다.

최종수요가 꾸준히 증가하면 제조업과 소비재 기업의 실적 개선 가능성이 높아질 수 있다.

8. 정리

최종수요는 소비나 투자와 같은 최종 목적을 위해 이루어지는 수요이며, 중간수요는 다른 재화와 서비스를 생산하기 위한 원재료나 부품에 대한 수요를 의미한다. 같은 상품이라도 구매 목적에 따라 최종수요가 될 수도 있고 중간수요가 될 수도 있다. 이러한 구분은 GDP를 계산할 때 중복 계산을 방지하기 위해 반드시 필요하다. 최종수요와 중간수요를 이해하면 경제지표와 생산 구조를 더욱 정확하게 해석할 수 있다.

경제금융용어 공부 569 : 최종대부자 기능

MKISOS — Thu, 23 Jul 2026 21:00:50 +0900

최종대부자 기능

은행은 고객의 예금을 모두 현금으로 보관하지 않고 상당 부분을 대출과 투자에 활용한다. 따라서 많은 예금자가 동시에 돈을 찾으러 오면, 자산이 충분한 은행도 당장 지급할 현금이 부족해질 수 있다. 이처럼 금융기관이 일시적인 유동성 위기에 빠졌을 때 중앙은행이 긴급 자금을 공급해 금융시스템의 붕괴를 막는 역할을 최종대부자 기능이라고 한다.

1. 한 줄 정의

최종대부자 기능은 금융위기 상황에서 중앙은행이 일시적으로 자금이 부족한 금융기관에 긴급 유동성을 공급하는 기능이다.

2. 기본 개념

최종대부자(Lender of Last Resort) 기능은 금융시장이 불안하거나 예금 인출이 급증해 금융기관이 일시적인 지급불능 상태에 빠졌을 때 중앙은행이 긴급 자금을 빌려주는 역할을 의미한다.

은행은 고객에게 받은 예금 가운데 일부만 현금성 자산으로 보유하고 나머지는 대출이나 채권 투자 등에 사용한다.

따라서 예금자들이 한꺼번에 돈을 찾으면 은행의 전체 자산가치가 충분하더라도 당장 지급할 현금이 부족해질 수 있다.

이때 중앙은행이 발권력을 바탕으로 신속하게 자금을 공급하면 은행의 파산과 금융위기의 확산을 막을 수 있다.

3. 왜 중요한가

금융시장은 신뢰를 기반으로 움직인다.

한 은행이 어려움에 빠졌다는 소문이 퍼지면 예금자들은 자신의 돈을 지키기 위해 한꺼번에 예금을 인출하려 할 수 있다.

이러한 현상을 뱅크런(Bank Run)이라고 한다.

뱅크런이 발생하면 건전한 은행도 단기간에 유동성이 부족해질 수 있고, 한 은행의 위기가 다른 금융기관으로 번질 가능성도 있다.

최종대부자 기능은 중앙은행이 충분한 자금을 공급할 수 있다는 신뢰를 제공함으로써 금융시장의 공포를 진정시키고 연쇄적인 금융기관 파산을 예방한다.

4. 쉽게 이해하는 예시

실생활 예시

친구가 아파트와 자동차 등 충분한 자산을 가지고 있지만 갑자기 병원비를 지불해야 하는 상황이라고 가정해보자.

재산은 충분하지만 당장 사용할 현금이 없어 일시적인 자금 부족을 겪는 것이다.

이때 가족이 급하게 돈을 빌려주면 자산을 헐값에 팔지 않고 위기를 넘길 수 있다.

중앙은행의 최종대부자 기능도 이와 비슷하다.

은행 예시

A은행에 예금 인출 요구가 한꺼번에 몰렸다고 가정해보자.

A은행은 장기대출과 채권 등 충분한 자산을 보유하고 있지만 이를 즉시 현금화하기는 어렵다.

중앙은행이 긴급 자금을 빌려주면 A은행은 예금자의 인출 요구에 대응하고 시장의 불안을 진정시킬 수 있다.

경제위기 예시

금융위기 때 여러 금융기관이 서로를 믿지 못하면 금융기관 간 대출이 중단될 수 있다.

이때 중앙은행이 유동성을 공급하면 금융기관들이 급격히 자금난에 빠지는 것을 막고 금융시장의 기능을 회복시킬 수 있다.

5. 핵심 특징

5-1. 중앙은행의 발권력을 기반으로 한다

중앙은행은 통화를 발행할 수 있는 독점적 권한을 가진다.

따라서 금융시장 전체에서 자금이 부족한 위기 상황에도 필요한 유동성을 공급할 수 있다.

5-2. 일시적인 유동성 부족을 해결한다

최종대부자 기능은 기본적으로 자산은 충분하지만 당장 지급할 현금이 부족한 금융기관을 지원하기 위한 제도이다.

사업 자체가 부실해 채무를 갚을 능력이 없는 금융기관을 무조건 구제하는 제도는 아니다.

5-3. 일반 대출보다 높은 금리가 적용될 수 있다

중앙은행의 지원을 너무 쉽게 받을 수 있다면 금융기관은 위험을 제대로 관리하지 않고 과도하게 빚을 낼 수 있다.

이러한 도덕적 해이를 방지하기 위해 긴급대출에는 일반적으로 시장금리보다 높은 금리가 적용될 수 있다.

5-4. 금융시장 전체로 역할이 확대되기도 한다

글로벌 금융위기 이후 중앙은행은 개별 금융기관뿐 아니라 채권시장과 단기금융시장 등 금융시장 전체에도 유동성을 공급하였다.

이러한 역할은 전통적인 최종대부자 기능과 구분하여 최종시장조성자 기능이라고 부르기도 한다.

6. 관련 개념과의 차이

최종대부자 vs 일반 은행대출

최종대부자

중앙은행이 금융기관에 자금을 공급
금융위기나 유동성 위기 상황에서 작동
금융시스템 안정이 목적

일반 은행대출

은행이 개인이나 기업에 자금을 공급
일상적인 금융거래
이자수익과 신용공급이 목적

즉 일반 은행은 경제주체에게 돈을 빌려주고, 중앙은행은 위기 때 은행에 돈을 빌려준다.

유동성 부족 vs 지급불능

유동성 부족

자산은 충분하지만 당장 사용할 현금이 부족한 상태
일시적인 문제일 가능성이 큼

지급불능

전체 자산보다 부채가 많거나 채무를 감당하기 어려운 상태
근본적인 재무 문제에 해당

최종대부자 기능은 원칙적으로 일시적인 유동성 부족을 해결하는 데 초점이 있다.

최종대부자 vs 최종시장조성자

최종대부자

개별 금융기관에 직접 자금 공급
은행의 유동성 위기 대응

최종시장조성자

채권시장 등 금융시장 전반에 유동성 공급
시장의 거래 기능과 가격 형성 회복

두 기능 모두 금융안정을 목적으로 하지만 지원 대상과 방식에 차이가 있다.

7. 경제적 의미

국가경제 관점

최종대부자 기능은 금융위기가 실물경제로 확산되는 것을 막는 핵심 안전장치이다.

은행의 연쇄 파산을 예방하고 기업과 가계의 금융거래가 중단되는 것을 방지한다.

기업 관점

금융시스템이 안정되어야 기업도 대출을 받고 결제와 투자 활동을 정상적으로 이어갈 수 있다.

중앙은행의 유동성 공급은 기업의 자금조달 환경이 급격히 악화되는 것을 완화한다.

금융시장 관점

중앙은행이 위기 시 자금을 공급한다는 신뢰는 시장 참가자들의 공포를 줄인다.

그러나 지원이 지나치게 반복되면 금융기관이 위험을 과소평가하는 도덕적 해이가 발생할 수 있다.

투자 관점

투자자는 금융위기 때 중앙은행의 긴급대출과 유동성 공급 정책을 주의 깊게 살펴봐야 한다.

최종대부자 기능이 적극적으로 작동하면 금융시장 붕괴 위험은 줄어들 수 있지만, 동시에 시장 상황이 그만큼 심각하다는 신호일 수도 있다.

8. 정리

최종대부자 기능은 금융기관이 일시적인 유동성 부족에 빠졌을 때 중앙은행이 긴급 자금을 공급하는 기능이다. 이는 예금 인출 사태와 금융기관의 연쇄 파산을 막아 금융시스템 전체의 안정을 유지하는 역할을 한다. 다만 무분별한 지원은 금융기관의 도덕적 해이를 유발할 수 있어 일반적으로 높은 금리와 엄격한 조건이 적용된다. 글로벌 금융위기 이후에는 개별 금융기관을 넘어 금융시장 전체에 유동성을 공급하는 최종시장조성자 기능으로도 확대되고 있다.

경제금융용어 공부 568 : 최저임금제

MKISOS — Wed, 22 Jul 2026 21:00:52 +0900

최저임금제

매년 "내년 최저임금이 얼마로 결정됐다"는 뉴스가 큰 관심을 받는다. 최저임금은 단순히 아르바이트 시급만 결정하는 제도가 아니라 근로자의 최소한의 생활을 보장하고 노동시장의 공정성을 높이기 위한 중요한 제도이다. 기업의 인건비와 소비, 물가 등 경제 전반에도 큰 영향을 미치는 대표적인 노동정책 가운데 하나이다.

1. 한 줄 정의

최저임금제는 국가가 근로자에게 지급해야 하는 임금의 최저 수준을 정하고, 그 이상을 지급하도록 법으로 의무화한 제도이다.

2. 기본 개념

최저임금제는 사용자가 근로자에게 법에서 정한 최저임금보다 낮은 임금을 지급하지 못하도록 하는 제도이다.

이 제도의 목적은 근로자의 기본적인 생활을 보장하고, 지나치게 낮은 임금을 예방하는 데 있다.

우리나라는 1988년부터 최저임금제를 시행하고 있으며, 매년 정부가 다음 연도에 적용할 최저임금을 결정하여 고시한다.

최저임금보다 적은 임금을 지급하는 사업주는 법에 따라 처벌받을 수 있다.

3. 왜 중요한가

노동시장에서 근로자와 기업은 협상을 통해 임금을 결정하지만, 항상 대등한 위치에 있는 것은 아니다.

특히 사회초년생이나 아르바이트생처럼 협상력이 약한 근로자는 매우 낮은 임금을 받을 가능성이 있다.

최저임금제는 이러한 문제를 막고 최소한의 생활 수준을 보장하기 위해 도입되었다.

또한 소득격차를 완화하고 소비를 늘려 경제 활성화에도 긍정적인 영향을 줄 수 있다.

반면 기업의 인건비 부담이 증가할 수 있어 최저임금 수준을 둘러싼 논의는 매년 이어지고 있다.

4. 쉽게 이해하는 예시

대학생 예시

대학생 A가 카페에서 아르바이트를 시작했다고 가정해보자.

사장이 "시급 7,000원만 줄게."라고 말하더라도 해당 연도의 법정 최저임금이 그보다 높다면 그 금액으로 계약할 수 없다.

사업주는 반드시 최저임금 이상을 지급해야 한다.

실생활 예시

편의점, 음식점, 카페, 학원 등 대부분의 사업장은 최저임금 이상의 시급을 지급해야 한다.

그래서 아르바이트 공고를 보면 대부분 법정 최저임금 이상으로 시급이 책정되어 있다.

경제 예시

최저임금이 인상되면 근로자의 소득은 늘어날 수 있다.

반대로 기업은 인건비 부담이 증가하여 채용 규모를 줄이거나 가격을 인상할 가능성도 있다.

5. 핵심 특징

5-1. 법으로 보장되는 최소 임금이다

근로자는 법으로 정해진 최저임금 이상의 임금을 받을 권리가 있다.

사업주는 이를 반드시 준수해야 한다.

5-2. 매년 새롭게 결정된다

경제 상황, 물가 상승률, 고용시장 등을 종합적으로 고려하여 다음 연도의 최저임금이 매년 결정된다.

5-3. 노동시장과 경제에 모두 영향을 준다

근로자의 소득뿐 아니라 기업의 인건비, 소비, 물가, 고용시장에도 영향을 미치는 중요한 경제정책이다.

6. 관련 개념과의 차이

최저임금 vs 평균임금

최저임금

법으로 보장되는 최소 임금
그보다 낮게 지급할 수 없음

평균임금

실제 근로자들이 평균적으로 받는 임금
법적 기준이 아니라 통계적 개념

최저임금은 하한선을 의미하고, 평균임금은 실제 임금 수준을 나타낸다.

최저임금 vs 생활임금

최저임금

국가가 법으로 정한 최소 임금

생활임금

인간다운 생활을 할 수 있도록 지방자치단체나 기관 등이 자체적으로 정한 임금 기준

생활임금은 최저임금보다 높은 경우가 많다.

7. 경제적 의미

국가경제 관점

최저임금제는 저임금 근로자를 보호하고 소득분배를 개선하는 대표적인 노동정책이다.

동시에 고용과 물가에도 영향을 주기 때문에 경제 전반을 고려한 정책 결정이 필요하다.

기업 관점

최저임금이 인상되면 기업의 인건비 부담이 증가할 수 있다.

반면 근로자의 생산성과 근무 만족도가 높아지는 긍정적인 효과도 기대할 수 있다.

노동시장 관점

최저임금은 노동시장의 공정성을 높이고 지나친 저임금 경쟁을 방지하는 역할을 한다.

다만 급격한 인상은 일부 업종의 고용 감소로 이어질 수 있다는 의견도 존재한다.

투자 관점

최저임금 인상은 유통, 외식, 프랜차이즈처럼 인건비 비중이 높은 산업의 수익성에 영향을 줄 수 있다.

반대로 근로자의 소비 여력이 늘어나면 소비재 기업에는 긍정적인 영향을 줄 가능성도 있다.

8. 정리

최저임금제는 국가가 근로자에게 지급해야 하는 최소 임금을 법으로 정해 근로자의 생활을 보호하는 제도이다. 저임금 근로자의 소득을 보장하고 소득격차를 완화하는 중요한 역할을 하지만, 기업의 인건비와 고용에도 영향을 미친다. 따라서 최저임금은 근로자 보호와 기업 부담 사이의 균형을 고려하여 매년 결정된다. 오늘날 최저임금제는 노동시장과 국가경제 전반에 큰 영향을 미치는 핵심 제도로 자리 잡고 있다.

경제금융용어 공부 567 : 총액결제시스템

MKISOS — Tue, 21 Jul 2026 21:00:38 +0900

총액결제시스템

은행 간에는 하루에도 수많은 송금과 자금 거래가 이루어진다. 이러한 거래를 처리하는 방식에는 크게 총액결제와 차액결제 방식이 있다. 총액결제시스템은 거래를 서로 상계하지 않고 건별로 즉시 결제하는 방식이다. 금융기관은 더 많은 결제자금이 필요하지만, 결제 위험이 거의 없다는 장점이 있어 국가의 핵심 금융시스템에서 사용된다.

1. 한 줄 정의

총액결제시스템은 금융기관 간 거래를 상계하지 않고 거래 건마다 전액을 즉시 결제하는 지급결제시스템이다.

2. 기본 개념

총액결제시스템(Gross Settlement System)은 금융기관 간 지급지시가 발생할 때마다 거래금액 전체를 바로 결제하는 방식이다.

예를 들어 A은행이 B은행에 100억 원을 보내고, B은행이 A은행에 90억 원을 보내야 한다고 가정해보자.

총액결제시스템에서는 두 거래를 따로 처리한다.

A은행 → B은행 : 100억 원 결제
B은행 → A은행 : 90억 원 결제

즉, 차액인 10억 원만 계산하는 것이 아니라 각각의 거래를 독립적으로 처리한다.

현재 대부분의 총액결제시스템은 거래가 접수되는 즉시 결제가 이루어지는 실시간총액결제시스템(RTGS, Real-Time Gross Settlement System) 형태로 운영된다.

우리나라에서는 한국은행이 운영하는 한은금융망(BOK-Wire+) 이 대표적인 총액결제시스템이다.

3. 왜 중요한가

금융기관 사이에서는 거액의 자금이 오가는 경우가 많다.

만약 거래를 한꺼번에 모아서 나중에 결제한다면 중간에 한 금융기관이 결제를 하지 못하는 상황이 발생할 수 있다.

총액결제시스템은 거래가 발생하는 즉시 결제를 완료하기 때문에 이러한 위험을 크게 줄일 수 있다.

특히 중앙은행, 은행 간 거액결제, 국채 결제 등 금융시스템의 핵심 거래에서는 안전성이 무엇보다 중요하기 때문에 총액결제방식이 사용된다.

4. 쉽게 이해하는 예시

실생활 예시

친구에게 10만 원을 송금하면 바로 계좌에서 돈이 빠져나가고 친구 계좌에 입금된다.

중간에 여러 거래를 모아서 나중에 정산하지 않는다.

총액결제도 이와 비슷하게 거래가 발생할 때마다 바로 결제하는 방식이다.

대학생 예시

친구와 여러 번 돈을 주고받기로 했다고 가정해보자.

총액결제는 돈을 빌릴 때마다 바로 송금하는 방식이다.

반대로 차액결제는 하루가 끝난 뒤 서로 주고받을 금액을 계산해 차액만 송금하는 방식이다.

금융시장 예시

A은행이 B은행에 5,000억 원을 송금하는 거래가 발생했다면 총액결제시스템에서는 즉시 5,000억 원이 결제된다.

다른 거래와 합산하거나 차감하지 않는다.

5. 핵심 특징

5-1. 거래마다 즉시 결제한다

모든 거래를 개별적으로 처리하기 때문에 거래가 완료되는 즉시 결제가 끝난다.

결제 지연 가능성이 매우 낮다.

5-2. 결제 위험이 매우 낮다

거래를 미루지 않고 즉시 처리하기 때문에 신용위험과 시스템 리스크를 크게 줄일 수 있다.

금융안정 측면에서 매우 중요한 장점이다.

5-3. 많은 유동성이 필요하다

모든 거래를 건별로 처리하기 때문에 금융기관은 충분한 결제자금을 미리 확보해야 한다.

이를 위해 중앙은행은 일중당좌대출이나 일중RP 등 결제유동성 지원제도를 운영하기도 한다.

6. 관련 개념과의 차이

총액결제시스템 vs 차액결제시스템

총액결제시스템

거래 건별 즉시 결제
상계하지 않음
결제 위험 매우 낮음
많은 유동성 필요

차액결제시스템

일정 기간 거래를 모아 차액만 결제
상계 후 최종 차액만 지급
유동성 부담 적음
결제 전까지는 위험 존재

즉 총액결제는 안전성을, 차액결제는 효율성을 중시하는 방식이다.

총액결제시스템 vs 실시간총액결제시스템(RTGS)

총액결제시스템

거래를 건별로 전액 결제하는 방식

실시간총액결제시스템(RTGS)

총액결제를 실시간으로 수행하는 시스템

현재 대부분의 총액결제시스템은 RTGS 방식으로 운영된다.

7. 경제적 의미

국가경제 관점

총액결제시스템은 국가 금융시스템의 핵심 인프라이다.

거액 자금이 안전하게 결제될 수 있도록 하여 금융안정을 유지하는 역할을 한다.

기업 관점

기업 간 거액 거래나 금융기관 간 자금 이동이 안전하게 처리될 수 있다.

이를 통해 거래 신뢰도가 높아진다.

금융시장 관점

중앙은행과 금융기관 간 결제가 실시간으로 이루어져 금융시장 전체의 안정성이 향상된다.

우리나라에서는 한은금융망(BOK-Wire+)이 이러한 역할을 수행하고 있다.

투자 관점

개인투자자가 직접 총액결제시스템을 이용하는 일은 거의 없지만, 주식·채권·외환시장 등 대부분의 금융거래가 안전하게 이루어질 수 있는 기반이 된다.

또한 금융위기 상황에서는 총액결제시스템이 금융시스템의 연쇄 부실을 막는 중요한 역할을 한다.

8. 정리

총액결제시스템은 금융기관 간 거래를 상계하지 않고 거래 건마다 전액을 즉시 결제하는 지급결제시스템이다. 대부분 실시간총액결제시스템(RTGS) 형태로 운영되며, 결제 위험을 최소화할 수 있다는 장점이 있다. 반면 거래마다 전액을 결제해야 하기 때문에 금융기관은 충분한 유동성을 확보해야 한다. 우리나라에서는 한국은행의 한은금융망(BOK-Wire+)이 대표적인 총액결제시스템으로 운영되며, 금융시장의 안전성과 신뢰를 유지하는 핵심 역할을 수행하고 있다.

[26년 독후감 15] 누구나 이해하는 클라우드 인프라 지식 사전 : “You build it, you run it”

MKISOS — Tue, 21 Jul 2026 14:38:52 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

책 정보

책 제목: 누구나 이해하는 클라우드 인프라 지식 사전
저자: 바바 도시아키
출판 연도: 2026년 (2026년 6월 15일 출간)
장르: IT · 클라우드 인프라 · 서버/네트워크 · 백엔드 개발 · DevOps/SRE

❓ 책을 고른 이유 (물음표)

나는 백엔드 개발 → 클라우드 → 안정적인 서비스 운영 → 스타트업 CTO로 성장하는 것을 장기적인 목표 중 하나로 생각하고 있다. 현재 AWS와 클라우드에 대한 기본적인 개념은 알고 있지만 서비스가 실제로 어떻게 운영되고 왜 이러한 기술들이 필요한지에 대한 깊이 있는 이해는 아직 부족하다고 느끼고 있다.

이 책은 단순히 AWS 서비스의 사용법을 설명하는 것이 아니라 '왜 이러한 인프라 기술이 필요한가', '서비스는 어떤 원리로 동작하는가'를 중심으로 설명해 줄 것 같아 더욱 흥미를 느꼈다. 또한 목차를 살펴보니 서버, 네트워크, 운영체제, 컨테이너, 클라우드, 모니터링, DevOps, SRE, 보안 등 백엔드 개발자가 알아야 할 핵심 주제를 하나의 흐름으로 다루고 있어 마치 백엔드 개발자 로드맵을 따라가는 느낌이었다.

특히 최근 프로젝트를 진행하면서 서비스 운영과 인프라에 대한 중요성을 점점 체감하고 있었고 채용공고에서도 DevOps, SRE, 플랫폼 엔지니어링과 같은 키워드를 자주 접하면서 해당 분야에 대한 관심이 더욱 커졌다.

이번 기회를 통해 이미 알고 있는 개념은 다시 한번 체계적으로 정리하고 부족했던 인프라 지식을 보완하며 앞으로 직접 프로젝트에 적용할 수 있는 아이디어와 실무적인 관점을 얻고 싶다.

독서 과정

읽은 기간: 2026.07.06 - 2026.07.21

목차 일부와 용어집

✍️ 책 내용 정리

이 책은 AWS나 특정 클라우드 서비스의 사용법을 알려주는 책이라기보다 애플리케이션이 실제 서비스로 동작하기 위해 필요한 기반과 운영 원리를 폭넓게 설명하는 책이다. 서버, 네트워크, 운영체제, 컨테이너처럼 익숙한 기술부터 가용성, 관찰 가능성, DevOps, SRE, 릴리스 엔지니어링처럼 실무에서 자주 접하게 되는 개념까지 하나의 시스템 안에서 연결해 보여준다.

책을 읽으며 가장 크게 느낀 점은 클라우드 인프라를 공부한다는 것이 단순히 AWS 서비스 이름을 외우는 일이 아니라는 것이다. 결국 중요한 것은 사용자에게 가치 있는 기능을 안정적으로 제공하기 위해 시스템이 어떻게 구성되고 운영되는지를 이해하는 것이다.

정보 시스템은 사용자 가치를 위해 존재한다

정보 시스템은 개발자가 원하는 기능을 구현했다고 완성되는 것이 아니다. 실제 사용자가 시스템을 통해 가치를 얻을 수 있어야 존재 의미가 생긴다.

책에서는 사용자 가치를 크게 유용성과 안정성으로 나누어 설명한다.

유용성: 생산성을 높이거나 기존에는 불가능했던 일을 가능하게 만드는 것
안정성: 사용자가 서비스를 안심하고 신뢰하며 이용할 수 있게 하는 것

유용성은 주로 기능 요구사항으로 드러난다. 검색, 저장, 추천, 결제처럼 사용자가 직접 사용하는 기능이 여기에 해당한다. 반면 안정성은 비기능 요구사항으로 나타난다. 서비스가 끊기지 않는지, 응답이 충분히 빠른지, 사용자 정보를 안전하게 보호하는지, 사용자가 늘어나도 견딜 수 있는지와 같은 부분이다.

학생 프로젝트를 진행할 때는 기능 구현에 집중하기 쉽다. 회원가입이 되고, 데이터가 저장되고, AI 분석 결과가 출력되면 서비스가 완성됐다고 생각하기도 한다. 그러나 실제 서비스에서는 다음과 같은 질문까지 답할 수 있어야 한다.

서비스가 계속 정상적으로 동작하는가?
사용자가 필요할 때 이용할 수 있는가?
사용자가 늘어나도 처리할 수 있는가?
응답 속도가 충분히 빠른가?
데이터를 안전하게 보호하는가?
장기간 운영 가능한 비용과 구조를 갖췄는가?

이 질문들은 각각 신뢰성, 가용성, 용량, 성능, 보안, 지속성과 연결된다. 결국 기능 요구사항과 비기능 요구사항은 서로 경쟁하는 것이 아니라, 사용자 가치를 완성하는 두 축이다.

시스템을 계층 구조로 바라보기

애플리케이션은 혼자서 실행되지 않는다. 내가 작성한 코드 아래에는 라이브러리, 런타임, 운영체제, 네트워크, 서버와 같은 여러 계층이 존재한다.

예를 들어 TypeScript로 작성한 웹 애플리케이션을 실행한다고 생각해 보면 다음과 같은 계층을 거치게 된다.

애플리케이션 → 라이브러리 → 런타임 → 운영체제 → 네트워크 → 하드웨어

실제 시스템은 이처럼 단순한 직선 구조는 아니며 여러 계층이 복잡하게 의존한다. 그래도 계층 구조를 먼저 파악해 두면 장애가 발생했을 때 문제의 범위를 좁힐 수 있다.

브라우저에서 API 요청이 실패했다고 해서 반드시 백엔드 코드에 문제가 있는 것은 아니다. DNS 설정, TLS 인증서, 프록시, 네트워크 연결, 애플리케이션 프로세스, 데이터베이스 연결 중 어느 한 곳에서 문제가 발생했을 수도 있다. 시스템의 전체 구조를 모르면 보이는 코드만 수정하게 되지만, 계층을 이해하면 문제가 어느 경계에서 발생했는지 추적할 수 있다.

각 계층은 정해진 인터페이스를 통해 상호작용한다. API도 넓게 보면 계층 사이의 약속이다. 인터페이스가 유지된다면 내부 구현을 다른 기술로 교체할 수 있고, 이것이 호환성과 이식성으로 이어진다.

내 맥북에서 작성한 프로그램이 리눅스 서버에서도 실행될 수 있는 것은 런타임과 운영체제가 환경 차이를 중간에서 해결해 주기 때문이다. 컨테이너 역시 실행에 필요한 환경을 함께 묶어 이식성을 높이는 방법이다.

클라우드의 IaaS, PaaS, SaaS도 결국 시스템의 어느 계층까지 클라우드 사업자가 책임지는가에 따라 구분할 수 있다. 따라서 클라우드를 이해하려면 서비스 이름을 외우기 전에 시스템 계층과 책임 경계를 이해해야 한다.

You build it, you run it

책 전체를 관통하는 문장 중 하나는 **“You build it, you run it”**이었다. 자신이 만든 소프트웨어의 운영까지 책임져야 한다는 의미다.

이는 개발자가 모든 서버와 네트워크를 혼자 관리해야 한다는 뜻은 아니다. 자신이 만든 기능이 운영 환경에서 어떻게 동작하고, 사용자에게 어떤 영향을 주며, 장애가 발생했을 때 어떻게 발견하고 복구할 것인지까지 관심을 가져야 한다는 뜻에 가깝다.

개발팀과 운영팀의 벽을 허무는 DevOps 역시 이러한 관점에서 출발한다. 개발자는 코드를 배포한 뒤 책임이 끝나는 사람이 아니며, 운영자는 개발자가 넘긴 결과물을 수동으로 관리하기만 하는 사람도 아니다. 두 영역이 함께 사용자 가치를 책임져야 한다.

백엔드 개발자는 API가 정상 응답하는 것뿐만 아니라 다음 과정까지 이해해야 한다.

코드 작성 → 테스트 → 배포 → 릴리스 → 모니터링 → 장애 대응 → 개선

이 흐름을 경험해야 단순히 기능을 구현하는 개발자에서 안정적인 서비스를 운영할 수 있는 개발자로 성장할 수 있다.

고장은 예외가 아니라 전제다

개별 장비의 고장 확률을 0으로 만드는 것은 불가능하다. 서버가 몇 대 되지 않는 작은 시스템에서는 오랫동안 장애를 겪지 않을 수도 있지만, 이는 시스템이 완벽해서가 아니라 아직 운이 좋았을 가능성이 크다.

수백 대, 수천 대의 장비를 사용하는 환경에서는 발생 가능한 문제가 언젠가는 대부분 실제로 발생한다. 따라서 엔지니어링의 목표는 고장을 완전히 제거하는 것이 아니라, 고장이 발생해도 사용자 피해로 이어지지 않도록 설계하고 빠르게 복구하는 것이다.

이 관점에서 가용성을 서버의 업타임만으로 판단해서는 부족하다. 서버와 운영체제가 실행 중이어도 애플리케이션이 요청을 처리하지 못하거나, 데이터베이스에 저장할 공간이 없거나, 외부 네트워크와 통신하지 못한다면 사용자는 서비스를 이용할 수 없다.

따라서 가용성은 시스템 중심이 아니라 사용자 경험 중심으로 측정해야 한다.

웹서비스라면 대표적으로 다음 지표를 활용할 수 있다.

요청의 지연 시간
오류율
정상 응답 비율
일정 기간 동안 목표 수준을 만족한 시간

데이터 처리 시스템이라면 데이터 최신성, 누락률, 처리 정확도, 처리량 등이 더 중요할 수 있다. 즉 모든 시스템에 동일한 가용성 기준을 적용하는 것이 아니라, 그 시스템이 사용자에게 제공하는 가치에 맞는 지표를 정의해야 한다.

이러한 지표가 SRE에서 말하는 SLI, 즉 서비스 수준 지표로 이어진다. 서버가 살아 있는지를 확인하는 것에서 끝나는 것이 아니라, 사용자가 실제로 서비스를 정상적으로 이용할 수 있는지를 측정하는 것이다.

용량과 성능은 비슷하지만 다른 개념이다

용량과 성능은 자주 함께 언급되지만 구분해서 이해해야 한다.

용량은 시스템이 감당할 수 있는 전체 허용량이다. 단위 시간당 처리 가능한 요청 수, 저장 가능한 데이터의 양, 동시에 연결 가능한 사용자 수 등이 포함된다.

성능은 하나의 처리를 얼마나 빠르고 효율적으로 수행하는가에 가깝다. 웹서비스에서는 주로 요청부터 응답까지 걸리는 지연 시간으로 판단한다.

시스템 사용량이 허용량에 가까워지거나 도달한 상태를 포화라고 한다. 포화 상태에서는 요청이 지연되고 오류가 증가하며 예상하지 못한 동작이 발생할 수 있다. 따라서 실제 운영에서는 이론적 최대 용량을 모두 사용하는 것이 아니라, 갑작스러운 트래픽 증가와 장애 상황에 대응할 여유 용량을 남겨두어야 한다.

시스템 전체의 처리량은 가장 느린 컴포넌트에 의해 제한된다. 이 지점을 병목 지점이라고 한다.

예를 들어 애플리케이션 서버를 열 대로 늘려도 데이터베이스 한 대가 모든 요청을 감당하지 못한다면 전체 처리량은 개선되지 않는다. 반대로 데이터베이스가 충분히 빠른데 네트워크 대역폭이 부족하다면 CPU를 업그레이드해도 효과가 없다.

병목 지점을 다루는 대표적인 방법은 다음 세 가지다.

수평 확장: 동일한 역할을 하는 서버나 인스턴스의 수를 늘린다.
수직 확장: CPU, 메모리 등 개별 장비의 성능을 높인다.
성능 튜닝: 코드, 쿼리, 캐시, 설정 등을 개선해 자원을 효율적으로 사용한다.

핵심은 무작정 확장하는 것이 아니라 현재 병목이 어디에 있는지 먼저 측정하는 것이다.

성능 튜닝은 추측이 아니라 측정이다

성능 튜닝은 단순히 빠른 코드를 작성하는 활동이 아니다. 서비스와 아키텍처를 이해하고 부하 테스트를 통해 병목 지점을 찾은 뒤, 개선과 검증을 반복하는 과정이다.

책에서 제시하는 흐름을 정리하면 다음과 같다.

서비스의 목적과 사용 방식을 이해한다.
측정 대상과 목표를 정한다.
시스템 아키텍처와 데이터 흐름을 파악한다.
부하 테스트를 통해 병목 지점을 찾는다.
한 가지 개선안을 적용한다.
동일한 조건으로 다시 측정한다.
결과를 비교하고 다음 가설을 세운다.

특히 기억에 남았던 원칙은 한 번에 하나씩 변경하라는 것이다. 여러 설정과 코드를 동시에 바꾸면 결과가 좋아지거나 나빠져도 무엇이 원인인지 알 수 없다. 개선안끼리 서로 방해할 가능성도 있다.

또한 인터넷에서 발견한 성능 튜닝 방법을 그대로 적용해서도 안 된다. 어떤 최적화 방법은 특정 병목과 환경에서만 효과가 있기 때문이다. 다른 서비스에서 Redis 캐시를 도입해 성능이 좋아졌다고 해서 내 서비스에서도 반드시 같은 결과가 나오는 것은 아니다.

따라서 성능 튜닝의 핵심은 다음 문장으로 정리할 수 있다.

먼저 측정하고, 데이터를 바탕으로 가설을 세우며, 하나씩 검증한다.

이 방식은 감이나 운에 의존하지 않는다. 시스템 구조에 대한 이해와 논리적 사고, 측정 경험이 쌓일수록 반복적으로 좋은 결과를 만들 수 있다.

IaC는 인프라를 소프트웨어처럼 관리하는 방법이다

Infrastructure as Code, 즉 IaC는 서버, 네트워크, 데이터베이스, 컨테이너 등 인프라 구성을 코드로 정의하고 관리하는 방법이다.

IaC의 목적을 단순히 작업 자동화로만 이해해서는 부족하다. 코드로 관리하면 인프라에도 소프트웨어 개발의 장점을 적용할 수 있다.

동일한 환경을 다시 만들 수 있는 재현성
다른 프로젝트에서 활용할 수 있는 재사용성
변경 이력을 확인할 수 있는 버전 관리
변경 전에 검토할 수 있는 코드 리뷰
자동 테스트 및 CI/CD 연계
담당자의 수작업 실수 감소

특히 중요한 장점은 시간 절약보다 품질과 보안 수준을 일관되게 유지할 수 있다는 것이다.

다만 작은 프로젝트에서도 무조건 IaC를 도입해야 하는 것은 아니다. 도구를 배우고 관리하는 비용이 발생하기 때문이다. 여러 환경을 반복해서 구성하거나 여러 사람이 함께 인프라를 관리해야 할 때 IaC의 장점이 커진다.

캐시는 강력하지만 재사용 조건이 핵심이다

캐시는 처리 결과나 데이터를 저장해 두었다가 다시 사용하는 기술이다. 동일한 작업을 반복하지 않기 때문에 지연 시간과 서버 부하를 크게 줄일 수 있다.

캐시는 시스템 곳곳에서 사용된다.

CPU와 메모리 내부의 캐시
데이터베이스 쿼리 결과 캐시
애플리케이션 서버의 데이터 캐시
CDN의 콘텐츠 캐시
브라우저의 HTTP 캐시

캐시는 성능을 수십 배, 수백 배 높일 수도 있지만 잘못 사용하면 오래된 정보가 노출되거나 다른 사용자의 데이터가 전달되는 심각한 문제가 발생할 수 있다.

따라서 캐시를 적용할 때는 다음을 명확히 정해야 한다.

어떤 요청의 결과를 같은 데이터로 볼 것인가?
얼마 동안 재사용할 것인가?
원본 데이터가 변경됐을 때 어떻게 무효화할 것인가?
사용자별 데이터가 서로 섞이지 않는가?

HTTP 캐시에서는 주로 GET 요청의 응답을 재사용하며, 브라우저에 저장되는 프라이빗 캐시와 CDN 같은 중간 프록시에 저장되는 공유 캐시가 있다. 캐시가 실제로 적용됐는지는 브라우저 개발자 도구의 네트워크 탭과 HTTP 응답 헤더, CDN의 캐시 적중률 지표 등을 통해 확인할 수 있다.

프록시와 OODA 루프

프록시는 특정 컴포넌트 앞에서 요청을 대신 받아 처리하거나 전달하는 역할을 한다. 백엔드 시스템 앞에 배치된 리버스 프록시는 트래픽 분산, 캐시, HTTPS 종료, 보안 정책 적용 등의 역할을 할 수 있다. 반대로 포워드 프록시는 클라이언트를 대신해 외부 서버와 통신한다.

프록시를 이해하면서 느낀 점은 많은 인프라 기술이 완전히 새로운 기능을 만드는 것이 아니라, 기존 컴포넌트 사이에 계층을 추가해 책임을 분리하는 방식이라는 것이다.

OODA 루프는 관찰, 상황 판단, 의사결정, 행동을 빠르게 반복하는 의사결정 방식이다.

Observe → Orient → Decide → Act

중요한 것은 각 단계를 한 번 완벽하게 수행하는 것이 아니라 전체 순환 시간을 짧게 만들어 변화에 빠르게 대응하는 것이다. 이는 서비스 운영과도 잘 연결된다.

로그와 메트릭으로 상황을 관찰하고, 원인을 판단하고, 개선안을 결정하고, 배포한 뒤 다시 결과를 측정하는 과정이 하나의 OODA 루프가 된다.

인터넷과 네트워크를 이해해야 장애를 추적할 수 있다

인터넷과 웹은 동일한 개념이 아니다. 인터넷은 IP 프로토콜을 사용하는 여러 네트워크가 연결된 거대한 네트워크이고, 웹은 그 인터넷 위에서 제공되는 여러 서비스 중 하나다.

브라우저와 서버가 통신할 때 데이터는 네트워크 계층을 따라 이동한다. 송신 측에서는 상위 계층에서 하위 계층으로 내려가고, 수신 측에서는 다시 하위 계층에서 상위 계층으로 올라간다.

이 구조를 알고 있으면 장애 발생 시 어느 계층을 확인해야 하는지 판단할 수 있다. 케이블이나 무선 연결이 끊긴 것인지, IP 주소와 라우팅에 문제가 있는지, TCP 연결이 실패한 것인지, HTTP 요청이나 애플리케이션 로직에 문제가 있는지를 구분할 수 있다.

TCP는 연결을 맺고 데이터 손실 시 재전송하며 혼잡을 제어한다. UDP보다 정교하게 신뢰성을 보완하지만 연결과 상태 관리에 필요한 비용이 존재한다.

중요한 사실은 아무리 네트워크를 잘 설계해도 단절과 지연을 완전히 없앨 수 없다는 것이다. 따라서 애플리케이션은 네트워크 실패를 전제로 타임아웃, 재시도, 중복 요청 처리 등을 고려해야 한다.

네트워크 성능을 볼 때도 대역폭과 지연 시간을 구분해야 한다.

대역폭: 일정 시간 동안 얼마나 많은 데이터를 전송할 수 있는가
지연 시간: 데이터가 목적지까지 도달하고 돌아오는 데 얼마나 걸리는가
패킷 손실: 전송 과정에서 데이터가 얼마나 유실되는가
지터: 지연 시간이 얼마나 불규칙하게 변하는가

대역폭이 높아도 물리적 거리가 멀거나 네트워크 경로가 복잡하면 응답은 느릴 수 있다. 결국 네트워크 성능 역시 물리적 한계에서 자유로울 수 없다.

운영체제, 프로세스와 스레드

운영체제는 하드웨어와 애플리케이션 사이를 연결한다. 애플리케이션이 하드웨어 제조사나 물리적인 제어 방식을 직접 알지 않아도 파일, 메모리, 네트워크를 사용할 수 있도록 추상화한다.

애플리케이션은 시스템 콜을 통해 운영체제의 기능을 사용한다. Python이나 Go 같은 언어로 개발할 때 시스템 콜을 직접 작성하지 않더라도, 언어의 런타임과 라이브러리가 내부적으로 운영체제와 통신한다.

운영체제는 실행 중인 프로그램을 프로세스 단위로 관리한다. 프로세스마다 CPU 시간과 메모리 영역을 할당하며, 프로세스가 종료되면 사용하던 자원을 회수한다.

프로세스와 스레드의 핵심 차이는 메모리 공유 범위에 있다.

프로세스끼리는 기본적으로 메모리 영역이 분리된다.
같은 프로세스에 속한 스레드는 메모리를 공유한다.

스레드는 데이터를 쉽게 공유할 수 있지만, 동시에 같은 데이터에 접근하면서 경쟁 조건이나 동기화 문제가 발생할 수 있다. 반면 프로세스는 격리 수준이 높지만 프로세스 간 통신 비용이 더 필요하다.

백엔드 서버의 동시성 모델을 이해하려면 단순히 언어 문법뿐 아니라 운영체제가 프로세스와 스레드를 어떻게 관리하는지도 알아야 한다.

가상화, 도커와 쿠버네티스

가상화는 물리적인 컴퓨터 자원을 논리적으로 통합하거나 분리해 효율적으로 사용하는 기술이다. 여러 개의 디스크를 하나처럼 묶거나 하나의 물리 서버를 여러 가상 서버로 분리하는 것이 대표적이다.

가상화의 핵심 효과는 다음 두 가지다.

물리적 제약을 넘어 자원을 통합한다.
자원을 분할하고 격리해 효율성과 보안을 높인다.

도커는 애플리케이션 컨테이너를 만들고 공유하고 실행하기 쉽게 만든 대표적인 도구다. 이를 Build, Ship, Run으로 표현할 수 있다.

애플리케이션 코드와 실행에 필요한 환경을 컨테이너 이미지에 담아두면 개발 환경과 서버 환경의 차이를 줄일 수 있다. 이미지는 레지스트리에 저장하고, 필요한 환경에서 내려받아 컨테이너로 실행한다.

도커 컴포즈는 주로 한 호스트에서 여러 컨테이너를 함께 실행하는 데 사용한다. 반면 여러 호스트에 걸쳐 많은 컨테이너를 운영하려면 컨테이너 오케스트레이션 도구가 필요하며 대표적인 도구가 쿠버네티스다.

쿠버네티스에서는 하나 이상의 컨테이너를 포드 단위로 관리하고, 포드는 노드에서 실행된다. 클러스터의 전체 상태를 관리하고 지시하는 컨트롤 플레인과 실제 애플리케이션을 실행하는 데이터 플레인으로 구분할 수 있다.

쿠버네티스는 강력하지만 구성 요소가 많고 복잡하다. 따라서 단순히 유행하는 기술이라는 이유로 도입하기보다, 여러 서버와 컨테이너를 자동으로 배치하고 확장하고 복구해야 하는 요구가 있는지를 먼저 판단해야 한다.

클라우드를 안전하게 사용하는 세 가지 원칙

클라우드 서비스는 쉽게 생성할 수 있다는 점이 장점이지만, 그만큼 비용과 보안 사고도 쉽게 발생할 수 있다.

책에서 강조한 기본 원칙은 명확했다.

과금 체계를 먼저 파악한다.
자원의 정지와 삭제 방법을 미리 알아둔다.
기본 설정을 비공개로 유지한다.

실습을 위해 만든 서버나 데이터베이스를 삭제하지 않으면 사용하지 않는 동안에도 비용이 발생할 수 있다. 저장소나 데이터베이스를 실수로 공개하면 개인정보나 인증 정보가 노출될 수도 있다.

비용 절감과 비용 최적화도 구분할 필요가 있다. 비용 절감은 사용자 가치나 안정성을 일부 포기하면서 지출 자체를 낮추는 것까지 포함한다. 반면 비용 최적화는 사용자 가치의 손실을 최소화하면서 불필요한 비용을 제거하는 것이다.

좋은 클라우드 운영은 무조건 가장 저렴한 구성을 선택하는 것이 아니라, 필요한 신뢰성과 성능을 만족하면서 낭비를 줄이는 것이다.

DevOps와 SRE의 중심에는 사용자 가치가 있다

DevOps는 개발 도구나 자동화 제품의 이름이 아니다. 개발과 운영 사이의 벽을 낮추고 사용자에게 가치를 더 빠르고 안정적으로 전달하기 위한 문화와 접근 방식이다.

SRE는 이러한 DevOps 원칙을 소프트웨어 엔지니어링으로 구현하는 대표적인 방법이다. 대규모 시스템이 성장할수록 운영 인력도 계속 늘어나는 문제를 해결하기 위해, 반복적인 운영 작업을 자동화하고 시스템의 신뢰성을 측정 가능한 지표로 관리한다.

SRE는 단순히 인프라 엔지니어의 다른 이름이 아니다. 다음과 같은 요소가 함께 포함된다.

신뢰성을 수치로 측정하는 지표와 목표
반복적인 운영 작업의 자동화
장애를 전제로 한 설계
개발팀과 운영팀의 협업 구조
모니터링과 관찰 가능성
장애 이후의 학습과 개선

무엇보다 DevOps와 SRE를 도입하는 것 자체가 목적이 되어서는 안 된다. 최종 목적은 사용자 가치다. 유명한 방법론과 도구를 사용하지 않더라도 사용자에게 더 빠르고 안정적으로 가치를 전달하려고 노력하다 보면 자연스럽게 비슷한 실천 방식에 도달할 수 있다.

배포와 릴리스는 다르다

책에서는 배포와 릴리스를 구분한다.

배포: 새로운 코드를 실행 환경에 배치하는 것
릴리스: 사용자가 새로운 기능을 실제로 사용할 수 있게 하는 것

코드가 서버에 배포됐더라도 피처 플래그로 기능을 비활성화해 두었다면 아직 릴리스된 것은 아니다. 이 둘을 분리하면 코드를 먼저 안전하게 배포한 뒤 일부 사용자에게만 기능을 공개하거나, 문제가 발생했을 때 기능만 빠르게 끌 수 있다.

릴리스 엔지니어링은 빠른 릴리스와 시스템의 신뢰성을 함께 달성하기 위한 기술과 프로세스다. 수작업을 자동화하면 실수를 줄일 수 있지만, 자동화했다고 결함이 사라지는 것은 아니다. 따라서 문제를 빠르게 발견하고 릴리스를 중단하거나 되돌릴 수 있어야 한다.

데이터베이스 변경에서는 특히 호환성이 중요하다. 예를 들어 컬럼을 즉시 삭제하기보다 다음과 같이 여러 단계로 나누는 것이 안전하다.

애플리케이션에서 기존 컬럼 의존성을 제거한다.
변경된 애플리케이션을 먼저 배포한다.
더 이상 사용하지 않는 컬럼을 이후 배포에서 삭제한다.

새로운 컬럼으로 전환할 때도 기존 컬럼과 새 컬럼을 일정 기간 함께 처리하면 상위 버전과 하위 버전의 애플리케이션이 동시에 실행되는 상황에 대응할 수 있다.

결국 무중단 릴리스를 위해서는 코드뿐 아니라 세션, 데이터베이스 스키마, 데이터 상태의 호환성을 함께 고려해야 한다.

CI/CD와 GitOps

CI는 지속적 통합을 의미한다. 코드 포맷 검사, 린트, 정적 분석, 자동 테스트를 반복적으로 실행해 여러 개발자의 변경 사항을 지속적으로 통합한다.

CD는 배포 또는 전달 과정을 일상적으로 수행할 수 있도록 만드는 활동이다. 저장소에 특정 변경이 발생하면 빌드, 테스트, 배포가 자동으로 이어지도록 파이프라인을 구성할 수 있다.

GitOps는 코드 저장소를 시스템 상태의 단일 기준 정보로 두고, 운영 환경이 저장소에 정의된 상태와 일치하도록 관리하는 방식이다. 이 구조에서는 브랜치 전략과 운영 환경이 밀접하게 연결된다.

예를 들어 main 브랜치를 프로덕션 환경과 연결하거나, staging과 production 브랜치를 각각의 환경에 대응시킬 수 있다.

중요한 것은 CI/CD 도구 자체가 아니라 다음 질문에 답할 수 있는 구조를 만드는 것이다.

어떤 변경이 언제 배포됐는가?
테스트를 통과한 코드만 배포되는가?
문제가 발생하면 어느 버전으로 되돌릴 수 있는가?
배포 이후 이상을 빠르게 감지할 수 있는가?
운영 환경이 코드와 문서에 정의된 상태와 일치하는가?

릴리스 엔지니어링은 CI/CD만으로 완성되지 않는다. 모니터링, 관찰 가능성, 자동화, 데이터 호환성, 롤백 전략이 함께 작동해야 한다.

백엔드 개발자로 성장하는 방법

마지막 취업 파트는 현재 나에게 특히 현실적으로 다가왔다. 주니어 백엔드 개발자에게 깊은 인프라 경험까지 요구하는 경우는 많지 않지만, 아키텍처와 인프라를 적절히 이해하고 있다면 충분한 차별점이 될 수 있다. 리드급 엔지니어로 성장할수록 이러한 지식은 선택이 아니라 필수에 가까워진다.

책에서 제안한 학습 방법은 현재 사용하는 기술을 정확히 이해하는 것부터 시작한다.

어떤 기술을 사용하고 있다면 다음 질문에 답할 수 있어야 한다.

이 기술의 정확한 이름과 버전은 무엇인가?
시스템에서 어떤 역할을 담당하는가?
왜 이 기술을 선택했는가?
어떤 효과를 기대하고 있는가?
다른 대안은 무엇인가?
현재 방식의 장점과 한계는 무엇인가?
문제가 발생했을 때 어떻게 확인할 것인가?

그다음에는 자신이 담당하는 영역에서 한 계층 위와 아래로 시야를 넓혀야 한다.

백엔드 애플리케이션을 개발한다면 아래로는 런타임, 운영체제, 네트워크, 데이터베이스를 살펴볼 수 있다. 위로는 프론트엔드, 사용자 요청, 비즈니스 요구사항과 연결할 수 있다.

데이터 흐름을 따라 학습하는 방법도 유용하다.

브라우저 → DNS → CDN·프록시 → 웹 서버 → 애플리케이션 → 캐시 → 데이터베이스

개발 공정을 기준으로도 범위를 넓힐 수 있다.

요구사항 분석 → 설계 → 구현 → 테스트 → 배포 → 릴리스 → 모니터링 → 장애 대응

특정 기술을 사용하고 있다면 대체재를 비교해 보는 것도 좋은 공부가 된다. PostgreSQL을 사용한다면 MySQL과 어떤 차이가 있는지, Redis는 RDBMS와 어떤 문제를 다르게 해결하는지, 관리형 데이터베이스와 직접 운영하는 데이터베이스는 책임 범위가 어떻게 다른지 살펴볼 수 있다.

이러한 지식을 가장 효과적으로 연결하는 방법은 작은 서비스라도 직접 만들어 운영해 보는 것이다. 사용자를 받는 개인 프로젝트를 운영하면 책에서 외웠던 개념이 실제 문제로 나타난다.

도메인 연결, HTTPS 설정, 환경 변수 관리, 데이터베이스 마이그레이션, 로그 확인, 비용 관리, 장애 복구를 직접 경험하면서 비로소 “왜 이렇게 해야 하는가”를 이해하게 된다.

책 전체를 관통하는 핵심

이 책을 읽으며 클라우드 인프라는 개발과 분리된 별도의 영역이 아니라는 생각이 들었다. 코드는 인프라 위에서 실행되고, 인프라는 사용자가 서비스를 안정적으로 이용할 수 있도록 코드를 지탱한다.

책의 내용을 하나의 흐름으로 정리하면 다음과 같다.

사용자 가치 정의→ 기능·비기능 요구사항 설계→ 시스템 계층과 책임 경계 파악→ 가용성·용량·성능 목표 설정→ 측정과 모니터링→ 자동화된 배포와 안전한 릴리스→ 장애 대응과 지속적인 개선

결국 좋은 백엔드 개발자는 API와 비즈니스 로직만 구현하는 사람이 아니다. 자신의 코드가 어떤 환경에서 실행되고, 요청이 어떤 경로로 이동하며, 병목과 장애가 어디서 발생할 수 있는지 이해하는 사람이다.

그리고 더 나아가 사용자가 서비스를 계속 신뢰하고 이용할 수 있도록 시스템을 설계하고 운영하는 사람이 진정으로 서비스 전체를 바라보는 개발자라고 생각한다.

❗ 책을 덮으며 느낀 변화

이 책을 읽으며 클라우드와 백엔드 시스템에 대해 알고 있던 개념을 다시 정리할 수 있었고, 그동안 단편적으로 접했던 지식들이 하나의 구조로 연결되는 경험을 했다. 서버, 네트워크, 운영체제, 가상화, 컨테이너와 같은 소프트웨어적인 내용뿐만 아니라 데이터 센터, 서버 장비, 냉각과 같은 물리적인 영역까지 함께 다루고 있어 클라우드 서비스 뒤에서 실제로 어떤 인프라가 움직이고 있는지도 생각해 볼 수 있었다.

가장 크게 달라진 점은 배포와 운영을 바라보는 기준이다. 지금까지는 Vercel에 프로젝트를 배포하고 API가 정상적으로 동작하면 운영까지 어느 정도 해냈다고 생각했다. 하지만 이 책을 읽고 나니 로그, 장애 감지, 데이터 백업, 비용 관리 기준이 없는 상태는 단순히 서비스가 인터넷에서 실행되고 있을 뿐, 운영 가능한 서비스라고 부르기 어렵다는 생각이 들었다.

서비스를 운영한다는 것은 기능이 정상적으로 동작하는지만 확인하는 일이 아니었다. 응답 속도와 오류율을 측정하고, 장애가 발생했을 때 빠르게 감지하며, 데이터가 유실됐을 때 복구할 수 있어야 한다. 트래픽이 증가했을 때 어느 부분이 병목이 되는지 파악할 수 있어야 하고, 서비스의 안정성과 비용 사이에서 적절한 선택도 내려야 한다. 이전에는 배포를 개발의 마지막 단계처럼 생각했다면, 이제는 배포 이후부터 본격적인 운영과 개선이 시작된다고 보게 되었다.

책에 담긴 저자의 실무 경험을 통해 현업의 판단 과정을 간접적으로 접할 수 있었던 점도 좋았다. 서버와 네트워크에는 언제든 장애가 발생할 수 있으며, 중요한 것은 고장을 완전히 없애는 것이 아니라 고장이 발생하더라도 사용자에게 미치는 영향을 줄이고 빠르게 복구하는 것이라는 설명이 특히 기억에 남았다. 성능 튜닝 역시 감으로 설정을 변경하는 것이 아니라 데이터를 측정해 병목 지점을 찾고, 한 번에 하나씩 개선하며 결과를 검증하는 과정이라는 점을 배웠다.

기술을 공부하는 방식에 대해서도 다시 생각하게 되었다. 단순히 사용 방법을 익히는 것보다 해당 기술이 왜 필요하고 시스템 안에서 어떤 역할을 하는지 설명할 수 있어야 한다. Docker 명령어를 사용할 줄 아는 것보다 컨테이너가 어떤 문제를 해결하는지 알아야 하고, AWS나 클라우드 서비스에 애플리케이션을 배포하는 것보다 왜 해당 서비스를 선택했으며 다른 대안과 비교했을 때 어떤 장단점이 있는지 이해해야 한다.

특히 마지막 취업 파트는 현재의 나에게 가장 현실적으로 다가왔다. 주니어 백엔드 엔지니어에게 아키텍처, 인프라, DevOps에 대한 깊은 경험이 반드시 요구되는 것은 아니지만, 적절한 수준의 이해와 경험은 다른 지원자와 차별화할 수 있는 요소가 된다. 더 나아가 리드급 엔지니어로 성장하기 위해서는 코드뿐만 아니라 시스템의 구조, 데이터의 흐름, 배포와 운영 과정까지 폭넓게 이해해야 한다는 점이 인상 깊었다.

책에서는 자신이 현재 사용하고 있는 기술부터 정확히 설명할 수 있어야 한다고 말한다. 이 조언은 앞으로 프로젝트를 진행할 때 실제 습관으로 만들어 보고 싶다. 새로운 기술을 도입하면 단순히 “사용해 봤다”라고 기록하는 것이 아니라 다음 질문에 답할 수 있도록 정리할 생각이다.

이 기술의 정확한 역할과 사용한 버전은 무엇인가?
프로젝트의 어느 계층에서 사용되는가?
왜 이 기술과 아키텍처를 선택했는가?
어떤 문제를 해결하기 위해 도입했는가?
비교할 수 있는 다른 대안은 무엇인가?
현재 방식의 장점과 한계는 무엇인가?
운영 중 문제가 발생하면 무엇을 확인해야 하는가?

현재 알고 있는 영역에서 한 계층 위와 아래까지 공부하는 습관도 들이고 싶다. 백엔드 애플리케이션을 개발한다면 코드와 API만 보는 데서 멈추지 않고, 요청이 들어오는 앞단의 DNS, HTTP, 프록시부터 데이터가 전달되는 데이터베이스, 운영체제, 네트워크, 클라우드 환경까지 흐름을 따라가며 이해하려고 한다.

개발 공정의 앞뒤로 시야를 넓히는 연습도 필요하다. 요구사항이 어떻게 정의되는지, 어떤 기준으로 아키텍처를 선택하는지, 테스트와 QA는 어떻게 진행하는지, 배포와 릴리스는 어떻게 구분되는지, 운영 중 발생한 문제를 어떤 로그와 지표로 확인하는지까지 경험해야 한다.

이를 위해 지금 진행 중인 프로젝트와 앞으로 만들 개인 서비스를 단순히 배포된 결과물로 끝내지 않고, 일정 기간 실제로 운영하며 개선해 보고 싶다. 로그를 남기고 확인하는 구조를 만들고, 오류나 장애를 감지할 수 있는 모니터링을 적용하며, 데이터 백업과 복구 방법도 직접 점검해 볼 생각이다. 가능하다면 부하 테스트를 통해 병목 지점을 찾아보고, 장애 상황을 가정해 서비스가 어떻게 동작하는지도 확인해 보고 싶다.

Docker와 CI/CD 역시 포트폴리오에 기술 이름을 추가하기 위해 도입하는 것이 아니라, 실행 환경의 차이를 줄이고 반복적인 배포 과정을 안정적으로 관리하기 위한 목적으로 활용해야 한다. 데이터베이스나 클라우드 서비스를 선택할 때도 익숙하다는 이유만으로 결정하지 않고 비용, 성능, 확장성, 운영 난이도, 벤더 종속성과 같은 기준을 대안과 함께 비교해 보고 싶다.

이 책을 읽기 전에는 클라우드와 인프라를 백엔드 개발 이후에 추가로 공부해야 하는 영역으로 생각했던 부분이 있었다. 그러나 책을 덮은 뒤에는 백엔드 개발, 인프라, 배포, 운영이 서로 분리된 과정이 아니라 사용자에게 안정적인 가치를 전달하기 위해 함께 연결되어야 하는 하나의 흐름이라는 생각이 들었다.

앞으로는 새로운 기술을 빠르게 익히는 데만 집중하지 않고, 기술이 바뀌어도 남아 있는 시스템의 기본 원리를 꾸준히 공부하고 싶다. 기능을 구현하고 인터넷에 배포하는 데서 멈추지 않고, 내가 만든 서비스가 어떤 환경에서 실행되고 사용자의 요청이 어떤 경로를 거치며 문제가 발생했을 때 어떻게 발견하고 복구할 것인지까지 고민하는 개발자로 성장하고자 한다.

이러한 경험을 하나씩 쌓아 가는 과정이 안정적인 서비스를 설계하고 운영할 수 있는 백엔드 개발자, 그리고 장기적으로 기술과 비즈니스를 함께 판단할 수 있는 CTO로 성장하는 기반이 될 것이라고 생각한다.

총평 및 추천 여부

별점: ★★★★★ (5점 만점)
이 책을 추천하는 대상: 클라우드와 인프라를 단편적인 기술이 아닌 전체 시스템의 관점에서 이해하고 싶은 사람
한줄평: 기능을 구현하는 개발자에서 시스템 전체를 이해하고 안정적으로 운영하는 개발자로 성장하기 위한 클라우드 인프라 입문 사전

[BEYOND BUSAN 3기] 부산까지, 걱정보다 더 큰 기대를 얻은 첫 워크숍

MKISOS — Tue, 21 Jul 2026 10:24:17 +0900

2026년 7월 20일, 부산유라시아플랫폼에서 열린 BEYOND BUSAN 3기 11차 워크숍에 참석했다.

BEYOND BUSAN은 부산디지털자산거래소 Bdan과 함께 블록체인, 디지털 자산, AI, 미래 금융 산업을 알아가고 직접 프로젝트를 수행하는 대학생 성장 프로그램이다.

이번 워크숍은 BEYOND BUSAN의 활동 방향과 개인·조별 미션을 확인하고, 앞으로 함께 활동할 조원들을 처음 만나는 자리였다.

행사에 참석하기 전까지는 기대만큼 걱정도 컸다. 하지만 워크숍을 마친 뒤에는 먼 거리를 이동해 부산까지 오길 잘했다는 생각이 들었다.

부울경 중심의 활동이지만 일단 지원해 보았다

사실 모집 공고를 처음 확인했을 때는 부울경 지역 대학생들의 참여를 우선적으로 고려하는 활동처럼 느껴졌다.

나는 충북대학교에 재학 중이고 현재도 청주에서 생활하고 있기 때문에 지역적으로는 다소 거리가 있었다. 그럼에도 지원서를 제출한 이유는 부산에서 블록체인과 AI, 디지털 금융에 관한 새로운 인사이트를 얻고 싶었기 때문이다.

부산은 블록체인 규제자유특구를 기반으로 디지털 자산과 미래 금융 산업을 적극적으로 준비하고 있다. 개발자를 목표로 공부하고 있는 나에게는 이러한 산업의 변화를 현장에서 직접 접할 수 있다는 점이 매력적으로 다가왔다.

평소에도 AI와 백엔드 개발뿐만 아니라 금융, 투자, 블록체인 분야에 관심이 많았기 때문에 전공과 산업을 함께 연결해 볼 수 있는 기회라고 생각했다.

지역 조건 때문에 선발 가능성이 높지 않을 수도 있다고 생각했지만, 내가 중요하게 여기는 말처럼 일단 빠르게 도전해 보기로 했다.

Fail Fast.

결과적으로 BEYOND BUSAN 3기에 합격했고, 직접 부산을 방문해 첫 워크숍에 참여하게 되었다.

⸻

청주에서 부산까지, 사실 부담도 있었다

합격한 뒤에는 기쁜 마음과 함께 현실적인 고민이 생겼다.
청주에서 부산까지 이동해야 했기 때문이다.
워크숍이나 정기 모임이 있을 때마다 부산을 오가는 것이 생각보다 부담스럽지 않을까 걱정했다. 이동 시간과 비용도 고려해야 했고, 어렵게 부산까지 갔는데 내가 기대했던 활동과 다르면 어쩌나 하는 생각도 들었다.

단순한 홍보 활동이나 형식적인 네트워킹으로 끝난다면 먼 거리를 이동하는 의미가 크지 않을 수도 있었다.
그래서 첫 워크숍에 참석하기 전까지는 기대와 걱정이 함께 있었다.
하지만 막상 현장에 도착해 프로그램에 참여하고 조원들과 이야기를 나눠보니, 그런 걱정은 많이 줄어들었다. 프로그램의 방향도 내가 기대했던 것보다 구체적이었고, 무엇보다 함께하게 된 사람들이 정말 좋았다.

⸻

부산디지털자산거래소와 BEYOND BUSAN

워크숍은 부산디지털자산거래소 Bdan에 대한 소개로 시작됐다.

BEYOND BUSAN은 단순히 기업이나 행사를 홍보하는 대학생 서포터즈가 아니다. 부산이 블록체인, AI, 디지털 금융을 중심으로 미래 산업을 준비하는 과정에서 대학생들이 직접 배우고, 제안하고, 실행하는 성장 플랫폼에 가까웠다.

프로그램의 슬로건은 다음과 같다.

부산을 넘어 세계로, 대한민국의 미래를 여는 청년 디지털 혁신가

참가자들은 활동을 통해 블록체인과 디지털 자산, 실물자산 토큰화인 RWA, 미래 금융 산업을 학습하게 된다. 여기에 정책·사업 아이디어 제안, 콘텐츠 제작, 지역사회 참여, 네트워킹과 같은 실전 활동도 함께 진행한다.

워크숍에서 특히 기억에 남았던 메시지는 다음과 같다.
얼마나 많이 참여했는가보다, 얼마나 성장했는가.
대외활동을 하다 보면 때로는 수료증이나 활동 이력만 남는 경우가 있다. 하지만 BEYOND BUSAN은 단순한 참여 횟수보다 활동 과정에서 무엇을 배우고, 누구를 만나고, 어떤 결과물을 만들었는지를 더 중요하게 생각하고 있었다.

프로그램이 추구하는 핵심 가치도 명확했다.

도전, 실행, 연결, 성장.

보장되지 않은 결과에도 도전하고, 아이디어에서 멈추지 않고 실제로 행동하며, 다양한 사람들과 연결되어 함께 성장하는 것이다.

완벽하게 준비될 때까지 기다리기보다 먼저 시도하고, 실행 과정에서 배우려는 나의 가치관과도 잘 맞는다고 느꼈다.

⸻

블록체인과 디지털 금융을 개발자의 관점으로 바라보다

이번 활동에서 내가 가장 기대하는 부분은 블록체인과 디지털 금융 산업을 개발자의 관점으로 이해할 수 있다는 점이다.

나는 현재 AI와 백엔드 개발을 중심으로 공부하고 있다. 이전에는 블록체인을 금융이나 투자에 가까운 분야로만 생각하기도 했다. 하지만 조금씩 알아갈수록 블록체인은 거래 시스템, 데이터 검증, 인증, 보안, 분산 시스템, 스마트 컨트랙트 등 소프트웨어 기술과 밀접하게 연결되어 있었다.

BEYOND BUSAN에서는 앞으로 다음과 같은 분야를 학습하고 경험할 예정이다.

* 블록체인과 디지털 자산
* 실물자산 토큰화 RWA
* AI와 스마트시티
* 디지털 금융 산업
* 글로벌 산업 및 직무 트렌드

백엔드 개발자는 단순히 API와 서버를 구현하는 데서 역할이 끝나지 않는다.

서비스가 속한 산업의 구조와 사용자가 겪는 문제를 이해해야 안정적이고 실질적인 시스템을 설계할 수 있다. 그런 의미에서 블록체인이나 디지털 금융과 같은 새로운 산업을 이해하는 경험은 개발자로서의 시야를 넓히는 데 도움이 될 것이라고 생각한다.

이번 활동을 통해 기술 용어만 공부하는 데서 그치지 않고, 디지털 자산이 실제 금융과 도시 산업에 어떻게 적용되는지를 알아가고 싶다. 지금까지 공부한 AI와 백엔드 기술을 새로운 산업과 연결할 수 있는 가능성도 찾아보고 싶다.

⸻

BWB2026에서 얻을 수 있는 현장의 인사이트

BEYOND BUSAN 3기는 부산디지털자산거래소와 BWB2026 공식 서포터즈로 활동한다.

BWB2026은 2026년 12월 2일 전야제를 시작으로, 12월 3일 부산 벡스코 오디토리움에서 본 행사가 진행될 예정이다.

이번 활동에 지원하면서 가장 기대했던 부분 중 하나가 바로 BWB2026이었다.

온라인 강의나 기사로 산업을 공부하는 것도 중요하지만, 실제 현장에서 일하는 사람들의 이야기를 듣고 관련 기업과 업계 관계자들을 만나는 경험은 또 다른 의미가 있다.

특히 진로의 가능성을 넓혀가고 있는 대학생으로서 글로벌 산업의 흐름과 다양한 직무를 접하는 것은 앞으로의 방향을 설정하는 데 큰 도움이 될 수 있다.

BWB2026에서는 블록체인과 디지털 자산 산업의 글로벌 트렌드를 살펴보고, 관련 기업과 기술을 직접 확인할 수 있을 것으로 기대한다.

단순히 행사에 참석했다는 기록만 남기기보다는 사전에 참여 기업과 기술을 공부하고, 현장에서 얻은 내용을 나만의 언어로 정리해 블로그에 기록해 보고 싶다.

⸻

걱정을 기대감으로 바꿔준 3조 조원들

이번 워크숍에서 가장 좋았던 것은 함께 활동할 3조 조원들을 만난 것이었다.

사실 처음 만나는 사람들과 조를 이루는 만큼 분위기가 어색하거나 활동에 대한 온도 차이가 있을 수도 있다고 생각했다. 하지만 막상 대화를 나눠보니 조원들 모두 성격이 좋았고, 활동에도 적극적으로 참여했다.

단순히 밝고 친근한 것을 넘어 서로의 의견을 잘 들어주고, 앞으로의 활동에 대해 열정적이고 건설적인 이야기를 나누는 모습이 인상적이었다.

처음 만난 자리였지만 누군가 혼자 대화를 주도하기보다 모두가 자연스럽게 의견을 나누었다. 앞으로 콘텐츠를 어떻게 만들면 좋을지, 각자 어떤 강점을 가지고 있는지 이야기하면서 금방 가까워질 수 있었다.

우리 조에는 정말 다양한 전공의 학생들이 모였다.

* 호텔경영학
* 경제·금융학
* 영어영문학
* 통계학
* 패션디자인학
* 소프트웨어학

같은 활동에 참여했지만 각자가 공부하는 분야와 바라보는 관점은 모두 달랐다.

소프트웨어를 공부하는 나는 서비스를 기술과 구현의 관점에서 바라보는 경우가 많다. 반면 호텔경영이나 패션디자인을 공부하는 조원은 고객 경험과 브랜딩의 관점에서, 경제·금융이나 통계학을 공부하는 조원은 시장과 데이터의 관점에서 문제를 바라볼 수 있다. 영어영문학을 전공하는 조원은 글로벌 커뮤니케이션과 콘텐츠 표현에서 강점을 발휘할 수 있다.

이렇게 서로 다른 배경을 가진 사람들이 함께한다는 점이 이번 활동의 가장 큰 장점 중 하나라고 생각한다.

앞으로 조별 콘텐츠와 프로젝트를 진행하면서 내가 생각하지 못했던 관점을 배우고, 나 역시 소프트웨어와 AI에 관한 경험을 조원들과 나눌 수 있을 것 같다.

어떤 인사이트를 주고받게 될지, 그리고 서로 다른 전공이 하나의 결과물 안에서 어떻게 연결될지 기대된다.

청주에서 부산까지 가야 한다는 부담과 행사에 대한 걱정도 있었지만, 좋은 팀원들을 만난 것만으로도 첫 워크숍에 참석한 의미가 충분했다.

첫날부터 좋은 에너지를 만들어준 우리 3조 조원들 모두 최고였다.

앞으로 수행할 개인 미션과 조별 미션

BEYOND BUSAN 3기의 활동은 크게 개인 미션과 조별 미션으로 구성된다.

개인 미션은 글로벌 허브도시 부산 실현을 위한 아이디어 제안 공모전이다.

참가자는 부산의 도시 자산과 성장 가능성을 바탕으로 다음 네 가지 분야 중 하나를 선택해 정책 또는 사업 아이디어를 제안해야 한다.

* 금융·경제
* 항만·물류·글로벌 비즈니스
* 관광·디자인·문화
* 시민생활·청년 미래

공모전 제출 마감일은 2026년 10월 1일이며, 결과 발표와 시상은 12월 3일 BWB2026 행사 이후 진행될 예정이다.

평가에서는 단순히 아이디어가 참신한지만 보는 것이 아니다.

문제 인식과 현황 분석, 창의성, 정책 적합성, 실행 가능성, 지속 가능성, 제안서의 전달력을 종합적으로 평가한다. 특히 실행 가능성과 정책 구체성의 배점이 가장 높았다.

좋은 아이디어를 떠올리는 것에서 끝나는 것이 아니라 실제로 어떻게 실행하고 지속할 것인지까지 설계해야 한다는 의미다.

조별 미션은 부산디지털자산거래소와 관련된 온라인 콘텐츠를 제작하는 것이다.

카드뉴스, 인스타그램 게시물, 릴스 등 다양한 형식으로 최소 7개의 콘텐츠를 만들어야 한다. 콘텐츠 주제와 형식은 조원들이 직접 기획하고, 제작 과정에서도 각자의 전공과 강점을 활용할 수 있다.

단순히 주어진 내용을 옮기는 홍보물이 아니라 블록체인과 디지털 자산을 처음 접하는 사람도 쉽게 이해할 수 있는 콘텐츠를 만드는 것이 중요할 것 같다.

⸻

앞으로의 주요 일정

첫 워크숍 이후에는 다음 일정이 예정되어 있다.

* 8월 29일: BEYOND BUSAN 정기 모임
* 10월 1일: 개인 아이디어 공모전 제출 마감
* 10월 31일: 조별 콘텐츠 미션 마감
* 12월 2일: BWB2026 전야제
* 12월 3일: BWB2026 본 행사 및 수료식

활동 기간 동안 조별로 부산디지털자산거래소 관련 온라인 콘텐츠를 최소 7개 제작해야 하며, 개인별로는 글로벌 허브도시 부산을 위한 공모전에 참여해야 한다.

아직 구체적인 콘텐츠 주제와 공모전 아이디어는 정하지 않았지만, 첫 워크숍에서 만난 조원들과 차근차근 방향을 만들어갈 생각이다.

⸻

수료증보다 사람과 경험이 남는 활동

BEYOND BUSAN을 수료하면 부산디지털자산거래소 명의의 수료증과 굿즈, BWB2026 참여 기회, 리더스클럽 지원 자격 등이 제공된다.

우수 활동자에게는 부산광역시장상, 부산디지털자산거래소 대표상과 여러 기업의 대표상이 수여되며, 부산디지털자산거래소 인턴십 기회도 제공된다.

물론 이러한 혜택도 매력적이다.

하지만 첫 워크숍을 마친 지금 가장 기대되는 것은 수료증 자체보다 앞으로 만나게 될 사람과 활동 과정에서 얻을 경험이다.

블록체인과 디지털 금융이라는 새로운 산업을 공부하고, BWB2026을 통해 현장의 관계자와 기업을 만나고, 다양한 전공의 대학생들과 협업해 실제 결과물을 만드는 모든 과정이 개발자로 성장하는 데 중요한 자산이 될 것 같다.

개발자는 혼자 코드를 잘 작성하는 것만으로 완성되지 않는다.

사람들이 겪는 문제를 이해하고, 다른 분야의 사람들과 소통하며, 아이디어를 실제 서비스로 구현할 수 있어야 한다. 장기적으로 기술 창업을 목표로 하는 나에게는 더욱 필요한 경험이다.

그런 의미에서 BEYOND BUSAN은 내가 목표로 하는 개발자와 창업가의 방향에도 잘 맞는 활동이라고 생각한다.

⸻

부산을 넘어 더 넓은 세상으로

첫 워크숍을 통해 BEYOND BUSAN이 단순한 홍보 서포터즈가 아니라는 것을 확인할 수 있었다.

블록체인과 AI, 디지털 금융 산업을 공부하고, BWB2026을 통해 업계의 현장을 경험하며, 다양한 전공의 대학생들과 직접 콘텐츠와 아이디어를 만들어가는 성장 플랫폼이었다.

처음에는 부울경 중심의 활동에 충북대학교 학생인 내가 지원해도 될지 고민했다. 합격한 뒤에는 청주에서 부산까지 이동하는 부담과 기대했던 행사와 다를 수 있다는 걱정도 있었다.

하지만 막상 현장을 방문하니 새로운 산업에 대한 인사이트를 얻을 수 있었고, 무엇보다 함께 성장하고 싶은 좋은 조원들을 만났다.

앞으로 활동하면서 모르는 것은 적극적으로 질문하고, 배운 것은 기록하며, 떠오른 아이디어는 빠르게 실행해 보려고 한다.

아직 블록체인과 디지털 금융에 대해 배워야 할 것이 많지만, 그렇기 때문에 이번 활동이 더욱 기대된다.

좋은 조원들과 함께하게 된 만큼 과정 자체를 즐기면서, 활동이 끝났을 때 단순한 수료 이력보다 분명한 성장과 결과물을 남기고 싶다.

부산을 넘어 세계로.

청주에서 시작한 나의 BEYOND BUSAN 3기 활동도 이제 본격적으로 시작된다.

[UNIKER] CampusLog, 로그인·DB와 오늘의 기록을 구현하고 사용자 흐름을 다시 점검하다

MKISOS — Tue, 21 Jul 2026 05:59:22 +0900

지난 7월 12일 멘토링에서 저희 팀은 CampusLog의 1차 MVP를 보여드리고, 현재 기능만으로는 아직 사용자가 계속 사용하고 싶을 만큼 매력적인 프로덕트로 느껴지지 않을 수 있다는 피드백을 받았습니다.
당시 CampusLog에는 활동 경험 기록, AI 분석, 경험 추천이라는 핵심 흐름이 구현되어 있었습니다. 하지만 경험을 단순히 카드 목록으로 보여주는 것에서 그치지 않고, 캘린더·타임라인·태그·마인드맵처럼 경험이 쌓일수록 더 편리해지는 탐색 구조가 필요하다는 이야기를 들었습니다.
또한 개발 프로젝트나 공모전 경험에 치우친 팀 내부 데이터만으로 테스트하지 말고 다양한 전공과 활동을 가진 지인들에게 실제 서비스를 사용하게 해보라는 조언도 받았습니다.
이번 주에는 이 피드백을 바탕으로 단순히 화면을 다듬는 것을 넘어, CampusLog를 실제 사용 가능한 서비스 구조로 확장하고 AI 결과의 활용도를 높이는 작업을 진행했습니다.
기능은 많이 발전했지만, 7월 19일 멘토링에서는 오히려 기능이 늘어난 만큼 사용자 흐름이 복잡해졌다는 새로운 문제를 발견했습니다.
이번 글에서는 7월 12일 멘토링 이후 진행한 개발 작업과 7월 19일 멘토링에서 받은 피드백을 함께 정리해보려고 합니다.

1차 MVP에서 2차 MVP 단계로

기존 CampusLog의 1차 MVP는 브라우저의 localStorage를 이용해 활동 경험과 AI 분석 결과를 저장하는 구조였습니다.
이 방식은 빠르게 핵심 기능을 검증하기에는 적합했지만, 브라우저나 기기가 바뀌면 데이터를 이어서 사용할 수 없고 사용자별로 데이터를 구분하기도 어려웠습니다.
저희 팀은 1차 MVP의 핵심 흐름을 기준선으로 남겨두고, 이번 주부터 프로젝트를 2차 MVP 단계로 전환했습니다.
2차 MVP는 크게 두 방향으로 나누었습니다.
첫 번째는 인증·데이터·AI 기능 고도화입니다.
두 번째는 디자인과 사용자 경험 고도화입니다.
기능과 디자인을 하나의 큰 작업에서 동시에 수정하면 충돌이 발생하기 쉽기 때문에, 작업 범위를 나누고 기능별 브랜치와 Pull Request를 통해 개발을 진행했습니다.

Supabase 기반 로그인과 회원가입 구현

이번 주에 진행한 가장 큰 기반 작업 중 하나는 로그인과 회원가입 기능이었습니다.
Supabase Auth를 이용해 다음 인증 방식을 구현했습니다.

이메일과 비밀번호를 이용한 회원가입·로그인
Google OAuth 로그인
로그아웃
로그인 여부에 따른 보호 페이지 접근 제한
신규 사용자의 이름·닉네임 온보딩

처음 서비스에 접속한 사용자는 CampusLog의 브랜드 화면을 본 뒤 로그인 또는 회원가입 영역으로 이동할 수 있습니다.
이메일 회원가입은 이메일과 비밀번호를 입력한 뒤 이름과 닉네임을 설정하는 단계형 흐름으로 구성했습니다. Google로 가입한 사용자도 필요한 프로필 정보가 없으면 온보딩 화면으로 이동해 동일한 정보를 입력하도록 했습니다.
로그인하지 않은 사용자가 대시보드나 AI 기능에 접근하면 로그인 화면으로 이동하고, 인증이 완료된 사용자만 자신의 기록을 관리할 수 있도록 구조를 변경했습니다.
단순히 로그인 버튼만 붙인 것이 아니라, 인증 상태가 전체 사용자 흐름과 자연스럽게 연결되도록 정리하는 작업이었습니다.

localStorage에서 사용자별 Supabase DB로 전환

인증 기능을 구현한 뒤에는 활동과 경험 데이터를 Supabase Postgres에 저장하도록 전환했습니다.
기존에는 같은 브라우저를 사용하는 모든 데이터가 localStorage에 저장되었습니다. 이제는 로그인한 사용자의 ID를 기준으로 데이터가 분리됩니다.

이를 위해 다음 데이터를 사용자별 테이블 구조로 정리했습니다.

활동 경험
진행 중인 활동
날짜별 기록
AI 경험 분석
AI 추천 기록
AI 답변 초안
경험 보완 답변
활동 종료 후 생성된 AI 초안

데이터 접근은 Repository 구조로 분리했습니다.
화면 컴포넌트가 localStorage나 Supabase를 직접 다루지 않고, 공통 Repository 인터페이스를 통해 데이터를 읽고 쓰도록 변경했습니다. 덕분에 화면 구조를 크게 바꾸지 않으면서 저장소를 localStorage에서 Supabase로 교체할 수 있었습니다.
또한 Row Level Security, 즉 RLS를 적용했습니다.
RLS는 단순히 화면에서 다른 사용자의 데이터를 숨기는 것이 아니라 데이터베이스 단계에서 로그인한 사용자가 자신의 데이터만 조회·수정·삭제할 수 있도록 제한하는 기능입니다.
서로 다른 Google 계정으로 로그인해 각 계정의 데이터가 분리되는 것도 직접 확인했습니다.

팀 테스트 계정 9개 준비

팀원들이 하나의 Google 계정을 공유해 테스트하려고 하자, 접속 위치와 기기가 달라 보안 차단이 발생하는 문제가 있었습니다.
이를 해결하기 위해 Supabase Auth의 이메일·비밀번호 인증을 이용한 테스트 계정을 별도로 만들었습니다.
test1부터 test9까지 총 9개의 계정을 생성할 수 있는 서버 전용 시드 스크립트를 추가했습니다.

 
             test1@campuslog.test
...
test9@campuslog.test 
            

각 계정에는 온보딩이 완료된 사용자처럼 사용할 수 있도록 테스트용 프로필 정보도 함께 넣었습니다.
계정 생성에는 Supabase의 관리자 권한이 필요하기 때문에 관리자 키는 앱 코드나 브라우저에 포함하지 않고, 계정을 생성하는 담당자의 서버 환경에서만 사용하도록 분리했습니다.
이제 팀원들은 서로 다른 테스트 계정으로 로그인해 데이터가 섞이지 않는 상태에서 기능을 검증할 수 있습니다.

하루하루 기록할 수 있는 ‘오늘의 기록’ 기능

지난 멘토링에서 경험을 목록뿐 아니라 캘린더나 시간의 흐름으로 보여주는 방향을 고민해보라는 피드백을 받았습니다.
기존 CampusLog는 활동이 끝난 뒤 사용자가 제목, 역할, 내용, 성과 등을 자세히 입력하는 방식이었습니다.
하지만 활동이 끝난 뒤 한 번에 정리하려고 하면 그동안 했던 세부 작업과 문제 해결 과정을 잊기 쉽습니다. 또 매번 긴 내용을 정성스럽게 입력해야 한다면 서비스 사용 자체가 부담이 될 수 있습니다.
그래서 이번 주에는 진행 중인 활동을 먼저 등록하고, 날짜별로 실제 한 일을 간단하게 기록하는 기능을 추가했습니다.
현재 흐름은 다음과 같습니다.

활동 추가
→ 날짜별로 오늘 한 일 기록
→ 월간 캘린더에서 기록 확인
→ 활동 종료
→ AI가 날짜별 기록을 하나의 완료 경험 초안으로 정리
→ 사용자가 검토한 뒤 나의 활동으로 저장

예를 들어 CampusLog 프로젝트를 진행 중인 활동으로 추가한 뒤, 매일 다음처럼 짧게 기록할 수 있습니다.

 
             7월 14일
Supabase 로그인 구현 및 Google OAuth 연결

7월 15일
AI 분석 결과에 STAR 구조와 근거 정보 추가

7월 16일
추천 결과 오류 수정 및 모바일 화면 점검 
            

활동이 종료되면 AI는 해당 활동의 기본 정보와 날짜별 기록을 바탕으로 내용, 역할, 성과, 부족한 근거를 정리합니다.
사용자는 처음부터 완성된 경험을 작성하지 않아도 되고, 실제로 했던 일을 조금씩 기록해두었다가 나중에 하나의 경험으로 완성할 수 있습니다.
/dashboard는 오늘의 기록과 캘린더를 중심으로 바뀌었고, /experiences에서는 진행 중인 활동과 완료된 경험을 함께 볼 수 있도록 구성했습니다.

과거 경험과 진행형 활동을 함께 관리하기

CampusLog에는 두 가지 경험 등록 방식이 존재합니다.
첫 번째는 이미 끝난 프로젝트, 공모전, 대외활동 등을 직접 자세하게 작성하는 방식입니다.
두 번째는 현재 진행 중인 활동을 먼저 등록하고, 날짜별 기록을 쌓아 완료 경험으로 정리하는 방식입니다.
진행형 활동에는 다음 기능을 추가했습니다.

활동 제목과 내용 수정
시작일과 예상 종료일 수정
활동 삭제
종료한 활동을 다시 진행 중 상태로 복원
활동 기간에 맞는 날짜에만 기록 작성
활동 타임라인에서 연도·월·일·요일 표시
예상 종료일 전이라도 실제로 종료하면 즉시 AI 초안 생성

이 과정에서 날짜와 상태에 관련된 여러 예외 상황도 발견했습니다.
예를 들어 과거에 종료된 활동이 오늘의 기록 목록에 나타나는 문제, 종료 버튼을 누르면 기존 예상 종료일이 의도치 않게 바뀌는 문제, 화면이 작은 경우 기록 팝업의 저장 버튼까지 스크롤할 수 없는 문제 등이 있었습니다.
이번 주에는 이러한 문제를 하나씩 수정하면서 실제 사용 흐름을 안정화했습니다.

AI 경험 분석을 STAR와 근거 중심으로 고도화

기존 AI 경험 분석은 경험 요약, 역량 태그, 주요 성과, 키워드를 보여주는 수준이었습니다.
하지만 실제 자기소개서나 면접에 활용하려면 단순한 요약만으로는 부족했습니다.
그래서 AI 경험 분석을 v2 구조로 확장했습니다.
새 분석 결과에는 다음 내용이 포함됩니다.

상황, 과제, 행동, 결과를 구분한 STAR 구조
분석 결과가 원본 경험의 어떤 문장을 근거로 했는지
기록에서 빠진 정보
자기소개서에서 활용할 수 있는 소재 방향
역량별 근거
과장해서 표현하면 안 되는 부분

AI가 기록에 없는 성과나 수치, 역할을 임의로 만들어내지 않도록 프롬프트와 응답 구조도 제한했습니다.
근거가 부족한 내용은 사실처럼 작성하는 대신 부족한 정보나 주의할 점으로 따로 보여주도록 했습니다.
이번 작업의 목적은 단순히 AI가 더 길게 답하도록 만드는 것이 아니라, 사용자가 결과를 신뢰하고 실제 지원서 작성에 활용할 수 있도록 만드는 것이었습니다.

질문과 JD를 분석하는 AI 추천 v2

AI 추천 기능도 기존의 한 개 경험 추천에서 더 구체적인 구조로 확장했습니다.
사용자가 자기소개서 문항, 면접 질문, 포트폴리오 목적, 채용공고의 JD 등을 입력하면 AI가 먼저 요구사항을 분석합니다.
그다음 저장된 경험과 AI 분석 결과를 비교해 적합한 경험을 최대 3개까지 추천합니다.
추천 결과에는 다음 정보가 포함됩니다.

입력 문항이나 JD에서 추출한 핵심 요구사항
추천 경험
경험별 적합도
해당 경험을 추천한 근거
부족한 근거
과장해서는 안 되는 부분
자기소개서나 면접에서 활용할 방향

기존에는 질문에 특정 경험을 유도하는 표현을 넣으면 원하는 경험이 추천되는 정도를 확인했습니다.
하지만 실제 서비스에서는 유도 질문이 아닌 일반적인 문항에서도 적합한 경험을 찾아야 합니다.
그래서 추천 결과가 그럴듯하게 보이는 것뿐 아니라, 실제 경험 데이터와 일치하는지를 계속 검증하고 있습니다.

500자·800자·1000자 자기소개서 초안 생성

추천된 경험을 바탕으로 답변 초안을 생성하는 기능도 추가했습니다.
사용자는 다음 형태 중 하나를 선택할 수 있습니다.

500자 자기소개서
800자 자기소개서
1000자 자기소개서
면접 답변
포트폴리오 설명

AI는 사용자가 입력한 원래 문항과 추천된 경험, 경험 분석 결과를 바탕으로 초안을 생성합니다.
초안에 사용된 근거와 부족한 정보, 과장 위험도 함께 표시합니다.
테스트 과정에서는 500자 초안을 선택했지만 실제 결과가 글자 수를 크게 벗어나는 문제도 발견했습니다.
이를 해결하기 위해 초안 유형별 최소·최대 글자 수 기준을 정하고, 결과가 범위를 벗어나면 다시 교정하도록 수정했습니다. 화면에도 실제 공백 포함 글자 수를 표시하도록 개선했습니다.

부족한 경험을 다시 보완하는 루프

경험을 분석하거나 자기소개서 초안을 만들다 보면 다음과 같은 문제가 자주 발생합니다.

 
             구체적인 성과 수치가 부족합니다.
본인이 직접 해결한 행동이 명확하지 않습니다.
팀 내에서 맡은 역할을 더 자세히 작성할 필요가 있습니다. 
            

이전에는 이런 부족한 정보를 발견해도 사용자가 원본 경험을 직접 수정한 뒤 다시 분석해야 했습니다.
이번 주에는 AI가 부족한 부분을 바탕으로 보완 질문을 생성하고, 사용자가 질문에 답한 뒤 재분석할 수 있는 기능을 구현했습니다.
예를 들어 AI가 다음과 같이 질문할 수 있습니다.

팀원 간 의견이 달랐을 때 어떤 방식으로 조율했나요?

기능 개선 전후의 사용자 반응이나 수치가 있나요?

해당 문제를 해결하기 위해 본인이 직접 수행한 행동은 무엇인가요?

사용자의 답변은 원본 경험을 자동으로 덮어쓰지 않고 별도의 보완 데이터로 저장됩니다.
사용자가 재분석을 요청하면 AI는 원본 경험과 보완 답변을 함께 사용해 새로운 분석 결과를 만듭니다.
이 기능을 통해 CampusLog는 단순히 경험을 분석해주는 서비스에서, 사용자가 자신의 경험을 더 구체적으로 떠올리고 보완하도록 돕는 서비스로 확장되었습니다.

AI API 보호와 비용 관리 기반 추가

로그인과 DB가 도입되면서 AI API도 인증된 사용자만 호출할 수 있도록 변경했습니다.
/api/analyze, /api/recommend, /api/synthesize-activity에서는 화면 접근 제한과 별개로 서버 내부에서 다시 사용자 세션을 확인합니다.
비로그인 요청은 공통 오류 형식으로 차단하고, 다음 보호 장치도 추가했습니다.

요청 데이터 크기 제한
입력 필드 길이 제한
OpenAI 응답 대기 시간 제한
사용자별 기본 호출 빈도 제한
재시도 시간 안내
API Key의 클라이언트 노출 방지

현재 적용한 호출 제한은 단일 서버 실행 환경을 기준으로 한 기본 구조입니다.
향후 실제 공개 배포 환경에서는 여러 서버 인스턴스에서도 유지되는 호출 제한과 OpenAI 비용 알림 설정이 추가로 필요합니다.

UI와 QA 작업

기능이 늘어나면서 화면의 세부적인 문제도 많이 발생했습니다.
이번 주에는 다음과 같은 UI와 버그를 수정했습니다.

빠른 기록 패널을 화면 중앙에 배치
작은 화면에서 기록 패널 내부 스크롤 지원
저장·취소 버튼 접근성 개선
활동 추가 화면을 별도 페이지 대신 확장형 패널로 제공
로그인 후 프로필과 로그아웃 메뉴 정리
AI 실행 버튼의 시각적 구분 강화
체크박스와 복사 버튼의 상태 표현 통일
추천 점수와 등급이 일치하도록 규칙 고정
보완 질문을 숨긴 뒤 다시 복원할 수 있도록 개선
다른 질문의 답변을 저장해도 작성 중인 내용이 사라지지 않도록 수정
활동 삭제 시 연결된 기록과 AI 결과의 삭제 범위 안내
완료 활동 복원 기능 추가
활동 날짜와 종료 상태 처리 개선

테스트 과정에서 발견한 문제를 ISSUE_LOG.md에 기록하고, 해결한 내용과 남은 검증 사항을 함께 관리했습니다.
코드 변경 후에는 lint, TypeScript 검사, production build 등을 반복해 기본적인 오류가 없는지도 확인했습니다.

7월 19일 멘토링: 기능은 많아졌지만 길을 잃기 시작하다

7월 19일 멘토링에서는 이번 주에 구현한 인증, DB, 오늘의 기록, AI 고도화 기능을 직접 화면으로 보여드렸습니다.
저희는 로그인과 Google 인증, Supabase 사용자별 DB 분리, STAR 기반 AI 분석, 답변 초안 기능을 구현했다고 보고했습니다.
동시에 현재 CampusLog에 기능이 예상보다 많이 추가되면서 UI와 사용자 흐름이 복잡해졌다는 고민도 말씀드렸습니다.
멘토님께서 화면을 보신 뒤 가장 먼저 확인한 것은 사용자의 전체 흐름이었습니다.

사용자가 처음 들어와서 기록하고, 분석하고, 추천받기까지 어떤 경로를 거치게 되는가?

저희가 설명한 현재 흐름은 다음과 같았습니다.

활동 등록
→ 날짜별 기록 또는 과거 경험 직접 작성
→ 활동 상세 확인
→ AI 분석
→ 부족 정보 보완
→ 재분석
→ AI 추천
→ 자기소개서 초안 생성

기능 하나하나는 연결되어 있었지만, 실제 화면에서는 상세 페이지 안으로 들어가고 다시 분석 결과 페이지로 이동하는 과정이 반복되었습니다.
저희 팀원도 중간에 현재 위치를 잃을 정도로 화면을 타고 들어가야 했고, 멘토님도 한눈에 흐름이 들어오지 않는다는 의견을 주셨습니다.

기능보다 UX 정리가 더 필요한 시점

멘토님은 현재 상태를 다음과 같이 정리해주셨습니다.

기능적으로는 어느 정도 완성되었지만, 하고 싶은 것을 계속 추가하면서 UX가 복잡해진 상태다.

지금 CampusLog의 기술적인 문제보다 더 중요한 것은, 사용자가 어떤 순서로 무엇을 해야 하는지 명확하게 보여주는 것입니다.
저희 팀은 활동 원본과 AI 분석 결과를 같은 화면에서 볼 수 있도록 좌우 Split View 형태로 구성하는 방안을 논의하고 있었습니다.
멘토님도 사용자가 페이지를 계속 타고 들어가지 않도록 다음과 같은 개선이 필요해 보인다고 말씀해주셨습니다.

왼쪽 사이드바의 카테고리와 진입 경로 활용
활동과 분석 결과를 한 화면에서 확인
중첩된 상세 페이지 이동 최소화
핵심 기능으로 바로 들어갈 수 있는 경로 제공
현재 위치를 잃지 않도록 정보 구조 단순화

단순히 “화면을 편하게 만들자”라고 접근하면 어디서부터 수정해야 할지 판단하기 어렵습니다.
멘토님은 먼저 사용자 흐름과 스토리보드를 다시 그리고, 각 단계에서 사용자가 수행해야 하는 행동 수를 줄이는 방식으로 접근하라고 조언해주셨습니다.

사용자가 어떤 행동을 해야 하는지 정리하고, 그 플로우에서 불필요한 클릭과 이동을 줄이는 방향으로 UX를 설계해야 한다.

이번 멘토링을 통해 다음 주 디자인 작업의 기준이 더 명확해졌습니다.

AI 대기 시간에는 스트리밍도 고려

AI 분석을 요청하면 사용자는 결과가 나올 때까지 기다려야 합니다.
현재는 로딩 상태만 표시되기 때문에 처리 시간이 길어질 경우 사용자가 서비스가 멈춘 것으로 느낄 수 있습니다.
멘토님은 대기 시간이 불편하게 느껴진다면, AI가 생성하고 있는 내용을 스트리밍 형태로 조금씩 보여주는 방법도 고려할 수 있다고 말씀해주셨습니다.
스트리밍이 모든 상황의 해결책은 아니지만, 사용자가 “현재 AI가 작업하고 있다”는 것을 확인할 수 있어 체감 대기 시간을 줄일 수 있습니다.
당장 반드시 구현해야 하는 기능은 아니지만, UX를 개선하는 후보로 기록해두었습니다.

캘린더와 과거 경험의 연결

현재 캘린더에는 진행 중인 활동에서 날짜별로 남긴 기록이 표시됩니다.
하지만 과거 경험을 직접 작성한 경우에는 해당 활동의 기간이 캘린더에 나타나지 않습니다.
멘토님은 사용자가 과거에 했던 활동도 시작일과 종료일을 입력하는 만큼, 캘린더나 타임라인에서 함께 확인할 수 있으면 좋겠다는 의견을 주셨습니다.
예를 들어 다음처럼 전체 대학생활을 시간순으로 볼 수 있습니다.

 
             2025년 3월~6월
학부 프로젝트

2025년 7월
공모전 참가

2026년 3월~현재
대외활동 진행

2026년 7월
UNIKER CampusLog 개발 
            

앞으로는 날짜별 기록뿐 아니라 과거 경험과 진행 중인 활동을 하나의 시간 흐름에서 볼 수 있도록 검토할 예정입니다.
또한 경험이 많아졌을 때는 날짜, 활동 유형, 역량 태그 등을 기준으로 필터링할 수 있는 탐색 기능도 필요합니다.

OCR과 JD 입력은 여전히 중요한 확장 방향

지난 멘토링에서 멘토님은 자기소개서 문항을 직접 입력하는 대신 화면을 캡처해 올리는 방식을 제안해주셨습니다.
이번 멘토링에서도 해당 기능이 아직 반영되지 않았다는 점을 확인했습니다.
현재는 사용자가 자기소개서 문항이나 JD를 텍스트로 입력해야 합니다.
하지만 실제 지원 상황에서는 다음 자료를 그대로 전달할 수 있어야 더 편리합니다.

자기소개서 문항 캡처
지원서 화면 이미지
채용공고의 JD
우대사항
이력서
포트폴리오 요구사항

이미지에서 문항을 추출하고, JD와 요구 역량을 분석해 경험을 추천할 수 있다면 사용자가 CampusLog를 훨씬 가볍게 사용할 수 있습니다.
다만 현재는 기능을 더 추가하기 전에 전체 UX를 정리해야 하는 상황이기 때문에, OCR과 이미지 입력은 텍스트 기반 추천 흐름을 안정화한 뒤 진행할 예정입니다.

지인 테스트는 어떻게 해야 할까?

이번 멘토링에서 저희가 가장 궁금했던 부분은 지인 테스트 방법이었습니다.
처음에는 주변 대학생들에게 링크를 보내고 자유롭게 사용해달라고 부탁하려고 했습니다.
하지만 CampusLog는 한 번 버튼을 누르면 바로 가치를 이해할 수 있는 단순한 서비스가 아닙니다.
사용자가 활동을 등록하고, 기록을 쌓고, AI 분석을 실행하고, 지원 문항에 맞는 경험을 추천받는 과정을 거쳐야 하기 때문에 어느 정도 학습이 필요합니다.
멘토님은 지인 테스트를 진행할 때 사용자가 원하는 흐름을 따라갈 수 있도록 가이던스가 필요하다고 말씀해주셨습니다.
가장 좋은 방법은 서비스 안에 단계별 튜토리얼을 제공하는 것입니다.
예를 들면 다음과 같습니다.

 
             1. 진행 중인 활동을 하나 등록해주세요.
오늘 한 일을 기록해주세요.
활동을 종료하고 AI 초안을 확인해주세요.
AI 분석을 실행해주세요.
자기소개서 문항을 입력하고 경험 추천을 받아보세요. 
            

다만 현재 일정에서 완성된 튜토리얼까지 만드는 것이 부담이라면, 짧은 사용 안내 영상이나 가이드 문서를 먼저 제공하는 방법도 제안해주셨습니다.
사용자 테스트 전에 다음과 같은 자료를 준비할 수 있습니다.

1~2분 사용 방법 영상
테스트 과업이 정리된 안내 문서
테스트용 계정
테스트 후 응답할 Google Form
오류 제보 양식

사람보다 먼저 합성 데이터로 추천 정확도 검증하기

이번 멘토링에서 가장 중요한 피드백 중 하나였습니다.
지인 테스트는 UI와 사용성 피드백을 받는 데 유용합니다.
하지만 CampusLog의 핵심 가치는 저장된 경험 중에서 질문에 가장 적합한 경험을 제대로 찾아주는 것입니다.
이 기능은 실제 사람에게 서비스를 보여주기 전에, 합성 데이터를 이용해 먼저 체계적으로 검증할 수 있습니다.
멘토님은 하나의 가상 사용자 페르소나를 만들고, 그 사람의 활동 경험을 10개에서 20개 정도 생성한 뒤 다양한 질문을 입력해보라고 조언해주셨습니다.
예를 들어 다음과 같은 페르소나를 만들 수 있습니다.

소프트웨어학과 3학년 대학생
프로젝트, 공모전, 학생회, 아르바이트, 봉사활동 경험 보유
백엔드 인턴 지원 준비 중

이 사용자에게 다음과 같은 경험 데이터를 넣을 수 있습니다.

팀 프로젝트에서 API 개발
공모전에서 일정 관리 실패 후 개선
학생회 행사 운영
아르바이트 중 고객 불만 대응
봉사활동에서 교육 자료 제작
동아리 내 갈등 조율
해커톤에서 MVP 완성
데이터 분석 프로젝트
발표와 팀 피드백 경험
개인 서비스 배포 경험

그다음 질문별로 어떤 경험이 추천되어야 하는지를 미리 정합니다.

 
             “팀원과 갈등을 해결한 경험”
→ 동아리 갈등 조율

“예상치 못한 문제를 해결한 경험”
→ 공모전 일정 실패 개선 또는 행사 돌발 상황 대응

“데이터를 활용해 의사결정을 내린 경험”
→ 데이터 분석 프로젝트

“빠르게 실행해 결과를 만든 경험”
→ 해커톤 MVP 완성 
            

CampusLog가 예상한 경험을 추천하는지, 추천 근거가 실제 기록에 존재하는지, 다른 경험의 내용을 섞지는 않는지를 반복해서 테스트할 수 있습니다.
대규모 정형 데이터가 필요한 작업이 아니기 때문에, AI와 함께 페르소나와 더미 경험을 만들면 비교적 빠르게 검증할 수 있다는 조언도 받았습니다.
즉, 다음 테스트 순서는 다음과 같이 정리할 수 있습니다.

합성 데이터로 추천 로직 검증
→ 팀 내부 사용자 흐름 점검
→ 지인 테스트
→ 피드백 반영
→ 최종 시연 흐름 정리

다음 주 계획

이번 주에는 기능을 많이 구현했습니다.
하지만 7월 19일 멘토링을 통해, 지금 필요한 것은 기능을 더 추가하는 것이 아니라 현재 기능을 사용자가 이해하기 쉬운 구조로 다시 정리하는 것이라는 결론을 내렸습니다.
다음 주에는 다음 작업을 중심으로 진행할 예정입니다.

1. 사용자 흐름과 스토리보드 재정리

현재의 전체 흐름을 다시 그린 뒤, 각 단계에서 필요한 클릭과 페이지 이동을 줄일 예정입니다.
특히 다음 부분을 중점적으로 보려고 합니다.

활동 원본과 AI 분석 결과를 Split View로 함께 보기
사이드바를 활용한 직접 진입 경로
분석과 보완 답변을 한 화면에서 처리
사용자가 현재 위치를 잃지 않는 구조
중복되거나 우선순위가 낮은 기능 제거

2. 합성 데이터 기반 추천 로직 테스트

가상 사용자 페르소나와 10~20개의 경험 데이터를 만들 예정입니다.
질문별 기대 추천 결과를 미리 정의한 뒤 다음 항목을 검증하려고 합니다.

추천 경험 적합성
추천 근거의 원본 일치 여부
누락된 근거 표시
과장 위험 안내
경험 간 내용 혼합 여부
Top 3 추천 순서

3. 지인 테스트 준비

UI 대공사와 기본 추천 테스트가 끝나면 주변 대학생을 대상으로 지인 테스트를 진행하려고 합니다.
자유롭게 사용해보라고 요청하기보다, 사용 안내 영상과 과업을 제공하는 방식으로 준비할 예정입니다.
테스트에서는 다음 항목을 확인하려고 합니다.

서비스 목적을 이해하는가
첫 활동을 어렵지 않게 등록할 수 있는가
날짜별 기록 방식이 부담스럽지 않은가
AI 분석 결과가 자신의 경험과 일치하는가
추천된 경험을 납득할 수 있는가
자기소개서나 면접에 실제로 활용하고 싶은가
다시 사용할 의향이 있는가

4. OCR·JD 이미지 입력 검토

텍스트 기반 추천 흐름과 UX가 안정된 뒤, 자기소개서 문항 캡처와 JD 이미지 입력을 추가하는 방향을 검토할 예정입니다.

마무리

이번 주는 CampusLog의 개발 규모가 가장 크게 확장된 시기였습니다.
기존 localStorage 기반 MVP에서 벗어나 로그인, Google OAuth, 사용자별 Supabase DB, RLS를 적용했습니다.
진행 중인 활동을 매일 기록하고 캘린더에서 확인한 뒤, 활동 종료 시 AI가 완료 경험을 정리하는 흐름도 만들었습니다.

AI 경험 분석은 STAR와 원본 근거 중심으로 확장했고, 추천 기능은 문항과 JD의 요구사항을 분석해 경험 Top 3를 제안하도록 고도화했습니다. 답변 초안과 부족한 경험을 다시 보완하는 기능도 추가했습니다.
기술적으로는 많은 부분이 완성되었습니다.

하지만 이번 멘토링을 통해 기능을 많이 구현하는 것과 사용하기 좋은 프로덕트를 만드는 것은 다른 문제라는 점을 다시 느꼈습니다.
기능이 추가될수록 화면과 흐름도 복잡해졌고, 사용자가 어디서 무엇을 해야 하는지 명확하게 안내하지 않으면 오히려 서비스의 가치가 가려질 수 있었습니다.
앞으로는 새로운 기능을 계속 추가하기보다, 사용자 흐름을 다시 설계하고 합성 데이터로 핵심 추천 로직을 검증한 뒤 실제 사용자 테스트로 넘어가려고 합니다.
CampusLog의 목표는 단순히 많은 기능을 가진 서비스가 아닙니다.

대학생이 자신의 경험을 부담 없이 기록하고, 필요한 순간에 가장 적합한 경험을 다시 꺼내 쓸 수 있도록 돕는 서비스

다음 주에는 이 목표가 더 분명하게 보이는 화면과 사용자 흐름으로 CampusLog를 다시 정리해보겠습니다.

경제금융용어 공부 566 : 총수익스왑(TRS, Total Return Swap)

MKISOS — Mon, 20 Jul 2026 21:00:25 +0900

총수익스왑(TRS, Total Return Swap)

금융기관들은 자산을 직접 사고팔지 않고도 해당 자산의 수익을 얻거나 위험을 다른 사람에게 넘기는 거래를 한다. 이러한 대표적인 파생상품이 바로 총수익스왑(TRS)이다. TRS는 채권이나 주식 같은 자산에서 발생하는 모든 수익과 위험을 다른 거래 상대방에게 이전하는 계약으로, 기관투자자와 금융회사에서 널리 활용되는 금융기법이다.

1. 한 줄 정의

총수익스왑(TRS)은 특정 자산에서 발생하는 모든 수익과 손실을 상대방에게 이전하고, 그 대가로 일정한 이자를 받는 파생상품 거래이다.

2. 기본 개념

총수익스왑(TRS, Total Return Swap)은 특정 자산을 실제로 매매하지 않고도 그 자산에서 발생하는 모든 경제적 성과를 서로 교환하는 계약이다.

여기서 총수익(Total Return) 이란 다음 두 가지를 모두 포함한다.

이자나 배당 등 정기적으로 발생하는 수익
자산 가격 상승 또는 하락에 따른 자본이득 및 손실

예를 들어 채권을 기초자산으로 하는 TRS에서는 채권에서 발생하는 이자뿐 아니라 채권 가격이 오르거나 내리는 손익까지 모두 거래 상대방에게 이전된다.

대신 자산의 총수익을 넘겨받은 상대방은 일정한 약정금리를 지급한다.

즉 자산은 그대로 보유하면서도 해당 자산의 수익과 위험만 교환하는 계약이라고 이해하면 된다.

3. 왜 중요한가

금융기관은 보유한 자산을 직접 팔지 않고도 위험을 줄이거나 자금을 효율적으로 운용하고 싶을 때가 많다.

TRS를 이용하면 자산의 소유권은 유지하면서도 시장위험과 수익을 다른 투자자에게 이전할 수 있다.

반대로 자산을 직접 매입하지 않고도 해당 자산의 수익을 얻고 싶은 투자자도 TRS를 활용할 수 있다.

이처럼 TRS는 자금 효율성을 높이고 다양한 투자 전략을 가능하게 하는 금융기법이다.

4. 쉽게 이해하는 예시

실생활 예시

친구가 아파트를 가지고 있는데 앞으로 집값이 오를지 내릴지 걱정된다고 가정해보자.

다른 친구가 "집값이 오르면 내가 이익을 가져가고, 대신 매년 일정한 돈을 줄게."라고 계약한다.

집의 소유권은 그대로지만 집값 변동에 따른 수익과 손실은 다른 사람이 가져가는 것이다.

TRS도 이와 비슷한 원리이다.

투자 예시

A은행이 100억 원 규모의 채권을 보유하고 있다고 가정해보자.

A은행은 채권은 계속 보유하지만 채권의 이자와 가격 변동에 따른 손익을 투자자 B에게 넘긴다.

대신 B는 일정한 이자를 A은행에 지급한다.

이것이 TRS 거래이다.

금융시장 예시

헤지펀드는 실제 주식을 대량으로 매입하지 않고도 TRS를 이용해 해당 주식의 수익률만 확보하는 전략을 사용하기도 한다.

5. 핵심 특징

5-1. 자산을 직접 매매하지 않는다

TRS는 자산의 소유권을 이전하지 않는다.

수익과 위험만 계약을 통해 교환한다.

5-2. 수익과 손실을 모두 이전한다

이자나 배당뿐 아니라 자산 가격 상승에 따른 이익과 하락에 따른 손실도 함께 이전된다.

즉 총수익 전체를 교환하는 계약이다.

5-3. 다양한 위험을 이전할 수 있다

TRS는 신용위험뿐 아니라 금리, 주가, 환율 등 시장위험까지 함께 이전할 수 있다.

그래서 위험관리 수단으로도 활용된다.

6. 관련 개념과의 차이

총수익스왑(TRS) vs 신용부도스왑(CDS)

총수익스왑(TRS)

이자와 자본손익 모두 이전
신용위험과 시장위험 모두 이전
자산 전체의 경제적 성과를 교환

신용부도스왑(CDS)

신용위험만 이전
채무불이행 위험에 대한 보험 역할
시장가격 변동은 포함하지 않음

즉 TRS는 자산의 모든 수익과 위험을 이전하고, CDS는 부도 위험만 이전한다.

총수익스왑(TRS) vs 일반 스왑

총수익스왑(TRS)

자산의 총수익을 교환
기초자산 가격 변동까지 포함

일반 금리스왑(IRS)

금리만 교환
자산 가격 변동은 포함하지 않음

TRS는 일반 스왑보다 교환 대상이 훨씬 넓다.

7. 경제적 의미

국가경제 관점

TRS는 금융시장에서 위험을 효율적으로 분산시키는 기능을 수행한다.

다만 과도한 레버리지와 복잡한 거래는 금융시스템 위험을 확대할 수도 있다.

기업 관점

금융기관은 보유 자산을 매각하지 않고도 위험을 이전하거나 자금 운용 효율을 높일 수 있다.

금융시장 관점

TRS는 기관투자자와 헤지펀드가 자산을 효율적으로 운용하는 대표적인 파생상품이다.

시장 유동성을 높이는 긍정적인 역할도 하지만 거래 구조가 복잡해 위험 관리가 중요하다.

투자 관점

개인투자자가 직접 활용하는 경우는 드물지만, 대형 금융기관과 헤지펀드의 투자 전략을 이해하기 위해 알아둘 필요가 있다.

특히 글로벌 금융위기 이후 TRS와 같은 파생상품의 위험성에 대한 관리가 더욱 중요해졌다.

8. 정리

총수익스왑(TRS)은 특정 자산에서 발생하는 이자, 배당, 가격 변동에 따른 손익 등 모든 경제적 성과를 거래 상대방과 교환하는 파생상품이다. 자산을 직접 매매하지 않고도 수익과 위험을 이전할 수 있기 때문에 금융기관과 기관투자자가 자주 활용한다. 또한 신용위험뿐 아니라 금리, 환율, 주가 변동 등 시장위험까지 함께 이전할 수 있다는 점에서 신용부도스왑(CDS)과 구별된다. TRS는 금융시장의 자산 운용과 위험관리에서 중요한 역할을 하는 대표적인 파생상품이다.

[주간회GO 26년 7월 3주차] D-44, 4일 미치게 일하고 3일 놀고

MKISOS — Sun, 19 Jul 2026 23:10:55 +0900

[주간회GO 26년 7월 3주차]

26년 7월 3주차

저번주는 주말까지 내내 바빴다.
이번주에는 목요일에 본가에 가기때문에 가서 조금이라도 쉬려면 미리 해두어야한다.
그래서 저번주 미리한다고 바빴는데 이번주도 월화수 진짜 죽도록 할 예정이다.
그래야지 진짜 좀 쉴 때 쉴 수 있을 것 같다.

진짜 벌려놓은 일이 많으니 해야하는 일들과 마감기한 지켰는지 등등 자가 체크할게 너무 많아서 뭐 하나 놓칠까봐 불안하다.
매일 매시간 매초 체크하고 기록하고 하는데 지금보다 좀 더 나의 시간을 온전히 관리할 수 있는 시스템을 갖추어야겠다고 느낀다.

이번주도 힘내자
다들 각자의 이유로 바쁘고 힘들게 살아간다.

26년 7월 13일 월요일

5시 기상해서 또 건우랑 회의했다

운동하면서 개발회의해서 실리콘밸리 개발자 느낌 ㄷ

월요일 운동완료~
월요일 운동 안하면 일주일이 찝찝해지는거 아시나요
하루, 한 주가 달라지는 걸 느꼈음. 내 기분이 그럼

오전 화분 물 듬뿍주고
난 점심에 두부랑 닭찌찌먹었다.
두부 닭가슴 계란 이걸로 돈아끼고 몸챙기고 굳임

산업통상부 탈락
코스피 떡락

나도 오늘부터 이번주 일 폭탄일 것 같다…
개발이랑 할게 많은데 비상이네

벌써 500일 넘게 매일 읽는중 ㄷㄷ

퇴근 후 블루베리 먹으면서 책 읽기
랭플릭스도~

26년 7월 14일 화요일

눈뜨면 자다깨면 개발이야기하고
운동가고 운동하면서도 개발야기하고
운동 끝나고도 쉐이크 먹고 출근 준비하면서도 회의했다.

좀만 더 버티자 곧 연휴니까

오늘의 점심 미리 에어프라이기 돌리고 출근하기

매번 초기화 하는게 일상 ㅋㅋㅋㅋㅋ
초기화권 어떤 기준으로 주는 건지 아직 모르겠다.

일하고 겨우 밥 먹으로 왔다
하…
진짜 할 게 많은데 일이 너무 많고 퇴근 후에도 안쉬고 하는데 진짜 시간이 너무 부족하네… 스트레스 폭탄이다 요즘
쉬기 전 대가를 치르는 거 겠지

점심시간에도 짬내서 강의 들었다.

오후에는
미친듯이 일만 함 ㅜㅜ

진짜 요즘 하루를 마무리할때 뭔가 힘들어서 눈물나면서도
또 열심히 사는 나 보면 뿌듯해서 행복하면서도
이러다가 바로 뻗어버리고
다음날 또 무슨 일 있어냐는 듯 운동가고 똑같이 하루를 살고…
이거 맞나?

근데 또 몸이 안아픈게 어디야
진짜 아파서 못하면 너무 서러운데 지금 건강한거에 감사하자.

26년 7월 15일 수요일

아침에 구청에 재진이형 데리고 운동 같이갔다.
재진이형 첫 방문

오전에 바로 엄청나게 옮기고

밥 먹고와서 간식까지 받았다

그리고 책을 좀 읽을까했는데

바로 출장다녀왔다
진짜 더워죽을뻔

다녀오니 간식이 쌓여있었다.
책 좀 읽으면서 땀식히고 오후 우편업무 다녀와서
바로 발대식 참여했다.

음 나 너무 바쁜데 이거 잘 해낼 수 있을까
과거의 나 만나면 ㄹㅇ 한소리 하고 싶네
근데 다 이겨내고 9월을 맞이하면 과거의 나를 칭찬하겠지?
칭찬할 수 있게 지금의 나가 열심히 해야지

끝나고 강의 또 들음
진짜 오늘 눈 빠진다

오랜만에 휴식…

26년 7월 16일 목요일

오운완하고 서울 가는데
3명만 태우고 공항가서 25명태운다길래 오 그렇구나 했는데
공항에서 갑자기 중국인 여자만 25명 타는데 자기들끼리 갑자기 자리 다 아무데나 앉아서 난리였다.

산동제 처음 넣어보았다.
수술 예약하고 피 같은 내 돈으로 예약금 넣었다 나중에 한 두 달 월급 벌지 뭐

버스 기다리면서 동생이랑 푸파 ㄷㄷ
그리고 같이 대구로~
오늘 졸라 많이 몰아서 먹어버림

와 진짜 서울 대구 4시간 넘게 걸렸음;;;
꼬리뼈부러짐

26년 7월 17일 금요일

대구와서도 오운완

할머니 아프셔서 내과가서 영양제 맞을동안 기다렸다.
기다리면서 시간을 어떻게 보내지하다가 전자책으로 한빛 책 읽었다.

고기먹고 카공출발
건우가 지각했음
근데 망빙 샀음
야호

명호의 홀 오픈식 전통주도 3병 서비스 ㄷㄷ
내기 볼링
내기 농구
골프까지 첫경험 ㄷㄷ
너무 재밌는 하루
골프는 자주 치고 싶다.

26년 7월 18, 19일 토,일요일 주말

수성못 어화도 최고의 메뉴선정
나 혼자 다 먹은 듯

바로 같은 건물 올라가서 디저트도 ㅎㅎ

이모집가서 인공눈물니랑 한우 받아왔다 낼 먹어야지

다녀와서 저녁 먹기전에 운동 다녀왔다.

아침에 축구보다가 전반 4대떡보고 운동다녀옴
곧 대구를 떠나야해 벌써..

투플9한우 먹고 돼지고기도 먹고 밥도 볶아먹고
진짜 식폭행당했다~

갈비에 간장게장에
하루에 5천칼로리씩 먹음 ㄷㄷ
과자랑 아이스크림 빵도 실컷 먹었다.

죄책감에 바로 튀어다녀옴

경제금융용어 공부 565 : 총산출

MKISOS — Sun, 19 Jul 2026 21:00:22 +0900

총산출

경제 뉴스에서 "국내 생산이 증가했다", "산업 생산이 감소했다"는 표현을 자주 볼 수 있다. 이때 경제 전체에서 얼마나 많은 재화와 서비스가 생산되었는지를 나타내는 개념이 바로 총산출이다. 총산출은 한 나라의 생산 규모를 측정하는 가장 기본적인 지표이지만, 중간재까지 모두 포함하기 때문에 국내총생산(GDP)과는 다른 개념이다.

1. 한 줄 정의

총산출은 일정 기간 동안 경제에서 생산된 모든 재화와 서비스의 가치를 합한 금액이다.

2. 기본 개념

총산출(Gross Output)은 일정 기간 동안 생산된 모든 재화와 서비스의 가치를 합한 것을 의미한다.

여기에는 시장에서 판매된 상품뿐 아니라 재고로 남은 제품이나 생산자가 직접 소비한 생산물도 포함된다.

산업에서는 생산한 모든 재화와 서비스의 가치를 합산하며, 서비스업은 서비스 제공으로 받은 수수료나 요금을 기준으로 계산한다.

다만 업종마다 생산 방식이 다르기 때문에 총산출을 계산하는 방법도 조금씩 달라진다.

예를 들어 도소매업은 상품을 사고파는 과정에서 발생한 거래마진을 총산출로 계산하고, 금융업은 금융서비스를 제공하면서 얻은 수수료와 금융중개서비스를 기준으로 총산출을 산정한다.

3. 왜 중요한가

총산출은 경제에서 실제로 얼마나 많은 생산 활동이 이루어졌는지를 보여주는 지표이다.

기업의 생산이 증가하면 총산출도 증가하고, 이는 경기 회복이나 경제성장의 신호로 해석될 수 있다.

또한 산업별 생산 규모를 비교하거나 경제 구조를 분석할 때도 총산출이 활용된다.

다만 총산출에는 중간재가 여러 번 포함되기 때문에 국가의 최종 생산 규모를 나타내는 GDP와는 구분해서 이해해야 한다.

4. 쉽게 이해하는 예시

실생활 예시

빵 한 개가 만들어지는 과정을 생각해보자.

밀 농가가 밀을 생산한다.
제분업체가 밀을 밀가루로 만든다.
제빵업체가 밀가루로 빵을 만든다.

총산출은 밀, 밀가루, 빵의 생산가치를 모두 더한다.

따라서 같은 가치가 여러 번 포함될 수 있다.

기업 예시

자동차 한 대를 생산하기 위해 철강회사, 부품회사, 타이어회사, 자동차회사가 모두 생산 활동을 한다.

총산출은 각 기업의 생산가치를 모두 합산한다.

경제 예시

한 해 동안 우리나라에서 생산된 스마트폰, 자동차, 음식, 의료서비스, 금융서비스 등을 모두 합한 것이 총산출의 개념이다.

5. 핵심 특징

5-1. 모든 생산을 포함한다

총산출은 최종재뿐 아니라 생산 과정에서 사용되는 중간재도 모두 포함한다.

그래서 실제 생산 규모를 폭넓게 보여준다.

5-2. 산업마다 계산 방식이 다르다

제조업은 생산된 제품의 가치로 계산하지만, 도소매업은 거래마진, 금융업은 금융서비스 수수료 등을 기준으로 총산출을 계산한다.

5-3. GDP보다 규모가 크다

중간재가 여러 번 포함되므로 총산출은 일반적으로 GDP보다 훨씬 큰 규모를 가진다.

6. 관련 개념과의 차이

총산출 vs GDP(국내총생산)

총산출

모든 생산가치 합산
중간재 포함
생산 규모 측정

GDP

최종재와 서비스만 포함
중복 계산 제거
국가 경제 규모 측정

즉 총산출은 생산의 전체 규모를, GDP는 최종 생산 가치를 나타낸다.

총산출 vs 부가가치

총산출

생산된 재화와 서비스의 전체 가치

부가가치

총산출에서 중간투입 비용을 제외한 가치

부가가치를 모두 합하면 GDP가 된다.

7. 경제적 의미

국가경제 관점

총산출은 경제활동이 얼마나 활발하게 이루어지고 있는지를 보여주는 대표적인 생산 지표이다.

산업별 성장과 경제 구조를 분석하는 데 중요한 자료로 활용된다.

기업 관점

기업의 총산출이 증가한다는 것은 생산 규모가 확대되고 있다는 의미이다.

다만 생산 증가가 반드시 이익 증가를 의미하는 것은 아니다.

금융시장 관점

총산출 증가는 경기 회복과 기업 실적 개선에 대한 기대를 높일 수 있다.

반대로 총산출 감소는 경기 둔화 신호로 해석되기도 한다.

투자 관점

투자자는 총산출 증가율을 통해 산업의 성장성을 판단할 수 있다.

특히 제조업과 서비스업의 생산 동향을 분석할 때 중요한 참고자료가 된다.

8. 정리

총산출은 일정 기간 동안 경제에서 생산된 모든 재화와 서비스의 가치를 합한 생산 지표이다. 최종재뿐 아니라 중간재와 재고품까지 포함하기 때문에 경제 전체의 생산 규모를 폭넓게 보여준다. 다만 중간재가 중복 계산되므로 GDP와는 다른 개념이며, 부가가치를 모두 합한 GDP보다 일반적으로 더 큰 규모를 가진다. 총산출은 산업별 생산 활동과 경기 흐름을 분석하는 데 중요한 경제지표로 활용된다.

경제금융용어 공부 564 : 총부채원리금상환비율(DSR)

MKISOS — Sat, 18 Jul 2026 21:00:27 +0900

총부채원리금상환비율(DSR)

집을 사거나 대출을 받을 때 가장 많이 듣는 용어 중 하나가 DSR이다. 최근에는 "DSR 규제 때문에 대출 한도가 줄었다"는 뉴스를 자주 볼 수 있다. DSR은 단순히 집값이나 담보가치를 보는 것이 아니라, 대출을 받는 사람이 실제로 빚을 갚을 능력이 있는지를 가장 엄격하게 평가하는 기준이다. 현재 우리나라 가계대출 심사에서 가장 중요한 규제 가운데 하나로 활용되고 있다.

1. 한 줄 정의

총부채원리금상환비율(DSR)은 모든 대출의 연간 원리금 상환액이 연소득에서 차지하는 비율을 나타내는 지표이다.

2. 기본 개념

DSR(Debt Service Ratio)은 대출을 신청한 사람이 보유한 모든 대출의 연간 원리금 상환액을 연소득으로 나누어 계산하는 비율이다.

계산식은 다음과 같다.

DSR = 모든 대출의 연간 원리금 상환액 ÷ 연소득 × 100

여기서 모든 대출에는 다음과 같은 부채가 포함된다.

주택담보대출
신용대출
마이너스통장
전세자금대출
자동차 할부금융
기타 금융권 대출

즉 DSR은 한 사람이 실제로 부담하고 있는 전체 부채를 종합적으로 평가하는 지표이다.

3. 왜 중요한가

과거에는 주택담보대출만 중심으로 대출 심사가 이루어지는 경우가 많았다.

하지만 실제로는 신용대출이나 자동차 할부 등 다양한 부채를 함께 가지고 있는 사람이 많다.

이러한 상황에서 주택담보대출만 고려하면 실제 상환 부담을 정확하게 파악하기 어렵다.

DSR은 모든 대출을 함께 계산하기 때문에 차주의 상환 능력을 가장 현실적으로 평가할 수 있다.

정부도 가계부채 증가를 억제하고 금융시스템의 건전성을 높이기 위해 DSR 규제를 적극 활용하고 있다.

4. 쉽게 이해하는 예시

실생활 예시

연봉이 6,000만 원인 사람이 있다고 가정해보자.

현재 매년 다음과 같은 대출을 갚고 있다.

주택담보대출 원리금 : 1,500만 원
신용대출 원리금 : 500만 원
자동차 할부금 : 400만 원

총 원리금 상환액은 2,400만 원이다.

따라서 DSR은 40%가 된다.

즉 연소득의 40%를 모든 대출 상환에 사용하고 있다는 의미이다.

대학생 예시

취업 후 연봉이 4,000만 원인 사회초년생이 학자금대출과 자동차 할부, 신용대출을 함께 보유하고 있다면 은행은 이 모든 대출을 합산하여 DSR을 계산한다.

부동산 예시

같은 소득을 가진 두 사람이 있다고 하더라도 기존 신용대출이 많은 사람은 DSR이 높아져 추가 주택담보대출 한도가 줄어들 수 있다.

5. 핵심 특징

5-1. 모든 대출을 반영한다

주택담보대출뿐 아니라 신용대출, 마이너스통장, 전세자금대출 등 모든 금융부채를 함께 계산한다.

그래서 가장 포괄적인 대출 규제라고 불린다.

5-2. 상환 능력을 현실적으로 평가한다

단순히 담보가치가 아니라 실제 소득 대비 상환 부담을 판단한다.

무리한 대출을 예방하는 효과가 있다.

5-3. 가계부채 관리의 핵심 수단이다

현재 정부와 금융당국은 DSR을 활용하여 가계부채 증가 속도를 조절하고 있다.

부동산 시장 안정 정책에서도 매우 중요한 역할을 한다.

6. 관련 개념과의 차이

DSR vs DTI

DSR

모든 대출의 원리금 반영
가장 엄격한 상환능력 평가

DTI

주택담보대출 원리금
기타 대출은 이자만 반영

즉 DSR이 DTI보다 더 넓은 범위의 부채를 평가한다.

DSR vs LTV

DSR

소득 기준 규제
상환 능력 중심

LTV

담보가치 기준 규제
주택 가격 중심

LTV는 집을 보고, DSR은 사람의 소득과 부채를 본다고 이해하면 쉽다.

7. 경제적 의미

국가경제 관점

DSR은 과도한 가계부채 증가를 억제하고 금융시스템의 안정성을 높이는 핵심 거시건전성 정책이다.

경제위기 시 금융기관의 부실 위험을 줄이는 데에도 중요한 역할을 한다.

기업 관점

은행은 DSR을 활용하여 대출 심사의 건전성을 높이고 부실채권 발생 가능성을 줄일 수 있다.

금융시장 관점

DSR 규제가 강화되면 대출 증가 속도가 둔화되고 부동산 시장 과열을 억제하는 효과를 기대할 수 있다.

반대로 규제가 완화되면 자금 조달이 쉬워져 시장이 활성화될 가능성이 있다.

투자 관점

부동산 투자자는 DSR 규제 수준을 반드시 확인해야 한다.

DSR이 강화되면 대출 한도가 감소해 투자 수요가 줄어들 수 있으며, 완화되면 시장의 유동성이 확대될 가능성이 있다.

8. 정리

총부채원리금상환비율(DSR)은 모든 대출의 연간 원리금 상환액을 연소득으로 나누어 계산하는 대표적인 대출 규제 지표이다. 주택담보대출뿐 아니라 신용대출, 마이너스통장, 자동차 할부 등 모든 금융부채를 반영하기 때문에 차주의 실제 상환 능력을 가장 현실적으로 평가할 수 있다. 현재 DSR은 가계부채 관리와 부동산 시장 안정화를 위한 핵심 금융 규제로 활용되고 있으며, 대출 한도를 결정하는 가장 중요한 기준 가운데 하나이다.

경제금융용어 공부 563 : 총부채상환비율(DTI)

MKISOS — Fri, 17 Jul 2026 21:00:44 +0900

총부채상환비율(DTI)

집을 구매하기 위해 주택담보대출을 받을 때 가장 많이 듣는 용어가 LTV와 DTI이다. 많은 사람들이 집값만 보고 대출 한도가 결정된다고 생각하지만, 실제로는 소득도 매우 중요한 기준이 된다. 총부채상환비율(DTI)은 대출을 받은 사람이 소득으로 빚을 얼마나 감당할 수 있는지를 판단하는 대표적인 금융 규제이다.

1. 한 줄 정의

총부채상환비율(DTI)은 연소득 대비 주택담보대출 원리금과 기타 대출 이자 부담이 어느 정도인지를 나타내는 비율이다.

2. 기본 개념

DTI(Debt To Income Ratio)는 대출을 신청한 사람의 소득을 기준으로 대출 가능 금액을 결정하는 규제이다.

쉽게 말하면 "이 사람의 소득으로 대출을 무리 없이 갚을 수 있는가?"를 판단하는 기준이다.

DTI는 다음과 같은 방식으로 계산된다.

DTI = (주택담보대출의 연간 원리금 상환액 + 기타 대출의 연간 이자 상환액) ÷ 연소득 × 100

예를 들어 연소득이 6,000만 원인 사람이 1년에 주택담보대출 원리금 2,000만 원과 다른 대출 이자 400만 원을 갚는다면 DTI는 40%가 된다.

즉 연소득의 40%를 대출 상환에 사용하고 있다는 의미이다.

3. 왜 중요한가

과거에는 집값을 기준으로만 대출을 받을 수 있는 경우가 많았다.

하지만 소득이 충분하지 않은 사람이 과도한 대출을 받으면 상환 부담이 커지고 가계부채가 급격히 증가할 수 있다.

DTI는 이러한 문제를 예방하기 위해 도입되었다.

즉 단순히 담보가치뿐 아니라 실제 상환 능력까지 함께 고려하여 대출을 제한하는 제도이다.

4. 쉽게 이해하는 예시

실생활 예시

연봉이 4,000만 원인 사람이 매년 3,000만 원씩 대출을 갚아야 한다면 생활비를 마련하기 어려울 것이다.

은행은 이러한 상황을 방지하기 위해 DTI를 확인한다.

대학생 예시

아르바이트로 연 2,000만 원을 버는 사람이 매년 1,500만 원씩 대출을 상환해야 한다면 매우 부담스러울 것이다.

은행은 소득 대비 상환 부담이 지나치게 높은 경우 대출 한도를 줄인다.

부동산 예시

같은 8억 원짜리 아파트를 구입하려는 두 사람이 있다고 가정해보자.

한 사람은 연봉이 1억 원이고, 다른 사람은 연봉이 4,000만 원이다.

집값은 같지만 소득이 더 높은 사람의 DTI가 낮게 계산되므로 일반적으로 더 많은 대출을 받을 수 있다.

5. 핵심 특징

5-1. 소득을 기준으로 대출 가능 금액을 결정한다

DTI는 집값보다 대출 신청자의 상환 능력에 초점을 맞춘다.

소득이 높을수록 같은 조건에서도 더 많은 대출을 받을 가능성이 있다.

5-2. 가계부채 증가를 억제한다

과도한 대출을 제한하여 금융기관의 부실과 가계부채 증가를 예방하는 역할을 한다.

5-3. 부동산 시장 안정 정책으로 활용된다

정부는 부동산 시장이 과열될 경우 DTI 규제를 강화하여 대출 규모를 줄이고 주택시장 과열을 억제하기도 한다.

6. 관련 개념과의 차이

DTI vs LTV

DTI(총부채상환비율)

소득 기준 규제
상환 능력을 평가
연소득이 중요

LTV(담보인정비율)

집값 기준 규제
담보가치를 평가
주택 가격이 중요

즉 DTI는 사람을 보고, LTV는 집을 본다고 이해하면 쉽다.

DTI vs DSR

DTI

주택담보대출 원리금
기타 대출은 이자만 반영

DSR(총부채원리금상환비율)

모든 대출의 원리금을 반영
더욱 엄격한 규제

현재는 DSR이 대출 심사의 핵심 기준으로 활용되는 경우가 많다.

7. 경제적 의미

국가경제 관점

DTI는 가계부채 증가를 억제하고 금융시스템의 안정성을 높이는 중요한 거시건전성 정책이다.

기업 관점

부동산 시장이 안정되면 금융기관의 부실 위험도 함께 감소할 수 있다.

은행은 DTI를 활용해 대출 건전성을 관리한다.

금융시장 관점

DTI 규제가 강화되면 주택담보대출 증가 속도가 둔화될 수 있다.

반대로 규제가 완화되면 대출이 늘어나면서 부동산 시장이 활성화될 가능성이 있다.

투자 관점

부동산 투자자는 정부의 DTI 규제 변화를 반드시 확인해야 한다.

DTI 규제가 강화되면 대출 한도가 줄어들어 주택 수요가 감소할 수 있고, 완화되면 시장이 다시 활기를 띨 가능성이 있다.

8. 정리

총부채상환비율(DTI)은 연소득 대비 주택담보대출 원리금과 기타 대출 이자 부담이 차지하는 비율을 의미한다. 이는 대출 신청자의 실제 상환 능력을 평가하기 위해 도입된 대표적인 금융 규제이다. DTI는 LTV와 함께 가계부채 증가를 억제하고 부동산 시장 과열을 방지하는 중요한 거시건전성 정책으로 활용된다. 최근에는 모든 대출의 원리금을 반영하는 DSR이 더욱 중요한 규제로 자리 잡고 있지만, DTI 역시 주택담보대출 제도를 이해하기 위해 반드시 알아야 할 핵심 개념이다.

[UNIKER] 3회차 라이브 강의 정리 ㅡ AI 서비스와 API 연결, Codex exec로 MVP의 AI 기능을 검증하는 법

MKISOS — Fri, 17 Jul 2026 13:59:10 +0900

이번 UNIKER 1기 세 번째 라이브 강의에서는 ‘AI 서비스와 API 연결’을 주제로, 사용자의 입력이 실제 AI 결과로 이어지는 서비스 구조를 배웠다.

지난 강의까지는 사용자 흐름과 핵심 화면을 정의하고, Codex를 활용해 작동하는 프로토타입을 만드는 데 집중했다. 이번 강의에서는 한 단계 더 나아가 AI 기능을 실제 서비스 안에서 어떻게 연결하고 검증할 것인가를 다뤘다.

강의에서 1회차의 PRD·사용자 문제·핵심 기능, 2회차의 화면·API 계약·Mock 데이터·검증에 이어, 이번 3회차를 AI 기능 정의, AI API 연결, 로컬 Codex exec 데모로 연결하고 있었다.

강의에 앞서 살펴본 최근 Codex 업데이트

이번 강의는 본격적인 API 설명에 앞서, 최근 ChatGPT와 Codex에 추가된 업데이트를 살펴보는 것으로 시작했다.

AI 도구는 한 달 단위도 아니라 한 주 사이에도 기능과 사용 방식이 달라질 만큼 빠르게 발전하고 있다. 강사님께서는 이러한 변화를 강의자료에도 계속 반영하고 있었고, 별도로 제작한 Codex 활용 가이드에도 최신 내용을 추가했다고 설명해 주셨다.

특히 인상 깊었던 업데이트는 Codex가 별도의 개발 도구로만 존재하는 것이 아니라, ChatGPT 데스크톱 앱 안에서 더 자연스럽게 연결되는 방향으로 발전하고 있다는 점이었다.

강의자료에서는 다음과 같은 변화가 소개됐다.

ChatGPT 데스크톱 앱 안에서 Codex 사용
Markdown과 코드 바로 편집
선택한 부분에 주석을 남겨 수정 요청
GitHub Pull Request 차이와 리뷰 피드백 확인
여러 저장소를 하나의 프로젝트에서 관리
작업 상태와 진행 과정 표시 개선

이전에는 AI에게 코드를 생성해 달라고 요청하고 결과를 복사하는 느낌이 강했다면, 이제는 프로젝트와 파일, GitHub 협업 흐름 전체가 하나의 작업 환경 안으로 들어오고 있었다.

내가 CampusLog를 개발하며 사용했던 방식도 이러한 변화와 연결된다. 단순히 코드를 만들어 달라고 요청한 것이 아니라 Codex가 프로젝트 문서를 읽고 브랜치를 만든 뒤 코드를 수정하고, 테스트와 커밋, Push, Pull Request까지 이어서 처리하도록 사용하고 있기 때문이다.

AI 에이전트는 점점 ‘코드를 알려주는 도구’보다 개발 업무의 일부를 실제로 수행하는 작업자에 가까워지고 있다는 생각이 들었다.

작업에 맞는 모델을 선택하는 세 가지 기준

이번 강의에서 기억에 남은 내용 중 하나는 모델 선택 기준이었다.

Sol, Terra, Luna. 강의에서는 모델을 무조건 가장 강력한 것으로 선택하는 것이 아니라 작업 난이도와 비용, 기다릴 수 있는 시간에 따라 구분해야 한다고 설명했다.

Sol — 가장 어려운 문제

Sol은 복잡한 코딩, 컴퓨터 사용, 연구, 보안처럼 속도보다 정확도가 중요한 작업에 적합하다.

예를 들면 다음과 같다.

원인을 알기 어려운 복잡한 버그
여러 파일에 영향을 주는 리팩터링
UI를 포함한 최종 검증
보안이나 데이터 마이그레이션
처음 보는 대규모 코드베이스 분석

CampusLog에 적용한다면 AI 추천 결과가 실제 경험과 무관한 내용을 생성하는 문제처럼, 여러 파일과 로직을 함께 추적해야 하는 작업에 적합하다.

Terra — 일상적인 개발의 기본값

Terra는 품질과 속도의 균형을 맞춘 모델이다.

일반적인 기능 개발, 테스트 작성, 일상적인 버그 수정처럼 대부분의 개발 작업에 사용할 수 있다.

CampusLog에서는 다음과 같은 작업이 여기에 해당한다.

경험 CRUD 기능 수정
입력 검증 추가
컴포넌트 분리
API Route 수정
테스트 코드 작성
작은 UI 동작 개선

특별히 난도가 높거나 단순하지 않다면 Terra를 기본값으로 두는 방식이 효율적이다.

Luna — 빠르고 가벼운 작업

Luna는 빠른 반복과 정리, 탐색처럼 깊은 추론이 필요하지 않은 작업에 적합하다.

예를 들면 다음과 같다.

문서 정리
작은 문구 수정
코드 위치 탐색
파일 구조 확인
간단한 설명 작성
초기 아이디어 조사

작업이 명확하고 범위가 작다면 무거운 모델을 사용할 필요가 없다.

결국 중요한 것은 최고 성능의 모델 하나만 고집하는 것이 아니라 다음 세 가지를 함께 보는 것이다.

작업의 난이도 + 실패했을 때의 비용 + 기다릴 수 있는 시간

이 기준은 개발팀 운영에서도 중요하다. 간단한 문구 수정까지 가장 무거운 모델로 처리하면 속도와 사용량을 낭비하고, 반대로 전체 구조를 건드리는 작업에 가벼운 모델을 사용하면 잘못된 수정이 더 큰 비용으로 돌아올 수 있다.

모델보다 먼저 결정해야 하는 생각의 깊이

강의에서는 모델 선택과 함께 Reasoning Effort, 즉 AI가 문제를 얼마나 깊이 생각하도록 할 것인지도 설명했다.

생각의 깊이는 대략 다음과 같이 구분할 수 있었다.

Low

작은 문구 수정이나 범위가 명확한 질문, 간단한 문서 정리에 적합하다.

Medium

일상적인 개발의 기본값이다. 속도와 결과 품질 사이에서 균형이 좋다.

High 또는 Max

원인이 모호한 버그, 처음 보는 저장소, 여러 파일에 걸친 수정처럼 깊은 분석이 필요한 작업에 적합하다.

Ultra

여러 하위 에이전트가 병렬로 처리할 수 있는 매우 복잡한 과제에 사용한다. 다만 사용량이 빠르게 줄어들 수 있으므로 꼭 필요한 경우에만 선택해야 한다.

여기서 기억해야 할 원칙은 간단했다.

처음부터 가장 높은 단계로 시작하지 말고, 기본값으로 실행한 뒤 결과가 부족할 때 한 단계씩 높인다.

나 역시 Codex를 사용하면서 어려운 작업일수록 무조건 가장 높은 설정을 선택해야 한다고 생각한 적이 있었다. 하지만 이번 강의를 통해 작업의 크기와 위험도에 맞춰 모델과 추론 강도를 조절하는 것도 개발자의 중요한 판단이라는 것을 배웠다.

AI를 사용했다고 모두 AI 서비스는 아니다

이번 강의의 핵심은 AI 기능과 AI 서비스를 구분하는 것이었다.

강의자료에서는 AI 서비스를 다음과 같이 설명했다.

사용자의 입력을 받아 AI가 판단하거나 생성하고, 그 결과가 서비스 화면 안에서 실제 기능처럼 작동하는 서비스

즉, 프롬프트를 입력하고 AI의 답변을 받아오는 것만으로는 충분하지 않다.

AI 서비스에는 다음 흐름이 있어야 한다.

사용자 입력
→ AI 처리
→ 구조화된 결과
→ 서비스 화면
→ 사용자의 다음 행동

예를 들어 CampusLog의 AI 추천 기능은 단순히 “이 경험을 추천합니다”라는 문장을 생성하는 것이 아니다.

사용자가 활용 목적과 문항을 입력한다.
저장된 경험을 AI가 비교한다.
적합한 경험을 순위별로 추천한다.
추천 이유와 부족한 근거를 설명한다.
과장 위험을 표시한다.
사용자가 자소서나 면접 답변 작성으로 이어갈 수 있게 한다.

AI를 사용했다는 사실보다 중요한 것은 AI를 통해 사용자가 얻는 결과가 실제로 달라지는가이다.

강의자료의 표현처럼 AI 서비스는 “AI를 썼다”가 아니라 사용자가 얻는 결과 화면이 달라지는 서비스라고 이해할 수 있었다.

AI 기능을 만드는 세 가지 방법

강의에서는 AI 기능을 구현하는 방법을 크게 세 가지로 구분했다.

AI API 사용

OpenAI, Anthropic, Gemini처럼 이미 만들어진 AI 모델을 API로 호출하는 방식이다.

사용자가 서비스를 이용할 때마다 서버가 AI API에 요청을 보내고 결과를 받아온다. 외부 사용자가 계속 사용하는 공개 서비스라면 일반적으로 이 구조가 적합하다.

Codex exec 사용

터미널이나 CI 환경에서 Codex 에이전트를 비대화형으로 한 번 실행하는 방식이다.

AI 기능의 입력과 출력이 제대로 작동하는지 빠르게 검증하거나, 반복 작업과 자동화에 활용할 수 있다.

직접 모델 제작

직접 데이터를 수집하고 모델을 학습한 뒤 서버에 배포하는 방식이다.

가장 높은 자유도를 가질 수 있지만 데이터, 인프라, 학습 비용과 운영 역량이 필요하기 때문에 이번 프로젝트의 범위에서는 제외됐다.

이번 UNIKER 프로젝트에서는 서비스의 최종 운영은 AI API, 빠른 기능 구현과 검증은 Codex exec를 활용하는 방향으로 정리할 수 있었다.

API는 요청과 응답의 약속이다

API라는 단어는 처음 들으면 복잡하게 느껴질 수 있지만, 강의에서는 이를 주문 과정에 비유했다.

사용자 화면은 주문서를 작성하는 손님
우리 서버는 주문서를 정리하는 직원
AI API는 결과를 만드는 전문가

사용자는 화면에서 필요한 내용을 입력한다. 서버는 이 입력을 AI가 이해할 수 있는 요청으로 정리하고 API 키를 이용해 AI 서비스에 전달한다. AI는 정해진 형식으로 결과를 반환하고, 서버는 이를 화면에 보여준다.

사용자 화면
→ 우리 서버
→ AI API
→ 우리 서버
→ 결과 화면

여기서 핵심은 단순히 무엇을 보낼지 정하는 것이 아니라, 어떤 형태로 결과를 받을지까지 미리 약속하는 것이다.

예를 들어 AI가 매번 자유로운 문장으로 답하면 화면에서 결과를 안정적으로 보여주기 어렵다. 반면 다음과 같은 JSON 구조를 정해두면 카드나 배지, 경고 문구로 쉽게 연결할 수 있다.

{
  "recommendations": [
    {
      "title": "추천 경험 제목",
      "reason": "이 경험을 추천하는 이유",
      "missingEvidence": ["추가로 필요한 근거"],
      "overclaimRisk": "과장 가능성"
    }
  ]
}

결국 API 설계는 AI에게 질문을 잘하는 것만이 아니라, 화면이 사용할 수 있는 결과 구조를 정하는 일이다.

API 키는 반드시 서버가 보관해야 한다

강의에서 실무적으로 중요했던 내용은 API 키 보안이었다.

API 키는 AI 서비스를 호출할 수 있는 비밀 출입카드와 같다. 따라서 사용자의 브라우저나 공개된 GitHub 저장소에 노출돼서는 안 된다.

API 키는 다음과 같은 위치에 보관해야 한다.

로컬 개발 환경의 .env.local
Vercel의 Environment Variables
서버 내부 환경변수

반대로 다음과 같은 방식은 피해야 한다.

NEXT_PUBLIC_이 붙은 환경변수
프론트엔드 코드에 API 키 작성
GitHub 저장소에 키 커밋
브라우저에서 AI API 직접 호출

사용자는 비밀 출입카드를 볼 필요가 없다. 사용자는 우리 서버에 요청하고, API 키를 가진 서버가 AI를 호출해야 한다.

브라우저 → 우리 서버 → AI API

이 구조는 단순한 구현 방식의 차이가 아니라 서비스 보안의 기본 원칙이다.

JSON 응답만큼 중요한 화면 상태

AI API를 연결하면 성공 결과만 생각하기 쉽다. 하지만 실제 서비스에서는 AI 응답이 느리거나, 잘못된 형식으로 오거나, 호출 자체가 실패할 수 있다.

강의에서는 결과 화면을 다음 세 가지 상태로 나누어 설명했다.

성공

정상적인 JSON 결과를 받아 카드나 문장으로 보여준다.

로딩

AI 응답에는 시간이 걸릴 수 있으므로 버튼을 비활성화하고, 현재 처리 중임을 사용자에게 알려야 한다.

실패

API 오류, JSON 파싱 실패, 사용량 초과 등이 발생했을 때 샘플 결과나 재시도 버튼을 제공해야 한다.

이번 강의에서 가장 기억에 남은 메시지는 다음이었다.

AI가 실패해도 서비스 화면은 멈추면 안 된다.

CampusLog에도 그대로 적용할 수 있는 원칙이다.

AI 추천이 실패했을 때 단순히 흰 화면이나 에러 코드만 보여주는 것이 아니라,

기존 입력을 유지하고
재시도 버튼을 제공하며
마지막 정상 결과를 보존하고
필요하면 Mock 결과를 보여주는 것

까지 설계해야 한다.

AI의 성능뿐 아니라 실패했을 때 사용자가 무엇을 할 수 있는지가 서비스 품질을 결정한다.

AI API 서비스별 특징

강의에서는 대표적인 AI API와 플랫폼도 함께 살펴봤다.

OpenAI

텍스트, 이미지, 음성, 코드 생성과 구조화된 출력까지 하나의 API 안에서 폭넓게 다룰 수 있다.

사용자 답변 분석, 추천 카드 생성, JSON 결과 생성처럼 CampusLog에 필요한 기능과 잘 맞는다.

Anthropic Claude

긴 문서 분석, 글쓰기, 추론, 코딩에 강점이 있다.

자기소개서 피드백이나 리서치 요약, 정책 문서 분석 등에 활용할 수 있다.

Gemini

Google 생태계와 연결하기 좋고 텍스트와 이미지 등 멀티모달 입력을 처리할 수 있다.

이미지 설명, 자료 요약, 검색형 응답 등에 활용할 수 있다.

Replicate

다양한 공개 모델을 API로 빠르게 실행할 수 있다.

이미지 생성, 배경 제거, 영상 변환처럼 특정 모델을 실험할 때 유용하다.

Hugging Face

모델과 데이터셋을 탐색하고 공개 데모를 확인할 수 있는 AI 커뮤니티 플랫폼이다.

원하는 기능을 직접 만들기 전에 유사 모델과 데모가 존재하는지 조사하기 좋다.

ElevenLabs

음성 합성, 음성 인식, 보이스 디자인에 특화돼 있다.

면접 연습 음성이나 캐릭터 목소리, 음성 안내 서비스 등에 활용할 수 있다.

중요한 것은 어떤 서비스가 가장 유명한지를 비교하는 것이 아니라, 우리가 원하는 출력 유형과 비용, 구현 난이도에 따라 선택하는 것이다.

MVP 단계에서는 비용보다 먼저 흐름을 검증해야 한다

AI API는 대부분 호출량이나 토큰 사용량에 따라 비용이 발생한다.

문제는 개발 중에도 문구를 조금 수정하거나 화면을 반복해서 확인할 때마다 호출 비용이 쌓일 수 있다는 점이다.

따라서 강의에서는 MVP 단계에서 다음 순서를 권장했다.

Mock 데이터로 화면 검증
→ Codex exec로 실제 AI 결과 확인
→ 필요한 순간에만 API 호출
→ 운영 단계에서 서버 API로 전환

AI 기능을 처음부터 완전한 운영 구조로 만들기보다, 먼저 사용자의 입력이 결과 화면으로 이어지는 흐름이 유용한지를 확인해야 한다.

아무리 뛰어난 AI를 연결해도 사용자가 입력해야 할 내용이 불명확하거나 결과 화면이 이해하기 어렵다면 좋은 서비스가 될 수 없다.

CampusLog 역시 AI 모델의 성능만 높이는 것보다,

어떤 경험 데이터를 입력으로 사용할지
추천 결과에 무엇을 보여줄지
사용자가 다음에 무엇을 할 수 있을지
잘못된 추천을 어떻게 발견할지

를 먼저 검증하는 것이 중요하다.

Codex exec는 ‘주문서 맡기기’에 가깝다

이번 강의에서 가장 새롭게 배운 개념은 Codex exec였다.

일반적인 Codex 사용은 대화창에서 여러 차례 이야기를 주고받으며 작업을 수정하는 방식이다. 반면 Codex exec는 채팅창을 열지 않고, 터미널에서 하나의 요청을 전달한 뒤 최종 결과를 받는다.

프롬프트 준비
→ codex exec 실행
→ 결과 출력
→ JSON 또는 파일로 저장

강의에서는 이를 ‘주문서 맡기기’에 비유했다.

화면에서 조건을 선택하면 서비스가 프롬프트 주문서를 만든다. 사용자는 이 주문서를 터미널의 Codex exec에 전달한다. Codex는 한 번 작업한 뒤 JSON 결과를 반환하고, 그 결과를 다시 서비스 화면의 카드에 적용한다.

Codex exec가 유용한 경우는 다음과 같다.

반복 가능한 한 번짜리 작업
문서나 데이터 정리
CI 내부 자동화
AI 기능의 입출력 검증
해커톤 시연용 MVP
결과를 파일이나 JSON으로 연결하는 작업

그러나 외부 사용자가 계속 이용하는 서비스의 백엔드로 바로 사용하는 것은 운영 복잡도가 커질 수 있다.

API와 Codex exec의 차이

강의 내용을 정리하면 둘의 차이는 다음과 같다.

AI API

서비스 서버가 AI 회사의 API를 호출한다.

외부 사용자의 반복 요청 처리
API 키와 비용 관리
오류와 사용량 제한 처리
공개 서비스 운영에 적합

Codex exec

터미널이나 스크립트에서 Codex를 비대화형으로 실행한다.

로컬 MVP
내부 기능 검증
반복 작업 자동화
시연과 프로토타입에 적합

Codex exec를 클라우드에서 실행하는 것도 가능하지만, 그렇게 하려면 인증, Git 작업공간, sandbox, timeout, 대기열, 동시 실행, 로그 관리가 필요해진다.

따라서 강의에서 제시한 기준은 명확했다.

MVP와 시연은 exec, 실제 운영은 API

이번 프로젝트 역시 최종 해커톤 현장에서 기능을 시연하는 것이 목표이기 때문에, 처음부터 복잡한 공개 운영 환경을 만들기보다 Codex exec로 핵심 AI 기능이 실제로 작동한다는 것을 증명하는 방향이 적합하다.

Prompt에서 JSON까지 이어지는 흐름

Codex exec를 활용한 로컬 MVP 흐름은 다음과 같았다.

1. 화면 입력

사용자가 지역, 목적, 조건과 같은 값을 선택한다.

CampusLog라면 활용 목적, 지원 문항, 직무 정보가 될 수 있다.

2. 주문서 만들기

화면에서 선택한 값을 바탕으로 Codex에 전달할 프롬프트를 만든다.

3. 한 번 실행

사용자가 프롬프트를 복사해 터미널에서 Codex exec를 실행한다.

4. 결과 붙이기

Codex가 반환한 JSON을 화면에 적용해 카드나 분석 결과로 보여준다.

이 방식은 완전한 자동화는 아니지만, AI 기능의 핵심 계약을 빠르게 검증할 수 있다.

사용자의 입력이 달라지면 결과도 달라지는지, JSON이 화면에 맞는 구조로 생성되는지, 파싱 실패 시 어떻게 대응할지를 확인할 수 있기 때문이다.

JSON은 화면에 붙일 때만 필요하다

AI에게 항상 JSON으로 답하도록 요구할 필요는 없다.

단순히 사람이 읽고 복사하는 결과라면 일반 문장으로도 충분하다. 하지만 결과를 코드가 읽어 카드나 표로 자동 표시해야 한다면 JSON 구조가 필요하다.

강의에서는 다음 요소를 구분했다.

일반 출력: 사람이 읽는 문장
--json: 실행 과정 이벤트를 JSON 형태로 출력
--output-schema: 최종 결과의 구조를 고정
결과 파일: 최종 JSON을 파일로 저장

중요한 것은 JSON 자체를 사용하는 것이 목적이 아니라, 화면이 필요로 하는 데이터 구조를 안정적으로 보장하는 것이다.

CampusLog의 추천 결과라면 다음과 같은 계약을 먼저 정해야 한다.

추천 경험은 정확히 몇 개인가
추천 이유가 반드시 포함되는가
근거 부족 항목은 배열인가
과장 위험은 어떤 형식인가
존재하지 않는 경험을 추천하지 않는가

출력 계약이 명확할수록 AI 결과를 서비스 화면에 연결하기 쉬워진다.

권한과 보안을 함께 생각해야 한다

Codex exec는 실제 파일과 터미널 환경에 접근할 수 있기 때문에 권한 설정이 중요하다.

강의에서는 기본적으로 읽기 전용 환경에서 시작하고, 파일 수정이 필요한 경우에만 권한을 넓히는 방식을 권장했다.

기본은 read-only
파일을 수정해야 할 때만 workspace-write
전체 접근 권한은 격리된 환경에서만 사용
API 키와 개인정보를 프롬프트에 포함하지 않기
브라우저가 임의로 로컬 명령을 실행하지 못하게 하기

AI에게 일을 맡긴다고 해서 모든 권한을 한 번에 열어주는 것은 안전하지 않다.

사람에게 업무를 위임할 때도 필요한 문서와 권한만 전달하듯, AI 에이전트에도 최소 권한 원칙을 적용해야 한다.

CampusLog에 적용해 본다면

이번 강의 내용은 우리 팀의 CampusLog 개발에도 바로 적용할 수 있다.

현재 CampusLog에는 사용자가 자신의 경험을 기록하고, AI가 경험을 분석하거나 지원 목적에 맞는 경험을 추천하는 기능이 있다.

이를 이번 강의의 흐름으로 정리하면 다음과 같다.

사용자 입력

지원 목적
자기소개서 또는 면접 문항
지원 직무
저장된 경험 목록

AI 작업

질문의 핵심 역량 분석
경험별 관련도 비교
추천 경험 순위 생성
근거 부족 여부 확인
과장 가능성 탐지

출력

추천 경험 Top 3
추천 이유
활용 가능한 근거
보완해야 할 정보
과장 위험
다음 행동

실패 상태

JSON 파싱 실패
추천 결과가 없는 경우
존재하지 않는 경험을 추천한 경우
AI 응답이 지나치게 일반적인 경우
실행 또는 사용량 제한 실패

이번 강의를 통해 현재 CampusLog의 AI 기능도 단순히 결과를 생성하는 데서 끝나서는 안 된다는 점을 다시 확인했다.

AI가 왜 그 경험을 추천했는지, 어떤 정보가 부족한지, 사용자가 다음에 무엇을 해야 하는지까지 보여줘야 실제 취업 준비를 돕는 서비스가 될 수 있다.

OpenAI Build Week 해커톤에 도전해 보고 싶다는 생각

강의 중 OpenAI Build Week와 같은 해커톤 이야기도 나왔다.

상금이 현금으로 제공되는 대회이기도 하지만, 더 중요한 것은 우리 삶에 실제로 도움이 되는 앱을 만들어 제출하는 자리라는 점이었다.

이 이야기를 들으면서 현재 개발하고 있는 CampusLog도 충분히 확장 가능성이 있다고 느꼈다.

대학생은 프로젝트, 대외활동, 봉사, 공모전 등 다양한 경험을 쌓지만 시간이 지나면 구체적으로 무엇을 했고 어떤 성과를 냈는지 잊어버리기 쉽다. 취업 준비를 시작한 뒤에야 과거 경험을 다시 복원하려고 하면 근거가 부족하거나 내용이 과장되기 쉽다.

CampusLog는 이러한 문제를 해결하기 위해,

활동 중 기록을 축적하고
활동 종료 후 하나의 경험으로 정리하며
AI가 STAR 구조와 역량을 분석하고
지원 문항에 맞는 경험을 추천하는 서비스

를 목표로 하고 있다.

단순한 AI 챗봇이 아니라 사용자가 자신의 경험을 장기적으로 관리하고, 필요한 순간에 근거 있는 답변으로 활용하도록 돕는다는 점에서 ‘우리 삶에 도움이 되는 앱’이라는 해커톤 주제와도 잘 맞을 수 있다고 생각했다.

이번 UNIKER 프로젝트에서 MVP를 완성한 뒤 실제 사용자 테스트와 문제 검증을 보완해, 비슷한 AI 해커톤에도 도전해 보고 싶다.

이번 강의를 통해 얻은 핵심 인사이트

이번 강의에서 얻은 가장 큰 인사이트는 세 가지였다.

첫째, 가장 강력한 모델이 항상 가장 좋은 선택은 아니다

작업의 난이도와 위험도, 기다릴 수 있는 시간에 따라 Sol, Terra, Luna와 추론 강도를 조절해야 한다.

AI를 잘 활용한다는 것은 가장 비싼 모델을 선택하는 것이 아니라, 작업에 맞는 도구와 설정을 고르는 것이다.

둘째, AI 기능은 입력과 출력의 계약으로 설계해야 한다

AI에게 자유롭게 답하게 한 뒤 화면에 억지로 끼워 맞추는 것이 아니라, 어떤 값을 입력하고 어떤 구조로 결과를 받을지 먼저 정의해야 한다.

좋은 프롬프트는 화면과 서비스 흐름에서 시작된다.

셋째, AI가 실패해도 서비스는 계속 작동해야 한다

AI 응답은 느려질 수 있고, JSON이 깨질 수도 있으며, 사용량 제한에 걸릴 수도 있다.

따라서 로딩, 실패, 빈 결과, 재시도, Mock 결과와 같은 대체 상태가 반드시 필요하다.

AI 서비스의 완성도는 정상적인 결과뿐 아니라 실패했을 때의 사용자 경험에서도 드러난다.

경제금융용어 공부 562 : 총고정자본형성

MKISOS — Thu, 16 Jul 2026 21:00:09 +0900

총고정자본형성

경제 뉴스에서 "설비투자가 증가했다", "기업의 투자심리가 살아나고 있다"는 표현을 자주 볼 수 있다. 이러한 투자 활동을 경제지표로 측정한 것이 바로 총고정자본형성이다. 총고정자본형성은 기업이나 정부가 미래의 생산능력을 높이기 위해 공장, 기계, 건물 등 장기간 사용할 자산에 얼마나 투자했는지를 보여주는 대표적인 투자 지표이다.

1. 한 줄 정의

총고정자본형성은 기업과 정부 등이 미래 생산을 위해 공장, 기계, 건물 등 고정자산을 새로 구입하거나 설치하는 투자 활동을 의미한다.

2. 기본 개념

총고정자본형성(Gross Fixed Capital Formation)은 여러 해 동안 생산활동에 사용되는 고정자산을 새롭게 취득하는 투자 규모를 의미한다.

여기서 고정자산이란 공장, 기계설비, 건물, 생산설비처럼 오랫동안 사용하는 자산을 말한다.

예를 들어 기업이 새로운 공장을 짓거나 생산라인을 증설하고, 정부가 도로와 공공시설을 건설하는 것도 총고정자본형성에 포함된다.

반면 토지 구매나 이미 사용하던 중고 설비의 거래는 새로운 생산능력이 만들어지는 것이 아니므로 일반적으로 총고정자본형성에 포함되지 않는다.

또한 기계를 설치하는 비용이나 취득세, 등록세 등 자산을 취득하는 과정에서 발생한 부대비용도 함께 포함된다.

3. 왜 중요한가

경제가 성장하려면 소비뿐 아니라 미래를 위한 투자가 계속 이루어져야 한다.

기업이 새로운 공장을 짓고 생산설비를 늘리면 앞으로 더 많은 상품을 생산할 수 있다.

정부가 사회기반시설에 투자하면 경제활동이 더욱 활발해질 수 있다.

따라서 총고정자본형성은 한 나라의 미래 성장 가능성과 기업들의 투자 의지를 보여주는 중요한 경제지표로 활용된다.

4. 쉽게 이해하는 예시

대학생 예시

카페 창업을 준비하는 학생이 있다고 가정해보자.

커피 머신, 냉장고, 테이블, 인테리어 공사 등에 돈을 투자했다면 이러한 지출은 앞으로 오랫동안 영업에 사용하는 자산이므로 총고정자본형성과 비슷한 개념이다.

기업 예시

자동차 회사가 새로운 전기차 생산공장을 건설하고 최신 로봇 설비를 도입했다면 이는 대표적인 총고정자본형성이다.

이러한 투자는 앞으로 수년간 생산에 활용된다.

국가경제 예시

정부가 고속철도나 공항을 건설하는 것도 장기간 사용할 사회기반시설에 대한 투자이므로 총고정자본형성에 포함된다.

5. 핵심 특징

5-1. 미래 생산능력을 높이기 위한 투자이다

총고정자본형성은 당장의 소비가 아니라 앞으로 생산을 늘리기 위한 투자이다.

경제성장의 기반이 되는 활동이라고 볼 수 있다.

5-2. 장기간 사용하는 자산이 대상이다

공장, 건물, 기계, 생산설비 등 여러 회계연도 동안 사용하는 자산만 포함된다.

소모성 재료나 일회성 소비는 포함되지 않는다.

5-3. 신규 투자만 포함된다

새로운 생산능력을 만드는 투자가 대상이다.

따라서 토지 거래나 중고 자산의 단순 매매는 일반적으로 제외된다.

6. 관련 개념과의 차이

총고정자본형성 vs 소비

총고정자본형성

미래 생산을 위한 투자
공장, 기계, 건물 등 고정자산 취득
장기적인 경제성장에 기여

소비

현재 생활을 위한 지출
음식, 의류, 서비스 이용 등
즉시 사용하고 종료

즉 소비는 현재를 위한 지출이고, 총고정자본형성은 미래를 위한 투자이다.

총고정자본형성 vs 재고투자

총고정자본형성

생산설비와 건물 등 고정자산 투자

재고투자

판매하지 않은 제품이나 원재료 증가

둘 다 투자에 포함되지만 대상이 서로 다르다.

7. 경제적 의미

국가경제 관점

총고정자본형성이 증가하면 기업과 정부가 미래 경제를 긍정적으로 전망하고 있다는 의미로 해석되는 경우가 많다.

경제성장률을 결정하는 중요한 요소 가운데 하나이다.

기업 관점

기업의 설비투자가 늘어나면 생산능력이 확대되고 장기적인 경쟁력이 강화될 수 있다.

반대로 투자가 감소하면 경기 둔화 신호로 해석되기도 한다.

금융시장 관점

총고정자본형성은 경기 선행지표 가운데 하나로 활용된다.

투자가 활발하면 기업 실적 개선 기대가 커지고 금융시장에도 긍정적인 영향을 줄 수 있다.

투자 관점

투자자는 총고정자본형성 증가 여부를 통해 경기 회복 가능성을 판단하기도 한다.

설비투자가 꾸준히 증가하면 산업재, 건설, 기계, 반도체 장비 등 투자 관련 업종이 수혜를 받을 가능성이 있다.

8. 정리

총고정자본형성은 기업과 정부 등이 미래 생산을 위해 공장, 기계, 건물 등 고정자산을 새롭게 취득하는 투자 활동을 의미한다. 이는 단순한 소비가 아니라 장기적인 생산능력을 확대하기 위한 투자라는 점에서 중요한 경제지표이다. 총고정자본형성이 증가하면 기업의 투자 의지가 높고 경제성장에 대한 기대가 커지고 있음을 의미하는 경우가 많다. 따라서 경기 전망과 국가 경제의 성장 잠재력을 분석할 때 반드시 살펴보는 핵심 지표 가운데 하나이다.

가디언을 만나다 0x0D : 운이 9라면 준비는 그 운을 잡는 힘이었다 — 삼성전자 DX 신입 합격 인터뷰

MKISOS — Thu, 16 Jul 2026 06:09:38 +0900

“취업에서 운과 실력의 비율을 따지면 저는 운이 9라고 생각해요.
그런데 운이 오려면 계속 찾아보고 준비하고 있어야 해요.”

※ 아직 입사 전인 만큼 삼성전자 내부 업무나 확정되지 않은 배치 정보보다는 학교생활과 취업 준비 과정에 집중했습니다.

프롤로그

황재찬 형과 나는 충북대학교 소프트웨어학부에서 서로 얼굴과 이름을 알고 인사하는 사이였다.

같은 학과 선후배였지만 활동 시기와 소속 동아리가 달라 깊은 이야기를 나눌 기회는 많지 않았다. 그래도 학교생활을 하면서 형의 이름은 여러 번 들었다. 알고리즘을 잘하고 프로젝트와 학부 연구 활동을 꾸준히 하며 후배들에게도 실력 있는 선배로 알려진 사람이었다.

그러던 중 형이 삼성전자 DX 부문에 합격했다는 소식을 보게 됐다.

축하 메시지를 보내면서 조심스럽게 커피챗을 부탁했고 형은 입사 전까지 시간이 있다며 흔쾌히 만나자고 했다. 이후 내가 진행하고 있는 ‘가디언과의 만남’ 인터뷰를 제안하자 형은 오히려 이렇게 말했다.

“내가 그런 시리즈에 껴도 되나? 나는 운이 좋았던 케이스인데.”

하지만 이야기를 나눌수록 알게 됐다.

형이 말한 ‘운’은 아무것도 하지 않고 기다리다가 우연히 얻은 행운이 아니었다. 학교 안에서 알고리즘을 공부하고 전국 단위의 경쟁을 경험하고 학부 연구생으로 논문과 시스템을 접하고 SSAFY와 스타트업을 거치며 자신이 갈 수 있는 길을 넓혀온 사람에게 찾아온 기회였다.

2026년 7월 11일, 청주 성안길의 한 카페에서 황재찬 형의 학교생활과 취업 준비, 졸업 이후의 불안, 그리고 삼성전자 DX 합격까지의 이야기를 들었다.

가디언 인터뷰 정보

만남 일시: 2026년 7월 11일 토요일 오후 4시
만남 장소: 청주 성안길 인근 카페
가디언: 황재찬

가디언 프로필

소속: 삼성전자 DX 부문 입사 예정
입사 예정일: 2026년 7월 27일
직무 방향: 인프라·미들웨어 개발 계열
세부 배치: 입사 후 확정 예정
경력: 신입 입사 예정
학력: 충북대학교 소프트웨어학부 졸업
졸업 시기: 2026년 2월

주요 경험:

알고리즘 학습 및 대회·수상 경험
학부 연구생 및 시스템 관련 프로젝트 경험
SSAFY 광주 캠퍼스 로봇 트랙 참여
스타트업 시스템 엔지니어 근무 경험
삼성전자 DX 부문 신입사원 최종 합격

1. 학교 안에서 잘하는 것만으로는 부족했다

형은 처음부터 삼성전자나 대기업 취업을 목표로 대학에 입학한 학생은 아니었다.

복학을 준비하면서 무엇을 공부할지 고민하다가 알고리즘을 시작했고 예상보다 잘 맞았다. 편의점 야간 아르바이트를 하면서도 시간이 날 때마다 알고리즘 문제를 풀었다.

단순히 문제만 풀었던 것은 아니다.

편의점 업무를 하며 불편하게 느꼈던 부분을 해결하기 위해 재고 관리 프로그램을 직접 만들었다. 코로나19 당시에는 기숙사에서 반복적으로 해야 했던 자가진단과 출석 확인을 자동화하는 프로그램도 제작했다.

지금처럼 생성형 AI가 코드를 대신 작성해주던 시기가 아니었다. 필요한 기능을 직접 고민하고 자료를 찾아보며 구현해야 했다.

이 경험들은 형의 개발관을 보여준다.

“요즘 면접관들이 가장 궁금해하는 건 이 사람이 스스로 문제를 발견하고 해결할 수 있는 사람인가인 것 같아요.”

거창한 기술을 사용하는 것보다 일상에서 불편함을 발견하고 기술을 이용해 직접 해결해본 경험이 중요하다는 것이다.

알고리즘 실력이 빠르게 늘면서 학교 안에서는 좋은 성과를 거뒀지만 외부 대회에 나간 뒤에는 자신의 위치를 다시 보게 됐다.

“학교 안에서는 이 정도면 잘하는 것 같았는데, 전국 대회에 나가니까 바로 깨졌어요. 그때 내가 비교 대상을 잘못 잡고 있었다는 걸 알았죠.”

이후 형은 학과 안에서 자신이 어느 정도 위치에 있는지를 확인하기보다 학교 밖의 사람들과 경쟁하고 교류하면서 시야를 넓히려고 했다.

상위권 대학 학생들과 경쟁한다는 생각에 지나치게 얽매일 필요도 없다고 했다. 학교 이름보다 결국 자신이 무엇을 공부했고, 어떤 문제를 해결해봤는지가 더 중요하다는 것이다.

“학교 사람들만 보고 안심하면 안 돼요. 밖으로 나가면 정말 잘하는 사람이 많거든요.”

2. 하나의 분야만 파기보다 여러 분야를 경험했다

형의 프로젝트 경험은 하나의 직무에 깔끔하게 정렬되어 있지 않았다.

백엔드와 프론트엔드, AI 모델 개발, 시스템 분야까지 다양한 영역을 경험했다. 졸업 작품에서는 AI 모델을 다뤘고 학부 연구 활동에서는 시스템과 인프라에 가까운 주제를 접했다.

면접에서는 오히려 이런 질문을 받기도 했다.

“왜 프로젝트 분야가 이렇게 다양하죠?”

한 분야에 집중하지 못한 것처럼 보일 수도 있었다. 하지만 형은 대학생이라면 자신이 정말 하고 싶은 분야를 확신하기 전까지 여러 영역을 경험해보는 것도 필요하다고 말했다.

“대학생 때는 여러 개를 해보는 것도 맞는 것 같아요. 내가 이것만 평생 하겠다는 확신이 있는 게 아니라면 경험을 해봐야 어떤 길이 맞는지 알 수 있으니까요.”

신입에게 모든 분야의 높은 전문성을 요구하는 것은 아니다. 채용 공고에 적힌 기술 역시 모두 갖춰야 하는 필수 조건으로 받아들이지 말아야 한다고 했다.

필수 역량과 우대 역량을 구분하고 현재 자신에게 필요한 경험을 선택해야 한다.

특히 형은 오픈소스를 단순히 설치해서 사용하는 수준을 넘어 직접 수정하거나 기여해보는 경험을 추천했다. 기존 시스템을 분석하고 자신의 목적에 맞게 개선하는 과정에서 기술에 대한 깊이와 주도성을 보여줄 수 있기 때문이다.

프로젝트의 숫자도 중요하지만 그보다 중요한 것은 다음과 같은 질문에 답할 수 있는가였다.

왜 이 문제를 해결하려고 했는가?
다른 방법이 아니라 이 기술을 선택한 이유는 무엇인가?
구현 과정에서 어떤 문제가 발생했는가?
자신이 직접 판단하고 결정한 부분은 무엇인가?
결과적으로 무엇을 배우고 개선했는가?

프로젝트를 많이 했다는 사실보다 하나의 경험을 자신의 언어로 깊게 설명할 수 있는 능력이 중요했다.

3. 대학원을 생각하다 취업으로 방향을 바꾸다

형은 원래 대학원 진학을 생각했다.

시스템과 컴퓨터과학 분야를 공부하는 것이 재미있었고 학부 연구 활동을 하면서 연구의 매력도 느꼈다.

학부 연구생 경험의 장점으로 형은 세 가지를 꼽았다.

첫째, 학회에 참여하며 학교 밖 연구자와 기술의 흐름을 볼 수 있다.

둘째, 논문을 읽고 근거를 찾아가는 과정을 배우게 된다.

셋째, 혼자였다면 미뤘을 일도 연구실에서는 과제로 주어지기 때문에 계속 공부하며 실력을 키울 수 있다.

논문을 읽은 경험은 면접에서도 도움이 됐다. 특정 기술 선택의 이유를 질문받았을 때 단순한 개인 의견이 아니라, 이전에 읽은 논문이나 연구 결과를 근거로 설명할 수 있었기 때문이다.

하지만 대학원 진학을 준비하면서 현실적인 고민도 커졌다.

더 높은 수준의 연구를 수행할 준비가 충분한지 확신이 없었고, 대학원 입시 시기도 일부 놓쳤다. 긴 시간과 경제적인 문제도 고려하지 않을 수 없었다.

결국 형은 4학년 2학기 무렵 대학원 대신 취업으로 방향을 바꿨다.

완벽한 계획에 따라 선택한 길이라기보다, 자신이 놓인 상황과 가능성을 계속 확인하며 방향을 수정한 결과였다.

4. 졸업 후 SSAFY, 스타트업, 그리고 다시 취업 준비

2026년 2월 졸업 후 형의 행보는 짧은 기간 안에 여러 번 바뀌었다.

먼저 SSAFY 광주 캠퍼스의 로봇 트랙에 참여했다. 특별히 거창한 이유가 있었던 것은 아니었다.

“로봇이 그냥 멋있어 보여서 광주로 갔어요.”

다소 가볍게 시작한 선택처럼 들렸지만 SSAFY 생활은 졸업 후 공백기를 보내는 데 큰 도움이 됐다.

아침 일찍 운동하고, 씻고 밥을 먹은 뒤 교육장에 가서 공부했다. 교육이 끝나면 집으로 돌아와 다시 자신의 공부를 이어갔다. 매일 정해진 장소에 나가 사람들과 공부하고 교류할 수 있다는 것 자체가 중요한 루틴이 됐다.

“취업 준비는 언제 끝날지 모르잖아요. 그래서 하루 일과를 정해놓는 게 중요해요. 그렇지 않으면 쉽게 무너져요.”

형은 취업 시점을 몇 개월 안으로 제한하지 않았다.

취업은 자신이 원한다고 특정 날짜에 끝낼 수 있는 일이 아니기 때문이다. 대신 통제할 수 없는 합격 시점보다 자신이 통제할 수 있는 하루의 루틴에 집중했다.

SSAFY에서는 전국에서 모인 취업 준비생들과 포트폴리오와 자기소개서를 서로 피드백했다. 이미 알고 있던 내용을 다시 공부하거나 다른 사람에게 설명하면서 기본기도 정리할 수 있었다.

이후 형은 SSAFY를 나온 뒤 한 스타트업에 시스템 엔지니어로 입사했다.

하지만 입사한 지 얼마 지나지 않아 다른 기업과 삼성전자 면접 일정이 연달아 잡혔다. 신입사원에게는 사용할 수 있는 연차가 없었고 이틀 연속 면접을 보기 위해서는 회사를 그만둬야 했다.

합격이 보장되지 않은 상황이었다.

그럼에도 형은 2주 만에 퇴사를 선택했다.

“면접까지 갔을 때 떨어진 적이 없어서 자신감이 조금 있었어요.”

누군가에게는 무모하게 보일 수 있는 선택이다. 그러나 형은 자신이 면접에서 강점이 있다는 것을 알고 있었고, 원하는 기회를 놓치지 않기 위해 위험을 감수했다.

스타트업 경험이 짧았다고 해서 의미가 없었던 것도 아니다.

체계가 충분하지 않은 환경에서 신입이 겪을 수 있는 어려움과 자신에게 맞는 조직의 조건을 빠르게 알게 됐다. 그리고 퇴사 직전 참여했던 AI 세미나의 내용이 이후 삼성전자 직무 면접에서 그대로 등장하는 우연도 경험했다.

5. AI 시대에도 기본 CS와 코딩테스트가 필요한 이유

생성형 AI와 바이브 코딩이 빠르게 확산되면서 코딩테스트가 사라질 것이라는 전망도 나온다.

하지만 형의 생각은 달랐다.

“코딩테스트의 비중은 줄어들 수 있어도 없어지기는 어려울 것 같아요. 적어도 로직을 설계하고, 코드가 무엇을 하는지 이해할 수 있는 사람인지는 봐야 하니까요.”

AI가 코드를 생성해준다고 해도 개발자가 내용을 이해하지 못하면 제대로 된 판단을 할 수 없다.

졸업 작품을 진행할 때도 팀원이 생성형 AI가 작성한 코드를 그대로 가져오면서 코드베이스가 지나치게 커지고 작성한 사람조차 코드의 구조와 이유를 설명하지 못하는 상황을 경험했다.

형은 AI를 사용하지 말아야 한다고 말한 것이 아니다.

오히려 취업 준비 과정에서 AI를 적극적으로 활용했다.

채용 공고의 직무 설명과 자신의 경험을 비교해 어떤 경험을 강조하면 좋을지 분석하고 노션에 정리한 이력과 포트폴리오를 바탕으로 회사별 서류를 수정했다. 기술 자료를 찾거나 논문을 읽을 때도 AI를 검색과 번역의 보조 도구로 사용했다.

다만 생각과 판단까지 AI에 맡기지는 않았다.

“AI가 나를 사용하게 되면 안 되고, 내가 AI를 사용해야 하는 것 같아요.”

형이 중요하게 생각한 기본 CS도 같은 맥락이었다.

가상화와 컨테이너의 차이, 운영체제, 네트워크, 멀티스레딩처럼 기본적인 개념을 알고 있어야 새로운 기술과 AI가 생성한 결과를 제대로 판단할 수 있다.

모든 개념을 깊게 암기할 필요는 없지만, 적어도 어떤 원리로 작동하고 왜 사용하는지는 설명할 수 있어야 한다고 했다.

6. 면접에서 한 번도 떨어지지 않았던 준비법

형은 직무 면접과 임원 면접까지 간 전형에서는 한 번도 떨어진 적이 없다고 말했다.

그 비결은 예상 답변을 통째로 외우는 것이 아니었다.

형은 고등학교부터 대학생활과 취업 준비까지 자신의 경험을 하나의 이야기로 정리해뒀다.

내향적이었던 자신이 왜 동아리에서 사람들 앞에 나서게 됐는지, 팀 프로젝트에서 갈등이 발생했을 때 어떻게 대응했는지, 여러 기술 분야를 경험하면서 왜 시스템과 인프라에 관심을 갖게 됐는지와 같은 흐름이 머릿속에 연결되어 있었다.

면접 질문을 받으면 외운 문장을 꺼내는 것이 아니라, 질문에 맞는 경험을 자신의 전체 이야기에서 꺼냈다.

“대본을 외우면 질문이 조금만 달라져도 고장 나요. 말할 목차 정도만 정해놓고 이야기하는 게 좋아요.”

문제 상황이나 PT형 질문을 받을 때는 다음 순서로 답변을 구성했다.

주어진 상황을 어떻게 이해했는가
어떤 방법으로 해결할 것인가
그 방법을 선택한 이유는 무엇인가
예상되는 결과와 한계는 무엇인가

이 구조를 지키면 예상하지 못한 질문을 받아도 답변의 방향을 잃지 않을 수 있었다.

기술 면접에서 어려운 질문을 받는 것도 반드시 나쁜 신호는 아니라고 했다.

면접관이 지원자의 지식 수준을 점점 깊게 확인한다는 것은 기본적인 답변이 만족스러워 더 높은 수준까지 확인하는 과정일 수도 있다.

형 역시 C언어 버전별 차이처럼 대답하기 어려운 질문을 받았고 모든 질문에 완벽하게 답하지 못했다. 하지만 모르는 것을 모른다고 인정하면서도 자신이 알고 있는 범위까지 논리적으로 설명했다.

자기소개서와 포트폴리오는 ‘방망이를 깎는 심정’으로 준비했다.

약 2주 동안 문장을 작성하고, 버리고, 다시 쓰는 과정을 반복했다. SSAFY 동기들과 서로 포트폴리오를 여러 번 검토하며 어떤 경험이 자신의 강점을 가장 잘 보여주는지 확인했다.

AI로 초안을 만들 수는 있지만, 최종적으로 자신의 경험과 언어가 드러날 때까지 계속 수정했다.

7. 운이 9라고 말한 사람

형에게 이번 합격의 이유를 묻자 예상보다 더 극단적인 답이 돌아왔다.

“취업에서 운과 실력의 비율을 따지면 저는 운이 9라고 생각해요.”

좋은 채용 공고가 자신이 취업을 준비하는 시기에 열려야 한다.

회사가 올해 필요로 하는 직무가 자신의 경험과 맞아야 한다.

면접관과 지원자의 대화 방식이 잘 맞아야 한다.

자신이 최근 공부했던 내용이 면접 질문으로 나올 수도 있고, 반대로 충분히 준비했지만 전혀 다른 내용이 나올 수도 있다.

형에게는 실제로 여러 우연이 겹쳤다.

스타트업에서 들었던 AI 세미나의 내용이 삼성전자 면접 질문으로 등장했다. 가상화와 컨테이너를 공부하며 흥미롭다고 표시했던 책의 부분이 면접에서 질문으로 나왔다. 알고리즘 시험 전날 풀어본 것과 비슷한 유형의 문제가 실제 시험에 등장하기도 했다.

학교 추천 채용이나 우연히 전달받은 좋은 정보도 있었다.

지원자가 모든 변수를 통제할 수 없다는 점에서 형은 취업의 대부분이 운이라고 표현했다.

그렇다면 준비는 의미가 없는 것일까.

오히려 반대였다.

세미나에 참여하지 않았다면 질문이 나와도 답할 수 없었다. 책을 읽지 않았다면 컨테이너와 가상화의 차이를 설명할 수 없었다. 알고리즘 문제를 꾸준히 풀지 않았다면 비슷한 문제를 만나도 알아보지 못했을 것이다.

“좋은 정보가 자꾸 저한테 왔다고 느꼈어요. 그런데 평소에 자료를 찾아보고 사람들과 이야기하고 있었기 때문에 그 정보가 좋은 기회라는 걸 알아볼 수 있었던 것 같아요.”

운은 자신이 선택할 수 없지만 운이 왔을 때 알아보고 잡을 수 있는 상태는 만들 수 있다.

형이 말한 ‘운이 9’라는 표현은 준비가 1밖에 필요하지 않다는 의미가 아니었다.

그 1이 없다면 나머지 9도 기회가 되지 못한다는 의미에 가까웠다.

8. 겉으로는 낙천적이지만, 혼자 있을 때는 불안했다

학교 후배들이 바라본 형은 자신감 있고 낙천적인 사람이었다.

알고리즘을 잘했고, 프로젝트와 연구 경험이 있었으며, 여러 수상 기록도 가지고 있었다. 그래서 주변에서는 형이 취업에 대해 불안하다고 말하면 이런 반응을 보였다.

“네가 불안하면 우리는 어떻게 하냐.”

하지만 형도 졸업 후 취업이 확정되지 않은 기간에는 상당한 불안을 느꼈다.

주변에서는 눈을 조금만 낮추면 취업할 수 있을 것 같다는 말을 했다. 학교에서 기대받던 사람이라는 사실도 오히려 부담이 됐다.

그런 고민을 이야기하면 다른 취업 준비생에게 상처가 될까 봐 쉽게 털어놓지도 못했다.

겉으로는 밝고 낙천적으로 행동했지만, 혼자 있을 때는 작은 실수도 며칠씩 자책할 정도로 자신에게 엄격했다.

“원래는 되게 부정적인 사람이에요. 그래서 최대한 낙천적으로 살려고 노력해요.”

긍정적인 태도는 타고난 성격이 아니라 의식적으로 선택한 태도였다.

‘이 정도면 운이 좋은 편이다’, ‘그래도 괜찮을 것이다’라고 자신에게 계속 말하면서 부정적인 생각에 빠지지 않으려고 했다.

그리고 불안할수록 결과가 아니라 루틴을 지켰다.

취업 합격 여부는 자신의 의지만으로 통제할 수 없지만, 오늘 운동할지, 공부할지, 지원서를 작성할지는 선택할 수 있기 때문이다.

9. 후배들에게 전한 현실적인 조언

학교 안에서만 비교하지 말 것

학교에서 자신이 잘하고 있다고 느끼는 것은 좋은 일이다.

하지만 그것만으로 안심해서는 안 된다. 외부 대회와 학회, 공모전, 교육 프로그램에 참여해 다양한 학교와 배경의 사람들을 만나야 자신의 위치와 부족한 부분을 현실적으로 볼 수 있다.

공모전은 수상보다 경험을 설명하는 것이 중요하다

공모전 수상 기록은 분명 도움이 된다.

그러나 수상 횟수 자체보다 그 과정에서 어떤 문제를 맡았고, 갈등을 어떻게 해결했으며, 기술적인 선택을 왜 했는지 설명할 수 있어야 한다.

많은 경험을 해도 좋지만, 경험을 자신의 이야기로 정리하는 과정이 반드시 필요하다.

프로젝트는 숫자보다 주도성과 깊이

가입과 로그인 기능을 반복해서 구현한 비슷한 프로젝트를 여러 개 만드는 것보다, 하나의 문제를 깊게 고민하고 개선한 경험이 더 가치 있을 수 있다.

오픈소스를 활용하거나 기존 프로젝트를 수정하고, 바이브 코딩 방식도 여러 번 실험하며 더 나은 결과를 찾은 과정을 기록하는 것이 좋다.

학점은 불필요한 의심이 생기지 않을 정도로

학점에 관한 질문에는 개인적인 기준임을 전제로 약 3.7~3.8 정도면 면접에서 학점 자체가 큰 이슈가 되지 않을 가능성이 높다고 답했다.

높을수록 도움이 되지만, 일정 수준을 확보한 뒤에는 프로젝트와 CS, 알고리즘, 경험을 쌓는 데 시간을 분배하는 것이 좋다는 의견이었다.

자격증보다 직무에 필요한 기본기

형은 전공 자격증이 없었지만 대기업 취업 과정에서 그것이 결정적인 약점으로 작용했다고 느끼지는 않았다.

다만 공기업이나 특정 직무에서는 자격증이 필요할 수 있으므로 목표에 따라 준비해야 한다.

무작정 남들이 취득하는 자격증을 따라가기보다, 자신이 지원하려는 기업과 직무에서 실제로 요구하는지를 확인해야 한다.

시스템과 인프라에도 관심을 가져볼 것

AI와 백엔드, 프론트엔드에 많은 학생이 몰리는 상황에서 형은 운영체제와 시스템, 인프라, 미들웨어 분야에도 관심을 가져볼 것을 권했다.

AI 서비스 역시 결국 서버, 네트워크, 운영체제, 인프라 위에서 동작한다. 여러 영역을 경험하고 전체 구조를 이해하는 사람에게 시스템 분야가 좋은 선택지가 될 수 있다는 것이다.

눈을 너무 빨리 낮추지 말 것

형은 자신의 조건을 객관적으로 판단했을 때 더 높은 수준의 회사에 도전할 가능성이 있다면, 취업이 조금 늦어진다는 이유로 너무 빠르게 목표를 낮추지는 않았으면 좋겠다고 말했다.

첫 회사의 환경과 성장 기회가 이후 커리어에 영향을 줄 수 있기 때문이다.

다만 이 조언은 모든 사람에게 동일하게 적용되는 정답이라기보다, 형이 직접 취업 준비와 짧은 직장 생활을 경험한 뒤 내린 개인적인 판단이었다.

10. 좋은 선배와 좋은 후배로 기억되고 싶다

삼성전자 합격이라는 큰 목표를 이룬 뒤 형은 오히려 다음 목표를 고민하고 있었다.

대학생일 때는 공부와 프로젝트, 취업이라는 명확한 목표가 있었다. 하지만 졸업과 취업 이후에는 무엇을 위해 살아갈 것인지 다시 정해야 했다.

책을 읽고, 새로운 사람을 만나고, 체스나 운동처럼 오래 이어갈 취미도 찾고 있었다.

형이 말한 삶의 목표는 거창한 성공이 아니었다.

“좋은 선배, 좋은 후배이고 싶어요. 나중에 돌아봤을 때 재찬이 정도면 나쁘지 않게 살았다고 생각하고 싶어요.”

실제로 형은 학부 시절 알고리즘 스터디를 운영하고, 후배들에게 자신이 정리한 면접 자료와 포트폴리오를 공유했다. 이번 만남에서도 개인적으로 정리해둔 자료와 경험을 아낌없이 설명해줬다.

자신이 먼저 경험한 시행착오를 후배들이 조금 덜 겪었으면 하는 마음이 느껴졌다.

삼성전자라는 회사보다도, 그곳에서 어떤 동료와 선배가 될 것인지가 형에게는 더 중요한 다음 질문일지도 모른다.

이번 만남을 통해 내가 얻은 것

이번 인터뷰를 시작하기 전까지 나는 삼성전자 합격자에게 특별한 전략이나 압도적인 스펙이 있을 것이라고 생각했다.

물론 형에게는 알고리즘, 프로젝트, 연구, 수상과 같은 분명한 준비가 있었다.

하지만 더 인상 깊었던 것은 각각의 경험을 대하는 태도였다.

편의점 아르바이트의 불편함을 프로그램으로 해결하고, 학교 안에서 좋은 성적을 거둔 뒤에도 외부 대회에서 깨지며 비교 대상을 바꾸고, 하나의 직무를 정하지 못했을 때는 여러 기술을 직접 경험했다.

AI를 무조건 거부하지도, AI에 모든 생각을 맡기지도 않았다.

불안이 없었던 것도 아니다. 오히려 혼자 있을 때는 누구보다 자신을 의심하고 자책했다. 그럼에도 밖에서는 긍정적인 태도를 선택하고 무너질 것 같을 때는 매일의 루틴을 지켰다.

그리고 합격한 뒤에는 자신의 모든 노력을 실력이라고 포장하기보다 운이 좋았다고 말했다.

나는 그 말을 이렇게 받아들이게 됐다.

운은 통제할 수 없지만, 운이 왔을 때 그것을 기회로 바꾸는 준비는 통제할 수 있다.

좋은 채용 공고가 열리는 것은 운이다.

최근 공부한 내용이 면접에 나오는 것도 운이다.

나와 잘 맞는 면접관을 만나는 것도 운이다.

하지만 채용 공고를 알아볼 수 있는 경험, 질문에 답할 수 있는 기본기, 면접관에게 보여줄 수 있는 자신만의 이야기는 하루아침에 생기지 않는다.

형은 운이 9라고 말했지만, 그 운을 잡은 사람은 오랜 시간 준비해온 형 자신이었다.