Writing Redis in Rust (CodeCrafters)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

CodeCrafters에서 Rust로 Redis를 구현하는 과정은 XADD의 응답 형식과 스트림 자료형 조회를 맞추며, 단계별 테스트를 실제 프로젝트 완성으로 이어가는 학습이다.

📌 핵심 요점

1. Rust 학습이 목적이므로 구현 선택은 직접 맡고 AI의 대행 범위를 제한한다. 다만 TCP 스트림에서 메모리 할당 없이 바이트를 읽는 부분에서는 AI의 도움을 받았다.
2. XADD 테스트는 bulk string을 기대했지만 구현은 simple string을 반환해 실패했다. 스트림에 데이터를 추가하는 동작뿐 아니라 응답 표현도 요구사항과 일치해야 한다.
3. XADD 응답 수정 뒤에는 스트림 자료형 검사에서 문제가 드러났다. 스트림에 대한 TYPE 명령 처리가 빠져 있어, 생성 기능과 자료형 조회를 함께 구현해야 했다.
4. CodeCrafters는 기능을 단계별로 나누고 테스트를 제공하면서 구현 방법은 학습자에게 맡긴다. 현재는 리스트 확장을 마친 뒤 스트림 생성 기능을 진행하는 단계다.
5. 과제 통과 이후에는 구조 재검토, 성능 측정, 자체 테스트, 빌드·CI 정비와 패키지 배포가 남는다. 진행자는 SaaS 등 다른 관심사보다 현재 Redis 작업을 우선한다.

🧩 배경과 문제 정의

• CodeCrafters의 Redis 구현 과제를 Rust 학습용으로 진행하며, 이전 작업인 성능 측정 설정과 XADD 구현을 확인한다. 학습이 목적이므로 AI가 구현을 지나치게 대신하지 않도록 하려 한다.
• 스트림 생성 기능은 명령 처리뿐 아니라 응답 형식과 자료형 조회까지 테스트의 기대 동작에 맞아야 한다.
• 과제 테스트 통과 이후에도 코드 구조 개선, 성능 측정, 자체 테스트와 배포 준비가 남는다. 단계별 과제를 자기 프로젝트로 발전시키는 방법이 주요 관심사다.
• 방송 초반에는 직접 만든 방송 관리 앱의 채팅 연동과 이모티콘 표시 문제를 점검한다. 후반에는 육아로 인한 피로와 향후 프로젝트의 우선순위가 개발 진행의 현실적인 제약으로 드러난다.

🕒 시간순 섹션별 상세정리

1. 여러 플랫폼의 채팅을 방송 화면에 연결하기

• 유튜브 댓글을 표시하려면 영상 ID를 별도로 지정해야 했으며, 화면에 메시지가 나타나지 않는 문제에는 브라우저 소스의 캐시 갱신이 필요했다. 갱신 후에는 메시지가 화면에 표시된다 [02:42]
• 트위터 메시지는 웹훅으로 전달되지만 도착 시점이 일정하지 않다. 방송 시작 약 1분 뒤부터 웹훅 전송이 시작되는 것 같다는 추정이며, 확정된 원인은 아니다 [03:22]

2. 이모티콘 ID를 이미지로 변환하지 못하는 문제

• 채팅에 실제 이모티콘 대신 식별자가 노출된다. 이모티콘 데이터를 확인해 해당 이미지를 가져오고, 텍스트 식별자 대신 채팅에 삽입하는 처리가 필요하다 [04:54]
• 메시지들은 직접 만든 방송 관리 앱을 거쳐 표시된다. 방송 연동 문제는 해결했지만 이모티콘 표시는 아직 해결하지 못했다 [05:26]

3. 플랫폼별 채팅 수집 방식과 메시지 누락의 원인

• 유튜브 API에는 할당량 제한이 있어, 할당량을 늘리는 대신 웹사이트에서 채팅 메시지를 수집하는 방식을 선택했다. 트위치는 IRC를 제공해 연동이 더 쉽지만, Kappa 같은 이모티콘은 별도 처리가 없으면 텍스트로 남고 BetterTTV 이모티콘도 추가 대응이 필요하다 [07:50]
• 이모티콘을 많이 넣은 메시지가 나타나지 않는 사례는 유튜브 채팅 자체에도 도착하지 않았다. 따라서 이 사례에서는 방송 관리 앱이 메시지를 받기 전 단계에서 누락된 것으로 판단한다 [09:10]

4. OpenCode와 공개 모델을 시험하려다 연결 설정을 보류하기

• OpenCode와 Pi Agent를 설치했고 Qwen 등 공개 모델을 시험하는 데 관심이 있다. 다만 모델별 과금 구조와 무료 제공 방식은 아직 잘 모르는 상태다 [11:26]
• OpenCode에서 OpenRouter를 연결하려면 API 키가 필요하다. 방송 중 로그인과 설정을 진행하는 일은 미루고, 당장은 기존의 Codex와 Antigravity를 사용하기로 한다 [12:39]

5. Neovim 선택과 손목 부담의 관계

