하고 싶은 대로

컴퓨터구조 다시 공부해보기

sjh9714 — Mon, 10 Aug 2026 16:42:36 +0900

컴퓨터구조 학점이 D-다. 이번 학기에 재수강하게 돼서 미리 한 바퀴 돌렸다. 강의가 14주고 평가는 중간과 기말이 거의 전부라, 시험에 나올 계산 위주로 다섯 덩어리를 잘랐다.

정리하고 보니 이 과목은 명령어 하나가 컴퓨터 안에서 어떻게 처리되는지를 앞에서 뒤로 따라간다. 그리고 뒤로 갈수록 질문이 느린 것을 어떻게 견디느냐로 바뀐다.

1. 성능 평가

프로그램이 얼마나 걸리는지 재는 방법부터 시작한다. 생각해보면 답은 뻔하다. 명령어를 몇 개 실행하는지, 명령어 하나에 클럭이 몇 번 드는지, 클럭 한 번이 몇 초인지. 이 셋을 곱하면 시간이 나오는데, 시험은 셋을 따로따로 흔들어서 묻는다.

CPU 시간 = 명령어 수(IC) × CPI × 클럭 주기
         = 명령어 수(IC) × CPI ÷ 클럭 주파수

CPI는 명령어 하나당 클럭 수인데, 명령어마다 다르다. 곱셈은 오래 걸리고 덧셈은 금방 끝난다. 그래서 종류별 비율을 알고 있으면 평균을 내서 쓴다.

평균 CPI = Σ(종류별 CPI × 종류별 비율)

Σ는 종류마다 곱해서 전부 더하라는 뜻이다. 명령어 100개짜리 프로그램으로 세어보면 바로 보인다. ALU가 50%에 CPI 1이면 50개가 50클럭을 쓰고, load가 20%에 CPI 5면 20개가 100클럭을 쓴다. 이렇게 다 더한 뒤 명령어 100개로 나눈 값이 평균 CPI다.

종류	CPI	비율	곱하면
ALU	1	0.5	0.5
load	5	0.2	1.0
store	3	0.1	0.3
branch	2	0.2	0.4
		합	2.2

여기서 두 가지를 조심해야 한다. 하나는 클럭 주기와 주파수가 서로 역수라는 점이다. 2GHz면 주기가 0.5ns인데, 문제가 어느 쪽으로 줬는지부터 봐야 한다.

다른 하나는 클럭이 빠르다고 무조건 빠른 게 아니라는 점이다. 2GHz에 CPI 1.5인 컴퓨터와 3GHz에 CPI 2.5인 컴퓨터를 비교하면, 클럭이 느린 쪽이 오히려 약 1.11배 빠르다. 클럭만 보고 고르면 틀리게 돼 있다.

마지막은 암달의 법칙이다.

속도 향상 = 1 ÷ ((1−f) + f/s)
            f = 개선되는 부분의 비율, s = 그 부분이 빨라지는 배수

프로그램의 60%가 곱셈인데 곱셈기를 4배 빠르게 만들면 전체는 1.82배밖에 안 빨라진다. 곱셈을 아예 공짜로 만들어도 2.5배가 한계다. 나머지 40%는 그대로 남아 있기 때문이다. 일부만 개선해서는 전체가 그만큼 빨라지지 않는다는 얘기다.

2. 명령어 형식

명령어 한 줄은 결국 32비트짜리 숫자 하나다. 그 안에 무슨 연산인지, 어떤 값을 쓸 건지, 결과를 어디에 넣을 건지를 다 담아야 한다.

레지스터를 가리키는 자리가 5비트인 이유가 여기서 나온다. MIPS 레지스터가 32개인데, 32개 중 하나를 고르려면 5자리가 필요하다. 2를 다섯 번 곱하면 32니까 그렇다. 외울 숫자가 아니라 세면 나오는 숫자다.

형식	배치	쓰임
R	op(6) rs(5) rt(5) rd(5) shamt(5) funct(6)	`add`, `sub` 같은 계산
I	op(6) rs(5) rt(5) immediate(16)	`lw`, `sw`, `addi`, `beq`
J	op(6) address(26)	`j`, `jal`

형식이 셋인 건 담아야 할 게 다르기 때문이다. 계산 명령어는 재료 둘과 결과 하나가 필요해서 레지스터 자리가 세 개다. addi처럼 숫자를 직접 쓰는 명령어는 그 숫자를 넣을 자리가 통으로 필요해서 레지스터 자리 하나를 포기하고 16비트를 확보한다. 멀리 점프하는 명령어는 아예 주소에 26비트를 다 쓴다.

분기 명령어가 재미있다. beq가 쓸 수 있는 자리는 16비트뿐인데 주소는 32비트다. 담을 수가 없다. 그래서 주소 대신 여기서 몇 칸 건너뛸지를 적는다.

분기 목적지 = (PC + 4) + (offset × 4)

× 4가 붙는 건 명령어 하나가 4바이트라서다. 칸 단위로 세면 같은 16비트로 네 배 멀리 갈 수 있다.

3. 파이프라이닝

명령어 하나를 처리하는 일은 다섯 토막으로 나뉜다.

단계	하는 일
IF	메모리에서 명령어를 꺼낸다
ID	명령어를 쪼개고 레지스터 값을 읽는다
EX	계산한다
MEM	메모리를 읽거나 쓴다
WB	결과를 레지스터에 적는다

빨래로 생각하면 쉽다. 세탁기를 돌리고 건조기에 넣고 개서 서랍에 넣는 일을 한 사람씩 다 끝내고 다음 사람으로 넘어가면, 첫 사람이 서랍에 넣을 때까지 세탁기는 논다. 첫 사람 빨래가 건조기로 넘어갈 때 세탁기에 둘째 사람 빨래를 넣으면 아무도 안 논다. 기계를 놀리지 않고 겹쳐서 흘리는 것, 그게 파이프라인이다.

여기서 클럭을 어디서 끊느냐가 갈린다. 단일 사이클은 명령어 하나를 클럭 한 번에 끝내니까, 클럭 한 번이 다섯 단계를 전부 통과할 만큼 길어야 한다. 파이프라인은 클럭 한 번에 단계 하나만 하면 되니까 제일 느린 단계만 버티면 된다.

방식	클럭 주기	CPI
단일 사이클	모든 단계의 합 (800ps)	1
다중 사이클	제일 느린 단계 하나 (200ps)	명령어마다 다름
파이프라인	제일 느린 단계 하나 (200ps)	이상적으로 1

단계 시간이 각각 200, 100, 200, 200, 100ps일 때의 숫자다. 합이냐 최댓값이냐를 바꿔 쓰면 그 문제는 통째로 틀린다.

시간 공식은 그림을 그려보면 안 외워진다. 명령어 세 개를 다섯 단계에 흘리면 첫 명령어가 끝나는 데 5클럭이 걸리고, 그 뒤로는 매 클럭 하나씩 나오니까 남은 두 개에 2클럭이 더 든다. 합쳐서 7클럭이고, 이걸 일반화한 게 아래 공식이다.

파이프라인 총 클럭 = 단계 수 + (명령어 수 − 1)
총 시간 = 총 클럭 × 클럭 주기

명령어가 백만 개면 5 + 999,999라서 앞의 5는 있으나 마나 해진다. 그래서 CPI가 1에 가까워진다. 다만 파이프라인은 명령어 하나를 빨리 끝내주지는 않는다. 오히려 조금 늘어난다. 빨라지는 건 명령어 하나가 아니라 전체 처리량이다.

4. 해저드

겹쳐서 돌리니까 생기는 문제다. 앞 명령어가 아직 결과를 안 적었는데 다음 명령어가 그 값을 읽으려 들면 곤란해진다.

종류	언제	해결
구조적	같은 부품을 동시에 쓸 때	부품을 늘린다
데이터	앞 결과를 뒤에서 바로 쓸 때	포워딩, 안 되면 스톨
제어	분기 결과가 나오기 전에 다음 걸 가져와야 할 때	예측한다

데이터 해저드는 값이 언제 나오고 언제 필요한지만 비교하면 풀린다. 원래 값은 WB에서 레지스터에 적히고 다음 명령어가 ID에서 읽어 가는데, 이러면 시간이 안 맞는다. 그래서 계산이 끝난 곳에서 필요한 곳으로 값을 직접 질러 보낸다. 레지스터에 넣었다 빼는 왕복을 생략하는 것이고, 이걸 포워딩이라고 부른다.

문제는 메모리에서 값을 읽어 오는 명령어다. 계산 명령어는 EX에서 값이 완성되는데 lw는 MEM에 가서 읽어야 값이 나온다. 한 단계 늦다. 다음 명령어가 EX를 시작할 때 lw는 아직 손에 값을 못 쥐고 있어서, 없는 값을 넘겨줄 수가 없다. 그래서 한 클럭을 그냥 흘려보낸다.

상황	스톨
바로 윗줄이 `lw`이고 그 값을 씀	1
바로 윗줄이 계산 명령	0
`lw`인데 두 줄 이상 떨어져 있음	0
포워딩이 없는 파이프라인	2 또는 3

세 번째 줄이 함정이다. lw 두 개가 붙어 있고 그 아래에서 둘 다 쓰면 스톨을 두 번 세기 쉬운데, 멀리 있는 쪽은 이미 값이 나와 있어서 세면 안 된다. 마지막 줄은 문제에 단서가 있어야 정해진다. 레지스터 파일이 같은 클럭에 쓰고 읽을 수 있다는 조건이 있으면 2, 없으면 3이다.

분기는 성격이 다르다. 어디로 갈지 아직 모르는데 다음 명령어를 가져와야 하니 일단 찍는다. 맞으면 그냥 흘러가고, 틀리면 잘못 가져온 걸 버리는데 그때 버리는 클럭이 벌점이다.

분기 벌점이 있을 때   CPI = 1 + (분기 비율 × 벌점 사이클)
예측이 있으면        CPI = 1 + (분기 비율 × 틀리는 비율 × 벌점)

기본 CPI 1에 더해지는 것이지 곱하는 게 아니다. 그리고 예측이 80% 맞는다고 하면 0.8이 아니라 틀리는 비율 0.2를 곱해야 한다. 벌점은 틀렸을 때만 받는다.

5. 캐시

메모리는 크지만 느리다. 명령어 하나에 백 클럭씩 기다릴 수는 없으니 자주 쓸 것만 가까운 곳에 작게 얹어둔다. 그런데 작으니까 어디에 놓을지 규칙이 필요해진다.

주차장으로 생각하면 편하다. 칸이 네 개인데 차가 여덟 대라고 해보자. 차 번호를 4로 나눈 나머지 칸에 대기로 정하면 규칙은 간단해지지만, 0번 차와 4번 차가 같은 칸을 쓰게 된다. 0번 칸에 서 있는 차가 둘 중 누구인지 알 수 없으니 앞유리에 번호표를 붙여둔다.

