← Ascendy EN

meta

이직하려고 만든 포트폴리오 하네스를 공개한다 — '지어내지 않음'을 구조로

· Ascendy Engineering


TL;DR

소스 노트. 이 글은 두 소스에서 나왔다 — 기술 캐논은 portfolio 팀 글감(public OSS, gh로 직접 검증), 1인칭 동기·뒷이야기는 운영자 인터뷰(/interview). 전부 public OSS(AscendyProject/portfolio)라 사실은 공개 repo에서 확인 가능하다. 같은 신뢰를-구조로 결의 grounding 아이디어 소개 글, 그리고 이 도구의 원칙이 온 곳인 적대적 에이전트-페어 redteam과 이어진다.

왜 만들었나 — 그냥 내가 쓰려고

순서를 정직하게 적는다. AI가 거짓말하는 걸 보고 분노해서 시작한 게 아니다.

이직을 생각 중이었고, 요즘 하는 일은 대부분 에이전트와 같이 한다. 그래서 이직 과정 — 포트폴리오, 이력서, 지원 — 도 에이전트로 최적화할 도구가 당연히 있겠지 하고 찾아봤다. 없었다. 그럴듯한 글을 뽑아주는 생성기는 많아도, 내 실제 기록에 묶인 채로 그 과정을 도와주는 하네스는 없었다.

그래서 내가 쓰려고 만들었다. 이 출발점이 중요한 이유는, 내가 쓸 도구라 정직할 수밖에 없었다는 것이다. 남 보여주려고 만든 데모면 화려한 게 이기지만, 내가 이걸로 진짜 지원할 거라면 — 과장된 이력서는 면접장에서 결국 나한테 돌아온다.

원칙은 새로 발명한 게 아니다 — redteam에서 왔다

“지어내지 않음”을 핵심으로 잡은 건 갑자기 떠오른 게 아니다. 먼저 만든 redteam 하네스의 영향이다.

redteam이 잡으려던 것도 결국 같은 문제였다 — 서로 다른 모델을 적대적으로 비판·논쟁시켜, 팩트에 기반하지 않은 할루시네이션 같은 구멍을 잡는 것. 그 하네스를 만들다 보니, 같은 원칙이 자연스럽게 포트폴리오로 옮겨왔다. 커리어라는 표면은 할루시네이션이 가장 비싼 곳 중 하나니까 — 면접장에서 “이 PR 설명해 보세요” 했을 때 설명 못 하는 한 줄은, 없느니만 못하다.

갈림길 — 같은 목표, 다른 기계 장치

여기 흥미로운 차이가 하나 있다. redteam과 portfolio는 같은 anti-할루시네이션 목표를 갖는데, 메커니즘이 다르다.

왜 포트폴리오엔 “또 다른 모델이 리뷰” 대신 “코드가 증거를 검사”를 택했나? 이유는 단순하다 — 정답이 이미 정해져 있느냐.

리뷰 대상에 고정된 정답이 없을 때(코드가 맞는지, 추론에 구멍이 있는지)는 모델을 적대적으로 싸우게 하는 게 최선이다. 그런데 포트폴리오는 정답이 이미 박혀 있다 — 내 실제 GitHub 기록. 머지된 PR, 바뀐 파일은 이미 정해진 사실이다. 그러면 모델끼리 논쟁시킬 필요가 없다. 그 사실과 대조만 하면 된다. 메커니즘은 ground truth가 있느냐 없느냐를 따라간다.

그래서 무엇을 만들었나 — 엔진과 5커맨드

엔진은 한 문장이다: 증거를 먼저 결정론적으로 고정하고, 모델은 그 위에서만 서술하고, 코드가 모든 인용을 검증한다. 3레이어로 분리된다.

1. extract  (결정론)  gh / web → 실제 머지된 PR·변경 파일 → Evidence 집합
2. narrate  (LLM)     모델이 기여 claim을 작성 — 주어진 증거 위에서, ref를 id로 인용
3. ground   (결정론)  모든 claim 검사: 인용한 ref가 추출된 Evidence에 있나?
                      → grounded / rejected / needs-confirmation 3분할

핵심은 extract와 ground가 모델을 절대 호출하지 않는다는 것이다. 증거를 모으는 일도, 인용을 검증하는 일도 결정론 코드다. 모델이 끼는 곳은 가운데 이야기를 쓰는 한 곳뿐. 그래서 테스트할 수 있고 감사할 수 있다. 그리고 gate는 “이게 사실이냐”를 모델에게 되묻지 않는다(그건 또 환각을 부른다) — 인용한 ref가 증거에 존재하는가라는 결정론 검사만 한다.

이 엔진 위에 5개 커맨드가 선다. 관통선은 하나 — grounding을 한 번이 아니라 출력마다 다시 강제한다.

/rating이 안 하는

/rating에서 가장 하고 싶은 말은 이 커맨드가 하지 않기로 한 것이다.

/rating은 “당신은 전체 개발자 중 **상위 N%**입니다” 같은 모집단 비교를 하지 않는다. 이유는 간단하다 — 그렇게 말하려면 남들과 비교한 데이터가 있어야 하는데, 그 데이터가 없다. 없는 걸 말하면 그게 곧 지어내기다. 그래서 등급은 어디까지나 내 증거 자체에 대한 평가지 남과의 순위가 아니고, 렌더러는 percentile 어휘를 출력에서 (테스트로) 막는다.

이게 이 도구의 톤이다 — 멋지게 들리는 한 줄을 위해 근거를 지어내느니, 덜 약속하고 정확히 지킨다.

정직한 현재 — 아직 증명 안 됐다

마지막은 정직하게. 도구는 다 만들었고 repo도 public이지만, 나는 아직 이걸로 실제 이직을 해보지 않았다.

다음 단계는 이걸로 진짜 지원서를 써서, 몇 군데나 서류합격하는지 보는 것이다. 붙으면 그것대로 글감이고, 떨어져도 그것대로 글감이다. grounded 포트폴리오가 — 화려하진 않아도 정직한 포트폴리오가 — 실제로 통하는지 아닌지는, 내가 지어낼 수 없는 종류의 사실이다. 그러니 그것도 결과가 나오면 그대로 적겠다.

이 글이 결과를 지어내지 않는 것 자체가, 이 도구가 하려는 일의 작은 증명이다.

써보기

# 실제 GitHub 작업으로 grounded 포트폴리오를:
python -m portfolio --source-type github --source <repo-url> --author <handle>

# JD에 맞춘 grounded 이력서를:
python -m resume --source-type github --source <url> --author <handle> --jd <jd.txt>

저장소: github.com/AscendyProject/portfolio (Apache-2.0, public). 슬로건은 그대로다 — “Every claim must be grounded.”


저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.


Tags: grounding, ai, portfolio, developer-tools, launch, trust