IRCv3

요약

IRC 개발자들이 모인 IRCv3가 오래된 채팅 프로토콜 IRC를 하위 호환되는 확장으로 고쳐 가고 있습니다.

IRCv3 작업 그룹은 IRC 클라이언트와 서버 소프트웨어를 만드는 개발자들의 모임입니다. 클라이언트 프로토콜의 변경안을 만들고 시험하는 일을 맡고 있으며, 명세 작업은 GitHub에서, 논의는 Libera.Chat의 #ircv3 채널에서 합니다.

왜 중요한가

모든 확장이 예전 클라이언트·서버와 호환되므로 기존 IRC 네트워크를 갈아엎지 않고도 새 기능을 더할 수 있습니다.
InspIRCd, UnrealIRCd, WeeChat, HexChat, ZNC, IRCCloud 등 주요 서버·클라이언트 진영이 함께 참여합니다.
대화 기록 조회처럼 요즘 메신저에 익숙한 기능이 표준으로 들어오는 중입니다.

핵심 내용

SASL(표준 계정 인증 방식) 로그인과 자리 비움 즉시 알림은 이미 구현돼 쓰이고 있습니다.
메시지 태그로 메시지에 부가 정보를 붙일 수 있고, 관련 메시지는 batch로 묶어 보냅니다.
서버 타임스탬프 덕분에 바운서(접속을 대신 유지해 주는 중계 프로그램)의 기록을 정확한 시각으로 재생합니다.
서버에서 대화 기록을 가져오는 chathistory와 보안 연결을 자동으로 쓰는 STS는 아직 작업 중입니다.
유니코드 닉네임·채널 이름과 그래픽 클라이언트용 아바타도 진행 중인 과제입니다.

HN 반응

가장 많은 댓글은 ICQ·mIRC·Winamp 시절의 가볍고 빠른 채팅 프로그램을 그리워하는 이야기였습니다.
IRC의 불편함은 대부분 클라이언트 문제라 IRCv3가 필수는 아니라는 의견과, 대화 기록 명세가 아직 초안에 머물러 있다는 경험담이 나왔습니다.

30개 표시 · 전체 296개

rkagerer14시간 전 HN

이런 말 했다가 몰매 맞겠지만, 요즘 채팅 앱을 볼 때마다 (90년대 모습 그대로의) ICQ 시절이 그리워요.

그 뒤로 나온 어떤 것보다 ICQ의 UI가 제 취향이었어요. 작고, 비교적 거슬리지 않고, 정보 밀도가 높고, 빨랐죠. 전체 채팅 기록을 기기 사이에 들고 다닐 수 있었고, 믿고 검색할 수도 있었고요(스크롤이 사라지거나 지연 로딩 때문에 답답할 일도 없었죠). 사람이나 그룹마다 다른 접속 상태를 보여줄 수 있었던 것도 편했어요.
Flere-Imsaho14시간 전 HN

ICQ에 Winamp까지 있던 때가 PC의 전성기였죠
hurril13시간 전 HN

그 목록에 mIRC 4.51도 넣어야죠. 1.44MB 디스켓 한 장에 들어갔고, 낡아빠진 486에서도 마우스 버튼에서 손을 떼기 전에 완전히 실행됐어요.
dollylambda10시간 전 HN

맞아요, mIRC 시절이 좋았죠. 윈도 98에 개 이빨 무늬(houndstooth) 배경화면이었고요 :P

저는 지금도 IRC를 쓰는데, 클라이언트와 OS만 달라졌어요.
lbreakjai10시간 전 HN

갑자기 커다란 송어로 뭔가를 후려치고 싶어졌어요.
doubled1129시간 전 HN

그걸로 라마 엉덩이도 때릴 수 있나요?
drusepth8시간 전 HN

로브 입고 마법사 모자 쓰는 것도 잊지 마세요
hurril7시간 전 HN

이 스레드 너무 좋네요. mIRC에서 정말 많은 시간을 보냈죠. 워레즈(warez)니 별별 이상한 얘기니 했지만 프로그래밍 얘기도 엄청 많이 했고요. 재밌었어요 :)
Al-Khwarizmi9시간 전 HN