캐시가 주소를 세 조각으로 자르는 게 정확히 이 일이다. 어느 칸에 댈지가 인덱스, 그 칸에 든 게 정말 찾던 것인지가 태그다. 그리고 메모리에 한 번 다녀올 때 여러 개를 통째로 끌고 오기 때문에 그중 몇 번째인지도 알아야 하는데, 그게 오프셋이다.

주소 = [ 태그 | 인덱스 | 오프셋 ]

오프셋 = log₂(블록 크기)
집합 수 = (캐시 크기 ÷ 블록 크기) ÷ 연관도
인덱스 = log₂(집합 수)
태그   = 주소 비트 − 인덱스 − 오프셋

32비트 주소에 캐시 16KB, 블록 16바이트, 직접 사상이면 오프셋 4, 인덱스 10, 태그 18이 된다. 셋을 더해 32가 나오는지가 검산이다. 태그는 계산해서 나오는 게 아니라 쓰고 남은 것이다.

인덱스는 집합 수로 센다. 블록 수가 아니다. 직접 사상만 연습하면 둘이 같아서 구분이 안 되는데, 연관도를 4배 올리면 인덱스가 2비트 줄고 태그가 2비트 는다.

여기서 제일 억울한 상황이 나온다. 빈 칸이 세 개나 남아 있는데도 하필 같은 칸을 원해서 쫓겨나는 경우다. 이걸 막으려고 칸 몇 개를 묶어서 그 안에서는 아무 데나 대게 해주는 게 집합 연관이다. 대신 찾을 때 번호표를 여러 개 확인해야 해서 조금 느려진다.

AMAT = 적중 시간 + (실패율 × 실패 손실)

캐시에는 항상 먼저 들르고, 없을 때만 추가로 메모리에 다녀온다. 그래서 곱하기가 아니라 더하기다. 적중 시간 1, 실패율 5%, 실패 손실 100이면 AMAT는 6이 된다. 실패율을 2%로 줄이면 3이 되는데, 3%포인트 차이로 절반이 되는 건 실패 손실이 적중 시간의 백 배라서다.

실패 종류	줄이는 법	대신 나빠지는 것
강제	블록 크기를 키운다	실패 손실이 커진다
용량	캐시를 키운다	느려지고 비싸진다
충돌	연관도를 올린다	적중 시간이 늘어난다

한 바퀴 돌고 나서

다섯 덩어리가 따로 노는 것 같았는데 다 하고 보니 한 줄이었다. 명령어를 32비트에 어떻게 담을지 정하고, 처리를 단계로 쪼개 겹치고, 겹쳐서 생긴 문제를 포워딩과 스톨로 손보고, 느린 메모리를 캐시로 가린다. 그리고 첫 덩어리의 공식이 그게 실제로 빨라졌는지 재는 자다.

공짜가 없다는 것도 계속 나온다. 파이프라인은 명령어 하나를 빨리 끝내주지 않고 전체를 빨리 끝낸다. 연관도를 올리면 충돌은 줄지만 적중 시간이 는다. 블록을 키우면 강제 실패는 줄지만 실패 손실이 커진다. 어느 쪽을 택할지가 이 과목이 계속 던지는 질문이다.

남은 네 과목도 이렇게 한 바퀴씩 돌려볼 생각이다.

하네스, 루프, 그래프 - 직접 짜보고 알게 된 것

sjh9714 — Sun, 9 Aug 2026 04:58:44 +0900

AI 에이전트를 공부한다고 유튜브를 계속 보는데, 어느 순간부터 하네스니 루프니 그래프니 하는 말이 반복해서 나왔다.

찾아보니 셋 다 결국 같은 걸 묻고 있었다. AI한테 일을 맡길 때 그 주위에 뭘 세워둘 것인가, 그리고 그 답이 세 가지라는 얘기였다.

마침 나한테 대볼 게 있었다. 오픈소스에 매일 PR을 하나씩 올리는 자동화를 몇 달째 돌리고 있어서, 셋을 거기다 하나씩 맞춰봤다.

셋이 뭐냐면

하네스는 규칙을 문서에 박아두는 방식이다. 뭘 건드리면 안 되고 무엇을 통과해야 결과물을 내보내는지를 적어두면, 에이전트가 매번 그걸 읽고 일한다.

루프는 정해진 시각에 반복해서 돌리는 방식이다. 사람이 시킬 때만 도는 게 아니라 알아서 깨어난다.

그래프는 일의 단계를 상자로 그리고 그 사이를 화살표로 잇는 방식이다. 어디서 갈라지고 어디로 되돌아가는지가 그림에 남는다.

내 자동화를 열어보니 앞의 둘은 이미 있었다. 그렇게 부르는 물건인 줄 몰랐을 뿐이다.

하네스는 문서 하나였다. 작업 폴더에 CLAUDE.md가 있고 절이 28개다. 저장소 정책 확인, 후보 점수표, 중복 작업 검사, 재현 규칙, 회귀 테스트 규칙. 흉터라고 쓴 그 규칙들이 실제로는 이 파일이다.

루프는 예약 실행 세 개였다. 아침 9시에 열린 PR을 훑고, 10시·14시·18시에 새 후보를 찾고, 밤 9시에 리뷰에 대응한다. 내가 켜두지 않아도 맥이 시간에 맞춰 알아서 깨운다.

그래프는 없었다. 그래서 그것만 만들어봤다. LangGraph라는 도구로 같은 파이프라인을 상자와 화살표로 옮겨 적었다. 새 규칙은 하나도 안 만들고 이미 있는 걸 옮기기만 했다.

화살표는 원래 있었다

옮기면서 제일 먼저 안 건, 그래프로 그린다는 게 없던 걸 만드는 일이 아니라는 거였다.

CLAUDE.md에 "재현이 안 되면 손대지 않는다"는 문장이 있다. 버그가 내 컴퓨터에서 실제로 재현되지 않으면 그 이슈는 건드리지 말라는 뜻이다. 그래프에서 이건 재현 상자에서 후보 고르기 상자로 되돌아가는 화살표가 된다. 문장일 때는 규칙이었는데, 그림에서는 길이다.

돌려보면 이렇게 나온다.

오늘 몫 남았나 → 남음
후보 고르기    → rubocop 선택 (10점 만점에 9점)
재현           → 실패, 후보 고르기로 되돌아감
후보 고르기    → hugo 선택 (9점)
재현           → 됨

첫 후보가 재현이 안 되니 알아서 다음 후보로 갔다. 예약 실행으로 돌릴 때도 결과는 같았을 텐데, 거기서는 이 되돌아감이 문서를 읽은 모델의 판단이었고 여기서는 그려둔 선이다.

하루 한 개 제한도 마찬가지다. 지금은 실행 스크립트가 시작할 때 기록을 읽어서 판단한다. 그래프에서는 그냥 첫 상자의 갈림길이다.

화살표는 처음부터 다 있었다. 스크립트에, 예약 시각에, 그리고 문서 안의 문장에 흩어져 있었을 뿐이다. 그래프는 그걸 한 장에 모아놓는다.

내가 그린 게 아니라 코드에서 뽑은 그림이다. 점선은 조건에 따라 갈라지는 길이고, 노란 상자 둘이 사람이 서는 자리다.

안 그린 것은 일어나지 않는다

처음 돌렸을 때 파이프라인이 수정 단계에서 멈췄는데, 에러 메시지 하나 없이 그냥 끝나 있었다.

화살표를 하나 빠뜨렸던 거다. 수정에서 검증으로 가는 선을 안 그렸는데, 나가는 화살표가 없는 상자는 오류가 아니라 그냥 끝이다. 그래프는 시키지 않은 걸 하지 않는다.

예약 실행으로 돌릴 때는 이런 일이 안 생긴다. 문서에 "고쳤으면 검증해라"라고 적혀 있고, 모델이 알아서 이어가고, 사실 안 적어놔도 대개는 그렇게 한다.

정해야 하는 것도 늘었다. 후보 점수표는 10점 만점인데 몇 점부터 통과인지가 문서에 없다. 검증이 실패하면 몇 번까지 다시 고쳐볼지도 없다. 예약 실행에서는 에이전트가 그때그때 정했다. 그래프에서는 비워둘 수가 없어서 7점과 2회로 내가 정했다.

흐름이 눈에 보이는 대신 안 정한 걸 계속 정해야 한다. 그래프의 값은 그 둘을 같이 치르는 것이었다.

그래프가 판단을 없애주지는 않는다

CLAUDE.md에는 "이런 이슈는 건드리지 마라"는 조건이 아홉 개 있다. 옮겨보니 그림이 된 건 둘뿐이었다. 저장소가 AI 기여를 금지했는가, 같은 저장소에 내 PR이 이미 열려 있는가. 둘 다 맞다 아니다로 갈리니 갈림길 하나면 된다.

나머지 일곱은 안 떨어진다. "가끔 실패한다는 모호한 리포트인가", "넓은 설계 변경이 필요한가", "내가 자신 있게 설명할 수 있는 이슈인가". 이건 상자 안으로 들어가고, 그 안에서는 여전히 모델이 판단한다.

그래프는 판단이 어디서 일어나는지를 보여주지, 판단을 대신하지 않는다. 유행하는 소개 글들을 읽으면서 이 부분이 잘 안 보였다.

사람이 멈추는 자리는 두 개였다

다 그리고 나서 보니 사람이 끼어드는 상자가 정확히 둘이었다. 메인테이너에게 답글을 보낼 때, 그리고 PR을 접을지 정할 때.

코드를 추가로 올리는 건 자동이다. 예전에는 여기도 내가 봤는데, 모델이 좋아지면서 문제가 생기는 경우가 드물어져서 승인을 뗐다.

여기서 걸리는 게 하나 있다. 나는 규칙 얘기를 쓰면서 "모델이 좋아지면 규칙이 필요 없어지는 것 아니냐"는 반론에 정반대라고 답했다. 그래놓고 정작 모델이 좋아지자 승인을 하나 뗐다.

그런데 전부 뗀 게 아니라 코드 올리는 것만 뗐다. 왜 답글은 남겼나 생각해보니, 기준이 모델 지능이 아니었다. 그걸 받는 쪽이 사람이냐 아니냐였다.

코드를 받는 쪽은 자동 검사 도구다. 잘못 올라가면 다시 올리면 된다. 답글을 받는 쪽은 사람이다. 나는 아직 사람과 AI 사이의 소통이 완전하게 되지는 않는다고 생각하고, 그래서 그 자리에 들어간다.

이건 겪어서 아는 거다. 차단당했을 때 AI로 쓴 해명이 "그 해명도 AI가 쓴 것 같은데요"로 돌아왔고, 레딧에서는 대시 하나 때문에 글 전체가 슬롭 취급을 받았다. 두 번 다 코드가 아니라 사람에게 말을 거는 자리에서 터졌다.

셋은 경쟁하지 않는다

