[연재] 봇이 여섯이 되자 뭐가 도는지 안 보였습니다 — 현황판을 만든 이유

초록불이 여섯 개 켜져 있는데, 뭐가 도는지 몰랐습니다

7월 27일 오전이었어요. 제 작업 현황판을 열어놓고 뭘 하나 고치는 중이었는데, 화면에 초록불이 켜진 카드가 줄줄이 늘어서 있었습니다. 그런데 저는 그 초록불을 보면서 지금 뭐가 돌아가고 있는지를 하나도 못 짚었어요.

이유는 좀 어이없었습니다. 그 화면에서 초록불의 뜻이 이거였거든요.

● 초록   LLM 모델을 쓴다
● 회색   안 쓴다
● 빨강   로그에 오류

제가 직접 그렇게 만들어 놓고 잊고 있었습니다. 초록은 "지금 일하는 중"이 아니라 "이 도구는 AI를 부르는 종류다"라는 뜻이었어요. 한 번 정해두면 몇 달을 안 바뀌는 성질이죠. 그런데 사람 눈에 초록불은 무조건 "돌아가는 중"으로 읽힙니다. 화면이 제가 묻지도 않은 질문에 답하면서, 묻고 있는 질문에는 답을 안 하고 있었던 겁니다.

이건 지금 화면의 맨 위입니다. 뭐가 달라졌는지는 아래에서 차근차근 풀게요. 먼저 왜 뒤집었는지부터요.

카드를 절반으로 줄이는 게 답이라고 생각했었어요

원래 화면은 이렇게 생겼습니다. 탭이 여섯 개예요. 봇 · 구조 · 일하는 중 · 에이전트 · 스킬 · 전체. 그 아래에 카드가 좍 깔립니다. 도구 하나가 카드 하나예요.

처음엔 도구가 하나였으니까 카드도 하나였습니다. 그때는 이 화면이 아주 잘 맞았어요. 그런데 사이트를 만들고 쇼츠를 붙이고 배포를 자동으로 돌리면서 도구가 늘었습니다. 폴더 기준으로는 서른다섯 개까지 갔는데, 대부분은 한 번 만들어놓고 안 건드리는 것들이라 실제로 하루에 손이 가는 건 여섯 개쯤이었어요. 그 여섯 개가 문제였습니다.

카드가 여섯 개 늘어서 있는데, 정작 알고 싶은 게 화면에 없었거든요. 제가 알고 싶은 건 늘 이거였습니다.

"지금 이 터미널이 뭘 붙잡고 있지?"

터미널을 두세 개 켜놓고 일하니까요. 왼쪽 창에서 사이트를 고치고 오른쪽 창에서 쇼츠를 만들고 있으면, 어느 쪽이 뭘 하는 중인지가 헷갈립니다. 그런데 화면은 봇 이름으로만 말해요. "shorts 가 3분 전에 움직였다." 그게 왼쪽 창인지 오른쪽 창인지는 안 알려줍니다. 심지어 두 창이 같은 도구를 동시에 만지고 있어도 카드는 하나였어요. 두 사람이 같은 문을 잡고 있는데 문이 하나만 그려져 있는 셈이죠.

그때 제가 뭘 했냐면, 카드를 작게 만들었습니다. 그 시절 화면 코드에 이런 주석이 남아 있어요.

/* 카드를 절반 크기로 — 한 화면에 봇 전체가 들어와야 관제가 된다 */

틀린 방향이었습니다. 전부 한 화면에 들어오게 만드는 게 문제가 아니었어요. 애초에 화면이 대답하는 질문 자체가 제 질문이 아니었던 거죠. 카드를 백 장 깔아놓고 절반 크기로 줄여봐야, 그 백 장 중에 지금 살아 있는 두 줄을 찾으려면 여전히 눈으로 훑어야 합니다.

주어를 봇에서 터미널로 바꿨습니다

그래서 7월 27일 오전 10시 39분에, 고치기 전 상태를 통째로 한 번 저장해두고 설계 문서부터 다시 썼습니다. 첫 줄이 이거였어요.

지금 화면은 봇이 주어다. 쓰다 보니 알고 싶은 건 그게 아니었다.

바꾼 건 딱 하나입니다. 주어를 터미널로. 문장으로 쓰면 이렇게 돼요.

