직접 써보고 나온 수정 목록은 셋이었다. 없는 고용주 이름, 단위 없는 점수, 폭주하는 추론 토큰. 고치는 과정에서 스키마를 조이면 옛 기록을 못 읽고, 필수를 선택으로 바꿔도 옛 위젯은 깨진다는 것을 리뷰가 잡아냈다.
[Read More]
드디어 써봤다: 공고 세 개, 판정 두 개, 지어낸 이름 하나 — Career Radar 사용 확인 1
검증 장치를 그만 만들고 합성 프로필과 공개 공고 세 개를 무료 모델에 넣어 봤다. 판정보다 먼저 보인 것은 60초 제한에 걸린 도구, 응답을 못 주는 무료 엔드포인트, 그리고 본문에 없는 고용주 이름을 만들어 낸 모델과 그것을 막지 못한 스키마였다.
[Read More]
직접 써보기 위해 모델 제공자를 하나 더 붙였다 — Career Radar OpenRouter
검증 장치는 늘었지만 지원할 공고를 고르는 데 도움이 되는지는 아직 몰랐다. 모델 제공자를 추가하면서 유지할 규칙과 바꿔야 할 기록을 나누고, 다음 목표를 작은 사용 장면으로 좁혔다.
[Read More]
근거를 확인할 수 없는 설명은 '모름'으로 남기기로 했다 — Career Radar M4-B2
적합도 판정과 별개로, 이 공고에서 무엇을 조심해야 하는지를 모델이 근거 위치와 함께 말하게 했다. 근거를 확인할 수 없으면 판단을 낮추고, 위젯은 그것을 낮은 위험이 아니라 모름으로 보여준다.
[Read More]
유료 호출을 하기 전에, 언제 하면 안 되는지부터 코드로 적었다 — Career Radar 라이브 측정 하네스
90초 배치 제한이 실제 모델에 맞는지 재려면 누군가 유료 호출을 승인해야 한다. 측정 도구를 만들면서 호출하면 안 되는 조건을 먼저 코드로 정했고, 별도 리뷰는 그 안전장치가 덮지 못한 층을 네 곳에서 찾아냈다.
[Read More]
‘우리는 TBD다’라는 말 다음에 필요한 것
같은 조직 안에서도 제품마다 코드를 통합하고 검증하고 출시하는 조건은 다르다. 여러 브랜치 전략과 태그 기반 배포를 살펴보며, 제품에 맞는 방식을 선택하고 관리하는 책임을 생각해봤다.
[Read More]
그 문장이 있다고, 그 판단까지 맞는 것은 아니다 — Career Radar M4-B1
AI의 설명에 인용문이 붙었다고 판단까지 검증된 것은 아니다. 문장의 출처와 위치를 확인하고, 확인할 수 없는 판단은 불확실하게 남기는 규칙부터 만들었다.
[Read More]
OFF면 영향 없다는 믿음으로 운영을 열 수 있을까
피처 플래그가 OFF면 사용자에게 영향이 없다는 전제 아래 머지와 운영의 문턱을 낮추려 한다. 그러나 서버 설정을 바꾸는 스위치와 사용자 경험을 되돌리는 스위치는 다르며, 먼저 열어야 할 것은 운영 권한이 아니라 그 차이를 검증하는 실험이다.
[Read More]
탈락을 기록했더니, 면접까지 간 과정이 빠졌다 — Career Radar M4-C
지원 결과를 갱신했을 뿐인데 이전에 도달한 단계가 집계에서 빠졌다. 새 소식을 추가하는 일과 잘못된 기록을 정정하는 일을 나누며, 개인의 맥락을 기억하는 도구에 필요한 기본값을 돌아봤다.
[Read More]
검토를 끝냈더니 이전 결과와 비교할 수 없었다 — Career Radar M4-A
평가 사례의 검토 상태만 바꿨는데 이전 실행과 비교할 수 없게 됐다. 판정에 영향을 주는 변경과 설명을 다듬는 변경을 나누며, 평가 기록에 필요한 기준을 배웠다.
[Read More]
기능을 붙이다 보니, 어떤 앱을 만들지 다시 묻게 됐다 — Career Radar
이력서와 공고를 비교하는 기능 다음에는 무엇이 필요할까. 지원 결과를 어떻게 받아들이고 개인의 맥락을 얼마나 기억해야 할지, 다음 개발 계획을 세우며 앱의 방향을 다시 생각했다.
[Read More]
공고 세 개를 판정하고 결과는 하나만 보여줬다 — Career Radar Milestone 3
선택한 공고를 모두 분석해 놓고 요청 개수만큼만 보여주면, 나머지 결과를 보려고 같은 분석을 다시 실행하게 된다. 검색·추천 기능을 붙이며 결과 반환, 실패 안내, 재시도 비용을 코드와 회귀 테스트로 확인한 과정을 정리했다.
[Read More]