옮겨보고 나니 셋이 서로 다른 질문에 답하고 있었다.

하네스는 무엇을 하면 안 되는지에 답한다. 루프는 언제 도는지에 답한다. 그래프는 어디서 갈라지고 어디서 멈추는지에 답한다. 그래서 어느 하나가 나머지를 대체하지 않는다. 지금도 매일 실제로 도는 건 예약 실행 쪽이고, 그래프는 흐름을 확인하려고 돌려본 것뿐이다.

셋을 다 대보고 제일 좋았던 건 새 도구가 생긴 게 아니었다. 여기저기 흩어놓은 것들을 한 장에 놓고 볼 수 있게 된 거였다. 놓고 보니 빠진 화살표가 보였고, 안 정해둔 숫자가 보였고, 사람이 서 있어야 할 자리가 두 개라는 것도 보였다.

레딧에 글을 쓰며 배운 것들 - 네 번 올렸고, 네 번 다 다른 데서 틀렸다

sjh9714 — Wed, 5 Aug 2026 21:45:11 +0900

레딧에 글을 하나 올렸다가 23분 만에 내 손으로 지웠다.

점수는 0점, 비율은 0.25였다. 본 사람 넷 중 셋이 내려찍었다는 뜻이다. 댓글은 딱 하나 달렸는데 그게 7점을 받아서, 내가 쓴 글보다 거기 달린 댓글이 높았다.

프롬프트 쓸 줄 모른다는 말을 참 길게도 했네.

반박할 말을 한참 찾았는데, 맞는 말이라 하나도 안 떠오르더라.

왜 레딧이었나

몇 달 전에 3편 끝에 이렇게 써뒀다. 복학 전에 데모 말고 실제 서비스를 만들어보고 싶고, GitHub 스타도 받아보고 싶다고. 되면 그것대로고 안 되면 회고 쓸 거리가 생기는 거라고.

만들기는 만들었는데 알릴 데가 없었다. 아무도 안 보는 저장소는 없는 거나 마찬가지라 사람이 모여 있는 곳을 찾다가 레딧으로 갔다. 내가 만든 게 이미지 생성 쪽이라 그 주제만 다루는 서브레딧이 있었고, 거기엔 하루에도 새 글이 몇 개씩 올라왔다.

11일 동안 네 번 올렸다. 별은 12개 받았고 목표는 300개였으니 결과는 말할 게 없는데, 네 번 다 다른 데서 틀렸다는 건 남았다.

처음엔 점수가 잘 나왔다

첫 글은 프롬프트를 정리한 카탈로그였다. 어떤 문구가 먹히고 어떤 게 안 먹혔는지, 실패한 것까지 전부 적어서 올렸다.

올려놓고는 잠이 안 와서 점수를 분 단위로 적고 있었다. 18분에 7점, 88분에 20점, 174분에 31점. 최종적으로는 54점에 비율 0.89, 댓글 13개, 조회수 11,000까지 갔으니 처음 올린 것 치고 잘 됐다고 생각했다.

그런데 정작 저장소에는 거의 아무도 안 왔다.

이상해서 같은 서브레딧에서 GitHub 저장소를 걸고 100점을 넘긴 글 14개를 찾아 하나씩 열어봤다. 전부 설치해서 돌리는 코드더라. 노드, 파이프라인, 학습 도구 같은 것들. 내가 올린 건 읽는 물건이었다. 스크린샷 찍고 문구 복사하면 끝나니까 굳이 저장해둘 이유가 없다.

점수는 "재미있게 봤다"는 뜻이고 저장은 "다시 쓸 거다"라는 뜻인데, 나는 그 둘을 같은 걸로 보고 있었다.

글을 고쳤는데 물건은 그대로였다

그래서 두 번째는 분량을 줄였다. 길어서 안 읽힌 거라고 생각해서 레시피를 다섯 개로 추렸는데, 16점에 댓글 하나로 끝났다.

지금 보면 좀 웃긴 게, 답은 1차에서 이미 나와 있었다. 사람들이 저장하는 건 돌아가는 물건이었고 나는 계속 글만 고치고 있었다. 다섯 개로 줄이든 오백 개로 늘리든 스크린샷 찍으면 끝나는 건 똑같았다.

안 본 걸 봤다고 썼다

세 번째가 맨 앞에 적은 그 글이다.

앞서 인기 글들을 훑다가 "이미지를 여러 장 붙인 갤러리 형식이 잘 된다"는 걸 봤고, 그래서 실패한 이미지 20장을 모아서 올렸다. 지금 보면 두 칸을 건너뛰었다. 내가 본 건 형식에 대한 이야기였는데 나는 그걸 내용에 대한 이야기로 바꿔서 "실패 이미지를 스무 장 모아도 이긴다"고 읽어버렸는데, 그런 말은 어디에도 없었다.

23분이면 방향이 바뀔 가능성은 없으니 지웠다. 삭제 버튼을 누를 때 제일 먼저 든 감정이 억울함이 아니라 안도감이었고, 그게 더 창피했다.

읽는 사람들은 글쓴이가 근거를 갖고 쓰는지 아닌지를 생각보다 빨리 알아보고, 세게 쓸수록 더 빨리 알아본다.

네 번째는 올리기 전에 검색부터 했다

네 번째를 올리기 직전에 그 서브레딧을 한 번 검색해봤다. 15일 전에 같은 모델로 거의 같은 걸 정리한 글이 2,100점을 받고 이미 올라와 있더라.

며칠 잡고 만든 걸 그 자리에서 버렸다. 대신 그 글에 달린 댓글을 전부 읽었다. 사람들이 물어봤는데 아무도 답을 안 한 질문이 하나 있길래, 그걸로 다시 지었다.

139점에 비율 0.87, 댓글 27개로 1차의 두 배가 넘는 점수였다.

검색에 쓴 30분이 그 앞의 며칠보다 값이 나갔다. 이미 있는 걸 확인하는 건 재미없는 일이고 열심히 만든 걸 버리는 건 더 재미없는데, 그 둘을 안 하면 그냥 늦게 온 사람이 된다.

그리고 댓글창에서 제일 크게 배웠다

잘 됐다고 생각한 건 딱 한 시간이었다.

시작은 대시 하나였다. 올리고 75분쯤 지나서 댓글에 답을 달았는데 거기에 em dash를 썼다. — 이거다. 27분 뒤에 "저 대시 봐라"는 댓글이 달리고 밈이 붙었고, 3분 뒤에는 이런 게 올라왔다.

이 사람 글은 전부 쓸모없는 LLM 슬롭이다.

내 답글은 −1점이 됐고 지적하는 댓글들은 +12점, +5점을 받았으니 스레드에서 나만 마이너스였다. 그날 그 화면을 계속 새로고침하면서, 뭐라도 해명하고 싶은 마음이랑 그러면 더 파일 거라는 걸 아는 마음이 계속 부딪혔다.

내용 쪽은 더 아팠다. 내 제목에는 "이미지 전체가 바뀐다"고 적혀 있었는데 정작 두 번째 예시는 인물만 바뀌고 배경은 사진 그대로였다. 한 사람이 그걸 7분 만에 잡아냈다. 그리고 레딧은 제목을 수정할 수 없다. 본문은 고쳤지만 제목은 그대로 남아서, 새로 들어오는 사람마다 같은 자리에서 걸렸다.

그 사이 나는 뭘 해야 할지 몰랐다. 본문을 고치자니 제목이 남고, 가만두자니 사람은 계속 들어오고, 해명하자니 그게 또 연료가 된다. 세 번째 글을 지운 게 며칠 전이었으니 이것도 지울까 하는 생각을 몇 번 했다.

네 시간쯤 뒤에 긴 댓글이 하나 달렸다. 내 예시들이 왜 전부 형편없는지 조목조목 적혀 있었고, 네 개 다 맞는 말이었다. 요지는 하나였다. 그림을 그려달라고 하면서 프롬프트에 사진 찍는 말을 네 개나 섞어놨다는 것. 그중 하나는 아예 facing the camera였다. 카메라라는 단어를 직접 써놓고 그림체가 안 나온다고 하고 있었던 거다.

읽고 나서 든 감정은 억울함이 아니라 고마움이었다. 그때까지 달린 댓글은 전부 내가 틀렸다는 얘기였는데, 그래서 뭘 어떻게 고쳐야 하는지는 아무도 말해주지 않았다. 이 사람이 처음으로 그걸 알려줬다. 지울 생각은 그 댓글을 읽고 나서 접었다.

고맙다고 답글을 달았다. 그리고 그 사람이 고쳐 적어준 프롬프트를 바로 돌려봤다.

그중 둘은 내가 본문에 "어떤 문구로도 안 된다"고 못박아둔 화풍이었다. 조건을 똑같이 맞추고 그 문장을 그대로 넣었더니 둘 다 한 번에 됐다. 내가 불가능이라고 부른 건 그냥 내가 못 한 거였다.

비교 이미지를 만들어서 내가 틀렸다고 답글을 올렸다. 그 답글이 +23점을 받았고 다이아몬드도 하나 받았다. 버티는 것보다 인정하는 게 훨씬 싸게 먹혔다. 솔직히 말하면 인정할 때도 계산이 좀 있었는데, 그렇게라도 하는 게 안 하는 것보다는 나았다고 생각한다.

밖에서는 안 배워진다

이 11일 동안 AI는 많은 걸 했다. 이미지 수백 장을 만들었고, 카탈로그를 짰고, 글 초안을 뽑았고, 검사 스크립트를 돌렸다.

못 한 게 정확히 하나 있었다. 이 사람들이 뭘 원하는지.

읽는 것보다 돌아가는 걸 저장한다는 것, 대시 하나에 반응한다는 것, 제목에서 세게 나가면 그게 그대로 공격면이 된다는 것, 잘못을 인정하면 오히려 점수가 올라간다는 것. 전부 그 커뮤니티의 문화인데, 이건 밖에서 자료를 아무리 모아도 안 나온다. 안에 들어가서 한 번 맞아봐야 나온다.

정답을 준 것도 모델이 아니라 댓글 단 사람들이었다. 한 명도 아니었다. 예시가 틀렸다고 처음 잡아준 사람, 프롬프트를 고쳐 써준 사람, 그리고 내 대시를 비웃은 사람까지 각자 하나씩 알려줬다.

3편에 안 되면 회고 쓸 거리가 생기는 거라고 써뒀는데, 별 대신 그게 남았다.

내가 블로그 글을 쓰는 방법 - 써줘 대신 인터뷰해줘

sjh9714 — Sat, 25 Jul 2026 02:36:22 +0900

이 블로그에 올린 글은 전부 AI로 썼다. 숨긴 것도 아니고, 그렇다고 AI가 알아서 다 해준 것도 아니다.

처음엔 제일 당연한 방법으로 시작했다. AI한테 나를 인터뷰시키고, 그걸로 회고를 써달라고 했다.

