좋은 의견 감사합니다 ㅎㅎ
사실 바이브코딩 이전의 Show GN (해커뉴스도 포함해서)과 현재의 결은 확실히 다르다고는 생각하지만 현재의 프로토타입 위주의 방향성은 나름대로의 장점이 있다고 생각합니다.
말씀해주신것처럼 LLM 기반으로 '알아서 다 해주는 마법'같은걸 저는 오히려 기피하는 입장이고, 사람이 제어해야하는 부분은 존재하다고 생각하는 입장에서 다른사람들은 어떻게 개발하는지 보는것도 꽤 재밌는것같아요.
사실 저같은 경우에는 이 플랫폼을 계속해서 개발한다고 QA를 대체한다기보다는 QA들이 사용하는 메인 툴로써, 한명이 반복적으로 힘들게 일하는 환경을 어느정도 생산성을 올려줄 수 있는 보조적인 역할로 보고 있습니다.
사실 게임개발을 제가 옛날부터 했기때문에 게임개발로 예시를 좀 들자면 저같은 경우엔 유니티로 개발을 주로 진행하였는데, 유니티 개발은 보통 클라이언트 레벨에서 내부적으로 트리거할 수 있는 영역을 별개로 개발해주고, 해당 부분을 매크로 방식으로 실행하는 매크로코드를 따로 작성해야만 기계적으로 동작하는 QA의 연구도 같이 진행했었는데, 해당부분은 굉장히 까다롭기도 하고 QA들이 사용하기 힘들더라구요.
그래서 방향성을 돌려서 이런저런 연구를 한 끝에 현재는 VLM을 활용하여 실제 디바이스를 직접적으로 제어하는걸 토대로 연구하고 있습니다. 단순히 LLM 모델을 가져와서 쓰는것 뿐만 아니라 다양한 모델 (30종 이상)을 내부적으로 벤치마크를 매겨서 각 레이어별로 제일 우수한 모델들을 피킹해서 섞어서 사용하고 있습니다.
아직 개발은 어느정도 되어있지만 api제공부터 다양한 추가 기능들까지 더 많은 기능들을 추가하고 꾸준히 발전시킬 예정이니 추후에 좀 더 나은 제품이 되었을때 '아 이런 제품도 있었지' 라고 생각드실때 한번 devops쪽이나 혹은 다양한 방면으로 사용하실 예정이시라면 한번 말씀해주시면 감사하겠습니다 ㅎㅎ
베타테스터를 찾는것도 방향성중에 하나지만 어떤 개발 관점에서 저희가 개발을 진행했는지에 대해서 공유를 같이 하고싶었는데 제가 글 재주가 없다보니 좀 누락된 내용들이 지금보니 많은것 같습니다.
말씀해주신 조언 깊게 받아들이도 한번 다른 회사들에 좀 컨택을 해서 QA용역 형태로 제안서를 좀 보내던지 한번 살펴봐야 할것같습니다. 아무래도 개발만 하고살아서 그런지 이런 부분에 대해선 굉장히 어렵네요.
실험 설계에 문제가 있네요. 정말 'GEO'때문에 오른 것인지를 보고자 한다면, GEO를 제외한 가능한 모든 변수를 통제해야죠. 이 경우에는 대조군으로 "아무것도 안 한 치과"가 아니라, "SEO만 한 치과"가 더 적절해 보입니다. 본문 내용만으로는 GEO를 해서 오른 건지, 방치하던 홈페이지를 개선해서 오른 건지 알 수가 없어요.
나름 큰 결정이네요.
저는 둘 곳이 없어서 그냥 네트워크로만 사긴 했는데, 이제 콘솔게임 즐긴 뒤에 재판매는 어려워 지겠어요
와 재미있어요 생각보다 어렵네요 ㅋㅋ
서버 자원을 많이 사용하지 못하는데도 이게 잘 돌아가는군요?
최근 ai-native 주니어 첫세대들을 접하게 되면서, 시스템에 대한 이해가 없을 때의 문제도 아직은 많이 있더라고요.
그런걸 경험해보고 나니, 손코딩 마지막 세대들의 역할도 꽤 중요해질 수 있겠다는 생각도 했었습니다.
꿀잼이네요 ㅎㅎㅎ 고맙습니다.
오 재미있어요. 근데 사각형 사이가 조금 좁아서 그런지 대각선 갈때마다 자꾸 옆을 건드려요.
간격을 조금 넓히거나 아니면 사각형의 히트영역을 줄여도 좋을거 같아요.
정말 좋은 글이네요. 감사합니다
엄청 와닿네요.. 불과 2년전 정도까지만 했어도 브레이크포인트 직접 잡으면서 메모리 보고 최적화 했는데, 이제는 그냥 메모리 많이먹는데 찾아봐 하면 찾아주니..
헤이버니도 종료되고 매일메일도 종료되고...ㅠㅠ
매일 출근하면서 보는게 루틴이었는데, 아쉽게 됐습니다
제가 서비스 오픈 초기에 헤이버니 - 뉴스레터 모아보기 로 알려드렸고,
Show에도 Show GN: 뉴스레터를 즐겨보고 있다면 주목해야 할 서비스, 헤이버니를 소개합니다. 라고 직접 소개해주셨는데요
긱뉴스 위클리 구독자 중에서도 Heybunny 로 구독하신 분이 꽤 계셔서 아쉽네요
풀린 건 좋은데 저번에 쓸 때 토큰 소모가 너무 많아서 뭔가 따로 맡길 작업이 생각나진 않네요;;
그래도 api 전환 후에서 쓰실 분들 덕분에 opus 지금 가격으로 조금 더 오래 사용할 수 있겠죠?
블로그 글 은 Show 로 등록하실수 없습니다. 원문 깃헙 링크로 대체합니다
HN에서 나온 autoexec.bat도 꽤나 추상화 된거라는 의견에 동의합니다.
"요즘 애들은 옛날엔 얼마나 힘들었는지 몰라" 라는 푸념에 가까운 글처럼 느껴지네요
Wayland에서 waypipe로 개별 앱을 실행해서 쓰는데 비슷한건가요
우려는되지만 참 똑똑하구나 싶어요
좋은 의견 감사합니다 ㅎㅎ
사실 바이브코딩 이전의 Show GN (해커뉴스도 포함해서)과 현재의 결은 확실히 다르다고는 생각하지만 현재의 프로토타입 위주의 방향성은 나름대로의 장점이 있다고 생각합니다.
말씀해주신것처럼 LLM 기반으로 '알아서 다 해주는 마법'같은걸 저는 오히려 기피하는 입장이고, 사람이 제어해야하는 부분은 존재하다고 생각하는 입장에서 다른사람들은 어떻게 개발하는지 보는것도 꽤 재밌는것같아요.
사실 저같은 경우에는 이 플랫폼을 계속해서 개발한다고 QA를 대체한다기보다는 QA들이 사용하는 메인 툴로써, 한명이 반복적으로 힘들게 일하는 환경을 어느정도 생산성을 올려줄 수 있는 보조적인 역할로 보고 있습니다.
사실 게임개발을 제가 옛날부터 했기때문에 게임개발로 예시를 좀 들자면 저같은 경우엔 유니티로 개발을 주로 진행하였는데, 유니티 개발은 보통 클라이언트 레벨에서 내부적으로 트리거할 수 있는 영역을 별개로 개발해주고, 해당 부분을 매크로 방식으로 실행하는 매크로코드를 따로 작성해야만 기계적으로 동작하는 QA의 연구도 같이 진행했었는데, 해당부분은 굉장히 까다롭기도 하고 QA들이 사용하기 힘들더라구요.
그래서 방향성을 돌려서 이런저런 연구를 한 끝에 현재는 VLM을 활용하여 실제 디바이스를 직접적으로 제어하는걸 토대로 연구하고 있습니다. 단순히 LLM 모델을 가져와서 쓰는것 뿐만 아니라 다양한 모델 (30종 이상)을 내부적으로 벤치마크를 매겨서 각 레이어별로 제일 우수한 모델들을 피킹해서 섞어서 사용하고 있습니다.
아직 개발은 어느정도 되어있지만 api제공부터 다양한 추가 기능들까지 더 많은 기능들을 추가하고 꾸준히 발전시킬 예정이니 추후에 좀 더 나은 제품이 되었을때 '아 이런 제품도 있었지' 라고 생각드실때 한번 devops쪽이나 혹은 다양한 방면으로 사용하실 예정이시라면 한번 말씀해주시면 감사하겠습니다 ㅎㅎ
베타테스터를 찾는것도 방향성중에 하나지만 어떤 개발 관점에서 저희가 개발을 진행했는지에 대해서 공유를 같이 하고싶었는데 제가 글 재주가 없다보니 좀 누락된 내용들이 지금보니 많은것 같습니다.
말씀해주신 조언 깊게 받아들이도 한번 다른 회사들에 좀 컨택을 해서 QA용역 형태로 제안서를 좀 보내던지 한번 살펴봐야 할것같습니다. 아무래도 개발만 하고살아서 그런지 이런 부분에 대해선 굉장히 어렵네요.
홍보하시려면 당당하게 showGN에서 합시다. 정작 본인 사이트도 ai 추천 못받고 계신거 같습니다만
실험 설계에 문제가 있네요. 정말 'GEO'때문에 오른 것인지를 보고자 한다면, GEO를 제외한 가능한 모든 변수를 통제해야죠. 이 경우에는 대조군으로 "아무것도 안 한 치과"가 아니라, "SEO만 한 치과"가 더 적절해 보입니다. 본문 내용만으로는 GEO를 해서 오른 건지, 방치하던 홈페이지를 개선해서 오른 건지 알 수가 없어요.
https://x.com/AnthropicAI/status/2072106151890809341
미 상무부 수출제재 해제 후 미국시간 7월 1일에 Fable 재공개한다고 합니다