터미널 ttys000 · victor-09 · 총괄 Opus 5
 └ 봇 shorts                    ← 그 터미널이 지금 만지는 것
    └ 에이전트 Explore · 12k

3층입니다. 터미널이 없으면 봇도 없고, 봇이 없으면 에이전트도 없어요. 화면에서는 터미널 하나가 세로 '레인' 하나가 됩니다. 창을 하나 켜면 레인이 하나, 셋 켜면 셋이 나란히 서요.

이게 레인 하나입니다. 맨 위 줄이 터미널이에요. 어느 창인지(ttys000), 이름이 뭔지, 총괄이 어느 모델인지, 그리고 컨텍스트를 얼마나 먹었는지가 한 줄에 있습니다. 481k / 1.00M 이면 백만 자리 중 48만을 쓴 거예요. 이게 꽉 차면 그 창은 곧 기억을 잘라내기 시작하니까, 미리 보이면 정리할 타이밍을 잡을 수 있습니다.

레인 머리만 떼어 보면 이렇게 생겼어요. 아래 초록 막대가 컨텍스트고, 오른쪽 "이번 주기"는 이 창이 이번 한 주에 쓴 양입니다.

그 아래에 그 터미널이 만진 도구들이 쌓입니다.

이제 "누가"가 먼저 나오고 "무엇을"이 그 안에 들어갑니다. 같은 도구를 두 창이 만지고 있으면 레인 두 개에 각각 뜨고요. 예전엔 한 장으로 뭉개지던 게 이제 두 줄로 갈립니다.

불 켜지고 꺼지는 규칙도 새로 정했어요. 이번엔 "지금 도는가"만 말하게 했습니다.

위 사진에서 빨간 테두리에 오류 한 줄이 그대로 보이죠. FileNotFoundError 로 시작하는 것. 화면에 오류 문구를 통째로 띄우게 한 게 은근히 값을 합니다. 로그 파일을 열러 가지 않아도 뭐가 없다는 건지 바로 읽히거든요.

계측을 하나도 안 심었습니다

여기서 제가 제일 신경 쓴 결정이 하나 있어요. 도구들 안에 아무것도 안 심었다는 겁니다.

보통 이런 화면을 만들면 각 프로그램에 "나 시작했어", "나 끝났어"를 보고하는 코드를 한 줄씩 넣습니다. 그게 제일 쉬워요. 그런데 그렇게 하면 서른다섯 개를 전부 뜯어고쳐야 하고, 더 나쁜 게 있습니다. 재는 도구가 재는 대상을 바꾸게 돼요. 나중에 현황판이 잘 안 보인다는 이유로 봇 코드를 고치는 날이 오는데, 그건 순서가 거꾸로죠.

그래서 이미 남아 있는 흔적만 읽기로 했습니다. 설계 문서에 표로 다 적어놨어요.

전부 원래부터 디스크에 쌓이던 것들입니다. 새로 만든 게 하나도 없어요. 그래서 봇을 한 줄도 안 고치고 현황판이 붙었습니다. 나중에 도구를 새로 만들어도 자동으로 잡히고요.

AI 도구인데 AI를 한 번도 안 부릅니다

두 번째 결정은 이거예요. 이 화면은 LLM 을 한 번도 안 부릅니다.

"AI로 만든 도구니까 요약도 AI가 하면 되지" 하는 유혹이 꽤 셌어요. 카드에 "지금 뭘 하는 중"을 두세 줄로 적으려면 요약이 필요하잖아요. 그런데 그렇게 만들면 이 화면은 켜놓는 것만으로 계속 돈이 나가는 물건이 됩니다. 3초마다 새로 그리는 화면인데요.

그래서 그 두세 줄도 전부 기록에서 그냥 뽑아 이어 붙였습니다. 마지막에 제가 친 말 한 줄, 그 뒤에 부른 도구 두 개. 그게 다예요. 위 사진에 "Bash · Commit the prompt fix" 같은 줄이 그렇게 붙은 겁니다. 문장이 매끄럽진 않은데, 대신 틀릴 일이 없어요. 요약이 아니라 그대로 옮긴 거니까요.

덕분에 이 화면은 하루 종일 켜놓아도 비용이 0입니다. 이게 그냥 절약 이야기가 아니라, 하루 종일 켜놓을 수 있느냐 없느냐를 가르는 조건이었어요. 켜놓을 수 없는 현황판은 현황판이 아니니까요.