저는 지금도 mIRC를 써요. 옛날 그대로 돌아가고, 제 생각엔 나이를 아주 잘 먹었어요. 다른 클라이언트도 써 봤지만 갈아탈 만한 건 없었어요. 이제는 라이선스도 샀고요(처음 쓰기 시작했을 때는 열다섯 살쯤이라 살 돈이 없었거든요).

Winamp는 안타깝게도 그만큼 곱게 늙지 못했네요.
PetahNZ5시간 전 HN

mIRC 스크립팅이 제가 처음 배운 언어 중 하나였어요.
lnxg33k14시간 전 HN

저는 첫 번째였어요! xD
embedding-shape11시간 전 HN

음성 채팅은 Ventrilo였죠. Quakenet에서 사람들을 찾아 3대3을 하고, 친구가 되기도 하고 원수가 되기도 하고, 늘 재밌었어요.
da_chicken5시간 전 HN

아직도 오픈 소스 Winamp 2.91/2.95 클론이 없다는 게 믿기지 않아요.

다들 "범용 미디어 라이브러리 관리자"를 만들려고 해요. 세상에, MP3 이름만 제대로 붙여 놓고 파일 관리로 정리한 다음, 그냥 오디오만 재생해 주는 플레이어를 원하는 사람은 아무도 없나요?
KPGv21시간 전 HN

MP3 이름을 제대로 붙이고 파일 관리만 쓰고 싶은 사람은 없나요

없죠. 어떨 땐 아티스트가, 어떨 땐 제목이, 어떨 땐 발매 연도나 앨범 이름이 중요하니까요. 제대로 된 메타데이터가 중요해요. 한 기기에서 다른 기기로 데이터를 옮길 때가 아니면 파일 이름은 거의 안 봐요.
bsammon3시간 전 HN

x11amp가 있었는데 XMMS로 이름이 바뀌었고, 나중에 Beep Media Player로 포크되었다가, 다시 Audacious로 포크되었습니다.

제 기억으로 Audacious를 마지막으로 썼을 때는 기본 인터페이스가 iTunes에서 느슨하게 영감을 받은 듯한 UI였는데, 설정 화면에서 알맞은 옵션을 만지면 Winamp 같은(적어도 XMMS 같은) UI로 바꿀 수 있었습니다.

https://en.wikipedia.org/wiki/Audacious_(software) 에서 제 기억 상당 부분이 확인됩니다.
jazzyjackson3시간 전 HN

원하시던 것과는 다르겠지만 그리 멀지 않을 수도 있어요. Spotify를 API로 제어한다면 로컬 오디오용 백그라운드 프로세스를 제어하도록 확장하지 못할 이유가 없어 보이거든요.

https://news.ycombinator.com/item?id=49990730
johnisgood10시간 전 HN

ICQ랑 MSN Messenger, 맞아요. :P
oooyay8시간 전 HN

제가 만든 IRCv3 클라이언트도 마음에 드실 수 있어요: https://github.com/matt0x6f/irc-client . 기능이 충실하고 현대적이면서도 리소스 사용량은 적고 꽤 쌩쌩해요. PR도 환영합니다.
d3Xt3r5시간 전 HN

인터페이스는 React와 Tailwind CSS로 만들었습니다

ಠ_ಠ
oooyay4시간 전 HN

하하, 이 두 가지에 구체적으로 무슨 불만이 있으신지는 모르겠지만, 제가 선택한 이유를 설명할 기회로 삼겠습니다.

저는 당연히 Go로 코드를 많이 쓰는데, Go는 IRC 프로토콜과도 정말 잘 맞는 언어입니다. 추상화와 테스트를 짜는 방식이 데스크톱 애플리케이션을 만드는 데 아주 잘 어울려요. 반면 Go로 UI를 짜는 건(여러 방식으로 시도해 봤습니다) 정말 맞지 않습니다. Go에 Elm 아키텍처를 흉내 내게 하는 건 너무 투박하거든요.

제 관점에서 UI는 부수 효과(side effect)로 굴러가는 코드이고, 그런 패러다임에 그저 잘 맞는 정도가 아니라 아주 잘 맞는 언어가 필요합니다. 제가 고를 수 있었던 다른 어떤 선택지도 지금보다 훨씬 많은 CGO 의존성(지금은 하나뿐입니다)이 필요했을 것이고, Go와 연결하려 하면 코드도 더 읽기 나빴을 겁니다.