• 편집기는 자신이 좋아하는 것을 사용하면 된다는 입장이다. 개인적으로는 PyCharm으로 시작했다가 Primeagen과 TJ의 영향을 받아 Neovim으로 옮겼다 [13:50]
• 오른손을 키보드와 마우스 사이에서 자주 옮기며 반복성 긴장 손상을 겪었다. Vim 사용이 부담을 조금 줄인 것 같다고 느끼지만, 효과를 확정적으로 단정하지는 않는다 [14:24]

6. 학습 목적에 맞춰 이전 Redis 작업을 복구하기

• Redis 구현은 학습용 과제이므로 AI가 너무 많은 작업을 대신하는 것을 원하지 않는다. 이번에는 이전 작업의 내용을 설명하고, 성능 측정 설정과 Redis XADD 구현이라는 두 변경을 커밋하도록 요청했다 [15:16]
• CodeCrafters 테스트를 실행하는 과정에서 데이터베이스의 ID와 필드가 아직 읽히지 않는다는 경고가 나온다. 현재 단계에서는 허용할 수 있는 경고로 판단한다 [15:58]

7. XADD 응답의 simple string과 bulk string 불일치

• XADD 테스트는 bulk string 응답을 기대하지만 구현은 simple string을 반환해 실패한다. 스트림 추가 기능과 별개로 응답 표현이 테스트의 요구와 맞지 않는다 [16:16]
• 명령 처리 코드는 프레임에서 인자를 추출하고 키, ID, 항목들을 database.xadd에 넘긴다. 현재 반환값이 simple string이라는 점을 확인하고 bulk string으로 바꾸는 수정을 시도한다 [17:24]

8. 과제 통과 이후에 필요한 프로젝트 완성 작업

• CodeCrafters 프로젝트를 여러 언어로 구현해 GitHub에 올리는 것은 포트폴리오가 될 수 있다. 다만 테스트 통과만으로 프로젝트가 완성되는 것은 아니며, 기본 구현 뒤에는 구조와 패턴을 재검토하고 성능을 측정하는 정리 단계가 필요하다 [18:49]
• 빌드와 CI를 정비하고 패키지로 배포하는 작업까지 확장하면 과제를 자기 프로젝트로 발전시킬 수 있다 [19:07]

9. CodeCrafters의 무료 과제와 단계별 검증의 가치

• 유료 이용을 권하지만, 결제하지 않아도 순환하는 무료 프로젝트를 선택할 수 있다고 보여준다. 본인은 유료 사용자라 현재 어느 프로젝트가 무료인지는 모른다 [21:56]
• CodeCrafters는 기능을 단계별로 나누고 각 단계에 특정 테스트를 제공한다. 직접 구현할 때 무엇부터 해야 할지 막막한 상황을 줄여 주는 학습 도구라는 점이 핵심 가치다 [22:35]

10. 스트림 생성 뒤 드러난 TYPE 명령의 누락

• XADD 수정 후 변경을 저장소에 푸시하자 테스트가 실행되지만, 스트림 자료형을 기대한 검사에서 해당 결과를 얻지 못한다 [23:29]
• 원인은 스트림에 대한 TYPE 명령 처리를 아직 구현하지 않은 데 있다. 스트림 생성에 이어 자료형 조회도 대응해야 한다 [23:38]

11. SaaS 개발의 매력과 당장의 작업 우선순위

• SaaS 개발에는 관심이 있지만 무엇을 만들지는 아직 정하지 않았다. 개발 과정을 보고 싶어 하는 시청자를 모으고 수익을 얻을 가능성도 매력으로 본다 [24:45]
• 앞으로 SaaS를 만들 수도 있지만 해야 할 일이 많아 한 번에 하나씩 진행하려 한다. 현재는 진행 중인 Redis 작업을 이어가는 쪽에 우선순위를 둔다 [25:02]

12. 구현 방법을 스스로 결정하는 학습과 후속 활동

• CodeCrafters는 기능이 무엇이고 어떻게 동작해야 하는지를 제시하고 테스트하지만, 구현 방법 자체를 알려 주지는 않는다. 이처럼 구현 선택을 학습자에게 남기는 방식을 긍정적으로 평가한다 [25:37]
• 오픈소스 기여와 RFC 읽기 같은 활동에도 관심이 있다. 다만 현재 과제를 먼저 마친 뒤 다른 활동으로 옮겨갈 가능성을 열어 둔다 [26:00]

13. 육아로 인한 피로 속에서 개발 방송을 이어가기

• 시스템 설계 등 더 많은 영상을 만들고 싶지만 최근 바빴고 피로도 쌓여 있다. 콘텐츠 제작을 늘리고 싶은 의지와 실제 여력 사이에 제약이 있다 [26:39]
• 최근 아이가 태어나 부부 모두 매우 피곤한 상태다. 그럼에도 방송과 Redis 구현을 계속해 조금씩 진전시키고, 다른 작업은 이후에 이어가려 한다 [27:37]