트리를 그리려다 관뒀습니다 — 표본 80개를 뒤졌더니

원래 계획은 에이전트를 나무처럼 그리는 거였습니다. 총괄이 있고, 그 밑에 시킨 애가 있고, 걔가 또 시킨 애가 있고… 흔히 그렇게 그리잖아요.

그리기 전에 실제 기록 80개를 뒤져봤습니다. 결과가 이랬어요.

서브에이전트가 더 아래로 뻗은 경우는 0건이었다. 구조는 실제로 2단이다.

없는 계층을 그리면 그건 그냥 거짓말이죠. 그래서 트리를 버렸습니다. 대신 다른 게 보였어요. 같은 요청 하나에서 동시에 여럿이 뜬 무리가 기록에 남아 있더라고요. 어떤 작업은 여덟 개가 한꺼번에 떴고요.

그래서 나무 대신 가로 막대 띠를 그리기로 했습니다. 시작·끝 시각으로 막대를 놓으면, 띠가 겹쳐 있으면 동시에 돈 거고 어긋나 있으면 차례로 돈 겁니다. 실제 기록의 4개짜리 묶음(83초·55초·49초·33초)이 딱 겹쳐서 그려지는 걸로 확인했어요.

보기 좋은 그림이 아니라 사실에 맞는 그림을 골랐다는 게 이 대목의 요지입니다. 트리가 훨씬 멋있어 보였거든요.

계획대로 지었으면 절반이 지어낸 숫자였습니다

여기가 이번 편에서 제일 아찔했던 곳이에요.

에이전트 하나가 끝나면 부모 기록에 결과가 남습니다. 모델이 뭐였고 토큰을 얼마 썼고 몇 초 걸렸는지요. 계획은 그 기록을 읽어서 "끝난 실행" 목록을 만드는 거였습니다. 아주 자연스러운 설계죠.

그런데 짓고 나서 실제 데이터를 세어봤더니 이랬습니다.

에이전트 기록 535건 중 257건이 '띄웠다'만 남기고 끝
에이전트 520개 중 시작·완료를 둘 다 가진 것 = 0개

절반이 완료 기록을 영영 안 남깁니다. 뒤로 돌려놓고 부모는 다음 일을 하러 가버리는 방식이라, 부모 쪽 기록에는 "띄웠다"까지만 찍혀요. 그런데 계획대로 만든 코드는 그 257건을 그냥 토큰 0, 모델 "?" 로 채워서 '끝난 실행'으로 내보내고 있었습니다.

화면에 뜨면 어떻게 보이냐면요. 에이전트 목록이 좍 나오는데 절반이 0k 예요. 저는 그걸 보고 "아, 얘네는 별로 안 썼구나" 하고 읽었을 겁니다. 실제로는 얼마나 썼는지 모르는 건데, 화면은 '0'이라고 말하고 있는 거죠. 모르는 걸 0으로 적는 건 비워두는 것보다 훨씬 나쁩니다. 비어 있으면 사람이 의심하는데, 0은 그냥 믿게 되거든요.

이건 AI가 게을러서 생긴 게 아니에요. 계획을 세울 때 실제 데이터를 안 세어봤기 때문입니다. 기록에 그런 필드가 있으니까 당연히 채워져 있을 거라고 본 거죠. 제가 실데이터로 직접 세어보고서야 드러났습니다.

고친 방식은 이래요. 뒤로 돌린 것은 부모 기록에서 이름표만 가져오고, 토큰과 시각은 그 에이전트 자기 기록 파일에서 다시 읽습니다. 그리고 그 파일이 90초 넘게 안 바뀌었으면 끝난 걸로 보되, 화면에 done? 이라고 물음표를 붙여서 표시해요. 추측이라는 걸 화면에 남기는 겁니다.

같은 검사에서 하나 더 나왔습니다. 세션을 이어서 켜거나 기억을 접을 때 같은 기록이 두 번 들어가는 경우가 있었어요. 서른 개 중 두 개요. 그대로 뒀으면 그 두 개는 화면에 두 번 그려지고 토큰도 두 배로 잡혔을 겁니다.

숫자 하나 차이로 글자가 깨지는 자리

좀 더 작지만 성격이 비슷한 것도 있었어요.