안 읽히는 글이 나왔다

문법도 멀쩡했고 문장도 틀린 데가 없었다. 그런데 읽고 나면 무슨 말을 하는 건지 하나도 모르겠는 글이었다. 분명 내 얘기인데 내 얘기 같지 않고, 눈이 글자 위를 미끄러지기만 했다.

인터뷰까지 시켰는데도 그랬다. 내 경험으로 만든 글인데 남이 쓴 것 같아서 기분이 좀 이상했고, 그걸 그대로 올릴 수는 없었다.

왜 그런 글이 나왔을까. "회고 써줘"라고 하면 AI는 세상의 평균적인 회고를 만든다. 수십만 개의 회고를 평균 낸 것 같은 글이다.

거기엔 정해진 재료가 들어간다. "돌이켜보면", "많은 것을 배웠다", "한층 성장할 수 있었다" 같은 상투어. 모든 문단이 비슷한 길이에 비슷한 톤. 구체적인 장면 없이 추상적인 교훈만 둥둥 뜬다. 감정은 서술되는데 그 감정이 나온 순간이 없다.

이게 AI 티의 정체다. 틀린 문장이라서가 아니라, 아무나의 이야기라서 안 읽히는 거다.

내 말을 뼈대로 세웠다

그래서 "써줘"라는 말을 버렸다.

첫 버전이 실패한 건 인터뷰가 없어서가 아니었다. 인터뷰를 해놓고 정작 쓸 때는 내 말을 AI의 언어로 갈아버렸기 때문이다. 내 입에서 나온 거친 문장이 매끈한 문어체로 바뀌어 있었고, 그러고 나니 누구 얘기인지 알 수 없게 됐다.

그래서 반대로 시켜서, 인터뷰에서 내 입으로 나온 말을 그대로 문장의 뼈대로 쓰고 AI는 그 사이만 엮게 했다.

지금 이 블로그에 그 문장들이 그대로 남아 있다. "에라 모르겠다, 최선이나 다하자." "그때 우리 프로젝트는 형편없었다." "남 눈치 봐가며 행동해봤자 나한테 아무 도움이 안 된다." 다듬으면 더 예뻐지겠지만 그러면 내 말이 아니게 된다.

거기에 클리셰는 문장 단위로 걷어내게 했다. "돌이켜보면"이 보이면 지웠고, "성장할 수 있었다"로 끝나는 결말은 다시 썼다. 모든 문단이 같은 길이로 가지런해지면 일부러 들쭉날쭉하게 흐트러뜨렸다.

부풀린 걸 도로 끌어내렸다

이게 제일 중요했는데, AI는 사람을 좋게 포장하는 재주가 있어서, 나온 문장을 하나하나 따져야 했다.

초안에는 내가 무대에서 발표한 것처럼 적혀 있었다. 발표는 팀원이 했고 나는 뒤에 있었다. 앱의 개인화 계산이 실제로 돌아가는 것처럼 쓰여 있기도 했는데, 그건 목 데이터였다. 오픈소스 머지 개수는 58개인데 공개 검색으로는 57로 잡히길래 그 사실까지 같이 적었다.

이미지도 같은 기준으로 갈았다. 그럴듯한 로고 그래픽을 만드는 대신 앱을 직접 돌려서 화면을 찍었고, PR은 실제로 머지된 화면을 넣었다.

모델도 나눠서, 산문은 창작에 강한 모델로 쓰고 검수는 따지기 잘하는 모델로 했다. 하나가 쓰면 다른 하나가 물어뜯는 식으로.

"그럼 AI가 다 쓴 거 아니냐"

맞다, 절반은 그렇다. 문장을 실제로 뽑아낸 건 AI니까.

하지만 뭘 쓸지, 어떤 게 진짜인지, 뭘 걷어낼지, 어떤 목소리로 갈지는 내가 정했다. 경험은 내 것이고, "이건 아니야"라고 자르는 판단도 내 것이었다. AI는 내가 겪은 걸 잘 읽히게 옮겨줬을 뿐 없는 얘기를 지어내지 않았고, 지어내려 하면 내가 잡았다.

나는 오픈소스에 PR을 올릴 때도, 에이전트에게 규칙을 세울 때도 똑같이 했다. AI가 초안을 만들고, 사람이 검증하고 판단하고 책임진다. 글쓰기라고 다를 게 없었다. 내가 안 겪은 일을 썼다면 그건 거짓말이겠지만, 나는 겪은 것만 썼다.

짓게 하지 말고 꺼내게 해라

AI로 글을 쓰려는 사람에게 딱 하나만 남긴다면 이거다. AI한테 네 이야기를 짓게 하지 마라. 네 이야기를 꺼내게 해라. 앞의 것은 아무나의 글이 되고, 뒤의 것은 네 글이 된다. 그 차이가 읽히는 글과 안 읽히는 글을 가른다.

학교를 쓸 줄 몰랐다 - 복학을 한 달 앞두고

sjh9714 — Sat, 25 Jul 2026 01:58:01 +0900

솔직히 말하면, 지금의 나를 만든 건 학교 수업이 아니었다. 휴학하고 오픈소스에 PR을 올리고, AI 에이전트를 붙잡고, 하나 청년 금융인재 프로젝트에서 낯선 사람들과 부딪힌 1년이 나를 여기까지 데려왔지 학점하고는 별 상관이 없었다.

이쯤 되면 "그래서 학교 다닐 필요 없다"는 얘기를 하려는 것 같지만 정반대다. 한 달 뒤에 복학하는데, 그 전에 인정하고 갈 게 하나 있어서 적는다.

2년 동안 내가 학교에서 한 것

수업 듣고, 동아리 하나 하고, 집에 갔다. 2년 동안 내가 학교에서 한 건 그게 전부였다.

동아리는 1년을 활동했는데, 끝나고 보니 같은 조 사람들 말고는 친한 사람이 하나도 없었다. 같은 기수에 사람이 그렇게 많았는데도 그랬다. 내가 적극적으로 말을 붙이지 않았으니 당연한 결과였고, 지금 그게 제일 후회된다. 그 사람들과 친해졌다면 그 1년은 아마 완전히 다른 1년이었을 거다.

더 정확히 말하면 후회되는 건 관계가 아니라 그때의 나다. 나는 지금 이대로가 편하다는 이유로 아무것도 하지 않고 있었다. 편안함에 취해 있었다는 말이 맞다.

3학년 1학기엔 그마저도 놓아버렸다. 텅 빈 학교생활이라고 예전에 쓴 적이 있는데, 그 학기의 나는 강의실에 아는 사람 하나 없이 앉아 있다가 수업이 끝나면 집에 왔다. 꿈도 의욕도 없었고 수업은 지루해서 듣기 싫었다.

그런 상태의 나에게 학교가 쓸모없었던 건 맞다. 그런데 그게 학교 탓이었나 하면 아니다. 나는 학교라는 시스템을 눈앞에 두고도 쓸 줄을 몰랐다. 의욕이 없고 이 공간을 어떻게 써먹는지 모르는 사람에게는 세상 어떤 좋은 학교도 쓸모가 없다.

받는 법은 학교 밖에서 배웠다

그 방법을 나는 휴학하고 나서, 그것도 개발이 아니라 사람 쪽에서 배웠다.

하나 프로젝트와 해커톤이 그랬다. 처음 만난 사람들 사이에서 먼저 인사했고, 회의에서 다듬어지지 않은 의견을 냈고, 마감 앞에서 밤을 새웠고, 둘 다 빈손으로 끝났다.

그런데 그 넉 달에 내가 얻은 건 결과물이 아니었다. 남들 앞에서 틀려도 별일 안 생긴다는 것, 먼저 말을 걸면 대체로 받아준다는 것, 내가 손을 들어야 뭐라도 굴러간다는 것.

이건 강의실에서는 안 배워지는 종류였고, 그렇다고 강의실에서 못 쓸 것도 아니었다.

그래서 학교가 다시 보였다

대학은 사람으로 이루어진 공간이다. 또래가, 선배가, 교수가, 나와 전혀 다른 길을 걷는 사람들이 한자리에 모여 있다.

2년 동안 나는 그 사람들 옆을 그냥 지나쳤다. 공간이 없었던 게 아니라 쓸 줄 몰랐던 거다.

지금은 그게 아깝다. 이런 밀도로 사람이 모여 있는 곳은 인생에 한 번뿐인데, 나는 그걸 배경화면처럼 지나쳤다. AI가 나를 개발자로 만들어줬어도 이 부분은 못 만들어준다.

한 달 뒤에 할 것

예전엔 학교가 나에게 뭘 해주기를 기다렸는데, 이번엔 내가 먼저 가서 받아올 생각이다.

성적. 예전엔 지루해서 안 들었다. 이번엔 아등바등할 거다. 잘 받고 싶어서가 아니라 내가 책임지는 사람이 되기로 해서다.
학부연구생. 주변에서 해보라고 한다. 솔직히 아직 고민 중인데, 예전 같으면 고민조차 안 했을 일을 저울에 올려두고 있다는 것 자체가 달라진 점이다.
동아리. 최소 하나는 하고, 에브리타임 뒤지다가 끌리는 데가 있으면 들어간다.
교수님 찾아가기. 수업을 듣다가 이루고 싶은 목표나 궁금한 게 생기면 찾아간다. 예전의 나는 상상도 못 했던 일이다.

가장 어려운 건 마지막이다. 나는 사람 만나는 게 무서웠고 지금도 무섭다. 넉 달 동안 겪어보고도 그렇다. 다만 무서운 것과 못 하는 것이 다르다는 건 이제 안다.

늦게 알았다

혹시 지금 학교가 쓸모없다고 느끼는 사람이 있다면, 한 번만 의심해봐도 좋겠다. 정말 학교가 쓸모없는 건지, 아니면 내가 이 한 번뿐인 기회를 그냥 흘려보내고 있는 건 아닌지.

나는 2년을 흘려보내고, 그 방법을 배우러 학교 밖으로 한 바퀴 돌고 나서야 알았다. 당신은 나보다 빨랐으면 좋겠다.

내 규칙은 전부 흉터다

sjh9714 — Sat, 25 Jul 2026 00:09:01 +0900

나는 AI 에이전트한테 오픈소스 기여를 시킬 때 지키게 하는 규칙 목록을 갖고 있다. 저장소 정책부터 확인할 것, 재현되지 않으면 손대지 말 것, 프로젝트가 어디로 가는지 볼 것, 하루에 하나만 올릴 것.

이렇게 적어두면 그럴듯한 방법론처럼 보인다. 실제로는 전부 얻어맞고 나서 붙인 것들이다. 규칙이 먼저 있고 사고를 막은 게 아니라, 사고가 먼저 있었고 그 자리에 규칙이 하나씩 생겼다.

아래 넷은 그렇게 생긴 규칙들이고, 순서는 내가 데인 순서다.

