논문의 핵심은 간단하다.

기존에는 DRAM의 Read Eye Margin을 확인하기 위해 전압과 시간을 촘촘하게 훑는 Shmoo Scan을 사용했다. 하지만 이제는 1010... 패턴을 출력시킨 뒤, 평균 전류(Net Current)를 한 번 측정하는 방식으로 Eye Margin 불량을 빠르게 검출하자는 것이다.

결과적으로 기존 방식 대비 테스트 시간을 약 74% 단축했다. 2.48초 → 0.65초 수준으로 줄였다고 한다.

⸻

1. 왜 DRAM에 Read Eye Margin 테스트가 필요한가?

DRAM 테스트라고 하면 우선 “데이터 0과 1을 제대로 읽고 쓰는가?”를 생각하게 된다.

예를 들어 Write 이후 Read를 수행했을 때, 저장한 데이터와 읽어낸 데이터가 같다면 기능적으로는 정상이라고 볼 수 있다. 하지만 이것만으로는 충분하지 않다.

고속 DRAM에서는 데이터가 매우 짧은 시간 안에 전송되기 때문에, 단순히 어느 한 시점에서 0 또는 1이 판정되었다고 해서 안정적인 I/O 특성을 보장할 수 없다.

이때 확인해야 하는 것이 바로 Read Eye Margin이다.

• Eye Height: High와 Low 전압 레벨이 충분히 벌어져 있는가?
• Eye Width: 데이터를 안정적으로 샘플링할 수 있는 시간 구간이 충분한가?

즉, 단순 기능 테스트는 “지금은 읽혔는가?”를 본다면, Eye Margin 테스트는 “PVT 변화나 노이즈가 있어도 앞으로 안정적으로 읽힐 여유가 있는가?”를 보는 테스트라고 이해하면 된다.

논문에서 말하는 multiple operation modes 역시 단순히 Read, Write, Refresh만 많아졌다는 의미보다는, 고속·저전력 DRAM이 다양한 주파수, 전력 상태, 구동 조건, I/O 동작 조건을 지원하면서 검증해야 할 조합 자체가 많아졌다는 의미에 가깝다.

그만큼 대량 생산 단계에서의 Test Time이 계속 늘어나는 문제가 생긴다.

⸻

2. 기존 방식: Comparator 기반 Shmoo Scan

기존 Read Eye Margin 테스트는 보통 ATE의 Comparator를 이용한 Shmoo Scan 방식으로 수행된다.

ATE는 DRAM에서 출력되는 DQ 신호를 보면서 다음 두 가지를 바꿔가며 측정한다.

1. 언제 샘플링할 것인가? → Time Offset 조절
2. 어느 전압을 기준으로 0과 1을 판정할 것인가? → Comparator Reference Voltage 조절

이 과정을 시간 축과 전압 축 전체에 대해 반복하면 아래와 같이 Shmoo Plot을 얻을 수 있다.

• 초록색 영역: 정상적으로 데이터가 판정되는 구간
• 빨간색 영역: 데이터 판정 실패 구간

정상 칩은 초록색 영역이 넓고 둥근 Eye를 형성한다. 반대로 불량 칩은 Eye의 위쪽, 아래쪽 또는 좌우 폭이 줄어든다.

문제는 이 방식이 너무 느리다는 것이다.

전압을 여러 단계로 바꾸고, 각 전압에서 다시 시간 축을 여러 포인트로 나누어 확인해야 한다. 해상도를 높일수록 정확도는 좋아지지만, 측정 포인트 수가 급격하게 늘어난다.

개발 단계에서는 상세한 특성 분석에 유용하다. 하지만 수많은 칩을 빠르게 선별해야 하는 양산 환경에서는 Test Time 증가가 곧 생산성 저하로 이어진다.

특히 Eye Height 불량은 비교적 적은 전압 포인트로도 잡을 수 있지만, 듀티 사이클 왜곡(DCD)처럼 Eye Width가 줄어드는 불량은 시간 축까지 더 촘촘하게 스캔해야 한다.

즉, 기존 방식은 정확하지만 양산용으로는 부담이 큰 방법이다.

⸻

3. 논문의 핵심 아이디어: 1010... 출력 중 평균 전류만 측정하자

이 논문은 ATE 내부 PMU의 VSIM(Voltage Source Current Measurement) 기능을 이용한다.

VSIM은 말 그대로 특정 전압을 강제한 뒤, 그때 흐르는 전류를 측정하는 기능이다. 일반적으로는 Output Driver의 Pull-up/Pull-down 강도나 ODT 특성, DC I-V 특성 등을 확인하는 데 활용할 수 있다.

그런데 저자들은 VSIM을 정적인 상태가 아니라, DRAM DQ가 빠르게 토글되는 동적인 상황에 적용했다.

DRAM이 101010... 패턴을 출력하도록 만들고, DQ에 연결된 ATE가 VDDQ/2 정도의 중간 전압을 유지한 상태에서 전류를 측정한다.

이때 동작은 다음처럼 해석할 수 있다.

• DRAM이 1을 출력할 때 → Pull-up Driver가 동작 → 전류가 DRAM에서 ATE 방향으로 흐름 → 논문 기준 음(-)의 전류로 측정
• DRAM이 0을 출력할 때 → Pull-down Driver가 동작 → 전류가 ATE에서 DRAM 방향으로 흐름 → 논문 기준 양(+)의 전류로 측정

정상적인 DRAM이라면 Pull-up과 Pull-down의 세기가 비슷하고, 1과 0이 머무는 시간도 거의 50:50이다.

따라서 음(-) 전류와 양(+) 전류가 평균적으로 상쇄되어 Net Current가 0mA 근처에 형성된다.

논문에서는 이를 아래처럼 표현한다.

$$ I_{\mathrm{net}} = \frac{V_{\mathrm{DDQ}}}{2} \left( \frac{1}{R_{\mathrm{PD}}} - \frac{1}{R_{\mathrm{PU}}} \right) $$

여기서 (R_{PU}), (R_{PD})는 각각 Pull-up과 Pull-down Driver의 유효 On-Resistance다.

만약 듀티 사이클까지 고려하면 다음처럼 확장할 수 있다.

$$ I_{net} = \frac{VDDQ}{2}\left(\frac{D_{PD}}{R_{PD}}-\frac{D_{PU}}{R_{PU}}\right)$$

즉, 평균 전류는 단순히 Driver 강도 차이뿐 아니라, High와 Low가 유지되는 시간 비율 차이까지 반영한다.

⸻

4. 불량이 발생하면 왜 평균 전류가 한쪽으로 쏠릴까?

이 방식의 핵심은 “Eye Margin 불량이 생기면, 결국 Pull-up/Pull-down Driver의 세기나 활성 시간의 균형이 무너진다”는 점이다.

4-1. 정상 칩

정상 칩에서는 Pull-up과 Pull-down의 세기가 유사하다.

또한 1과 0이 유지되는 시간도 거의 동일하다.

그래서 1 출력 시 발생하는 음(-) 전류와 0 출력 시 발생하는 양(+) 전류가 서로 상쇄되고, 평균 Net Current는 0mA 근처에 위치한다.

⸻

4-2. VOH 부족: Pull-up Driver가 약한 경우

Pull-up Driver가 약하면 1을 충분히 높게 밀어 올리지 못한다.

즉, VOH가 낮아지고 Eye의 상단이 줄어든다.

이 경우 Pull-up 구간에서 발생해야 할 음(-) 전류의 절대값이 작아진다. 반면 Pull-down 구간의 양(+) 전류는 상대적으로 더 크게 남는다.

결국 평균 Net Current는 양(+) 방향으로 이동한다.

⸻

4-3. VOL 부족: Pull-down Driver가 약한 경우

반대로 Pull-down Driver가 약하면 0을 충분히 낮게 끌어내리지 못한다.

이 경우 VOL이 충분히 낮아지지 않아 Eye의 하단이 줄어든다.

Pull-down 구간에서 발생해야 할 양(+) 전류가 약해지므로, Pull-up 구간의 음(-) 전류 영향이 상대적으로 커진다.

결국 평균 Net Current는 음(-) 방향으로 이동한다.

⸻

4-4. DCD: 듀티 사이클 왜곡으로 Eye Width가 줄어드는 경우

듀티 사이클 왜곡(Duty Cycle Distortion, DCD)은 1과 0이 유지되는 시간이 50:50이 아닌 상태를 의미한다.

예를 들어 1이 57%의 시간 동안 유지되고 0이 43%만 유지된다면, 두 전류가 흐르는 시간 자체가 달라진다.

Driver 강도는 정상이어도, 한쪽 전류가 더 오래 흐르기 때문에 평균 전류는 0에서 벗어난다.

즉, 전압 레벨 불량뿐 아니라 시간 축의 불량인 Eye Width 감소도 Net Current Offset으로 감지할 수 있다.

⸻

5. 실제 측정 결과

논문에서는 8.5 Gbps, 85°C 조건에서 LPDDR5 칩 40개를 측정했다.

정상 칩은 Net Current가 거의 0mA 근처에 모였다.

반면 Eye Height 불량 칩은 확실한 Offset을 보였다.

• VOH 부족 칩: 약 +2.3mA
• VOL 부족 칩: 약 -2.7mA
• 정상 칩: 약 0mA 부근

즉, 전류 값이 단순히 “정상 범위를 벗어났다”는 것만 보여주는 것이 아니다.

전류가 어느 방향으로 이동했는지를 보면 Pull-up 불량인지, Pull-down 불량인지까지 어느 정도 추정할 수 있다. Eye Width 불량인 DCD도 마찬가지였다.

• 듀티 비율 57:43 → 약 -1.32mA
• 듀티 비율 59:41 → 약 -1.50mA
• 듀티 비율 43:57 → 약 +1.40mA

정상적인 50:50 듀티에서는 Net Current가 0에 가까웠지만, 듀티 비율이 틀어질수록 평균 전류가 한쪽으로 이동했다.

기존 방식이라면 여러 타이밍 포인트에서 Comparator 기준을 이동시키며 Eye Width를 직접 확인해야 한다. 하지만 이 방식은 평균 전류 한 번으로 DCD 관련 불량까지 감지할 수 있다.

⸻

6. Test Time은 얼마나 줄었을까?

기존 Comparator 기반 방식은 VOH/VOL 불량을 찾기 위해 여러 전압 레벨을 확인해야 하고, DCD에 의한 Eye Width 불량까지 잡기 위해서는 시간 축 스윕도 필요하다.

반면 제안 방식은 1010... 패턴 출력 중 VSIM으로 Net Current를 한 번 측정하면 된다.

논문 결과는 다음과 같다.

구분 기존 Comparator 기반 방식 제안 VSIM 방식 테스트 시간 2.48초 0.65초 불량 검출 범위 VOH / VOL / DCD VOH / VOL / DCD 시간 단축률 - 약 74%

중요한 점은 단순히 “조금 덜 정확한 대신 빨라진 방법”이 아니라는 것이다.

논문에서는 기존 Margin Test와 동등한 수준의 불량 검출 능력을 유지하면서도 테스트 시간을 크게 줄였다고 주장한다.

⸻

7. 정리

이 논문은 DRAM Read Eye Margin을 직접 Shmoo Scan으로 그리는 대신, 출력 Driver의 전류 균형이 무너지는 현상을 이용해 불량을 빠르게 검출한 연구다.

