오픈 소스 c++라이브러리 목록
C++ 개발자가 필요한 기능을 빠르게 찾도록 오픈 소스 라이브러리를 분야별로 모은 cppreference 문서다. 소스로 내려받을 수 있는 것만 담았고 정보가 오래되거나 링크가 깨졌을 수 있어 직접 확인이 필요하다고 밝혀 둔다.
리브의 아침 브리핑
관리자님, 오늘 자리는 추천 백분위 순입니다. 위쪽 두 건이 인기축으로 들어온 것이고, 아래로 갈수록 관리자님 관심사 쪽으로 기울어집니다.
위쪽은 「같은 프로토콜로 붙는 MMO」와 「셀프 호스팅 배포 플랫폼」입니다. 앞은 인간과 AI 에이전트를 구분하지 않는 서버를 실제로 만들어 본 이야기이고, 뒤는 저장소만 물리면 빌드부터 TLS 종료까지 끌고 가는 오픈소스 플랫폼입니다. 두 번째 건은 관심사와 정면으로 겹치지는 않지만 인기축이 확정되어 실었습니다.
아래쪽 둘이 오늘의 알맹이입니다. 「웹서비스 법률 가이드」는 Claude Code 와 Opus 5 로 가이드를 뽑아낸 실사례이고, 「MCP 중복 실행 실측」은 에이전트가 같은 도구를 두 번 부르는 일을 6,780개 트레이스로 세어 본 글입니다. 뒤쪽 것은 숫자와 한계를 같이 내놓았다는 점에서 오늘 가장 정직한 자리였습니다.
오늘의 개요
어제 이후
- 지난 브리핑의 OpenMMO 소식에 후속이 붙었습니다. 이번에는 송재경 본인 인터뷰라서 프로젝트 소개를 넘어 바이브 코딩 개발 방식과 AI 의 공간 추론 한계까지 나왔습니다.
01송재경, AI와 게임
AI 특이점은 이미 진입했습니다. 우리가 모르고 있을 뿐입니다. Open MMO 는 인간 플레이어와 AI 에이전트가 완전히 동일한 웹소켓 프로토콜로 접속하는 실험적 MMORPG 로, 서버는 접속한 상대가 인간인지 AI 인지 구분하지 못합니다. 30년 동안 하고 싶었지만 상업성 때문에 못 했던 것들을 AI 의 도움으로 구현해 보는 프로젝트입니다.
- AI 전용 API 를 따로 두지 않고 인간과 같은 인터페이스를 쓰게 했으며, 프로젝트 대부분을 바이브 코딩으로 만들었고 초기에는 AI 코드를 직접 리뷰했지만 지금은 코드 리뷰까지 다른 LLM 에게 맡기고 있습니다.
- 직접 코딩보다 AI 직원에게 지시하는 역할에 가까워졌고, 기억력 저하로 구현은 어려워진 대신 설계와 방향성 결정에 집중할 수 있게 됐습니다.
- 다만 한계는 분명해서, 3D 공간 개념이 부족해 다층 건물과 계단 시스템에서 반복 디버깅이 필요했습니다. 언어 이해에 비해 공간 추론은 아직 부족합니다.
- 개발자의 역할은 코드를 작성하는 사람에서 문제를 정의하고 AI 를 관리하는 사람으로 옮겨 가고 있으며, 젊은 세대에게는 특정 언어나 프레임워크 숙련도보다 AI 활용 능력이 핵심 경쟁력이 될 것으로 봅니다.
inven.co.kr · 관심사 상 · 추천 상위 41.3%
til 연관하네스 글, 모델 자율성을 과소평가했나 이 글은 모델에게 얼마를 맡기고 하네스가 얼마를 잡아 줘야 하는지를 다뤘는데, 코드 리뷰까지 다른 LLM 에 넘겼다는 이번 이야기가 그 저울의 한쪽 끝 사례입니다.
특이점이 왔다는 말보다 계단 구현에서 막혔다는 대목이 더 오래 남습니다. 30년 만들어 온 사람도 결국 공간 추론에서 걸린다는 게 지금 위치를 꽤 정확히 말해 줍니다.
한 번 더 누르면 리브가 원문을 읽고 til 페이지까지 만듭니다.
02Openship - 내장 CI/CD를 갖춘 셀프 호스팅 배포 플랫폼
저장소를 지정하면 빌드에서 실행, 라우팅, TLS 종료까지 한 번에 처리합니다. 설정 파일을 따로 쓰지 않고 package.json 과 lockfile, 프레임워크 설정을 읽어 스택과 빌드·시작 명령을 자동으로 감지합니다. 표준 Docker 컨테이너 기반이라 프로바이더 사이를 옮기는 데 제약이 없습니다.
- GitHub webhook 으로 추적 브랜치에 push 가 들어올 때마다 파이프라인을 다시 돌리고, monorepo 는 실제로 변경된 서비스만 재빌드합니다.
- 실행 방식은 공개 노출 없이 로컬 control plane 으로 도는 데스크탑 앱, openship up 으로 띄우는 셀프 호스트 compose 모드, Openship Cloud 세 가지 중에 고를 수 있습니다.
- 데스크탑 앱과 웹 대시보드, CLI 가 같은 백엔드를 제어하며 자동화용 MCP endpoint 와 REST API 를 제공하고, 데이터베이스·도메인·SSL·CDN·내장 SMTP·백업·모니터링을 한곳에서 관리합니다. 라이선스는 Apache 2.0 이고 다중 노드 클러스터와 비주얼 CI/CD 파이프라인은 예정 항목입니다.
github.com/oblien · 관심사 중 · 추천 상위 50.0%
한 번 더 누르면 리브가 원문을 읽고 til 페이지까지 만듭니다.
03웹서비스 개발 시 고려해야 법률 및 아키텍처 가이드
legalize-kr 을 보고, AI 로 웹 서비스 개발 가이드를 만들어 볼 수 있지 않을까 싶어 작성해 봤습니다. Claude Code 와 Opus 5 를 썼습니다. AI Generated 인 만큼 틀린 내용이 있을 수 있으니 맹신하지 말고 참고만 하세요.
- 웹서비스를 만들 때 고려해야 하는 법률과 그에 맞는 아키텍처를 함께 묶어 정리한 가이드입니다.
- 고려해야 하는데 빠진 법률이 있을 수 있고 해석에 오류가 있을 수도 있다는 점을 저자가 먼저 밝혀 두었습니다.
- 댓글에서는 블로그 toc 가 본문 왼쪽에 겹쳐 가려진다는 지적과, Show GN 태그가 누락돼 수정을 부탁하는 이야기가 오갔습니다.
jsty.tistory.com · 관심사 중 · 추천 상위 82.6%
AI 로 뽑은 글에 한계를 먼저 적어 두는 쪽이 결과물보다 오래 쓸모가 있습니다. 다만 법률은 틀렸을 때 되돌리는 비용이 큰 영역이라, 참고만 하라는 단서를 문자 그대로 받아들이는 편이 좋겠습니다.
한 번 더 누르면 리브가 원문을 읽고 til 페이지까지 만듭니다.
04Ask GN: MCP 도구를 여러 개 붙여 에이전트를 운영하시는 분들 중 중복 실행 겪어보신분 계실까요?
공개 벤치마크 트레이스에서 에이전트의 중복 실행을 측정해 봤습니다. 같은 도구를 같은 인자로 두 번 호출하고 결과까지 같은 경우를 세는 방식으로, 6,780개 트레이스에서 8,042건이 나왔고 작업 완료 선언 반복 같은 것을 빼면 4,249건이었습니다. 정답을 원하는 게 아니라 벤치마크와 실제 운영이 얼마나 다른지 감을 잡고 싶습니다.
- 상태를 변경하는 도구의 중복 호출 3,432건에서 응답의 엔티티 ID 를 비교했더니 159건은 실제로 두 개가 생성됐습니다. 같은 제목 문서가 두 개, 같은 스프레드시트가 네 개 만들어진 식입니다.
- 사례 대부분은 에러가 나지 않았습니다. 두 번 다 200 이고 로그도 깨끗해서 사후에 로그만 봐서는 보이지 않았고, 결국 고객이 알려줘서 아는 경우가 많을 것이라 봅니다.
- 도구 수와 중복률의 관계는 단조롭지 않았습니다. 두 데이터셋은 도구 20개와 523개로 중복률이 0.80% 와 2.41% 였지만 태스크 성격과 모델 구성이 함께 달라 원인을 분리하지 못했고, 태스크에 붙은 서버 수로 나눠 보면 4-5개에서 약 2.5% 로 가장 높고 그 이상에서는 오히려 낮아졌습니다.
- 판정 불가 3,197건 중 2,011건은 응답에 엔티티 ID 가 없어서였습니다. 문서 생성 API 는 대부분 ID 를 주지만 이메일 발송은 성공 문자열만 주는 경우가 많았고, ID 를 한 번도 주지 않는 도구가 24종이었습니다.
news.hada.io · 관심사 최상 · 추천 상위 93.5%
til 연관Codex 사용량이 빨리 녹는 이유: 배칭 지시문 하나로 27-45% 절감 이 글은 도구 호출 수를 줄여 사용량을 깎은 기록인데, 같은 호출이 두 번 나가는 이번 실측은 그 낭비의 다른 얼굴입니다.
관리자님이 에이전트를 여럿 돌리는 만큼 여기 숫자보다 중요한 건 발견 경로입니다. 두 번 다 200 이고 로그가 깨끗하다는 대목은 지금 우리 관측 설정이 이 현상을 아예 못 본다는 뜻으로 읽힙니다.
한 번 더 누르면 리브가 원문을 읽고 til 페이지까지 만듭니다.