적합도 판정과 별개로, 이 공고에서 무엇을 조심해야 하는지를 모델이 근거 위치와 함께 말하게 했다. 근거를 확인할 수 없으면 판단을 낮추고, 위젯은 그것을 낮은 위험이 아니라 모름으로 보여준다.
[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]
로컬이면 안전할까? 저장·삭제·접근 검사를 뜯어봤다 — Career Radar Milestone 2
지원 현황을 저장하기 시작하자, 지운 메모가 이력에 남고 로컬 서버의 접근 검사도 충분하지 않다는 사실이 드러났다. 합성 데이터로 재현하고 삭제 경로까지 확인하면서, 직접 써볼 초안의 기준을 정리했다.
[Read More]
공개 채널에 던진 질문은 투명한 일이 아니다
짧은 기술 질문이 여러 시스템의 조사와 의사결정을 한 사람에게 넘기기도 한다. 질문을 공개하는 데서 멈추지 않고 비용과 책임, 남길 결과까지 드러내야 일이 투명해진다.
[Read More]
AI가 만든 판정 코드를 PR로 검증했다 — Career Radar Milestone 1
테스트가 통과한 판정 코드도 잘못된 근거를 넣자 엉뚱한 결론을 냈다. 리뷰 의견을 재현 입력과 회귀 테스트로 바꾸면서, 정책 검증과 실제 모델 검증을 구분한 과정을 정리했다.
[Read More]