차단당했다

vitest라는 프로젝트에 PR을 하나 올렸다. 그 저장소가 "AI로 만든 PR은 받지 않는다"고 명시해둔 걸 나는 못 봤다.

뒤늦게 알고 해명을 달았다. "저 진짜 사람이에요. 최종 diff도 직접 검토했고, 기여 가이드라인도 지켰고, AI를 썼다는 것도 본문에 밝혔습니다." 길게 썼다. 돌아온 답은 짧았다. "그 해명도 AI가 쓴 것 같은데요. 사람이냐고 묻는 질문에 AI로 답하지 마세요."

결국 그 조직 전체에서 차단당했다. 내 해명조차 AI처럼 읽혔다는 게 오래 남았다.

그날 첫 번째 규칙이 생겼다. 기여하기 전에 그 저장소가 AI를 어떻게 대하는지부터 확인한다. 금지한 곳은 아예 건드리지 않는다.

그냥 틀렸다

serde라는 프로젝트에 버그라고 생각한 걸 고쳐서 올렸다. 메인테이너가 답했다. "원래 코드가 맞습니다. 그래도 고마워요."

나는 버그가 아닌 걸 버그라고 우겼던 거다. 재현을 제대로 안 해봤으니까.

그래서 두 번째 규칙이 붙었다. 버그를 로컬에서 진짜로 재현하고, 근본 원인을 이해하기 전엔 손대지 않는다.

잘했는데도 닫혔다

bootstrap에서는 다 제대로 했다. 재현하고, 테스트 붙이고, 최소한으로 고쳤다. 그런데 창시자가 닫으면서 이렇게 남겼다. "다음 버전 재작성에서 이 부분을 통째로 들어냈습니다. 그래서 닫아요."

내가 고친 코드 자체가 곧 사라질 예정이었던 거다. 이건 내 잘못이 아니라 세상이 내 발밑에서 움직인 쪽에 가깝다. 그렇다고 들인 시간이 돌아오지는 않는다.

여기서 세 번째 규칙이 나왔다. 손대기 전에 이 프로젝트가 지금 어디로 가고 있는지부터 본다.

누가 먼저, 더 잘 고쳤다

tailwind에 올린 PR에는 이런 답이 왔다. "고맙지만 저는 다른 방식으로 이미 고쳤어요. 그리고 당신 수정은 이 경우는 풀어도 저 경우는 못 풉니다."

나는 증상을 봤고, 그 사람은 뿌리를 봤다. 같은 화면을 보고도 보는 깊이가 달랐다.

마지막 규칙은 여기서 왔다. 이미 같은 걸 고치는 사람이 있는지 먼저 확인하고, 증상이 아니라 원인을 고친다.

왜 프롬프트가 아니라 규칙인가

이 네 가지를 그냥 프롬프트에 적어 넣을 수도 있었는데, 나는 그러지 않았고 그 차이가 생각보다 컸다.

프롬프트는 그때 한 번만 유효한 계약 같은 것이다. 한 번의 대화에만 효력이 있고 다음 작업이 오면 처음부터 다시 써야 한다. 오늘 rubocop 버그를 기막히게 고친 프롬프트가 내일 다른 프로젝트에는 아무것도 남겨주지 않는다. 프롬프트는 아무리 잘 써도 쌓이지 않는다.

규칙은 문서에 박아두면 그때부터 혼자 굴러간다. 그다음 모든 작업이 자동으로 그 검사를 통과한다. 흉터 하나가 미래의 실수 백 개를 막는 셈이다. 이렇게 모델 주위에 세워둔 것들을 나는 하네스라고 부른다. 모델한테 뭐라고 말하느냐보다, 모델 주위에 뭘 세워뒀느냐가 결과를 갈랐다.

일부는 아예 도구로 떼어냈다.

mergewarden은 AI가 만든 PR이 스코프와 정책을 벗어났는지 검사하는, 내가 만든 게이트다. 머릿속에 있던 규칙을 코드로 내린 것이다.

그래서 뭐가 달라지나

지난 글에서 나는 좀 위험한 말을 했다. "나는 PR에 올리는 코드를 줄 단위로 다 이해하지 않는다"고. 그 말만 떼어놓으면 무책임하게 들린다.

그걸 무책임이 아니라 방법으로 만들어주는 게 이 규칙들이다. 내가 모든 문법을 외우지 않아도, 재현이 되고 · 테스트가 실패했다가 · 고친 뒤 통과하고 · 이 저장소가 AI를 받아주는 곳이라면, 그 PR은 구조적으로 검증된다. 통과 여부를 정하는 게 내 감이 아니라 규칙이라는 뜻이다.

규칙이 촘촘할수록 내가 손으로 붙잡고 있지 않아도 되는 범위가 넓어지고, 그만큼 위임이 안전해진다.

"모델이 좋아지면 필요 없어지는 거 아니냐"

이 얘기를 하면 꼭 나오는 반론이다. 모델이 더 똑똑해지면 이런 규칙들 다 필요 없어지는 거 아니냐고.

나는 정반대라고 생각한다. 모델이 좋아질수록 우리는 더 큰 일을 맡긴다. 맡기는 일이 클수록 경계와 검증은 덜 중요해지는 게 아니라 더 중요해진다.

규칙은 모델이 멍청해서 필요한 게 아니다. 신뢰를 감이 아니라 구조로 만들려고 필요한 거다. 어떤 특정 모델은 지나가도, 믿을 수 없는 일꾼에게 경계와 검증을 설계하는 능력은 지나가지 않는다.

흉터는 계속 는다

프롬프트만 다듬던 시절의 나는 결과가 안 좋으면 문장을 바꿨다. 지금은 문장을 바꾸는 대신 규칙을 하나 더 박는다.

그리고 이 목록은 아직 안 끝났다. 다음에 또 어딘가에서 데일 거고, 그러면 다섯 번째 규칙이 붙을 거다. 처음부터 잘 설계하는 방법이 있으면 좋겠는데, 적어도 나한테는 없었다.

AI를 이용해 오픈소스에 기여하는 방법

sjh9714 — Fri, 24 Jul 2026 23:07:24 +0900

두 달 동안 오픈소스 프로젝트에 PR 58개를 머지시켰다. black(Python), rubocop(Ruby), symfony(PHP), hugo(Go), nushell(Rust), html-react-parser(TypeScript)… 언어가 제각각이다.

나는 이 언어들을 다 잘 다루지 못한다.

AI를 쓰면 이게 된다. 그런데 이 문장만 보면 딱 요즘 메인테이너들이 제일 싫어하는 부류이기도 하다. 남의 프로젝트에 AI로 뽑은 PR을 쏟아붓는 사람. 실제로 나는 그러다 한 번 차단당했다.

거기서 알게 된 게 이 글의 전부다. 코드를 못 짜는 건 이제 장벽이 아니다. 남은 병목은 그 코드를 읽어줘야 하는 사람의 시간이다.

코드 장벽이 사라진 자리

시작은 첫 PR 하나였다. 5월 16일, html-react-parser라는 라이브러리의 버그를 고쳐 올렸고 메인테이너와 몇 번 대화하며 다듬은 끝에 머지됐다. 그 얘기는 휴학 회고에 적었다.

예전이라면 Ruby 프로젝트에 기여하려면 먼저 Ruby를 어느 정도 해야 했다. 지금은 순서가 바뀌었다. rubocop의 버그를 재현하고, 회귀 테스트를 짜고, 최소한으로 고치는 걸 에이전트와 함께 하면서 그 언어의 그 부분을 배운다.

진입점이 "이 언어를 마스터한 다음"에서 "이 버그 하나를 고치면서"로 내려온 것이다. 58개가 여러 생태계에 걸쳐 있는 건 그래서 가능했다. 대단한 게 아니라 진입 장벽이 무너진 시대의 당연한 결과에 가깝다.

차단당하고 나서야 선이 보였다

그런데 장벽이 낮아졌다는 건 나 말고 다른 수천 명한테도 낮아졌다는 뜻이다. 메인테이너 쪽에서 보면 갑자기 AI로 만든 PR이 쏟아지기 시작한 거다.

나도 그 쏟아붓는 쪽이었다. vitest라는 프로젝트에 PR을 올렸는데, 그 저장소가 "AI로 PR 보내지 말라"고 명시해둔 걸 못 보고 저지른 일이었다. 결과는 그 GitHub 조직 차원의 차단이었다. 이 사건이 나한테 어떤 규칙들을 남겼는지는 따로 자세히 썼다.

그때 알았다. 내가 아낀 시간만큼 누군가는 시간을 쓴다. 에이전트를 붙여 빠르게 뽑아낸 diff라도, 그걸 읽고 판단하는 쪽은 사람이고 그 시간은 줄어들지 않는다. 기여와 민폐를 가르는 건 코드 품질이 아니라 내가 남의 시간을 얼마나 아껴줬느냐였다.

그래서 선을 두 개 그었다.

그 저장소가 AI 기여를 어떻게 대하는지부터 확인한다. 금지한 곳은 아예 건드리지 않고 우회할 방법도 찾지 않는다. 다른 계정으로도, 다른 표현으로도. 고지나 Co-Authored-By를 요구하면 그대로 따르고, 규정이 없어도 필요하면 AI를 썼다고 짧고 정직하게 밝힌다.
새로 여는 PR은 전부 합쳐 하루 한 개까지. 같은 저장소에 내 PR이 이미 열려 있으면 거기엔 새 걸 올리지 않는다.

PR 하나가 만들어지는 순서

나머지는 전부 리뷰하는 사람의 시간을 줄이려고 만든 장치다. 문서로 박아두고 매번 그대로 돌린다.

후보 고르기. 최근 활동, 테스트 명령어 유무, good first issue 신호, 재현 가능성을 점수로 매겨 통과한 것만 고른다. 이미 같은 걸 고치는 PR이 열려 있으면 버린다.
재현. 로컬에서 실제로 재현한다. 안 되면 손대지 않는다.
실패하는 테스트부터. 고치기 전에, 그 버그 때문에 실패하는 회귀 테스트를 먼저 짠다.
최소 수정. 테스트를 통과시키는 가장 작은 변경만. 관련 없는 포맷팅이나 리팩터는 넣지 않는다.
검증. 테스트·린트·빌드를 돌리고, 못 돌린 게 있으면 못 돌렸다고 적는다.
좁은 PR. "뭐가 고장 나 있었고, 뭘 바꿨고, 어떻게 검증했는지"를 몇 문장으로 적는다.

여섯 단계가 노리는 건 하나다. 리뷰하는 사람이 짧은 시간 안에 "아 이거 맞네" 할 수 있는 크기. 그래서 큰 리팩터나 기능 추가는 안 한다.