이 화면은 기록 파일을 매번 처음부터 읽으면 느려서, 늘어난 부분만 읽습니다. 지난번에 어디까지 읽었는지 위치를 기억해뒀다가 거기서 이어 읽는 거죠. 그 위치를 계산하는 코드가 계획서에 들어 있었는데, 그게 틀렸습니다.

한글이 문제였어요. 영어는 한 글자가 1바이트인데 한글은 3바이트입니다. 글자 수로 세어놓고 바이트 위치로 쓰면 어긋나요. 직접 재현해봤더니 이랬습니다.

정답 9  → 계획 코드는 8
정답 18 → 계획 코드는 12
어떤 경우엔 -1 이 나와서 다음 번에 아예 읽기 실패

한 칸씩 밀려서 읽으면 다음 줄이 깨진 채로 들어옵니다. 그럼 그 줄에 있던 토큰은 그냥 사라져요. 조용히요. 오류도 안 나고 화면도 멀쩡해 보이는데 숫자만 조금씩 모자란 상태가 되는 겁니다.

여기서 배운 게 하나 있어요. 처음엔 이걸 잡는 테스트를 넣었는데, 그 테스트가 옛날 틀린 코드에서도 통과했습니다. "값이 있으면 됐다" 식으로 느슨하게 확인했거든요. 그래서 다시 갔습니다. "정확히 9여야 한다"로 못 박고 나서야 옛 코드가 제대로 빨간불이 났어요. 테스트가 통과했다는 말과 코드가 맞다는 말은 다른 말입니다.

다 짓고 나서 셋이 더 걸렸습니다

설계대로 다 짓고, 실제로 켜서 확인했습니다. 도구 서른다섯 개에 세션 기록 아흔일곱 개, 터미널 두 개를 켜놓고요. 그랬더니 셋이 걸렸어요.

첫째, 두 번째 새로고침부터 화면이 텅 비었습니다. 늘어난 부분만 읽는 구조라서, 읽을 게 없으면 아무것도 안 읽었고, 그럼 그 세션의 상태가 초기값으로 돌아갔어요. 3초 뒤에 모델도 컨텍스트도 잡은 도구도 전부 0이 됐습니다. 첫 화면은 완벽했는데 두 번째부터 유령이 된 거죠. 세션별 마지막 상태를 따로 들고 있다가 그 위에 덮어쓰는 걸로 고쳤습니다.

둘째, 조용해진 도구가 화면에서 아주 사라졌습니다. 레인에서 빠지면 보관함으로 가야 하는데, 레인에 못 세운 것까지 '쓰는 중'으로 쳐버려서 보관함에서도 빠졌어요. 어디에도 없는 상태가 된 겁니다.

셋째는 다음 편에서 할게요. 한 주에 얼마 썼는지를 세는 부분인데, 그 얘기만 한 편이 나옵니다.

응답 속도는 목표가 0.3초였는데 첫 요청 1.6초, 두 번째부터 0.075초가 나왔습니다. 첫 요청이 느린 건 그동안 쌓인 걸 소급해서 한 번 읽기 때문이고, 그건 한 번뿐이에요.

같은 '확인' 단추인데, 하나는 관문이고 하나는 기록입니다

이번 편에서 제일 오래 고민한 게 이겁니다. 오후에 만든 건데, 사실 이게 이 화면의 성격을 정했어요.

자동으로 도는 일들이 있습니다. 정해진 시각에 알아서 도는 것들요. 화면 아래쪽에 이렇게 섭니다.

이건 사이트 배포 쪽이에요. 네모 하나가 회차 하나입니다. 네모 안 위가 예정 시각, 아래가 실제로 돈 시각이에요. 09:00 예정인데 09:05 에 돌았으면 거기서 바로 보입니다. 색은 회색이 아직 안 함, 노랑이 도는 중, 초록이 됐음, 빨강이 실패예요. 아래에는 그날 뭘 내보냈는지가 줄줄이 남고요.

여기까지는 그냥 보는 화면입니다. 그런데 다른 쪽에는 단추를 달았어요.

쇼츠 쪽입니다. 맨 왼쪽 카드 제목 옆에 "확인해야 올라감" 이라고 붙어 있죠. 대기열에 쌓인 영상은 제가 체크를 해야만 다음 회차에 올라갑니다. 안 누르면 로그에 "확인 대기"만 남고 아무것도 안 나가요.

