저번 글에서는 USC에서 보낸 첫 일주일의 생활을 간략하게 정리해봤다.

학교를 돌아다니고, LA 시내도 구경하고,
기숙사에서 친구들과 이것저것 해먹고, 마지막에는 해커톤까지...

1주차 이야기가 궁금하다면 아래 글에서 볼 수 있다.

🇺🇸 USC 빅데이터 컨퍼런스 참가기🇺🇸 | USC에서 보낸 첫 일주일

이번에는 그 뒤를 이어
USC에서 보낸 두 번째 일주일과 한국으로 돌아오기까지의 기록을 남겨보려고 한다.

첫 주도 정신없이 돌아다녔는데,
사진을 다시 모아보니 2주 차는 더 열심히 놀러 다닌 것 같다...

일요일 아침, LA에서 샌디에이고로

첫 주 일정이 끝나고
일요일 아침부터 LA를 떠나 샌디에이고로 향했다.

그리고 여기서 꿀팁 하나.

다른 지역으로 넘어갈 때 장거리 버스는 개인적으로 정말 비추천한다.

내가 탔던 버스는 한 시간 정도 늦었고,
이용 환경도 생각보다 편하지 않았다.

심지어 내가 이용했을 때는 왕복 비용도 대략 15만 원 정도 들었다.

다시 간다면?

기차
또는
비행기

를 먼저 알아볼 것 같다.

시간도 여행에서는 돈인데
버스를 기다리면서 시간을 날리는 게 생각보다 너무 아까웠다.

그리고 내가 제일 좋아하는 In-N-Out

샌디에이고에 도착해서 먹은 것은
내가 미국에서 제일 좋아하는 햄버거 중 하나인 인앤아웃.

모자까지 쓰고 음료수 빠는 중...

미국 오면 인앤아웃은 못 참지.

햄버거 + 감자튀김.

개인적으로 미국 햄버거 중에서는
여전히 인앤아웃이 제일 취향이다.

엄청 자극적이지도 않고
가격도 비교적 괜찮아서 미국 갈 때마다 한 번씩은 먹는 것 같다.

샌디에이고 바다

그리고 샌디에이고 바닷가.

LA 바다와는 또 느낌이 달랐다.

날씨도 좋고 바다도 예뻐서
그냥 걷는 것만으로도 좋았다.

그리고 해변에서 만난 바다사자들.

사진으로 볼 때보다
실제로 보니까 신기했다.

미국에 와서 도시 구경만 하다가
이런 풍경을 보고 있으니 여행 온 느낌이 확 났다.

주중에는 Stüssy도 갔다

다시 LA로 돌아와서는
주중에 스투시 매장도 다녀왔다.

구경하다가 가방이 생각보다 싸길래...

하나 사버림.

여행에서 계획에 없던 소비가 제일 무섭다.

그리고 한국에서 출발하기 전부터
노리고 있던 게 하나 있었다.

바로 Los Angeles 프린팅이 들어간 스투시 후디.

거울샷 한 장 찍어주고...

뒷면에는 Los Angeles 프린팅이 크게 들어가 있다.

LA에서 산 옷에 Los Angeles가 박혀 있으니
여행 기념품으로도 딱이었다.

한국에서도 열심히 입어야지.

다시 Hollywood

시내에서도 보이는 Hollywood Sign.

처음에는 저 사인이 뭐가 그렇게 특별한가 싶었는데
LA에 며칠 있다 보니 저게 보일 때마다

"아 내가 지금 LA에 있구나."

싶었다.

그리고 엄청 큰 피자.

이걸 계속 먹다가는...

성인병 안 걸리나? 지방간 생길 듯.

미국 음식은 진짜 양 하나는 인정해야 한다.

Hollywood Walk of Fame

헐리우드 거리를 걷다가 발견한
마이클 잭슨 별.

유명한 사람들의 이름을 하나씩 찾아보는 재미가 있었다.

헐리우드 거리.

관광지 느낌이 정말 강해서
사람도 많고 정신없긴 했지만,

그래도 LA에 왔다면 한 번쯤은 걸어볼 만한 곳이었다.

분위기 좋았던 이탈리아 식당

어느 이탈리아 식당.

정확히 뭘 먹었는지보다
사진에서 보이는 분위기가 너무 좋았다.

느좋...

그리고 이탈리아 갔을 때 생각이 나서 시켜본 Spritz.

여행하다 보면 음식 하나 때문에
예전에 갔던 여행이 갑자기 생각나는 순간이 있는데,

이날이 딱 그랬다.

기숙사에서 진행된 Men's Night

그리고 어느 날 밤...

기숙사에서 진행된 Men's Night.

이번 프로그램에는 여학생들이 훨씬 많았고
기숙사에서도 남자 인원이 상대적으로 적었다.

그래서 남자들끼리 따로 모여 친목회를 열었다ㅋㅋㅋㅋㅋ

별거 한 것도 아닌데 이날 진짜 개꿀잼이었다.

해외 프로그램에서 결국 오래 기억에 남는 건
수업도 수업이지만 이런 사람들이랑 놀았던 순간들인 것 같다.

LA Dodgers 경기 직관

그리고 이번 여행에서 정말 기대했던 일정 중 하나.

LA 다저스 경기 직관!

다저 스타디움 입구.

미국까지 왔는데
MLB 직관은 한 번 해보고 싶었다.

그리고 오타니 뒷모습.

진짜 오타니를 실제로 봤다...

경기장 분위기도 정말 좋았다.

사진으로 보면 잘 안 느껴지는데
실제로 들어가면 경기장 크기와 관중 분위기 때문에 압도되는 느낌이 있다.

경기가 끝난 뒤 찍은 다저 스타디움.

이날 경기가 진짜 재밌었다.

처음부터 오타니가 홈런을 쳤고, 이후에도 계속 엎치락뒤치락하면서 경기가 진행됐다.

결과적으로 다저스가 지기는 했지만
경기 자체가 너무 재밌어서 아쉬움은 별로 없었다.

한국에서 보던 야구와는 또 다른 느낌이었다.

선수들의 경기력이나 경기장 규모, 관중 문화까지
MLB를 직접 보는 재미가 확실히 있었다.

미국에 다시 간다면
MLB 직관은 또 하고 싶다.

Manhattan Beach

맨해튼 비치에 간 날.

Pier 쪽에서 전체적으로 찍은 사진인데
개인적으로 LA에서 봤던 바다 중에서도 정말 좋았다.

바다도 한 장.

LA는 도시 구경하다가
조금만 이동하면 이렇게 바다가 나온다는 게 정말 좋은 것 같다.

그리고 또 간 북창동 순두부

미국에서 한식이 그리울 때쯤 다시 찾아간 곳.

북창동 순두부.

여기서 꿀팁 하나.

여기는 개인적으로 순두부보다 갈비 맛집이다.

갈비 맛있음.

미국에서 며칠 동안 햄버거, 피자 같은 것만 먹다가
한식 먹으면 진짜 정신이 번쩍 든다.

USC에서의 마지막 날

학교 안에서 마지막 날 찍은 사진.

그냥...

느좋이라 올려봄.

처음 USC에 도착했을 때는
2주가 꽤 길 것 같았는데,

막상 마지막 날이 되니까

"벌써 끝이라고?"

싶었다.

마지막은 Santa Monica

산타 모니카 쪽 야자수.

이런 사진 보면
왜 사람들이 캘리포니아 감성이라고 하는지 알 것 같다.

파란 하늘
+
야자수
+
바다

이 조합은 반칙이다.

그리고 그 유명한 Route 66 표지판.

사진 한 장 남겨주고.

산타 모니카 Pier의 놀이기구.

타고 싶다...

시간만 조금 더 있었으면
하루 종일 여기서 놀았을 것 같다.

그리고 한국으로

그렇게 모든 일정을 마치고
드디어 한국으로 돌아가는 비행기를 탔다.

그런데 여기서 마지막 행운이 터졌다.

운 좋게도 내 옆자리가 비어 있었다.

덕분에...

눕코노미 당첨.

장거리 비행에서 옆자리가 비어 있는 것만큼
행복한 일이 없다.

개꿀.

한국 도착하자마자 먹은 것

그리고 한국 도착하자마자 먹으러 간 곳.

내가 제일 좋아하는
돼지국밥 + 수육.

거기에 소주 한잔까지.

미국 음식도 맛있지만
2주 동안 먹고 돌아오니까 역시...

한국 음식이 최고다.

ㄹㅇ 개꿀맛.

그리고 수료증

USC에서 받은 수료증은
한국에 돌아와서 액자에 고이 모셔놨다.

처음 받았을 때 농담으로

"이건 액자에 걸어놔야지."

했는데,

진짜 걸어놨다.

볼 때마다 2주 동안 있었던 일들이 생각날 것 같다.

2주간의 USC 생활을 마치며

처음 미국으로 출발할 때는
이번 프로그램에서 무엇을 얼마나 얻어올 수 있을지 잘 몰랐다.

물론 가장 큰 목적은
USC에서 데이터 사이언스와 AI를 배우는 것이었다.

실제로 수업에서는 평소 소프트웨어 공부를 하면서 깊게 접하지 않았던
데이터 사이언스의 여러 개념들을 배울 수 있었다.

하지만 2주가 끝나고 돌아보니
강의실 안에서 배운 것만큼 강의실 밖에서 경험한 것들도 기억에 많이 남는다.

USC 캠퍼스에서 생활해보고,

친구들과 LA를 돌아다니고,

기숙사에서 같이 밥을 해먹고,

해커톤 때문에 정신없이 개발하고,

샌디에이고도 다녀오고,

MLB도 직접 보고,

마지막에는 산타 모니카 바다까지.

2주라는 시간이 짧다면 짧은 시간이지만
사진을 다시 정리해보니 그 안에서 정말 많은 것을 하고 돌아왔다.

그리고 이번 프로그램에서 개인적으로 가장 크게 느낀 것은
내가 아직 모르는 것이 정말 많다는 것이었다.

평소에는 백엔드 개발이나 알고리즘처럼
내가 공부하던 분야를 중심으로만 바라봤다면,

USC에서는 데이터 사이언스와 머신러닝, AI를 조금 더 넓은 관점에서 접할 수 있었다.

모든 것을 2주 안에 깊게 이해할 수는 없었지만,

"아, 이런 분야가 있고 이런 방식으로 문제를 바라보는구나."

를 직접 배우고 경험한 것만으로도 충분히 의미가 있었다고 생각한다.

무엇보다 새로운 내용을 배우면서
내가 기존에 공부했던 컴퓨터 사이언스 지식과 연결되는 순간들이 꽤 재미있었다.

그래프 탐색이나 알고리즘처럼 이미 학교에서 배웠던 내용도 다시 등장했고,
데이터 사이언스처럼 상대적으로 익숙하지 않았던 분야도 새롭게 공부할 수 있었다.

여행은 끝났지만 공부는 이제부터

USC에서의 생활은 2주로 끝났지만,
개인적으로는 오히려 한국에 돌아온 지금부터가 진짜 시작이라고 생각한다.

수업을 들을 때는 새로운 개념이 계속 쏟아지다 보니
그 자리에서 모든 내용을 완벽하게 이해하기는 어려웠다.

그래서 강의를 들으면서

이건 다시 공부해야겠다.

이 개념은 학교에서 배운 내용이랑 연결되는 것 같은데?

이 부분은 조금 더 찾아봐야겠다.

싶었던 내용들을 계속 메모해두었다.

한국에 돌아온 뒤에는
그 메모와 강의 자료를 다시 하나씩 살펴보면서 공부하고 있다.

그리고 배운 내용을 그냥 혼자 정리하고 끝내기보다는
가능하면 이 블로그에 계속 기록해보려고 한다.

USC에서 배운 내용들을 하나씩 다시 정리해보려고 한다

이번 프로그램에서는 생각보다 정말 다양한 내용을 다뤘다.

Data Science
Data Exploration
Data Preprocessing
Tabular Data
Traditional Machine Learning
Deep Learning for Tabular Data
Representation Learning
LLM for Tabular Data
Tabular Foundation Model
Search Algorithm
A* Search
Clustering
Classification
Regression
Anomaly Detection

짧은 기간 동안 상당히 많은 내용을 빠르게 훑었다.

그래서 수업 당시에는

"아 대충 이런 개념이구나."

정도로 넘어간 부분도 많았다.

하지만 블로그에 글을 쓰려고 다시 자료를 읽어보면
그때는 그냥 지나갔던 내용들이 새롭게 보이기도 한다.

그리고 내가 잘못 이해했던 부분도 꽤 발견된다.

개인적으로 블로그에 글을 쓰는 이유도 이것 때문이다.

누군가에게 설명하기 위해 글을 쓰다 보면
내가 정확하게 이해하지 못한 부분이 어디인지 바로 드러난다.

알고 있다고 생각함
↓
글로 설명해보려고 함
↓
설명이 안 됨
↓
다시 공부함
↓
조금 더 제대로 이해함

이 과정이 생각보다 공부에 도움이 많이 된다.

그래서 앞으로 USC에서 배운 내용들도
가능한 한 하나씩 다시 정리해서 올릴 예정이다.

데이터 사이언스를 전공하지 않기 때문에 더 재미있었던 것 같다

나는 데이터 사이언스를 전공하고 있는 것은 아니다.

그래서 처음에는

"내가 이 내용을 얼마나 이해할 수 있을까?"

라는 걱정도 조금 있었다.

하지만 오히려 내가 평소 공부하던 분야와 다른 내용을 배우다 보니
새롭게 연결되는 부분들이 많았다.

예를 들어 Search Algorithm 수업에서는

BFS
DFS
Greedy
A*

같은 내용이 등장했는데,

이건 학교의 컴퓨팅 문제와 알고리즘 과목이나
코딩테스트를 준비하면서 계속 공부하던 내용이었다.

반대로 Tabular Data나 Feature Engineering,
Anomaly Detection 같은 내용은 상대적으로 생소했다.

그래도 결국 문제를 해결하기 위해

데이터를 어떻게 표현할 것인가?
어떤 알고리즘을 사용할 것인가?
어떤 기준으로 결과를 평가할 것인가?
어떻게 시스템에 적용할 것인가?

를 고민한다는 점에서는
소프트웨어 개발과 크게 다르지 않다는 생각도 들었다.

가장 좋았던 것은 새로운 분야를 직접 접해봤다는 것

이번 프로그램을 통해 갑자기

"나는 앞으로 데이터 사이언티스트가 되어야겠다."

라는 생각이 든 것은 아니다.

내가 앞으로 어떤 개발자가 되고 싶은지는 여전히 비슷하다.

다만 이번 경험을 통해
내가 사용할 수 있는 도구가 하나 더 늘어난 느낌이다.

예전에는 어떤 문제를 보면

서버를 어떻게 만들까?
데이터베이스를 어떻게 설계할까?
어떤 알고리즘을 사용할까?

정도를 먼저 생각했다면,

이제는 여기에

이 데이터에는 어떤 패턴이 있을까?
이 문제를 머신러닝으로 해결할 수 있을까?
어떤 Feature가 중요할까?
데이터를 어떻게 수집해야 할까?

같은 질문도 조금씩 추가될 것 같다.

결국 개발자는 문제를 해결하는 사람이고,
문제를 해결할 수 있는 방법을 많이 알고 있을수록 선택지도 많아진다고 생각한다.

그런 의미에서 이번 USC 프로그램은
내가 기존에 잘 알지 못했던 영역을 직접 경험해본 시간이었다.

다시 갈 수 있다면?

간다.

ㅋㅋㅋㅋㅋㅋㅋㅋ

수업도 좋았고,
LA에서 생활했던 것도 좋았고,
좋은 사람들을 만난 것도 좋았다.

특히 대학생일 때 이런 프로그램을 경험해볼 수 있다는 것 자체가
생각보다 큰 행운이라는 생각이 들었다.

물론 미국 물가는 사악하고,

환율
+
외식비
+
교통비

를 볼 때마다 정신이 아찔했지만...

그래도 다시 기회가 생긴다면
망설이지 않고 갈 것 같다.

마지막으로

처음 USC에 도착했을 때는

"2주 동안 뭘 얼마나 할 수 있을까?"

라는 생각을 했다.

그런데 돌아와서 사진과 메모를 정리해보니
생각보다 정말 많은 것들이 남아 있었다.

새로운 공부
새로운 사람들
해커톤
LA에서의 생활
여행
그리고 수많은 사진들

아마 시간이 더 지나면
세세한 기억들은 조금씩 흐려질 것이다.

그래서 더더욱 지금 기록해두려고 한다.

여행 사진도 그렇고,
수업에서 배운 내용도 그렇고,

내가 그때 무엇을 보고, 무엇을 배우고,
어떤 생각을 했는지를 남겨놓는 것 자체가
나중에는 꽤 좋은 자산이 될 것 같다.

USC에서의 2주 생활기는 여기서 끝!

하지만 USC에서 배운 내용에 대한 글은
앞으로도 계속 올라올 예정이다.

여행은 끝났지만 공부는 이제부터.

강의에서 배운 내용들을 하나씩 다시 공부하면서
잘 정리해서 이 블로그에 계속 기록해보려고 한다.

🇺🇸 USC 시리즈는 계속됩니다 🇺🇸

이번 글은 강의 이야기는 잠깐 내려놓고,
USC에서 보낸 첫 일주일의 일상을 간단하게 기록해보려고 한다.

학교 구경도 하고, LA 시내도 돌아다니고,
친구들과 밥도 해먹고, 마지막에는 해커톤까지...

사진을 다시 보니까 짧은 시간 동안 정말 이것저것 많이 하고 다녔다.

USC 캠퍼스 구경

서던 캘리포니아 대학교 로고....

멋지다.

확실히 학교 곳곳에 USC 특유의 색깔이 있어서
그냥 돌아다니는 것만으로도 미국 대학에 왔다는 느낌이 났다.

학교 중간에 있는 탑(?)인데
딱 봐도 뭔가 상징성이 있어 보였다.

캠퍼스 건물들도 전체적으로 분위기가 비슷해서
학교를 돌아다니는 재미가 꽤 있었다.

학교 안의 고요한 모습.

사람이 없는 시간대에 돌아다니면
캠퍼스가 정말 조용하다.

그리고 내가 생각했던 미국 대학 느낌 그 자체.

넓은 잔디
+
서구적인 건물
+
야자수
+
LA의 날씨

영화에서만 보던 미국 대학 느낌이 정말 이런 건가 싶었다.

사진만 봐도 느좋...

학교 건물 중앙 쪽으로 오면
이렇게 시야가 뻥 뚫린 공간도 나온다.

날씨까지 좋아서 그냥 아무 데나 앉아 있어도 좋았다.

LA는 날씨가 진짜 사기다.

USC 안에서 만난 도산 안창호 선생님의 흔적

그리고 캠퍼스를 돌아다니다가 발견한 곳.

도산 안창호 하우스.

미국 대학 캠퍼스를 돌아다니다가
한국 독립운동가의 이름을 만나니까 느낌이 묘했다.

<도산 안창호 하우스 간판>

감사합니다.

미국에서의 첫 점심은 Chick-fil-A

첫날 점심은 친구들과 칙필레로 갔다.

치킨버거로 유명한 곳인데
딱 생각하는 미국 치킨버거 맛이다.

나는 워낙 많이 먹어봐서...

미국 3회차라...

대충 어떤 맛일지 예상이 갔다.

그냥 무난하게 맛있었다.

그리고 LA 시내로

첫날 학교 투어를 마치고
친구들과 그랜드 센트럴 마켓으로 향했다.

<가는 길에 찍은 건물들>

뭔가 여의도랑 비슷했다.

여기에 NH투자증권 간판 하나만 붙어 있으면 딱일 듯...

그리고 라라랜드에 나온 그 열차!

영화에서 봤던 장소를 실제로 보니까
괜히 신기했다.

LA 시내에 처음 나온 날이라
LA뽕 한가득 차서 이런 것도 열심히 찍고 다녔다.

지금 보면

내가 저걸 왜 찍었지?

싶은 사진도 많은데,

그때는 그냥 모든 게 신기했다.

Grand Central Market

그랜드 센트럴 마켓 내부!

분위기 있다.

여러 음식점이 한곳에 모여 있어서
구경하는 재미도 꽤 있었다.

이탈리아식 피자를 만들어주시는 주인장.

이런 게 또 미국 시장 구경하는 맛이지...

Hollywood Sign도 갔다

헐리우드 사인도 갔다.

사실 가기 전에는

"그냥 산에 HOLLYWOOD 써있는 거 아닌가?"

싶었다.

근데 실제로 가보니까 생각보다 좋았다.

LA 풍경이랑 헐리우드 사인을 같이 보고 있으니까
진짜 영화 속에 들어와 있는 느낌이었다.

사진으로 보는 것보다 직접 보는 게 훨씬 좋았던 곳.

USC 기숙사 생활 꿀팁

그리고 USC 기숙사에서 생활한다면
개인적으로 이건 꿀팁이다.

기숙사 바로 앞 USC Village 안에
Trader Joe's와 Target이 있다.

생각보다 식재료가 그렇게 비싸지 않았다.

특히

소고기
주스
빵
과일
치킨

같은 것들은 외식하는 것과 비교하면 확실히 저렴하다.

그래서 기숙사에서 요리할 수 있다면
치킨 윙이나 고기를 사서 직접 해먹는 것을 추천한다.

단,

냄비와 프라이팬은 필수.

우리 기숙사 친구들은 조리도구를 꽤 잘 챙겨와서
다 같이 이것저것 엄청 해먹었다.

미국은 외식비가 비싸기 때문에
이게 생각보다 생활비를 많이 아껴준다.

그리고 소고기 스테이크가 10달러!

말이 돼?

외식 한 번 할 돈이면
기숙사에서 고기를 몇 번을 구워 먹을 수 있다.

그리고 대망의 해커톤

그리고 대망의 해커톤 날...

우리 팀은 주제를 조금 늦게 정했다.

그만큼 개발 시작도 늦어졌고,

"이거 시간 안에 완성할 수 있나?"

라는 걱정을 계속하면서 개발했다.

그래도 어떻게든 범위를 줄이고 개발을 이어가면서
제출 약 1시간 전에 MVP를 완성했다.

진짜 겨우 마무리...

해커톤 이야기는 프로젝트 내용까지 들어가면 길어질 것 같아서
별도의 글에서 제대로 정리해볼 예정이다.

해커톤을 끝내고

그리고 찍은 단체사진!

사진을 보니까
그때 정신없이 개발하던 게 다시 생각난다.

해커톤을 마치고 나면
이렇게 USC 인증 증서도 준다.

이건...

액자에 걸어놔야지.

USC에서의 첫 일주일을 마치며

이렇게 USC에서 보낸 첫 일주일을
사진과 함께 간략하게 정리해봤다.

USC 캠퍼스 구경
↓
LA 시내 구경
↓
Grand Central Market
↓
Hollywood
↓
기숙사에서 열심히 해먹기
↓
그리고 해커톤

사진을 모아서 다시 보니까
일주일 동안 생각보다 정말 많은 것을 하고 다녔다.

강의를 들으러 미국에 왔지만
강의실 밖에서 보고 경험했던 것들도 꽤 기억에 많이 남는다.

특히 영화에서만 보던 미국 대학 캠퍼스에서 생활하고,
수업이 끝나면 친구들과 LA를 돌아다니고,
기숙사에 돌아와서는 같이 밥을 해먹던 일상이 꽤 재미있었다.

그리고 첫 주의 마지막은 해커톤으로 아주 제대로 불태웠다...

2주 차에는 또 다른 일정들이 기다리고 있었으니,

Coming Soon...

문제풀이 시간 : 20분

오늘의 코테 연습문제는 프로그래머스의
명예의 전당 (1) 문제다.

문제 링크는 아래와 같다.

https://school.programmers.co.kr/learn/courses/30/lessons/138477?language=cpp

문제 설명

"명예의 전당"이라는 TV 프로그램에서는 매일 한 명의 가수가 노래를 부르고,
시청자들의 문자 투표수에 따라 점수를 받는다.

매일 새로운 점수가 들어왔을 때
지금까지 등장한 점수 중 상위 K개의 점수만 명예의 전당에 유지한다.

그리고 매일 발표해야 하는 값은

현재 명예의 전당에 올라가 있는 점수들 중 가장 낮은 점수

다.

예를 들어

k = 3

score = [10, 100, 20, 150, 1, 100, 200]

라면 매일 발표되는 점수는

[10, 10, 10, 20, 20, 100, 100]

이 된다.

제한 사항

3 ≤ k ≤ 100

7 ≤ score의 길이 ≤ 1,000

0 ≤ score[i] ≤ 2,000

처음 문제를 봤을 때

문제를 읽고

"이거 생각보다 너무 쉬운데?"

라는 생각이 들었다.

처음에는 queue, priority_queue가 바로 떠올랐다.

그런데 문제의 입력 크기를 보니
일반 vector를 이용해서 정렬해도 충분히 풀 수 있겠다는 생각이 들었다.

문제를 다시 아주 단순하게 정리하면 다음과 같다.

매일 지금까지 나온 점수 중 상위 K개를 기준으로,
그 K개 중 가장 낮은 점수를 출력하라.

처음 K명이 다 차기 전까지는
지금까지 등장한 점수 중 최솟값을 출력하면 된다.

현재까지 나온 사람 수 ≤ K
→ 지금까지 점수 중 최솟값

그리고 K명보다 많은 사람이 등장한 이후부터는
전체 점수를 오름차순으로 정렬했을 때

rank.size() - k

번째 원소가 현재 상위 K개 중 가장 작은 점수가 된다.

예를 들어

score = [10, 20, 100, 150]

정렬 후
[10, 20, 100, 150]

k = 3

이라면 상위 3개는

20, 100, 150

이고,

rank.size() - k

= 4 - 3
= 1

이므로

rank[1] = 20

을 출력하면 된다.

아이디어는 단순했다.

곧바로 구현에 들어갔다.

나의 풀이

#include <bits/stdc++.h> 
using namespace std;

vector<int> solution(int k, vector<int> score) { 
    // 명예의 전당 목록의 점수의 개수 K,
    // 1일부터 마지막 날까지 출연한 가수들의 점수인 score,
    // 결과물은 그 날의 가장 최하위 점수
    vector<int> answer;

    // 1단계: 먼저 rank 라는 vector를 만든다.
    // 그리고 K보다 작을 경우의 로직까지 설계 (가장 최하위만 return)
    vector<int> rank; 

    for (int x : score) {

        rank.push_back(x); // score에 있는 숫자를 rank로 하나씩 넣은 후
        sort(rank.begin(), rank.end()); // 정렬까지 맡는다

        // case 1) : k보다 작을 때는 그냥 sort로 정렬 후
        // 0번째에 있는 숫자를 넣으면 간단
        if (rank.size() <= k) {
            answer.push_back(rank[0]); 
            continue; 
        }

        // case 2) : 현재 rank는 오름차순으로 정렬되어 있음.
        // 즉 rank.size() - k 위치가
        // 현재 상위 k개의 점수 중 가장 작은 숫자임
        answer.push_back(rank[rank.size() - k]);    
    }

    return answer;
}

결과는?

정답이었다.

생각보다 쉽게 풀려서 조금 당황했지만...

그래... 이게 레벨 1이지...

라는 생각도 들었다.

하지만 문제를 맞히고 나서 코드를 다시 보니
효율성 측면에서는 꽤 아쉬운 부분이 있었다.

문제는 매번 정렬한다는 것

핵심은 이 부분이다.