기존 방식은 전압과 시간 축을 촘촘하게 스캔해야 해서 정확하지만 오래 걸린다.

반면 제안 방식은 1010... 데이터 토글 상황에서 평균 Net Current를 측정한다.

• 정상 칩: Pull-up / Pull-down 전류가 상쇄되어 0mA 근처
• VOH 불량: Pull-up이 약해져 양(+) 방향 Offset
• VOL 불량: Pull-down이 약해져 음(-) 방향 Offset
• DCD 불량: High / Low 유지 시간 차이로 Offset 발생

결국 이 논문은 “Eye를 직접 전부 그리지 않고도, 출력 전류의 평균값만으로 Eye Height와 Eye Width 관련 불량을 동시에 잡을 수 있다”는 점이 핵심이다.

PE 관점에서도 흥미로운 포인트는 단순히 Fail을 검출하는 것을 넘어, 전류 Offset의 방향과 크기를 통해 어떤 I/O 비대칭이 발생했는지 빠르게 분류할 수 있는 가능성이다.

양산 Test에서는 정확도뿐 아니라 Test Time이 매우 중요하다. 이 논문은 회로의 동작 특성을 다른 물리량인 전류로 변환해 관찰함으로써, 기존 테스트 구조를 더 효율적으로 바꾼 사례라고 볼 수 있다.

Reference

• High-Speed ATE-Based Test Method for DRAM Read Eye Margin Failure Detection 논문

물론 ChatGPT, Claude 같은 서비스의 사용자는 계속 늘고 있다. 그럼에도 많은 사람들이 기대하는 “AI Agent 시대”가 오려면, 거창한 기술보다 먼저 사람들이 실제 업무에서 체감할 수 있는 작은 자동화 경험이 필요하지 않을까 싶었다.

그래서 나는 이것을 나름 “대 딸깍 시대”라고 부르고 싶다. 복잡한 개발 지식이 없더라도, AI에게 원하는 것을 설명하고, 필요한 서비스를 빠르게 만들고, 실제 문제에 바로 적용하는 시대 말이다.

이번에 내가 적용해본 문제는 RRC, 즉 연세대학교 중앙 레크리에이션 동아리의 대동제 부스 운영이었다.

RRC는 내가 가장 애정을 가지고 활동했던 동아리다. 이번 학기에는 임원진은 아니었지만, 그래도 추억이 많이 남아 있는 동아리에 조금이라도 기여하고 싶었다. 대동제 부스를 운영할 때 주문을 사람이 직접 받고, 이를 다시 정리해서 전달하는 과정이 꽤 번거로울 수 있다고 생각했다.

그래서 주문 접수 과정을 웹사이트로 대체해보기로 했다.

사용자는 웹사이트에서 주문을 입력하고, 주문이 들어오면 운영진은 구글 스프레드시트에서 바로 확인할 수 있도록 만들었다. RRC는 원래 구글 드라이브를 운영 폴더로 사용하고 있었기 때문에, 일부러 별도의 백엔드를 만들기보다는 다음 임원진들도 쉽게 이해하고 따라할 수 있도록 구글 스프레드시트를 데이터 저장소처럼 활용했다.

아래는 Codex에게 직접 프롬프트를 주고 만든 주문 웹사이트다. (gif로 변경했는데 화질이...)

영상처럼 주문을 완료하면, 아래와 같이 어디로 보내달라는 안내가 나온다.

그리고 주문 정보는 구글 드라이브 안의 스프레드시트에 자동으로 기록된다. 운영진은 별도의 관리자 페이지에 접속할 필요 없이, 기존에 익숙하게 사용하던 구글 스프레드시트만 확인하면 된다.

이번 프로젝트가 엄청 거창한 서비스는 아니다. 하지만 오히려 그래서 더 의미가 있었다고 생각한다.

AI를 활용해서 무언가를 만든다는 것이 꼭 완전히 새로운 서비스를 출시하는 것만을 의미하지는 않는다. 기존에 사람이 반복해서 하던 일을 줄이고, 운영진이 더 중요한 일에 집중할 수 있게 만들고, 남는 인력을 호객이나 현장 대응에 쓸 수 있게 만드는 것도 충분히 의미 있는 활용이라고 생각한다.

이번 학기에는 임원진이 아니었지만, 그래도 내가 애정을 가지고 있던 동아리에 작은 자동화를 남길 수 있어서 좋았다. 그리고 이런 작은 경험들이 쌓여야 진짜 AI Agent 시대도 자연스럽게 오지 않을까 싶다.

어떻게 인간의 개입 없이 에이전트 스스로 거대한 프로젝트를 완성할 수 있었을까요? 엔지니어들은 코드를 직접 짜는 대신, 'AI 에이전트가 코드를 잘 짤 수밖에 없는 환경'을 구축했습니다. 그리고 우리는 이 환경을 하네스(Harness)라 부르며, 이를 설계하는 기술을 하네스 엔지니어링(Harness Engineering)이라고 부릅니다.

2023년 프롬프트 엔지니어링, 2025년 컨텍스트 엔지니어링의 시대를 지나 2026년 현재 가장 각광받는 하네스 엔지니어링이란 무엇인지, 개발자와 기획자가 반드시 알아야 할 핵심 개념을 정리해 보았습니다.

1. 하네스(Harness)란 무엇인가?

하네스는 원래 말에 씌우는 고삐나 안장 같은 마구를 뜻합니다. 말이 아무리 빠르고 힘이 세도 마구 없이 벌판에 풀어놓으면 제멋대로 뛰어다니듯, 제미나이나 클로드 같은 강력한 AI 에이전트도 제어 장치 없이 풀어놓으면 코드를 엉망으로 고치거나 궤도를 이탈해 버립니다.

즉, 하네스는 모델 자체를 만드는 것이 아니라 AI 에이전트를 감싸고 있는 제약 조건, 도구, 피드백 루프, 문서화 등을 모두 포함하는 전체 운영 환경을 말합니다. 구글 딥마인드의 한 엔지니어는 이를 "모델은 CPU이고, 하네스는 운영 체제(OS)다"라고 명쾌하게 비유하기도 했습니다.

2. 프롬프트 엔지니어링과의 결정적 차이점

가장 많이 헷갈리시는 부분은 *"결국 프롬프트를 줘서 행동을 제약하는 것 아니냐?"*는 것입니다. 하지만 이 둘은 본질적으로 접근 방식이 다릅니다.

• 프롬프트 엔지니어링 (무엇을 말할까): AI에게 "좋은 코드를 짜줘", "이 규칙을 지켜줘"라고 말로 부탁하는 기술입니다. 완벽한 이메일 한 통을 작성하는 법에 비유할 수 있습니다.
• 하네스 엔지니어링 (어떤 환경에서 일하게 할까): 프롬프트 지시와 첨부파일을 넘어, 일하는 사무실의 책상 배치, 업무 규칙, 보고 체계 등을 통째로 설계하는 거대한 틀입니다.

가장 중요한 하네스의 핵심 철학은 "말로 타일러서 제약하지 않고, 시스템으로 강제한다"는 것입니다. 에이전트가 실수했을 때 프롬프트를 수정해서 "다음에는 이렇게 하지 마"라고 부탁하는 것이 아니라, 아키텍처 제약이나 피드백 루프 같은 시스템을 설계하여 잘못된 행동 자체가 아예 실행되지 못하도록 구조적으로 막아버리는 것입니다.

3. 코드 상에서 하네스를 강제하는 4가지 기둥

그렇다면 실제 시스템과 코드 상에서 어떻게 에이전트를 물리적으로 통제할 수 있을까요? 하네스 엔지니어링은 4가지 기둥으로 구성됩니다.

① 컨텍스트 엔지니어링 (Context Engineering)

에이전트에게 코드 저장소에 없는 정보는 존재하지 않는 것과 같습니다. 프로젝트의 기술 스택, 빌드 명령어, 코딩 규칙 등을 기계가 읽을 수 있는 형태(Claude.md나 Agent.md)로 코드 저장소에 배치해야 합니다. 단, 오픈AI의 실패 사례처럼 1,000페이지짜리 거대한 매뉴얼 하나를 던져주면 AI가 패턴만 대충 읽고 무시해버리므로, 정보를 분리하고 '지도(주소)' 형태로 적재적소에 제공해야 합니다.

② 아키텍처 제약 (Architectural Constraints)

구현 방식은 에이전트에게 자유롭게 맡기되, 반드시 지켜야 할 규칙은 기계적으로 강제합니다. 예를 들어 에이전트가 규칙을 무시하려 해도 린터(Linter)나 CI(지속적 통합) 도구를 통해 에러를 뿜어내어 결재(Merge) 자체를 물리적으로 불가능하게 만들어 버리는 식입니다.

③ 피드백 루프 (Feedback Loops)

AI는 자신이 만든 결과물을 스스로 평가하면 무조건 잘했다고 착각하는 경향이 있습니다. 따라서 에이전트가 코드를 짜면 즉시 외부 기준으로 테스트를 돌리거나, 코드를 짜는 모델과 이를 리뷰/테스트하는 모델을 분리하여 즉각적인 검증 센서를 달아두어야 합니다.

④ 엔트로피 관리 (Entropy Management)

에이전트가 작업을 지속하면 코드 베이스에 무질서가 쌓입니다. 문서와 코드가 안 맞거나 중복 코드가 생기죠. 이를 막기 위해 마치 사무실 청소 담당자처럼 주기적으로 문서-코드 일치 여부만 검사하는 '정리 전담 에이전트'를 따로 가동해야 합니다.

4. 실무 적용을 위한 5가지 핵심 원칙

어떤 AI 도구를 쓰든 당장 적용할 수 있는 5가지 원칙입니다.

1. 모델을 바꾸지 말고 환경을 바꿔라: 랭체인(LangChain)의 실험에 따르면, 같은 모델을 사용하더라도 하네스를 개선했더니 코딩 벤치마크 점수가 52.8%에서 66.5%로 수직 상승했습니다.
2. 실패에서 시작하라: 처음부터 완벽한 시스템을 만들려 하지 말고, 매주 금요일 20분씩 에이전트의 실패 사례를 구조적으로 방지하는 장치를 하네스에 하나씩 추가하세요.
3. 적게 넣어라: 규칙이 너무 많으면 에이전트의 성능이 오히려 저하되고 비용만 증가합니다. 최소한의 규칙이 최대의 효과를 냅니다.
4. 말로 하지 말고 시스템으로 강제하라: 프롬프트는 AI가 무시할 수 있지만, 테스트 코드나 린터 같은 시스템적 제약은 절대 무시할 수 없습니다.
5. 하네스도 모델과 함께 진화한다: 모델의 성능이 좋아지면 과거의 복잡했던 다중 에이전트 하네스도 단일 에이전트 구조로 가볍게 바뀔 수 있습니다. 하네스는 계속해서 진화하는 시스템입니다.

💡 마무리하며

주요 AI 모델들(GPT, 클로드, 제미나이 등)의 성능이 상향 평준화되고, 에이전트가 데모 수준을 넘어 실제 프로덕션 환경에 투입되면서 하네스의 중요성은 그 어느 때보다 커졌습니다.