왜 여기만 막았냐면, 유튜브는 한 번 올라가면 되돌리기가 어렵기 때문입니다. 지워도 이미 본 사람이 있고, 채널 기록에도 남아요. 되돌릴 수 없는 일 앞에는 사람이 한 번 서야 합니다.

그런데 연재 원고 쪽에는 같은 모양의 확인 단추를 달아놓고 발행은 안 막았습니다. 이건 관문이 아니라 기록이에요. 제가 읽었으면 표시가 남고, 안 읽고 나간 글은 나중에 미확인 발행 이라고 빨갛게 뜹니다. 그래서 나중에라도 눈에 걸려요.

왜 여기는 안 막았냐. 한 번 못 누른 날 연재가 통째로 비는 게 더 나쁘기 때문입니다. 매일 한 편씩 나가는 물건인데, 제가 하루 바빠서 화면을 못 열면 그날이 그냥 빕니다. 글은 나가고 나서도 고칠 수 있어요. 유튜브랑 다릅니다.

정리하면 기준은 하나예요.

되돌릴 수 있으면 기록만 하고, 되돌릴 수 없으면 관문을 세운다.

같은 단추, 같은 코드, 같은 화면인데 하나는 막고 하나는 안 막습니다. 이 판단은 AI 가 대신 못 해요. 코드만 보면 둘은 완전히 똑같은 확인 단추거든요. 뭐가 되돌릴 수 있는 일이고 뭐가 아닌지는 그 일을 실제로 하는 사람만 압니다.

그래서 지금은 이렇게 보입니다

그날 오전에 뒤집고 오후 내내 다듬었어요. 그 뒤로도 계속 붙었고요. 지금은 탭이 이렇게 있습니다.

구조 — 도구를 성격별로 갈라놓은 탭입니다. 이건 예전 화면에서 살려온 건데, 하나가 크게 달라졌어요. 카드를 누르면 그렇게 판정한 근거가 파일까지 펼쳐집니다.

"이 도구는 중앙이 일을 쪼개 맡기는 구조다, 43회 나왔다"까지만 말하면 맞는지 틀린지 따질 수가 없거든요. 그래서 어느 파일에서 몇 번 나왔는지를 다 폅니다. 그런데 여기서 재미있는 게 하나 나왔어요. 43회 중 23회가 테스트 파일 한 곳에서 나왔습니다.

테스트 파일은 구조를 설명하는 말이 실제 코드보다 훨씬 많이 나와요. 그러니까 판정 근거의 절반이 테스트에서 나왔다면 그 판정은 의심해야 합니다. 그래서 테스트 파일은 주황색으로 칠했어요. 화면 아래쪽 초록색은 AI 를 실제로 부르는 파일이고요. 색만 봐도 "얘는 진짜 그런 구조인가, 아니면 테스트에서 말만 많은 건가"가 갈립니다.

토큰 — 한 주에 얼마 썼나. 날짜별로 쌓아두고 기간을 골라 다시 더합니다.

주 단위 경계를 목요일 오후 1시로 잡았는데, 이 경계 하나 때문에 숫자가 크게 어긋났던 적이 있어요. 그 얘기가 다음 편입니다.

지표 — 올린 쇼츠가 얼마나 돌았나.

여기 규칙이 하나 있는데, 올린 지 같은 시간일 때끼리만 견줍니다. 어제 올린 편이랑 아까 올린 편의 조회수를 나란히 놓으면 오래된 쪽이 무조건 이기잖아요. 그렇다고 '시간당'으로 나누면 이번엔 초반에 몰리는 쇼츠 특성 때문에 어린 쪽이 무조건 이기고요. 그래서 6시간·24시간·48시간 시점을 찍어서 그때끼리 비교합니다.

색인 — 구글이 제 글을 몇 장 올려뒀나.

이 탭은 여기서 구글에 묻지 않습니다. 서치콘솔은 로그인이 있어야 열리고 하루에 몇 번 볼 화면도 아니거든요. 제가 손으로 열어본 결과를 파일에 적으면 이 탭이 읽어서 그립니다. 다시 확인할 때는 그 파일만 새로 쓰면 되고요.

건강 — 어제 돌았어야 할 것들이 실제로 돌았나.