최근에는 앞부분(후보 탐색부터 PR 생성까지)을 자동화해서, 아침 9시에 열린 PR을 점검하고 낮 동안 세 번 새 후보를 찾는 실험을 하고 있다. 이 경로로 나간 PR은 아직 한 손에 꼽는다. 그리고 완전 자율은 아니다. 후속 push는 자동으로 나가지만 공개 답글은 내가 확인한 뒤에 나가고, PR을 접을지는 에이전트와 얘기해보고 내가 정한다.

다 이해하지 못한 코드를 올린다는 것

여기서 솔직해야 한다. 나는 PR에 올리는 코드를 줄 단위로 다 이해하지 않는다. 그게 이 방식에서 사람들이 제일 걸고넘어질 부분이다.

대신 올리기 전에 이건 직접 확인한다. 내가 바꾼 함수와 그게 불리는 경로, 실패의 원인, 테스트가 검증하는 범위, 그리고 내가 검증하지 못한 범위가 어디까지인지. 마스터하지 않은 언어라도 이 변경이 왜 맞는지 내 입으로 설명할 수 있을 때만 올린다.

이건 대충 한다는 뜻이 아니다. 오히려 반대다. 사람이 눈으로 훑고 "괜찮아 보인다"로 넘기는 것보다, 재현과 테스트로 강제하는 검증이 더 빡세다. 리뷰어 입장에서도 작은 diff에 동작을 붙잡는 테스트가 붙어 있으면 읽기가 빠르다.

숫자를 정직하게 까면 이렇다. 2026년 7월 24일 기준으로 머지 58개, 닫힘·미병합 40개, 아직 열려서 대기 중인 게 47개다(개인·팀 저장소 제외, 공개 검색으로는 57개로 잡힌다). 두 달 동안 145개쯤 열어서 58개가 안착했다.

선을 다 지켜도 절반 가까이는 닫힌다는 뜻이다. 중복이었거나, upstream이 바뀌었거나, 내가 철회했거나, 구현이 틀렸거나. 그래서 머지 비율을 실력 점수로 보지 않는다. 닫힌 이유를 읽으면 그 프로젝트가 뭘 받아주고 뭘 안 받아주는지가 다음 기여에 쌓인다.

그러니 "AI가 다 해준 거 아니냐"고 물으면 절반은 맞다. 코드 탐색과 초안, 반복 검증의 상당 부분은 에이전트가 한다. 하지만 어떤 버그를 고를지, 그게 진짜 재현되는지, 이 저장소가 AI 기여를 받아주는지, 리뷰에 뭐라고 답할지는 사람이 정하고 책임진다. AI는 진입 장벽을 낮췄지, 판단을 대신해주지 않았다.

시간과 돈

대학생 입장에서 제일 궁금할 부분이라 솔직하게 적는다.

시간. PR 하나에 내가 실제로 쓰는 시간은 단순한 건 10분 안팎이다. 리뷰가 한 번 달리면 코멘트 해석하고 수정 범위 정하는 데 10~30분, 설계를 바꿔야 하거나 CI가 터지면 누적 한두 시간까지 간다. 에이전트가 후보 찾고 테스트 돌리는 데는 수십 분이 걸리지만 그동안 내가 화면을 붙잡고 있을 필요는 없다.

돈. 매일 고성능 모델로 돌리면 비싸다. Claude Max나 ChatGPT의 상위 플랜은 월 $100~200 선이고(세금·지역가 별도), 둘 다 상위로 쓰면 $400까지도 간다. 나는 프로모션이 적용된 구간이 있어서 실제 지출은 정가보다 낮았지만 누구나 같은 값에 쓸 수 있는 건 아니다.

시작하는 사람한테 현실적인 조언은 이거다. 둘 다 구독할 필요 없다. 하나만 월 $20에 쓰고 매일이 아니라 주 1~2회 돌려도 첫 머지는 충분히 가능하다.

시작하려는 사람에게

두 달 전의 나는 오픈소스 기여가 나 같은 사람한텐 먼 얘기라고 생각했다. 지금은 여러 언어의 프로젝트에 내 코드가 들어가 있고, 그 코드는 내가 자는 동안에도 어딘가에서 누군가의 버그를 막고 있다. 그 감각은 수상이나 스펙과는 다른 종류의 것이다.

딱 하나만 남긴다면, 그 저장소가 AI 기여를 어떻게 대하는지부터 확인하고, 남이 5분 안에 이해할 수 있는 작은 버그 하나부터 고쳐라. 나도 거기서 시작했고, 그게 전부였다.

혼자선 아무것도 못 한다고 믿었다 - 나의 휴학 1년

sjh9714 — Fri, 24 Jul 2026 22:19:38 +0900

3학년 1학기, 나는 강의실에 아는 사람이 한 명도 없었다.

같이 다니던 사람들은 다 휴학했거나 졸업한 뒤였다. 수업을 듣고, 아무하고도 말을 안 섞고, 집에 왔다. 그게 한 학기 내내 반복됐다. 강의실에 앉아 있으면 이대로 가는 게 맞나 하는 생각이 매일 들었고, 자괴감이 쌓였다. 개발이든 학교든 뭐 하나 손에 잡히는 게 없었다.

1학기가 끝나자마자 휴학계를 냈고, 그 1년이 지금 이 글이다.

텅 빈 2학년

2024년, 2학년 때 나는 멋쟁이 사자처럼 12기에 백엔드 파트로 들어가 1년을 활동했다. 학교생활에 동아리에, 겉보기엔 열심히 사는 대학생이었다. 그런데 1년을 보내고 남은 감정은 이상하게도 공허함이었다.

아는 게 아무것도 없으니 어디서든 끌려다니기만 했다. 내가 뭘 판단해서 기여하는 게 아니라, 남들이 정한 걸 따라가는 게 전부였다. 활동은 많은데 나한테 남는 건 없는 것 같았고, 학교생활이 통째로 텅 비어 있는 느낌이었다. 실력은 없는데 개발에 시간은 쓰니까 성적은 계속 떨어졌다.

2학년이 끝나갈 무렵부터 생각했다. 차라리 휴학을 빨리 하고 개발 공부를 좀 한 다음에 복학하면, 그때는 더 가치 있는 학교생활을 할 수 있지 않을까.

그 고민을 안고 3학년 1학기를 다녔는데, 동아리에서의 안 좋은 기억 때문인지 뭘 하고 싶은 의욕이 하나도 없었다. 그래서 아무 활동에도 참여하지 않고, 수업만 듣고 집에 갔다. 그 반년이 결국 나를 휴학으로 밀어냈다.

대부분의 휴학생이 그렇듯

휴학하면서 세운 계획은 흔했다. 알고리즘 공부하고, 백엔드 지망이니까 김영한 스프링 강의 열심히 듣고, 운동도 하고. 그리고 처음 얼마간은 진짜 그렇게 살았다.

그리고 대부분의 휴학생이 그렇듯, 그 생활은 잘 안 지켜졌다. 알고리즘도 스프링도 운동도, 처음의 의욕은 점점 나태로 바뀌어 갔다. 지나고 나서 솔직하게 말하면, 2025년은 거의 전부 힘들었다. 남들과 비교하면 나는 할 수 있는 게 아무것도 없었고, 나 자신에게서 단점밖에 발견하지 못하는 해였다.

커서로 만든 포트폴리오

그렇게 공부를 깨작거리던 어느 날, 바이브 코딩이라는 걸 알게 됐다.

사실 예전부터 이름은 알고 있었다. 그런데 옛날에 GPT에서 코덱스를 써봤을 때 결과가 정말 최악이었어서, "그 정도인가" 하고 접어뒀었다. 그러다 다시 보니 사람들이 커서는 공부용으로, 클로드 같은 건 실무용으로 많이 쓴다고 하길래, 나도 커서를 한번 써봤다.

그걸로 백엔드 포트폴리오를 하나 만들어봤는데, 결과가 말도 안 되게 잘 나왔다. 내가 백엔드를 그렇게 잘 아는 것도 아닌데. 그 순간부터 개발이 너무 재밌어졌다.

외출할 때도 노트북을 들고 다니면서 개발했고, 만드는 양이 늘어나니까 토큰이 부족해졌다. 이왕 결제하는 김에 클로드로 넘어갔고, 맥스 5배 플랜으로 개발하다가, 어느 날 카카오가 코덱스 20배 모델을 10분의 1 값에 뿌리길래 그걸로 5개월 치를 사서 개발했다.

돌아보면 여기가 1년의 변곡점이었다. 스프링 강의를 몇 배속으로 넘기며 조급해하던 내가, 처음으로 뭔가를 직접 만들어내는 재미에 빠진 순간이었으니까.

하나 프로젝트, 그리고 해커톤

그렇게 개발에 빠져 있던 중에 하나 청년 금융인재 프로젝트에 참여하게 됐다. 팀 프로젝트를 질색하던 내가 아이디어를 내고, 3개월을 날리고, 마감 며칠 전에 프로젝트를 통째로 갈아엎은 이야기는 따로 적었다.

그 사이에 낀 TECH4GOOD 해커톤에서 밤을 새우며 배운 것도, 두 번 다 상을 못 받고 얻은 것도 마찬가지다.

이 1년만 놓고 보면 그 넉 달이 어디에 끼어 있었는지가 더 중요하다. 그전까지 내 1년은 전부 혼자였다. 방에서 커서를 붙잡고, 혼자 만들고, 혼자 잘 나왔다고 좋아하는 시간이었다.

그 넉 달에 사람이 끼어들었다. 의견이 갈리는 회의가 있었고, 내가 결정을 미루면 팀 전체가 멈췄고, 마감 앞에서 나 하나 도망치면 남의 몇 달이 같이 날아가는 자리에 있었다. 혼자 개발하면서는 절대 안 생겼을 종류의 압력이다.

반년 전 강의실에서 아무하고도 말을 안 섞던 내가, 처음 만난 사람들과 팀을 이뤄 무대 뒤에서 개발을 굴리고 있었다. 그게 나한테는 성적이나 수상보다 큰 사건이었다.

PR은 날리면 끝인 줄 알았다

개발이 손에 붙으면서 오픈소스에 눈이 갔다. 예전에 오픈소스 기여를 하면 포트폴리오에 정말 좋다는 얘기를 들은 적이 있었고, AI 에이전트를 쓰면 나 같은 사람도 오픈소스 기여가 꿈이 아니지 않을까 싶었다.

첫 PR은 html-react-parser라는 라이브러리에 올렸다. DOM 요소의 instanceof 체크가 깨지는 버그를 고치는 거였다.

나는 PR은 코드 올리면 끝나는 건 줄 알았는데, 아니었다. 메인테이너가 "이 로직은 여기로 옮겨라", "Element 노드만 대상으로 좁혀라" 하고 리뷰를 남겼고, 그 요청을 따라 코드를 고치고 회귀 테스트까지 붙였다.

PR은 메인테이너가 원하는 걸 미리 파악하고, 대화하면서 같이 완성해 가는 거라는 걸 그때 처음 알았다.