어떤 모델을 쓰느냐보다 중요한 것은, 그 강력한 모델의 힘을 우리가 원하는 방향으로 이끌어주는 '마구(하네스)'를 얼마나 잘 설계하느냐입니다. 진정한 생산성의 레버리지는 모델 자체가 아니라 모델을 둘러싼 하네스에 있다는 점을 기억하시기 바랍니다.

Claude Code Skill: 캐치테이블 빈자리 나오면 AI가 자동으로 예약해준다

이게 가능해?

캐치테이블에서 인기 오마카세 예약을 잡으려면 두 가지 방법이 있다.

1. 오픈 시간(보통 자정이나 오전)에 맞춰 새로고침 연타
2. 취소가 생기길 기다리며 수시로 확인

둘 다 사람이 직접 해야 한다. 빈자리가 언제 뜰지 모르니까 폰을 계속 들여다봐야 한다.

그래서 이걸 AI한테 맡길 수 없을까 생각했다.

결론부터 말하면 된다. Chrome MCP로 이미 로그인된 브라우저를 제어하면, 캐치테이블 빈자리 모니터링부터 예약 클릭까지 자동화할 수 있다.

어떻게 동작하나

스킬 구조는 단순하다.

사용자: "스시 오마카세 이번달 안에 2명 빈자리 잡아줘"
 ↓
STEP 1. 캐치테이블 로그인 상태 확인
 ↓
STEP 2. 검색 → 식당 페이지 탐색
 ↓
STEP 3. 날짜 선택 → 슬롯 파싱
 ↓
STEP 4. 빈자리 없으면 30초 대기 후 재확인 (폴링)
 ↓
STEP 5. 빈자리 발견 즉시 → 예약 버튼 클릭
 ↓
STEP 6. 예약 완료 화면 캡처 + 사용자 보고

핵심은 STEP 4의 폴링 루프다. 빈자리가 없으면 30초마다 페이지를 새로고침하며 슬롯 상태를 계속 확인한다. 빈자리가 뜨는 순간 즉시 예약으로 넘어간다.

실제로 써봤다

"스시 오마카세 아무데나 이번 달 안에 2명"이라고 던졌다.

스킬이 알아서:

1. 캐치테이블 홈 → 검색창에 "스시 오마카세" 입력
2. 결과 목록에서 예약 가능한 식당 필터링
3. 스시전 田鮨 페이지 진입

그리고 4월 19일 빈자리를 발견했다.

임시로 예약을 해보니 예약이 된걸 확인하였고, 테스트용도라 바로 취소를 누르긴했다...! ㅎ

기술적으로 어려웠던 부분

캐치테이블은 SPA다

일반 URL로 직접 접근하면 흰 화면만 나온다. 검색 결과 페이지, 식당 상세 페이지 전부 JS로 렌더링된다. Chrome MCP가 아니면 아예 불가능한 자동화다.

처음에 /ct/search?keyword=스시 URL로 바로 접근했더니 빈 화면이 나왔다. 홈페이지부터 진입해서 검색창을 직접 클릭하고 타이핑하는 방식으로 해결했다.

# 이 방식 ❌ — 흰 화면
navigate: https://app.catchtable.co.kr/ct/search?keyword=스시오마카세

# 이 방식 ✅ — 정상 동작
navigate: https://app.catchtable.co.kr
→ 검색창 클릭
→ "스시 오마카세" 타이핑
→ 검색 실행

API 직접 호출은 막혀 있다

캐치테이블 API(ct-api.catchtable.co.kr)를 curl로 직접 호출하면 403이 뜬다. 쿠키 기반 세션 인증인데 httpOnly라서 JS로도 읽을 수 없다.

그래서 UI 폴링 방식으로 전환했다. API를 직접 호출하는 대신 브라우저에서 날짜를 클릭하고 슬롯 버튼의 활성화 상태를 파싱한다. 속도는 조금 느리지만 로그인된 세션이 있으면 항상 동작한다.

제한사항

로그인 자동화는 하지 않는다

이 스킬은 이미 Chrome에 캐치테이블 로그인이 되어 있어야 한다. 로그인 정보(아이디/비밀번호)를 스킬에 주는 건 보안상 하지 않았다. 처음 한 번만 사람이 직접 로그인해두면 그 다음부터는 스킬이 알아서 한다.

선결제 식당은 사람이 결제 단계를 직접 진행해야 한다

빈자리를 잡고 예약 폼까지 자동으로 진입하지만, 결제 정보 입력은 스킬이 하지 않는다. 선결제 식당의 경우 "빈자리 발견, 결제가 필요합니다" 알림을 보내고 사람이 결제를 진행하도록 멈춘다.

폴링 간격 최소 30초

너무 빈번하게 요청하면 서버에 부하를 줄 수 있어서 30초 간격을 기본값으로 설정했다. 2시간이 지나면 자동으로 멈추고 계속할지 묻는다.

사용 방법

설치

mkdir -p ~/.claude/skills/catchtable-sniper
curl -o ~/.claude/skills/catchtable-sniper/SKILL.md \
  https://raw.githubusercontent.com/choihyun-1110/upstage-ai-ambassador/main/skills/catchtable-sniper/SKILL.md

준비

• Chrome에서 캐치테이블(app.catchtable.co.kr) 로그인
• Chrome MCP 연결 확인

사용 예시

"온지음 5월 10일 저녁 2인 빈자리 나오면 예약해줘"
"스시 오마카세 이번달 안에 2명 자동예약"
"https://app.catchtable.co.kr/ct/shop/mingles 토요일 4명"

JD Fit이랑 같이 쓰면

지금까지 만든 스킬 두 개가 사실 같은 철학을 공유하고 있다.

• JD Fit: 반복적인 정보 수집 + 판단을 AI에게 맡긴다
• CatchTable Sniper: 반복적인 모니터링 + 즉각 실행을 AI에게 맡긴다

사람이 해야 했던 반복 작업을 AI가 대신하고, 사람은 최종 결정만 한다. 결제 확인, 공고 지원 여부 판단 같은 것들.

앞으로 이런 방식으로 일상의 반복 작업을 하나씩 스킬로 만들어볼 계획이다.

→ GitHub: https://github.com/choihyun-1110/upstage-ai-ambassador

Upstage AI Ambassador 2기 미션2 후기: 내가 만든 스킬로 내 지원서를 분석해봤다

시작하기 전에

미션2에서 만든 JD Fit 스킬, 직접 써봤다.

대상은 내가 실제로 서류 넣은 공고. SK하이닉스 2026 상반기 신입 Talent hy-way.

원래 계획은 이거였다. "스킬이 내가 자소서에 뭘 쓸지를 미리 예측해줄 수 있을까?" 이미 서류를 쓴 상태에서 스킬 결과를 보면, 내가 강조했던 포인트랑 스킬이 추천한 포인트가 얼마나 일치하는지 확인할 수 있다.

이 공고, 왜 하이닉스인가

솔직히 말하면 반도체를 전공으로 파겠다는 생각은 없었다. 나는 전기전자공학부지만 AI, 자동화, 시스템 쪽에 더 관심이 있다.

그런데 하이닉스 공고를 보다 보니 전혀 다른 느낌의 포지션이 눈에 들어왔다. 기반기술. JD를 읽으니까 AI/DT 기반 솔루션이라는 표현이 계속 나온다. 그리고 Product Engineering은 빅데이터 분석, Test Solution 개발을 한다고 되어 있었다.

뭔가 내 경험이랑 연결될 것 같아서 넣었다.

• 1지망: Tech R&D | Product Engineering
• 2지망: 제조 | 기반기술

스킬에게 PDF를 던졌다

JD PDF 하나, 내 지원서 PDF 하나를 스킬에 넘겼다.

스킬은 먼저 Upstage Document Parse로 두 PDF에서 텍스트를 뽑아냈다. 하이닉스 JD는 이천/분당/서울 전체 직군이 한 PDF에 들어 있어서 총 25,000자가 넘었다. 지원서도 경력, 프로젝트, 학점까지 포함해서 8,000자 분량이었다.

그걸 Upstage Solar Pro에 넣었다.

결과:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏆 SK하이닉스 적합도 분석 결과
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| 직무 | 점수 | 추천 |
|------|------|------|
| 기반기술 (2지망) | 85점 | ✅ 추천 |
| Product Engineering (1지망) | 82점 | ⚠️ 조건부 추천 |
| IT | 82점 | ⚠️ 조건부 추천 |

2지망이 1지망보다 높게 나왔다

처음엔 좀 당황했다.

그런데 스킬의 분석 근거를 읽어보니 납득이 됐다.

기반기술 JD에 "AI/DT 기반의 선제적 기반기술 솔루션 제공" 이라는 문구가 있다. 이 포지션은 Defect 분석, Metrology, 소재 개발을 하면서 AI/DT 도구를 활용하는 게 핵심이다.

스킬이 내 경험과 이걸 연결했다.

✅ 매칭되는 강점 (기반기술)

• AI·DT 기반 문제 해결 경험
  → SAM 모델 LoRA fine-tuning, Dice Score 0.748 → 0.914 향상
  → JD의 "AI/DT 기반 선제적 기반기술 솔루션"과 직결

• 협업 및 시스템 통합 능력
  → AGV·로봇암·AI 비전 통합 시스템 개발
  → Defect & Metrology 팀 협업에 적용 가능

• 반도체 공정 실습 경험
  → KLayout 기반 레이아웃 설계, DRC/LVS 검증
  → 소재/장비 분야와 연결 가능

Product Engineering은 DRAM 특화 지식이 부족하다는 점을 지적했다. 맞는 말이다. 나는 DRAM을 직접 다뤄본 적이 없다.

반면 기반기술은 AI/DT 역량을 곧바로 활용할 수 있는 포지션이라 내 경험이 더 직접적으로 매핑됐다.

강조할 포인트, 내가 쓴 것과 맞나

스킬이 추천한 자소서 포인트 3가지:

Product Engineering 기준:

1. DRC/LVS 오류 해결 → 반도체 불량 분석 역량으로 연결
2. AI 모델 개발 경험 → 테스트 프로그램 개선 가능성으로 어필
3. 드론 정비 시스템 → 반도체 양산 환경의 팀워크로 연결

기반기술 기준:

1. "반도체 공정 + AI" 융합 경험 — 설계 프로젝트와 AI 모델을 같이 언급
2. 시스템 통합 능력 — AGV·로봇암 경험을 Defect 분석팀 협업으로
3. 문제 해결 프로세스 — "오류 패턴 분석 → 자동화 파이프라인" 방법론

내가 실제로 자소서에 썼던 것과 꽤 겹쳤다. 다만 스킬이 더 구체적으로 "이 경험을 이 JD 문구와 연결해라"고 짚어줬다는 점이 달랐다.

내가 그냥 "AI 모델 개발 경험 있습니다"라고 썼다면, 스킬은 "Test Solution 개발 업무에서 AI 분석 파이프라인을 기여할 수 있다"는 프레임으로 바꿔 쓰라고 조언한다.

써보고 느낀 것

좋았던 점

혼자 공고를 읽으면 "내가 맞나 안 맞나" 감으로만 판단하게 된다. 스킬은 JD 텍스트를 다 읽고 내 이력서와 단어 단위로 매핑한다. 내가 놓쳤던 키워드들을 잡아준다.