여기 원칙도 하나예요. 로그가 아니라 결과를 봅니다. "성공했습니다"라고 로그에 찍혀 있는 건 증거가 아니에요. 파일이 실제로 새로 생겼는지, 몇 건이 들었는지를 봅니다. 스위치 자료 931건, 이어폰 자료 2,517건 하는 식으로요.

마지막으로 오래 걸리는 일 칸이 있습니다.

밤새 도는 수집이나 변환 같은 것들이에요. 정해진 시각에 도는 것도 아니고 제가 창 앞에 앉아 시킨 것도 아닌, 그냥 며칠씩 도는 일들요. 카드는 세 가지만 답합니다. 어디까지 갔나 · 뭐가 돌고 있나 · 언제 끝나나.

이 칸에는 규칙을 하나 더 넣었어요. 못 센 건 0 이 아니라 '못 셈'으로 적습니다. 외장 디스크를 안 꽂아뒀을 때 다 끝난 작업이 0% 로 뜬 적이 있거든요. 앞에서 얘기한 그 문제랑 똑같아요. 모르는 걸 0 이라고 적으면 사람이 믿습니다.

도구가 늘면, 도구를 보는 도구가 필요해집니다

앞에 한 번 이런 일이 있었어요. 어느 날 이 현황판을 열었더니 터미널이 세 개로 잡혀 있었습니다. 제가 연 건 하나였는데요. 유령 창 두 개가 붙어 있던 걸 그때 알았습니다. 현황판이 없었으면 몰랐을 일이에요.

만들 때는 그냥 "뭐가 도는지 보려고" 만든 거였습니다. 그런데 쓰다 보니 자꾸 다른 걸 알려주더라고요. 유령 창이 있다는 것도, 제가 어디에 시간을 쓰고 있는지도, 어제 돌았어야 할 게 안 돌았다는 것도요.

이번 편에서 사람이 남은 자리를 꼽으라면 넷입니다.

하나, 질문을 바꾼 것. AI 는 "봇이 주어인 화면"을 아주 잘 만들어줬어요. 문제는 그 화면이 제가 묻는 질문에 답을 안 한다는 거였는데, 그건 화면을 몇 주 써본 사람만 압니다. 코드에는 그 정보가 없어요.

둘, 안 만들기로 정한 것. 계측을 안 심기로, LLM 을 안 부르기로, 트리를 안 그리기로. 셋 다 "그게 자연스러운 방향"의 반대였습니다. 만들 수 있는 걸 안 만드는 결정은 AI 가 잘 못 해요. 물어보면 대개 만들 수 있다고 답합니다.

셋, 실제 데이터를 세어본 것. 절반이 지어낸 숫자가 될 뻔한 걸 잡은 건 실데이터를 손으로 세어봤기 때문이고, 트리를 안 그린 것도 표본 80개를 뒤졌기 때문입니다. 둘 다 "설계가 그럴싸한가"가 아니라 "실제로 그런가"를 물어본 거예요.

넷, 되돌릴 수 있는지를 가른 것. 유튜브는 막고 연재는 안 막았습니다. 코드로는 똑같은 단추 두 개인데, 어느 쪽이 되돌릴 수 없는 일인지는 화면 밖에 있는 사실이에요.

만드는 건 빨랐어요. 오전 10시 39분에 옛 화면을 저장하고, 11시 56분에 새 관제 화면이 떴습니다. 한 시간 십몇 분이요. 그런데 그 앞의 "주어를 바꿔야겠다"는 한 줄이 나오기까지는 몇 주가 걸렸습니다. 그 한 줄이 안 나왔으면 저는 아직도 카드를 절반 크기로 줄이고 있었을 거예요.

다음 편은 이 화면이 세는 숫자 이야기입니다. 한 주에 얼마 썼나를 재려다가, 처음엔 200배 틀린 값을 보고 있었거든요.

#현황판 #대시보드 #에이전트모니터링 #터미널관제 #개발자도구 #관측성 #모니터링 #자동화관리 #크론탭 #cron #파이썬 #표준라이브러리 #의존성없이 #로컬서버 #AI코딩 #클로드 #클로드코드 #개발자아닌사람 #사이드프로젝트 #1인개발 #휴먼인더루프 #사람이하는일 #설계문서 #스펙먼저 #테스트코드 #증분파싱 #로그분석 #유튜브쇼츠 #victorhouse #개인홈페이지