머지가 됐을 때, 나는 아무것도 모르는 대학생이 아니라 누군가에게 도움이 되는 개발자가 된 것 같았다. 기분이 좋았다.

처음엔 깃허브 생태계가 어떻게 돌아가는지도 몰랐지만, 커서와 클로드와 코덱스로 개발하면서 코드만 치는 게 아니라 그 바깥의 것들(개발자들이 어디서 활동하고 뭘 원하는지)을 훨씬 많이 접하게 됐고, 그게 기여에도 그대로 도움이 됐다.

불편해서 만든 도구

오픈소스에 PR을 올리다 보니, PR을 자동으로 검사하는 봇을 자주 봤다. 검사에 시간이 오래 걸려 한참을 기다렸는데 결국 close되면 허무했다. 그래서 생각했다. 사용자가 원하지 않을 PR을 미리 걸러주는 도구가 있으면 좋지 않을까.

그렇게 만든 게 mergewarden이다. AI가 생성한 PR이 정해진 범위를 벗어나지 않았는지, 건드리면 안 되는 파일을 손대지 않았는지 같은 걸 검사하는 도구다.

커밋이 130개 가까이 쌓였고, 내가 깃허브를 하면서 받은 스타 중 제일 많은 스타를 받았다. 스타 수야 대단한 건 아니지만, 내가 겪은 불편을 내가 도구로 만들어 풀었다는 게 나한테는 컸다.

한 학기만 빨랐어도, 늦었어도

이제 곧 복학한다.

1년 전, 휴학을 막 결정한 나에게 지금 한마디 한다면, 타이밍 정말 잘 잡았다고 말하고 싶다. 한 학기만 빨리 했으면 AI 에이전트로 뭔가 이룬 것 하나 없이 복학했을 거고, 한 학기만 늦게 했으면 학교생활 반년을 더 날린 데다 이미 판이 다 바뀐 뒤였을 테니까. 하필 이 1년이었기 때문에 잡을 수 있던 것들이 있었다.

2025년은 힘들었다. 남들과 비교하며 내 단점만 세던 해였다. 그런데 그 끝에서 나는 개발자로서 자신감이 붙었다.

1년 전엔 혼자서는 아무것도 못 하고, 취업은 어떻게 하고 팀플은 또 어떻게 하나 걱정만 했는데, 지금은 뭐든 할 수 있을 것 같다. 무슨 역경이 와도 지난 1년의 경험으로 넘길 수 있을 것 같고, 제일 무서웠던 사람들과 부대끼는 일도 이제는 두렵지 않다.

애초에 휴학하며 세운 계획은 "실력을 쌓아서 더 가치 있는 학교생활을 하자"였다. 알고리즘도 스프링도 계획대로는 안 됐지만, 그 계획이 노렸던 것(텅 비지 않은 학교생활을 할 수 있는 나)은 결국 손에 넣은 것 같다.

복학한 강의실에는 여전히 아는 사람이 없을지도 모른다. 그래도 이번엔 먼저 말을 걸 수 있을 것 같다.

상은 하나도 못 받았다, 그래도 남는 장사였다

sjh9714 — Thu, 23 Jul 2026 23:01:14 +0900

하나 청년 금융인재 프로젝트에서도, TECH4GOOD 해커톤에서도 상을 못 받았고, 두 번 다 빈손이었다.

그런데 이 글을 쓰는 지금, 억울하거나 허무하지가 않다. 넉 달 동안 나한테 일어난 일을 늘어놓고 보면 오히려 이득 본 쪽에 가깝다.

그 계산을 한번 적어보려고 한다. 나 같은 대학생, 그러니까 팀플이 무섭고 남 눈치 보느라 손을 못 드는 사람이 읽었으면 좋겠다.

넉 달 전의 나

나는 팀 프로젝트를 질색했다. 조용하고 남 눈치를 많이 보는 성격이라, 여럿이 모인 자리에서 말을 매끄럽게 못하면 사람들이 나를 이상하게 볼 것 같았다.

그래서 아이디어가 있어도 입을 다물었고, 결정은 남에게 미뤘고, 결과가 좋았던 적은 한 번도 없었다.

그 상태로 이력서에 쓸 타이틀이나 하나 얻자는 마음 반, 이번엔 좀 달라져보자는 마음 반으로 프로그램에 들어갔다.

바뀐 건 성격이 아니라 행동이었다

넉 달 뒤의 나는 처음 본 사람 일곱 명이 모인 해커톤 팀에서 개발 기획을 먼저 정리하고 팀 개발을 조율하는 사람이 되어 있었다.

성격이 바뀐 건 아니다. 지금도 낯을 가리고 지금도 눈치를 본다.

달라진 건 행동이고, 그 계기는 거창하지 않았다. OT 레크리에이션 자리에서 "에라 모르겠다, 최선이나 다하자" 하고 한 번 놓아본 것, 조별 토론에서 덜 다듬어진 의견을 툭 던져봤는데 사람들이 그냥 잘 들어주더라는 것, 딱 그 정도였다.

거기서 알았다. 내가 두려워한 시선의 대부분은 상대의 것이 아니라 내가 만들어낸 것이었다는 걸.

그리고 사람이 남았다

행동이 바뀌니까 남는 것도 달라졌다.

하나 프로젝트를 하는 동안 다른 팀 사람들과 네트워킹을 했다. 같이 밥을 먹고, 각자 뭘 하고 있는지 서로 정보를 나눴다. 주고받은 게 실제로 도움이 됐다. 넉 달 전의 나라면 그런 자리는 어떻게든 피했을 거다.

해커톤은 이틀뿐이었는데도 인스타와 연락처를 교환했다. 그리고 최종 성과회에서, 같이 뛰었던 팀원이 상을 받았다.

나는 빈손이었다. 그런데 그 자리에서 축하한다고 말하는 게 어렵지 않았고, 아쉽긴 해도 웃으면서 마무리할 수 있었다. 상을 못 받은 자리를 웃으면서 나왔다는 게 나한테는 좀 새로웠다.

돈 쓰는 기준도 바뀌었다

바뀐 게 하나 더 있는데, 이건 좀 다른 종류다. 마감 닷새 전 프론트를 다시 만들 때 나는 30만원짜리 AI 플랜을 결제했다. 학생한테 30만원은 망설일 수밖에 없는 돈이고, 실제로 주변에서는 다들 주저한다.

나는 반대로 계산했다. 내 한 달이 30만원보다 싸면 그게 더 문제 아닌가. 도구가 시간을 벌어주면, 그 시간을 30만원보다 가치 있게 쓰는 건 내 몫이다.

물론 이건 "다들 결제해라"는 말이 아니다. 결제한 만큼 시간을 결과로 바꿔야 한다는 책임까지 같이 사는 거다. 나는 그 며칠 동안 300개 넘는 커밋으로 그 값을 치렀다고 생각한다.

예전 같으면 그 앞에서 며칠을 재다가 결국 안 샀을 거다. 결정을 미루는 게 그때는 편했으니까.

그래서 다음 팀에서는

제일 크게 후회하는 건 하나 프로젝트 초반에 내 결정권을 남한테 넘긴 것인데, 그 얘기는 거기에 적었다. 여기서는 그래서 다음엔 어떻게 하겠다는 것만 남긴다. 나를 위한 메모지만, 비슷한 사람에게도 쓸모 있을 것 같아 적어둔다.

역할을 맡으면 그 역할은 끝까지 내가 책임진다. 애매하게 걸쳐두지 않는다.
의견은 덜 완성됐어도 낸다. 틀리는 걸 두려워하지 않는다.
반박할 땐 비판만 하지 않고 더 나은 대안을 같이 가져간다.
아이디어가 안 떠오르면 침묵하는 대신 사전 조사를 해서 근거를 들고 간다.
주제를 정했으면 단점 찾기를 멈추고 일단 믿고 디벨롭한다. 불신은 팀을 제자리에 세운다.

특히 마지막 줄. 우리 팀이 3개월을 잃은 건 아이디어가 없어서가 아니라, 정한 주제의 단점만 계속 찾고 있었기 때문이다.

좋은 주제를 고르는 것보다 고른 주제를 좋게 만드는 게 훨씬 생산적이라는 걸 시간을 다 쓰고 나서야 알았다.

예전의 나 같은 사람에게

복학까지 한 달 남짓 남았다. 그 전에 데모가 아니라 실제 서비스를 만들어서 배포해보는 게 목표다. GitHub 스타도 받아보고 싶고, 수익도 내보고 싶다. 되면 그것대로, 안 되면 또 회고 쓸 거리가 생기는 거고.

혹시 예전의 나처럼, 낯선 사람들과 팀 하는 게 무서워서 대외활동 지원 버튼 앞에서 망설이는 사람이 있다면.

있는 모습 그대로 보여주고, 잘하는 사람 걸 창피해하지 말고 따라 배워라. 이번 넉 달 동안 확실해진 건, 남 눈치 봐가면서 행동해봤자 나한테 아무 도움이 안 된다는 거다.

발전하고 싶으면 눈치 보지 말고 하고 싶은 대로 해라. 틀려도 된다. 틀리면 거기서 배우는 게 있고, 그게 당신이 한 단계 성장하는 시간이 된다.

상 하나 없이 끝난 넉 달을 두고 이런 말을 하는 게 웃길 수도 있는데, 그래서 더 자신 있게 말할 수 있다. 이건 수상 소감이 아니라 계산서니까.

3개월을 버리고, 5일 만에 다시 만들었다 - 하나 청년 금융인재 회고

sjh9714 — Thu, 23 Jul 2026 23:00:06 +0900

멘토가 우리 발표를 듣는 동안 나는 그 사람 표정만 봤다. 지적도 질문도 별로 없었다. 그냥 관심이 없어 보였는데, 최종 발표를 닷새 앞둔 날이었다.

돌아오는 길에 인정할 수밖에 없었다. 그 시점의 우리 프로젝트는 형편없었다. UI는 엉망이었고, 백엔드도 데이터도 제대로 돌아가지 않았고, 무엇보다 우리가 무슨 문제를 풀겠다는 건지 우리 스스로도 설명하지 못했다.

다음 날 단톡에 "저희 이대로 가면 안 될 것 같습니다"라는 메시지가 올라왔고, 긴급 소집이 걸렸다. 반대하는 사람은 없었다. 다들 이 프로젝트에 자신이 없었으니까.

그렇게 전부 갈아엎기로 했는데, 사실 다른 선택지도 없었다.

이 얘기를 하려면 2월로 돌아가야 한다.

할 게 없어서 시작했다

3학년 1학기를 마치고 백엔드 공부를 한답시고 6개월을 방황했다. 그러다 올해 2월 초에 Cursor로 바이브 코딩이라는 걸 처음 접했다. 스프링 좀 깔짝거릴 줄 알던 나한테는 충격이었다.