기반기술 JD에서 "AI/DT 기반 선제적 솔루션" 이라는 표현은 내가 직접 읽었을 때는 그냥 흘려봤다. 스킬이 이걸 집어내서 내 경험과 연결했다.

아쉬운 점

내가 자소서에 실제로 어떤 문장으로 썼는지는 스킬이 모른다. JD와 이력서만 비교하기 때문에, 자소서에서 어떻게 표현했는지까지 피드백받으려면 자소서 전문도 함께 넘겨야 한다.

다음 버전에서는 "JD + 이력서 + 자소서 초안"을 같이 넣으면 더 정확할 것 같다.

결과적으로

스킬이 본 순위: 기반기술 85 > Product Engineering 82

내가 선택한 순위: 1지망 Product Engineering, 2지망 기반기술

스킬의 판단이 틀렸다고 생각하지 않는다. 오히려 내가 막연하게 1지망을 설정했던 것보다 더 근거 있는 분석이었다.

그리고 결과가 나왔다.

서류 합격.

근데 지금 갑자기 드는 생각이 있다.

스킬이 2지망 기반기술을 더 높게 봤다. 나는 1지망 Product Engineering으로 넣었다. 만약 최종에서 떨어진다면...

혹시 그게 이거 때문인가?

계속 지켜봐야 알겠다.

→ 스킬 사용 방법: [미션2 포스트 링크] → GitHub: https://github.com/choihyun-1110/upstage-ai-ambassador

Powered by Upstage Solar AI

태그: #Upstage #ClaudeCode #Skill #취업 #JD분석 #SK하이닉스 #대학생 #커리어 #SolarLLM #AI앰배서더

Upstage AI Ambassador 2기 미션2: Upstage API 기반 Claude Code Skill 구축

이걸 왜 만들었나

미션1 글 마지막에 이런 말을 했었다.

미션2: 이 커리어 어드바이저의 핵심 분석 기능을 Upstage API 기반의 Skill로 고도화하기

그런데 막상 시작하려다 보니 생각이 좀 달라졌다.

커리어 어드바이저의 핵심은 결국 "나한테 맞는 정보를 찾아주는 것"이다. 그중 가장 직접적인 건 채용공고다. 공고를 찾고, 내 스펙이랑 맞는지 판단하고, 어떻게 어필할지 생각하는 일련의 과정을 AI가 대신해줄 수 있다면?

마침 기아 상반기 신입 채용이 열렸다. 기아 채용 사이트에 들어가니 IT 직군 공고만 6개다. 각각 열어보고, 내 전공이랑 맞는지 하나씩 따지다 보니 금방 30분이 지나 있었다.

그래서 만들었다. 채용 사이트 URL 하나만 던지면, 전체 공고를 알아서 다 읽고 나한테 맞는 걸 점수로 줄 세워주는 스킬을.

어떻게 동작하나

이 스킬은 Claude Code Skill 형태로 만들었다. Claude Code에 불러오면 채용공고 URL이나 PDF를 주는 것만으로 자동으로 동작한다.

전체 흐름은 이렇다:

채용 사이트 URL 입력
 ↓
Chrome MCP → 페이지 접속 + JS 렌더링까지 대기
 ↓
목록 페이지라면: 전체 공고 링크 자동 추출 → 각 공고 순차 방문
 ↓
각 JD 텍스트 수집
 ↓
Upstage Solar Pro → 사용자 프로필과 비교 분석
 ↓
적합도 점수(0-100) + 강점/약점/추천 이유 출력
 ↓
여러 공고라면 랭킹 테이블로 정리

사용자 입장에선 딱 두 단계다.

1. URL 던지기 (또는 PDF 경로)
2. 결과 받기

직접 써봤다

https://kia-autoworld.com/entry/ — 2026 상반기 기아 신입 채용 랜딩 페이지다.

이 URL 하나로 스킬을 돌렸다.

스킬이 알아서:

• IT 섹션 팝업 클릭
• 6개 공고 링크 발견
• career.kia.com에서 각 JD 상세 텍스트 수집
• Upstage Solar Pro로 내 프로필과 비교 분석

결과가 이렇게 나왔다.

🏆 채용공고 적합도 랭킹 (총 6개 분석)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| 순위 | 직무 | 점수 | 추천 |
|------|------|------|------|
| 1위  | Data Scientist | 65점 | ⚠️ 조건부 추천 |
| 2위  | Machine Learning Engineer | 65점 | ⚠️ 조건부 추천 |
| 3위  | 글로벌 CRM | 50점 | ⚠️ 조건부 |
| 4위  | IT Project Manager | 45점 | ⚠️ 조건부 |
| 5위  | Mobile Developer | 40점 | ❌ 비추천 |
| 6위  | Solution Architect (ERP FI) | 30점 | ❌ 비추천 |

🥇 최우선 추천: Data Scientist
SAM LoRA fine-tuning, 의료 AI 모델 개발 경험이 AI 역량 요건과 직결됨.
"도메인은 다르지만 데이터 패턴 인식 방법론은 동일"하다는 어필 포인트가 있음.

그리고 각 공고마다 이런 상세 분석이 붙어 나온다.

✅ 매칭되는 강점
• AI/의료영상 분야 실무 경험 및 SAM LoRA fine-tuning 프로젝트
• MCP 에이전트 시스템 구현 → 데이터 파이프라인 자동화 경험

⚠️ 부족하거나 보완이 필요한 부분
• 커넥티드카/판매 데이터 분석 경험 없음 → 자동차 도메인 사전 학습 권장
• 데이터 엔지니어링 역량 → SQL, Spark 등 기초 학습

💡 자기소개서에서 강조할 포인트
1. "SAM fine-tuning 경험 = 대규모 데이터 패턴 추출 역량"으로 재해석
2. MCP 에이전트 = 데이터 파이프라인 자동화 맥락으로 어필
3. 글로벌 전개 업무 대비 영어 활용 의지 강조

Mobile Developer랑 ERP FI는 솔직히 나랑 맞지 않는다고 바로 비추천을 줬다. 과장 없이 현실적인 분석이 나와서 오히려 신뢰가 갔다.

설계에서 제일 많이 고민한 것

"JS 렌더링 사이트를 어떻게 읽을 것인가"

기아, 삼성, 현대 같은 대기업 채용 사이트는 전부 SPA(Single Page Application)다. 일반 HTTP 요청으로 URL을 긁으면 빈 껍데기 HTML만 나온다. 콘텐츠가 JavaScript로 로딩되기 때문이다.

처음에 WebFetch로 시도했다가 이걸 깨달았다. 그래서 Chrome MCP를 사용했다. Chrome MCP는 실제 브라우저 엔진이 렌더링한 결과를 읽을 수 있어서 JS 렌더링 사이트도 문제가 없다.

# 이 방식은 안 됨 (빈 HTML)
WebFetch → career.kia.com

# 이 방식이 됨 (실제 콘텐츠)
Chrome MCP navigate → get_page_text

"Solar Pro 프롬프트 설계"

단순히 "이 JD랑 이 프로필 비교해줘"로는 결과가 들쭉날쭉했다. 점수 기준도 없고, 출력 형식도 매번 달랐다.

그래서 분석 구조를 명확히 지정했다.

점수 기준: 필수 요건 충족 여부(40%) + 우대 조건 일치도(30%) + 커리어 방향성(30%)
출력: 점수 / 강점 bullet / 약점+보완방법 bullet / 추천여부+이유 / 강조할 포인트 3가지 / 키워드

이렇게 하니 6개 공고의 결과물이 일관된 형식으로 나와서 랭킹 테이블을 만들기도 쉬웠다.

만들면서 힘들었던 것

kia-autoworld.com의 모달 방식

랜딩 페이지의 "자세히 보기" 버튼들이 전부 href="#"이었다. 클릭하면 JS 모달이 뜨고, 거기서 각 직무 링크가 나오는 구조다.

처음엔 DOM에서 링크를 바로 추출하려고 했는데 당연히 href="#"만 보였다. 결국 JavaScript로 버튼을 직접 클릭하고, 모달이 열린 뒤 그 안의 링크를 다시 추출하는 방식으로 해결했다.

// 직접 클릭으로 모달 열기
document.querySelectorAll('.item-link.pop_view')[1].click();

// 모달 안에서 링크 추출
[...document.querySelectorAll('a[href*="applyView"]')]
  .map(a => a.pathname)

career.kia.com 무한스크롤

채용 목록 페이지가 10개씩 끊어서 로딩되는 방식이었다. 전체 44건 중 IT 신입은 7페이지에 흩어져 있었다. 페이지 전체를 다 긁으려고 스크롤 이벤트도 트리거해보고 여러 시도를 했는데, 결국 페이지 전역 함수 getList(page)를 발견해서 직접 호출하는 방식으로 전체 데이터를 불러왔다.

// 페이지에 선언된 전역 함수로 전체 페이지 로드
for (let p = 2; p <= listTotal; p++) {
  getList(p);
}

이런 걸 찾아내는 과정이 생각보다 재밌었다. 사이트마다 방식이 다 달라서 매번 탐정처럼 파고들어야 한다.

사용 방법

1. 설치

git clone https://github.com/choihyun-1110/upstage-ai-ambassador.git
mkdir -p ~/.claude/skills/jd-fit
cp skills/jd-fit/SKILL.md ~/.claude/skills/jd-fit/SKILL.md

2. API 키 설정

export UPSTAGE_API_KEY=your_key_here

3. 사용

Claude Code를 켜고 채용 사이트 URL을 던지면 된다.

# 목록 페이지 → 전체 공고 자동 분석
https://kia-autoworld.com/entry/  분석해줘

# 개별 공고 URL
https://career.kia.com/apply/applyView.kc?recuYy=2026&recuType=N1&recuCls=29

# PDF JD 파일
/Downloads/삼성전자_공고.pdf 분석해줘

처음 사용 시 프로필(전공, 기술스택, 커리어 목표, 경력)을 한 번 입력하면 ~/.claude/jd-fit-profile.json에 저장되어 다음부터는 바로 분석해준다.

왜 Claude Code Skill인가

n8n 워크플로우와 비교했을 때 Claude Code Skill의 장점이 뚜렷하게 있었다.

특히 "JS 렌더링 사이트 자동 크롤링"은 n8n으로는 구현이 어렵거나 복잡한 우회가 필요한데, Claude Code + Chrome MCP 조합이면 자연스럽게 해결된다.

다음 단계

미션2 결과물을 실제로 써보면서 드는 생각이 있다.

지금은 채용공고 분석에 집중했는데, 사실 이 스킬의 더 큰 가능성은 "내가 지금 어디에 집중해야 하는가"를 알려주는 것에 있다. 단순히 "이 공고에 지원해도 되냐"를 넘어서, 6개월 뒤 이 공고에 지원하려면 지금 뭘 준비해야 하는지를 알려주는 로드맵 기능까지 붙이면 더 실용적인 도구가 될 것 같다.

미션3에서 이걸 커리어 어드바이저 전체 플로우와 합칠 계획이다.

→ [GitHub 링크] https://github.com/choihyun-1110/upstage-ai-ambassador

Powered by Upstage Solar AI

태그: #Upstage #ClaudeCode #Skill #취업 #JD분석 #대학생 #커리어 #SolarLLM #AI앰배서더

요즘 LLM 양자화 논문을 꽤 읽고 있다.