for (int x : score) {

    rank.push_back(x);
    sort(rank.begin(), rank.end());

매일 새로운 점수가 하나 들어올 때마다
rank 전체를 다시 정렬하고 있다.

예를 들어 점수가 총 N개라면
정렬되는 배열의 크기는 다음처럼 증가한다.

1개 정렬
2개 정렬
3개 정렬
...
N개 정렬

각 정렬 비용은 대략

1 log 1
2 log 2
3 log 3
...
N log N

이 된다.

따라서 전체 연산량은

Σ i log i

형태가 되고,

Big-O로 보면 대략

O(N² log N)

으로 볼 수 있다.

물론 이 문제에서는

N ≤ 1,000

이라 충분히 통과한다.

하지만 생각해보면 조금 이상하다.

문제에서 우리가 실제로 필요한 것은

지금까지 등장한 모든 점수

가 아니다.

필요한 것은 오직

현재 상위 K개의 점수

뿐이다.

즉 굳이 모든 점수를 계속 저장하고
매번 전체를 다시 정렬할 필요가 없는 것이다.

더 나은 자료구조는 없을까?

여기서 처음 문제를 읽었을 때 떠올렸던
Priority Queue가 다시 등장한다.

우선순위 큐는 일반 Queue처럼

먼저 들어온 값

을 먼저 꺼내는 것이 아니라,

우선순위가 가장 높은 값

을 먼저 꺼낼 수 있는 자료구조다.

C++의 priority_queue는 기본적으로 Max Heap으로 동작한다.

priority_queue<int> pq;

즉 가장 큰 값이 top()에 위치한다.

하지만 이번 문제에서는
명예의 전당 상위 K명 중

가장 작은 점수

를 계속 알아야 한다.

따라서 필요한 것은 Min Heap이다.

왜 Min Heap이 필요한가?

명예의 전당에 다음 점수들이 있다고 해보자.

20
100
150

여기서 우리가 매일 발표해야 하는 점수는

20

이다.

그리고 새로운 점수

200

이 들어오면

20
100
150
200

중 상위 3명만 남겨야 한다.

즉 가장 작은 값인

20

을 제거하면 된다.

결과는

100
150
200

이다.

다시 말하면 매번 필요한 연산은

현재 상위 K개 중 최솟값 확인
↓
새로운 점수가 들어옴
↓
K개를 초과하면 최솟값 제거

이다.

이 구조는 Min Heap과 정확히 맞는다.

C++에서 Min Heap 만들기

C++에서는 다음처럼 작성할 수 있다.

priority_queue<int, vector<int>, greater<int>> rank;

처음 보면 굉장히 복잡해 보인다.

하나씩 뜯어보자.

int
→ 저장할 자료형

vector<int>
→ 내부적으로 데이터를 저장할 Container

greater<int>
→ 작은 값을 더 높은 우선순위로 두는 비교 기준

즉,

priority_queue<int, vector<int>, greater<int>>

는

int 값을 저장하고, 가장 작은 값을 top()에서 바로 꺼낼 수 있는 Priority Queue

라고 보면 된다.

Priority Queue를 활용한 풀이

#include <bits/stdc++.h>
using namespace std;

vector<int> solution(int k, vector<int> score) {
    vector<int> answer;

    priority_queue<int, vector<int>, greater<int>> rank;

    for (int x : score) {

        rank.push(x);

        if (rank.size() > k) {
            rank.pop();
        }

        answer.push_back(rank.top());
    }

    return answer;
}

처음 내 코드보다 훨씬 짧아졌다.

코드 흐름을 하나씩 살펴보자

먼저 Min Heap을 만든다.

priority_queue<int, vector<int>, greater<int>> rank;

그리고 하루의 점수를 하나씩 넣는다.

rank.push(x);

아직 K명이 다 차지 않았다면
그냥 계속 넣으면 된다.

예를 들어

k = 3

10 입력
→ [10]

100 입력
→ [10, 100]

20 입력
→ [10, 20, 100]

Min Heap의 top()에는 항상
현재 가장 작은 값이 존재한다.

따라서

rank.top();

을 그대로 발표하면 된다.

K개를 초과하면?

새로운 점수를 넣은 뒤

if (rank.size() > k) {
    rank.pop();
}

을 수행한다.

Min Heap에서는 pop()을 하면
가장 작은 값이 제거된다.

예를 들어

현재 명예의 전당

10
20
100

에

150

이 들어온다고 해보자.

우선 넣는다.

10
20
100
150

크기가 k = 3을 초과했으므로

rank.pop();

을 수행한다.

그러면 가장 작은

10

이 제거된다.

결과적으로

20
100
150

만 남는다.

정확히 상위 3개의 점수만 유지되는 것이다.

현재 최하위 점수는?

Min Heap에는 항상 상위 K개의 점수만 남아 있다.

그리고 그중 가장 작은 값은

rank.top()

이다.

따라서 매일

answer.push_back(rank.top());

만 하면 된다.

정말 문제의 요구사항과 자료구조의 특성이 정확하게 맞아떨어진다.

두 풀이의 차이를 비교해보자

내 첫 번째 풀이는

지금까지의 모든 점수를 저장
↓
매번 전체 정렬
↓
상위 K번째 위치 확인

이었다.

반면 Priority Queue 풀이는

상위 K개의 점수만 저장
↓
가장 작은 점수는 항상 top()
↓
K개를 넘으면 가장 작은 값 제거

이다.

구조 자체가 훨씬 문제의 요구사항에 가깝다.

시간복잡도 비교

첫 번째 풀이

매번 커지는 전체 배열을 다시 정렬한다.

O(N² log N)

정도로 볼 수 있다.

Priority Queue 풀이

Heap에는 최대 K개의 원소만 존재한다.

push()와 pop()은 각각

O(log K)

이다.

이를 N개의 점수에 대해 반복하므로

O(N log K)

가 된다.

그리고 Heap의 크기도 최대 K이므로
공간복잡도는

O(K)

이다.

첫 번째 풀이는 모든 점수를 저장하기 때문에
공간은

O(N)

이 필요하다.

여기서 한 가지 중요한 점

처음에는

"내 코드도 결국 score를 한 번 순회하니까 O(score.size()) 정도 아닌가?"

라고 생각할 수 있다.

하지만 반복문이 한 번 있다고 해서 무조건 O(N)은 아니다.

반복문 안에서 어떤 연산을 하는지도 봐야 한다.

내 코드에서는 매 반복마다

sort(rank.begin(), rank.end());

가 실행된다.

sort() 자체가 배열 크기 M에 대해

O(M log M)

의 시간이 필요하다.

그리고 M이

1, 2, 3, ..., N

으로 계속 커진다.

따라서 단순한

O(N)

순회라고 볼 수 없다.

이번 문제에서 개인적으로 가장 다시 기억해둘 만한 부분이었다.

사실 내 첫 번째 풀이도 실전에서는 나쁘지 않다

그렇다고 첫 번째 풀이가 잘못된 풀이는 아니다.

문제의 제한을 보면

score.size() ≤ 1,000

이다.

따라서 매번 정렬하더라도 충분히 빠르게 통과한다.

코딩테스트에서 가장 중요한 것은 우선

정확하게 풀리는 코드를 제한 시간 안에 작성하는 것

이다.

처음부터 항상 가장 최적화된 풀이만 찾으려고 하다가
문제 자체를 못 푸는 것보다는

1. 먼저 확실한 풀이를 구현한다.
2. 시간복잡도를 확인한다.
3. 필요하다면 더 적절한 자료구조로 개선한다.

라는 접근이 실전에서는 훨씬 현실적이라고 생각한다.

이번에도 내가 처음 떠올린 vector + sort 방식으로
문제를 먼저 해결한 뒤,

"현재 상위 K개만 유지하면 되는데 왜 전체 데이터를 정렬하고 있지?"

라는 질문을 통해 Priority Queue 풀이로 개선할 수 있었다.

문제를 풀고 나서

처음 문제를 읽었을 때는 생각보다 너무 간단해서
그냥 배열을 이용해 바로 풀었다.

실제로 제한사항만 본다면
내 풀이도 충분히 통과하는 코드였다.

하지만 문제를 풀고 나서 다시 보니
이 문제는 Priority Queue를 연습하기 정말 좋은 문제였다.

핵심은 이것이다.

상위 K개만 유지한다.

그리고 그 K개 중
가장 작은 값이 계속 필요하다.

이 문장을 보는 순간

Min Heap

을 떠올릴 수 있어야 한다.

결론

이번 문제를 통해 가져갈 핵심은 크게 세 가지다.

1. 먼저 단순한 풀이로 문제를 해결하는 것도 충분히 좋은 접근이다.

2. 반복문 안에서 sort()를 수행한다면
   단순히 O(N)이라고 생각하면 안 된다.

3. "상위 K개를 계속 유지하면서 그중 최솟값이 필요하다"
   는 문제에서는 Min Heap을 떠올릴 수 있다.

특히 Priority Queue 풀이의 시간복잡도는

O(N log K)

이고,

내 첫 번째 vector + sort 풀이보다
문제의 구조 자체를 훨씬 직접적으로 표현한다.

처음 문제를 풀 때

queue?
priority_queue?
vector?

를 고민하다가 가장 익숙한 vector로 풀었는데,
결과적으로는 Priority Queue를 다시 공부할 좋은 계기가 됐다.

앞으로 코딩테스트에서

최댓값 또는 최솟값을 계속 꺼내야 한다.

상위 K개 또는 하위 K개만 유지해야 한다.

값이 계속 들어오는데 매번 전체 정렬하기에는 비효율적이다.

라는 조건이 보이면
Priority Queue를 먼저 떠올려봐야겠다.

소프트웨어 모델링을 공부하다 보면
UML(Unified Modeling Language)이라는 말을 정말 자주 보게 된다.

그중에서도 이번에 정리할 것은 Activity Diagram이다.

처음 Activity Diagram을 봤을 때는

"그냥 순서도(Flowchart)랑 비슷한 거 아닌가?"

라는 생각이 들었다.

실제로 둘은 꽤 비슷하게 생겼다.

하지만 Activity Diagram은 단순히

A를 하고
↓
B를 하고
↓
C를 한다

정도의 실행 순서만 표현하는 것이 아니다.

조건에 따라 흐름이 나뉘거나,
여러 작업이 병렬적으로 진행되거나,
Action 사이에서 어떤 데이터가 전달되는지까지 표현할 수 있다.

이번 글에서는 Activity Diagram이 무엇인지부터
각 구성 요소가 어떤 역할을 하는지 하나씩 정리해보고자 한다.

Activity Diagram이란?

Activity Diagram은 UML에서

시스템이나 비즈니스 프로세스의 작업 흐름(Workflow)을 표현하는 Diagram

이라고 볼 수 있다.

쉽게 말하면

어떤 일이 시작되고
↓
어떤 작업들이 수행되고
↓
어떤 조건에서 흐름이 나뉘고
↓
어떤 작업들이 동시에 수행되고
↓
어디에서 끝나는가

를 시각적으로 표현하는 것이다.

예를 들어 쇼핑몰의 주문 과정을 생각해보자.

상품 선택
↓
주문서 작성
↓
결제
↓
주문 완료

단순하게 보면 이런 흐름이지만 실제 시스템에서는 조금 더 복잡하다.

상품 선택
↓
주문서 작성
↓
결제 성공?
├─ Yes → 주문 완료
└─ No  → 결제 재시도

주문이 완료된 뒤에는

고객에게 알림 전송
재고 감소
주문 기록 저장

같은 작업들이 동시에 또는 서로 다른 흐름으로 수행될 수도 있다.

Activity Diagram은 이런 전체적인 행동의 흐름을 표현하기 좋다.

Activity Diagram은 언제 그릴까?

Activity Diagram은 특히 다음과 같은 상황에서 유용하다.

1. 비즈니스 프로세스를 표현할 때

예를 들어 쇼핑몰 주문 프로세스가 있다.

상품 선택
↓
주문
↓
결제
↓
배송

이런 Workflow를 개발자뿐만 아니라
기획자나 비개발자와 함께 확인해야 할 때 Activity Diagram이 꽤 직관적이다.

2. Use Case의 내부 흐름을 자세히 표현할 때

Use Case Diagram에서

사용자 → 상품 주문

이라고만 표현하면
"상품 주문" 내부에서 실제로 어떤 일이 일어나는지는 알 수 없다.

Activity Diagram을 사용하면

상품 선택
↓
주문서 작성
↓
결제
↓
결제 성공 여부 확인
↓
주문 완료

처럼 내부 흐름까지 구체화할 수 있다.

3. 복잡한 조건 분기를 표현할 때

프로그램에서 if, else, switch 같은 조건 분기가 많아지면
코드만 보고 전체 흐름을 이해하기 어려울 수 있다.

Activity Diagram에서는 Decision Node를 이용해

결제 성공?
├─ Yes → 주문 완료
└─ No  → 재시도

처럼 표현할 수 있다.

4. 병렬적으로 진행되는 작업을 표현할 때

하나의 작업이 끝난 뒤 여러 일이 독립적으로 진행될 수도 있다.

예를 들어 주문 완료 후

알림 전송
재고 감소
포인트 적립

이 병렬적으로 진행될 수 있다.

이런 흐름은 Fork / Join Node를 이용해서 표현할 수 있다.

Activity Diagram의 구성 요소

Activity Diagram에서 자주 사용하는 구성 요소는 다음과 같다.

Action / Activity
Object Node
Control Flow
Object Flow
Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node

처음 보면 꽤 많아 보인다.

그래서 나는 다음과 같이 묶어서 이해하는 것이 편했다.

실제 작업
→ Action / Activity

흐름
→ Control Flow / Object Flow

데이터
→ Object Node

시작과 종료
→ Initial / Final

조건 분기
→ Decision / Merge

병렬 처리
→ Fork / Join

Action / Activity

가장 먼저 실제로 수행하는 작업을 표현하는
Action이 있다.

예를 들어 다음과 같은 것들이다.

상품을 선택한다.
주문서를 작성한다.
결제를 진행한다.
주문을 취소한다.

보통 Action의 이름은

동사 + 명사

형태로 작성하면 무엇을 수행하는지 이해하기 쉽다.

예를 들어

상품 선택
결제 진행
재고 확인
주문 저장

같은 식이다.

Action과 Activity는 같은 것일까?

처음에는 이 둘이 조금 헷갈렸다.

Diagram에서 비슷한 둥근 사각형 형태로 표현되는 경우가 많기 때문이다.

하지만 개념적으로는 차이가 있다.

Action

Action은 하나의 Activity 안에서 실행되는
더 이상 세분화하지 않고 하나의 실행 단위로 보는 작업이다.

예를 들어

상품 선택
결제 진행
주문 저장

같은 작업이다.

Activity

Activity는 여러 Action이나 다른 제어 흐름을 포함할 수 있는
전체적인 행동 또는 Workflow에 가깝다.

예를 들어

상품 주문

이라는 Activity 안에는

상품 선택
↓
주문서 작성
↓
결제
↓
주문 완료

라는 여러 Action이 포함될 수 있다.

즉,

Activity
→ 전체적인 행동 흐름

Action
→ 그 안에서 수행되는 하나의 실행 단위

정도로 이해하면 편하다.

다만 실제 UML 모델링에서는 Activity 안에 다른 Activity를 호출하는 Action이 존재할 수도 있기 때문에
단순히 "Activity는 큰 것, Action은 작은 것"이라고만 외우기보다

Action은 실행되는 하나의 Node이고, Activity는 전체 Behavior의 흐름을 정의한다

정도로 이해하는 것이 더 정확하다.

Object Node

Object Node는

Activity 안에서 Action이 사용하거나 만들어내는 데이터 또는 객체

를 표현한다.

예를 들어 주문 과정을 생각해보자.

[주문 생성]
      ↓
  주문 정보
      ↓
[결제 처리]

여기에서

주문 정보

가 Object Node다.

즉,

Action
↓
데이터 생성
↓
다른 Action에서 사용

되는 흐름에서
중간의 데이터 자체를 표현한다고 보면 된다.

코드로 생각하면 더 쉽다

예를 들어 Java 코드가 다음과 같다고 해보자.

Order order = createOrder();

pay(order);

createOrder()에서

Order 객체

가 만들어진다.

그리고 그 객체가

pay(order)

에 전달된다.

Activity Diagram에서는 이 order와 같은 객체를
Object Node로 표현할 수 있다.

Control Flow

Control Flow는

Action이 어떤 순서로 실행되는지를 나타내는 화살표

다.

예를 들어

[상품 선택]
      ↓
[주문서 작성]
      ↓
[결제 진행]
      ↓
[주문 완료]

가 있다면
각 Action 사이의 화살표가 Control Flow다.

쉽게 말하면

"다음에 무엇을 실행하지?"

를 표현한다.

Object Flow

Object Flow는 Control Flow와 비슷하게 화살표를 사용하지만
의미가 조금 다르다.

Object Flow는

Object나 Data가 Action 사이에서 어떻게 전달되는지를 나타낸다.

예를 들어

[주문 생성]
      │
      ▼
 ┌─────────┐
 │ 주문 정보 │
 └─────────┘
      │
      ▼
[결제 처리]

이 흐름에서

주문 정보 → 결제 처리

처럼 데이터가 전달되는 흐름이 Object Flow다.

앞에서 봤던 코드로 생각하면

Order order = createOrder();

pay(order);

에서 order 객체가 pay()로 전달되는 흐름이라고 볼 수 있다.

Control Flow와 Object Flow의 차이

Control Node

Activity Diagram에는 작업 자체를 수행하지 않고
Flow를 제어하는 Node들이 있다.

대표적으로 다음 여섯 가지다.

Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node

처음에는 이름이 많아서 헷갈렸는데
세 쌍으로 묶어서 생각하면 상당히 편하다.

시작 / 종료
→ Initial ↔ Final

조건 분기
→ Decision ↔ Merge

병렬 처리
→ Fork ↔ Join

Initial Node

Initial Node는

Activity가 시작되는 지점

이다.

검은색 원으로 표현한다.

●
│
▼
[상품 선택]

즉,

여기서부터 Activity가 시작된다.

라는 의미다.

Final Node

Final Node는

Activity 전체가 종료되는 지점

을 의미한다.

보통 다음과 같이 표현한다.

[주문 완료]
     │
     ▼
     ◉

전체 흐름으로 보면

● 시작
↓
[상품 선택]
↓
[결제]
↓
[주문 완료]
↓
◉ 종료

가 된다.

즉,

Initial Node
→ 시작

Activity Final Node
→ Activity 전체 종료

라고 이해하면 된다.

Final Node에서 하나 주의할 점

UML에는 실제로 종료 Node가 하나만 있는 것은 아니다.

대표적으로

Activity Final Node
Flow Final Node

가 있다.

Activity Final Node

Activity 전체를 끝낸다.

◉

Flow Final Node

해당 Flow 하나만 종료한다.

다른 병렬 Flow는 계속 진행될 수 있다.

처음 Activity Diagram을 배울 때는
대부분 Activity Final을 기준으로 배우지만,

병렬 처리까지 복잡하게 다루게 되면
이 둘을 구분할 필요가 있다.

Decision Node

Decision Node는

조건에 따라 실행 경로를 나누는 Node

다.

마름모로 표현한다.

예를 들어

        ◇ 결제 성공?
       /              [성공]          [실패]
     ↓               ↓
[주문 완료]      [결제 재시도]

와 같이 표현할 수 있다.

프로그래밍에서 생각하면 if-else와 상당히 비슷하다.

Guard Condition

Decision Node에서 분기되는 각 경로에는
보통 Guard Condition을 작성한다.

UML에서는 일반적으로

[조건]

형태로 표시한다.

예를 들어

[결제 성공]
[결제 실패]

처럼 표현할 수 있다.

즉 Decision Node에서 중요한 것은

각 분기 조건이 명확하게 정의되어 있어야 한다

는 것이다.

Merge Node

Merge Node는

여러 개의 대체 경로를 다시 하나의 흐름으로 합치는 Node

다.

예를 들어 결제 방법에 따라 흐름이 나뉜다고 해보자.

           ◇ 결제 방법?
          /               [카드 결제]     [계좌 결제]
          \           /
           \         /
               ◇
               │
               ▼
          [주문 완료]

첫 번째 마름모는

Decision Node

이고,

두 번째 마름모는

Merge Node

다.

모양은 동일하지만 역할은 완전히 다르다.

Decision
→ 하나의 Flow를 여러 대안으로 나눈다.

Merge
→ 여러 대안 Flow를 하나로 합친다.

Fork Node

Fork Node는

하나의 Flow를 여러 개의 병렬적인 Flow로 나누는 Node

다.

굵은 막대로 표현한다.

예를 들어 주문이 완료된 뒤

고객에게 알림 전송
재고 감소

두 작업을 병렬적으로 진행한다고 해보자.

          [주문 완료]
               │
        ━━━━━━━━━━━━━
          │         │
          ▼         ▼
     [알림 전송]  [재고 감소]

가운데 굵은 막대가 Fork Node다.

Decision과 Fork의 차이

Decision

A 또는 B

Fork

A 그리고 B

따라서

Decision
→ OR

Fork
→ AND

라고 기억하면 상당히 편하다.

다만 Fork는 "CPU가 반드시 정확히 같은 순간에 두 작업을 실행한다"는 뜻이라기보다
UML 의미상 서로 독립적으로 진행될 수 있는 Concurrent Flow를 표현한다고 이해하는 것이 더 정확하다.

Join Node

Join Node는 Fork의 반대다.

Fork로 나뉜 여러 Flow가 모두 끝난 뒤 다시 하나의 Flow로 합쳐지는 Node

다.

          [주문 완료]
               │
        ━━━━━━━━━━━━━
          │         │
          ▼         ▼
     [알림 전송]  [재고 감소]
          │         │
          ▼         ▼
        ━━━━━━━━━━━━━
               │
               ▼
        [주문 기록 저장]

위쪽 막대가 Fork,
아래쪽 막대가 Join이다.

정리하면

Fork
→ 여러 Flow를 시작한다.

Join
→ 여러 Flow가 끝날 때까지 기다린 뒤 다음으로 진행한다.

Merge와 Join도 다르다

이 둘 역시

여러 Flow를 하나로 합친다.

라는 점 때문에 헷갈릴 수 있다.

하지만 의미가 다르다.

Merge

여러 경로 중 실제로 실행된 하나의 경로가 들어오면
다음 Flow로 진행한다.

A 또는 B
↓
Merge

Join

여러 병렬 Flow가 모두 끝날 때까지 기다린다.

A 그리고 B
↓
Join

즉,

Merge
→ OR를 다시 합친다.

Join
→ AND를 다시 합친다.

라고 생각하면 된다.

Control Node를 한 번에 정리하면

그리고 세 쌍으로 기억하면 된다.

Initial ↔ Final
시작 / 종료

Decision ↔ Merge
분기 / 병합

Fork ↔ Join
병렬 시작 / 병렬 종료

Activity Diagram을 볼 때 던질 질문

구성 요소를 전부 외우려고 하면
생각보다 헷갈린다.

그래서 나는 각 요소를 다음 질문과 연결해서 기억하려고 한다.

Action
→ "무엇을 하는가?"

Control Flow
→ "다음에 무엇을 하는가?"

Object Node
→ "어떤 데이터가 존재하는가?"

Object Flow
→ "그 데이터가 어디로 이동하는가?"

Decision / Merge
→ "조건에 따라 어디로 갈 것인가?"

Fork / Join
→ "어떤 작업들이 병렬적으로 진행되는가?"

Initial / Final
→ "어디서 시작하고 어디서 끝나는가?"

Activity Diagram과 Flowchart는 무엇이 다를까?

처음 Activity Diagram을 보면
Flowchart와 상당히 비슷해 보인다.

실제로 둘 다

작업
조건
분기
흐름

을 표현한다.

하지만 Activity Diagram은 UML의 일부이기 때문에
소프트웨어 시스템의 Behavior를 모델링하는 데 조금 더 초점이 맞춰져 있다.

특히 다음 요소들을 명확하게 표현할 수 있다.

Object Flow
Concurrent Flow
Fork / Join
Activity / Action
UML의 다른 Diagram과의 연계

그래서 단순한 알고리즘 순서만 표현한다면
Flowchart로도 충분할 수 있다.

하지만

비즈니스 Workflow
Use Case 내부 동작
데이터 전달
병렬 처리
복잡한 시스템 Behavior

를 모델링한다면 Activity Diagram이 더 적합할 수 있다.

언제 Activity Diagram을 그리면 좋을까?

모든 기능마다 Activity Diagram을 그릴 필요는 없다고 생각한다.

예를 들어

getUserName()

처럼 정말 단순한 메서드 하나를 설명하기 위해
Activity Diagram까지 만드는 것은 오히려 과할 수 있다.

Activity Diagram은 다음과 같은 상황에서 특히 가치가 있다.

조건 분기가 많다.

여러 시스템 또는 기능이 연결된다.

작업 순서가 중요하다.

병렬적으로 실행되는 작업이 있다.

데이터 전달 흐름까지 확인해야 한다.

비개발자와 Workflow를 공유해야 한다.

즉,

코드 한 줄 한 줄을 설명하는 Diagram이라기보다
시스템의 행동 흐름 전체를 이해하기 위해 그리는 Diagram

이라고 생각하면 될 것 같다.

정리하면서 느낀 점

처음 Activity Diagram의 구성 요소를 봤을 때는

Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node
Object Node
Object Flow
Control Flow
...

처럼 용어가 너무 많아서
정의를 하나씩 외워야 하나 싶었다.

그런데 실제 Workflow에 적용해서 생각해보니
생각보다 구조는 단순했다.

작업한다.

순서대로 이동한다.

데이터를 전달한다.

조건에 따라 나뉜다.

다시 합친다.

병렬적으로 실행한다.

모두 끝나면 다시 합친다.

종료한다.

결국 우리가 프로그램을 작성하면서
평소 코드로 표현하던 것을 그림으로 바꾼 것에 가깝다.

if
→ Decision

if 종료
→ Merge

병렬 처리
→ Fork

모두 완료될 때까지 대기
→ Join

메서드 실행
→ Action

객체 전달
→ Object Flow

이런 식으로 코드와 연결해서 생각하니
각 Node의 의미가 훨씬 쉽게 들어왔다.

결론

Activity Diagram은

시스템이나 비즈니스 프로세스에서 어떤 작업들이 어떤 순서와 조건으로 수행되는지를 표현하는 UML Behavior Diagram

이라고 정리할 수 있다.

핵심 구성 요소를 다시 압축하면 다음과 같다.

Action / Activity
→ 무엇을 하는가?

Control Flow
→ 다음에 무엇을 하는가?

Object Node / Object Flow
→ 어떤 데이터가 어디로 이동하는가?

Decision / Merge
→ 어떤 조건으로 흐름이 나뉘고 다시 합쳐지는가?

Fork / Join
→ 어떤 작업이 병렬적으로 진행되고 언제 다시 합쳐지는가?

Initial / Final
→ Activity가 어디서 시작하고 어디서 끝나는가?

정의를 달달 외우기보다는
실제 주문 Process 같은 예시를 하나 그려보면서

이건 Action인가?

이 화살표는 Control Flow인가 Object Flow인가?

여기서는 Decision인가 Fork인가?

다시 합칠 때 Merge인가 Join인가?

를 하나씩 판단해보는 것이 훨씬 이해하기 좋은 것 같다.

Activity Diagram을 그리는 목적도 결국 하나다.

코드로 들어가기 전에 시스템의 행동 흐름을 사람이 이해할 수 있는 형태로 만드는 것.

이 관점만 기억하면
각 구성 요소가 왜 필요한지도 자연스럽게 이해할 수 있을 것 같다.

Lesson 3에서는 BFS, DFS, Uniform Cost Search와 같은
기본적인 Search Algorithm에 대해 정리했다.

이번 Lesson 4에서는 여기에서 한 단계 더 나아가
Informed Search를 다룬다.

말 그대로

목표에 대한 추가적인 정보를 가지고 탐색하는 방법

이다.

이번 단원에서도 Greedy Search와 같은 내용은
코딩테스트를 준비하면서 어느 정도 접해본 내용들이라 비교적 익숙했다.

다만 단순히

Greedy = 지금 가장 좋아 보이는 것을 선택한다.

정도로 알고 있었는데,

이번 강의에서는 이를 Heuristic, Best-First Search, 그리고 A* Search까지 연결해서 설명했다.

특히 A* Search는 예전에 알고리즘 수업에서도 이름만 몇 번 들어봤는데,
이번에는

왜 Greedy Search보다 안정적인지
왜 최적해를 찾을 수 있는지
Heuristic은 어떤 조건을 만족해야 하는지

까지 조금 더 자세히 이해할 수 있었다.

그리고 후반부에는

Local Search
Hill Climbing
Simulated Annealing
Local Beam Search
Genetic Algorithm
Gradient Descent / Ascent

까지 다루면서

탐색이라는 개념이 단순한 그래프 경로 탐색을 넘어 최적화 문제까지 연결될 수 있다.

는 것을 보여준다.

Uninformed Search와 Informed Search

먼저 이전 Lesson에서 다뤘던 알고리즘을 생각해보자.

BFS
DFS
Uniform Cost Search

이 알고리즘들은 기본적으로
문제에서 주어진 정보만 가지고 탐색한다.

예를 들어 BFS라면

가장 얕은 Node부터 탐색

하고,

Uniform Cost Search라면

현재까지의 Path Cost가 가장 작은 Node부터 탐색

한다.

그런데 실제로 우리가 목적지에 대한 정보를 조금이라도 알고 있다면 어떨까?

예를 들어 서울에서 부산까지 운전한다고 해보자.

모든 도로를 하나하나 탐색하는 것보다

"부산은 대략 남동쪽에 있다."

라는 정보라도 가지고 있는 편이 훨씬 유리하다.

이러한 추가적인 정보를 탐색에 사용하는 것이
Informed Search다.

Best-First Search

강의에서는 먼저 Best-First Search라는 큰 개념부터 설명한다.

핵심 아이디어는 간단하다.

각 Node에 대해

이 Node가 얼마나 좋아 보이는가?

를 평가하는 함수를 만든다.

이것을 Evaluation Function이라고 한다.

그리고 Frontier에 있는 Node 중

가장 좋아 보이는 Node

를 먼저 탐색한다.

즉,

Frontier
↓
각 Node의 Evaluation Value 계산
↓
가장 좋은 Node 선택
↓
Expand

하는 방식이다.

Best-First Search의 대표적인 두 가지 형태가 바로

Greedy Search
A* Search

다.

Greedy Search

먼저 Greedy Search다.

Greedy라는 단어 그대로

현재 순간 가장 좋아 보이는 선택을 한다.

라는 아이디어다.

코딩테스트에서도 상당히 자주 등장하는 방법이다.

예를 들어 동전을 최소 개수로 사용해서 금액을 만든다고 할 때
특정 조건에서는 가장 큰 동전부터 선택하는 방식이 Greedy가 될 수 있다.

500원
100원
50원
10원

이 있다고 하면

가장 큰 동전부터 사용

하는 방식이다.

Search Problem에서는 조금 다르게 표현한다.

Heuristic이란?

Greedy Search에서는 Heuristic Function이라는 것을 사용한다.

보통

h(n)

이라고 표현한다.

h(n)은

현재 Node n에서 Goal까지 얼마나 비용이 들 것 같은지 추정한 값

이다.

중요한 점은 실제 비용이 아니라 추정값이라는 것이다.

예를 들어 전주에서 서울까지 간다고 생각해보자.

실제 도로를 따라 이동하는 거리는

약 200km

일 수 있지만,

지도에서 직선거리만 계산하면

약 170km

가 나올 수 있다.

이 직선거리를

h(n)

으로 사용할 수 있다.

Romania 예제

강의에서는 이전 Lesson에서도 사용했던
루마니아 도시 문제를 다시 사용한다.

목표는

Arad
↓
Bucharest

로 이동하는 것이다.

이번에는 각 도시에서 Bucharest까지의
Straight-Line Distance, 즉 직선거리를 추가적으로 알고 있다고 가정한다.

예를 들어

Arad → Bucharest 직선거리 = 366

Sibiu → Bucharest 직선거리 = 253

Timisoara → Bucharest 직선거리 = 329

Zerind → Bucharest 직선거리 = 374

같은 정보가 있다.

Arad에서 갈 수 있는 곳이

Sibiu
Timisoara
Zerind

라면 Greedy Search는

h(Sibiu) = 253
h(Timisoara) = 329
h(Zerind) = 374

를 비교한다.

그리고 가장 작은 값인

Sibiu

를 선택한다.

왜냐하면

"현재 기준으로 Bucharest에 가장 가까워 보이는 도시"

이기 때문이다.

Greedy Search의 핵심

Greedy Search는 오직

h(n)

만 본다.

즉,

지금까지 얼마나 왔는가?

는 크게 신경 쓰지 않고

앞으로 Goal까지 얼마나 남았는가?

만 본다.

그래서 평가 함수는 다음과 같다.

f(n) = h(n)

라고 생각할 수 있다.

이 방식의 장점은 분명하다.

Heuristic이 좋다면
쓸데없는 Node를 탐색하지 않고 Goal 방향으로 빠르게 갈 수 있다.

하지만 문제가 있다.

Greedy는 항상 최적일까?

아니다.

Greedy Search는 현재 순간의 선택만 보기 때문에
전체 경로가 최적이라는 보장이 없다.

예를 들어

Start
├── A → Goal
└── B → C → Goal

이라는 경로가 있다고 해보자.

A가 Goal에 훨씬 가까워 보인다고 해서
반드시

Start → A → Goal

의 실제 비용이 작은 것은 아니다.

A로 가는 Edge Cost가 엄청나게 클 수도 있다.

즉,

Goal과 가까워 보인다
≠
전체 비용이 작다

이다.

또한 반복 State를 제대로 처리하지 않는다면
Loop에 빠질 수도 있다.

강의에서도 Greedy Search는 일반적으로

Complete X
Optimal X

라고 설명한다.

다만 finite state space에서 repeated-state checking을 한다면
Completeness를 확보할 수 있다.

그렇다면 지금까지 온 거리도 같이 보면 되지 않을까?

여기에서 A* Search가 등장한다.

Lesson 3에서 다뤘던 Uniform Cost Search는

g(n)

을 사용했다.

g(n)은

Start Node에서 현재 Node까지 실제로 사용한 비용

이다.

반면 Greedy Search는

h(n)

을 사용했다.

g(n)
= 지금까지 실제로 사용한 비용

h(n)
= 앞으로 Goal까지 필요할 것으로 예상되는 비용

그렇다면 두 개를 더하면 어떨까?

f(n) = g(n) + h(n)

바로 이것이 A* Search의 핵심이다.

A* Search

A* Search는

Uniform Cost Search
+
Greedy Search

의 아이디어를 합친 알고리즘이라고 볼 수 있다.

강의에서도 다음과 같이 설명한다.

Uniform Cost Search
→ backward cost g(n)

Greedy Search
→ forward cost h(n)

A*
→ g(n) + h(n)

즉 A*의 평가 함수는

f(n) = g(n) + h(n)

이다.

각각의 의미는 다음과 같다.

g(n)
= Start에서 n까지 실제로 사용한 비용

h(n)
= n에서 Goal까지 예상되는 비용

f(n)
= n을 거쳐 Goal까지 갈 것으로 예상되는 전체 비용

간단한 예시로 이해해보자

자동차 내비게이션을 생각하면 꽤 이해하기 쉽다.

현재까지

전주 → 대전

으로 100km를 이동했다고 하자.

그리고 대전에서 서울까지 남은 거리를
약 150km라고 추정한다면

g(n) = 100
h(n) = 150

이므로

f(n) = 250

이다.

반면 다른 경로에서는

g(n) = 150
h(n) = 80

일 수도 있다.

그러면

f(n) = 230

이다.

A*는 이 둘 중

230

인 경로를 먼저 탐색한다.

즉,

이미 사용한 비용과 앞으로 사용할 것 같은 비용을 동시에 고려한다.

A*가 Greedy보다 좋은 이유

Greedy Search는

h(n)

만 본다.

따라서 목표에 가까워 보인다는 이유만으로
매우 비싼 경로를 선택할 수도 있다.

A*는

g(n) + h(n)

을 보기 때문에

앞으로 얼마나 남았는가?
+
지금까지 얼마나 썼는가?

를 모두 고려한다.

개인적으로 이 부분을 보고

"A*는 Greedy를 조금 더 현실적으로 만든 알고리즘이구나."

라고 이해했다.

A*는 Goal을 발견하면 바로 끝날까?

여기서 중요한 주의점이 하나 있다.

A*에서는 Goal Node를 Frontier에 넣었다고 바로 종료하면 안 된다.

즉,

Goal을 Enqueue
→ 종료 X

이다.

Goal이 Frontier에서 실제로

Dequeue

될 때 종료해야 한다.

왜냐하면 Goal을 처음 발견했더라도
Frontier 안에 더 작은 f(n) 값을 가진 다른 Node가 존재할 수 있기 때문이다.

그 다른 경로를 통해

더 작은 실제 비용으로 Goal

에 도달할 가능성이 있다.

강의의 Romania 예제에서도
Bucharest가 처음 Frontier에 등장한 시점보다

Pitesti

의 f(n) 값이 더 작아서 Pitesti를 먼저 탐색한다.

결국 Pitesti를 거쳐가는 경로가
더 저렴한 Bucharest 경로를 만들어낸다.

A*에서 가장 중요한 것은 Heuristic이다

여기까지 들으면 한 가지 의문이 생긴다.

h(n)

은 그냥 내가 아무렇게나 추정해도 되는가?

그렇지 않다.

A*가 최적해를 보장하기 위해서는
Heuristic이 특정 조건을 만족해야 한다.

이를 Admissible Heuristic이라고 한다.

Admissible Heuristic

실제 n에서 Goal까지의 최소 비용을

h*(n)

이라고 하자.

A*에서 사용하는 Heuristic h(n)은

h(n) ≤ h*(n)

을 만족해야 한다.

쉽게 말하면

실제 비용보다 크게 추정하면 안 된다.

라는 것이다.

이를 강의에서는

optimistic

하다고 표현한다.

조금 낙관적으로 보는 것이다.

왜 비용을 크게 잡으면 안 될까?

예를 들어 실제 Goal까지의 거리가

10

인데

h(n) = 100

이라고 해버렸다고 하자.

그러면 A*는 이 경로를

너무 비싼 경로

라고 판단해 탐색하지 않을 수 있다.

그런데 실제로는 그 경로가 최적 경로일 수도 있다.

즉 Heuristic이 실제 비용을 과대평가하면

좋은 경로를 미리 버릴 수 있다.

그래서 A*에서 사용하는 Heuristic은

실제 비용 이하

여야 한다.

직선거리가 좋은 Heuristic인 이유

Romania 예제에서 사용했던

Straight-Line Distance

는 좋은 예다.

두 도시 사이를 실제 도로로 이동하면
보통 직선거리보다 짧아질 수 없다.

즉,

직선거리 ≤ 실제 도로거리

이다.

따라서 Bucharest까지의 직선거리를 h(n)으로 사용하면
실제 비용을 과대평가하지 않는다.

그래서 Admissible Heuristic이 된다.

8-Puzzle의 Heuristic

강의에서는 8-Puzzle을 이용해서
두 가지 Heuristic을 소개한다.

Lesson 3에서도 나왔던 퍼즐이다.

현재 퍼즐
↓
타일 이동
↓
Goal State

여기에서 대표적인 Heuristic이 두 가지 있다.

h1 : 잘못 놓인 타일의 개수

첫 번째는

h1(n)
= 목표 위치에 있지 않은 Tile의 개수

다.

예를 들어 8개의 Tile 중
6개가 잘못된 위치에 있다면

h1(n) = 6

이다.

각 Tile은 최소 한 번은 움직여야 제자리로 돌아갈 수 있으므로
이 값은 실제 비용을 넘지 않는다.

따라서 Admissible하다.

h2 : Manhattan Distance

두 번째는 Manhattan Distance다.

각 Tile이 현재 위치에서
자신의 목표 위치까지 이동해야 하는

가로 칸 수 + 세로 칸 수

를 계산한다.

예를 들어 한 Tile이

오른쪽 2칸
아래 3칸

을 이동해야 한다면

Manhattan Distance = 5

이다.

그리고 모든 Tile의 Manhattan Distance를 합한다.

강의 예제에서는

h2(S) = 14

가 나온다.

어떤 Heuristic이 더 좋은가?

둘 다 Admissible하다고 해서
성능이 똑같은 것은 아니다.

강의에서는 Dominance라는 개념을 설명한다.

만약 모든 Node에 대해

h2(n) ≥ h1(n)

이고 두 Heuristic 모두 Admissible이라면

h2가 h1을 dominate한다.

고 한다.

왜 더 큰 값이 좋은 걸까?

단,

실제 비용을 넘지 않는 범위

에서는 Goal까지의 실제 비용을 더 정확하게 추정하기 때문이다.

즉,

너무 작게 추정하는 Heuristic

보다

실제 비용에 최대한 가깝게 추정하는 Heuristic

이 탐색할 Node를 더 많이 줄일 수 있다.

강의의 8-Puzzle 예제에서도 Manhattan Distance를 사용했을 때
잘못 놓인 Tile 개수를 사용하는 것보다 탐색 Node 수가 크게 감소한다.

좋은 Heuristic은 Search Cost를 크게 줄인다

이 부분이 꽤 인상적이었다.

Heuristic이 조금만 좋아져도
탐색해야 하는 Node의 개수가 엄청나게 달라질 수 있다.

결국 A*의 성능은

A* 알고리즘 자체

뿐만 아니라

얼마나 좋은 h(n)을 만들 수 있는가?

에 크게 좌우된다.

즉,

A*를 잘 쓰는 핵심은 결국 문제에 적합한 Heuristic을 설계하는 것이다.

여러 Heuristic을 합칠 수도 있다

만약 두 개의 Admissible Heuristic

ha(n)
hb(n)

이 있다면

h(n) = max(ha(n), hb(n))

으로 사용할 수도 있다.

둘 모두 실제 비용을 넘지 않는다면
그중 큰 값을 사용하더라도 여전히 실제 비용을 넘지 않는다.

따라서 새로운 h(n)도 Admissible하다.

그리고 기존 두 Heuristic보다
더 실제 값에 가까운 추정치를 사용할 가능성이 높다.

Relaxed Problem

그렇다면 좋은 Heuristic은 어떻게 만들까?

강의에서는 한 가지 중요한 방법으로
Relaxed Problem을 소개한다.

원래 문제의 조건을 조금 완화한 문제를 만드는 것이다.

예를 들어 8-Puzzle에서는 실제로 Tile이 움직일 수 있는 방법에 제약이 있다.

그런데

Tile이 아무 위치로 이동할 수 있다.

고 조건을 완화하면 문제는 훨씬 쉬워진다.

이 Relaxed Problem에서 구한 최적 비용은
원래 문제의 최적 비용보다 클 수 없다.

Relaxed Problem Cost
≤
Original Problem Cost

따라서 Relaxed Problem의 정확한 Solution Cost를
원래 문제의 Heuristic으로 사용할 수 있다.

TSP에서도 활용할 수 있다

강의에서는 Travelling Salesperson Problem, 즉 TSP도 예로 든다.

TSP는

모든 도시를 한 번씩 방문하면서 총 이동 거리를 최소화하는 문제

다.

굉장히 어려운 최적화 문제다.

하지만 문제의 조건을 완화해서
Minimum Spanning Tree를 계산하면

실제 TSP Tour의 비용보다 작은 Lower Bound

를 얻을 수 있다.

이 값을 Heuristic으로 활용할 수 있다.

A* Search의 특징

강의 자료에서 A*의 특징을 정리하면

Complete: Yes

Optimal: Yes

이다.

물론 앞에서 설명한 것처럼
적절한 Heuristic 조건이 필요하다.

또한 A*는 같은 Heuristic을 사용하는 Optimal Search Algorithm 중
필요 이상으로 많은 Node를 확장하지 않는다는 의미에서
Optimally Efficient하다고 설명한다.

다만 문제가 있다.

A*의 가장 큰 단점, Memory

A*는 Frontier와 탐색한 Node들을 계속 저장한다.

그래서 상태 공간이 매우 커지면

Memory

가 큰 문제가 된다.

Heuristic이 좋아지면 탐색 Node 수를 크게 줄일 수 있지만,
문제가 충분히 크다면 A* 역시 많은 Memory를 요구한다.

즉,

좋은 Heuristic
→ 탐색량 감소

하지만
→ 모든 문제가 갑자기 쉬워지는 것은 아니다.

A*는 어디에 사용될까?

강의에서는 A*의 활용 분야도 여러 개 소개했다.

대표적으로

Video Game
Path Finding
Routing
Resource Planning
Robot Motion Planning
Language Analysis
Machine Translation
Speech Recognition

등이다.

개인적으로 가장 익숙한 것은 역시 게임의 Path Finding이다.

NPC가 장애물을 피해 목적지까지 이동해야 하는 상황에서

현재 위치
↓
A*
↓
목적지까지 효율적인 경로

를 계산할 수 있다.

이제 경로 자체가 중요하지 않은 문제를 생각해보자

여기부터 강의가 조금 다른 방향으로 넘어간다.

지금까지는

Start
↓
...
↓
Goal

이라는 경로가 중요했다.

그런데 어떤 최적화 문제에서는
경로가 별로 중요하지 않다.

중요한 것은

최종 상태 자체

다.

예를 들어 TSP에서는

어떤 과정을 거쳐 이 Tour를 만들었는가?

보다

최종 Tour의 길이가 얼마인가?

가 중요하다.

이러한 문제를 해결하기 위해
Local Search를 사용할 수 있다.

Local Search

Local Search는 현재 State에서 시작해서

주변의 Neighbor State

를 탐색한다.

하지만 기존 Graph Search와 달리
지나온 경로를 모두 저장하지 않는다.

현재 State
↓
Neighbor 평가
↓
더 좋은 State로 이동
↓
다시 Neighbor 평가

를 반복한다.

쉽게 말하면

현재 답을 조금씩 수정하면서 더 좋은 답을 만들어가는 방식

이다.

TSP를 Local Search로 풀어보자

예를 들어 아무 Tour 하나를 만든다.

A → B → C → D → E → A

그리고 두 경로를 서로 바꿔본다.

현재 Tour
↓
일부 Edge 교환
↓
새로운 Tour

새로운 Tour의 비용이 더 작다면
그 상태를 채택한다.

이러한 과정을 반복하면
점점 더 좋은 Solution으로 이동할 수 있다.

n-Queens

Local Search의 또 다른 대표 예제가
n-Queens Problem이다.

체스판 위에 n개의 Queen을 놓는데

같은 Row X
같은 Column X
같은 Diagonal X

가 되도록 해야 한다.

여기에서 Heuristic을

서로 공격 가능한 Queen Pair의 수

라고 정의할 수 있다.

예를 들어

h = 5

라면 충돌이 5개 있다는 뜻이고,

Queen을 하나 이동해서

h = 2

로 만든다.

계속 줄여서

h = 0

이 되면 Solution이다.

Hill Climbing

이 아이디어를 가장 단순하게 구현한 것이
Hill Climbing이다.

강의의 표현이 재미있었다.

"Like climbing Everest in thick fog with amnesia"

안개가 자욱한 에베레스트에서
주변만 보면서 더 높은 곳으로 계속 올라가는 것과 같다.

현재 위치에서 주변을 본다.

현재보다 좋은 Neighbor가 있는가?

있다면 이동한다.

현재 State
↓
가장 좋은 Neighbor
↓
이동
↓
반복

더 좋은 Neighbor가 없다면 종료한다.

Hill Climbing의 문제

문제는 우리가 도착한 곳이
진짜 최고의 지점이라는 보장이 없다는 것이다.

예를 들어

        Global Maximum
           /\
          /  \
    /\   /    \
   /  \_/      \
Local Maximum

같은 공간이 있다고 해보자.

Hill Climbing은 Local Maximum에 도착하면

주변에 더 좋은 곳이 없음

이라고 판단하고 종료할 수 있다.

하지만 멀리 떨어진 곳에는
더 좋은 Global Maximum이 있을 수도 있다.

Random Restart

이 문제를 완화하기 위한 간단한 방법은

다른 위치에서 다시 시작

하는 것이다.

이를 Random-Restart Hill Climbing이라고 한다.

Random Start
↓
Hill Climbing

Random Start
↓
Hill Climbing

Random Start
↓
Hill Climbing

을 반복하면서 더 좋은 Solution을 찾는다.

Simulated Annealing

Local Maximum 문제를 해결하기 위한
더 재미있는 방법도 있다.

바로 Simulated Annealing이다.

핵심 아이디어는

가끔은 일부러 더 나쁜 선택도 허용하자.

이다.

Hill Climbing은 항상

좋아지는 방향

으로만 이동한다.

그런데 그러면 Local Optimum을 빠져나오기 어렵다.

Simulated Annealing은 경우에 따라

나쁜 상태

로도 이동할 수 있게 한다.

왜 일부러 나쁜 선택을 할까?

예를 들어 현재 Local Minimum에 갇혀 있다고 해보자.

     Global Minimum
        \        /
         \      /
      ___ \____/
     /
Local Minimum

Global Minimum으로 가려면
일시적으로 더 높은 비용의 상태를 지나야 할 수도 있다.

Hill Climbing / Descending은 이를 허용하지 않는다.

하지만 Simulated Annealing은 일정 확률로

일시적으로 더 나쁜 상태

를 받아들인다.

그래서 Local Optimum을 빠져나갈 가능성이 생긴다.

Temperature

Simulated Annealing에서는 Temperature T라는 개념을 사용한다.

초반에는 T가 크다.

T가 큼
→ 나쁜 선택도 비교적 자주 허용
→ Exploration

시간이 지나면 T를 점점 줄인다.

T가 작음
→ 나쁜 선택을 거의 허용하지 않음
→ Exploitation

즉,

초반
→ 다양하게 탐색

후반
→ 좋은 지역에 집중

한다.

Machine Learning에서 자주 듣는

Exploration vs Exploitation

의 관계와 비슷하다.

Local Beam Search

Local Search를 하나의 State만 가지고 하지 않고
여러 개의 State를 동시에 유지할 수도 있다.

이것이 Local Beam Search다.

현재 State k개
↓
각 State의 Successor 생성
↓
전체 중 좋은 k개 선택
↓
반복

중요한 것은

독립적인 Search를 k개 돌린다

는 의미가 아니라는 것이다.

모든 Successor를 함께 비교하고
그중 가장 좋은 k개를 선택한다.

그런데 좋은 State들만 남기면 비슷해지지 않을까?

맞다.

계속 좋은 State만 선택하면
결국 k개의 State가 모두 비슷한 Local Optimum에 모일 수 있다.

그래서 좋은 State를 선택할 확률을 높이되
Randomness를 섞는 방법도 사용할 수 있다.

여기에서 강의는 자연스럽게
Genetic Algorithm으로 연결한다.

Genetic Algorithm

Genetic Algorithm은
생물의 자연 선택과 진화를 모방한 알고리즘이다.

핵심은

Population
Selection
Crossover
Mutation
Next Generation

이다.

Representation

먼저 하나의 Solution을
어떤 형태로 표현해야 한다.

Genetic Algorithm에서는 보통 하나의 Solution을

String

으로 표현한다.

예를 들어

1011010011

같은 Binary String을 사용할 수도 있다.

이것을 생물의

Chromosome

처럼 생각하는 것이다.

Population

Solution 하나만 사용하는 것이 아니라
여러 Candidate Solution을 만든다.

Solution 1
Solution 2
Solution 3
Solution 4
...

이 집합을 Population이라고 한다.

초기 Population은 보통 Random하게 생성한다.

Fitness Function

각 Solution이 얼마나 좋은지 평가해야 한다.

이를 Fitness Function이라고 한다.

Fitness가 높다
→ 좋은 Solution

Fitness가 낮다
→ 좋지 않은 Solution

이라고 생각할 수 있다.

Selection

좋은 Solution일수록
다음 Generation에 자신의 정보를 전달할 확률을 높인다.

강의에서는 Roulette Wheel Selection을 예로 든다.

Fitness가 높은 개체일수록
Roulette Wheel에서 더 큰 영역을 차지한다.

따라서 선택될 확률이 높다.

Crossover

선택된 두 Parent를 섞어서
새로운 Child를 만든다.

예를 들어

Parent 1

11011 | 00100

Parent 2

10101 | 11100

이라고 하면

Child 1

11011 | 11100

Child 2

10101 | 00100

처럼 만들 수 있다.

이를 Crossover라고 한다.

한 지점에서 자르면

Single Point Crossover

이고,

두 지점에서 자르면

Two Point Crossover

가 될 수 있다.

Mutation

하지만 Parent끼리 계속 섞기만 하면
Population이 점점 비슷해질 수 있다.

그러면 Local Optimum에 빠질 가능성이 높다.

그래서 아주 작은 확률로 일부 값을 Random하게 변경한다.

예를 들어

101101

에서

101001

로 Bit 하나를 바꾸는 것이다.

이를 Mutation이라고 한다.

Mutation은 Population에 새로운 다양성을 제공한다.

Next Generation

Selection, Crossover, Mutation을 통해
새로운 Candidate Solution을 만든다.

그리고 이들을 다음 Generation으로 사용한다.

Generation 1
↓
Selection
↓
Crossover
↓
Mutation
↓
Generation 2
↓
...

이 과정을 반복한다.

때로는 이전 Generation의 가장 좋은 Solution을
다음 Generation에 그대로 유지시키기도 한다.

이를 Elitism이라고 한다.

결국 Genetic Algorithm도 Search다

처음에는 Genetic Algorithm이
Graph Search와 완전히 다른 내용처럼 보였다.

하지만 강의를 따라가다 보면
결국 이것도

State Space에서 더 좋은 State를 찾는 Search

라는 큰 틀 안에 있다.

단지

BFS / DFS
→ 명확한 Frontier를 탐색

Local Search
→ Neighbor를 이용해 개선

Genetic Algorithm
→ Population을 진화시키며 탐색

이라는 차이가 있을 뿐이다.

마지막은 Continuous State Space

지금까지 대부분의 Search 문제는
State가 명확하게 구분되는 Discrete Space였다.

예를 들어

City A
City B
City C

또는

Puzzle State 1
Puzzle State 2

처럼 구분된다.

그런데 현실에는 Continuous한 문제도 많다.

예를 들어 지도 위에 공항 3개를 어디에 배치할지 결정한다고 해보자.

각 공항의 위치가

(x1, y1)
(x2, y2)
(x3, y3)

라고 하면

총 6개의 Continuous Variable이 존재한다.

Gradient-Based Algorithm

Continuous State Space에서는
Neighbor를 하나하나 생성하기보다 Gradient를 사용할 수 있다.

Gradient는 쉽게 생각하면

현재 위치에서 함수 값이 가장 빠르게 변하는 방향

이다.

값을 최대화하고 싶다면

Gradient Ascent

를 사용하고,

값을 최소화하고 싶다면

Gradient Descent

를 사용할 수 있다.

Gradient Descent

Machine Learning을 조금 공부했다면
정말 자주 보는 이름이다.

예를 들어 Loss Function을 줄이고 싶다고 해보자.

현재 Parameter에서

Loss가 가장 빠르게 증가하는 방향

이 Gradient라면,

그 반대 방향으로 이동한다.

Parameter
↓
Gradient 계산
↓
Gradient 반대 방향 이동
↓
Loss 감소
↓
반복

이것이 Gradient Descent다.

결국 Deep Learning에서 사용하는 Optimization도
큰 관점에서 보면

더 좋은 State를 찾는 Search

라고 볼 수 있다는 점이 인상적이었다.

Lesson 4를 정리하면

이번 Lesson은 사실 꽤 많은 알고리즘을 다루고 있다.

하지만 큰 흐름으로 묶으면 생각보다 단순하다.

먼저

Uninformed Search

에서 벗어나

Heuristic

이라는 추가 정보를 사용한다.

그리고

Greedy Search
→ h(n)

Uniform Cost Search
→ g(n)

A*
→ g(n) + h(n)

으로 연결된다.

그 이후에는 경로 자체보다
최종 상태가 중요한 Optimization Problem으로 확장하면서

Local Search
↓
Hill Climbing
↓
Simulated Annealing
↓
Local Beam Search
↓
Genetic Algorithm

을 다룬다.

마지막으로 Continuous State Space에서는

Gradient Ascent
Gradient Descent

까지 연결된다.

수업을 듣고 나서

이번 Lesson의 앞부분은 꽤 익숙했다.

Greedy Algorithm은 코딩테스트를 준비하면서 자주 접해왔고,
문제를 보고

현재 가장 좋은 선택을 반복해서 해도 되는가?

를 고민하는 과정도 어느 정도 익숙했다.

그런데 이번 강의를 들으면서
Greedy를 단순한 코딩테스트 풀이 기법이 아니라

Heuristic을 이용하는 Search Strategy

라는 관점에서 볼 수 있었다.

특히

Greedy
→ h(n)

Uniform Cost
→ g(n)

A*
→ g(n) + h(n)

이라는 연결이 가장 기억에 남았다.

그동안 A* Search는

"길 찾기에 사용하는 유명한 알고리즘"

정도로만 알고 있었는데,

왜 g(n)과 h(n)을 더하는지 이해하고 나니
알고리즘 구조가 훨씬 자연스럽게 느껴졌다.

또한 Heuristic이 단순히

대충 Goal과 가까운 정도

가 아니라,

A*의 최적성을 보장하기 위해

h(n) ≤ 실제 남은 비용

이라는 조건을 만족해야 한다는 점도 새롭게 정리할 수 있었다.

마무리

Lesson 3에서는

어떤 순서로 State Space를 탐색할 것인가?

를 배웠다면,

Lesson 4에서는

Goal에 대한 정보를 알고 있다면 그 정보를 어떻게 탐색에 활용할 것인가?

를 배웠다고 생각한다.

특히 가장 핵심적인 내용을 하나만 고르라고 한다면
역시 A* Search다.

g(n)
= 지금까지 실제 비용

h(n)
= 앞으로 필요할 것으로 예상되는 비용

f(n)
= g(n) + h(n)

그리고 좋은 Heuristic을 사용하면
불필요한 탐색을 크게 줄이면서도 최적해를 찾을 수 있다.

후반부의 Local Search와 Genetic Algorithm, Gradient Descent까지 보고 나니
Search라는 개념이 생각보다 훨씬 넓다는 것도 알게 되었다.

Graph에서 길을 찾는 것도 Search

최적의 TSP Tour를 찾는 것도 Search

Queen의 배치를 개선하는 것도 Search

Neural Network의 Loss를 줄이는 것도 Search

결국 많은 알고리즘 문제는

수많은 가능한 상태 중에서 더 좋은 상태를 어떻게 효율적으로 찾아갈 것인가?

라는 하나의 질문으로 연결되는 것 같다.

학교에서 컴퓨팅 문제와 알고리즘이라는 과목을 들을 때 배웠던 내용들이 거의 대다수 등장한 단원이었다.

기초적인 그래프 탐색을 시작으로
그래프와 트리의 개념, 그리고 대표적인 탐색 알고리즘인 BFS와 DFS를 다룬다.

그런데 이번 강의에서는 단순히

DFS는 깊게 탐색한다.
BFS는 넓게 탐색한다.

정도에서 끝나지 않았다.

조금 더 근본적인 관점에서

컴퓨터가 어떤 문제를 '탐색 문제'로 바꾸고, 그 안에서 해답을 어떻게 찾아가는가?

를 설명했다.

그리고 BFS와 DFS뿐만 아니라

• Uniform Cost Search
• Depth-Limited Search
• Iterative Deepening Search

와 같은 탐색 전략도 함께 다뤘다.

개인적으로 알고리즘 수업에서 이미 공부했던 내용이라 익숙한 부분도 많았지만,
이번에는 이를 AI의 Problem-Solving Agent 관점에서 바라본다는 점이 재미있었다.

Problem Solving이란 무엇일까?

강의에서는 문제 해결을 굉장히 추상적으로 정의한다.

어떤 문제에는 현재 상태가 있고,

Initial State

우리가 도달하고 싶은 상태가 있다.

Goal State

그리고 현재 상태를 다른 상태로 변화시키는 행동이 존재한다.

Operator / Action

결국 문제 해결이라는 것은

Initial State
↓
Action
↓
State
↓
Action
↓
State
↓
...
↓
Goal State

처럼 초기 상태에서 목표 상태까지 도달할 수 있는 행동의 순서를 찾는 것이라고 볼 수 있다.

예를 들어 길 찾기를 생각해보자.

현재 위치 : 전북대학교
목표 위치 : 전주역

그리고 내가 할 수 있는 행동은

버스를 탄다.
택시를 탄다.
걷는다.

등이 될 수 있다.

컴퓨터 입장에서는 결국

"어떤 행동들을 어떤 순서로 수행해야 목표 상태까지 갈 수 있을까?"

를 찾아내는 것이 문제 해결이다.

강의에서는 특히 가능하면 최소의 연산 또는 최소 비용으로 목표 상태에 도달하는 것을 중요하게 다룬다.

Offline Problem Solving과 Online Problem Solving

여기서 문제 해결 방식도 두 가지로 나눌 수 있다.

Offline Problem Solving

Offline Problem Solving은
실제로 행동하기 전에 해결 방법을 먼저 찾아놓는 방식이다.

문제 분석
↓
해결 경로 탐색
↓
경로 결정
↓
실제 행동

말 그대로 계획을 모두 세운 뒤 움직인다.

예를 들어 내비게이션이 경로를 먼저 계산하고

전북대
→ 백제대로
→ 기린대로
→ 전주역

이라는 길을 알려주는 것과 비슷하다.

강의에서는 이를 약간 재미있게

solution executed "eyes closed"

라고 표현했다.

이미 해결 방법을 알고 있기 때문에
그 계획을 그대로 실행하면 된다는 의미다.

Online Problem Solving

반대로 Online Problem Solving은
환경에 대한 정보를 완전히 알지 못하는 상태에서 행동한다.

행동
↓
새로운 정보 획득
↓
다음 행동 결정
↓
새로운 정보 획득
↓
...

예를 들어 미로 전체 지도를 모르는 상태에서
직접 움직이며 길을 찾는 로봇을 생각하면 된다.

이 경우에는

탐색 → 행동 → 관찰 → 다시 탐색

이 반복된다.

Problem의 종류

강의에서는 문제를 환경에 대한 정보가 얼마나 주어지는지에 따라 여러 종류로 나누었다.

처음에는 용어가 조금 복잡해 보였는데
결국 핵심은

현재 상황을 얼마나 정확하게 알고 있는가?

라고 생각하면 이해하기 쉬웠다.

Single-State Problem

가장 단순한 경우다.

환경이 Deterministic하고 Fully Observable하다.

즉,

현재 내가 어디 있는지 정확히 알고 있고
+
어떤 행동을 했을 때 어떤 결과가 나오는지도 알고 있다.

예를 들어

A → B → C → Goal

이라는 길을 정확하게 알고 있다면

Right
Right
Right

와 같은 행동 Sequence를 만들면 된다.

우리가 코딩테스트에서 일반적으로 풀게 되는
그래프 탐색 문제 대부분은 이런 형태라고 볼 수 있다.

Conformant Problem

이번에는 현재 상태를 정확하게 알 수 없다.

즉 Non-observable 환경이다.

센서가 없어서 내가 정확히 어떤 상태인지 모르지만
그래도 모든 경우를 고려해서 목표에 도달해야 한다.

이때는 단순한 물리적인 State 하나가 아니라

현재 존재할 가능성이 있는 State들의 집합

을 고려하게 된다.

강의에서는 이를 Belief State라고 표현한다.

Contingency Problem

환경이

Nondeterministic
또는
Partially Observable

한 경우다.

행동의 결과가 항상 동일하지 않을 수도 있고
환경의 일부 정보만 관찰할 수도 있다.

따라서 해결 방법도 단순한 하나의 Action Sequence가 아니라

만약 A라면 → 행동 1
만약 B라면 → 행동 2

같은 조건부 계획(Contingent Plan) 또는 Policy가 된다.

즉,

Search
↓
Execution
↓
새로운 정보
↓
Search

가 반복될 수 있다.

Vacuum World

강의에서는 이러한 차이를 설명하기 위해
AI 분야에서 자주 등장하는 Vacuum World 예제를 사용했다.

청소기가 두 공간을 이동하면서
먼지를 제거하는 매우 단순한 환경이다.

청소기가 수행할 수 있는 행동은

Left
Right
Vacuum
NoOp

정도다.

목표는 단순하다.

모든 공간에 먼지가 없는 상태

이다.

Single-State Problem이라면 현재 청소기 위치와
먼지가 어디 있는지 모두 알고 있으므로

Right
Vacuum

같은 명확한 해결 방법을 만들 수 있다.

하지만 현재 위치나 먼지의 위치를 알 수 없다면
가능한 모든 상태를 고려해야 한다.

그리고 환경이 불확실하다면

Right
if dirt then Vacuum
Left
if dirt then Vacuum
...

처럼 조건에 따라 행동을 결정해야 한다.

결국 같은 청소 문제라도

환경에 대한 정보를 얼마나 알고 있느냐에 따라 문제의 형태가 완전히 달라진다.

그렇다면 문제를 어떻게 표현할까?

이제부터가 그래프 탐색과 직접적으로 연결되는 부분이다.

강의에서는 하나의 Single-State Problem을 네 가지 요소로 정의한다.

1. Initial State
2. Successor Function
3. Goal Test
4. Path Cost

하나씩 살펴보자.

1. Initial State

탐색이 시작되는 상태다.

예를 들어 루마니아의 도시 간 길 찾기 문제에서

현재 위치 = Arad

라면

Initial State = Arad

가 된다.

2. Successor Function

현재 상태에서
다음으로 이동할 수 있는 상태들을 정의한다.

예를 들어 Arad에서 직접 갈 수 있는 도시가

Zerind
Sibiu
Timisoara

라면

S(Arad)
=
{Zerind, Sibiu, Timisoara}

정도로 생각할 수 있다.

즉,

현재 상태에서 어떤 행동을 수행할 수 있으며 그 결과 어떤 상태가 되는가?

를 정의한다.

코딩테스트에서 그래프의 인접 노드를 찾는 것과 거의 같다.

3. Goal Test

현재 상태가 우리가 원하는 목표인지 검사한다.

예를 들어 목적지가 Bucharest라면

현재 도시 == Bucharest ?

를 검사하면 된다.

이처럼 목표가 정확한 하나의 상태로 주어질 수도 있고,

청소기 문제처럼

모든 먼지가 제거되었는가?

처럼 조건 형태로 정의될 수도 있다.

4. Path Cost

목표까지 이동하는 데 필요한 비용이다.

예를 들어 도시 간 이동에서는

거리

가 비용이 될 수 있다.

반면 퍼즐에서는

한 번 이동 = 비용 1

이라고 정의할 수도 있다.

그러면 전체 경로 비용은

각 이동 비용의 합

이 된다.

결국 우리가 원하는 것은 단순히 Goal에 도착하는 경로가 아니라
경우에 따라서는

Goal까지 가는 경로 중 가장 비용이 작은 경로

일 수 있다.

State Space, Problem Space

이제 문제를 그래프로 표현할 수 있다.

강의에서는 이를 State Space, 또는 Problem Space라고 부른다.

State Space는 결국 하나의 Graph다.

Node
→ 문제에서 가능한 State

Edge
→ 한 State에서 다른 State로 이동할 수 있는 Action

예를 들어

A → B → C
     ↓
     D → Goal

이라는 구조가 있다면

A, B, C, D, Goal은 각각 State이고
화살표는 가능한 Action을 의미한다.

즉,

문제를 그래프로 바꾸고, 그래프에서 Initial State부터 Goal State까지의 경로를 찾는 것

이 Search Problem이라고 볼 수 있다.

Romania Route Finding

강의에서는 이러한 구조를 설명하기 위해
루마니아의 도시 지도를 사용한다.

예를 들어 현재 위치가

Arad

이고 목적지가

Bucharest

라고 해보자.

그러면 문제를 다음과 같이 정의할 수 있다.

Initial State
= Arad

States
= 각 도시

Actions
= 연결된 도시로 이동

Goal
= Bucharest

Path Cost
= 도시 간 거리

그러면 문제는 완전히 그래프 탐색 문제가 된다.

Arad
↓
Sibiu
↓
Fagaras
↓
Bucharest

같은 경로를 찾을 수 있다.

물론 이 경로가 항상 가장 짧은 경로라는 의미는 아니다.

이후 어떤 Search Strategy를 사용하느냐에 따라
찾게 되는 경로가 달라질 수 있다.

8-Puzzle도 결국 Graph 문제다

다음 예제는 8-Puzzle이다.

3×3 칸 안에서 하나의 빈칸을 이동시키면서
숫자를 목표 배열로 만드는 퍼즐이다.

처음 보면 그래프와 별로 관련이 없어 보인다.

하지만 이것도 State Space로 표현할 수 있다.

하나의 퍼즐 배치를

State

라고 생각한다.

그리고 빈칸을

Left
Right
Up
Down

으로 움직이는 것을 Action으로 생각한다.

그러면

현재 퍼즐
↓
빈칸 이동
↓
새로운 퍼즐

이 된다.

즉 각각의 퍼즐 배치가 Node이고
한 번의 이동이 Edge인 거대한 Graph가 만들어진다.

Goal Test는

현재 퍼즐 == 목표 퍼즐

이고,

한 번 움직일 때 비용을 1이라고 두면

Path Cost = 이동 횟수

가 된다.

처음에는 완전히 다른 문제처럼 보이지만
추상화하고 나면 결국 같은 그래프 탐색 문제라는 점이 재미있다.

Graph란 무엇인가?

여기서 그래프의 기본 개념도 다시 다뤘다.

그래프는 크게

Node(Vertex)
Edge

로 구성된다.

Node는 하나의 State를 나타내고
Edge는 Node 사이의 연결 관계를 의미한다.

강의에서는 주로 Directed Graph를 기준으로 설명한다.

A → B

가 있다고 해서 반드시

B → A

가 존재하는 것은 아니다.

그리고 연결된 Node들을 따라가는 순서를 Path라고 한다.

예를 들어

A → B → C → D

가 하나의 Path다.

Edge가 3개이므로 이 경로의 길이는 3이고
포함된 Node의 개수는 4개다.

Search Graph와 Search Tree는 다르다

여기에서 개인적으로 다시 한번 정리할 만했던 부분이 있었다.

바로

State Space Graph

와

Search Tree

의 차이다.

State Space Graph에서는
하나의 State는 기본적으로 한 번만 존재한다.

하지만 Search Tree에서는 같은 State가 여러 번 등장할 수 있다.

왜냐하면 Search Tree의 Node는 단순히 State 하나를 표현하는 것이 아니라

그 State에 도달하기까지의 전체 경로

를 표현하기 때문이다.

예를 들어

S → A → C

와

S → B → C

가 있다고 해보자.

State Space Graph에서는 C라는 Node가 하나만 존재한다.

하지만 Search Tree에서는

S-A-C

S-B-C

라는 서로 다른 경로가 있기 때문에
C가 두 번 등장할 수 있다.

따라서 Search Tree에는 상당히 많은 중복 구조가 생길 수 있다.

State Node와 Tree Node도 다르다

State 자체와
Search 과정에서 사용하는 Tree Node도 구분해야 한다.

State는 말 그대로

현재 세계의 상태

다.

하지만 Tree Node는 탐색 알고리즘을 수행하기 위해 사용하는 자료구조이기 때문에
다음과 같은 정보도 가지고 있을 수 있다.

State
Parent
Children
Depth
Path Cost
Action

즉,

State ≠ Search Tree Node

라고 이해하면 된다.

Search의 핵심, Frontier

Search Algorithm에서 매우 중요한 개념이 하나 등장한다.

바로 Frontier, 또는 Fringe다.

Frontier는

아직 탐색해야 할 후보 Node들의 집합

이라고 생각하면 된다.

탐색 과정을 굉장히 단순하게 표현하면 다음과 같다.

Start Node를 Frontier에 넣는다.

while Frontier가 비어있지 않다면

    Frontier에서 Node 하나를 선택한다.

    Goal인지 확인한다.

    Goal이라면 종료한다.

    아니라면 Neighbor들을 Frontier에 넣는다.

여기서 정말 중요한 부분은

Frontier에서 "어떤 Node를 먼저 선택할 것인가?"

이다.

이 선택 방식이 바로 Search Strategy가 된다.

Search Strategy를 평가하는 기준

탐색 알고리즘은 단순히

답을 찾았는가?

만으로 평가하지 않는다.

강의에서는 네 가지 기준을 사용한다.

Completeness

해답이 존재한다면 반드시 찾을 수 있는가?

Time Complexity

얼마나 많은 Node를 생성하고 탐색해야 하는가?

Space Complexity

얼마나 많은 Node를 메모리에 저장해야 하는가?

Optimality

찾은 답이 최소 비용의 최적해인가?

이 네 가지 기준으로
각 탐색 알고리즘의 특징을 비교할 수 있다.

Uninformed Search

이번 강의에서 다루는 탐색 전략은
주로 Uninformed Search다.

말 그대로 추가적인 정보 없이
문제 정의에 주어진 정보만으로 탐색한다.

대표적인 방법은 다음과 같다.

Breadth-First Search
Uniform-Cost Search
Depth-First Search
Depth-Limited Search
Iterative Deepening Search

BFS : Breadth-First Search

먼저 코딩테스트에서 정말 자주 등장하는 BFS다.

BFS는

가장 얕은 Node부터 탐색한다.

예를 들어 다음 Tree가 있다고 해보자.

        A
      /   \
     B     C
    / \   / \
   D   E F   G

BFS의 탐색 순서는

A
↓
B, C
↓
D, E, F, G

가 된다.

즉,

A → B → C → D → E → F → G

처럼 Level 단위로 탐색한다.

BFS는 왜 Queue를 사용할까?

BFS에서는 먼저 들어온 Node를 먼저 탐색해야 한다.

따라서 FIFO(First In First Out) 구조가 필요하다.

바로 Queue다.

Queue

A 삽입

A 제거
B, C 삽입

B 제거
D, E 삽입

C 제거
F, G 삽입

이런 방식으로 탐색한다.

그래서 BFS 구현을 보면 거의 항상

queue<Node> q;

가 등장한다.

BFS의 장점

BFS의 가장 중요한 특징은

Edge의 비용이 모두 같다면 최단 경로를 찾을 수 있다는 것

이다.

예를 들어 모든 이동 비용이 1이라면

한 번 이동
두 번 이동
세 번 이동
...

순서로 탐색하기 때문에
Goal을 처음 발견했을 때의 경로가 가장 짧다.

그래서

미로 최단 거리
게임 맵 최단 거리
최소 이동 횟수

같은 문제에서 BFS를 많이 사용한다.

최근 프로그래머스의 게임 맵 최단거리 문제를 풀면서
DFS로 접근했다가 효율성 테스트에서 시간 초과가 났던 이유도 이것과 연결된다.

최단 경로를 찾는 문제인데 모든 경로를 끝까지 확인하려고 했던 것이다.

BFS의 단점

문제는 Memory다.

BFS는 같은 Level의 Node들을 모두 Frontier에 저장해야 한다.

Branching Factor를 b, 가장 가까운 해답의 깊이를 d라고 하면
탐색해야 하는 Node의 수는 대략 지수적으로 증가한다.

1
+ b
+ b²
+ b³
+ ...
+ bᵈ

따라서 시간뿐만 아니라
메모리 사용량이 매우 커질 수 있다.

강의에서도 BFS에서 특히 Space Complexity가 큰 문제라고 강조했다.

DFS : Depth-First Search

다음은 DFS다.

DFS는 BFS와 완전히 반대다.

현재 갈 수 있는 곳까지 최대한 깊게 들어간다.

예를 들어 같은 Tree가 있다고 해보자.

        A
      /   \
     B     C
    / \   / \
   D   E F   G

더 아래에 Node가 존재한다고 가정하면
DFS는 대략

A
↓
B
↓
D
↓
D의 자식
↓
...

처럼 한쪽 끝까지 내려간다.

더 이상 갈 곳이 없으면 다시 돌아와
다른 경로를 탐색한다.

DFS는 왜 Stack을 사용할까?

DFS에서는 가장 최근에 발견한 Node를 먼저 탐색한다.

따라서

LIFO
Last In First Out

구조가 적합하다.

즉 Stack이다.

그리고 재귀 함수도 내부적으로 Call Stack을 사용하기 때문에
DFS를 재귀로 구현하는 경우가 굉장히 많다.

void dfs(int node) {

    visited[node] = true;

    for (int next : graph[node]) {

        if (!visited[next]) {
            dfs(next);
        }
    }
}

나도 그래프 문제를 보면 가장 먼저 떠오르는 방식이
이 재귀 DFS인 것 같다.

DFS의 장점

DFS의 가장 큰 장점은 메모리다.

BFS는 각 Level의 Node를 대부분 보관해야 하지만
DFS는 현재 탐색 중인 경로 중심으로 정보를 가지고 있으면 된다.

그래서 일반적으로 BFS보다 훨씬 적은 메모리를 사용할 수 있다.

또한 정답이 깊은 위치에 있고
운 좋게 해당 방향부터 탐색한다면 매우 빠르게 답을 찾을 수도 있다.

DFS의 단점

하지만 DFS에는 중요한 문제가 있다.

먼저 최단 경로를 보장하지 않는다.

예를 들어

A → B → C → D → E → Goal

이라는 경로를 먼저 발견했더라도

실제로는

A → F → Goal

이라는 훨씬 짧은 경로가 존재할 수 있다.

DFS는 첫 번째 Goal을 찾았다고 해서
그것이 최적이라는 보장이 없다.

또한 Cycle이 존재하는 Graph에서 방문 처리를 하지 않으면

A → B → C → A → B → C → ...

처럼 무한히 반복될 수도 있다.

그래서 실제 구현에서는 보통

visited[]

를 사용한다.

BFS와 DFS를 비교해보면

둘의 차이를 가장 단순하게 표현하면 다음과 같다.

결국

DFS와 BFS 중 무엇이 더 좋은 알고리즘인가?

라는 질문은 의미가 없다.

문제가 무엇을 요구하는지를 먼저 봐야 한다.

Uniform Cost Search

여기에서 BFS의 한계가 하나 등장한다.

BFS는 이동 횟수가 가장 적은 경로를 찾는다.

하지만

이동 횟수가 적다
=
비용이 가장 작다

는 항상 성립하지 않는다.

예를 들어

A → B → Goal

이라는 경로의 비용이

A → B = 100
B → Goal = 100

Total = 200

이라고 해보자.

반면

A → C → D → Goal

은 이동 횟수는 더 많지만

10 + 10 + 10 = 30

일 수도 있다.

BFS는 이동 횟수만 보면 첫 번째 경로를 선택할 수 있다.

하지만 진짜 최소 비용 경로는 두 번째다.

이 문제를 해결하는 것이 Uniform Cost Search(UCS)다.

Uniform Cost Search의 핵심

UCS는 Frontier에서

가장 Path Cost가 작은 Node

부터 선택한다.

따라서 일반 Queue가 아니라
Priority Queue를 사용한다.

Frontier

Path Cost 3
Path Cost 7
Path Cost 12

가 있다면 항상 Cost 3부터 탐색한다.

즉,

지금까지 들어간 비용이 가장 작은 경로부터 확장한다.

모든 Step Cost가 동일하다면
UCS는 BFS와 동일하게 동작한다.

그리고 적절한 양의 Step Cost 조건에서는
최소 비용의 Optimal Solution을 찾을 수 있다.

Depth-Limited Search

DFS의 가장 큰 문제 중 하나는

끝없이 깊게 들어갈 수 있다.

는 것이다.

그래서 아예 깊이에 제한을 둘 수 있다.

이것이 Depth-Limited Search다.

예를 들어

Depth Limit = 3

이라고 하면

Depth 0
Depth 1
Depth 2
Depth 3

까지만 탐색하고
그 아래는 탐색하지 않는다.

쉽게 말하면

DFS에 최대 깊이 제한을 추가한 방식

이다.

Iterative Deepening Search

그런데 Depth Limit을 얼마로 설정해야 할까?

1?
3?
10?
100?

정답이 어디에 있는지 모르기 때문에
적절한 값을 미리 결정하기 어렵다.

그래서 나온 방법이 Iterative Deepening Search(IDS)다.

아이디어는 매우 단순하다.

Depth Limit = 0으로 DFS

없으면

Depth Limit = 1로 DFS

없으면

Depth Limit = 2로 DFS

없으면

Depth Limit = 3로 DFS

...

정답이 나올 때까지 Depth Limit을 계속 증가시킨다.

그런데 같은 Node를 계속 다시 탐색하는 것 아닌가?

나도 이 부분을 보고 처음에는

"이거 너무 비효율적인 것 아닌가?"

라는 생각이 들었다.

예를 들어 Depth 3까지 가려면

Depth 1 탐색
Depth 2 탐색
Depth 3 탐색

을 반복하므로
위쪽 Node를 여러 번 방문하게 된다.

그런데 Tree 탐색에서는 보통
가장 마지막 Level의 Node 수가 압도적으로 많다.

예를 들어 Branching Factor가 10이면

Depth 0 → 1개
Depth 1 → 10개
Depth 2 → 100개
Depth 3 → 1,000개
Depth 4 → 10,000개

가 된다.

즉 상위 Level을 몇 번 반복하는 비용보다
가장 깊은 Level을 탐색하는 비용이 훨씬 크다.

그래서 생각보다 반복 탐색의 손해가 크지 않다.

IDS는 BFS와 DFS의 장점을 섞는다

Iterative Deepening의 목적은 꽤 명확하다.

DFS의 낮은 Memory 사용량

+

BFS의 얕은 Solution 탐색 능력

을 함께 얻는 것이다.

강의에서도

DFS의 Space Advantage와 BFS의 Shallow-Solution Advantage를 함께 얻는 방식

으로 설명했다.

Step Cost가 동일한 경우
IDS 역시 얕은 Goal부터 발견하기 때문에 Optimal Solution을 찾을 수 있다.

결국 Search Strategy의 차이는 무엇일까?

여기까지 보고 나니 탐색 알고리즘들이
사실 완전히 다른 알고리즘처럼 느껴지지 않았다.

기본 구조는 거의 동일하다.

Frontier에서 Node를 하나 꺼낸다.
↓
Goal인지 확인한다.
↓
Neighbor를 추가한다.
↓
반복한다.

달라지는 것은 딱 하나다.

Frontier에서 어떤 Node를 먼저 꺼낼 것인가?

이다.

BFS는

가장 얕은 Node

DFS는

가장 깊은 Node

Uniform Cost Search는

현재까지 비용이 가장 작은 Node

를 선택한다.

이 선택 기준이 달라지면서
알고리즘의 성질도 완전히 달라진다.

Search Algorithm 비교

강의 마지막에는 지금까지 다룬 Search Algorithm을
Completeness, Time, Space, Optimality 관점에서 비교했다.

큰 특징만 정리하면 다음과 같다.

결국 어떤 알고리즘을 사용할지는
문제가 무엇을 요구하느냐에 따라 달라진다.

수업을 듣고 나서

이번 Lesson은 개인적으로 다른 단원보다 훨씬 익숙했다.

학교에서 컴퓨팅 문제와 알고리즘 과목을 들으며
Graph, Tree, BFS, DFS 같은 내용을 이미 공부했기 때문이다.

그때는 주로

DFS 구현하기
BFS 구현하기
최단 경로 찾기
그래프 탐색하기

같은 알고리즘 자체에 집중했던 것 같다.

하지만 이번 강의에서는 조금 더 상위 개념에서 접근했다.

현실의 문제
↓
State와 Action으로 추상화
↓
State Space 구성
↓
Graph로 표현
↓
Search Strategy 선택
↓
Solution 탐색

이라는 전체 흐름으로 바라본다.

그래서 예전에는

"그래프가 주어졌으니까 BFS를 사용한다."

정도로 생각했다면,

이번에는

"현실의 문제 자체를 State Space로 표현하면 결국 Graph Search Problem으로 바꿀 수 있구나."

라는 생각을 하게 되었다.

이 차이가 생각보다 컸다.

특히 BFS와 DFS를 다시 생각하게 됐다

코딩테스트를 풀다 보면
DFS와 BFS 문제를 정말 많이 만나게 된다.

그런데 막상 문제를 보면 나도 가끔

그래프 문제네?
→ 일단 DFS?

처럼 습관적으로 접근할 때가 있다.

최근 프로그래머스의 게임 맵 최단거리 문제에서도
처음에는 별 생각 없이 DFS 재귀를 작성했다.

정답 자체는 나왔지만
모든 경로를 계속 탐색하다 보니 효율성 테스트에서 시간 초과가 발생했다.

문제에서 요구한 것은

도착 가능한가?

가 아니라

최소 몇 칸을 지나야 하는가?

였다.

즉 동일한 비용의 Graph에서 최단 경로를 찾는 문제였고
이 경우에는 Level 순서대로 탐색하는 BFS가 훨씬 자연스러운 선택이었다.

이번 강의를 들으면서 다시 느꼈다.

알고리즘을 구현할 줄 아는 것도 중요하지만,
문제의 특성을 보고 어떤 Search Strategy를 선택해야 하는지를 판단하는 것이 훨씬 중요하다.

마무리

이번 Lesson 3의 핵심을 한 문장으로 정리하면 다음과 같다.

Problem Solving은 결국 가능한 State들을 탐색하면서 Initial State에서 Goal State까지의 경로를 찾는 과정이다.

그리고 많은 문제를

State
Action
Goal
Cost

로 추상화하면
Graph Search Problem으로 표현할 수 있다.

그 Graph를 어떤 순서로 탐색하느냐에 따라

BFS
DFS
Uniform Cost Search
Depth-Limited Search
Iterative Deepening Search

와 같은 서로 다른 Search Strategy가 만들어진다.

예전에 배웠던 DFS와 BFS를 다시 복습한 단원이기도 했지만,
이번에는 단순한 알고리즘 구현을 넘어

왜 Search가 문제 해결의 기본 구조가 되는가

를 이해할 수 있었던 단원이었다.

오늘의 코테 연습문제는 프로그래머스의
삼총사 문제다.

문제 링크는 아래와 같다.

https://school.programmers.co.kr/learn/courses/30/lessons/131705?language=cpp

문제 설명

한국중학교 학생들은 각자 정수 번호를 하나씩 가지고 있다.

이 중 3명의 정수 번호를 더했을 때 합이 0이 되면
이 세 학생을 삼총사라고 한다.

예를 들어 다음과 같은 학생들이 있다고 해보자.

[-2, 3, 0, 2, -5]

여기서

-2 + 0 + 2 = 0
3 + 2 + (-5) = 0

이므로 만들 수 있는 삼총사는 총 2개다.

결국 문제에서 요구하는 것은 간단하다.

학생들 중 3명을 선택했을 때
세 학생의 번호 합이 0이 되는 경우의 수를 구하면 된다.

제한 사항

3 ≤ number의 길이 ≤ 13
-1,000 ≤ number의 각 원소 ≤ 1,000
서로 다른 학생의 정수 번호가 같을 수 있다.

여기서 마지막 조건이 꽤 중요하다.

번호가 같다고 해서 같은 학생은 아니다.

예를 들어

[-1, -1, 0, 1, 1]

에서 첫 번째 -1과 두 번째 -1은 같은 값을 가지고 있지만 서로 다른 학생이다.

즉 이 문제에서는 단순히 숫자만 보는 것이 아니라
각 위치에 존재하는 서로 다른 학생을 선택한다고 생각해야 한다.

처음 문제를 봤을 때

문제를 읽자마자 든 생각은 이거였다.

음... 완전탐색 문제인가?

학생 수가 최대 13명밖에 되지 않고
그중 3명을 선택하면 된다.

그러면 경우의 수는 그냥

number.size() C 3

이다.

즉,

모든 3명의 조합을 확인한다.
↓
세 학생의 번호를 더한다.
↓
합이 0이면 answer++

하면 된다.

아이디어 자체는 상당히 간단해 보였다.

그래서 처음에는 별생각 없이
next_permutation()을 이용하면 되겠다고 생각했다.

먼저 도메인 지식부터 정리해보자

이 문제에서 가장 중요한 것은
완전탐색, 그리고 순열과 조합의 차이다.

완전탐색이란?

완전탐색(Brute Force)은 말 그대로
가능한 모든 경우를 직접 확인하는 방법이다.

이번 문제에서는

학생 3명을 선택할 수 있는 모든 경우

를 확인하면 된다.

학생이 N명이라면
3명을 선택하는 경우의 수는

N C 3

이다.

문제에서 학생 수는 최대 13명이므로

13C3 = 286

밖에 되지 않는다.

따라서 모든 경우를 직접 확인해도 충분히 빠르다.

즉 이 문제는

"완전탐색을 사용해도 되는가?"

를 고민할 필요는 거의 없었다.

진짜 중요한 문제는

모든 경우를 어떤 방식으로 만들 것인가?

였다.

순열과 조합의 차이

순열(Permutation)

순열은 순서를 고려해서 선택하는 것이다.

예를 들어 A, B, C라는 세 사람이 있다면

A B C
A C B
B A C
B C A
C A B
C B A

를 모두 서로 다른 경우로 본다.

반면 조합은 순서를 고려하지 않는다.

A, B, C

라는 세 사람을 선택했다면

A, C, B
B, A, C
C, B, A

는 전부 같은 세 사람을 선택한 것이다.

이번 문제에서 필요한 것은

순열 X
조합 O

이다.

첫 번째 문제풀이

하지만 처음에는 이 부분을 깊게 생각하지 않고
다음과 같은 코드를 작성했다.

#include <bits/stdc++.h> 

using namespace std;

int solution(vector<int> number) {
    int answer = 0;

    do { 
        int sum = 0; 

        for (int i = 0; i < 3; i++) { 
            sum += number[i]; 
        }

        if (sum == 0) {
            answer++;
        }

    } while (next_permutation(number.begin(), number.end())); 

    return answer;
}

처음 봤을 때는 나름 그럴싸했다.

next_permutation()으로 모든 경우를 만든다.
↓
앞의 3개 숫자를 더한다.
↓
0이면 삼총사다.

그런데 생각해보니 이건 아니었다.

문제는 숫자가 아니라 "사람"을 선택하는 것이다

예를 들어 다음 배열이 있다고 해보자.

[-2, 3, 0, 2, -5]

이를 학생의 관점에서 보면 다음과 같다.

0번 학생 → -2
1번 학생 →  3
2번 학생 →  0
3번 학생 →  2
4번 학생 → -5

즉 우리가 선택해야 하는 것은
숫자 자체가 아니라 학생의 인덱스다.

예를 들어

0번 학생
2번 학생
3번 학생

을 선택했다면

-2 + 0 + 2 = 0

이므로 하나의 삼총사가 된다.

그런데 이 세 사람의 순서를 바꾼다고 해서
새로운 삼총사가 되는 것은 아니다.

next_permutation(number)이 문제가 되는 이유

next_permutation(number)으로 배열 자체의 모든 순열을 만들면
같은 세 사람이 앞의 세 자리에 등장하는 경우가 여러 번 생긴다.

예를 들어 선택된 사람이 A, B, C라면

A B C
A C B
B A C
B C A
C A B
C B A

는 전부 같은 세 사람이다.

하지만 배열의 순열을 기준으로 보면
서로 다른 경우로 취급된다.

즉 내가 처음 작성한 코드는

조합

을 세어야 하는데

순열

을 만들고 있었던 것이다.

우리가 원하는 것은

nP3

가 아니라

nC3

이다.

문제는 완전탐색이 맞았다.
하지만 완전탐색해야 하는 대상이 순열이 아니라 조합이었다.

그런데 조합을 어떻게 구현하지?

여기까지는 알았다.

이 문제는 순열이 아니다.
조합이다.

그런데 막상 구현하려고 하니 고민이 생겼다.

next_permutation()을 이용해서 조합을 만들 수는 없을까?

아무리 생각해도 아이디어가 바로 떠오르지 않았다.

이 시점에서 AI에게 문제를 풀어달라고 한 것이 아니라
현재 상황에서 사용할 수 있는 아이디어가 무엇인지 물어봤다.

그러자 생각하지 못했던 방법을 알게 됐다.

0과 1로 선택 여부를 표현한다

예를 들어 학생이 5명이고
그중 3명을 선택해야 한다고 해보자.

다음과 같은 배열을 만든다.

vector<int> select = {0, 0, 1, 1, 1};

여기서

0 = 선택하지 않음
1 = 선택함

이라고 생각하는 것이다.

예를 들어

0 0 1 1 1

이라면 2번, 3번, 4번 학생을 선택한 하나의 조합이다.

여기에 next_permutation을 사용하면?

이제 select 배열에 next_permutation()을 사용한다.

do {

} while (next_permutation(select.begin(), select.end()));

그러면 다음과 같은 패턴들이 만들어진다.

0 0 1 1 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 0
1 0 0 1 1
...

모든 배열에는 항상 1이 정확히 3개 존재한다.

즉 학생 N명 중 정확히 3명을 선택한 모든 경우가 만들어진다.

이걸 보고 조금 허무했다.

아... next_permutation()으로 학생들의 번호를 섞는 것이 아니라
선택 여부를 섞으면 되는구나.

왜 이 방법은 중복되지 않을까?

예를 들어

0 1 1 0 1

은 1번, 2번, 4번 학생을 선택했다는 뜻이다.

여기에서 1 세 개는 서로 구분되지 않는다.

중요한 것은 오직

어느 위치가 1인가?

이다.

따라서 서로 다른 select 배열 하나가
서로 다른 학생 조합 하나와 정확하게 대응한다.

학생이 5명이라면 만들어지는 경우의 수도 정확하게

5C3 = 10

개가 된다.

next_permutation은 정렬 후 사용해야 한다

next_permutation()은 현재 순열보다
사전순으로 바로 다음에 오는 순열을 만들어준다.

따라서 모든 순열을 탐색하려면
가장 작은 순열부터 시작하는 것이 안전하다.

처음 select는

1 1 1 0 0

이므로 정렬한다.

sort(select.begin(), select.end());

그러면

0 0 1 1 1

이 된다.

이 상태에서 next_permutation()을 반복하면
모든 선택 조합을 빠짐없이 확인할 수 있다.

두 번째 문제풀이

바로 이 아이디어를 적용했다.

#include <bits/stdc++.h> 

using namespace std;

int solution(vector<int> number) {
    int answer = 0;

    vector<int> select(number.size()); 

    for (int i = 0; i < 3; i++) { 
        select[i] = 1;
    }

    sort(select.begin(), select.end()); 

    do { 
        int sum = 0; 

        for (int i = 0; i < number.size(); i++) { 
            if (select[i] == 1) { 
                sum += number[i]; 
            }
        }

        if (sum == 0) {
            answer++; 
        }

    } while (next_permutation(select.begin(), select.end())); 

    return answer;
}

결과는?

정답이었다!

그런데 사실 더 간단한 방법도 있다

문제를 풀고 나서 생각해보니
이 문제에서는 반드시 next_permutation()을 사용할 필요는 없다.

선택해야 하는 사람이 정확히 3명으로 고정되어 있기 때문에
3중 for문으로도 상당히 간단하게 풀 수 있다.

#include <bits/stdc++.h>

using namespace std;

int solution(vector<int> number) {
    int answer = 0;

    for (int i = 0; i < number.size(); i++) {
        for (int j = i + 1; j < number.size(); j++) {
            for (int k = j + 1; k < number.size(); k++) {
                if (number[i] + number[j] + number[k] == 0) {
                    answer++;
                }
            }
        }
    }

    return answer;
}

항상

i < j < k

가 유지되기 때문에 같은 세 학생을 순서만 바꿔 중복해서 세지 않는다.

개인적으로 실제 코딩테스트에서 이 문제를 다시 만난다면
3중 for문을 사용할 것 같다.

하지만 이번 문제를 통해
next_permutation()을 조합 생성에도 활용할 수 있다는 것을 배운 점은 꽤 의미 있었다.

시간복잡도

학생 수를 N이라고 하면 확인해야 하는 조합의 수는

N C 3

이다.

문제에서는

N ≤ 13

이므로 최대 조합 수도

13C3 = 286

밖에 되지 않는다.

따라서 이 문제에서는 복잡한 최적화보다
정확하게 조합을 구현할 수 있는가가 더 중요하다.

문제를 풀고 나서

개인적으로 이 문제는 아이디어 자체는 상당히 쉬운 문제라고 생각한다.

문제를 읽으면 거의 바로

3명을 뽑는다.
↓
합이 0인지 확인한다.

가 떠오른다.

즉 완전탐색이라는 것까지는 어렵지 않았다.

하지만 막상 구현하려고 하니

"모든 경우"와 "모든 순서"는 다르다.

라는 것을 다시 생각하게 됐다.

처음에는 next_permutation()이라는 함수를 알고 있으니
그냥 모든 순열을 만들면 되겠다고 생각했다.

하지만 문제에서 요구하는 것은 순열이 아니라 조합이었다.

그리고 이번 문제에서 가장 기억에 남았던 것은
next_permutation()으로 조합도 만들 수 있다는 점이었다.

0 = 선택하지 않음
1 = 선택함

으로 표현하고

0 0 1 1 1

을 next_permutation()으로 순회하면
선택 위치의 모든 조합을 만들 수 있다.

함수 하나를 알고 있는 것과
그 함수를 어떻게 활용할 수 있는지를 아는 것은
확실히 다른 문제인 것 같다.

결론

이번 문제에서 가져갈 것은 크게 세 가지다.

1. 완전탐색 문제에서도 순열과 조합을 먼저 구분해야 한다.

2. next_permutation()은 숫자 자체뿐 아니라
   0/1 선택 배열을 이용해 조합 생성에도 활용할 수 있다.

3. 뽑는 개수가 고정되어 있다면
   중첩 for문이 오히려 더 단순하고 직관적일 수 있다.

결국 이 문제는 단순히

세 수의 합이 0인가?

를 묻는 문제가 아니었다.

순열과 조합의 차이를 이해하고,
원하는 경우의 수를 코드로 정확하게 만들어낼 수 있는가?

를 묻는 문제에 더 가까웠다고 생각한다.

앞으로 완전탐색 문제가 나오면
무작정 next_permutation()부터 떠올리기보다

순서가 중요한가?
↓
순열

순서가 중요하지 않은가?
↓
조합

을 먼저 판단해야겠다.

이전 글에서는 LLM을 활용해
Tabular Data를 다루는 방법에 대해 정리했다.

LLM이 가지고 있는 Semantic Knowledge를 활용하거나,
테이블을 Text 형태로 Serialization하여 예측하거나,
Feature Engineering이나 Anomaly Detection에 LLM을 활용하는 방식이었다.

그런데 Tabular Foundation Model을 만드는 방법이
LLM만 있는 것은 아니다.

이번 강의에서는 최근 Tabular ML에서 상당히 주목받고 있는
TabPFN이라는 완전히 다른 방향의 Foundation Model을 다뤘다.

처음 이름을 봤을 때는 그냥

"Transformer를 Tabular Data에 적용한 또 다른 모델인가?"

정도로 생각했다.

그런데 공부해보니 핵심 아이디어가 꽤 신기했다.

일반적인 머신러닝은 새로운 데이터셋이 들어올 때마다
모델을 다시 학습한다.

새로운 Dataset
↓
Train / Validation 분리
↓
모델 학습
↓
Hyperparameter Tuning
↓
Test Prediction

그런데 TabPFN은 조금 다르다.

수많은 가상의 머신러닝 문제를 미리 풀어본다.
↓
새로운 Task를 푸는 방법 자체를 학습한다.
↓
실제 새로운 Dataset이 들어온다.
↓
Training Data를 Context로 입력한다.
↓
별도의 Parameter Update 없이 Prediction

처음 들었을 때는

이게 어떻게 가능하지?

라는 생각이 들었다.

이번 글에서는 이 아이디어가 어디에서 출발했고,
TabPFN v1 → v2 → v3로 어떻게 발전했는지,
그리고 최근에는 어떤 방향으로 확장되고 있는지 정리해보고자 한다.

먼저 Tabular Foundation Model이란?

Foundation Model이라고 하면 보통 GPT 같은 LLM을 먼저 떠올린다.

GPT는 엄청나게 많은 Text를 미리 학습해놓고
새로운 문제가 주어졌을 때 이미 학습한 지식을 활용한다.

Tabular Data에서도 비슷한 질문을 할 수 있다.

여러 Table과 Task에서 사용할 수 있는
범용적인 Tabular Foundation Model을 만들 수 없을까?

문제는 Table마다 생김새가 너무 다르다는 것이다.

금융 데이터
→ 소득, 신용점수, 부채, 연체 여부

의료 데이터
→ 나이, 혈압, BMI, 질병 여부

마케팅 데이터
→ 방문 횟수, 클릭 수, 구매 금액, 전환 여부

Column의 개수도 다르고,
Feature의 의미도 다르고,
Classification일 수도 Regression일 수도 있다.

즉, 자연어처럼 모든 데이터를 동일한 Token Sequence로 표현하기가 쉽지 않다.

그래서 Tabular Foundation Model 연구에서는
크게 두 가지 방향이 등장했다.

1. LLM-based Tabular Foundation Models
2. TabPFN-style Foundation Models

지난 글에서 첫 번째를 다뤘다면
이번 글에서는 두 번째를 살펴본다.

TabPFN에서 PFN이란?

TabPFN을 이해하려면 먼저
PFN(Prior-Fitted Network)을 이해해야 한다.

PFN의 핵심 아이디어는 다음과 같다.

실제 문제를 만나기 전에
다양한 가상의 머신러닝 문제를 엄청나게 만들어서 미리 풀어보자.

조금 더 정확하게 말하면
먼저 데이터가 만들어지는 방식에 대한 Prior를 정의한다.

Prior란?

Prior는 우리말로 하면 사전분포라고 번역한다.

처음 보면 상당히 어렵게 느껴지는데
여기서는 그냥 이렇게 생각해도 된다.

"세상에 존재할 법한 데이터셋은 대충 이런 방식으로 만들어질 것이다."

라는 가정이다.

강의에서는 이를 다음과 같이 표현했다.

p(D)

p(D)는 여러 종류의 데이터 생성 분포에 대한 Prior다.

그리고 여기에서 하나를 Sampling한다.

D ~ p(D)

이렇게 뽑힌 D는 하나의 데이터 생성 방식, 즉 하나의 Task라고 생각할 수 있다.

예를 들어 어떤 D는 다음과 같은 문제를 만들 수 있다.

공부 시간
출석률
과제 점수
↓
합격 여부

또 다른 D는

소득
부채
신용점수
↓
대출 승인

과 같은 관계를 만들 수도 있다.

핵심은 특정 Dataset 하나를 미리 외우는 것이 아니라
다양한 데이터 생성 규칙을 Sampling하면서 수많은 Task를 만든다는 것이다.

Task를 엄청나게 만들어보자

일반적인 머신러닝은 다음과 같다.

Dataset A
↓
Model A 학습

새로운 Dataset이 생기면 다시 학습한다.

Dataset B
↓
Model B 학습

PFN은 조금 다르다.

Prior p(D)
↓
D1 Sampling → Task 1
D2 Sampling → Task 2
D3 Sampling → Task 3
...
↓
수많은 Synthetic Task

그리고 각 Task에서는 다시

Training Dataset

Test Sample

을 만든다.

예를 들어 하나의 Task에서는

(x1, y1)
(x2, y2)
(x3, y3)

x_test → ?

라는 문제가 만들어질 수 있다.

PFN은 이런 문제를 정말 많이 풀어본다.

쉽게 비유하면 코딩테스트와 비슷하다.

한 문제의 정답을 외우는 것이 아니라

그래프 문제
DP 문제
그리디 문제
정렬 문제

를 수없이 풀면서

"처음 보는 문제를 어떻게 풀어야 하는가?"

를 학습하는 것이다.

PFN은 무엇을 학습하는가?

일반적인 머신러닝 모델은
하나의 Dataset에서 Feature와 Label의 관계를 학습한다.

예를 들어 XGBoost라면

D_train
↓
XGBoost 학습
↓
학습된 Model
↓
x_test
↓
y_test

이다.

PFN은 조금 다르다.

PFN이 받는 입력은 다음과 같다.

(x1, y1)
(x2, y2)
(x3, y3)
...
(xn, yn)

그리고

x_test

즉,

Training Dataset 자체가 모델의 입력으로 들어간다.

그리고 모델은 최종적으로

y_test

를 예측한다.

강의에서는 이를 다음처럼 표현한다.

qθ( · | x_test, D_train )

쉽게 풀어쓰면

"여기 Training Example들이 있고 새로운 Test Sample 하나가 있는데,
앞의 Example들을 참고해서 Test Label을 맞혀봐."

라는 것이다.

이 구조는 어디서 많이 본 것 같다.

이거 In-Context Learning 아닌가?

맞다.

나도 이 부분을 들으면서
LLM의 Few-shot Prompting이 바로 떠올랐다.

예를 들어 LLM에게 다음 예시를 준다고 해보자.

2 + 3 = 5
4 + 7 = 11
10 + 2 = 12

20 + 3 = ?

LLM은 앞의 예시를 Context로 사용해
마지막 문제의 답을 추론한다.

PFN도 상당히 비슷하다.

Training Sample 1
Training Sample 2
Training Sample 3
...
↓
Context

새로운 Test Sample
↓
Prediction

즉,

PFN에서는 Training Dataset 자체가 Few-shot Example의 역할을 한다.

그래서 PFN의 구조는
In-Context Learning(ICL)과 상당히 닮아 있다.

그래서 Transformer를 사용한다

그렇다면 Training Sample들 사이의 관계와
Test Sample과 Training Sample 사이의 관계를
어떻게 계산할까?

여기에서 Transformer가 등장한다.

Transformer의 Attention은
여러 입력 사이의 관계를 계산하는 데 강하다.

예를 들어 다음 Training Data가 있다고 해보자.

Sample 1 → Class A
Sample 2 → Class A
Sample 3 → Class B

Test Sample → ?

Test Sample은 Attention을 통해
Training Sample들의 정보를 참고할 수 있다.

물론 이것을 단순히

"가장 비슷한 Sample을 찾는다"

정도로만 이해하면 조금 부족하다.

핵심은 Transformer가 Training Dataset 전체의 패턴을 보면서

이 Task에서 Feature와 Label이 어떤 방식으로 연결되는지

를 Context 안에서 추론한다는 것이다.

Prior Fitting과 Inference

강의 자료에서 이 부분이 PFN을 이해하는 핵심이라고 느꼈다.

PFN은 크게 두 단계로 나뉜다.

1. Prior Fitting
2. Inference

1. Prior Fitting

Prior Fitting은 한 번 Offline에서 수행하는 학습 과정이다.

Prior에서 Synthetic Dataset 생성
↓
D1, D2, D3, ... Dn
↓
수많은 Task 학습
↓
PFN Parameter θ 학습

즉, PFN은 새로운 Dataset마다 처음부터 다시 학습하는 것이 아니라
먼저 수많은 Synthetic Task를 이용해

"Training Data를 보고 새로운 Test Sample을 예측하는 방법"

자체를 미리 학습한다.

2. Inference

이제 실제 Dataset이 들어온다.

예를 들어 처음 보는 고객 이탈 데이터라고 해보자.

Training Dataset

고객 A → 이탈
고객 B → 유지
고객 C → 유지

Test Sample

고객 D → ?

PFN은 다음 정보 전체를 입력으로 받는다.

고객 A + Label
고객 B + Label
고객 C + Label
고객 D

그리고 한 번의 Forward Pass를 통해

고객 D → 이탈 확률

을 계산한다.

여기서 정말 중요한 점이 있다.

Gradient Descent X
Fine-tuning X
Parameter Update X

즉, 새로운 Dataset이 들어왔다고 해서
PFN의 Parameter를 다시 학습하지 않는다.

강의 자료의 그림을 보면
왼쪽은 Synthetic Dataset들을 생성해서 한 번 학습하는 Prior Fitting, 오른쪽은 실제 Dataset과 Test Sample을 넣어 한 번의 Forward Pass로 예측하는 Inference로 나뉘어 있다.

여기에 강의자료 4페이지의 Prior Fitting / Inference 그림을 넣으면 이해하기 좋을 것 같다.

그런데 왜 모델을 다시 학습하지 않아도 될까?

처음에는 이 부분이 가장 이해가 안 됐다.

일반적인 머신러닝에서는 새로운 Dataset이 들어오면

model.fit(X_train, y_train)

을 해야 한다.

그런데 PFN은 왜 이 과정이 필요하지 않을까?

핵심은 다음과 같다.

PFN에게 새로운 Dataset의 Training Data는
Parameter를 업데이트하기 위한 데이터가 아니라
Prediction을 위한 Context다.

일반적인 모델은

Training Data
↓
Parameter에 Dataset의 규칙을 저장
↓
학습이 끝나면 Training Data 없이 Prediction

한다.

반면 PFN은

미리 학습된 Parameter
+
현재 Dataset의 Training Data
+
Test Sample
↓
Prediction

을 수행한다.

즉 Dataset의 정보를 Parameter 안에 새로 저장하는 것이 아니라
Inference 시점에 Training Data를 직접 입력으로 넣어 참고한다.

PFN은 Prior Fitting 과정에서 이미

Training Data가 이렇게 주어졌을 때
↓
어떤 규칙을 읽어야 하는지
↓
Test Label을 어떻게 예측해야 하는지

를 수많은 Task를 통해 반복적으로 학습해두었다.

그래서 실제 Dataset에서는
Parameter Update 없이도 새로운 Task에 적응할 수 있다.

이 부분이 PFN을 이해하는 가장 중요한 포인트라고 생각한다.

TabPFN v1

이 PFN 아이디어를
Tabular Data에 적용한 것이 TabPFN이다.

TabPFN v1은 ICLR 2023에 발표되었다.

초기 논문의 제목부터 상당히 직관적이다.

TabPFN:
A Transformer That Solves Small Tabular
Classification Problems in a Second

즉 초기 TabPFN은
작은 Tabular Classification 문제를 빠르게 해결하는 것에 초점을 맞췄다.

하나의 Row를 하나의 Token으로

TabPFN v1의 핵심 아이디어는 단순하다.

하나의 Row를 하나의 Token으로 만들자.

예를 들어 다음 Table이 있다고 해보자.

각 Row 전체를 하나의 Token처럼 취급한다.

Row 1 → Token 1
Row 2 → Token 2
Row 3 → Token 3

Training Sample은 Feature x와 Label y를 모두 알고 있다.

그래서 다음처럼 표현한다.

MLP_x(x) + MLP_y(y)

반면 Test Sample은 Label을 모른다.

MLP_x(x_test) + MLP_y([MASK])

처럼 Label 위치를 Mask 처리한다.

또한 Dataset마다 Column 수가 다른 문제는
Zero Padding으로 맞춘다.

TabPFN v1의 Attention은 어떻게 동작할까?

강의 자료의 그림에서 Training Row와 Test Row가 함께 Transformer에 들어간다.

Training Row들은 Training Row끼리 정보를 주고받을 수 있고,
Test Row는 Training Row를 참고해 Prediction을 만든다.

개념적으로는 다음과 같이 이해하면 된다.

Training ↔ Training

Test → Training

Training → Test X

Test → Test X

왜 Test Token끼리는 서로 참고하지 않도록 할까?

각 Test Sample은 기본적으로

D_train + x_test

만 주어진 하나의 독립적인 Query라고 생각해야 하기 때문이다.

Test Sample끼리 정보를 공유하게 만들면
다른 Test Sample의 존재 여부에 따라 Prediction이 달라질 수 있다.

그래서 각 Test Sample은
현재 Training Dataset을 Context로 사용해 독립적으로 예측한다.

최종 예측은 어떻게 할까?

Transformer를 통과하고 나면
각 Test Token에는 마지막 Hidden State가 만들어진다.

Test Token
↓
Transformer
↓
Final Hidden State

그리고 이 값을 MLP Classifier에 넣는다.

Final Hidden State
↓
MLP Classifier
↓
Class Prediction

즉 v1의 전체 흐름은 다음과 같다.

Training Rows + Labels
+
Test Row
↓
Row Token 생성
↓
Transformer
↓
Training Dataset을 Context로 활용
↓
Test Token Hidden State
↓
MLP Classifier
↓
Prediction

그런데 Synthetic Dataset은 어떻게 만들까?

여기까지 이해하고 나니
가장 중요한 의문이 생겼다.

수많은 Synthetic Task를 만든다고 했는데
그 데이터는 도대체 어떻게 만드는 걸까?

TabPFN v1에서는 대표적으로 두 가지 Prior를 사용한다.

1. SCM
2. BNN

SCM

SCM은 Structural Causal Model이다.

쉽게 생각하면

변수들이 서로 어떤 구조적인 관계를 가지도록
가상의 Graph를 만든 뒤 데이터를 생성하는 방식

이라고 보면 된다.

예를 들어 다음과 같은 관계를 생각해보자.

나이
 ↓
소득
 ↓
대출 승인

부채 ─────→ 대출 승인

TabPFN에서는 Random Graph를 생성하고
그 Graph에서 일부 Node를 관측 Feature로,
특정 Node를 Target으로 선택한다.

Random Graph 생성
↓
Feature Node 선택
↓
Target Node 선택
↓
Graph를 따라 값 생성
↓
Synthetic Dataset 완성

네 필기에서 적었던

"사이클이 없는 그래프를 만든다"

라는 이해는 방향은 맞다.

SCM은 보통 인과관계를 표현하기 위해
DAG(Directed Acyclic Graph) 형태를 사용할 수 있다.

중요한 것은 단순히 랜덤 숫자를 만드는 것이 아니라
Feature 사이에 구조적인 Dependency를 넣어준다는 것이다.

BNN

두 번째는 BNN(Bayesian Neural Network) Prior다.

처음 들었을 때는

"랜덤하게 Input을 넣는다는 말인가?"

싶었는데 핵심은 조금 다르다.

먼저 Neural Network 자체를 하나 Sampling한다.

Random Neural Network

그리고 Input x를 넣는다.

x
↓
Sampling된 Neural Network
↓
y

즉, 이 Neural Network 하나가
하나의 데이터 생성 함수가 된다.

다른 Network를 Sampling하면
완전히 다른 관계를 가진 Task가 만들어진다.

BNN 1 → Task 1
BNN 2 → Task 2
BNN 3 → Task 3

초기 TabPFN v1은 Classification을 목표로 했기 때문에
Continuous Target은 Class Label로 변환해 사용한다.

SCM과 BNN의 목적은 결국 동일하다.

현실에 존재할 법한 다양한 Feature-Target 관계를 가진
Synthetic Task를 최대한 많이 만들어내는 것

이다.

그런데 가상의 문제만 학습해서 실제 문제도 풀 수 있을까?

여기까지 이해하고 나니 또 의문이 생겼다.

TabPFN은 실제 Dataset 하나하나를 학습한 것이 아니라
SCM과 BNN으로 만든 Synthetic Task를 엄청나게 학습했다.

그렇다면

"가짜로 만든 문제만 풀어봤는데
실제 금융, 의료, 마케팅 데이터도 잘 풀 수 있을까?"

라는 질문이 자연스럽게 생긴다.

강의에서는 TabPFN이 실제 Dataset에서도 동작할 수 있는 이유를
크게 세 가지로 설명했다.

1. Synthetic Prior가 충분히 다양하다

첫 번째는 Prior의 다양성이다.

SCM과 BNN을 이용하면

Feature 관계가 다른 Dataset
선형적인 관계
비선형적인 관계
Feature 간 Dependency가 존재하는 Dataset
다양한 Target 결정 규칙

등 상당히 다양한 Task를 만들 수 있다.

실제 세상의 모든 Dataset을
완벽하게 복제할 필요는 없다.

대신 충분히 다양한 Task를 만들어두면

실제 Dataset
≈
Pretraining에서 경험했던 Task 중 어떤 형태와 비슷함

이 될 가능성이 높아진다.

코딩테스트로 비유하면
실제 시험 문제를 미리 정확하게 알고 있을 필요는 없다.

DFS, BFS, DP, Greedy 같은 다양한 유형을 충분히 풀어봤다면
처음 보는 문제도 기존 문제와의 구조적 유사성을 바탕으로 접근할 수 있다.

2. Transformer가 그 규칙을 학습한다

Synthetic Task를 많이 만들어도
모델이 그 관계를 제대로 학습하지 못하면 의미가 없다.

강의에서는 Transformer가
주어진 Prior에 대한 Bayesian Posterior를 학습할 수 있을 만큼
충분히 유연한 Function Approximator라고 설명한다.

처음 보면 상당히 어려운 말이다.

지금 단계에서는 조금 단순하게

수많은 Synthetic Task를 경험
↓
Training Data가 이런 모습일 때
어떤 Label이 나올 가능성이 높은지 학습
↓
새로운 Dataset에서도
Training Data를 보고 적절한 규칙을 추론

정도로 이해했다.

즉,

Prior
→ 어떤 문제들을 경험할지 결정

Transformer
→ 그 문제들에서 어떻게 답을 추론할지 학습

한다고 볼 수 있다.

3. 실제 새로운 Dataset의 Training Data도 직접 본다

그리고 가장 직관적인 이유가 이것이다.

TabPFN은 Pretraining에서 배운 지식만으로
아무 정보 없이 답을 찍는 모델이 아니다.

실제 새로운 Dataset이 들어오면

현재 Dataset의 Training Data
+
Test Sample

을 함께 본다.

즉

Pretraining
→ 다양한 Tabular Task를 푸는 방법 학습

+

Inference
→ 지금 풀고 있는 Dataset의 Training Data 확인

이 합쳐지는 것이다.

이렇게 생각하면

왜 별도의 Parameter Update 없이도
새로운 Dataset에 적응할 수 있는지

조금 더 이해가 된다.

그래서 TabPFN v1의 성능은 어땠을까?

강의 자료에서는 TabPFN v1이
작은 Dataset에서 MLP와 GBDT 계열 Baseline보다 좋은 성능을 보였고, Runtime도 매우 빨랐다고 설명한다.

여기에서 특히 중요한 조건은

Small Dataset

이다.

TabPFN은 이미 Prior Fitting을 끝낸 모델이기 때문에
새 Dataset이 들어와도

Model Training
Hyperparameter Search
Cross Validation

을 매번 처음부터 다시 할 필요가 없다.

Inference에서는

Training Data + Test Sample
↓
Forward Pass
↓
Prediction

으로 끝난다.

그래서 작은 Dataset에서는
성능뿐 아니라 속도 측면에서도 강점이 있었다.

TabPFN v1의 한계

당연히 좋은 점만 있는 것은 아니었다.

강의 자료에서 정리한 v1의 제약은 다음과 같다.

Training Sample
→ 1,000개 미만

Column
→ 100개 미만

Multiclass Classification
→ 10개 Class 미만

Missing Value
→ 별도 Preprocessing 필요

Categorical Value
→ 별도 Preprocessing 필요

그리고 Architecture 측면에서도
더 근본적인 문제가 하나 있었다.

바로

Tabular Data의 2차원 구조를 제대로 활용하지 못한다는 것

이다.

v1에서는 Row 전체를 하나의 Token으로 만든다.

Age | Income | Debt | Job
          ↓
      Row Token 하나

하지만 Table은 원래

Row × Column

이라는 2차원 구조다.

예를 들어 하나의 Row 안에서는

Income ↔ Debt
Age ↔ Income

같은 Feature 간 관계가 존재할 수 있다.

그리고 하나의 Column을 기준으로 보면

고객 A의 Income
고객 B의 Income
고객 C의 Income

처럼 Sample 간 관계도 생각할 수 있다.

v1은 Row 전체를 하나의 Token으로 압축했기 때문에
이런 2차원 구조를 직접 모델링하기 어렵다.

그래서 다음 버전에서는 아주 자연스러운 질문이 생긴다.

"Table이 2차원이라면
그 2차원 구조 자체를 모델이 보게 만들면 되지 않을까?"

여기서 TabPFN v2가 등장한다.

TabPFN v2: Row 하나가 아니라 Table의 2차원 구조를 보자

v2의 첫 번째 큰 변화는
Row Token 중심에서 2D Table Modeling으로 넘어간 것이다.

강의 자료에서는

Represent each cell as one token

이라고 설명한다.

즉 v1에서는

한 Row 전체
↓
Token 하나

였다면

v2에서는 각 Cell의 Feature-level 정보를 더 직접적으로 표현한다.

그리고 두 가지 Attention을 번갈아 사용한다.

Feature-wise Attention

Sample-wise Attention

Feature-wise Attention

Feature-wise Attention은
같은 Row 안의 Feature들이 서로 어떤 관계가 있는지 본다.

예를 들어

Age
Income
Debt

가 있다면

Income이 높은데 Debt도 높은가?

Age와 Income은 어떤 관계가 있는가?

같은 Feature 사이의 관계를 모델링할 수 있다.

Sample-wise Attention

Sample-wise Attention은
여러 Row 사이의 관계를 본다.

예를 들어

고객 A
고객 B
고객 C

가 있을 때

비슷한 Feature 패턴을 가진 고객들은
어떤 Target을 가지는가?

를 참고할 수 있다.

즉 v2는

Column 방향
+
Row 방향

을 모두 본다.

이게 v1과 가장 큰 차이다.

여기에 강의자료 11페이지의 2D Attention 그림을 넣으면 좋을 것 같다.

v2에서는 Synthetic Prior도 더 현실적으로 바뀌었다

v2의 변화는 Architecture만이 아니다.

Pretraining에 사용하는 Synthetic Task도
현실 Table에 더 가까워졌다.

강의 자료에서는 다음 요소들을 추가했다고 설명한다.

Categorical Features
Missing Values
Quantization
...

또 Synthetic Task 자체도 더 큰 규모로 확장됐다.

최대 약 10,000 Samples
최대 약 500 Features

그리고 Synthetic Data를 생성할 때도
단순한 Neural Network뿐만 아니라

Neural Network
Tree
Discretization

등 여러 형태의 구조를 활용해
더 다양한 Task를 만든다.

즉 v2는 두 가지 방향으로 발전했다고 볼 수 있다.

1. Table Architecture를 더 잘 본다.
2. Pretraining Task도 실제 Table에 더 가깝게 만든다.

v2의 성능

강의 자료에서는 TabPFN v2 역시
작은 Dataset에서 MLP와 GBDT Baseline보다 좋은 성능을 보였다고 설명한다.

특히 v2부터는 Classification뿐 아니라
Regression 결과도 함께 제시된다.

그래서

"TabPFN은 원래 Classification만 가능한 모델이다"

라고 일반화하면 정확하지 않다.

그 설명은 v1의 초기 제약에 더 가깝다.

v2는 Regression까지 범위를 넓혔다.

하지만 v2도 문제가 있다

Cell-level Representation과 2D Attention을 사용하면
당연히 계산량이 늘어난다.

예를 들어

10,000 Rows
×
500 Columns

의 Table이라면
굉장히 많은 Cell 정보를 처리해야 한다.

그리고

Feature-wise Attention
+
Sample-wise Attention

을 반복한다.

따라서 v2의 주요 한계는 다음과 같다.

Computational Cost 증가

Memory 사용량 증가

큰 Context Table 처리 어려움

Classification Evaluation은
최대 10개 Class 수준으로 제한

즉,

Table을 더 잘 이해하게 되었지만
그만큼 계산 비용이 비싸졌다.

그래서 다음 질문이 생긴다.

"Cell 수준의 정보를 활용하되
모든 정보를 끝까지 들고 다니지 않으면 안 될까?"

이 질문에서 v3가 등장한다.

TabPFN v3: 다시 Row로 압축하자

v3의 핵심 변화는 두 가지다.

1. Row Compression
2. Retrieval-based Prediction

Row Compression

v2에서는 Feature-level 정보를 상당히 오래 유지했다.

v3에서는 먼저 Feature-level 정보를 처리한 뒤
이를 Compact Row Embedding으로 압축한다.

강의 그림에는

4 CLS per row

라고 표시되어 있다.

즉 한 Row의 많은 Feature 정보를
몇 개의 CLS Token에 압축하는 형태다.

하지만 여기에서 중요한 것은
"정확히 4개를 사용한다"는 사실을 외우는 것이 아니다.

핵심은

Feature-level 정보를 ICL 전에 작은 Row Representation으로 압축한다.

는 것이다.

많은 Feature 정보
↓
Feature Aggregation
↓
Compact Row Embedding
↓
Row-level ICL

v2가

Cell 정보를 많이 유지해서 비싸다

라는 문제가 있었다면,

v3는

Feature 정보를 먼저 압축해서
Row 수준에서 효율적으로 ICL하자

라는 방향으로 바뀐 것이다.

Retrieval-based Prediction

v3의 두 번째 변화는
최종 Prediction 방식이다.

기존에는 Fixed Classification Head를 사용하는 방식이었다면
v3에서는

Attention-based Soft Nearest-Neighbor Decoder

를 사용한다.

이름만 보면 어렵지만
아이디어는 꽤 직관적이다.

Test Row가 들어오면

어떤 Training Row들이
이 Test Row와 관련이 있는가?

를 Attention Weight로 계산한다.

그리고 그 Training Row들의 Label 정보를 이용해
최종 Prediction을 만든다.

쉽게 비유하면 kNN과 조금 닮았다.

하지만

가장 가까운 K개를 딱 잘라서 동일하게 보는 것

이 아니라

Training Row마다 얼마나 참고할지를
Attention Weight로 부드럽게 결정

한다고 이해하면 된다.

v3의 성능과 확장성

강의 자료에서는 v3가
빠른 Inference Speed와 SOTA 성능을 보여준다고 설명한다.

특히 더 중요한 것은 Scalability다.

v3의 Benchmark에는

100K ~ 1M Training Samples

규모의 Classification과 Regression Task가 등장한다.

즉 초기 v1의

1,000 Samples 미만

수준에서 시작했던 모델이
v3에서는 훨씬 큰 Dataset까지 확장되고 있는 것이다.

Relational Table까지 확장: TabPFN-REL

v3에서는 단순한 Flat Table뿐 아니라
Relational Data에도 적용하려는 시도가 등장한다.

예를 들어 데이터베이스에는

User Table
Order Table
Product Table

처럼 여러 Table이 관계를 맺는 경우가 많다.

TabPFN-REL은 이러한 Relational Table을
자동으로 Flatten한 뒤 TabPFN-3를 적용한다.

강의 자료에서는

Relational Foundation Model 중에서는 SOTA

라고 설명하지만,

전체적으로는 Supervised RelGNN이 여전히 더 좋은 성능을 보인다는 한계도 함께 언급한다.

즉 Foundation Model 방식이 Relational Data까지 확장되고 있지만
아직 모든 상황에서 기존 Supervised Model을 압도하는 것은 아니다.

v1, v2, v3를 한 번에 정리하면

여기까지 내용을 가장 단순하게 정리하면 다음과 같다.

조금 더 직관적으로 보면

v1
"Row 하나를 Token으로 만들자"
↓
문제:
Table의 2차원 구조를 잘 못 본다.

v2
"그러면 Cell과 Row/Column 관계를 모두 보자"
↓
문제:
좋은데 너무 비싸다.

v3
"Feature 정보를 먼저 압축하고
Row 수준에서 효율적으로 ICL하자"

이라고 이해할 수 있다.

여기서 끝이 아니다: 최근 TabPFN 스타일 연구

강의 후반부에서는
TabPFN v1, v2, v3뿐 아니라 최근 변형 모델들을 꽤 많이 소개한다.

모델 이름은 많지만
하나씩 외우기보다는

"기존 TabPFN의 어떤 문제를 해결하려고 하는가?"

라는 관점으로 보면 이해하기 쉽다.

TabDPT: 전체 Dataset을 다 볼 필요가 있을까?

TabDPT의 핵심 아이디어는 매우 직관적이다.

Test Sample을 예측할 때
전체 Training Dataset을 모두 볼 필요가 있을까?

오히려 Test Sample과 관련 있는 Row만 보는 것이
더 좋을 수도 있다.

그래서 TabDPT는

Test Sample
↓
Training Data에서 비슷한 Row 검색
↓
Top-K Row 선택
↓
그 Row들만 Context로 사용
↓
ICL Prediction

을 수행한다.

즉 네 필기에서 적었던

"K개만 뽑아서 한다"

가 맞다.

정확히는 K개의 가장 비슷한 Row를 Retrieval해서 Context로 사용한다.

TabDPT는 Row를 하나의 Token으로 본다는 점에서는
TabPFN v1과 비슷하다.

TabDPT의 또 다른 차이: 실제 Table로 Pretraining

기존 TabPFN은 Synthetic Prior가 굉장히 중요했다.

TabDPT는 조금 다른 방향도 시도한다.

실제 Real-world Tabular Data를 이용해 Pretraining하자.

그리고 Masked Column Self-Supervised Learning을 사용한다.

쉽게 말하면

Table의 일부 Column 값을 가린다.
↓
나머지 정보를 보고
가려진 값을 맞혀본다.

와 비슷하다.

강의 자료에서는

Real-world Pretraining
+
ICL Retrieval
+
SSL

의 조합이 Robust한 Downstream Generalization을 만든다고 설명한다.

또 실제 데이터로 Pretraining했을 때
순수 Synthetic Data Generator만 사용한 것보다
더 빠른 Convergence와 좋은 Downstream Accuracy를 보였다고 소개한다.

Semi-supervised 상황에서도 활용할 수 있다

TabDPT에서는 Semi-supervised Setting도 다룬다.

즉 Training Data 중 일부에만 Label이 있는 상황이다.

Label 있음
Label 있음
Label 없음
Label 없음
...

이때 모델이 Unlabeled Data에 대해
자신의 Prediction을 만들어

Pseudo-label

로 사용한다.

그리고 그 데이터를 다시 Context에 추가한다.

즉,

Label이 적다
↓
모델이 Unlabeled Data를 예측
↓
Pseudo-label 생성
↓
Context 확장
↓
더 나은 ICL

이라는 구조다.

TabICL: v2의 2D Attention이 너무 비싸다면?

TabPFN v2의 문제는
Row/Column Attention을 반복하면서 비용이 커진다는 것이다.

TabICL은 이를 두 단계로 나눈다.

Stage 1
Feature 정보를 처리
↓
Fixed-dimensional Row Embedding 생성

Stage 2
Row Embedding들 사이에서 ICL

즉

Feature 관계를 먼저 Row 하나에 압축하고
그다음 Row끼리 In-Context Learning을 한다.

는 것이다.

이렇게 하면 큰 Dataset에서 계산량을 줄일 수 있다.

강의 자료의 Complexity를 보면

TabICL
O(m²n + n²)

TabPFN v2
O(m²n + mn²)

로 정리된다.

여기서

n = Row 수
m = Column 수

다.

특히 Row 수가 커질수록
mn²에서 n²로 줄어드는 차이가 커진다.

강의에서는 TabICL이 TabPFN v2와 경쟁력 있는 성능을 유지하면서
더 큰 Dataset에 잘 Scaling된다고 설명한다.

TabICLv2

TabICLv2는 TabICL을 더 발전시킨 모델이다.

강의에서는 다음 변화들을 소개한다.

Richer Synthetic Data Generation Engine

Circular-shift Feature Grouping

Target-aware Embedding

QASSMax

Optimized Pretraining Protocol

Muon Optimizer

각각을 깊게 들어가면 꽤 복잡하지만
큰 방향은 명확하다.

더 다양한 Task를 만들고,
Feature Representation이 무너지는 것을 줄이고,
Label 정보를 더 일찍 활용하고,
긴 Context에서도 Attention을 효율적으로 처리하자.

강의 자료에서는 TabICLv2가
최근 Baseline보다 Overall Performance가 좋고,
큰 Dataset에서도 좋은 Scalability를 보이며,
여러 Hardware에서 TabPFN-2.5보다 빠른 Inference를 보였다고 소개한다.

TACO: Context 자체를 압축하면?

TACO의 아이디어는 더 단순하다.

Tabular ICL에서 가장 비싼 것 중 하나가
긴 Context 전체에 Attention을 수행하는 것이다.

그렇다면

Context 자체를 미리 압축하면 안 될까?

라는 생각이다.

Large Training Context
↓
Compressor
↓
Compact Latent Representation
↓
Predictor

Training Sample 전체를 그대로 들고 다니는 대신
중요한 정보를 작은 Latent Representation에 압축한다.

강의 자료에서는 Predictor-only Transformer와 비교해

53× Speedup

94% Memory Reduction

을 달성하면서도 큰 성능 저하는 없었다고 소개한다.

이 수치만 봐도
최근 Tabular Foundation Model 연구에서
Compression과 Scalability가 얼마나 중요한지 알 수 있다.

MITRA: 좋은 Architecture만큼 Prior도 중요하다

PFN을 공부하면서 계속 등장하는 것이 있다.

바로 Prior다.

MITRA는 이 부분을 직접 다룬다.

기존처럼 하나의 Synthetic Prior에만 의존하지 않고

Prior A
Prior B
Prior C
...

처럼 여러 Synthetic Task Generator를 섞는다.

핵심 아이디어는 다음과 같다.

Prior Design은 Model Architecture만큼 중요하다.

강의 결과에서도 SCM Prior 자체가 강력한 Standalone Prior였고,
여러 Prior를 혼합했을 때 Robustness가 향상되는 모습을 보였다.

즉 아무리 좋은 Transformer를 만들어도
Pretraining에서 경험하는 Task가 너무 단순하거나 편향되어 있다면
좋은 Generalization을 기대하기 어렵다는 것이다.

ConTextTab: Column 이름의 의미도 활용하자

기존 TabPFN 계열은
주로 Table의 값과 구조에 집중한다.

하지만 실제 Table에서는 Column 이름 자체에도
굉장히 중요한 정보가 들어 있다.

예를 들어

25

라는 값만 보면 아무 의미가 없다.

하지만

Age = 25

라고 하면 의미가 생긴다.

또

Price = 25

라면 완전히 다른 뜻이다.

ConTextTab은 이런 Semantic Information을 In-Context Learning에 넣는다.

강의에서는

Column Name

Text / Categorical Value

에 Pretrained Text Embedding을 사용한다고 설명한다.

Text/Categorical Feature에는

all-MiniLM-L6-v2

를 사용하고,

날짜는

Day
Month
Year

를 각각 Embedding한 뒤 합친다.

강의 자료에서는 ConTextTab이
Semantic Information이 풍부한 CARTE Benchmark에서 SOTA 결과를 보였다고 소개한다.

MultiModalPFN: Table에 이미지와 텍스트까지 있다면?

현실의 데이터가 항상 순수한 Table만으로 구성되는 것은 아니다.

예를 들어 쇼핑 데이터라면

상품 가격
상품 카테고리
상품 판매량
+
상품 이미지
+
상품 설명 Text

가 함께 존재할 수 있다.

MultiModalPFN은 TabPFN을
이런 Multimodal Setting으로 확장한다.

Tabular Feature
Image
Text
↓
각 Modality Encoder
↓
TabPFN이 사용할 수 있는 Representation으로 변환
↓
함께 Prediction

즉

Table + Image + Text

를 동시에 사용하도록
TabPFN의 범위를 확장하는 것이다.

nanoTabPFN

nanoTabPFN은
완전히 새로운 모델이라기보다

TabPFN v2를 쉽게 공부하고 실험할 수 있도록 만든 Lightweight Reimplementation

에 가깝다.

강의에서는

500줄 이하의 코드

로 TabPFN v2의 핵심 Architecture와 Training Loop를 구현했다고 소개한다.

그리고 Single GPU에서도
몇 분 안에 Pretraining을 실험할 수 있도록 했다.

개인적으로는 TabPFN 내부 동작을 직접 공부하고 싶다면
이런 프로젝트가 오히려 가장 도움이 될 것 같았다.

결국 최근 연구는 어디로 가고 있을까?

강의 마지막에서는 Tabular Foundation Model의 Open Direction을
크게 네 가지로 정리한다.

1. Scalability and Efficiency

TabPFN은 처음에는 작은 Dataset에 강한 모델이었다.

하지만 최근에는

100K
1M

규모의 Dataset까지 확장되고 있다.

그럼에도

Memory
Latency
Long-context Processing

은 여전히 중요한 Bottleneck이다.

그래서

Row Compression
Context Compression
Retrieval
Efficient Attention

같은 방법이 계속 등장하고 있다.

2. Pretraining Distribution

또 하나 중요한 문제는

무엇으로 Pretraining할 것인가?

이다.

한쪽에는

Synthetic Prior

가 있고,

다른 한쪽에는

Real-world Table

이 있다.

Synthetic Data는 원하는 만큼 다양한 Task를 만들 수 있다는 장점이 있고,
Real-world Data는 실제 Table의 복잡한 특성을 직접 반영한다는 장점이 있다.

강의에서는 이 두 방향이 경쟁 관계라기보다
서로 보완적인 Signal이라고 설명한다.

3. Semantic and Heterogeneous Tables

현실 Table에는 숫자만 존재하지 않는다.

Column Name
Text
Categorical Value
Missingness
Date
Mixed Feature Types

같은 정보가 존재한다.

ConTextTab처럼
이런 의미 정보를 어떻게 활용할지 역시 중요한 연구 방향이다.

4. Beyond Standard Flat Tables

마지막으로 앞으로는
단순한 하나의 Flat Table만 다루지 않을 가능성이 크다.

Relational
Temporal
Multimodal
Causal

구조까지 Tabular Foundation Model이 확장되고 있다.

TabPFN-REL과 MultiModalPFN이
이미 그 방향을 보여주고 있다고 생각한다.

이번 강의를 들으며 느낀 점

처음에는 Foundation Model이라고 하면
GPT처럼 엄청나게 많은 데이터를 학습한 거대한 모델만 떠올렸다.

그런데 PFN은 조금 다른 관점을 보여준다.

다양한 문제를 미리 만들어서 많이 풀어본다.
↓
"문제를 푸는 방법"을 학습한다.
↓
새로운 Dataset이 들어오면
그 Training Data를 Context로 본다.
↓
별도의 재학습 없이 Prediction한다.

이 아이디어가 가장 인상 깊었다.

또 v1 → v2 → v3의 발전 과정도 재미있었다.

v1
Row 하나를 Token으로 만들자.
↓
문제:
Table의 2차원 구조를 잘 못 본다.

v2
그러면 Row와 Column 방향을 모두 보자.
↓
문제:
계산량과 Memory가 너무 커진다.

v3
Feature 정보를 먼저 압축하고
Row 수준에서 효율적으로 ICL하자.

결국 모델이 발전하는 과정은
무조건 더 복잡하게 만드는 것이 아니라

표현력을 높이면서 계산 비용을 다시 줄이는 과정

처럼 느껴졌다.

그리고 이번 강의를 통해
Architecture만큼 Pretraining Task를 어떻게 만들 것인가도 중요하다는 점을 알게 됐다.

좋은 Transformer를 만드는 것만으로 끝나는 것이 아니라

어떤 Prior를 사용할 것인가?

Synthetic Data를 얼마나 현실적으로 만들 것인가?

실제 Table도 Pretraining에 사용할 것인가?

같은 질문들이 성능에 직접적인 영향을 준다.

결론

TabPFN의 핵심을 한 문장으로 정리하면 다음과 같다.

수많은 Tabular Task를 미리 학습해두고,
새로운 Dataset의 Training Data를 Context로 사용하여
별도의 Parameter Update 없이 예측하는 Tabular Foundation Model이다.

전체 흐름은 다음과 같다.

Prior 설계
↓
수많은 Synthetic Task 생성
↓
Transformer 기반 PFN 사전학습
↓
새로운 Dataset 등장
↓
Training Data를 Context로 입력
↓
In-Context Learning
↓
Parameter Update 없이 Prediction

그리고 TabPFN은 계속 발전하고 있다.

v1
Row Token

↓

v2
2D Table Modeling
+ Richer Synthetic Prior

↓

v3
Row Compression
+ Retrieval-based Prediction

최근 연구는 여기에

Top-K Retrieval
Real-world Pretraining
Context Compression
Mixed Synthetic Priors
Semantic Information
Multimodal Data

까지 결합하고 있다.

이전까지 Tabular ML에서는
새로운 Dataset이 주어지면 그 Dataset에 맞는 모델을 학습하고
Hyperparameter를 튜닝하는 것이 당연하다고 생각했다.

TabPFN은 이 전제를 바꾼다.

"모델을 데이터셋마다 다시 학습하는 대신,
데이터셋을 보고 문제를 푸는 방법 자체를 미리 학습할 수는 없을까?"

아마 이 질문이
TabPFN이라는 새로운 패러다임의 가장 핵심적인 아이디어가 아닐까 싶다.

오늘은 오픈소스 개발자 프로젝트를 진행하면서 마주친
Spring의 간단한 원칙들과 의존성 주입(DI)을 이해하기 전에 알아야 할 내용을 정리해보고자 한다.

프로젝트 코드를 보다 보니 다음과 같은 코드들이 계속 등장했다.

@Component
class LsTrDispatcher {
}

@RestController
class LsController {
}

@Bean
SimulationEngine simulationEngine() {
    return new SimulationEngine(...);
}

Java 코드는 어느 정도 익숙한데
문제는 앞에 붙어 있는 녀석들이었다.

@Component
@RestController
@Bean

@ 뒤에 붙어 있는 저 꼬리표들은 대체 뭘까?

이번 글에서는 이 세 가지가 무엇인지부터
Spring이 왜 객체를 직접 관리하려고 하는지까지 정리해보려고 한다.

먼저 Annotation이란?

Java에서 @로 시작하는 것을
Annotation(애노테이션)이라고 한다.

예를 들어 다음과 같은 것들이다.

@Override
@Deprecated
@Component
@RestController
@Bean

애노테이션은 쉽게 말하면
코드에 추가적인 정보나 의미를 붙이는 표시라고 생각할 수 있다.

그리고

@Component
@RestController
@Bean

은 Spring에서 사용하는 애노테이션들이다.

이 애노테이션들을 통해 Spring에게

"이 클래스는 네가 관리해."

"이 클래스는 REST API 요청을 처리해."

"이 메서드가 반환하는 객체를 네가 관리해."

같은 정보를 전달할 수 있다.

그렇다면 하나씩 알아보자.

1. @Component

@Component를 정말 쉽게 표현하면 다음과 같다.

"이 클래스의 객체는 Spring이 만들어서 관리해줘."

예를 들어 다음 클래스가 있다고 해보자.

class LsTrDispatcher {
}

일반적인 Java 코드라면 이 객체가 필요할 때
개발자가 직접 객체를 생성할 수 있다.

LsTrDispatcher lsTrDispatcher = new LsTrDispatcher();

즉,

개발자가 직접 new
↓
객체 생성
↓
개발자가 사용

하는 것이다.

그런데 클래스에 @Component를 붙이면 달라진다.

@Component
class LsTrDispatcher {
}

Spring은 애플리케이션이 시작될 때
컴포넌트 스캔 대상에서 이 클래스를 발견하고 객체를 생성해 관리한다.

쉽게 표현하면 Spring이 이렇게 받아들이는 것이다.

@Component 발견

"아, LsTrDispatcher는 내가 관리해야 하는 객체구나."

↓

LsTrDispatcher 객체 생성

↓

Spring Container에서 관리

그러면 개발자가 필요한 곳마다

new LsTrDispatcher();

를 반복해서 작성하며 직접 관리할 필요가 줄어든다.

처음 이걸 알고 나서는

엄청 편리한데?
이래서 Java 개발자들이 Spring을 쓰는 건가?

라는 생각이 들었다.

물론 Spring을 사용하는 이유가 이것 하나뿐인 것은 아니지만,
객체 생성과 관계를 Spring에게 맡길 수 있다는 점은 굉장히 큰 장점이다.

Spring Bean이란?

여기서 하나의 새로운 용어가 등장한다.

Bean이다.

Spring이 생성하고 Spring Container에서 관리하는 객체를
일반적으로 Spring Bean이라고 부른다.

예를 들어

@Component
class LsTrDispatcher {
}

가 Spring에 의해 등록되었다면
LsTrDispatcher 객체는 Spring Bean이 된다.

구조를 단순하게 표현하면 다음과 같다.

Spring Container

└── LsTrDispatcher 객체
        ↑
     Spring Bean

즉,

Bean
=
Spring Container가 관리하는 객체

라고 우선 이해하면 된다.

2. @RestController

다음은 @RestController다.

@RestController
class LsController {
}

이것도 Spring이 해당 클래스를 관리하도록 만드는 애노테이션이다.

하지만 @Component보다 추가적인 의미가 있다.

쉽게 표현하면 다음과 같다.

"이 클래스는 Spring이 관리하면서 HTTP 요청도 처리하는 REST Controller야."

예를 들어 다음 코드가 있다고 해보자.

@RestController
class LsController {

    @GetMapping("/orders")
    public String orders() {
        return "주문 목록";
    }
}

클라이언트가 다음 요청을 보낸다고 해보자.

GET /orders

그러면 Spring이 해당 요청을 적절한 Controller 메서드와 연결하고
orders()가 실행된다.

사용자 / 클라이언트
        ↓
    HTTP 요청
        ↓
@RestController
   LsController
        ↓
    orders()
        ↓
    "주문 목록"
        ↓
    HTTP 응답

즉, @RestController는 외부 HTTP 요청이 애플리케이션 내부로 들어오는 입구 역할을 하는 클래스에 붙일 수 있다.

@Component와 @RestController의 관계

여기서 조금 헷갈렸다.

@Component
class LsTrDispatcher {
}

도 Spring이 관리하고,

@RestController
class LsController {
}

도 Spring이 관리한다.

그렇다면 둘의 차이는 뭘까?

핵심은 역할이다.

@Component
→ 일반적인 Spring 관리 Component

@RestController
→ Spring이 관리하는 Component
  + REST API 요청 처리 역할

실제로 @RestController는 내부적으로 @Controller와 @ResponseBody의 의미를 결합한 애노테이션이고, @Controller 역시 Spring의 component stereotype에 속한다.

따라서 지금 단계에서는 이렇게 이해하면 편하다.

@RestController도 Spring Bean으로 관리되지만,
HTTP API Controller라는 추가적인 역할을 가진다.

3. @Bean

마지막으로 @Bean이다.

@Bean
SimulationEngine simulationEngine() {
    return new SimulationEngine(...);
}

쉽게 표현하면 다음과 같다.

"이 메서드가 반환하는 객체를 Spring이 관리해줘."

그런데 처음 봤을 때 이런 생각이 들었다.

뭐야? @Component랑 똑같은 거 아닌가?

맞다.

결과만 보면 둘 다
객체를 Spring Bean으로 등록해 관리하도록 한다는 공통점이 있다.

하지만 Bean을 등록하는 방법이 다르다.

@Component VS @Bean

가장 큰 차이는
애노테이션을 어디에 붙이는지 보면 이해하기 쉽다.

@Component

클래스에 붙인다.

@Component
class LsTrDispatcher {
}

Spring은 컴포넌트 스캔을 통해 이 클래스를 발견하고
객체를 생성해 관리한다.

@Component
      ↓
LsTrDispatcher 클래스 발견
      ↓
Spring이 객체 생성
      ↓
Spring Container에 등록

@Bean

메서드에 붙인다.

@Bean
SimulationEngine simulationEngine() {
    return new SimulationEngine(...);
}

Spring은 이 메서드가 반환한 객체를
Spring Bean으로 등록해 관리한다.

@Bean
  ↓
simulationEngine() 실행
  ↓
SimulationEngine 객체 반환
  ↓
Spring Container에 등록

개념적으로 보면 다음 코드로 만들어지는 객체를

SimulationEngine engine =
        new SimulationEngine(...);

Spring Container가 관리하도록 등록한다고 이해할 수 있다.

그런데 왜 굳이 두 가지 방법이 존재할까?

여기서 중요한 차이가 하나 더 있다.

내가 직접 작성한 클래스라면
클래스 자체에 @Component를 붙일 수 있다.

@Component
class LsTrDispatcher {
}

하지만 외부 라이브러리의 클래스라면 어떨까?

예를 들어 내가 직접 수정할 수 없는 클래스가 있다고 해보자.

SimulationEngine

클래스 소스 코드에 직접

@Component

를 붙일 수 없다면,
설정 클래스에서 객체를 직접 생성해 Bean으로 등록할 수 있다.

예를 들어 다음과 같은 형태다.

@Configuration
class AppConfig {

    @Bean
    SimulationEngine simulationEngine() {
        return new SimulationEngine(...);
    }
}

즉,

@Component
→ 클래스 자체를 Spring이 찾아서 등록

@Bean
→ 개발자가 객체 생성 방법을 직접 정의해서 등록

이라고 이해하면 훨씬 명확하다.

@Bean은 외부 라이브러리뿐 아니라, 생성 과정에 세밀한 설정이 필요한 객체를 등록할 때도 유용하다.

세 가지를 비교하면?

지금까지 살펴본 내용을 정리하면 다음과 같다.

조금 더 쉽게 정리하면 다음과 같다.

@Component

"이 클래스 Spring이 관리해."

@RestController

"이 클래스 Spring이 관리하고
REST API 요청도 처리해."

@Bean

"이 메서드가 만든 객체 Spring이 관리해."

결국 핵심은 Spring이 객체를 관리한다는 것

여기까지 공부하고 나니
세 애노테이션을 관통하는 하나의 공통점이 보였다.

바로 객체 관리다.

일반적인 Java 코드에서는 개발자가 직접 객체를 만들 수 있다.

new SimulationEngine();

new LsTrDispatcher();

new LsController();

그리고 객체 사이의 관계도 개발자가 직접 연결한다.

하지만 Spring에서는
이런 객체들의 생성과 관계 설정을 Spring Container에 맡기는 방식을 적극적으로 사용한다.

내 프로젝트의 구조를 아주 단순화하면
다음과 같이 생각할 수 있다.

Spring Container
│
├── LsTrDispatcher 객체
│       ↑
│   @Component
│
├── LsController 객체
│       ↑
│   @RestController
│
└── SimulationEngine 객체
        ↑
      @Bean

Spring Container 안에는
애플리케이션에서 사용할 여러 객체들이 Bean으로 등록되어 있다.

그리고 필요한 객체가 있다면
Spring이 그 객체를 필요한 곳에 연결해줄 수 있다.

여기서 다음 개념으로 이어진다.

그런데 왜 Spring이 객체를 관리해야 할까?

여기까지 이해하고 나니 새로운 의문이 생겼다.

예를 들어 LsController가 LsTrDispatcher를 사용해야 한다고 해보자.

그냥 이렇게 하면 되는 것 아닌가?

@RestController
class LsController {

    private final LsTrDispatcher dispatcher =
            new LsTrDispatcher();
}

Java 문법상 전혀 이상하지 않다.

그런데 Spring에서는 왜 굳이

@Component
class LsTrDispatcher {
}

처럼 객체를 Bean으로 등록하고
Spring에게 관리를 맡기는 것일까?

이 질문을 이해하면

@Component

@Bean

Spring Container

가 왜 필요한지도 자연스럽게 연결된다.

바로 의존성 주입(Dependency Injection, DI) 때문이다.

다음 글: 의존성 주입(DI)

이번 글에서는 일단 여기까지만 정리하고자 한다.

@Component
→ 클래스를 Spring Bean으로 등록

@RestController
→ REST API Controller 역할을 하는 Spring Bean

@Bean
→ 메서드가 반환한 객체를 Spring Bean으로 등록

그리고 이 객체들은
Spring Container에서 관리된다.

그렇다면 다음 질문은 이것이다.

LsController가 LsTrDispatcher를 필요로 할 때
왜 직접 new LsTrDispatcher()를 하지 않을까?

이 질문이 바로
Spring의 핵심 개념 중 하나인 의존성 주입(DI)으로 이어진다.

Spring의 중요 원칙, 의존성 주입(DI)에 관한 이야기는 다음 글에서 이어서 정리해보고자 한다.

(USC 빅데이터) 개인 과제 프로젝트 : YOLO 트럭 객체 탐지 성능 개선 + 근데 이제 LA 관광을 곁들인(?)

USC에서 미국 대학생활을 체험하고 있던 어느 날.

조교님들로부터 갑작스럽게 과제가 하나 주어졌다.

그런데 그냥 과제가 아니었다.

개인전.

그리고 주어진 시간은 사실상 단 하루.

각자 YOLO 모델의 성능을 최대한 끌어올리고, 최종 성능 점수에 따라 순위를 매겨 상위권 학생은 자신의 성능 개선 방법을 발표하는 작은 대회가 열린 것이다.

심지어 간단한 상품도 있다고 했다.

이 이야기를 듣자마자 갑자기 욕심이 생겼다.

"이거 1등 하고 싶은데?"

앞서 공식적으로 진행됐던 팀 해커톤에서는 아쉽게 수상하지 못했기 때문에 여기서라도 지금까지 공부했던 AI 역량을 마음껏 펼쳐보고 싶었다.

마침 이번에는 개인전이기도 했다.

그렇게 나만의 작은 해커톤이 시작됐다.

과제부터 제대로 읽어보자

일단 무작정 모델부터 학습시키기보다는 과제가 정확히 무엇을 요구하는지부터 살펴봤다.

과제의 제목은 아주 직관적이었다.

Homework: Detect the Trucks

트럭을 탐지하는 YOLO 모델을 학습시키고, Test Set에서 얼마나 정확하게 탐지하는지 확인하는 것이 목표였다.

원문

Homework: Detect the Trucks
Due: Friday, at the start of class.

The task
Train a YOLO model on the truck dataset and find out how accurate it is on the test set.

That's the whole assignment. But you have room to be clever about it, and the top 3 scores get recognized on Friday.

간단하게 번역하면

과제: 트럭을 탐지하라
제출: 금요일 수업 시작 전

제공된 트럭 데이터셋으로 YOLO 모델을 학습하고 Test Set에서 모델의 정확도를 측정한다.

기본적인 과제는 여기까지지만, 각자 다양한 방법으로 모델의 성능을 개선할 수 있으며 상위 3개의 성능은 금요일에 발표한다.

기본으로 제공된 모델은 yolov8n.pt였다.

from ultralytics import YOLO

model = YOLO('yolov8n.pt')

model.train(
    data='/content/truck_dataset/truck_data.yaml',
    epochs=30,
    imgsz=640,
    batch=8,
    name='my_run'
)

학습이 끝나면 Test Set에서 다음 지표를 측정한다.

metrics = model.val(split='test')

print(f"mAP50     : {metrics.box.map50:.4f}")
print(f"mAP50-95  : {metrics.box.map:.4f}")
print(f"Precision : {metrics.box.mp:.4f}")
print(f"Recall    : {metrics.box.mr:.4f}")

최종적으로 확인하는 값은

• mAP50
• mAP50-95
• Precision
• Recall

등이었다.

이 중 순위를 결정하는 가장 중요한 지표는 mAP50이었고, 동점일 경우 mAP50-95를 기준으로 순위를 결정한다고 했다.

그냥 돌리면 다 비슷한 점수가 나온다

재미있는 부분은 여기부터였다.

과제 설명에는 이런 내용이 있었다.

Everyone who follows the tutorial exactly will get roughly the same score.

즉,

튜토리얼을 그대로 따라 하면 모두 비슷한 점수가 나온다는 것이다.

상위권으로 올라가려면 무언가를 직접 바꿔야 했다.

조교님들이 제시한 방법은 여러 가지였다.

1. 더 오래 학습하기

기본 30 Epoch에서 50 또는 100 Epoch까지 늘려볼 수 있다.

다만 Loss가 다시 증가하기 시작하는지도 확인해야 한다.

2. 더 큰 모델 사용하기

yolov8n
   ↓
yolov8s
   ↓
yolov8m

모델의 표현력이 높아질 수 있지만 계산량과 학습 시간도 함께 증가한다.

3. 더 새로운 YOLO 사용하기

YOLOv8
  ↓
YOLO11

yolov8n.pt 대신 yolo11n.pt, yolo11s.pt 같은 모델도 사용할 수 있었다.

4. 이미지 크기 변경하기

기본 설정은

imgsz=640

이었지만, 작은 트럭이나 멀리 있는 트럭을 더 잘 잡기 위해

imgsz=960

처럼 입력 해상도를 변경해 볼 수 있었다.

5. Learning Rate 조절하기

lr0 = 0.001
lr0 = 0.0001

처럼 학습률을 직접 조절할 수도 있었다.

6. Ensemble

두 모델이 서로 다른 실수를 한다는 점을 이용해 여러 모델의 결과를 합치는 방법도 Extra Credit으로 소개됐다.

대표적으로

• NMS Ensembling
• Weighted Boxes Fusion(WBF)

등이 있었다.

그런데 점수만 높으면 되는 건 아니었다

개인적으로 과제 설명에서 마음에 들었던 부분이다.

조교님들은 단순히

"누가 가장 높은 점수를 얻었는가?"

만 보는 것이 아니었다.

과제에는 다음과 같은 문장이 있었다.

Keep a log. Write down what you changed and what score you got. The log is worth as much as the score — on Friday we want to hear why things did or didn't work.

즉,

무엇을 변경했고, 그 결과 점수가 어떻게 변했는지를 기록하라는 것이었다.

금요일에는 단순히

"점수가 이렇게 나왔습니다."

가 아니라

왜 좋아졌는지
왜 떨어졌는지

설명할 수 있어야 했다.

또 하나 굉장히 중요한 규칙도 있었다.

Never train on the test set.

Test Set을 학습에 사용하는 것은 절대 금지였다.

이건 단순한 과제 규칙이 아니라 실제 머신러닝에서도 굉장히 중요한 원칙이라고 강조하셨다.

좋다.

규칙은 이해했다.

이제 진짜 성능을 올려볼 차례다.

그런데 YOLO가 정확히 뭐지?

과제가 YOLO를 이용한 Object Detection이라는 것은 알겠는데,

막상 생각해보니 YOLO의 원리를 제대로 설명해 본 적은 없었다.

그래서 우선 Object Detection부터 다시 정리했다.

Object Detection은 단순히

이 이미지에는 트럭이 있다.

라고 분류하는 문제가 아니다.

이미지 안에서

어떤 객체인가?
+
어디에 있는가?

를 동시에 찾아야 한다.

즉 모델은 일반적으로

• 객체의 클래스
• Bounding Box
• Confidence

를 함께 출력한다.

이번 과제에서는 여러 종류의 객체를 찾는 것이 아니라 truck이라는 단일 클래스의 위치를 정확하게 찾는 것이 목표였다.

그리고 여기서 사용하는 것이 YOLO다.

YOLO는

You Only Look Once

의 약자다.

이미지 전체를 하나의 통합된 추론 과정에서 분석해 객체의 위치와 클래스를 함께 예측하는 대표적인 Single-Stage Object Detector 계열이다.

전통적인 Two-Stage Detector는

객체가 있을 만한 영역 탐색
        ↓
각 영역 분류 및 위치 보정

처럼 여러 단계를 거치는 반면,

YOLO 계열은 하나의 모델 안에서 객체의 위치와 클래스를 함께 예측하는 방식이라 비교적 빠른 추론이 가능하다.

그래서

• CCTV
• 자율주행
• 로봇 비전
• 실시간 객체 탐지

같은 분야에서도 많이 활용된다.

물론 YOLO가 항상 다른 탐지 모델보다 좋은 것은 아니다.

작거나 멀리 있는 객체,

가려진 객체,

화면 밖으로 일부가 잘린 객체 등은 여전히 어려운 문제다.

그리고 이번 과제에서 바로 작은 객체가 중요한 문제가 되었다.

바로 구현하지 않고 파이프라인부터 만들었다

YOLO가 어떤 모델인지 이해한 다음에도 바로 학습부터 시작하지 않았다.

먼저 Codex와 함께 작업할 프로젝트 폴더를 만들고

• 과제 PDF
• 데이터
• 코드
• 실험 로그
• 제출 자료

를 한곳에서 관리할 수 있도록 구성했다.

그리고 생각했다.

"하루 동안 여러 실험을 해야 하는데 매번 코드를 수정하고 결과를 직접 기록하고 있으면 너무 느리지 않을까?"

그래서 먼저 실험 파이프라인을 만드는 것에 집중했다.

대략 다음 흐름으로 설계했다.

과제 요구사항 확인
      ↓
실행 환경 검사
      ↓
데이터 무결성 검사
      ↓
Baseline 학습
      ↓
Validation
      ↓
실험 설정 기록
      ↓
학습 결과 저장
      ↓
그래프 / 예측 이미지 확인
      ↓
이전 실험과 비교
      ↓
다음 실험 결정

그리고 몇 가지 안전장치도 넣었다.

Ultralytics 버전 고정
Seed 고정
Deterministic 실행
Dataset Commit 기록
SHA256 저장
GPU 연결 여부 검사
best.pt 자동 저장
중단 시 last.pt에서 복구
실험 설정 및 점수 자동 기록

특히 공식 Test는 모델 선택 과정에서 실수로 실행하지 않도록 따로 막아두었다.

이 구조를 먼저 만든 것이 결과적으로 꽤 큰 도움이 됐다.

다른 설정을 시험할 때마다 코드를 다시 만들 필요가 없었고,

나는

"다음에는 무엇을 바꿔야 할까?"

에 더 많은 시간을 사용할 수 있었다.

Validation은 단순한 점수 확인이 아니었다

이번 프로젝트를 진행하면서 Validation을 보는 시각도 조금 달라졌다.

처음에는 Validation을

"학습 끝나고 점수 한 번 보는 것"

정도로 생각하기 쉬웠다.

하지만 실제 역할은

여러 모델 중 무엇을 선택할지 판단하는 데이터

에 가깝다.

그래서 다음 원칙을 잡았다.

Train
→ 모델 학습

Validation
→ 실험 비교 / 모델 선택

Test
→ 모델 확정 후 최종 평가

Test 결과를 계속 보면서 설정을 바꾸기 시작하면 결국 Test에 맞춰 간접적으로 모델을 튜닝하게 된다.

그래서 가능하면 Test를 최대한 마지막까지 보지 않는 구조를 유지했다.

Visualization도 적극적으로 사용했다

숫자 하나만 보고 모델을 선택하고 싶지는 않았다.

그래서

• Train / Validation Loss
• Epoch별 mAP50
• Epoch별 mAP50-95
• Precision–Recall Curve
• F1–Confidence Curve
• 실제 Bounding Box 예측 결과

등도 함께 확인했다.

특히 마지막 Epoch의 점수 하나만 보는 것이 아니라

후반 Epoch에서 점수가 안정적으로 유지되는가?

도 중요하게 봤다.

좋은 점수가 한 번 튀어나왔다가 바로 무너지는 모델과,

조금 낮아도 계속 안정적으로 유지되는 모델은 다르게 봐야 한다고 생각했기 때문이다.

일단 데이터부터 보자

이제 본격적으로 EDA를 시작했다.

"내가 지금 학습시키려는 데이터가 대체 어떻게 생겼지?"

부터 확인했다.

전체 데이터는 다음과 같았다.

특징은 다음과 같았다.

Class : truck 단일 클래스
총 이미지 : 439장
Bounding Box : 809개
원본 이미지 : 640×360
이미지당 평균 트럭 : 약 1.84개

439장.

생각보다 굉장히 작은 데이터셋이었다.

따라서 처음부터 너무 큰 모델을 사용하는 것도 조금 위험해 보였다.

데이터가 적을수록 모델이 데이터를 외워버리는 Overfitting 가능성이 높아지기 때문이다.

트럭 크기를 살펴봤더니

Bounding Box 크기도 분석했다.

COCO 기준으로 나누었을 때 분포는 다음과 같았다.

즉,

전체 객체의 94%가 Small 또는 Medium 객체였다.

여기서 하나의 가설을 세웠다.

작은 트럭과 먼 거리의 트럭이 대부분이라면 Epoch를 무작정 늘리는 것보다 입력 해상도를 높이는 것이 더 직접적인 개선 방법 아닐까?

원본 설정은

imgsz = 640

이었다.

그래서

640
↓
960
↓
1280

까지 입력 크기를 늘려보기로 했다.

해상도를 높인다고 원본 이미지에 없던 정보가 새로 생기는 것은 아니다.

하지만 모델 내부에서 이미지를 처리할 때 작은 객체가 지나치게 축소되는 현상을 줄일 수 있다고 판단했다.

최종적으로는 imgsz=1280을 사용했다.

YOLOv8n에서 YOLO11s로

기본 모델은

YOLOv8n

이었다.

Nano 모델은 굉장히 가볍고 빠르다는 장점이 있다.

하지만 작은 객체가 많은 현재 데이터에서는 조금 더 높은 표현력을 가진 모델을 사용해 볼 가치가 있다고 생각했다.

그렇다고 가장 큰 모델을 사용할 수도 없었다.

데이터 : 307장
GPU : Colab T4
시간 : 하루

라는 조건이 있었기 때문이다.

모델이 너무 커지면 한 번의 실험 시간이 길어지고,

그만큼 내가 시도할 수 있는 실험 횟수가 줄어든다.

그래서 성능과 실험 속도 사이의 타협점으로

YOLO11s

를 선택했다.

그런데 데이터가 뭔가 이상하다

EDA를 하면서 이미지를 계속 보다 보니 이상한 느낌이 들었다.

배경이 너무 비슷했다.

"이거 혹시 같은 CCTV 영상에서 뽑은 거 아닌가?"

파일명을 확인해봤다.

Regular-18-XX.MP4#t=OO.jpg

실제로 이미지들은 독립적인 사진이 아니라 9개의 원본 영상에서 특정 시간의 프레임을 추출한 데이터였다.

그래서 영상 ID를 파싱해 Train / Validation / Test 분포를 확인했다.

결과는 조금 충격적이었다.

즉,

모든 Test 이미지가 Train과 같은 원본 영상에서 나온 프레임이었다.

파일은 다른데 장면은 같은데?

처음에는 파일 중복 검사를 해봤다.

동일한 파일은 없었다.

그런데 문제가 이것이었다.

Train : 영상의 10초 프레임
Test  : 영상의 11초 프레임

이라면 파일 자체는 다르지만 거의 같은 장면이다.

그래서 Test 이미지와 같은 영상에서 추출된 가장 가까운 Train 프레임의 시간 차이를 계산했다.

Test 이미지 44장 전부가 Train 이미지와 최대 3초 이내의 프레임이었다.

여기서 생각했다.

"이 정도면 새로운 장면을 맞히는 것보다 익숙한 배경을 다시 보는 것에 가까운 것 아닌가?"

pHash까지 확인해봤다

그래서 이미지 자체가 얼마나 비슷한지도 확인해봤다.

일반적인 파일 Hash는 픽셀이 조금만 달라져도 완전히 다른 값이 나오기 때문에 이런 문제를 찾기에는 적절하지 않았다.

대신 pHash(Perceptual Hash) 를 이용했다.

pHash는 이미지의 시각적인 특징을 압축해서 표현하고, 두 값의 Hamming Distance가 작을수록 두 이미지가 비슷하다고 판단하는 방식이다.

결과는 다음과 같았다.

즉,

Test 44장 중 43장이 Train 이미지와 시각적으로 굉장히 비슷한 장면이었다.

여기서 중요한 점이 있다.

내가 Test 데이터를 Train에 넣은 것이 아니다.

교수님이 제공한 공식 Split 자체가 프레임 단위로 구성되어 있었던 것이다.

그리고 모든 학생이 같은 Split으로 평가받기 때문에 수업 내 순위 비교 자체는 공정했다.

하지만 공식 Test 점수를

"완전히 새로운 카메라와 도로에서도 이 정도 성능이 나온다."

라고 해석하는 것은 무리가 있다고 판단했다.

그래서 Validation을 새로 만들었다

공식 Test는 과제의 평가 기준이기 때문에 당연히 그대로 두었다.

대신 모델 선택을 위한 Validation을 하나 더 만들었다.

기존 Train + Validation 395장을 원본 영상 단위로 다시 분리했다.

새로운 Train
→ 7개 영상 / 307장

새로운 Validation
→ 완전히 제외한 2개 영상 / 88장

공식 Test
→ 모델 선택에 사용하지 않음

이것을 Clip-held-out Validation으로 사용했다.

이제는 같은 영상의 프레임이 Train과 Validation에 동시에 들어가지 않는다.

완벽한 외부 검증은 아니다.

같은 종류의 CCTV 환경에서 촬영된 데이터이기 때문에 새로운 날씨나 새로운 도로, 새로운 카메라까지 일반화되는지는 알 수 없다.

그래도 기존 프레임 단위 Validation보다 훨씬 엄격한 조건에서 모델을 비교할 수 있었다.

처음 실험 설계도 완벽하지 않았다

초기에는 다음과 같이 A부터 F까지 실험을 미리 만들어 놓았다.

A
YOLOv8n / 640 / 30 Epoch

↓

B
+ imgsz 960

↓

C
+ YOLO11s

↓

D
+ Rotation 10°

↓

E
+ Epoch 100

↓

F
+ Early Stopping

각 단계에서는 바로 이전 실험에서 하나의 변수만 바뀐다.

그래서 처음에는

"한 번에 하나만 바꾸니까 잘 설계했네?"

라고 생각했다.

그런데 다시 보니 문제가 있었다.

예를 들어 B가 나쁜 설정이어도

B → C → D → E → F

로 계속 물려받게 된다.

즉, 앞 단계의 잘못된 선택이 이후 실험 전체에 영향을 줄 수 있다.

또 설정을 어떤 순서로 적용했는가에 따라서도 결과가 달라질 수 있었다.

AI와 이 부분을 검토하면서 실험 방식을 바꿨다.

현재 가장 좋은 설정
        ↓
변수 하나 변경
        ↓
Validation
        ↓
좋아짐?
   ↙         ↘
 YES         NO
 유지        원상복귀
   ↓           ↓
다음 가설 설계

즉,

미리 A~F를 모두 정해두는 방식에서 결과를 보고 다음 실험을 결정하는 방식으로 바꿨다.

개인적으로 이게 이번 과제에서 꽤 중요한 변화였다고 생각한다.

처음부터 완벽한 실험 설계를 한 것은 아니었다.

하지만 내 설계의 문제점을 발견하고 다시 수정했다.

이제 제대로 실험해보자

Clip-held-out Validation을 고정한 후부터는 모델과 데이터를 같은 조건으로 유지하면서 한 번에 하나의 변수만 바꿨다.

대표적으로 I부터 L까지의 결과는 다음과 같다.

여기부터 하나씩 결과를 해석했다.

Learning Rate를 낮춰보자

실험 I에서는 optimizer=auto를 사용했고 내부적으로 AdamW와 약 0.002의 Learning Rate가 선택됐다.

그런데 학습 과정 중 한 번 Validation 성능이 크게 무너지는 현상이 있었다.

그래서

"현재 데이터셋에 비해 학습률이 조금 큰 것 아닐까?"

라는 가설을 세웠다.

AdamW를 명시적으로 사용하고

lr0
0.002
  ↓
0.001

로 낮춘 J를 실행했다.

결과는

mAP50-95
0.8299 → 0.8461

Precision
0.9438 → 0.9485

Recall
0.8842 → 0.8889

였다.

특히 마지막 5 Epoch에서 mAP50-95의 표준편차도

I : 0.0153
J : 0.0025

로 크게 줄었다.

단순히 최종 점수뿐만 아니라 학습 후반의 안정성도 좋아졌다.

그래서 J 설정을 유지하기로 했다.

오래 학습하면 더 좋아지지 않을까?

J의 마지막 구간에서 성능이 계속 올라가는 모습을 보고 이런 생각이 들었다.

"그럼 30 Epoch보다 50 Epoch까지 돌리면 더 좋아지겠는데?"

그래서 다른 조건은 그대로 두고

Epoch
30 → 50

만 변경한 K를 실행했다.

그런데 결과는 예상과 달랐다.

Recall은 아주 조금 올라갔다.

하지만 Precision과 mAP는 오히려 떨어졌다.

즉,

이번 조건에서는 오래 학습한다고 무조건 성능이 좋아지는 것이 아니었다.

그래서 K는 과감하게 버리고 다시 30 Epoch로 돌아갔다.

실패한 실험이었지만 오히려 꽤 중요한 결과였다.

내가 가지고 있던

"더 오래 학습하면 더 좋겠지."

라는 가설 하나를 직접 기각할 수 있었기 때문이다.

Learning Rate를 한 번 더 낮춰보자

다음으로 Epoch는 30으로 유지하고

Learning Rate만

0.001
  ↓
0.0001

로 낮춘 L을 실행했다.

결과는 조금 재미있었다.

모든 점수가 좋아진 것은 아니었다.

mAP50과 Precision은 조금 떨어졌다.

반면

• mAP50-95
• Recall

은 올라갔다.

여기서 고민이 생겼다.

"그럼 어떤 모델이 더 좋은 거지?"

mAP50-95는 IoU 0.5 하나만 보는 것이 아니라 0.5부터 0.95까지 여러 기준으로 Bounding Box 품질을 평가한다.

그래서 작은 트럭의 위치를 좀 더 정확하게 잡는 능력을 보고 싶었던 이번 과제에서는 mAP50-95의 상승도 의미가 있다고 판단했다.

그리고 한 번 잘 나온 결과만으로 L을 선택하고 싶지는 않았다.

혹시 그냥 운이 좋았던 거 아닐까?

딥러닝 학습에는 Random Seed에 따라 결과가 조금씩 달라질 수 있다.

그래서

Seed 7
Seed 42
Seed 123

세 가지 환경에서 J와 L을 다시 학습했다.

결과는 다음과 같았다.

세 Seed 모두에서 L이 더 높은 mAP50-95를 기록했다.

평균을 내보면

J : 0.841685
L : 0.848851

였다.

물론 Seed 세 개만 가지고 통계적으로 완벽하게 우월하다고 말할 수는 없다.

하지만 적어도

"Seed 42에서 우연히 한 번 잘 나온 것"

은 아니라는 근거는 얻을 수 있었다.

그래서 최종적으로 L을 선택했다.

그런데 문제가 하나 있었다

여기까지 집중해서 실험하다 보니 어느새 수업이 끝났다.

그리고 나에게 주어진 시간은 단 하루.

마음 같아서는 숙소에 들어가서 밤새 이것만 하고 싶었다.

그런데...

내가 LA까지 와서 하루 종일 Colab만 보고 있을 수는 없잖아...?

굉장히 어려운 선택이었다.

YOLO 성능 개선
      VS
LA 관광

둘 다 포기하고 싶지 않았다.

그래서 생각했다.

"둘 다 하면 안 되나?"

모델은 학습시키고, 나는 LA로 간다

마침 Codex를 모바일에서도 확인하면서 작업을 이어갈 수 있는 방법이 있었다.

그래서 학습과 실험은 계속 돌려놓고,

밖에서는 휴대폰으로 진행 상황과 결과를 확인하는 방식으로 작업하기로 했다.

실험 설정
    ↓
모델 학습 시작
    ↓
나는 LA 관광
    ↓
학습 완료
    ↓
휴대폰으로 결과 확인
    ↓
결과 분석
    ↓
다음 실험 결정
    ↓
다시 학습

완벽하다.

그래서 나는...

리틀 도쿄로 갔다.

근데 이제 LA 관광을 곁들인(?)

리틀 도쿄를 돌아다니다 발견한 오타니 벽화.

역시 LA라 그런지 오타니의 존재감이 엄청났다.

그리고 리틀 도쿄의 상징 중 하나인 야구라(櫓).

당연히 일본 음식도 먹었다.

그리고 맥주와 도쿠리까지.

하지만 놀러 나왔다고 해서 모델을 완전히 잊은 것은 아니었다.

밖에서도 계속 결과 확인 중...

어떤 작업은 무려 1시간 18분 동안 진행됐다.

(토큰 녹는다 녹아...)

학습이 끝나면 결과를 확인하고,

이전 실험과 비교한 뒤,

"그러면 다음에는 이 값을 바꿔볼까?"

라고 생각하며 다음 실험을 다시 돌렸다.

이렇게 밖에서도 계속 실험 흐름을 이어갈 수 있었던 것이 결과적으로 꽤 도움이 됐던 것 같다.

모델 돌려놓고 현지 밴드 보러 가기

리틀 도쿄를 구경한 뒤에는 근처에 있는 현지 밴드 공연을 하는 바에도 갔다.

물론...

이때도 모델은 열심히 학습 중이었다.

맥주 한 잔.

전체적인 분위기는 이런 느낌이었다.

공연을 보다가 중간중간 휴대폰을 확인하면

모델은 열심히 트럭을 찾고 있었다.

나 : 🍺🎸
YOLO : 🚚🚚🚚🚚🚚

각자의 LA를 즐기는 중이었다.

최종 모델을 결정하다

결국 최종적으로 선택한 설정은 다음과 같았다.

model: yolo11s.pt
epochs: 30
imgsz: 1280
batch: 8
optimizer: AdamW
lr0: 0.0001
momentum: 0.9
degrees: 0
close_mosaic: 10
seed: 42
ultralytics: 8.4.112

최종 모델을 확정한 뒤에는 설정을 더 이상 변경하지 않았다.

그리고 그제야 공식 Test를 평가했다.

최종 Test 결과

공식 Test 44장에 대한 결과는 다음과 같았다.

반올림하면

mAP50     : 0.9892
mAP50-95  : 0.8669
Precision : 0.9466
Recall    : 0.9620

이다.

특히 과제의 순위 기준이었던 mAP50은 98.92%까지 올라갔다.

실제 탐지 결과도 확인해봤다

숫자만 보는 것보다 실제 Bounding Box도 직접 확인했다.

가까이 있고 가림이 적은 트럭은 confidence 약 0.97 수준으로 안정적으로 탐지했다.

또한 고해상도 입력을 사용하면서 상대적으로 멀리 있는 작은 트럭도 꽤 잘 탐지하는 모습을 확인할 수 있었다.

하지만 실패 사례도 있었다.

특히 화면 오른쪽 끝에서 트럭의 상당 부분이 잘려 있는 경우,

객체 자체는 굉장히 컸지만 탐지하지 못하는 사례가 있었다.

즉,

객체가 크다고 항상 쉬운 것은 아니었다.

화면 밖으로 많이 잘려 있거나,

가림이 심하거나,

학습 데이터에서 자주 보지 못한 형태라면

큰 객체도 놓칠 수 있었다.

다음에 데이터를 추가한다면

• 화면 경계의 Partial Object
• 가려진 트럭
• 다른 카메라
• 다른 날씨
• 다른 도로

등을 더 많이 포함시키는 것이 필요할 것 같았다.

그리고 다음 날, 결과 발표

그렇게 하루 동안 여러 실험을 진행하고 다음 날 수업에 들어갔다.

드디어 결과 발표 시간.

학생들의 성능 점수가 하나씩 공개됐고,

결과는...

내가 1등이었다.

그래서 앞으로 나가 어떤 방식으로 모델의 성능을 개선했는지 발표하게 되었다.

그런데 사실 발표에서는 꽤 간단하게 이야기했다.

"AI를 적극적으로 활용해서 자료를 검토하고, 여러 설정을 바꿔가며 실험했습니다."

조금 더 솔직하게 말하면

"AI 돌려서 했습니다."

정도의 느낌이었다.

실제로 Codex를 굉장히 적극적으로 활용한 것도 맞다.

이번 과제에서 AI는

• 과제 자료 검토
• 반복 코드 작성
• 실험 로그 자동화
• 오류 원인 탐색
• 분석 코드 작성 보조
• 학습 상태 확인
• 결과 정리
• 다음 실험 후보 제안

등의 작업에서 꽤 많은 도움을 줬다.

그래서 발표만 들으면

"그냥 AI한테 성능 높여달라고 해서 1등한 거 아닌가?"

라고 생각할 수도 있을 것 같다.

그런데 당시 실험 기록을 다시 정리해보니 실제 과정은 조금 달랐다.

과제 요구사항 분석
        ↓
Object Detection / YOLO 이해
        ↓
실험 파이프라인 설계
        ↓
EDA
        ↓
Small·Medium 객체 94% 확인
        ↓
입력 해상도 조정
        ↓
YOLOv8n → YOLO11s
        ↓
데이터 Split의 이상한 점 발견
        ↓
원본 영상 / 프레임 구조 분석
        ↓
pHash를 통한 유사성 확인
        ↓
Clip-held-out Validation 구축
        ↓
Learning Rate / Epoch 실험
        ↓
실패한 실험 기각
        ↓
Multi-Seed 재현성 검증
        ↓
최종 모델 선정
        ↓
공식 Test 평가

물론 이 과정에서도 AI의 도움을 계속 받았다.

하지만 AI가 제안한 내용을 그대로 실행하고 가장 높은 숫자 하나를 고른 것은 아니었다.

오히려 내가 계속 고민했던 것은 이런 질문들이었다.

"왜 이 실험을 해야 하지?"

"이 Validation 점수를 믿어도 되는 걸까?"

"왜 Train과 Test의 배경이 이렇게 비슷하지?"

"50 Epoch까지 학습했는데 왜 오히려 성능이 떨어졌지?"

"이번 성능 개선이 우연히 잘 나온 한 번의 결과는 아닐까?"

AI가 답이나 실험 후보를 제안하면 실제 데이터와 Validation 결과를 확인하고,

그 결과를 바탕으로 다음 실험을 유지할지, 버릴지 결정했다.

초기에 만들었던 A~F 누적 실험 구조도 AI와 함께 다시 검토하다가 문제가 있다는 것을 발견했다.

앞 단계에서 좋지 않은 설정을 선택해도 다음 실험이 그대로 그 설정을 물려받는 구조였기 때문이다.

그래서 이후에는

현재 가장 좋은 설정
        ↓
변수 하나 변경
        ↓
Validation
        ↓
성능 개선?
   ↙           ↘
 YES           NO
 유지          되돌림
   ↓             ↓
     다음 가설 설계

처럼 결과를 확인한 뒤 다음 실험을 결정하는 방식으로 바꿨다.

50 Epoch 실험 역시 마찬가지였다.

처음에는

"더 오래 학습하면 더 좋아지겠지."

라고 생각했지만 실제 Validation에서는 mAP가 떨어졌다.

그래서 미련 없이 기각하고 다시 30 Epoch로 돌아갔다.

결국 이번 과제를 하면서 느낀 것은

AI를 잘 활용하는 것과 AI에게 판단을 맡기는 것은 전혀 다른 문제다.

라는 점이었다.

AI는 코드를 훨씬 빨리 작성할 수 있었고,

반복 작업도 빠르게 처리할 수 있었다.

그 덕분에 나는 직접 코드를 반복해서 작성하는 시간 대신

데이터를 보고, 결과를 해석하고, 다음 실험을 고민하는 데 더 많은 시간을 사용할 수 있었다.

돌이켜보면 이번 프로젝트에서 Codex는

Pair Programmer이자 실험 보조 도구

에 가까웠던 것 같다.

전날까지만 해도

리틀 도쿄에서 스시를 먹고,

맥주를 마시고,

밴드 공연을 보면서

휴대폰으로 YOLO 학습 결과를 확인하고 있었는데,

다음 날에는 앞에 나가 1등 발표를 하고 있으니 기분이 조금 묘했다.

그리고 대망의 상품 수여식.

상품은...

교수님의 특급 볼펜.

잘 간직하겠습니다...

1등보다 더 기억에 남은 것

최종적으로 과제에서 1등을 했다.

물론 좋았다.

아주 좋았다.

하지만 이번 프로젝트를 다시 정리하면서 가장 기억에 남는 것은 mAP50=0.9892라는 숫자보다 그 과정이었다.

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

큰 모델 쓰고
Epoch 늘리고
해상도 높이면

성능 올라가겠지?

그런데 실제로는 그렇지 않았다.

50 Epoch까지 학습했더니 오히려 성능이 떨어졌다.

mAP50이 조금 떨어지더라도 mAP50-95와 Recall은 올라가는 경우도 있었다.

같은 설정도 Seed에 따라 결과가 달랐다.

그리고 가장 높은 공식 점수조차 데이터의 분할 방식 때문에 그대로 일반화 성능이라고 믿을 수는 없었다.

결국 이번 과제에서 가장 크게 배운 것은

좋은 점수가 좋은 모델을 보장하지는 않는다.

는 것이었다.

왜 그 점수가 나왔는지,

데이터가 어떻게 구성되어 있는지,

어떤 Validation을 사용했는지,

같은 결과가 다시 나오는지까지 설명할 수 있어야 그 결과를 조금 더 믿을 수 있었다.

그래서 이번 과제를 통해 가장 많이 배운 것은 YOLO 자체보다 오히려 다음과 같은 실험 과정이었다.

데이터를 먼저 본다.

↓

가설을 세운다.

↓

하나의 변수만 변경한다.

↓

결과를 확인한다.

↓

가설이 틀리면 과감하게 버린다.

↓

다음 실험을 설계한다.

↓

다른 조건에서도 다시 확인한다.

특히 실패한 실험 역시

실패한 결과가 아니라 다음 선택의 근거

가 될 수 있다는 점이 인상 깊었다.

그리고 AI를 쓰는 방식에 대해서도 다시 생각하게 됐다.

AI는 반복 작업을 빠르게 처리해 줬고,

나는 그 시간을 이용해

데이터를 보고, 결과를 해석하고, 다음 실험을 고민하는 데 더 집중할 수 있었다.

결국 중요한 것은 AI를 쓰느냐 안 쓰느냐가 아니라,

AI가 만든 결과를 어디까지 믿고, 무엇을 다시 검증할 것인가

였던 것 같다.

그리고 무엇보다...

LA까지 와서 AI 과제만 하고 있지 않으면서도 결국 1등까지 했다.

스시 🍣

맥주 🍺

밴드 공연 🎸

그리고 YOLO 🚚

나름 완벽한 하루였다.

올해 초부터 계속 고민하던 개인 프로젝트가 하나 있었다.

바로 주식 자동매매 프로그램이다.

평소 증권 도메인에 관심이 많기도 했고, 자동매매 시스템이 실제로 어떤 구조로 동작하는지도 궁금했다.

특히 최근에는 금융권에서도 AI를 활용해 데이터를 분석하거나 투자 의사결정을 보조하는 사례가 늘어나고 있다.

그래서 단순히 증권사 API를 호출해서 주문을 보내는 프로그램보다는, 거래 시스템과 투자 판단 시스템을 분리해서 만들어보면 어떨까?라는 생각이 들었다.

대략적인 구조는 다음과 같다.

                    주식 자동매매 시스템

        ┌─────────────────────────────┐
        │   Python 분석 / 판단 시스템   │
        │                             │
        │  시장 데이터 분석             │
        │       ↓                     │
        │  매수 / 매도 전략             │
        │       ↓                     │
        │  BUY / SELL / HOLD 판단      │
        └──────────────┬──────────────┘
                       │
                       │ 거래 판단 결과
                       ↓
        ┌─────────────────────────────┐
        │   Java / Spring 거래 시스템   │
        │                             │
        │  인증 / 계좌 / 주문 / 체결     │
        │       ↓                     │
        │       증권사 API              │
        └─────────────────────────────┘

증권사 API와 통신하고 계좌, 주문 등의 도메인 객체를 관리하는 부분은 Java / Spring으로 구현하고,

실질적으로 데이터를 분석하여 매수와 매도를 판단하는 부분은 Python을 활용할 생각이다.

처음에는 간단한 규칙 기반 전략부터 시작하고, 이후 데이터를 충분히 확보하면 머신러닝이나 AI 모델을 적용해 판단 로직을 발전시키는 것이 최종적인 목표다.

그런데 무엇부터 만들어야 할까?

아이디어 자체는 올해 초부터 가지고 있었다.

하지만 학교도 다니고 여러 활동에도 참여하다 보니 정작 증권 도메인과 시스템 자체에 대해서는 제대로 공부하지 못했다.

그래서 이번 여름방학에는 미뤄두었던 이 프로젝트를 본격적으로 진행해 보려고 한다.

다만 이번 프로젝트에서는 곧바로 코드를 작성하고 싶지는 않았다.

학교에서 소프트웨어 공학과 개발론을 배우면서 항상 들었던 이야기가 있다.

개발은 코드를 작성하는 것부터 시작하는 것이 아니다.

무엇을 만들어야 하는지 정의하고, 필요한 기능을 분석하고, 구조를 설계한 뒤에야 실제 구현이 시작된다.

개인 프로젝트를 할 때는 아이디어가 떠오르면 바로 IDE부터 켜는 경우가 많았는데, 이번에는 학교에서 배운 개발 프로세스를 실제 개인 프로젝트에 적용해 보고 싶었다.

그래서 다음과 같은 순서로 프로젝트를 진행해 볼 생각이다.

요구사항 분석
      ↓
기능 목록 정리
      ↓
도메인 분석
      ↓
화면 / API / 데이터 구조 설계
      ↓
아키텍처 설계
      ↓
MVP 범위 결정
      ↓
개발
      ↓
테스트
      ↓
배포 / 운영
      ↓
개선 반복

물론 실제 개발에서는 이 과정이 항상 일직선으로 흘러가지는 않을 것이다.

개발하면서 새로운 요구사항이 생길 수도 있고, 설계가 잘못되었다면 이전 단계로 돌아갈 수도 있다.

그래도 '일단 만들고 나중에 생각하기'보다는 무엇을 왜 만드는지 먼저 정의해 보는 것을 이번 프로젝트의 또 다른 목표로 잡았다.

첫 번째 단계, 요구사항 분석

그렇다면 가장 먼저 해야 할 것은 요구사항 분석이다.

프로그램을 만들기 전에 최소한 다음 질문들에는 답할 수 있어야 한다고 생각했다.

1. 이 프로그램은 사용자에게 무엇을 제공해야 하는가?
2. 어떤 증권사 API와 통신할 것인가?
3. 어떤 데이터를 가져와야 하는가?
4. 어떤 조건에서 매수와 매도를 판단할 것인가?
5. 주문 실패, API 오류, 잔고 부족 같은 상황은 어떻게 처리할 것인가?
6. 첫 번째 버전에서는 어디까지 구현할 것인가?

처음 적어두었던 이 질문들은 별도의 개발 단계라기보다는 요구사항을 구체화하기 위해 스스로에게 던진 질문에 가깝다.

그리고 이를 바탕으로 요구사항을 사용자 요구사항과 시스템 요구사항으로 나누어 정리했다.

사용자 요구사항과 시스템 요구사항

두 요구사항은 비슷해 보이지만 관점이 다르다.

사용자 요구사항(User Requirement)

사용자 입장에서

"이 프로그램을 이용해서 무엇을 할 수 있어야 하는가?"

를 정의한다.

시스템 요구사항(System Requirement)

사용자 요구사항을 만족시키기 위해

"시스템 내부에서는 어떤 기능을 수행해야 하는가?"

를 정의한다.

예를 들어 사용자는 단순히

"내 계좌 상태를 보고 싶다."

라고 생각할 수 있다.

하지만 시스템 입장에서는 이를 위해

사용자 인증
    ↓
Access Token 발급
    ↓
증권사 API 요청
    ↓
계좌 정보 조회
    ↓
응답 데이터 변환
    ↓
사용자에게 전달

과 같은 여러 작업이 필요하다.

이 차이를 기준으로 요구사항을 정리해 보았다.

사용자 요구사항

현재 생각한 사용자 요구사항은 다음과 같다.

1. 사용자는 증권 계좌에 투자금을 입금한다.
2. 사용자는 자동매매 프로그램을 실행할 수 있다.
3. 사용자는 계좌에서 현재 사용 가능한 잔액을 확인할 수 있다.
4. 프로그램은 설정된 매수/매도 전략에 따라 거래 여부를 판단한다.
5. 조건이 충족되면 프로그램은 매수 또는 매도를 수행할 수 있다.
6. 사용자는 거래 결과와 현재 계좌 상태를 확인할 수 있어야 한다.

아직 초기 단계이기 때문에 상당히 큰 단위의 요구사항만 작성했다.

프로젝트를 진행하면서 실제 사용자 흐름을 구체화하면 더 세분화할 예정이다.

시스템 요구사항

사용자 요구사항을 실제로 구현하기 위해 시스템이 제공해야 하는 기능도 정리했다.

1. 시스템은 증권사 API 인증 토큰을 발급받고 관리할 수 있어야 한다.
2. 시스템은 계좌 잔고를 조회할 수 있어야 한다.
3. 시스템은 보유 종목을 조회할 수 있어야 한다.
4. 시스템은 특정 종목의 현재가를 조회할 수 있어야 한다.
5. 시스템은 매수/매도 전략에 필요한 데이터를 판단 시스템에 전달할 수 있어야 한다.
6. 판단 시스템은 데이터를 기반으로 매수/매도 여부를 결정할 수 있어야 한다.
7. 시스템은 판단 결과에 따라 증권사에 매수/매도 주문을 요청할 수 있어야 한다.
8. 시스템은 주문 및 체결 결과를 확인할 수 있어야 한다.
9. 시스템은 거래 내역과 판단 결과를 로그로 저장할 수 있어야 한다.
10. 시스템은 API 오류, 인증 실패, 잔고 부족 등의 예외 상황을 처리하고 기록할 수 있어야 한다.

아직 어떤 증권사 API를 사용할지, 두 시스템을 어떤 방식으로 통신시킬지는 완전히 결정하지 않았다.

REST API를 사용할 수도 있고, Python 판단 시스템을 별도의 서비스로 분리할 수도 있다.

이 부분은 이후 아키텍처 설계 단계에서 조금 더 구체적으로 고민해 보려고 한다.

그런데 처음부터 이걸 전부 만들어야 할까?

요구사항을 작성하고 보니 생각보다 구현해야 할 것이 많았다.

인증
계좌
시세
전략
주문
체결
로그
예외 처리
UI
백테스트
AI
...

여기에 처음부터 머신러닝 모델과 실시간 UI, 실제 주문까지 전부 넣으려고 하면 프로젝트가 끝나기도 전에 지칠 가능성이 높다.

그래서 필요한 것이 MVP다.

MVP란?

MVP는 Minimum Viable Product, 즉 최소 기능 제품을 의미한다.

쉽게 말하면

"우리 서비스의 핵심 가치를 확인하기 위해 첫 번째 버전에서는 어디까지 만들 것인가?"

를 정하는 것이다.

여기서 중요한 것은 단순히 기능을 적게 만드는 것이 아니다.

최소한의 기능만 가지고도 이 시스템의 핵심 흐름이 실제로 동작하는지 확인할 수 있어야 한다.

내 자동매매 프로그램에서 가장 먼저 검증하고 싶은 흐름은 다음과 같다.

증권사 API 연결
        ↓
계좌 / 시장 데이터 조회
        ↓
Python 판단 시스템으로 데이터 전달
        ↓
매수 / 매도 / 대기 판단
        ↓
결과 기록

이 흐름이 정상적으로 동작한다면 그다음에 실제 주문이나 복잡한 전략을 추가할 수 있다.

1차 MVP

그래서 첫 번째 MVP의 범위를 다음과 같이 잡았다.

1. API 인증

증권사 API를 사용하기 위한 인증 토큰을 정상적으로 발급받고 관리한다.

2. 계좌 잔고 조회

API를 통해 실제 계좌의 사용 가능한 잔액을 가져온다.

3. 특정 종목 현재가 조회

지정한 종목의 현재 가격 데이터를 가져온다.

4. 단순한 매수/매도 전략 구현

Python으로 가장 단순한 규칙 기반 전략부터 구현한다.

시장 데이터
    ↓
Python 전략
    ↓
BUY / SELL / HOLD

이 단계에서는 처음부터 복잡한 AI 모델을 사용하는 것이 아니라 Java/Spring 시스템과 Python 판단 시스템이 정상적으로 연결되는지 확인하는 것을 우선한다.

5. 모의 판단 결과 기록

1차 MVP에서는 실제 주문을 보내지 않는다.

[14:30:01] 삼성전자 현재가 : 80,000원
[14:30:01] 전략 판단 : BUY
[14:30:01] 주문 실행 : SKIP (MVP Simulation Mode)

이처럼 실제 돈이 움직이지 않는 상태에서 전체 파이프라인이 정상적으로 동작하는지 먼저 검증한다.

1차 MVP에서 제외할 것

반대로 처음부터 만들지 않을 기능도 명확하게 정했다.

1. 실제 매수/매도 주문 실행
2. 복잡한 투자 전략
3. 머신러닝/딥러닝 기반 투자 판단
4. 실시간 차트 UI
5. 백테스트 시스템
6. 서버 배포
7. 모바일 알림

특히 AI 기반 투자 판단은 일부러 1차 MVP에서 제외했다.

최종적으로는 Python을 이용해 데이터를 분석하고 모델이 매수와 매도를 판단하도록 만드는 것이 목표지만, 아직 데이터 파이프라인조차 만들어지지 않은 상태에서 AI부터 붙이는 것은 순서가 아니라고 생각했다.

먼저

데이터를 제대로 가져올 수 있는가?

        ↓

Java/Spring과 Python이 통신할 수 있는가?

        ↓

판단 결과를 안정적으로 전달할 수 있는가?

        ↓

로그와 예외 처리가 정상적으로 이루어지는가?

부터 확인하려고 한다.

그다음 전략을 하나씩 고도화하면 된다.

앞으로의 방향

여기까지 내가 만들고자 하는 자동매매 프로그램의 요구사항과 1차 MVP를 간단하게 정리해 보았다.

아직은 설계 초기 단계라 앞으로 개발하면서 바뀌는 부분도 분명히 있을 것이다.

하지만 이번 프로젝트에서는 단순히

"자동매매 프로그램 하나 만들어봤다."

에서 끝내고 싶지는 않다.

요구사항 분석부터 도메인 설계, 아키텍처 설계, 구현, 테스트와 배포까지 학교에서 배운 소프트웨어 개발 과정을 실제 개인 프로젝트에 하나씩 적용해 보는 것이 또 하나의 목표다.

그리고 그 과정에서 왜 이런 구조를 선택했고, 어떤 문제가 발생했고, 어떻게 개선했는지도 계속 기록해 보려고 한다.

다음 글에서는 요구사항을 기반으로 실제로 구현해야 할 기능 목록을 조금 더 구체적으로 정리해 볼 예정이다.

다음 글 : 주식 자동매매 프로그램 만들기 (2) - 기능 목록 정의하기

AI 시대에 살아남는 개발자의 조건, 그리고 앞으로의 커리어

앞선 두 편에서는

• AI-Native 시대가 무엇인지
• Oracle와 Amazon에서는 AI를 어떻게 활용하고 있는지
• AI가 개발자의 업무를 어떻게 바꾸고 있는지

에 대해 이야기했다.

이번 글에서는 개인적으로 가장 인상 깊었던 내용,

바로 AI 시대를 살아가는 개발자의 태도에 대해 정리해 보려고 한다.

사실 기술적인 내용보다도 이 부분이 훨씬 오래 기억에 남았다.

AI 시대에도 사람은 여전히 필요하다

강연 후반부에서

박사님은 계속해서

Perspective(관점)

이라는 단어를 강조하셨다. Staying Relevant in the AI-Native Era.pdf

AI는 앞으로 더 많은 일을 하게 될 것이다.

코드를 작성하고,

문서를 만들고,

발표 자료를 만들고,

심지어 여러 AI가 협업하는 Multi-Agent 시스템도 점점 일반화되고 있다.

하지만

AI가 대신하지 못하는 것이 있다.

바로

무엇을 해결해야 하는가

를 결정하는 일이다.

AI는

문제를 해결하는 도구이지,

문제를 정의하는 존재는 아니라는 말이 특히 기억에 남았다.

결국 중요한 것은 Context

강연 중 한 학생이 질문했다.

"AI가 결국 이런 영역도 대체하지 않을까요?"

박사님의 대답은 굉장히 현실적이었다.

AI는

많은 작업(Task)을 대신할 수 있다.

하지만

Context를 이해하는 사람

까지 대체하기는 어렵다고 이야기하셨다.

같은 코드라도

왜 이렇게 설계했는지,

비즈니스 목적이 무엇인지,

앞으로 어떤 방향으로 발전해야 하는지를 이해하는 것은

여전히 사람의 역할이라는 것이다.

AI가 발전할수록

오히려 Context를 이해하는 능력이 더 중요해진다는 말이 인상 깊었다.

Task는 자동화되지만 Job은 다르다

박사님은

AI가 앞으로

Task Automation

은 계속 발전할 것이라고 이야기하셨다.

반복적인 업무,

정형화된 작업,

문서 작성,

코드 생성 등은

점점 AI가 담당하게 될 가능성이 높다.

하지만

그렇다고 해서

직업(Job) 자체가 바로 사라지는 것은 아니라고 말씀하셨다.

사람은

여러 Task를 연결하고,

우선순위를 정하고,

최종 결정을 내리는 역할을 계속 맡게 될 것이라는 설명이 인상 깊었다.

문제를 가장 빨리 정의하는 사람이 강하다

이번 강연에서

개인적으로 가장 공감했던 조언이다.

박사님은

회사에서 잘하는 사람들을 보면

코딩을 가장 잘하는 사람이 아니라,

문제를 가장 빨리 파악하는 사람

이었다고 이야기하셨다.

그리고

사람들을 잘 리드해서

좋은 결과를 만드는 사람들이

결국 높은 성과를 냈다고 한다.

학생 때는

코딩 실력만 중요하다고 생각하기 쉽다.

하지만

실제 회사에서는

문제 정의와 의사결정 능력이

생각보다 훨씬 중요하다는 것을 다시 한번 느꼈다.

60~70% 준비되면 일단 지원하라

강연 중

학생들의 질문 시간이 있었는데,

가장 기억에 남는 답변이 하나 있었다.

"아직 준비가 부족한 것 같은데 지원해도 될까요?"

박사님의 대답은 의외였다.

60~70% 정도 준비되었다고 생각하면 일단 지원하세요.

그리고

부족한 30%는

정말 미친 듯이 채우면 된다고 말씀하셨다.

완벽하게 준비될 때까지 기다리다 보면

기회 자체를 놓치는 경우가 많다고 하셨다.

이 말을 들으면서

나 역시

지원하기 전에

"아직 부족한데..."

라는 생각을 많이 했던 순간들이 떠올랐다.

질문을 더 구체적으로 하라

또 하나 기억에 남았던 조언이 있다.

학생들은 종종

"무엇을 준비해야 할까요?"

라고 질문한다.

하지만

박사님은

그보다

"이 직무를 위해 앞으로 2주 동안 무엇을 준비하면 좋을까요?"

처럼

구체적인 질문을 하는 것이 훨씬 좋은 답을 얻을 수 있다고 말씀하셨다.

AI에게 질문할 때도,

사람에게 질문할 때도,

좋은 질문이 좋은 답을 만든다는 점은

공통적인 원리인 것 같았다.

Persistence와 Curiosity

강연 마지막에는

에릭 슈미트(Eric Schmidt)가 중요하게 생각했던 두 가지 가치도 소개되었다.

첫 번째는

Persistence

포기하지 않는 끈기.

두 번째는

Curiosity

끊임없이 궁금해하는 태도.

화려한 기술보다

이 두 가지가

오랫동안 성장하는 사람들의 공통점이라는 설명이 인상 깊었다.

실패를 두려워하지 말고 빨리 움직여라

또 하나 기억에 남는 조언.

빨리 실패하고, 빨리 방향을 수정하라.

완벽한 계획을 세우는 것보다

먼저 시도하고,

실패하면서

계속 방향을 수정하는 것이 훨씬 중요하다고 하셨다.

스타트업에서 일했던 경험과

대기업에서의 경험을 함께 이야기해 주셨는데,

결국

행동하는 사람이

가장 많은 것을 배우게 된다는 말이 크게 와닿았다.

Reach Out

개인적으로 가장 현실적인 조언이었다.

박사님은

기회를 기다리기보다

직접 사람들에게 연락하는 것이 중요하다고 말씀하셨다.

거창한 메일이 아니라

안녕하세요.

논문 잘 읽었습니다.

축하드립니다.

혹시 학회에서 잠깐 커피챗 가능하실까요?

정도의 짧은 메시지면 충분하다고 하셨다.

실제로

이런 Cold Message 하나로

새로운 기회를 얻었던 경험도 들려주셨다.

네트워킹은

특별한 사람만 하는 것이 아니라,

먼저 용기 내어 연락하는 사람에게 찾아온다는 점이 인상 깊었다.

커뮤니케이션은 생각보다 훨씬 중요하다

학생 때는

코딩만 잘하면 될 것 같지만,

회사에서는

생각보다

커뮤니케이션의 비중이 매우 크다고 하셨다.

특히

Written Communication

즉,

문서로 명확하게 전달하는 능력이 굉장히 중요하다고 말씀하셨다.

또한

말로 대화하는 상황에서는

내가 하고 싶은 말보다

상대방이 무엇을 원하는지 이해하는 능력

이 더 중요하다고 강조하셨다.

AI 시대에도

사람과 협업하는 능력은

여전히 핵심 역량이라는 생각이 들었다.

추천해 주신 책들

강연 마지막에는

앞으로 읽어보면 좋을 책들도 추천해 주셨다.

• The Coming Wave
• Superagency
• Eat That Frog
• The One Thing
• 내가 가진 것을 세상이 원하게 하라

단순한 AI 기술서가 아니라,

AI 시대를 살아가는 방법,

우선순위를 정하는 방법,

그리고 자신의 커리어를 만들어가는 방법에 대한 책들이었다.

시간이 날 때 하나씩 읽어보려고 한다.

강연을 마치며

이번 강연은

AI 기술 자체를 배우는 시간이라기보다,

AI 시대를 살아가는 개발자의 태도를 배우는 시간이었다.

처음에는

"AI가 개발자를 대체할까?"

라는 질문을 가지고 강연을 들었다.

하지만 끝나고 나니

질문 자체가 조금 달라졌다.

AI 시대에 나는 어떤 개발자가 되어야 할까?

AI는 앞으로 더 많은 일을 대신하게 될 것이다.

하지만

문제를 정의하고,

좋은 방향을 설계하고,

사람들과 협업하며,

최종 결정을 내리는 일은

여전히 사람의 역할이다.

이번 강연을 통해

기술을 공부하는 것만큼이나

좋은 질문을 하는 능력, 문제를 정의하는 능력, 그리고 끊임없이 배우려는 태도가 중요하다는 것을 다시 한번 느낄 수 있었다.

USC에서 들었던 여러 강의 중에서도

앞으로의 커리어를 가장 많이 돌아보게 만든 강연이었다.

AI 시대에도 결국 중요한 것은 사람이다

지난 글에서는 Oracle에서 바라보는 AI-Native 시대와 개발자의 역할 변화에 대해 이야기했다.

강연을 들으며 가장 인상 깊었던 부분은 AI 기술 자체보다,

"AI 시대에도 결국 무엇을 잘하는 사람이 살아남는가?"

에 대한 이야기였다.

생각보다 현실적이었고, 앞으로 어떤 개발자가 되어야 하는지 다시 한번 생각해 보게 만든 시간이었다.

AI가 바꾸는 것은 코딩이 아니라 '일하는 방식'

강연 중 가장 기억에 남았던 키워드는

Workflow

였다.

요즘은 AI를 얼마나 잘 사용하는지가 중요하다고 많이 이야기한다.

하지만 박사님은

AI를 사용하는 것보다

AI를 활용한 Workflow를 만드는 능력

이 더 중요해질 것이라고 말씀하셨다.

예전에는

문제 발생

↓

선배에게 질문

↓

코드 찾기

↓

문서 읽기

↓

수정

이라는 흐름이었다.

하지만 앞으로는

문제 발생

↓

AI에게 Context 전달

↓

AI가 관련 코드 분석

↓

수정 방향 제안

↓

사람이 최종 판단

이라는 형태로 바뀌게 된다.

즉,

AI는 개발자를 대체하는 것이 아니라

개발 프로세스 자체를 바꾸고 있는 것이었다.

회사에서는 남의 코드를 더 많이 본다

학생 때는

대부분 내가 작성한 코드만 본다.

하지만 회사에서는 그렇지 않다.

오히려

남이 작성한 코드가 훨씬 많다.

박사님도

회사에서는

기존 코드베이스를 이해하는 시간이 굉장히 많다고 이야기하셨다.

예전에는

관련 문서를 찾고,

기존 개발자에게 질문하고,

하나씩 분석해야 했다.

하지만 지금은

AI에게

"이 프로젝트 구조를 설명해줘."

"이 함수가 왜 필요한지 알려줘."

라고 물어보면

생각보다 빠르게 이해할 수 있다.

이 부분을 들으면서

AI는 단순히 코드를 생성하는 도구가 아니라,

기존 시스템을 이해하는 도구로도 엄청난 가치를 가진다는 생각이 들었다.

AI는 커뮤니케이션도 바꿀 것이다

강연에서 조금 놀랐던 부분도 있었다.

박사님은

AI가 단순히 개발만 바꾸는 것이 아니라

사람과 사람 사이의 커뮤니케이션도 크게 바꿀 것이라고 이야기하셨다.

예전에는

주니어 개발자가

시니어 개발자에게

질문하면서 배우는 과정이 많았다.

하지만

이제는

AI에게 먼저 질문하고,

필요한 정보를 바로 얻을 수 있다.

즉,

단순한 질문과 답변은

점점 AI가 대신하게 될 가능성이 높다는 것이다.

물론

사람 사이의 협업이 사라지는 것은 아니지만,

커뮤니케이션의 형태는 분명히 달라질 것이라는 생각이 들었다.

그렇다면 사람은 무엇을 해야 할까?

강연에서 한 학생이 질문했다.

"AI가 결국 이런 영역도 대체할 것이라고 생각하시나요?"

박사님의 답변은 인상 깊었다.

AI는

많은 일을 대신할 수 있다.

하지만

중요한 Context를 이해하고 판단하는 사람

까지 대체하기는 어렵다는 것이다.

예를 들어

같은 코드라도

왜 이런 구조를 선택했는지,

비즈니스 요구사항이 무엇인지,

앞으로 어떻게 확장될지를 이해하는 것은

여전히 사람의 역할이라는 것이다.

결국

기술보다

맥락(Context)을 이해하는 능력이 더욱 중요해질 것이라는 이야기였다.

좋은 코드를 많이 보는 것이 중요하다

이 부분은 개인적으로 가장 공감했던 내용이었다.

박사님은

코딩 연습도 중요하지만,

좋은 코드를 많이 보는 것이 훨씬 중요하다.

고 말씀하셨다.

처음에는

조금 의외였다.

하지만 생각해 보면

좋은 글을 많이 읽어야 글을 잘 쓰게 되듯,

좋은 코드를 많이 봐야

좋은 코드가 무엇인지 판단할 수 있다.

AI가 코드를 생성해 주는 시대일수록

그 코드가

좋은 코드인지,

나쁜 코드인지,

수정해야 하는 코드인지를

판단하는 능력이 훨씬 중요해질 것이라는 말이 인상 깊었다.

코딩테스트는 없어질까?

많은 사람들이 궁금해하는 질문도 나왔다.

"AI 시대에도 코딩테스트가 필요할까요?"

박사님의 대답은

"당분간은 필요하다."

였다.

이유는 단순했다.

현재로서는

지원자의 문제 해결 능력을 평가할 수 있는

더 좋은 방법을 찾기 어렵기 때문이다.

다만

코딩테스트에서

면접관이 정말 보고 싶은 것은

단순히 정답을 맞히는 것이 아니라고 하셨다.

오히려

• 어떻게 문제를 접근했는지

• 왜 그렇게 생각했는지

• 다른 사람과 어떻게 설명하고 소통하는지

같은 부분을 더 중요하게 본다고 이야기하셨다.

이 말을 듣고

앞으로 코딩테스트를 준비할 때도

단순히 정답만 맞추는 것이 아니라,

내 생각을 설명하는 연습도 함께 해야겠다는 생각이 들었다.

이번 강연에서 가장 기억에 남은 한 문장

이번 강연을 들으며

가장 오래 기억에 남은 문장은

"좋은 코드를 작성하는 사람보다, 좋은 코드를 판단할 수 있는 사람이 되어라."

였다.

AI는 앞으로도 계속 발전할 것이다.

하지만

그 결과를 검증하고,

더 나은 방향을 선택하는 일은

결국 사람의 몫이다.

이번 강연을 통해

앞으로 개발자는

단순히 코드를 작성하는 사람이 아니라,

좋은 방향을 선택하는 사람이 되어야 한다는 생각을 하게 되었다.

다음 글에서는

김장원 박사님이 들려주신

가장 현실적인 커리어 조언과

추천 도서,

그리고 개인적으로 가장 인상 깊었던 이야기들을 정리해 보려고 한다.

AI-Native 시대, 개발자는 정말 코딩을 덜 하게 될까?

USC 프로그램 중 가장 기대했던 일정 중 하나는 Oracle의 김장원 박사님 초청강연이었다.

강연 제목은

Staying Relevant in the AI-Native Era

였다.

처음에는 단순히 AI 기술 동향이나 Oracle에서 사용하는 최신 기술을 소개하는 강연일 것이라고 생각했다.

그런데 강연을 듣고 나니 예상과는 조금 달랐다.

이번 강연은

"AI 시대에 개발자는 무엇을 준비해야 하는가?"

에 대한 이야기였다.

기술보다도 앞으로의 개발 문화와 커리어에 대해 훨씬 많은 생각을 하게 만든 시간이었다.

AI가 코딩을 대신하는 시대?

강연 초반에는 AI가 얼마나 빠르게 발전하고 있는지 다양한 사례를 보여주셨다.

최근 AI는 단순히 코드를 생성하는 수준을 넘어

• 문서를 작성하고
• 전략을 세우고
• 여러 AI가 협업하는 Multi-Agent System까지 발전하고 있다.

발표 자료에서도 최근 AI 연구 흐름으로

• Multi-Agent Systems
• Vision-Language Models
• Reasoning
• AI Coding
• AI for Strategy & Design

등이 소개되었다. Staying Relevant in the AI-Native Era.pdf

특히 기억에 남았던 말은

"이제 코딩하는 시간은 없어졌다."

였다.

물론 코딩이 필요 없어졌다는 의미는 아니었다.

단순히 코드를 직접 입력하는 시간이 점점 줄어들고,

AI에게 적절한 Instruction를 주고,

전체 시스템을 설계하는 시간이 훨씬 많아질 것이라는 의미였다.

Oracle에서는 AI를 어떻게 활용하고 있을까?

Oracle 내부에서도 이미 다양한 AI Agent가 활용되고 있었다.

강연에서는 Oracle Health에서 개발 중인 Clinical AI Agent 사례가 소개되었다. Staying Relevant in the AI-Native Era.pdf

또한 Oracle의 하나의 서비스가 아니라

각 컴포넌트마다 전담 팀이 존재하며,

Agent들이 서로 협력하는 구조로 발전하고 있다는 설명도 이어졌다.

예전에는 하나의 AI가 하나의 일을 했다면,

앞으로는 여러 Agent가 역할을 나누어 하나의 업무를 수행하는 방향으로 발전한다는 것이다.

마침 얼마 전 샌디에이고에서 열린 AI 컨퍼런스에서도

Multi-Agent Systems가 주요 주제로 다뤄졌다고 소개해 주셨다.

AI의 발전 방향이 단순한 ChatGPT가 아니라

여러 AI가 협업하는 구조라는 점이 굉장히 인상 깊었다.

Amazon에서 시작된 경험

강연 중 재미있었던 부분은 박사님의 커리어 이야기였다.

Amazon Alexa 프로젝트를 진행했던 경험과,

이후 Healthcare 분야에서 AI를 활용했던 사례를 들려주셨다.

특히 기억에 남았던 것은

"보고 싶은 드라마가 있는데 어느 채널인지 기억이 나지 않는다."

는 예시였다.

리모컨으로 하나씩 채널을 찾는 대신

TV에게

"OO 드라마 틀어줘."

라고 말하면

알아서 채널을 찾아주는 세상이 더 자연스럽지 않을까?

이러한 생각에서 음성 AI에 관심을 갖게 되었다고 말씀하셨다.

단순한 기술이 아니라

실제 사용자의 불편함에서 출발한 문제 정의라는 점이 인상 깊었다.

앞으로는 UI도 달라질 것이다

또 하나 기억에 남았던 내용은

앞으로의 사용자 인터페이스(UI)에 대한 이야기였다.

지금은

• 버튼을 누르고
• 메뉴를 찾고
• 콘솔에 명령어를 입력하는 방식이 익숙하다.

하지만 앞으로는

이러한 방식 자체가 점점 줄어들 것이라고 이야기하셨다.

AI와 자연스럽게 대화하는 것이

새로운 인터페이스가 될 가능성이 높다는 것이다.

생각해 보면

이미 ChatGPT나 음성비서도

기존 UI와는 완전히 다른 방식으로 동작한다.

이번 강연을 들으며

UI도 결국 AI 중심으로 계속 변화하고 있다는 점을 다시 느낄 수 있었다.

개발자는 무엇을 하게 될까?

강연에서 가장 기억에 남았던 질문은 이것이었다.

"AI가 코딩을 다 하면 개발자는 무엇을 해야 할까?"

박사님의 대답은 명확했다.

앞으로 개발자는

코드를 한 줄 한 줄 작성하는 사람이 아니라

Strategy와 Design을 담당하는 사람이 되어야 한다는 것이다.

AI에게

무엇을 만들지,

어떻게 만들지,

어떤 방향으로 문제를 해결해야 하는지를 설명하는 능력이

점점 더 중요해질 것이라고 말씀하셨다.

즉,

개발자의 역할이 사라지는 것이 아니라

역할 자체가 바뀌고 있는 것이었다.

이번 강연에서 가장 인상 깊었던 한 문장

이번 강연을 들으며 가장 오래 기억에 남은 문장은

"코딩하는 시간은 줄어들고, 생각하는 시간은 늘어난다."

였다.

AI는 코드를 빠르게 만들어 줄 수 있다.

하지만

무엇을 만들지,

왜 그렇게 만들어야 하는지,

어떤 문제를 해결해야 하는지는

여전히 사람이 결정해야 한다.

강연을 들으며

앞으로는 단순히 프로그래밍 언어를 많이 아는 것보다

문제를 정의하고,

좋은 방향을 설계하는 능력이 훨씬 중요해질 것이라는 생각이 들었다.

다음 글에서는

AI 시대에도 여전히 중요한 커뮤니케이션 능력, 좋은 코드를 보는 능력, 그리고 박사님이 들려주신 현실적인 커리어 조언들을 정리해보려고 한다.

1편에서는 USC 빅데이터 컨퍼런스에 지원하게 된 계기와 선발 과정, 그리고 출국 직전까지의 이야기를 적어보았다.

📖 이전 이야기
🇺🇸 USC (서던 캘리포니아 대학교) 빅데이터 컨퍼런스에 참가하다 - 1편

드디어 출국.

이번 글에서는 미국에 도착해서 처음 느꼈던 분위기와 USC에서의 첫인상, 그리고 개인적으로 오래 기억에 남을 이야기를 적어보려고 한다.

드디어 LA 도착

LA에 도착한 첫날.

미국은 이번이 처음은 아니었지만, 오랜만에 밟는 미국 땅은 여전히 자유로운 분위기였다.

공항을 나와 바깥 공기를 마셨는데 생각보다 덥지 않았다.

한국의 한여름을 생각하고 왔는데 오히려 선선해서 놀랐다.

역시 캘리포니아는 날씨 하나만큼은 정말 좋다는 생각이 들었다.

생각보다 큰 USC 캠퍼스

학교에 도착해서 가장 먼저 느낀 건

"생각보다 정말 크다."

였다.

학교 안에 마트도 있고 식당도 있고 카페도 있고...

거의 작은 도시 하나가 학교 안에 들어와 있는 느낌이었다.

특히 신기했던 건

Trader Joe's가 학교 바로 옆에 있다는 점이었다.

미국에 오면 한 번쯤 꼭 가보는 마트인데,

학교와 너무 가까워서 학생들이 장보기에는 정말 좋은 환경이라는 생각이 들었다.

'USC 학생들은 정말 살기 좋은 환경에서 학교를 다니는구나.'

라는 생각이 가장 먼저 들었다.

첫날 저녁은 역시 한식

첫날 저녁은 코리아타운에 있는 북창동순두부(BCD Tofu House) 로 갔다.

사실 미국에 오면 햄버거나 스테이크부터 먹을 줄 알았는데,

비행 시간이 워낙 길다 보니 자연스럽게 따뜻한 국물이 생각났다.

순두부도 맛있었지만,

개인적으로는 여기 갈비가 정말 맛있다.

미국에 갈 일이 있다면 한 번쯤은 꼭 추천하고 싶은 식당이다.

우버에서 만난 70살 기사님

하지만 이날 가장 기억에 남았던 건 저녁이 아니었다.

기숙사로 돌아가는 우버에서 만난 한 분과의 대화였다.

기사님은 올해 70살이셨고,

35년 전 미국으로 건너오셨다고 했다.

예전 럭키금성(LG)에서 근무하시다가

사업 때문에 미국에 오셨고,

정착하여 작년까지 일을 하셨다고 했다.

이야기를 나누다 보니 자연스럽게

한국의 취업 이야기로 이어졌다.

그때 기사님이 하신 말이 아직도 기억에 남는다.

"요즘 한국의 젊은 친구들은 정말 힘들겠다."

사실 조금 놀랐다.

보통은

"요즘 젊은 친구들은 끈기가 부족하다."

"노력을 안 해서 그렇다."

같은 이야기를 많이 들었기 때문이다.

그런데 기사님의 생각은 전혀 달랐다.

기사님은 본인이 75학번이라고 말씀하시며

당시를 이렇게 회상하셨다.

"우리 때는 취업이 정말 쉬웠어."

"조금 과장해서 말하면 지원서만 넣어도 여러 군데에서 합격 연락이 왔지."

"회사에서 사람을 뽑는 시대였어."

그리고 잠시 말을 멈추시더니

이어서 이렇게 말씀하셨다.

"근데 지금은 아니잖아."

"너희는 우리보다 훨씬 좋은 교육을 받고 더 열심히 살아도 취업이 어렵잖아."

"우리 때랑은 비교 자체가 안 되는 시대야."

그 말을 듣는데 괜히 마음이 묵직해졌다.

"한국 청년들은 정말 잘한다"

기사님은 미국에서 오래 살아오면서 느낀 점도 이야기해 주셨다.

"한국 젊은 친구들은 정말 똑똑해."

"미국 친구들보다 더 성실하고 더 열심히 하는 경우도 많아."

"그런데 한국 사회가 그걸 다 받아줄 수 없는 구조인 것 같아."

그리고 한국과 미국의 가장 큰 차이도 이야기해 주셨다.

기사님의 생각으로는

한국은 자본이 부동산에 너무 많이 묶여 있고,

도전보다 안정이 우선되는 분위기가 강하다고 하셨다.

반면 미국에서는

새로운 아이디어나 창업,

투자에 훨씬 적극적으로 돈이 흘러간다고 말씀하셨다.

그 차이가

새로운 기업을 만드는 문화의 차이로 이어지는 것 같다고도 했다.

물론 모든 사람이 같은 생각을 하는 것은 아니겠지만,

35년 동안 미국에서 생활한 한 사람의 경험이라 그런지

더 흥미롭게 들렸다.

마지막으로 기사님은 이런 말을 남기셨다.

"아직 젊잖아."

"꿈이 있다면 절대 도전을 멈추지 마."

그리고

본인도 올해 70살이 되었지만,

미국의 높은 물가와 사회 구조 때문에

지금도 우버를 운행하고 있다고 담담하게 말씀하셨다.

짧은 이동 시간이었지만,

미국에 도착한 첫날부터

생각보다 많은 것을 배우게 된 시간이었다.

요세미티 국립공원

USC 프로그램이 시작되기 전,

주말을 이용해 요세미티 국립공원에도 다녀왔다.

사실 예전 미국 여행 때는 그랜드 캐니언을 갔었기 때문에,

이번에는 다른 곳을 가보고 싶었다.

결과적으로는 정말 좋은 선택이었다.

사진으로는 다 담기지 않지만,

실제로 보면 압도적인 자연이라는 표현이 가장 잘 어울리는 곳이었다.

미국의 국립공원이 왜 유명한지 직접 와보니 알 것 같았다.

드디어 시작되는 USC 생활

요세미티를 다녀온 뒤

본격적으로 USC에서의 생활이 시작되었다.

학교를 돌아다니면서 캠퍼스도 구경하고,

학생증도 발급받았다.

미국 드라마에서만 보던 캠퍼스를 직접 걷고 있다는 사실이 아직도 신기했다.

그리고 드디어 받은 USC 학생증.

비록 단기간 프로그램이었지만,

학생증 하나만으로도 괜히 진짜 USC 학생이 된 기분이었다.

여기까지가 USC에서의 첫 번째 주말이었다.

새로운 환경,

새로운 사람들,

그리고 우연히 만난 우버 기사님까지.

아직 프로그램은 시작도 하지 않았지만,

벌써부터 많은 것을 느끼고 배우고 있었다.

다음 편에서는

드디어 USC에서 진행된 첫 번째 데이터 사이언스 강의와 컨퍼런스 이야기를 적어보려고 한다.

문제 링크

프로그래머스 - 타겟 넘버

문제 설명

numbers 배열에 들어 있는 모든 숫자를 순서대로 사용하면서, 각 숫자 앞에 + 또는 -를 붙여 target을 만드는 방법의 수를 구하는 문제다.

예를 들어 다음과 같은 입력이 주어진다.

numbers = [1, 1, 1, 1, 1]
target = 3

숫자 3을 만드는 방법은 다음과 같다.

-1 + 1 + 1 + 1 + 1 = 3
+1 - 1 + 1 + 1 + 1 = 3
+1 + 1 - 1 + 1 + 1 = 3
+1 + 1 + 1 - 1 + 1 = 3
+1 + 1 + 1 + 1 - 1 = 3

따라서 정답은 5가 된다.

처음 문제를 보고 든 생각

처음 문제를 읽었을 때는 배열에 있는 숫자를 모두 사용해 가능한 경우의 수를 계산해야 하므로,

완전탐색 문제인가?

라는 생각이 먼저 들었다.

각 숫자마다 더하는 경우와 빼는 경우가 존재하므로, 모든 조합을 확인해야 하기 때문이다.

그런데 문제를 조금 더 생각해보니 이 과정을 그래프 탐색, 정확히는 트리 탐색으로 표현할 수 있었다.

사실 이 문제가 프로그래머스의 DFS/BFS 알고리즘 문제에 포함되어 있어서 DFS나 BFS로 풀어야 한다는 힌트를 어느 정도 받은 것도 있다.

그중에서도 나는 DFS가 더 자연스럽다고 생각했다.

문제를 트리로 생각해보기

각 단계에서는 현재 숫자를 더할지, 뺄지 선택할 수 있다.

예를 들어 첫 번째 숫자가 1이라면 다음 두 방향으로 나뉜다.

현재 합계 0
├── +1
└── -1

다음 숫자에서도 다시 두 가지 선택지가 생긴다.

                 0
              /     \
            +1       -1
           /  \     /  \
         +1   -1  +1   -1

여기서 정확히 말하면 배열의 각 숫자 자체가 노드라기보다는,

지금까지 몇 번째 숫자까지 사용했고, 현재 합계가 얼마인지

를 하나의 상태, 즉 노드로 볼 수 있다.

그리고 각 노드에서 다음 숫자를

• 더하는 방향
• 빼는 방향

으로 두 개의 가지가 만들어진다.

따라서 숫자가 n개라면 트리의 깊이는 n이 되고, 마지막 깊이까지 내려갔을 때 현재 합계가 target과 같은지 확인하면 된다.

DFS를 선택한 이유

이 문제는 BFS로도 해결할 수 있다.

하지만 모든 숫자를 끝까지 사용한 뒤 결과를 확인해야 하므로, 한 경로를 마지막까지 내려가는 DFS가 구현하기 더 간단하다고 생각했다.

DFS의 흐름은 다음과 같다.

현재 합계에서 numbers[index]를 더한다.
↓

다음 숫자로 이동한다.

↓

현재 합계에서 numbers[index]를 뺀다.
↓

다음 숫자로 이동한다.

그리고 모든 숫자를 사용했을 때 현재 합계가 target과 같다면 정답의 개수를 증가시킨다.

<나의 풀이>

#include <string>
#include <vector>
using namespace std;

int count = 0; 

int DFS(int node , vector<int> arr , int index , int targetnum){

    if(arr.size() == index){ 
        if(node == targetnum){ 
            count++; 
        }
        return 0; 
    }

    DFS(node + arr[index] , arr , index + 1 , targetnum); 
    DFS(node - arr[index], arr , index + 1 , targetnum); 
    return 0; 
}

int solution(vector<int> numbers, int target) {  // 숫자는 모두 사용해야함
    // numbers 에는 숫자들이 나열되어 있다. target은 각 숫자들을 더하거나 빼서 만들 숫자
    int answer = 0;

    // left = -  , right = + 로 잡고 출발한다
    DFS(0 , numbers , 0 , target);

    answer = count; 

    return answer;
}

DFS는 다음 상태를 인자로 받는다.

node      : 현재까지 계산한 합계
arr       : 사용할 숫자 배열
index     : 현재 사용할 숫자의 위치
targetnum : 만들어야 하는 목표 숫자

처음에는 아직 아무 숫자도 사용하지 않았기 때문에 다음과 같이 시작한다.

DFS(0, numbers, 0, target);

• 현재 합계는 0
• 첫 번째 숫자의 인덱스는 0

이다.

종료 조건

재귀 함수에서 가장 중요한 부분은 종료 조건이다.

if (arr.size() == index) {
    if (node == targetnum) {
        count++;
    }

    return 0;
}

index가 배열의 크기와 같아졌다는 것은 모든 숫자를 사용했다는 의미다.

이때 현재까지 계산한 값인 node가 targetnum과 같다면 타겟 넘버를 만든 것이므로 count를 증가시킨다.

두 개의 재귀 호출

이 문제의 핵심은 다음 두 줄이다.

DFS(node + arr[index], arr, index + 1, targetnum);
DFS(node - arr[index], arr, index + 1, targetnum);

현재 숫자를 더한 경우와 뺀 경우를 각각 탐색한다.

처음 숫자뿐만 아니라 모든 숫자에 대해 +, - 두 방향을 모두 확인해야 한다.

예를 들어 현재 합계가 3이고 현재 숫자가 2라면 다음 상태는 두 개가 된다.

3 + 2 = 5
3 - 2 = 1

DFS는 먼저 한쪽 경로를 마지막까지 탐색하고, 탐색이 끝나면 되돌아와 다른 경로를 탐색한다.

실행 결과

정답이었다.

간단한 DFS를 구현하는 문제처럼 보이지만, 생각보다 문제에서 요구하는 핵심 아이디어가 분명히 있었다.

이 문제의 핵심 포인트

1. 문제를 보고 DFS를 떠올릴 수 있는가?

보통 DFS/BFS 문제라고 하면 그래프의 정점과 간선이 직접 주어지는 경우가 많다.

하지만 이 문제에는 일반적인 그래프가 등장하지 않는다.

대신 각 숫자마다 다음 두 가지 선택이 존재한다.

현재 숫자를 더한다.
현재 숫자를 뺀다.

하나의 상태에서 두 개의 다음 상태로 분기되고, 모든 숫자를 사용한 마지막 상태에서 결과를 확인한다.

따라서 이 문제는 다음과 같은 이진 트리 탐색 문제로 볼 수 있다.

현재 상태
├── 현재 숫자 더하기
└── 현재 숫자 빼기

DFS라고 생각해야 하는 핵심 이유는,

각 숫자마다 발생하는 두 가지 선택을 하나의 분기로 보고, 모든 선택 경로를 끝까지 탐색해야 하기 때문

이다.

그래프가 직접 주어지지 않아도 선택의 과정을 그래프로 바꿔 생각할 수 있어야 한다.

2. +와 - 두 가지 경우를 모두 탐색해야 한다

두 번째 핵심은 재귀 호출을 반드시 두 번 해야 한다는 것이다.

DFS(node + arr[index], arr, index + 1, targetnum);
DFS(node - arr[index], arr, index + 1, targetnum);

한쪽만 탐색하면 가능한 경우의 절반을 놓치게 된다.

특히 첫 번째 숫자를 무조건 양수로 시작한다고 생각하면 안 된다.

문제에서는 첫 번째 숫자에도 + 또는 -를 붙일 수 있기 때문이다.

+numbers[0]
-numbers[0]

따라서 초기값을 0으로 두고, 첫 번째 숫자부터 두 방향으로 분기해야 한다.

시간 복잡도

숫자가 하나 추가될 때마다 선택지는 두 배가 된다.

숫자의 개수를 n이라고 하면 가능한 경우의 수는 다음과 같다.

2 × 2 × 2 × ... × 2 = 2ⁿ

따라서 시간 복잡도는

O(2ⁿ)

이다.

문제에서 숫자의 개수는 최대 20개이므로 최대 경우의 수는 다음과 같다.

2²⁰ = 1,048,576

약 100만 개 정도이므로 완전탐색으로 충분히 해결할 수 있다.

재귀 호출의 최대 깊이는 숫자의 개수와 같으므로 공간 복잡도는 호출 스택 기준으로 O(n)이다.

코드를 조금 개선한다면

내 코드는 정답이지만 몇 가지 개선할 수 있는 부분이 있다.

1. 배열을 참조로 전달하기

현재 코드는 DFS를 호출할 때마다 vector를 복사한다.

int DFS(int node, vector<int> arr, int index, int targetnum)

배열의 내용을 수정하지 않으므로 const 참조로 전달하는 것이 더 효율적이다.

void DFS(
    int node,
    const vector<int>& arr,
    int index,
    int targetnum
)

2. 전역 변수 사용 줄이기

count를 전역 변수로 선언하면 함수가 여러 번 호출될 때 이전 값이 남아 있을 수 있다.

int count = 0;

최소한 solution()이 실행될 때 count를 초기화하는 것이 안전하다.

count = 0;

또는 DFS가 경우의 수를 직접 반환하도록 만들면 전역 변수 없이 해결할 수 있다.

개선한 풀이

#include <vector>

using namespace std;

int dfs(
    const vector<int>& numbers,
    int index,
    int currentSum,
    int target
) {
    if (index == numbers.size()) {
        return currentSum == target ? 1 : 0;
    }

    int plusCount = dfs(
        numbers,
        index + 1,
        currentSum + numbers[index],
        target
    );

    int minusCount = dfs(
        numbers,
        index + 1,
        currentSum - numbers[index],
        target
    );

    return plusCount + minusCount;
}

int solution(vector<int> numbers, int target) {
    return dfs(numbers, 0, 0, target);
}

이 방식은 각 경로에서 타겟 넘버를 만들었다면 1, 만들지 못했다면 0을 반환한다.

그리고 두 방향에서 반환된 값을 더한다.

return plusCount + minusCount;

전역 변수 없이 함수의 반환값만으로 정답을 계산할 수 있어 조금 더 깔끔하다.

마무리

처음에는 단순한 완전탐색 문제라고 생각했지만, 핵심은 선택 과정을 트리로 변환하는 데 있었다.

각 숫자에서

더할 것인가?
뺄 것인가?

라는 두 개의 선택지가 만들어지고, 이를 마지막 깊이까지 탐색하면 모든 경우의 수를 확인할 수 있다.

이번 문제에서 기억해야 할 포인트는 다음과 같다.

각 상태에서 두 가지 선택지가 생긴다.
↓

선택 과정을 이진 트리로 표현할 수 있다.
↓

모든 숫자를 사용한 뒤 결과를 확인해야 한다.
↓

DFS로 각 경로를 마지막까지 탐색한다.

DFS/BFS 문제라고 해서 항상 그래프가 직접 주어지는 것은 아니다.

문제 속 선택과 상태 변화를 보고 스스로 그래프 구조를 만들어내는 것이 더 중요한 문제였다고 생각한다.

데이터는 어떤 상품을 함께 선택할까? - Association Rule Learning

이번 강의에서는 지금까지 배웠던 Classification이나 Regression과는 조금 다른 주제를 다뤘다.

바로 Association Learning(연관 규칙 학습) 이다.

처음에는 "Association"이라는 단어만 보고 추천 시스템을 만드는 알고리즘 정도라고 생각했다.

하지만 강의를 듣고 보니,

Association Rule은 예측(Prediction) 을 위한 알고리즘이라기보다,

데이터 속에서 숨겨진 관계를 발견하는(Data Mining) 기법

이라는 점이 가장 큰 차이였다.

Association Learning이란?

교수님은 가장 먼저 Association Learning을 이렇게 설명하셨다.

데이터 안에서 함께 자주 등장하는 패턴을 찾아내는 방법

예를 들어 마트에서 장을 본다고 생각해 보자.

우유
빵
버터

이 세 상품이 항상 같이 구매된다면

이 세 상품 사이에는 어떤 관계가 존재할 가능성이 높다.

Association Learning은

이처럼

"무엇이 무엇과 함께 나타나는가?"

를 찾아내는 것이 목표이다. Lecture-Note-06-Association.pdf

하지만 Association은 인과관계가 아니다

강의에서 가장 먼저 강조했던 부분도 이것이었다.

Bread

↓

Butter

라는 Rule이 있다고 해서

빵이 버터를 구매하게 만든 것은 아니다.

Association Rule은

단순히

함께 나타날 가능성이 높다

는 의미일 뿐이다.

즉,

Association은 Correlation이지

Causation은 아니다.

이 부분은 교수님이 여러 번 강조했던 내용이라 특히 기억에 남았다. Lecture-Note-06-Association.pdf

Rule은 어떻게 표현할까?

Association Rule은

아주 간단하게 표현된다.

X → Y

예를 들어

{Bread}

↓

{Butter}

라는 Rule은

빵을 구매한 사람이

버터도 함께 구매할 가능성이 높다는 의미이다.

하지만

이 Rule이 좋은 Rule인지는

아직 알 수 없다.

그래서

세 가지 기준이 등장한다.

Support

첫 번째는

Support이다.

Support는

이 조합이 얼마나 자주 등장했는가

를 의미한다.

예를 들어

100개의 거래 중

Bread + Butter

가

30번 등장했다면

Support는 30%이다.

즉,

인기 있는 조합인지

먼저 확인하는 과정이다. Lecture-Note-06-Association.pdf

Confidence

두 번째는

Confidence이다.

Confidence는

조금 더 의미 있는 값이다.

Bread를 구매한 사람 중

Butter도 구매한 사람은?

즉,

조건부 확률이다.

Support가

얼마나 자주 등장했는지를 본다면,

Confidence는

실제로 함께 구매될 가능성을 의미한다. Lecture-Note-06-Association.pdf

Confidence가 높다고 좋은 Rule일까?

교수님은 여기서 재미있는 예시를 보여주셨다.

Toothbrush

↓

Milk

Confidence가

70%였다.

처음에는

"굉장히 좋은 Rule 아닌가?"

라고 생각했다.

그런데

알고 보니

원래 우유는 거의 모든 사람이 구매하는 상품이었다.

즉,

칫솔 때문이 아니라

우유 자체가 인기 상품이었던 것이다.

그래서

Confidence 하나만으로는

좋은 Rule인지 판단할 수 없다. Lecture-Note-06-Association.pdf

Lift가 필요한 이유

그래서 등장한 것이

Lift이다.

Lift는

정말로 두 상품이 서로 영향을 주는가?

를 측정한다.

교수님은

Lift가 1보다 크면

실제로 함께 구매되는 경향이 있다고 설명하셨다.

반대로

1보다 작으면

Confidence가 높더라도

의미 있는 Rule이 아닐 수 있다.

Confidence만 보고 판단하면

잘못된 결론을 내릴 수 있다는 점이 흥미로웠다. Lecture-Note-06-Association.pdf

Lift만 봐도 안 된다

그런데

Lift도 완벽하지 않았다.

교수님은

두 가지 경우를 비교해 주셨다.

첫 번째는

Lift는 매우 높지만

Support가 매우 낮은 경우.

이 경우는

우연히 발생한 패턴일 수도 있다.

반대로

Support는 매우 높지만

Lift가 1에 가까운 경우도 있다.

이 경우는

그 상품이 원래 많이 팔리는 상품일 뿐

특별한 연관성은 없다.

결국

Support

Confidence

Lift

세 가지를 함께 봐야 한다는 것이 이번 강의의 핵심이었다. Lecture-Note-06-Association.pdf

어디에 활용될까?

교수님은 Association Learning이

생각보다 다양한 분야에서 사용된다고 설명하셨다.

대표적으로

• 마트 상품 배치
• 추천 시스템
• 의료 데이터 분석
• 콘텐츠 추천

등이 있다.

특히 마트에서는

같이 구매되는 상품을 가까운 위치에 배치해

추가 구매를 유도한다고 한다.

우리가 마트에서

우유 옆에 시리얼,

맥주 옆에 과자가 있는 이유도

이런 데이터 분석 덕분이라는 점이 재미있었다. Lecture-Note-06-Association.pdf

그런데 문제가 하나 있다

여기까지는

Association Rule이 굉장히 쉬워 보였다.

하지만 교수님은

곧바로 하나의 질문을 던지셨다.

상품이 100,000개라면?

가능한 Rule의 개수는

상상하기 어려울 정도로 많아진다.

모든 조합을 전부 계산하는 것은

사실상 불가능하다.

그래서

효율적으로

필요한 조합만 찾아내는 알고리즘이 등장한다.

바로

Apriori Algorithm이다.

다음 강의에서는

Apriori가 어떻게

수많은 조합을 효율적으로 줄여가며

Frequent Itemset을 찾는지 정리해보려고 한다.

대부분의 현실 데이터는
행과 열로 구성된 Tabular Data 형태로 저장되어 있다.

처음 머신러닝을 공부할 때는
데이터가 준비되어 있으면 곧바로 모델을 선택하고 학습하면 되는 줄 알았다.

데이터 준비
↓
모델 선택
↓
학습
↓
평가

하지만 실제 데이터는 그렇게 친절하지 않았다.

값이 비어 있고,

같은 의미인데 표기가 다르고,

숫자형 Column에 문자열이 섞여 있고,

무한대가 들어가 있고,

앞뒤 공백이 붙어 있고,

정상 범위를 크게 벗어난 값도 존재한다.

예를 들어 다음과 같은 데이터가 있다고 해보자.

사람이 보면 금방 이상한 부분을 찾을 수 있다.

NaN
무한대
앞뒤 공백
문자열 형태의 알 수 없는 값
서로 다른 Target 표기

하지만 컴퓨터는 이것을 보고

이 값은 이상하니까 알아서 고쳐야겠다.

라고 판단하지 않는다.

우리가 넣어준 데이터 그대로 계산한다.

따라서 제대로 정리되지 않은 데이터는
잘못된 분석과 잘못된 학습 결과로 이어질 수 있다.

이번 강의에서는 모델링보다 먼저 수행해야 하는
Data Exploration의 7단계를 다뤘다.

이번 글을 통해 데이터 탐색이 무엇이고,
결측치와 이상치를 어떻게 바라봐야 하며,
변수 변환과 Feature Creation이 왜 필요한지 정리해보고자 한다.

Data Exploration이란?

Data Exploration은
본격적인 모델링에 들어가기 전에 데이터를 살펴보며
그 특성을 이해하는 과정이다.

쉽게 말하면 다음 질문에 답하는 것이다.

어떤 데이터가 들어 있는가?

각 Column은 무엇을 의미하는가?

값은 어떤 분포를 가지는가?

서로 관련된 변수는 무엇인가?

누락되거나 잘못된 값은 없는가?

모델링 전에 어떤 처리가 필요한가?

강의 자료에서는 데이터 탐색의 주요 목적을 다음과 같이 설명했다.

- 적절한 전처리 및 분석 도구 선택
- 사람이 가진 패턴 인식 능력 활용
- 흥미로운 변수 발견
- 데이터 내부의 패턴 발견
- 데이터 그룹 발견
- 이상치 발견
- 오류 발견

결국 Data Exploration은
단순히 그래프 몇 개를 그리는 과정이 아니다.

모델이 데이터를 학습하기 전에
사람이 먼저 데이터를 이해하는 과정이다.

데이터 분석과 데이터 탐색의 차이

데이터 분석은 데이터를 정리하고,
표현하고, 요약하고, 질문에 답하는 과정이다.

Organizing
Displaying
Summarizing
Asking Questions

반면 데이터 탐색은
아직 명확하게 정해지지 않은 가능성을 여러 방향으로 확인하는 과정에 가깝다.

이 변수에 이상한 값은 없을까?

두 변수 사이에 숨은 관계가 있지 않을까?

특정 그룹에서만 다른 패턴이 나타나지 않을까?

분석에는 구조적인 사고가 필요하고,
탐색에는 데이터를 여러 방향으로 잘라보는 인내심이 필요하다는 설명이 기억에 남았다.

결국 입력 데이터의 품질이
출력 결과의 품질을 결정한다.

Garbage In
↓
Garbage Out

좋지 않은 데이터를 강력한 모델에 넣는다고 해서
좋은 결과가 나오는 것은 아니다.

데이터는 먼저 시각화해야 한다

데이터를 탐색할 때는
먼저 각 변수를 독립적으로 확인한 뒤
변수 사이의 관계를 살펴보는 것이 좋다.

강의에서는 다음 순서를 제시했다.

각 변수 개별 확인
↓
그래프로 분포 확인
↓
수치적 요약 추가
↓
변수 사이의 관계 분석

왜 시각화가 중요할까?

평균과 표준편차가 같더라도
실제 데이터의 형태는 완전히 다를 수 있기 때문이다.

대표적인 사례가 Anscombe's Quartet이다.

네 개의 데이터셋은 다음 통계량이 거의 같다.

평균
표준편차
상관계수
회귀선

하지만 산점도로 보면
각 데이터의 패턴은 완전히 다르다.

직선 관계
곡선 관계
이상치 하나가 결과를 좌우하는 관계
특정 x값에 몰려 있는 관계

즉, 통계 수치만 보고 데이터의 모습을 판단하면
중요한 문제를 놓칠 수 있다.

숫자로 요약하기 전에
그래프로 직접 확인해야 한다.

표본을 통해 모집단을 추론한다

현실에서는 모든 데이터를 수집하기 어려운 경우가 많다.

예를 들어 미국 전체 성인의 평균 소비 패턴을 분석한다고 해보자.

모든 사람의 데이터를 전부 수집하는 것은
시간과 비용 측면에서 현실적이지 않다.

그래서 모집단 전체가 아니라
이를 대표할 수 있는 Sample을 선택한다.

Population
↓
Representative Sample 수집
↓
Sample 분석
↓
Population에 대한 Inference

여기서 중요한 것은
표본의 크기만이 아니다.

표본이 모집단을 제대로 대표하지 못한다면
아무리 복잡한 분석을 해도 잘못된 결론에 도달할 수 있다.

따라서 Sampling 과정에서도 다음을 생각해야 한다.

특정 집단만 과도하게 포함되지 않았는가?

중요한 집단이 빠지지는 않았는가?

수집 방식에서 편향이 발생하지 않았는가?

모든 데이터를 사용할 필요는 없지만,
사용하는 데이터가 전체를 잘 대표해야 한다.

Data Exploration의 7단계

강의에서는 데이터 탐색 과정을
다음 7단계로 정리했다.

1. Variable Identification
2. Univariate Analysis
3. Bi-variate Analysis
4. Missing Values Treatment
5. Outlier Treatment
6. Variable Transformation
7. Variable Creation

하나씩 정리해보자.

Step 1. Variable Identification

첫 번째 단계는
데이터에 어떤 변수가 존재하는지 확인하는 것이다.

먼저 Predictor와 Target을 구분해야 한다.

Predictor Variable
→ 예측에 사용하는 입력값

Target Variable
→ 모델이 최종적으로 예측해야 하는 값

예를 들어 학생이 크리켓을 할지 예측하는 데이터가 있다고 해보자.

이때 변수는 다음과 같이 구분할 수 있다.

Predictor
- Gender
- Exam Score
- Height
- Weight

Target
- Play Cricket

그다음 각 변수의 자료형과 범주를 확인한다.

Student ID → Character / Identifier

Gender → Categorical

Exam Score → Quantitative

Height → Quantitative

Play Cricket → Binary Categorical

여기서 Student ID는 숫자처럼 보일 수 있지만
크기의 의미가 있는 수치형 변수가 아니다.

S002가 S001보다 두 배 크다

같은 해석은 성립하지 않는다.

즉, 숫자처럼 보인다고 모두 수치형 데이터는 아니다.

범주형 변수와 수치형 변수

변수는 크게 두 가지로 나눌 수 있다.

Categorical Variable

개체를 특정 그룹에 배치하는 변수다.

성별
지역
직업
결혼 여부
상품 종류

범주형 데이터는 다시 나눌 수 있다.

Nominal
→ 순서가 없는 범주

예시:
국가, 혈액형, 직업

Ordinal
→ 순서가 있는 범주

예시:
만족도 1~5
질병 단계
등급

Quantitative Variable

수치적 크기가 의미를 가지며
평균과 같은 연산을 적용할 수 있는 변수다.

나이
키
몸무게
소득
시험 점수

어떤 유형의 변수인지 알아야
적절한 분석과 시각화 방법을 선택할 수 있다.

Step 2. Univariate Analysis

Univariate Analysis는
변수를 하나씩 독립적으로 분석하는 과정이다.

여기서 가장 중요한 것은
Distribution, 즉 분포를 이해하는 것이다.

분포는 다음을 알려준다.

어떤 값이 존재하는가?

각 값이 얼마나 자주 등장하는가?

분포를 이해하는 것이 중요한 이유는
이후의 거의 모든 선택에 영향을 주기 때문이다.

정규분포인가?

한쪽으로 치우쳐 있는가?

여러 봉우리가 존재하는가?

극단적으로 큰 값이 있는가?

결측치가 많은가?

분포에 따라 다음이 달라진다.

사용할 통계 검정

시각화 방법

결측치 처리

이상치 처리

변수 변환

모델 선택

연속형 변수 분석

연속형 변수는
중심 경향과 퍼짐 정도를 확인한다.

중심 경향

Mean
Median
Mode
Minimum
Maximum

분산 정도

Range
Quartile
IQR
Variance
Standard Deviation
Skewness
Kurtosis

시각화

Histogram
Box Plot
Dot Plot

예를 들어 고객 소비 금액의 평균이 100만 원이라고 해보자.

하지만 대부분의 고객이 2만 원을 소비하고
일부 고객만 1억 원을 소비했다면
평균 100만 원은 일반적인 고객을 잘 설명하지 못한다.

따라서 평균만 보는 것이 아니라

중앙값
분포의 모양
이상치

를 함께 확인해야 한다.

범주형 변수 분석

범주형 데이터는
각 범주가 몇 번 나타나는지 확인한다.

주로 다음을 사용한다.

Count
Count Percentage
Frequency Table
Bar Chart

예를 들어 지역 변수가 다음과 같다고 해보자.

이 표만 봐도
특정 범주에 데이터가 지나치게 몰려 있는지 확인할 수 있다.

분류 문제에서는 이런 불균형이
Class Imbalance 문제로 이어질 수 있다.

Step 3. Bi-variate Analysis

Bi-variate Analysis는
두 변수 사이의 관계를 분석하는 과정이다.

예를 들어 다음 질문을 확인할 수 있다.

소득이 증가하면 구매 금액도 증가하는가?

나이가 증가하면 이탈 가능성이 낮아지는가?

성별에 따라 상품 선택 비율이 다른가?

특정 Feature가 Target과 관련이 있는가?

이 분석을 통해 다음을 판단할 수 있다.

Target과 관련된 변수

도움이 되지 않는 변수

서로 중복되는 변수

비선형 관계

새로운 Feature 생성 가능성

예를 들어 집값 예측에서

대지 면적
→ 집값과 강한 관계

현관문의 색상
→ 집값과 의미 있는 관계가 없음

이라면 현관문 색상은
모델에 큰 가치를 제공하지 않을 가능성이 있다.

또 다음 두 변수가 있다고 해보자.

연간 소득
월간 소득

두 값은 거의 같은 정보를 담고 있다.

이 둘을 모두 사용하면
중복 정보와 다중공선성 문제가 발생할 수 있으므로
하나를 선택하는 것이 나을 수 있다.

Continuous & Continuous

두 연속형 변수 사이의 관계는
주로 Scatter Plot으로 확인한다.

강한 양의 상관관계

약한 양의 상관관계

상관관계 없음

음의 상관관계

곡선 관계

선형 관계의 강도를 수치화할 때는
Correlation을 사용할 수 있다.

-1
→ 완전한 음의 선형관계

0
→ 선형 상관관계가 없음

+1
→ 완전한 양의 선형관계

주의해야 할 점도 있다.

상관계수가 0이라고 해서
두 변수 사이에 아무 관계도 없다는 뜻은 아니다.

곡선 형태의 비선형 관계가 존재한다면
선형 상관계수는 낮게 나올 수 있다.

그래서 상관계수만 보지 말고
Scatter Plot을 함께 확인해야 한다.

Categorical & Categorical

두 범주형 변수 사이의 관계는
다음 방법으로 확인할 수 있다.

Two-way Table

Count / Count Percentage

Stacked Bar Chart

Chi-square Test

예를 들어 성별과 상품 구매 여부의 관계를 확인하려면
성별마다 구매와 미구매 비율을 비교할 수 있다.

Categorical & Continuous

범주형 변수와 연속형 변수를 비교할 때는
범주별 수치 분포를 비교한다.

예를 들어 직업별 연봉을 분석한다면
다음과 같은 방법을 사용할 수 있다.

Box Plot

Violin Plot

범주별 Mean / Median

분산 비교

이 과정을 통해
특정 범주가 수치형 Target과 관련이 있는지 확인할 수 있다.

Step 4. Missing Values Treatment

Missing Value는
데이터에 값이 존재하지 않는 상태다.

일반적으로 다음처럼 표현된다.

NaN
NULL
None
빈 문자열
?

결측치를 그대로 두면
다음 문제가 발생할 수 있다.

모델의 학습 능력 감소

편향된 결과 발생

잘못된 분류와 예측

통계량 왜곡

일부 알고리즘 실행 실패

Linear Regression이나 SVM처럼
결측치를 직접 처리하지 못하는 알고리즘도 있다.

하지만 결측치가 문제인 이유는
단순히 값이 없기 때문만은 아니다.

어떤 데이터가 비어 있다는 사실 자체가
중요한 정보일 수 있다.

예를 들어 특정 연령대만
소득 입력을 자주 거부했다면
결측 여부 자체가 해당 집단의 특성과 관련될 수 있다.