이전에 송재경대표와 함께 일해본 경험상 정말 리스펙함. 대표이지만 개발자팀 중앙에 자리를 잡고 이른 아침부터 나와서 늦게까지 실제 현업(코딩)을 하고 회의에 들어와서도 자신이 원하는 방향성을 명확히 개진하고, 그의 요구가 있다면 대부분 리즈너블하고 합리적인 것들이었음. 자신은 워라벨에 크게 신경쓰지 않았지만 직원들의 워라벨은 상당히 좋았음. 권위적이지 않았고, 사내문화가 모두 자신의 영문 닉네임을 만들어 호칭을 부르는 문화였는데 송재경대표는 그냥 "Jake"라 부름. 이게 실제 회의중에서도 권위적인 분위기를 상쇄시키는 느낌. 대외적으로 알려진 네거티브한 이미지와는 다르게 실제 현장에서 접했던 송재경은 정말 말 그대로 게임 개발자였음.
"줄 수 있는데 안 주는" 쪽을 래퍼로 처리하기 전에, 149건부터 보는 게 맞을 것 같습니다. 응답에 ID가 있는데 매핑이 안 됐다는 건 필드명 컨벤션 문제(id / _id / resource_id / document_id)이거나 중첩 구조(result.data.id) 때문일 가능성이 높습니다. 이 149건은 API 수정 없이 매핑 레이어만 고쳐도 잡히는 범위입니다.
"줄 수 없는 쪽"은 도구마다 다르게 접근해야 할 것 같습니다.
write_file은 경로 + 내용 해시 조합이면 "같은 내용을 두 번 썼는가"는 감지 가능합니다.
k8s scale은 목표 replica 수가 현재 값과 이미 같다면 실질적으로 멱등 — 사전 상태 조회로 중복 실행 자체를 막을 수 있습니다.
click은 다릅니다. 액션 자체에 ID를 붙이는 건 의미가 없고, "이 click이 달성하려던 상태 변화가 이미 일어났는가"를 전후 스냅샷으로 비교하는 방향이 더 현실적일 것 같습니다.
저희가 내부적으로 고민 중인 건 도구를 "ID 반환 가능 여부 × 상태 변화 유형"으로 매트릭스화해서 처리 전략을 분기하는 방식입니다. 149건이 어떤 패턴에 몰려있는지 더 공유해주시면 매핑 전략 잡는 데 도움이 될 것 같습니다.
현재 사이드프로젝트를 진행하면서, 막막했었는데 좋은 유스케이스를 얻었습니다. 감사합니다!
한가지 질문을 드리고싶은게 있는데 BM으로 생각하고 있는 것이 있을까요? 아니면 지금 단계는
단순 서비스 검증 단계일까요?
Youtube 본 것을 기록해봤는데 url 복사 외에 더 간편한 방법이 있으면 좋을 것 같습니다. Youtube 외에는 이미 왓챠피디아가 있어서 차별점이 있어야 할 것 같습니다.
저한테 유용한 서비스네요 ㅎㅎ
가끔 특정 핫딜 사이트만 보는데, 그것보다 시인성도 좋고 깔끔해서 쓰기 편한 것 같습니다!
거기에 들어가지 않아도 반응 요약도 볼 수 있어서 좋네요 ㅎㅎ
크롤링 하는 주기를 여쭤봐도 될까요? 업데이트가 얼마나 자주 되는지가 궁금해서요
이전에 송재경대표와 함께 일해본 경험상 정말 리스펙함. 대표이지만 개발자팀 중앙에 자리를 잡고 이른 아침부터 나와서 늦게까지 실제 현업(코딩)을 하고 회의에 들어와서도 자신이 원하는 방향성을 명확히 개진하고, 그의 요구가 있다면 대부분 리즈너블하고 합리적인 것들이었음. 자신은 워라벨에 크게 신경쓰지 않았지만 직원들의 워라벨은 상당히 좋았음. 권위적이지 않았고, 사내문화가 모두 자신의 영문 닉네임을 만들어 호칭을 부르는 문화였는데 송재경대표는 그냥 "Jake"라 부름. 이게 실제 회의중에서도 권위적인 분위기를 상쇄시키는 느낌. 대외적으로 알려진 네거티브한 이미지와는 다르게 실제 현장에서 접했던 송재경은 정말 말 그대로 게임 개발자였음.
어 나도 돌려볼수 있는가?
선발대 있을라나요?
skills를 쓰시고 세션 내에서 로컬 멱등키를 따로 쓰셔야합니다
중년입니다;
감사합니다!!
한걸음씩요~
최소 충분 풀스택....ㄷㄷ
현재 진행중인 프로젝트에 좋은 인사이트를 얻었습니다. 고생하셨습니다.
블로그에서 toc가 본문 왼쪽이랑 겹쳐져서 가려지네요ㅠ
아 답변 감사합니다. 고충이 있으시군요 ㅠㅠ
이게 진짜 소버린이고 내재화고 파인튜닝이지...
오, 말씀대로 플랜 모드에서 골세터 스킬을 호출하니까 질문이 플랜모드 자체 기능으로 나오고, 더 많은 질문이 자세하게 나오면서 플랜의 실행이 실제 실행이 아니라 골 작성이 되어서 완벽한 것 같습니다.
놀랍긴 하네요
ditto clipboard manager만한게 없네요.
청년... 내 집값 돌려줘요...
지금 매달 구독제 쓰고 있습니다ㅜ 비용이 작지 않은 것 같아서 지속성에 대해 고민이 이씁니다.
분류 구조 덕분에 저희 설계에서 어느 전략이 실제로 작동하는지 가늠이 됩니다.
"줄 수 있는데 안 주는" 쪽을 래퍼로 처리하기 전에, 149건부터 보는 게 맞을 것 같습니다. 응답에 ID가 있는데 매핑이 안 됐다는 건 필드명 컨벤션 문제(id / _id / resource_id / document_id)이거나 중첩 구조(result.data.id) 때문일 가능성이 높습니다. 이 149건은 API 수정 없이 매핑 레이어만 고쳐도 잡히는 범위입니다.
"줄 수 없는 쪽"은 도구마다 다르게 접근해야 할 것 같습니다.
저희가 내부적으로 고민 중인 건 도구를 "ID 반환 가능 여부 × 상태 변화 유형"으로 매트릭스화해서 처리 전략을 분기하는 방식입니다. 149건이 어떤 패턴에 몰려있는지 더 공유해주시면 매핑 전략 잡는 데 도움이 될 것 같습니다.