그럼에도 불구하고 유의미한 측정기준은 있을거라 생각해요. 특히 상반되는 두 지표를 모두 책임질 누군가가 있어야 더욱 효과적일것 같습니다. SRE 관점에서 장애건수를 낮췄다고 좋아해도, 그만큼 돌다리 두드리느라 배포가 늦어져서 기능 개발이 더뎌질수 있고, Dev 관점에서 기능 개발 많이 했다고 좋아해도, 그만큼 장애 발생 건수도 많아질수도 있는거니까요.
p99 latency, 응답 성공율, 요청당 비용, MTTR, 장애 발생 건수 같은 지표도 어뷰징하기 어려운 좋은 지표라고 생각합니다. (물론 어뷰징 될수도 있긴하겠지만 추적하고 관리하는게 실보다 득이 더 많을것 같은...)
일반화 하기는 쉽지 않겠지만 일단 경영진을 설득하기에는 가장 좋은 도구인것은 확실하네요.
타인의 서버에서 연산을 수행하는 방식은 사용자의 컴퓨팅 자유를 훼손한다는 점에서 사용을 거부해야 함
이건 LLM 뿐만 아니라 모든 클라우드 서비스랑 외부 서비스를 거부하자는 주장 아닌가요...? 번역이 잘못된건가요?
이거 굉장히 오래 전에 봤던 글 같은데.. 다시금 스스로에게 동기부여가 되는 글이었네요. 업로드해주셔서 감사합니다.
언어모델로 코딩하면서 기계에 가까운 표현을 알아서 마법처럼 만들어줄거라 믿다니 도둑놈 심보네요
제약이 걸려 있을수록 제약 안에서 일을 잘 합니다
재밌는 아이디어인 것 같습니다! 웹 UI나 디자인은 어떤식으로 구현하셨나요?
요즘은 발표 자체가 유의미하려면 AI를 다루는 팁 위주일 것 같은데, 발표의 본질이 점점 편해지고 퇴색되는 느낌이라 아쉽네요.
일을 위임한다는 것이 얼마나 어려운지 새삼 느꼈습니다.
그런 것 치고는 메인테이너가 여럿 떨어져나가지 않았나요?
음.. 뭔가 claude hooks/subagents/skill 같은 기능으로 만들 수도 있어보이는데 ..
한글 관련 서적이 딱 한권 나와 있는데, 아쉽게도 리눅스 커널에서 러스트 사용 방식이 여러번 브레이킹 체인지를 겪는 바람에 요즘의 커널과는 완전히 호환 되지 않더라구요. 깃헙 등을 통해 보완이 되면 참 좋겠습니다.
ai가 코드를 작성하더라도, 서비스에 대한 책임은 개발자가 져야 할텐데요. 본인이 이해할 수 없는 코드에 대해 책임을 질 수 있을지 싶습니다.
그럼에도 불구하고 유의미한 측정기준은 있을거라 생각해요. 특히 상반되는 두 지표를 모두 책임질 누군가가 있어야 더욱 효과적일것 같습니다. SRE 관점에서 장애건수를 낮췄다고 좋아해도, 그만큼 돌다리 두드리느라 배포가 늦어져서 기능 개발이 더뎌질수 있고, Dev 관점에서 기능 개발 많이 했다고 좋아해도, 그만큼 장애 발생 건수도 많아질수도 있는거니까요.
p99 latency, 응답 성공율, 요청당 비용, MTTR, 장애 발생 건수 같은 지표도 어뷰징하기 어려운 좋은 지표라고 생각합니다. (물론 어뷰징 될수도 있긴하겠지만 추적하고 관리하는게 실보다 득이 더 많을것 같은...)
그렇다면 아마 그 그래프는 오염될 가능성이 높겠군요.
굿하트의 법칙: "측정 기준이 목표가 되는 순간, 그 측정 기준은 더 이상 좋은 측정 기준이 되지 못한다"
평소에, 퍼센티지로 성과를 내세우는게 무의미하다고 생각했는데 이 글이 제 생각을 완성시켜주는 것 같습니다.
매출 5퍼센트 상승에 기여, 가 아니라 어느 기간동안 얼마나 올렸고 그게 본인의 기여 전이랑 비교했을 때 얼마나 가파라진 것인지를 말해야된다고 생각합니다
:+1:
너무 좋은 내용입니다.
???: It's a White.
이렇게 보니 색이 다 예뻐보이네요
ㅋㅋㅋㅋㅋㅋㅋㅋ
지금 웹캠이 없어 Vcam만으로 시험 해봤는데, 대체 이미지가 표시되는 것을 확인했습니다. 이런 방식이라면 이미지 업로드도 가능할 듯 합니다. 토큰 US2PU입니다!