반대로 Wails의 TypeScript·React 브리지는 쓰기 아주 간단하고 안정적이며, IRC 클라이언트에 요구되는 성능과 일관성도 따라옵니다. Tailwind도 호환되는 CSS를 만드는 데 정말 좋습니다. 컴포넌트 기반 CSS 방식을 고른 것은 요즘 자동차 인포테인먼트 시스템에서 QT를 쓰는 모습에서 영감을 받았습니다.

마지막으로, 전체가 다운로드하시는 바이너리 안에 컴파일되어 들어 있고 스스로는 외부 호출을 하지 않습니다. 예를 들어 Electron처럼 서드파티 브라우저 위에서 도는 게 아니라 OS의 WebView 위에 만들어졌습니다.
d3Xt3r4시간 전 HN

제가 불만인 건 "리소스 사용량이 제한적"이라고 하신 부분입니다. 물론 Wails는 Electron보다 가볍지만, 네이티브 앱만큼 가볍거나 효율적이지는 않아요. 저라면 "리소스 사용량이 적은" 앱이라고 내세우진 않을 겁니다.

oooyay3시간 전 HN

물론 Wails는 Electron보다 가볍지만, 네이티브 앱만큼 가볍거나 효율적이지는 않아요.

네, 맞는 말씀이라고 생각합니다. 저는 리소스 사용량을 따로 떼어 놓고 생각하지 않아요. 네이티브 앱으로 가면 앱을 세 개 개발해야 하고 CGO 의존성도 많아질 가능성이 높습니다. Wails와 OS WebView를 쓰면 MacOS에서 쓰시던 클라이언트가 리눅스와 윈도에서도 상식적인 범위 안에서 똑같거나 비슷하게 동작합니다. 리소스 사용 양상도 모두 비슷하게 유지되고요. 그래서 사용량이 제한적이라고 말한 겁니다. 저는 네이티브 라이브러리의 성능과 경쟁하려는 게 아니고, 네이티브 라이브러리의 성능도 제 크로스 컴파일 능력과 경쟁하려는 게 아니니까요.

    Process                         PID     Avg CPU    Footprint (MiB)
    ------------------------------  ------  ---------  ---------------
    Cascade                         45314      0.46%              73.0
    WebKit WebContent               45349      0.50%             392.9
    WebKit GPU                      45347     <0.01%              26.1
    WebKit Networking               45348      0.02%               6.5
    Nick completer plugin           45344     <0.01%               2.8
    Nickname colors plugin          45345     <0.01%               9.7
    ThemeWidget service             41353     <0.01%              10.1
    SafariPlatformSupport helper    41355     <0.01%              13.1
    ------------------------------  ------  ---------  ---------------
    Total                                     1.00%             534.2

저는 지금 네트워크 네 곳에 6일 18시간째 연결해 둔 상태입니다. 같은 시스템의 다른 네이티브 앱과 비교하면 이렇습니다:

    App           Main PID  Uptime        Avg CPU  Main MiB  Total MiB
    ------------  --------  ------------  -------  --------  ---------
    Cascade          45314   6d 17h 45m     1.52%      73.0      556.8
    Proton Drive     22091  11d 04h 32m     0.15%      48.0       65.1
    Ghostty          78285  27d 22h 03m    <0.01%     173.6      184.2
    Finder            1308  34d 19h 32m     0.05%     104.4      104.4

그러니 애플리케이션을 세 개로 나눠 다시 쓴다면 메모리를 200MiB쯤은 아낄 수 있을 겁니다. 메모리 사용량을 줄일 방법은 알아보겠지만, 이 중 일부는 아마 각 채널의 메시지 버퍼일 겁니다.

Dylan168074시간 전 HN

Wails 웹사이트에는 "기준 메모리 약 10MB(Electron은 100MB 이상)"라고 되어 있는데, 꽤 괜찮아 보여요. 뭔가 하기 시작하면 심하게 불어나나요?
singingtoday3시간 전 HN

저는 여는 것부터요. 제 PC가 낡아서 React 같은 무거운 걸 돌릴 만큼 튼튼하지 않거든요.
eahm7시간 전 HN

"Go로 작성됨"이라고 말하는 걸 깜빡하셨네요 /s