GPTQ, AWQ, SmoothQuant, QDrop, AdaRound, BRECQ, DuQuant... 주요 논문들을 읽으면서 공통적으로 드는 생각이 있었다. 양자화는 결국 "얼마나 적은 비트로, 얼마나 원래에 가깝게" 라는 트레이드오프 싸움이라는 것.

그러다가 최근에 X(구 트위터)에서 난리난 논문 하나를 봤다.

TurboQuant. ICLR 2026, Google Research.

조회수 1900만, 그리고 메모리 주가 하락

솔직히 처음엔 밈인 줄 알았다.

이 논문 관련 포스트 하나가 X에서 조회수 1900만을 찍었는데, 관련 영상이나 글 댓글 분위기가 심상치 않았다. "메모리 필요 없어지는 거 아니야?" 류의 반응들. 그리고 실제로 SK하이닉스 -6%, 삼성전자 -5%, 마이크론 -3% 주가가 흔들렸다.

...이게 말이 되나?

논문 하나 나왔다고 메모리 반도체 기업 주가가 내려가는 게? 그것도 양자화 논문으로?

궁금해서 논문을 직접 읽어봤다.

TurboQuant가 뭘 하는 건지

한 줄 요약: LLM 추론할 때 쌓이는 KV 캐시를 3비트까지 압축한다.

KV 캐시는 모델이 이미 처리한 토큰들의 정보를 저장해두는 공간이다. 대화가 길어질수록 이게 폭발적으로 커진다. 70B 모델을 긴 컨텍스트로 돌리면 KV 캐시만 수십 GB가 필요할 수 있다.

TurboQuant는 이걸 줄이는 방법이다. 핵심 아이디어는 두 가지다.

1. 압축 전에 벡터를 먼저 회전시킨다 (PolarQuant)

KV 벡터를 직교 좌표계(X, Y, Z)가 아닌 극좌표계(반지름과 각도)로 변환한다. 구글 블로그의 비유가 딱 맞다 — "동쪽 3블록, 북쪽 4블록"을 "37도 방향으로 5블록"으로 바꾸는 것. 반지름은 데이터의 강도, 각도는 데이터의 방향/의미를 담는다. 이렇게 변환하면 각도들의 분포가 예측 가능한 형태로 고정되어서, 최적의 압축 기준(codebook)을 확률 이론으로 미리 계산해둘 수 있다. 모델마다 별도 학습도, 캘리브레이션 데이터도 필요 없고, 압축 기준이 고정되어 있으니 메타데이터 오버헤드도 사라진다.

2. 1비트로 내적 편향을 보정한다 (QJL)

MSE를 최소화하는 압축은 attention 점수 계산(내적)에서 미묘한 편향이 생긴다. QJL(Quantized Johnson-Lindenstrauss)이 잔여 오차를 1비트만 추가해서 보정한다. 이 덕분에 attention 점수의 정확도를 유지하면서도 실제 연산에 쓰이는 "핫한" KV 캐시를 실시간으로 압축할 수 있다.

결과는 인상적이다. 메모리 6배 이상 절감, H100 기준 attention 연산 최대 8배 빠름. 파인튜닝 없이.

참고로 엔비디아도 비슷한 걸 냈다

사실 ICLR 2026에 KV 캐시 압축 논문이 TurboQuant만 있는 게 아니다.

엔비디아도 KVTC(KV Cache Transform Coding)라는 논문을 같은 학회에 냈다. JPEG 같은 미디어 압축 방식에서 아이디어를 빌려와 PCA로 KV 캐시의 중복을 제거하는 방식인데, 압축률이 무려 20배다. TurboQuant의 6배보다 훨씬 높다.

다만 KVTC는 모델별로 캘리브레이션 데이터가 필요하다. TurboQuant는 그게 필요 없다는 게 차이. 어떤 게 더 낫냐기보다는 상황에 따라 선택이 갈리는 구조다.

주가 하락 뉴스가 "TurboQuant" 하나만 다룬 건데, 사실 엔비디아 KVTC도 같이 나왔다는 걸 아는 사람은 별로 없었던 것 같다.

근데 자세히 읽어보니...

이게 진짜 혁명적인 기술인가? 하고 논문 레퍼런스를 따라가다 보니 흥미로운 게 보였다.

Random rotation을 써서 양자화하는 건 TurboQuant가 처음이 아니다.

RaBitQ, QuaRot, QJL 모두 비슷한 아이디어를 이미 쓰고 있었다. 실제로 RaBitQ 저자들이 OpenReview에 공개적으로 이의를 제기했다. "우리도 random rotation 쓰는데, 논문에서 이 점을 누락하고 기여를 과장한 것 아니냐"는 취지로.

TurboQuant의 실제 기여는 이 rotation과 수학적으로 최적임을 증명한 Lloyd-Max codebook의 조합, 그리고 theoretical lower bound 증명이다. 기술 자체가 완전히 새로운 게 아니라, 기존 아이디어들을 이론적으로 탄탄하게 정립하고 시스템으로 완성한 것에 가깝다.

커뮤니티 구현 결과에서도 QJL 보정이 이론과 달리 실제로는 오히려 분산을 키워서 정확도를 떨어뜨린다는 보고도 나왔다. 아직 논쟁 중인 부분이 있다는 뜻.

그래서 메모리 주가가 왜 떨어진 거야

"KV 캐시를 6배 줄이면 메모리 필요량이 줄어드니까 메모리 반도체 회사에 악재다."

이 논리 자체는 맞다. 근데 이걸로 삼성, 하이닉스, 마이크론 주가가 저만큼 흔들렸다면... 그 반응이 좀 과했다는 생각이 든다.

이유가 몇 가지 있다.

첫째, KV 캐시 압축은 이미 있던 기술이다. KIVI, PolarQuant 등 기존 방법들도 비슷한 방향이었다. TurboQuant가 더 나은 방법이긴 하지만, 갑자기 없던 개념이 생긴 게 아니다. 엔비디아 KVTC도 작년 11월에 이미 나왔던 논문이다.

둘째, 메모리가 남으면 더 쓴다. KV 캐시를 압축해서 메모리 공간이 생겼다고 메모리를 덜 사는 게 아니다. 남는 여력으로 동시 사용자를 더 많이 처리하고, 더 긴 컨텍스트를 쓰고, 더 큰 모델을 돌린다. AI가 더 많이 쓰일수록 메모리 수요는 결국 다른 형태로 다시 늘어난다.

셋째, 아직 공식 구현이 없다. Google 공식 코드는 2026년 Q2 예정이고, vLLM·SGLang 통합도 진행 중이다. 실제 서빙에 쓰이려면 시간이 더 필요하다.

논문 두 개가 주식 시장을 흔들 만큼 시장의 기대가 컸다는 뜻이기도 하지만, 그 기대 자체에 거품이 좀 있는 게 아닐까 싶기도 하다.

정리하자면

시장이 이 기술을 "메모리 수요가 줄어든다"로 읽은 게 틀렸다고 생각한다.

맞는 해석은 이쪽이다. 온디바이스 AI와 클라우드 AI가 더 잘 된다.

스마트폰이나 노트북에서 지금까지 메모리 때문에 돌리지 못했던 모델을 돌릴 수 있게 되고, 클라우드에서는 같은 GPU로 더 많은 사용자를 서빙하거나 더 긴 컨텍스트를 처리할 수 있게 된다. AI 자체의 활용 범위가 넓어지는 것이지, 메모리를 덜 쓰게 되는 게 아니다.

반도체 주가 하락은 틀린 독해에서 나온 과잉 반응이었고, 기술 자체는 진짜다. 다만 기존에 없던 개념이 아닌 이론적 정립에 가깝고, 공식 구현도 아직 없다. 올해 안에 vLLM 같은 서빙 프레임워크에 통합되고 나서야 실제 임팩트를 제대로 평가할 수 있을 것 같다.

참고

• TurboQuant 논문 (ICLR 2026)
• Google Research 블로그
• Nvidia KVTC 논문 (ICLR 2026)

태그: #TurboQuant #LLM #양자화 #KVCache #ICLR2026 #AI #반도체

Upstage AI Ambassador 2기 미션1: 노코드 기반 워크플로우 SNS 공유

이걸 왜 만들었나

취업을 준비하거나 커리어를 쌓으려는 대학생들에게 가장 큰 장벽은 무엇일까? 의외로 '기회의 부족'이 아니다. 진짜 문제는 '나에게 맞는 정보의 부재'다.

링커리어만 들어가 봐도 공모전이 수백 개고, 각종 대외활동과 숨은 지원금 같은 알짜배기 정보들이 쏟아진다. 하지만 정작 내 주변을 보면 이런 혜택을 100% 누리는 사람은 드물다. 수많은 정보 속에서 '지금의 나에게 필요한 것'만 골라내는 과정 자체가 생각보다 피곤하고 접근하기 어렵기 때문이다.

그래서 발품을 팔아 좋은 대외활동을 쏙쏙 골라 하는 친구들을 보면 다들 꼭 이렇게 묻는다. 🗣️ "야, 넌 그런 거 대체 어디서 찾아서 해?"

사실 필자도 주변에서 이 질문을 꽤나 자주 듣는 편이다. 그때마다 내 지인들을 비롯해, 정보의 홍수 속에서 길을 잃은 대학생들을 도와줄 수 있는 프로덕트가 있으면 좋겠다고 생각했다.

그래서 만들었다. 내 이력서나 포트폴리오(PDF) 한 장만 올리면, AI가 나를 분석하고 당장 실행할 수 있는 '맞춤 커리어 액션'을 이메일로 꽂아주는 서비스를.

어떻게 동작하나

전체 구조는 이렇다.

흐름을 텍스트로 정리하면:

이력서/자소서/포트폴리오 PDF 업로드
    ↓
Upstage Document Parse → 텍스트 추출
    ↓
Upstage Solar LLM → 커리어 분석
    (전공, 희망진로, 강점, 성장포인트 추출)
    ↓
맞춤 데이터 수집 (Google News RSS, HackerNews)
    ↓
Solar LLM → 개인화된 액션 리포트 생성
    ↓
Gmail로 이메일 발송

사용자 입장에선 딱 세 단계다.

1. 이름 + 이메일 + PDF 업로드
2. 분석 결과 확인
3. 이메일 수신

직접 써봤다

나는 실제로 지원한 이력서 PDF를 그대로 넣어봤다.

결과가 이런 이메일로 왔다.

단순 뉴스 요약이 아니라, "왜 나한테 이게 중요한지"를 같이 써준다는 게 핵심이다.

설계에서 제일 많이 고민한 것

"없는 정보를 만들지 않게 하는 것"

LLM한테 커리어 리포트를 써달라고 하면, 없는 공모전이나 채용 공고를 그냥 만들어낸다. 그래서 실제 RSS 데이터를 먼저 수집하고, 그 데이터만 써서 리포트를 작성하도록 강제했다.

프롬프트에 이 한 줄을 넣은 것만으로 결과 품질이 확 달라졌다.

⚠️ 반드시 아래 제공된 실제 데이터만 사용하세요. 없는 정보는 절대 만들지 마세요.

"분석 결과를 구조화하는 것"

