"줄 수 있는데 안 주는" 쪽을 래퍼로 처리하기 전에, 149건부터 보는 게 맞을 것 같습니다. 응답에 ID가 있는데 매핑이 안 됐다는 건 필드명 컨벤션 문제(id / _id / resource_id / document_id)이거나 중첩 구조(result.data.id) 때문일 가능성이 높습니다. 이 149건은 API 수정 없이 매핑 레이어만 고쳐도 잡히는 범위입니다.
"줄 수 없는 쪽"은 도구마다 다르게 접근해야 할 것 같습니다.
write_file은 경로 + 내용 해시 조합이면 "같은 내용을 두 번 썼는가"는 감지 가능합니다.
k8s scale은 목표 replica 수가 현재 값과 이미 같다면 실질적으로 멱등 — 사전 상태 조회로 중복 실행 자체를 막을 수 있습니다.
click은 다릅니다. 액션 자체에 ID를 붙이는 건 의미가 없고, "이 click이 달성하려던 상태 변화가 이미 일어났는가"를 전후 스냅샷으로 비교하는 방향이 더 현실적일 것 같습니다.
저희가 내부적으로 고민 중인 건 도구를 "ID 반환 가능 여부 × 상태 변화 유형"으로 매트릭스화해서 처리 전략을 분기하는 방식입니다. 149건이 어떤 패턴에 몰려있는지 더 공유해주시면 매핑 전략 잡는 데 도움이 될 것 같습니다.
본문에서 아파트 공유 기능을 빼먹었네요 ㅎㅎ 유명 대단지인 헬리오시티 공유 링크 하나 테스트 겸 남겨둡니다.
(예측 결과는 참고용으로만 봐주시고, 자세한 모델링은 백서 참고 부탁드려요!)
로그인 없이 바로 열리니 차트 UI 구경용으로 편하게 눌러보세요. https://app.apt-insights.com/s/apt/9NPumhVmCv
응답에 ID 필드가 아예 없음: 2,011건 (62.9%)
호출이 에러로 실패: 1,037건 (32.4%)
응답에 ID가 있는데 저희 매핑이 못 잡음: 149건 (4.7%)
여기서 하나 정정드릴 게 있습니다. 아까 "대부분의 중복이 추적 자체가 안 되는 구간"이라고 하셨는데, 32%는 호출이 실패한 건입니다. 아무 일도 안 일어났으니 추적할 대상이 없는 거죠. 진짜로 "일어났는데 추적이 안 되는" 건 2,011건입니다. 여전히 큰 숫자지만 3,197보다는 작습니다.
성공/실패만 돌려주는 도구는 24개였습니다. 유형별로 묶으면:
브라우저 조작 (9개) — click, type, navigate 등. click 하나만 719건
파일시스템 (3개) — write_file, edit_file, move_file
쿠버네티스 (4개) — scale, create, apply, delete
문서 편집 (3개) — add_paragraph, add_heading, format_text
개별 — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
이 24개가 두 종류로 갈립니다. 이게 스펙 설계에 쓸모 있을 것 같아서 덧붙입니다.
ID를 줄 수 없는 쪽 브라우저 클릭이나 파일 편집은 애초에 "생성된 엔티티"가 없습니다. 클릭에 ID를 붙일 수가 없죠. 파일은 경로가 곧 식별자고요.
줄 수 있는데 안 주는 쪽 github-create_repository가 대표적입니다. 저장소를 만들었으면 당연히 ID가 있는데 응답엔 없습니다. emails-send_email도 SMTP 레벨엔 message ID가 있는데 안 돌려주고요. github-fork_repository, excel-write_data_to_excel도 같습니다.
후자가 고칠 수 있는 쪽입니다. 내부 도구 스펙에 "생성 계열은 응답에 엔티티 ID 필수"를 넣으신다면, 이 구분이 어디에 적용할지 판단 기준이 될 것 같습니다.
마지막 149건은 저희 매핑 문제입니다. notion database-query 102건, pptx open_presentation 28건에 몰려 있는데, 둘 다 저희가 의도적으로 범위 밖에 둔 도구라 잡히지 않았습니다. 도구 설계 문제가 아니라 저희 커버리지 문제입니다.
혹시 지금 운영하시는 스택에서 쓰기 작업이 어느 쪽에 몰려 있나요? 저희가 본 건 벤치마크라 도구 구성이 실제 운영과 다를 것 같아서요.
오, 말씀대로 플랜 모드에서 골세터 스킬을 호출하니까 질문이 플랜모드 자체 기능으로 나오고, 더 많은 질문이 자세하게 나오면서 플랜의 실행이 실제 실행이 아니라 골 작성이 되어서 완벽한 것 같습니다.
놀랍긴 하네요
ditto clipboard manager만한게 없네요.
청년... 내 집값 돌려줘요...
지금 매달 구독제 쓰고 있습니다ㅜ 비용이 작지 않은 것 같아서 지속성에 대해 고민이 이씁니다.
분류 구조 덕분에 저희 설계에서 어느 전략이 실제로 작동하는지 가늠이 됩니다.
"줄 수 있는데 안 주는" 쪽을 래퍼로 처리하기 전에, 149건부터 보는 게 맞을 것 같습니다. 응답에 ID가 있는데 매핑이 안 됐다는 건 필드명 컨벤션 문제(id / _id / resource_id / document_id)이거나 중첩 구조(result.data.id) 때문일 가능성이 높습니다. 이 149건은 API 수정 없이 매핑 레이어만 고쳐도 잡히는 범위입니다.
"줄 수 없는 쪽"은 도구마다 다르게 접근해야 할 것 같습니다.
저희가 내부적으로 고민 중인 건 도구를 "ID 반환 가능 여부 × 상태 변화 유형"으로 매트릭스화해서 처리 전략을 분기하는 방식입니다. 149건이 어떤 패턴에 몰려있는지 더 공유해주시면 매핑 전략 잡는 데 도움이 될 것 같습니다.
앗 Show GN 인데 누락되었네요...ㅠㅠ 수정 가능하다면 수정 부탁드립니다.
넵! 국민 평형을 기준으로 모델링 되어있습니다.
다만, 국민 평형이 없는 아파트의 경우, 다수의 표본 평형으로 예측하도록 구현되어 있습니다.
부모님께서 거주하시는 구축 아파트 넣고 해보니..
33평만 나오는데.. 해당 구축 아파트는 33평, 26평이 같이 있습니다.
원래 33평만 지원을 하는지요?
와~ 저도 만들고 싶었던 서비스인데, 혹시 이런 크롤링하면 Supabase 금액은 어느정도 나오는지 알 수 있을까요?
영상 , 녹음 모두 서버로 서빙되는 건가요?
본문에서 아파트 공유 기능을 빼먹었네요 ㅎㅎ 유명 대단지인 헬리오시티 공유 링크 하나 테스트 겸 남겨둡니다.
(예측 결과는 참고용으로만 봐주시고, 자세한 모델링은 백서 참고 부탁드려요!)
로그인 없이 바로 열리니 차트 UI 구경용으로 편하게 눌러보세요.
https://app.apt-insights.com/s/apt/9NPumhVmCv
무료 앱들도 많고 만들기도 쉬워서 유료앱이라면 흠...
제보 감사합니다. 수정했습니다!!
기술 백서 링크 404 가 발생하고 있습니다!
https://edge.apt-insights.com/v1/public/whitepaper
크헉 cppreference 한국 사이트가 있는지, 이 글을 보고 처음알아서 행복했는데..
기존대로 영문 사이트를 이용해야겠네요.
아 윈도우를 안쓴지 오래되어서 잘 몰랏네요 찾아보니 비슷해 보입니다
3,197건을 사유별로 나누면 이렇게 됩니다.
응답에 ID 필드가 아예 없음: 2,011건 (62.9%)
호출이 에러로 실패: 1,037건 (32.4%)
응답에 ID가 있는데 저희 매핑이 못 잡음: 149건 (4.7%)
여기서 하나 정정드릴 게 있습니다. 아까 "대부분의 중복이 추적 자체가 안 되는 구간"이라고 하셨는데, 32%는 호출이 실패한 건입니다. 아무 일도 안 일어났으니 추적할 대상이 없는 거죠. 진짜로 "일어났는데 추적이 안 되는" 건 2,011건입니다. 여전히 큰 숫자지만 3,197보다는 작습니다.
성공/실패만 돌려주는 도구는 24개였습니다. 유형별로 묶으면:
브라우저 조작 (9개) — click, type, navigate 등. click 하나만 719건
파일시스템 (3개) — write_file, edit_file, move_file
쿠버네티스 (4개) — scale, create, apply, delete
문서 편집 (3개) — add_paragraph, add_heading, format_text
개별 — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
이 24개가 두 종류로 갈립니다. 이게 스펙 설계에 쓸모 있을 것 같아서 덧붙입니다.
ID를 줄 수 없는 쪽 브라우저 클릭이나 파일 편집은 애초에 "생성된 엔티티"가 없습니다. 클릭에 ID를 붙일 수가 없죠. 파일은 경로가 곧 식별자고요.
줄 수 있는데 안 주는 쪽 github-create_repository가 대표적입니다. 저장소를 만들었으면 당연히 ID가 있는데 응답엔 없습니다. emails-send_email도 SMTP 레벨엔 message ID가 있는데 안 돌려주고요. github-fork_repository, excel-write_data_to_excel도 같습니다.
후자가 고칠 수 있는 쪽입니다. 내부 도구 스펙에 "생성 계열은 응답에 엔티티 ID 필수"를 넣으신다면, 이 구분이 어디에 적용할지 판단 기준이 될 것 같습니다.
마지막 149건은 저희 매핑 문제입니다. notion database-query 102건, pptx open_presentation 28건에 몰려 있는데, 둘 다 저희가 의도적으로 범위 밖에 둔 도구라 잡히지 않았습니다. 도구 설계 문제가 아니라 저희 커버리지 문제입니다.
혹시 지금 운영하시는 스택에서 쓰기 작업이 어느 쪽에 몰려 있나요? 저희가 본 건 벤치마크라 도구 구성이 실제 운영과 다를 것 같아서요.
한국판은 마지막 업데이트가 16년이라 원문을 보는 것이 좋을 듯 합니다
하루 한 걸음이라도 나아갈 수 있다면 그것으로 충분합니다.
생산은 쉬워지고 검증은 정교해지며, 결국 '선택'이 핵심이 되는 시대입니다. 그만큼 흐름을 정확히 읽어내는 안목이 더욱 중요한 시점입니다.