AI 생태계에 씨앗을 뿌리다: 상업용 오픈소스 AI, HyperCLOVA X SEED | CLOVA
https://bit.ly/4cOkG8e
- 네이버는 상업용 오픈소스 AI 모델 HyperCLOVA X SEED를 공개
- 3B(이미지 이해), 1.5B(텍스트 처리), 0.5B(경량 대화) 세 가지 크기로 출시
- 모두 한국어에 특화되어 동급 모델보다 우수한 성능을 보임
- 2024년 4월 24일부터 Hugging Face에서 다운로드 가능
Gemma 3 와 비교하는군요
Perlmint
@perlmint@hackers.pub · 36 following · 27 followers
크로스 플랫폼 빌드 고치는 노동자
Github
- @perlmint
Bluesky
- bsky.perlmint.dev
오는 8월 9일 Microsoft Korea에서 열리는 #우분투 #사용자 와 #기여자 가 모이는 국내 최대 행사, #UbuCon Korea 2025의 #연사 를 찾습니다! 🎤
올해는 특별히 커뮤니티 #20주년 을 맞아, #초보자 부터 #전문가 까지 모두를 위한 우분투 #활용법 과 경험, 흥미로운 #사례 를 공유해주실 분들을 기다립니다. 여러분의 우분투, #리눅스 그리고 #오픈소스 이야기를 들려주세요! ✨
🗓️ #CFP 마감: 2025년 5월 16일
🔗 자세히 보기 및 #제안서 제출: https://2025.ubuntu-kr.org/cfp
#UbuConKorea #UbuConKorea2025 #Ubuntu #컨퍼런스 @ubuntuCanonical Ubuntu
친구가 외국 반도체회사에 다니는데 이름만 들으면 다 아는 세계에서 손꼽히는 회사다. 1년 전쯤에, 친구가 자기 팀에서 예전부터 쓰고있는 시뮬레이션 코드가 너무 복잡해서 리팩토링 하고 싶다고 나를 찾아왔다. 한 2, 3000줄 되는 Numpy 코드였다.
나는 시뮬레이션의 의미 자체는 전혀 이해를 못하니(이래서 보안문제도 익스큐즈 할수 있었을 것이다), 그냥 코드의 모양만 보고 이상한 부분을 조금씩 고쳐나갔다. 그... 전형적인 물리학자들의 실험실 코드였다(코드를 못짜는건 이해를 하는데, 거기에 대해 한치의 부끄러움도 느끼지 않는다는 점이 뒷목을 잡게 만든다). Numpy 함수도 제대로 활용을 못해놨길래, 나도 Numpy 잘 못쓰지만 대충 이런 함수가 아마 있겠지... 하고 검색해서 찾아내서 교체하고 이런걸 반복했다.
이것저것 고친 다음에 잘돌아가나 한번 실행을 해봤는데, 이럴수가. 시뮬레이션이 1000배 빨라졌다. 아니 뭐, 한 2배 3배 빨라졌으면 내 솜씨라고 자부할텐데, 1000배 빨라진거는 그냥 원래 코드가 똥통이었다고 해석할수 밖에 없다. 구라안치고 정말 1000배다. 1000배의 성능향상의 보답으로 나는 교촌치킨웨지콤보세트를 현장에서 받아먹었다.
그 이후에 어떤 일이 있었냐. 기존 시뮬레이션 코드로는 하루에 시뮬레이션을 2, 3번정도밖에 돌리지 못했는데, 1000배 빨라지고 나니까 결과가 수십초만에 나오니 하루에 수백번 돌릴수 있게 된것이다(내가 고친 코드가 전부는 아니어서 1000배 향상은 아닌데, 가장 큰 병목이긴 해서 결국 100배 이상이라는 듯). 그때부터 100배 많아진 데이터를 처리하기 위한 인프라가 필요해졌다. 그래서 거기 개발팀이 데이터베이스와 데이터 파이프라인 구축을 시작하게 되었다고 한다. 그 팀에서는 일종의 특이점이 시작된것이다;;
결론: 교촌치킨웨지콤보 세트는 개맛있었다.
확실히 문서에 잘 정리해놓으니까 AI랑 협업하기가 수월한 것 같음. 개인 프로젝트에도 잘 해놓으면 아주 좋겠구먼
@joonnotnotJoon CONTRIBUTING.md 파일 하나 잘 작성해 두면 사람이랑 협업할 때 뿐만 아니라 LLM이랑 협업할 때도 도움이 많이 되더라고요. Hackers' Pub도 하나 마련해 뒀어요.
소프트웨어 엔지니어를 위한 연합우주 서비스 Hackers' Pub을 알고 계신가요? 저희가 특별히 중요시하는 것은 다른 플랫폼과는 조금 다른 행동 강령입니다.
저희는 현실 세계의 불평등이 온라인 공간에도 그대로 반영된다는 사실을 인식하고 있습니다. 그래서 “모든 사람을 동등하게 대우”한다는 표면적인 중립성이 아닌, 구조적 불평등에 적극적으로 대응하는 자세를 분명히 하고 있습니다. 이러한 접근의 일환으로, 차별적 발언과 차별에 대항하는 발언을 구분합니다. 이를 통해 “차별은 안 된다”는 명목 하에 차별 비판까지 동일시하는 “양비론”의 함정을 피할 수 있다고 생각합니다.
기술 커뮤니티에서 자주 볼 수 있는 문제로는 특정 기술 선택에 대한 비판이나 기술 수준에 따른 계층화가 있습니다. “이것도 모르냐?”는 태도는 학습을 방해할 뿐입니다. 저희는 초보자와 경험자 모두 동등하게 존중받는 환경 조성을 중요시합니다.
또한, 연합우주의 핵심 가치로 프라이버시가 있지만, Hackers' Pub에서는 특히 익명성의 권리를 강조합니다. 타인의 신원을 특정하려는 행위나 익명이라는 이유로 차별하는 것을 금지함으로써, 안심하고 참여할 수 있는 공간을 지향합니다.
이러한 행동 강령 자체도 완벽하지 않으며, 커뮤니티와 함께 발전해 나가는 것이라고 생각합니다. 모든 구성원이 개선안을 제안할 수 있는 체계를 마련함으로써, 더 나은 환경을 함께 만들어 나가고자 합니다.
자세한 내용은 Hackers' Pub 행동 강령을 참조해 주세요. 연합우주에서 더 건강한 기술 커뮤니티를 함께 키워나가지 않으실래요?
해커뉴스에서 Fabrice Bellard의 QuickJS가 한 파일에 5만줄 집어 넣고 한 함수가 몇백 몇천줄 되는 걸 보고서 파일 및 함수 길이를 강력하게 제한하는 도그마가 항상 옳은 것은 아니다, 라는 코멘트를 보았는데 이는 반만 맞는 말이다. 나도 대부분의 개발자보다 파일이나 함수 길이에 훨씬 관대한 (그리고 이 사실을 한참 뒤에야 깨달은) 사람이라 아는 건데, 그냥 Bellard가 5만줄 전체의 맥락을 전부 기억하고 있고 해당 코드를 거의 Bellard만 건들고 있기 때문에 추가적으로 모듈화할 필요가 없는 거고, 대부분은 그 정도의 기억이 불가능하기 때문에 여럿이 같이 짜는 코드라면 최저치에 맞춰서 파일이나 함수 길이를 줄일 필요가 있다고 하는 것이다. 지나친 도그마를 부정하는 것도 중요하지만 도그마가 생긴 진짜 이유를 파악해서 취사 선택하는 것이 더 중요한 이유.
@ailrunAilrun (UTC-5/-4)
@kodingwarriorJaeyeol Lee
@lionhairdino 아아 어떤 느낌인지 상상이 갑니다. 저는@parksb
님이 하신것처럼 맥주가 차있으면 좋겠다싶어 H 중간 막대를 위로 올렸습니다.
H가 컵이고, P가 손잡이어야 하는데, H가 컵 모양이 잘 안나와서, 포기하고 그냥 맥주에 담가 버렸습니다. (근데 호스트분 아주 근거리에 디자이너분 계신 거 아닌가 모르겠습니다.) @ailrunAilrun (UTC-5/-4)
Hackers' Pub은 검색에서 몇 가지 기본적인 문법들을 지원하고 있습니다. 문서화되지 않았기 때문에 한 번 정리해 봅니다.
문법 | 설명 | 예시 |
---|---|---|
" 키워드 " |
따옴표 안에 들어간 문자열을 띄어쓰기를 포함하여 찾습니다. 대소문자는 구분하지 않습니다. (따옴표 안에 따옴표를 넣으려면 \" 와 같이 이스케이프.) |
"Hackers' Pub" |
from: 핸들 |
해당 사용자가 쓴 콘텐츠만 추립니다. | from:hongminhee from:hongminhee@hollo.social |
lang: ISO 639-1 |
해당 언어로 쓰여진 콘텐츠만 추립니다. | lang:ko |
# 태그 |
해당 태그가 달린 콘텐츠만 추립니다. 대소문자는 구분하지 않습니다. |
#Fedify |
조건 조건 |
띄어쓰기 양 옆의 조건을 모두 만족하는 콘텐츠만 추립니다(논리곱). | "Hackers' Pub" lang:ko |
조건 OR 조건 |
OR 연산자 양 옆의 조건 중 하나라도 만족하는 콘텐츠를 추립니다(논리합). |
해커즈퍼브 OR "Hackers' Pub" lang:ko |
( 조건 ) |
괄호 안의 연산자들을 먼저 결합합니다. | (해커즈퍼브 OR 해커즈펍 OR 해커스펍) lang:ko |
구체적인 동작 방식은 Hackers' Pub 소스 코드를 보시면 더 자세히 알 수 있습니다.
그와 반대로 맥 데스크탑은 생각외로 컴팩트하고 예쁜데다가 맥 데스크탑 셋업은 꽤 좋아보이더라
습 이게맞나
맥 스튜디오는 귀여운거 맞음
가격이 흉악해서 문제지
쿠버네티스는 컴포즈만으로는 할 수 없는 HA (네트워킹 포함) 까지 책임져주는 솔루션 중 de-facto 라서 쓴다고 생각해요
앵간한 상황 다 대응되고
복잡하고 어려운 이유는 "앵간한 상황 다 대응"되기 때문이 아닐까 싶음... 컨테이너만 띄울거면 이렇게 복잡해질 이유가 없었음 - 사실 그 부분만 보면 컴포즈랑 비슷하기도 하고
GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:
소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?
(…중략…)
물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.
Jira, Linear 등 일정 관리 앱이 풀어야할 가장 어려운 문제는, 사용자 중 상당수는 애초에 일정 관리를 하기 싫어하는 사람이라는 것이다. 안타깝게도 나도 거기 포함되는데, 문제는 그런 사람일 수록 일정 관리가 꼭 필요하다. 나중에 프로젝트가 복잡해지면 일정 관리 앱을 켜는 거 자체를 꺼리게 된다. 이걸 어쩌면 좋지.
주말에 했던 〈국한문혼용체에서 Hollo까지〉의 발표에서 대강:
- 연합우주에서도 국한문혼용체로 글을 쓰는데 사람들이 읽기 쉽게 한글 독음을
<ruby>
태그로 달고 싶다! - Mastodon에 패치를 할 수는 있지만 업스트림에 받아들여질 리가 없으니 패치된 Mastodon 서버를 직접 운영할 수 밖에 없다.
- 혼자 쓰자고 Mastodon 서버를 운영하려니 비용이 크다. 가벼운 ActivityPub 서버 구현을 만들어야겠다.
- ActivityPub 서버 구현을 바닥부터 하자니 할 일이 너무 많다. ActivityPub 프레임워크를 만들어야겠다. → Fedify
- Fedify를 만들었으니 일인 사용자용 ActivityPub 서버를 구현하자. → Hollo
- Hollo를 만들었으니 Seonbi를 연동하자.
- Seonbi를 연동하여 한자어에 한글 독음이
<ruby>
로 달게 했으나 Mastodon과 Misskey에서<ruby>
태그를 지원 안 한다. - Mastodon 쪽에 이슈를 만들고 연합우주에서 홍보하여 결국 패치됨. Mastodon에서도
<ruby>
지원! - Misskey 쪽에 패치를 보내서 결국 Misskey에서도
<ruby>
지원! - 행복한 국한문혼용 생활.
이상과 같은 이야기를 했더니, “야크 셰이빙이 엄청나다”라는 의견을 들었다.
RE: https://hackers.pub/@hongminhee/019603e0-33ef-700f-90f4-153c8c995135
간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?
요약: 에모지라서 에모지라고 씁니다.
"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)
그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :)
, ¯\_(ツ)_/¯
, ^_^
등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.
프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).
반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:
)이나 닫는 괄호()
)는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :)
이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_-
같은 것은 대다수가 이모티콘으로 인정하지만, ->
같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.
-
문자와 >
문자에는 화살표라는 의미가 없기 때문에, ->
조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz
같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=
는 이모티콘인가? 이모티콘이 맞다면, 왜 ->
는 이모티콘이 아니고 <:=
는 이모티콘인가? 알 수 없습니다. ㅋㅋ
과 ㅠㅠ
는 둘 다 정서를 나타내는데, ㅠㅠ
만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ
는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ
만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ
에서 큐
는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.
https://mathstodon.xyz/@dginev/114299575351888130
arXiv에서 개발자 채용하는데, PHP/Perl 로 작성되어있는걸 Python으로 재작성하는 단계라고
Hackers' Pub의 소스 코드 저장소를 제 개인 계정에서 hackers-pub 조직 계정으로 옮겼습니다.
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
작년에 비하면 조금 약하다 ㅎㅎ 참고로 작년에는...
Faster than LIght speed Protocol(FLIP)은 LLM을 이용해 패킷이 수신 피어에 도착하기 전에 미래의 패킷을 예측함으로써 광속보다 빠른 전송을 달성한다. (...) 이 프로토콜 명세는 AI와 LLM을 사용하기 때문에 멍청한 인간은 이 명세를 리뷰해서는 안 된다고 여겨졌다. 대신 여러 LLM 챗 서비스의 코멘트와 제안으로 개선되어 승인받았다. https://www.rfc-editor.org/rfc/rfc9564