Solar LLM이 커리어를 분석할 때 자유롭게 쓰면 결과가 매번 달라서 다음 단계에서 쓰기가 어려웠다. JSON 형식으로 출력하게 고정하고, 키워드를 한/영 모두 뽑게 설계했다. 이 키워드가 이후 맞춤 데이터 수집의 검색어가 된다.

{
  "major": "전공 또는 전문 분야",
  "career_goal": "희망 진로",
  "keywords_en": ["영어키워드1", "영어키워드2"],
  "keywords_kr": ["한국어1", "한국어2"],
  "summary": "이 사람을 한 줄로 요약",
  "career_analysis": "3-4문장 분석. 반드시 '당신은'으로 시작",
  "strengths": ["강점1", "강점2"],
  "growth_areas": ["성장 포인트1", "성장 포인트2"]
}

만들면서 힘들었던 것

Supabase 임베딩 연동

Upstage Embeddings로 4096차원 벡터를 만들고 Supabase pgvector에 저장하는 부분이 생각보다 까다로웠다. n8n에서 직접 지원하는 노드가 없어서 HTTP Request 노드로 직접 API 호출을 구성해야 했다. 요청 바디 형식이 조금만 달라도 에러가 났다.

RSS 데이터 품질

Google News RSS는 편리하지만 노이즈가 많다. "링커리어 공모전"으로 검색해도 관련 없는 기사가 섞인다. Solar LLM한테 "제공된 실제 데이터만 쓰라"고 강제하는 프롬프트가 이 문제를 많이 잡아줬다.

n8n 병렬 처리

프로필 저장 / 임베딩 / 데이터 수집을 동시에 실행하고 싶었는데, n8n에서 병렬 분기 후 합치는 게 생각보다 제약이 있었다. 결국 데이터 수집 흐름을 메인으로 빼고, 저장과 임베딩은 분기 후 각자 흘러가게 구성했다.

코드와 워크플로우

전체 n8n 워크플로우와 설치 방법은 GitHub에 정리해두었습니다.

→ [GitHub 링크]
https://github.com/choihyun-1110/upstage-ai-ambassador

워크플로우 파일을 import한 뒤 크레덴셜만 등록하면 바로 실행할 수 있습니다.

다음 단계

이건 이번 '미션1'을 통해 만들어낸 첫 결과물이다. 솔직히 말하자면 아직 초기 단계의 노코드 기반이다 보니, 실제 성능 면에서는 내 기대치에 못 미치는 아쉬운 부분들도 꽤 보인다.

하지만 여기서 끝이 아니다. 앞으로의 미션들을 거치며 부족한 점을 보완하고, 다음 두 가지 스텝을 통해 계속해서 디벨롭할 계획이다.

• 미션2: 이 커리어 어드바이저의 핵심 분석 기능을 Upstage API 기반의 Skill로 고도화하기
• 미션3: 단순 노코드 자동화에서 한 단계 더 끌어올려, 완성도 있는 최종 프로젝트로 발전시키기

내 최종 목표는 명확하다. 취업을 고민하는 대학생이라면 누구나 실전에서 유용하게 쓸 수 있는 도구를 만드는 것. 지금은 다소 투박할지 몰라도, 하나씩 차근차근 레벨업해 나가는 과정을 계속 기록해 보려 한다.

Powered by Upstage Solar AI

태그: #Upstage #n8n #노코드 #AI #커리어 #대학생 #취업 #SolarLLM

솔직히 말하면, 지원할 때 붙을 거라고 확신하지 못했다. 잠깐 붙은 썰을 풀자면...

Upstage가 어떤 회사인지는 알고 있었다. Solar LLM, Document Parse... Meta LLaMA 과정을 하면서 Upstage API를 처음 써봤고, "이거 진짜 쓸만하다"는 인상을 받았다. 그래서 앰배서더 모집 공고를 봤을 때 바로 지원했다.

서류 항목이 네 가지였는데, 1번 지원 동기와 평소 AI 관련 관심분야, 2번 Upstage AI 활동 계획, 3번 관심 기술 분야 및 경험, 그리고 대망의 4번(선택) 활동 커뮤니티 또는 동아리.

나는 AI 관련 학회나 동아리에 소속되어 있지 않아서.. 해커톤을 진행하는 이번 앰배서더 같은 경우 차질이 생길 거라는 추측에 서류가 떨어질 수도 있겠다고 생각을 했다.. 그래서 서류 제출할 때 같이 낸 프로젝트도 내가 만든 버전 중 가장 괜찮은 걸 골라서 영상 편집까지 직접 해서 냈고... 어찌저찌 면접까지 갔었다.

면접 OT에서 교육팀 여진님 말씀을 잘 새겨들었는데 해커톤이 메인인 걸로 이해했고, 어떻게 하면 잘 개최할 수 있을지 머리를 엄청 굴렸다. 나름 연세대 최고의 (노는) 동아리 중 하나인 RRC 중앙 레크리에이션 동아리 2년차에 임원진도 했던 터라, 기획 자체는 자신 있었고 사람 마음을 어떻게 움직이는지도 알고 있었다.

그래서 면접 전에 에브리타임, 지인들, 카톡방을 다 돌려가며 "해커톤 기획 수요조사" 를 직접 돌렸다. 면접 때 이 얘기를 드리니 좋게 보셨는지, 동아리 소속이 없었음에도 뽑아주셨다. 정말 감사합니다 ㅜㅜ!!! 제가 지금까지는 좀 바빴지만 앞으로는 정말 매주 최소 1개 이상의 블로그는 꾸준히 올리겠습니다 ㅠㅠ

암튼 해커톤 기획안 정말 열심히 썼다. 설문조사를 바탕으로... 아래는 증거물.. 도대체 기획안 몇 번을 갈아엎은 거지...?

그리고 합격했다. 전국에서 총 17인 중 한 명으로.

OT 썰

여진님(업스테이지 교육팀)이 앰배서더를 반겨주시겠다고~~ 굿즈도 엄청 많이 준비해주시고, 진짜 레전드 김밥 치킨 도시락까지 준비해주셨다.

여진님이 준비해주신 굿즈들

레전드 김밥

여기서 나의 RRC 짬바가 발동했다. OT에서 준비해주신 게임들 척척 맞춰서 우리 팀이 가볍게 1등 🏆 나만 추가로 무신사랑 업스테이지가 콜라보한 셔츠도 받았다 ㅎㅎ (물론 아직 안 입어봄. 카페 갈 때 한번 입어봐야겠음)

내가 게임 잘해서 탄 셔츠

끝나고는 저녁으로 피자 + 치킨으로 사람들끼리 네트워킹할 시간, 장소, 음식까지 마련해주셨다...!

네트워킹 피자

업스테이지 대표님이랑 사진도 찍음 ㅎ

Upstage AI Ambassador가 뭔데?

한 줄로 정리하면 이렇다.

Upstage의 기술을 실제로 써보고, 그 경험을 콘텐츠로 풀어내는 사람들.

단순히 홍보성 게시물을 올리는 게 아니다. 직접 API를 쓰고, 프로젝트를 만들고, 해커톤도 열고, 그 과정을 SNS에 기록하는 구조다.

혜택도 생각보다 실질적이다.

• Upstage API 크레딧 $300 (활동 시작 즉시 지급, 6월 말까지 사용 가능)
• 활동 종료 후 추가 $300 지급 예정
• 공식 수료증 + Ambassador 인증 뱃지
• Upstage 실무자 멘토링 연결
• 타 앰배서더 네트워킹

대학생 입장에서 API 크레딧 $600은 진짜 큰 혜택이다. 아이디어가 있어도 비용 때문에 못 써보는 게 많은데, 이건 그 장벽을 없애준다.

왜 지원했나

취업 고민이 많다.

전기전자공학 전공인데, AI가 너무 빠르게 변하고 있어서 "나는 지금 제대로 된 방향으로 가고 있나?" 하는 생각이 자꾸 든다. 강의 듣고 과제 하는 것만으론 뭔가 부족한 것 같고, 실제로 뭔가를 만들어봐야 한다는 건 알겠는데 그게 쉽지가 않다.

Upstage 앰배서더는 그 고민에 대한 내 나름의 답이었다.

• 실제 AI API를 써서 뭔가를 만들어야 하고
• 그 과정을 글로 정리해야 하고
• 그게 자연스럽게 포트폴리오가 된다

"강제성이 있는 성장 환경" 이 나한텐 필요했다.

앞으로 해야 할 것들

활동 기간은 약 3개월. 미션은 크게 세 파트다.

미션 1 (~ 3월 31일): No Code 자동화 워크플로우 n8n 같은 노코드 툴로 Upstage API를 연결한 자동화 워크플로우를 만들고 SNS에 공유한다.

미션 2-3 (4월): Upstage API 기반 Skill 만들기 Claude Code 같은 AI 도구에서 쓸 수 있는 Skill을 Upstage API로 개발한다.

미션 4-5 (5월): 프로젝트 만들기 + 오프라인 발표 노코드든 바이브코딩이든 방법은 자유. Upstage API 기반 프로젝트를 만들고 오프라인에서 발표까지 한다.

나는 이 세 미션을 하나의 흐름으로 연결할 계획이다.

"취업 고민이 많은 대학생을 위한 AI 커리어 어드바이저"

n8n으로 기초를 만들고 → Skill로 성능을 높이고 → 최종 프로젝트로 완성하는 것. n8n 미션은 거의 다 만들었고, 다음 글에서 바로 공유할 예정이다.

마무리

합격 통보를 받았을 때 솔직히 좀 설렜다.

Meta LLaMA 과정 때 Upstage API를 처음 써보면서 "이 혜택을 그냥 흘려보내기 아깝다"고 느꼈던 것처럼, 이번엔 크레딧이랑 기회를 제대로 활용해볼 생각이다.

뭔가를 만들고, 기록하고, 공유하는 3개월이 될 것 같다.

다음 글: n8n으로 AI 커리어 어드바이저 만들기 — PDF 한 장으로 나만의 커리어 코치를

지민이는 여러 크기의 정사각형 돗자리를 가지고 공원에 왔다. 공원은 2차원 배열 형태로 주어지고, • 사람이 앉아 있는 자리 → 알파벳 • 빈 자리 → "-1"

로 표현된다.

지민이는 사람이 앉아 있지 않은 자리("-1")로만 이루어진 k×k 정사각형 영역에만 돗자리를 깔 수 있다.

mats에는 지민이가 가지고 있는 돗자리 한 변의 길이들이 들어 있고, 이 중에서 공원에 실제로 깔 수 있는 가장 큰 정사각형의 한 변 길이를 구하는 문제다.

만약 어떤 돗자리도 깔 수 없다면 -1을 반환한다.

⸻

아이디어

이 문제는 전형적인 브루트포스 유형처럼 보인다.

우선 mats를 내림차순 정렬해서 가장 큰 k부터 검사한다. 왜냐하면 조건을 만족하는 순간 바로 return k 하면 되기 때문이다.

그 다음, 1. 공원의 모든 좌표 (i, j)를 시작점으로 잡고 2. 해당 위치에서 k×k 정사각형이 범위를 벗어나지 않는지 확인한 뒤 3. 내부가 전부 "-1"인지 검사한다.

조건을 만족하는 순간 바로 return k.

⸻

시간 복잡도 계산

최악의 경우를 계산해보면: • mats 최대 10개 • park 최대 50 × 50 → 시작 좌표 2500개 • 각 위치마다 최대 20 × 20 검사 → 400