한동안 클라이언트를 지켜보고 있었는데 정말 멋져 보여요. 상기시켜 주셔서 고맙습니다. 30년 넘게 쓰다가 결국 지쳐서 IRC를 완전히 떠났는데, 오늘 늦게 다운로드해서 한번 써 볼게요.
oooyay4시간 전 HN

감사합니다! 의견 주시면 정말 좋겠어요.
Al-Khwarizmi9시간 전 HN

그리고 말씀하신 장점 외에도, 얼마나 깊이 관여하고 얼마나 열어 둘지를 정말 자유롭게 설정할 수 있었습니다. 친구들과 대화하는 용도로만 쓰고 그 외에는 연락이 안 되게 할 수도 있었고(나중의 MSN 같은 것들처럼), 낯선 사람과도 채팅할 수 있게 열어 둘 수도 있었어요. 관심사로 사람을 찾을 수도 있었는데, 저는 제가 갖고 있지 않은 동전이 있는 나라의 동전 수집가를 찾곤 했던 기억이 납니다 :)

그러다 MSN Messenger가 (적어도 스페인에서는) ICQ를 밀어냈는데, 기능은 ICQ의 10%도 안 됐어요.
theshrike799시간 전 HN
IRC를 지금도 매일 쓰고 여러 해 동안 IRC 봇과 클라이언트를 여러 개 만들어 본 사람으로서 말씀드립니다.
- IRC의 불편함은 대부분 클라이언트 쪽 문제라 클라이언트에서 고칠 수 있습니다. IRCv3 프로토콜 변경도 좋지만 좋은 경험에 꼭 필요한 건 아니에요.
- 봇은 채널을 더 활기차게 만들 수 있습니다. 채널에 붙여 넣은 URL의 제목만 올려 줘도, 화려한 리치 클라이언트가 없는 사람들까지 유튜브 링크나 Reddit 공유 URL 뒤에 뭐가 있는지 클릭하지 않고 볼 수 있어서 "Discord/Slack 같은" 경험에 더 가까워집니다.
- IRC 봇과 클라이언트는 어떤 언어로든 첫 프로젝트로 아주 재미있고 쉽습니다. 여러 대상(물론 멀티 서버)에 영구적으로 열린 소켓을 두고, 비동기 처리와 텍스트 처리까지 해 볼 수 있거든요.
저는 올해 초까지 아주 오랫동안 IRCCloud를 썼는데, AI 모델이 엄청 좋아진 "11월 혁명" 덕분에 Claude Pro 구독 한 개 값으로 제 입맛에 딱 맞는 나만의 IRCCloud를 만들 수 있겠다는 걸 알게 됐습니다.

그래서 만들었습니다. 한 주(여가 시간의 저녁들)쯤 만에 MVP가 돌아갔고, 여름 동안 IRCCloud 구독을 해지해서 이제는 제 시스템만 쓰고 있습니다.

지금은 TUI, 웹 UI, 네이티브 Swift 클라이언트(iOS 포함이지만 아직 테스트는 못 해봤습니다), 리눅스용 Tauri 클라이언트가 있고, 전부 제가 VPS에서 24시간 돌리는 공통 백엔드를 공유합니다.
basilikum13시간 전 HN

저는 요즘 IRCv3를 갖고 노는 중인데, 구체적으로는 지속되는 채널 기록(바운서 없이)입니다.

실험용으로 ergo^1 서버를 하나 세웠어요. 채널 기록은 현재 초안 단계인데, 어쩌면 영원히 초안일지도 몰라요.

혹시 이유가 있어서 들러서 써 보고 싶은 분은 exp3.irc.basilikum.monster:6697의 #hn으로 오세요.

IRCv3를 지원하는 클라이언트 목록은 여기 있어요(기록 지원은 draft/chathistory 확인): https://ircv3.net/software/clients

[1] https://ergo.chat/
prologic16시간 전 HN

IRCv3를 계속 밀고 나가려면 새 리더십이 필요한 걸까요? Parley/Ahoy( https://git.mills.io/prologic/parley https://git.mills.io/fastidious/ahoy )에서는 Discord/Slack 느낌이 나면서도 IRC와 IRCv3에 충실한, 연합형 분산 IRC 채팅 경험을 만들었습니다(Ahoy는 IRCv3를 완전히 지원하는 클라이언트입니다).

Hacker News에서 보기 ↗