개발판이 통째로 바뀌겠구나, 지금 늦으면 앞으로 큰일 나겠구나 싶어서 하루 12~14시간씩 Cursor랑 Claude를 붙잡고 이것저것 만들었다. 그렇게 몇 달을 보내니 지금 개발판이 어떻게 돌아가는지, 사람들이 뭘 추구하는지 조금은 보이기 시작했다.

그 무렵 같은 고민을 하던 친구한테 연락이 왔다. 하나 청년 금융인재 양성 프로젝트를 같이 해보자고 했다. 마침 할 것도 없었다. 세 명이던 팀에 내가 들어가면서 네 명이 됐다.

솔직히 동기는 두 가지였다. 이력서에 적을 타이틀이 필요했다. 그리고 나는 팀 프로젝트라면 질색하는 사람이었는데, 이번엔 그걸 한번 넘어보고 싶었다.

조용하고 남 눈치를 많이 보는 성격이라 팀플 자체가 무서웠고, 동아리든 수업 팀플이든 결과가 좋았던 적도 없었다.

남들이 준비 안 한 걸 준비해 갔다

중간에 합류하는 처지라 첫 회의에 뭘 들고 갈지 고민했다. 팀원들이 준비하지 않은 걸 해 가면 어떨까 싶어서 이 대회의 역대 수상작과 채점 기준을 뒤졌다.

실현가능성 30%, 사업성 30%, 참신성 30%, 자료완결성 10%. 수상작들을 보다 보니 감이 왔다. 거창한 문제보다 작아도 확실하게 풀 수 있는 문제, 거기에 하나은행 사업이랑 자연스럽게 엮이는 그림이면 되겠다 싶었다.

그래서 내가 낸 아이디어가 Student Start Mode였다. 외국인 유학생이 한국에 와서 처음 90일 동안 계좌, ARC, 휴대폰 개통처럼 서로 꼬여 있는 절차를 어떤 순서로 풀어야 하는지 알려주는 AI 금융 온보딩 서비스.

유학생의 금융 문제를 풀면 금융 포용, ESG까지 자연스럽게 걸린다. "버스만 타지 말고 자기주장 있는 사람이 되자"고 다짐하고 들어온 팀이었는데, 그 다짐이 처음으로 결과로 이어진 순간이었다.

당시 안내받기로는 220팀 남짓이 지원해서 20팀을 뽑는 예선이었다. 4월에 결과가 났는데, 기대 안 하고 있다가 붙었다.

기뻤다기보다 당황스러웠다. 이런 데서 좋은 소식을 받아본 적이 없었으니까. 4월 20일 명동 하나금융 사옥에서 열린 본선까지 통과해서, 역시 당시 안내 기준으로 최종 13팀에 들었다.

본선 발표는 팀원이 했고, 나는 자료조사와 시연 영상을 맡았다. 발표 시간에 맞춰서 58초, 65초, 78초, 88초짜리 영상을 몇 번이고 다시 만들고, 효과음 넣고, 화면 전환 타이밍을 조정했다.

무대에서는 한마디도 안 했다. 대신 객석에서 다른 팀 발표를 하나하나 봤다. 세상에 발표 잘하는 사람 진짜 많구나. 같은 주제를 저렇게도 접근하는구나.

에라 모르겠다

1박 2일 OT를 갔다. 모르는 사람 여럿이랑 얘기하는 것도, 레크리에이션도 진짜 싫어한다.

그런데 이번엔 도망칠 데가 없어서, 에라 모르겠다, 이 상황에서 내가 할 수 있는 최선이나 다하자고 마음먹었다. 그랬더니 이상하게 점점 재밌어졌다.

조별 활동을 아예 모르는 사람 여섯이서 했는데, 마주칠 때마다 먼저 인사하려고 했고, 예전 같으면 아이디어가 있어도 입 꾹 다물고 있었을 토론에서 생각날 때마다 툭툭 던져봤다.

사람들이 내 말을 잘 들어줬다. 나는 말을 매끄럽게 못하면 남들이 나를 이상하게 볼까 봐 피해온 건데, 그 두려움의 대부분은 상대가 아니라 내 안에서 만든 거였다. 이제 그 생각은 떠나보내야겠다고, 그때 처음 생각했다.

비즈니스 매너 교육에서 배운 것도 아직 써먹고 있다. 식당에서 나오면서 "잘 먹었습니다" 하고 인사하는 것, 아는 사람이 보이면 기다리지 말고 먼저 가서 인사하는 것. 사소한데, 이런 게 쌓이니까 사람 대하는 게 조금씩 덜 무서워졌다.

5월부터 7월까지 주말마다 교육이 이어졌다. AI 강의가 대부분이었는데 그 무렵 내가 매일 붙잡고 있던 것과 겹쳐서, 나한테 새로운 건 많지 않았다.

대신 매주 하는 팀 회의에서 회의 자료 정리하는 법, 조리 있게 말하는 법, 남의 의견에 반박하고 보충하는 법을 배웠다. 평생 할 팀플은 이 기간에 다 해본 것 같다.

여기까지는 좋았다. 그런데 이렇게 배운 걸 정작 우리 팀 안에서는 못 썼다.

제자리에서 보낸 3개월

문제는 그다음부터였다. 역할은 나름 나눠져 있었다. 나는 프론트와 백엔드, 한 명은 데이터, 한 명은 기획과 발표, 한 명은 자료조사. 그런데 개발자 네 명이 모인 팀에, 방향을 정해줄 사람이 없었다.

나는 예선을 통과한 Student Start Mode를 계속 밀고 싶었다. 한 팀원은 유학생보다 한국 사회초년생이 실제로 겪는 문제를 다뤄야 한다는 의견이 강했다.

둘 다 틀린 말은 아니었다. 그런데 어느 쪽으로 갈지 결정할 방법이 우리한텐 없었다. 회의는 매주 했지만 정해지는 건 없었고, 티는 안 냈지만 서로 감정이 상해갔고, 새 주제에서 마땅한 아이디어를 찾지 못한 채 3개월이 갔다.

다른 팀들이 앞으로 가는 동안 우리는 제자리에서 주제 탓만 하고 있었다.

그 와중에도 뭔가 만들고는 있긴 했다. 홈 화면, 또래 비교, AI 코칭, 미션, 소비 기록, 생일펀드, 포인트, 심지어 RPG 레이드까지. 회의가 겉돌수록 기능만 계속 늘어났다.

그런데 "그래서 이 앱이 누구의 무슨 문제를 푸는 건데?"라는 질문에는 우리 중 누구도 답을 못 했다. 멘토가 아무 반응이 없었던 게, 지금 생각하면 이상한 일이 아니었다.

지금 와서 제일 후회하는 건 그 팀원도, 리더가 없던 상황도 아니다. 내가 내 결정권을 남한테 넘긴 거다. 내 의견에 자신이 없으니까 판단을 미뤘고, 누가 결론을 내려주기를 기다렸다.

그래 놓고 결과가 나쁘면? 아무한테도 책임을 물을 수 없다. 나는 결정에 제대로 참여하지 않았으니까. 이게 이 프로그램 전체에서 가장 비싸게 배운 교훈이다.

마지막 닷새

그리고 그 멘토링이 있었다. 남은 시간은 닷새. 심지어 같은 7월에 TECH4GOOD 해커톤에서 밤을 새우고 온 지 얼마 안 된 때였다.

백엔드고 데이터고 다 살릴 시간은 없었다. 심사위원한테 보여줄 화면이 제일 급하니까, 프론트만이라도 제대로 만들자. 프론트는 내가 맡고, PPT는 다 같이 붙기로 했다.

첫날은 친구랑 카페에서 손으로 와이어프레임을 그렸다. 종이에 그린 화면을 그대로 옮기는 게 목표였다.

평소 쓰던 Codex로 프론트를 뽑아봤는데 진짜 안 예뻤다. 새로 나온 Kimi K3도 써봤다. 마찬가지였다. 사나흘 안에 끝내야 하는데 이 퀄리티로는 안 되겠다 싶어서 30만원짜리 Claude 플랜을 질렀다. 학생한테 30만원은 큰돈인데, 그 순간엔 그게 제일 싼 선택지였다. 디자인은 Claude의 Fable이 확실히 나았고, 프론트 대부분을 그걸로 구현했다.

그다음 사흘은 카페와 찜질방을 오가면서 보냈다. 사흘 내내 잔 시간을 다 합쳐서 두 시간이었고, 밥은 하루 한 끼였다. 그러면서 화면을 만들고 고치고 다시 만들었다.

커밋이 300개 넘게 쌓였다. SNS 레퍼런스랑 금융 앱들을 뒤져가며 "또래의 금융 생활을 구경하다가 나도 시작하게 되는" 느낌이 나올 때까지 고쳤다.

제일 무서웠던 건 잠이 아니었다. 남들이 3개월 동안 만든 걸 나흘 만에 따라잡을 수 있냐, 만들어도 만족할 만한 게 나오긴 하냐는 질문이었다. 그래도 여기서 접으면 나뿐 아니라 팀원들이 보낸 3~4개월까지 전부 헛것이 된다는 생각으로 버텼다.

그렇게 나온 게 FinMate다. 금융 관리를 미루는 20대에게 또래의 소비·저축·투자 이야기를 짧은 스토리로 보여주고, AI가 고민을 작은 미션으로 바꿔서 첫 행동을 하게 만드는 서비스.

설문 97명, 홈 화면 콘셉트 테스트 108명, 카드 이용 데이터 약 65GB를 마이데이터 형태로 가공한 가상 사용자까지, 닷새치고는 채울 수 있는 건 다 채웠다.

상은 못 받았다

최종 발표는 하나은행 본점에서 했다. 시연은 전부 돌아갔다. 발표는 이번에도 팀원이 맡았고, 심사위원들은 마이데이터를 어떻게 생성했는지, 참고한 레퍼런스가 있는지, 개인정보 문제는 어떻게 풀 건지를 물었다. 우리 팀이 대답하는 걸 지켜보면서 "어, 나쁘지 않은데?"라는 생각까지 했다.

상은 못 받았다.

예상은 하고 있었다. 우리 문제 정의는 나쁘지 않았지만 뻔했고, 솔루션도 심사위원을 설득할 만큼 날카롭고 디테일하지 못했다.

다른 팀들은 본선 아이디어를 3개월 내내 디벨롭해서 왔다. 우리는 그 3개월을 버렸다. "나흘 만에 만든 것치고 잘했다"는 말은 위로가 안 된다. 우리한테도 똑같이 3개월이 주어졌었으니까, 그게 제일 아쉽다.

그래도 이 프로그램을 후회하지 않는다. 시작할 때의 나는 팀플이 무서워서 피하던 사람이었고, 끝날 때의 나는 먼저 인사하고, 회의에서 의견을 내고, 마감 앞에서 도망치지 않는 사람이 됐다.

상은 없었지만 나라는 인간은 한 단계 나아갔다. 그거면 남는 장사였다고 생각한다.