따라서 대략

10 × 2500 × 400 = 10,000,000

천만 정도 연산이면 파이썬에서도 충분히 가능하다. 그래서 굳이 DP나 누적합까지 갈 문제는 아니라고 판단했다.

⸻

중요한 포인트 (조기 탈출)

시간 복잡도가 빡빡한 편이기 때문에 조기 탈출이 핵심이다.

k×k 내부를 검사하다가 • 하나라도 "-1"이 아닌 값이 나오면 • 즉시 break

그리고 이때 중요한 건 가로(b 루프)만 끊는 게 아니라 세로(a 루프까지 끊어줘야 한다는 점이다.

이미 실패가 확정된 상태에서 계속 검사하면 불필요한 연산이 많이 발생한다.

⸻

그래서 작성한 코드는 다음과 같다.

def solution(mats, park):
    H = len(park)
    W = len(park[0])
    mats = sorted(mats, reverse=True)  # 내림차순

    for k in mats:
        for i in range(H):
            for j in range(W):
                if i + k > H or j + k > W:
                    continue

                flag = True
                for a in range(i, i + k):
                    for b in range(j, j + k):
                        if park[a][b] != "-1":
                            flag = False
                            break
                    if not flag:
                        break

                if flag:
                    return k

    return -1

⸻

마무리 • 가장 큰 k부터 검사 • 조건 만족 시 즉시 return • 조기 탈출로 불필요한 반복 제거

전형적인 브루트포스지만, 정렬 + 범위 체크 + 이중 break 이 세 가지가 깔끔하게 들어가면 충분히 통과 가능한 문제였다.

민수는 다양한 지폐를 수집한다. 지폐마다 크기가 달라 지갑에 넣기 위해 여러 번 접어야 한다.

접는 규칙은 다음과 같다: 1. 항상 긴 변을 반으로 접는다 2. 접기 전 길이가 홀수라면, 접은 뒤 소수점 이하는 버린다 3. 접힌 지폐를 그대로 또는 90도 회전해서 지갑에 넣을 수 있으면 종료

지갑의 크기 wallet = [w, h] 지폐의 크기 bill = [w, h]

지갑에 넣기 위해 최소 몇 번 접어야 하는지 구하는 문제다.

⸻

이 문제는 사실 세 가지 포인트만 이해하면 끝난다.

1. 항상 긴 변을 접는다

즉, 매 단계에서 큰 쪽을 // 2 하면 된다.

⸻

2. 90도 회전이 가능하다

이 조건 때문에 사고를 단순화할 수 있다.

회전이 가능하다는 것은 결국 작은 변끼리, 큰 변끼리 비교하면 된다는 뜻이다.

그래서 두 리스트를 정렬해두면:

wallet = sorted(wallet)
bill = sorted(bill)

이렇게 놓고,

    •    bill[0] <= wallet[0]
    •    bill[1] <= wallet[1]

이 둘을 동시에 만족하면 종료다.

⸻

3. 둘 중 하나라도 크면 계속 접어야 한다

그래서 while 조건은 다음처럼 된다:

while wallet[0] < bill[0] or wallet[1] < bill[1]:

둘 중 하나라도 지갑보다 크면 더 접어야 한다.

⸻

우당탕탕 첫 번째 풀이

def solution(wallet, bill):
    answer = 0
    wallet = sorted(wallet)
    bill = sorted(bill)

    while (wallet[0] < bill[0]) or (wallet[1] < bill[1]):
        bill[1] = bill[1] // 2
        bill = sorted(bill)
        answer += 1

    return answer

동작 방식 • 매 반복마다 긴 변(bill[1])을 반으로 줄인다. • 다시 정렬해서 긴/짧은 변 관계를 유지한다. • 둘 다 지갑보다 작아질 때까지 반복한다.

구현은 단순하고 직관적이다.

⸻

추가 최적화 — sort 제거

생각해보니 원소는 2개뿐이다.

굳이 매번 sorted()를 호출할 필요가 없다. 긴 변을 줄인 뒤, 필요하면 swap만 해주면 된다.

def solution(wallet, bill):
    w0, w1 = sorted(wallet)
    b0, b1 = sorted(bill)

    ans = 0
    while b0 > w0 or b1 > w1:
        b1 //= 2          # 항상 큰 변을 반으로
        if b0 > b1:       # 정렬 대신 swap
            b0, b1 = b1, b0
        ans += 1

    return ans

차이점 • sorted() 호출 제거 • 상수 시간 swap으로 대체 • 로직은 동일

엄청난 시간복잡도 차이는 없지만, 불필요한 연산을 제거한 더 깔끔한 구현이다. 막힘없이 푼 문제라 블로그에 안쓰려 했는데, 답을 맞추고 나서 추가 최적화를 하면서 sort에 치중된 내 사고를 고칠 수 있는 계기가 된듯해서 나름 뿌듯

이 문제를 처음 봤을 때 가장 먼저 든 생각은 “시작 요일(startday)을 어떻게 처리해야 하지?” 였다.

그래서 처음에는 규칙을 일반화하려고 하기보다는, 아이패드에 직접 요일을 하나씩 써가며 • startday = 1일 때 • startday = 2일 때 • startday = 3일 때 …

를 하나하나 따져보는, 소위 말하는 노가다(?) 방식으로 접근했다.

규칙을 찾으려고 하면 찾을 수도 있었겠지만, 그 당시에는 “괜히 머리 써서 깔끔해 보이는 효과만 생기는 거 아닐까?” 라는 생각이 더 컸다.

⸻

하드코딩 풀이: startday별로 직접 슬라이싱

그래서 선택한 방법은 꽤 직관적이었다.

startday마다 if 분기를 걸고, 평일에 해당하는 인덱스만 직접 잘라내자

if startday == 1:
    i[:] = i[0:5]
elif startday == 2:
    i[:] = i[0:4] + i[-1:]

이 방식은 생각보다 빠르게 형태가 잡혔다.

⸻

다만 구현하면서 바로 한 번 막혔다.

for i in timelogs:
    i = i[0:5]

이렇게 하면 당연히 리스트가 바뀔 줄 알았는데, 막상 돌려보니 timelogs가 전혀 변하지 않았다.

오랜만에 파이썬으로 바닥부터 구현하다 보니 감이 좀 떨어진 상태였고, 이때 다시 한 번 깨달았다.

i = ... 

->> 리스트 자체를 바꾸는 게 아니라, 변수 i가 다른 객체를 가리키게 만드는 것뿐이라는 걸.

그래서 아래처럼 슬라이스 대입(in-place 수정)으로 고쳤다.

i[:] = i[0:5]

이제서야 의도한 대로 timelogs 내부 값이 실제로 변경되었다.

⸻

또 하나 놓쳤던 부분은 반복문 구조였다.

처음에는 “지각한 날이 나오면 break” 라는 생각으로 코드를 짰는데,

그렇게만 두면 break가 발생해도 바깥에서 그대로 카운트가 증가해버린다.

그래서 최종적으로는 이 사람이 끝까지 통과했는지를 나타내는 flag 변수를 두는 방식으로 정리했다.

ok = True
for ...
    if 지각:
        ok = False
        break

if ok:
    answer += 1

⸻

그래서 결과적으로 다음 코드로 어찌어찌 테스트 코드는 통과했다.

def to_minites(t):
    return (t //100)*60 + (t%100)  
def solution(schedules, timelogs, startday):
    answer = 0

    # schedules는 사람 수
    # timelogs는 [i]번째마다 출근퇴근 출근 퇴근
    if startday ==1:
        for i in timelogs:
            i[:] = i[0:5]
    elif startday ==2:
        for i in timelogs:
            i[:] = i[0:4] + i[-1:]
    elif startday ==3:
        for i in timelogs:
            i[:] = i[0:3] + i[-2:]
    elif startday ==4:
        for i in timelogs:
            i[:] = i[0:2] + i[-3:]
    elif startday ==5:
        for i in timelogs:
            i[:] = i[0:1] + i[-4:]
    elif startday ==6:
        for i in timelogs:
            i[:] = i[2:]
    elif startday ==7:
        for i in timelogs:
            i[:] = i[1:-1]
    for i in range(len(schedules)):
        ok = True
        for j in range(len(timelogs[i])):
            if to_minites(timelogs[i][j]) - to_minites(schedules[i]) >10:
                ok = False
                break
        if ok == True:
            answer +=1
    return answer

다만 풀고 나서 코드를 다시 보니 startday 분기가 많아서 전체적으로 좀 난잡해 보였고, 원본 데이터를 직접 잘라 쓰는 방식도 썩 깔끔하다는 느낌은 아니었다.

그래도 이런 시행착오를 한 번 겪어봤으니, 다음에 비슷한 문제를 만나면 훨씬 정리된 코드로 풀 수 있을 것 같다. 다음 문제에서는 분기부터 치지 말고, 한 번 더 구조를 생각해보는 사람이 되어보자.

든든한 우리 팀원분들...

Meta LLaMA 과정에서 수상도 하고 기술적으로도 많이 배웠다. 그런데 개인적으로 가장 반가웠던 건 따로 있었다. Upstage API를 무료 크레딧으로 쓸 수 있게 된 것이었다.

방학이었고, "이 혜택을 그냥 흘려보내긴 아깝다"는 생각이 들었다. 그래서 평소 메모장에 적어두던 고민들을 다시 꺼냈다.

메모장에 적어두던 고민들

과제는 많은데, 포트폴리오는 늘 귀찮다

메모장에 있던 질문은 단순했다.

"교내에서 한 과제나 프로젝트를, 나중에 취업할 때 쓸 포트폴리오 형태로 자동으로 바꿀 수는 없을까?"

교내 과제·프로젝트 레포트 자체는 이미 잘 만들어져 있다. 교수님 검수를 거치다 보니 과정이 자세하고, 실험 결과·수치도 빠짐없고, 코드 설명도 나름 친절하다. 문제는 그 다음이다. 이걸 Notion에 옮기거나, 블로그에 정리하거나, 다른 사람에게 공유하려고 할 때마다 같은 생각이 든다.

"이걸 그대로 올리기엔… 너무 과제 레포트 같다."

PDF는 제출하기엔 좋지만, 보여주기엔 별로다

과제 PDF는 제출용으로는 충분하다. 하지만 누군가에게 보여주기엔 불친절하다. 핵심이 한눈에 안 들어오고, 숫자와 표는 많은데 맥락은 흐려지고, 끝까지 읽는 사람은 거의 없다. 오픈소스 시대에 공유는 쉬워졌지만, 읽히는 문서를 만드는 건 여전히 어렵다.

마침, 쓸 수 있는 도구가 있었다

그 시점에 맞춰 이런 것들이 있었다.

• Upstage API를 사용할 수 있었고
• Document Parsing으로 PDF를 구조적으로 읽을 수 있었고
• Solar-Pro로 "사람이 읽기 좋은 글"을 다시 쓸 수 있었다

업스 대표님 만세

그래서 만들기로 했다.

과제 → 포트폴리오 AI Agent

목표는 단순하다.

교내 과제 PDF를 그대로 옮기는 게 아니라, '포트폴리오용 문서'로 다시 만들어주는 것.

과제를 과제로만 끝내지 않고, 보여줄 수 있는 결과물로 바꿔주는 도구. 그게 이번 프로젝트의 시작이었다.

문제 정의

과제는 넘치는데, 남는 건 없다

학교 다니며 과제에 치여 살다가 이력서를 만들 시기가 오면…

아... 과제 이거 다 열심히 한 건데... 언제 포트폴리오로 다 정리하지...

문제 1. 과제 PDF는 "제출용"이지 "공유용"이 아니다

교내 과제 레포트는 기본적으로 교수님을 위한 문서다. 배경 설명이 길고, 실험 조건·수식·표가 많고, 평가 기준에 맞게 구성되어 있다.

과제 레포트 예시 — 잘 만들어진 문서이지만 "공유용"으로는 부담

그 자체로는 잘 만들어진 문서다. 하지만 "이 프로젝트 뭐 한 거야?"라고 보여주기엔 불친절하다. 핵심이 바로 안 보이고, 처음부터 끝까지 읽어야 맥락이 잡힌다.

문제 2. 포트폴리오로 옮기려면 '노가다'가 시작된다

그래서 대부분 이렇게 한다. PDF를 열고 → 중요한 부분만 복사해서 → Notion이나 블로그에 붙여넣고 → 문단을 다시 정리하고 → 표는 스크린샷으로 바꾸고 → 이미지를 다시 정렬한다. 이 과정이 생각보다 귀찮다. 시간이 많이 들고, 매번 비슷한 작업을 반복하게 되고, 결국 "나중에 해야지"만 반복하다 끝나지 않는다.

열심히 한 프로젝트가 포트폴리오로 잘 남지 않는다.

문제 3. OCR은 있어도, '의도'를 이해하지 못한다

그렇다면 OCR이나 기존 문서 변환 도구는 어떨까?

OCR은 텍스트 추출은 잘하지만, "과제 vs 포트폴리오" 구분은 못 한다

텍스트 추출, 이미지 인식은 잘한다. 하지만 이게 과제인지, 포트폴리오인지 구분하지 못한다. 숫자와 측정 테이블을 전부 텍스트로 풀어버리고, 오히려 더 복잡해지며, "무엇을 보여주고 싶은지"는 전혀 반영되지 않는다. 문서를 읽을 수는 있어도, 다시 쓰기까지는 수많은 프롬프트와 설계가 필요하다.

그래서 필요한 건 단순한 변환기가 아니라, "과제 문서를 이해하고, 보여주기 좋은 포트폴리오 형태로 재구성해주는 도구"였다. 그걸 만들기 위해 이번 프로젝트를 시작했다.

해결 방안

과제를 '변환'하지 말고, 다시 쓰게 하자

정리하면 이렇다. PDF를 그대로 옮기는 것 자체가 문제가 아니라, 과제 문서를 포트폴리오 문서처럼 다시 써주는 과정이 없다는 것.

핵심 아이디어 1. PDF를 그대로 쓰지 않는다

이 프로젝트에서 PDF는 결과물이 아니라 입력이다. PDF는 이렇게만 쓴다.

• 프로젝트 맥락을 파악하기 위한 재료
• 실험 결과, 코드 설명, 이미지의 출처
• "내가 실제로 뭘 했는지"를 판단하기 위한 근거

즉, PDF 문장을 그대로 가져와 붙이지 않는다. 대신 AI에게 이렇게 요구한다.

"이 문서를 읽고, 누군가에게 보여주기 좋은 포트폴리오 글로 다시 써라."

핵심 아이디어 2. LLM이 '문서 구조'를 다시 만든다

이때 중요한 건 글의 구조다. 교내 과제 레포트는 보통 '과제 목표 → 이론 → 실험 조건 → 수식/표/결과' 흐름이다. 포트폴리오 글은 다르다. 이 프로젝트에서는 고정된 포트폴리오 구조를 AI에게 강제했다.

• 한 줄 요약 (One-line Summary)
• 내가 무엇을 만들었는지 (What I Built)
• 핵심 결과 (Key Results)
• 대표 이미지 (Representative Visuals)
• 배운 점 / 엔지니어링 인사이트
• 사용 기술 스택
• 태그

LLM은 이 틀 안에서만 쓴다. 그래서 결과물이 항상 '사람이 읽기 좋은 글' 형태로 나온다.

🛠️ 프롬프트 엔지니어링 살짝 맛보기

실제로 쓴 System Prompt와 문서 구조는 이렇게 잡았다. (개발자 분들이 "어떻게 짰길래 잘 나오지?" 궁금하실 것 같아서 일부만 공개한다.)

1) System Prompt (톤 강제)

너는 기술 문서(PDF)를 "채용 담당자·타 개발자가 보는 포트폴리오 문서"로 재구성하는 전문 에디터다.
과제 제출물/보고서 톤이 아니라, LinkedIn에 그대로 올려도 자연스러운 톤으로 써라.
원문에 없는 사실을 만들지 말고, 과장·허위 성과·임의 수치 생성은 금지한다.
이 문서를 그대로 LinkedIn에 올려도 이상하지 않아야 한다. "과제 제출물" 느낌이 1%라도 나면 실패다.

2) 출력 구조 (코드에서 고정)