14. Redis 구현의 체감 난도와 AI 도움이 필요했던 부분

• SaaS가 Redis보다 쉽다는 의견에는 확신하지 않는다. 지금까지 진행한 Redis 구현은 대체로 직관적이고 크게 어렵지는 않았다는 개인적인 평가다 [29:34]
• 예외적으로 TCP 스트림에서 메모리 할당 없이 바이트를 읽는 부분에는 AI의 도움이 필요했다. 그 외의 구현은 지금까지 감당할 만한 수준이라고 본다 [29:49]

15. Redis의 TCP 읽기와 메모리 할당 방식 확인

• Redis가 TCP 스트림에서 바이트를 버퍼로 읽는지에 대한 질문이 나오면서, 실제 Redis의 처리 방식이 확인 대상이 된다 [30:54]
• 확인한 server라는 C 파일은 8,500줄 규모여서 바로 읽어 파악하기 어렵다. 이에 Gemini를 이용해 구현 방식을 알아보려 한다 [31:21]

16. Gemini의 긴 도구 호출과 진행 피드백 부족

• Gemini가 원래부터 나빴다는 의견에는 동의하지 않으며, 과거에는 좋았고 특히 ‘3.8’ 버전을 긍정적으로 평가한다 [32:25]
• 현재의 불만은 도구 호출에 지나치게 오래 걸리면서도 무엇을 하려는지, 어떤 생각이나 코드 내용을 검토하는지 피드백을 주지 않는다는 점이다 [32:38]

17. 화면 손상 확인과 방송 중단 결정

• 방송 끊김 우려가 나오지만 드롭된 프레임은 0으로 표시된다. 지표상으로는 안정적이어야 하는 상황에서도 화면이 픽셀처럼 깨진다는 문제가 제기된다 [33:05]
• 공유된 이미지를 보고 GPU 고장 가능성을 의심하지만 원인은 확정하지 못한다. 직접 미리보기를 확인한 결과 화면 상태가 심각하게 손상되어 있다 [33:38]

🧾 결론

• 기능 구현의 완료 여부는 명령 처리, 응답 형식, 관련 조회 명령까지 연결해서 확인해야 한다.
• 단계별 테스트는 구현 순서를 잡는 데 도움이 되지만, 테스트 통과만으로 프로젝트 전체가 완성되지는 않는다.
• AI를 활용하더라도 구현을 이해하고 선택하는 책임을 학습자에게 남기는 것이 이번 작업의 기준이다.

📈 투자·시사 포인트

• 개발 역량에 대한 시간 투자 관점에서는 과제 구현을 구조 개선·성능 측정·배포까지 확장하는 과정이 포트폴리오를 구체화할 수 있다.
• 학습 도구의 가치는 단계별 요구사항과 검증을 제공해 시작의 막막함을 줄이면서도 구현 선택권을 보장하는 데 있다.
• AI 개발 도구에 대한 평가에는 결과 외에도 도구 호출 속도와 진행 상황 피드백이 영향을 준다. 방송에서는 긴 대기와 설명 부족이 불만으로 제시됐다.
• SaaS와 개발 방송의 수익 가능성은 관심사로 언급됐지만, 제품이나 수익 모델은 정해지지 않았다. 현재의 구체적인 우선순위는 Redis 구현을 이어가는 것이다.

⚠️ 불확실하거나 확인이 필요한 부분

• XADD 응답 수정 뒤에도 스트림 TYPE 검사에서 실패했다. 제공된 내용만으로는 TYPE 구현 완료나 전체 테스트 통과를 확인할 수 없다.
• 실제 Redis가 TCP 바이트를 읽을 때 메모리를 언제 할당하고 버퍼를 어떻게 사용하는지는 질문으로 남았으며, 답은 확인되지 않았다.
• 구조 개선·자체 테스트·CI·배포는 후속 과제로 제시됐다. 특히 한 파일에 모인 코드와 자체 테스트 부족에 대한 언급은 이전 HTTP 서버 사례이므로 현재 Redis 저장소의 상태로 단정하면 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• XADD가 기대하는 bulk string 응답을 반환하는지 해당 단계 테스트로 다시 확인한다.
• 스트림 키에 대한 TYPE 처리를 구현하고, XADD로 생성한 키의 자료형 조회까지 검증한다.
• 과제 테스트와 별개로 저장소의 자체 테스트 현황을 확인하고, 응답 형식과 자료형 조회의 회귀 테스트를 마련한다.
• 기본 기능이 안정된 뒤 코드 구조와 성능 측정을 검토하고 빌드·CI·패키지 배포 작업을 구체화한다.

❓ 열린 질문

• 스트림 TYPE 처리를 추가한 뒤 해당 단계 테스트는 통과하며, 다음 확장 단계에서는 어떤 요구사항이 드러날까?
• 실제 Redis의 TCP 읽기 경로에서는 버퍼 확보·재사용·확장이 각각 언제 발생할까?
• 학습 효과를 유지하면서 AI에 맡길 설명·조사·구현의 범위를 어디까지 정할 것인가?