• Title → One-line Summary → What I Built → Key Results (No raw tables) → Representative Visuals (Max 2~3) → What I Learned / Engineering Insight → Tech Stack → Suggested Tags

3) 금지 사항을 프롬프트에 명시

• raw OCR 수치, 측정 로그, 표 전체 넣지 말 것
• 마크다운 강조 기호 **, __ 사용 금지 (Notion에서 그대로 노출되는 문제 방지)
• "[Missing image: ...]" 같은 placeholder 문구 금지

구조를 고정하고, 금지할 것까지 적어 두니까, 과제 톤이 슬쩍 들어오는 일이 많이 줄었다.

핵심 아이디어 3. OCR 결과는 '보여줄 것만' 남긴다

Document Parsing을 하면 숫자·표·측정 결과가 많이 나온다. 이걸 전부 글로 풀면 오히려 가독성이 떨어진다. 그래서 이렇게 처리했다.

• 긴 숫자 테이블 → 본문에서 제거
• 정말 중요한 결과 → 문장으로 요약
• 설명에 필요한 부분 → 대표 이미지로 대체

즉, 포트폴리오에 불필요한 정보는 과감히 버리고, "보여줘야 할 것"만 남긴다. 그래서 결과 글은 보고서보다 블로그 글에 가까운 톤이 된다.

핵심 아이디어 4. 결과는 자동으로 저장까지

이 프로젝트는 "글을 잘 써주는 것"에서 끝나지 않는다.

• 생성된 포트폴리오 글은 바로 미리보기로 확인
• 버튼 한 번으로 Notion 데이터베이스에 자동 저장
• 이미지는 외부 저장소에 업로드 후 Notion 이미지 블록으로 연결

사용자는 PDF 업로드 → 미리보기 확인 → 저장 버튼 클릭만 하면 된다. 그 다음에는 포트폴리오용 문서가 Notion에 정리된 상태로 남는다.

Before & After (실제 변환 결과)

같은 과제 PDF를 넣었을 때, 원본과 AI가 재작성한 뒤 Notion에 저장한 결과를 나란히 비교했다.

Before — 과제 PDF 원본

빽빽한 문단, 표·수치가 많고 "제출용" 느낌. 핵심이 한눈에 안 들어온다.

After — Notion 포트폴리오 (변환 결과 일부)

한 줄 요약 → What I Built → Key Results → 대표 이미지 2~3장 → Tech Stack 순으로 정리된, 읽기 좋은 문서.

전체 흐름은 아래 데모 영상에서 확인할 수 있다.

데모 영상에서 전체 흐름을 확인할 수 있다. (아래 링크)

개발하면서 겪은 난관 한두 가지 (Troubleshooting)

스무스하게만 되진 않았다. 두 가지는 꽤 신경 썼다.

1) Notion에 마크다운 강조(`,__`)가 그대로 노출되던 문제**

• LLM이 출력한 마크다운에 **굵게**가 들어가면, Notion API로 블록을 만들 때 문자 그대로 들어가서 "굵게"처럼 보였다.
• 해결: Notion에 넘기기 직전에 strip_markdown_emphasis()로 **, __를 제거하는 후처리를 넣었다. 포트폴리오 톤은 프롬프트에서 강제하고, 강조 기호는 아예 쓰지 않도록 금지 문구도 프롬프트에 넣었다.

2) 이미지가 Notion에서 안 보이거나, 캡션만 문단으로 남는 문제

• 파이프라인에서 이미지 경로가 assets/img_001.png처럼만 있으면, 문서별 폴더(assets/{doc_id}/img_001.png)와 매칭이 안 되어 Notion에 이미지가 안 올라갔다. 또 이미지 블록이 실패하면 그다음 줄(캡션)만 문단으로 들어가는 일이 있었다.
• 해결: assets/파일명 형태도 전부 assets/{doc_id}/파일명으로 통일했고, 같은 doc 내에서는 파일명만 맞아도 이미지를 찾도록 fallback을 넣었다. 캡션으로 인식할 줄(기울임꼴, 짧은 설명문 등)은 "이미지가 없을 때는 캡션도 블록으로 넣지 말자" 규칙을 추가해서 처리했다.

이 정도만 정리해 두니, "완벽하게 한 번에 성공"이 아니라 버그 잡은 경험이 조금이라도 보인다는 피드백을 반영한 셈이다.

기대 효과

• 과제를 단발성 제출물로 끝내지 않고, 계속 쓸 수 있는 포트폴리오 자산으로 바꿀 수 있다.
• 문서 옮기기·정리하는 반복 작업 없이, PDF 업로드만으로 정리된 결과물을 얻을 수 있다.
• 포트폴리오 관리의 진입 장벽을 크게 낮출 수 있다.

핵심 기술

• Upstage Document Parsing — PDF 구조 분석
• Solar 기반 LLM — 의도 기반 문서 재작성
• Notion API 연동 — 결과 자동 저장 파이프라인

마무리 — 만들면서 느낀 점 & 다음에 해보고 싶은 것

느낀 점

• "과제는 제출용이지 공유용이 아니다"라는 걸 명확히 잡고 나니, 해결 방향이 잘 잡혔다. 단순 변환기가 아니라 "다시 쓰게 하는 도구"로 가져가니까, 프롬프트 설계나 후처리도 덜 엉켰다.
• Upstage 무료 크레딧이 있어서 부담 없이 Document Parse + Solar를 많이 써 볼 수 있었고, 덕분에 실제로 쓸 수 있는 수준까지 만들 수 있었다.

앞으로 추가해 보고 싶은 것

• Velog(또는 다른 블로그) 자동 업로드: 지금은 Notion까지가 끝인데, "이 포트폴리오 글을 블로그 초안으로 한 번에 올리기" 같은 플로우가 있으면 좋겠다.
• 다른 채널용 톤: GitHub README용, LinkedIn용 짧은 버전은 이미 프롬프트에 채널을 나눠 두었는데, 실제 UI에서 "지금 문서를 README 스타일로 다시 생성" 버튼을 넣어 보는 것도 재밌을 것 같다.

모든 과정은 데모 영상으로 확인할 수 있다.

• ▶ 데모 영상
  https://youtu.be/h49VJiQs2qU

• ▶ 프로젝트 코드
  https://github.com/choihyun-1110/rewrite-my-report