▲

25년 된 커널 드라이버를 Claude Code로 현대화하기

 (dmitrybrant.com)
9P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • ftape 드라이버는 1990년대 백업테이프(QIC-80)에서 데이터를 복구할 수 있는 유일한 리눅스 오픈소스 커널 드라이버임
  • 하지만 해당 드라이버는 2000년 이후 더 이상 유지보수되지 않아, 구형 리눅스 환경에서만 사용할 수 있었음
  • Claude Code를 활용해 오래된 소스코드를 최신 리눅스 커널에 맞도록 리팩토링하고, 독립형 커널 모듈로 성공적으로 변환함
  • 과정에서 Claude는 자동으로 구식 함수와 구조체를 최신 API로 전환하며, 사용자가 수동으로 출력 결과를 분석해 일부 설정 오류를 교정함
  • AI 코딩 에이전트 활용 경험을 통해 프로그래머의 역량 증폭, 신기술·프레임워크에 빠르게 온보딩하는 방법에 대해 인사이트를 얻음

배경: 오래된 백업 테이프의 복구와 ftape 드라이버

  • QIC-80 등 테이프 카트리지에서 데이터를 복구하는 것이 저자의 취미 중 하나임
  • 이러한 테이프는 대부분 플로피 컨트롤러에 연결된 특수 테이프 드라이브가 필요함
    • 해당 드라이브는 주로 1990년대 소규모 사업장이나 개인이 백업용으로 사용함
    • 플로피 컨트롤러를 사용하는 방식은 별도의 SCSI 어댑터 없이 저렴하게 구현할 수 있었으나, 속도 제한(500Kbps) 과 비표준 프로토콜 등 여러 단점이 존재함
  • 이 테이프 장치와 통신하기 위해서는 리눅스에서는 ftape 커널 드라이버가 필수임
    • ftape로만 순수 원시 바이너리 데이터를 읽을 수 있기 때문에, 복구에 반드시 필요함
  • 그러나 ftape 드라이버는 2000년 무렵 이후로 유지보수되지 않아, 최신 리눅스 커널에서 사용할 수 없었음
    • 따라서 데이터를 복구할 때마다 구식 리눅스(CentOS 3.5 등)를 직접 부팅해야만 했음

Claude Code로 커널 드라이버 현대화 시작

  • Claude Code에게 리포지토리 설명과 함께 "최신 커널에서 빌드 가능하도록 드라이버를 현대화"해달라고 요청함
  • Claude는 현재의 커널 API 및 구조에 맞게 구식 함수와 구조체를 찾아내 교체함
    • 여러 번의 피드백 및 수동 보정 과정을 거쳐, 오류 없이 컴파일 되는 드라이버 코드 완성
  • 초기 코드는 전체 커널 소스 트리 내에서만 빌드가 가능했으나, 추가 요청을 통해 독립형 외부 모듈 빌드 시스템을 자동으로 생성함
    • 이를 통해 .ko 파일로 커널 모듈을 따로 만들 수 있게 되어 실제 하드웨어 연결 테스트 돌입

문제 해결 과정

  • 커널 모듈이 정상적으로 로드됐으나, 드라이브 인식·통신 문제가 발생함
    • sudo 권한이 필요한 작업이라 Claude가 직접 반복 실행은 불가, dmesg 로그를 수동으로 전달하며 문제점 추적
  • Claude가 로그와 기존 성공 사례 비교를 통해, 기본 I/O 포트 주소 미설정 및 파라미터 초기화 관련 버그를 발견
    • 기본값이 -1에서 0xffff로 변환되어 탐지 실패, 올바른 주소로 재설정해 해결
  • 최종적으로 모듈이 정상적으로 로드되고, 테스트 테이프의 데이터 덤프에 성공함

AI 코딩 에이전트와 협업 경험의 시사점

  • Claude Code와의 상호작용은 "주니어 개발자와의 협업" 처럼 실제 엔지니어와 일하는 느낌임
    • 사용자가 아키텍처 결정, 문제 발견 및 방향성을 주도적으로 가져가야만 함
  • 도메인에 특화된 키워드와 구체적 요청을 할수록 효과적임
  • AI 에이전트는 알맞은 유형의 작업이 주어질 때 생산성이 급격히 높아지므로, 한계와 강점을 이해하는 감각 필요
  • 본인의 역량을 AI가 배로 증가시켜줌. 수작업으로 했다면 몇 주 걸릴 작업을, 일상적인 대화와 피드백만으로 며칠 만에 완료 경험
    • 이 과정에서 현대 커널 개발 관행, x86 아키텍처, 새 명령어 라인 툴 등 실제 유용한 스킬도 학습
  • 새로운 프레임워크(Rust, Flutter 등)에 대한 초기 온보딩·적응 과정을 대폭 빠르게 해준다는 점 강조

결론: ftape, 다시 살아나다

  • 25년 만에 ftape가 다시 최신 리눅스에서 빌드 및 사용 가능해짐
  • 저자는 추가적인 기능 개선과 테스트를 진행 중이며, 플로피 기반 드라이브에 더해 병렬 포트 기반 장치도 지원 확인함
  • 물리적 장치는 예전과 거의 같지만, 운영체제는 CentOS 3.5 대신 Xubuntu 24.04로 변화함

참고

  • ftape 프로젝트 소스코드는 GitHub에서 공개되어 있음
  • 저자의 수집 장비 목록 등은 개인 블로그에서 확인 가능
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 직접 모듈을 로드하고 dmesg 출력을 반복해서 Claude에게 수동으로 붙여넣기했음
    Claude를 주로 사용하는 이유 중 하나는, 장시간 수행되는 프로세스를 시작하고 그 출력을 읽어서 디버깅할 수 있기 때문임
    여기서 수동 단계를 건너뛸 수 있는 다양한 해킹 방법이 있었음—예를 들어, dmesg를 로컬 UDP 포트로 파이프하고 Claude가 리스너를 시작하도록 하는 방법 등이 있음

  • 좋은 사례라고 생각함
    이런 툴을 사용할 때 두 가지 주요 효과를 얻는다고 봄
    첫째, 내가 이미 익숙한 프레임워크에서는 Claude가 반복적인 부분을 빠르게 패턴 매칭해서 생산성을 엄청나게 올려줌
    둘째, 새로운 프레임워크를 배울 때도 훨씬 빠르게 온보딩할 수 있음—이 점은 다양한 스택을 사용하는 대기업에서 특히 큰 도움이 됨
    AI의 역량을 제대로 파악하려면 빠르게 변화하는 기술과 프레임워크에 상당 시간을 투자해야 함
    Claude Code나 Claude 4.0을 100시간 이상 써보지 않았다면 그 가능성을 충분히 모를 수 있음
    "코더가 아닌 사람이 감으로 코딩해서 문제에 빠진다"는 시나리오가 X(구 Twitter) 상에서 보통이겠지만, 숙련된 개발자가 꾸준히 시간을 들이면 전혀 다른 경험을 하게 됨

    • 이 점이 핵심 포인트임
      나는 Claude Code를 하루도 빠짐없이 기존 코드베이스 변경에 메인 도구로 사용하고 있음
      시행착오 끝에 내 나름의 프로세스를 만들었고, 덕분에 생산성과 대형 실험의 도전 의지가 크게 상승함
      특히 내가 선행적으로 데이터 구조, 스키마, 내부 API를 설계하고 나면, Claude Code가 내부 툴의 UI를 거의 한 번에 잘 만들어주는 것이 정말 마음에 듦
      단순 반복 작업이나 프레임워크의 복잡성에서 벗어난 추상적 사고가 가능해져서, 16년 경력에 큰 전환점이 되어주었음

    • 맞음
      글쓴이가 Claude에게 Linux 2.4 드라이버를 6.8로 포팅해달라고 시킨 셈임
      온라인에 충분히 관련 자료가 있기 때문에 대부분의 일은 Claude가 처리했고, 정말 복잡한 핵심 부분에서만 글쓴이의 전문성이 필요했음
      "자신의 기술을 폭발적으로 증폭시키는 도구로 AI를 활용한다"는 말이 정말 와닿음
      여기서 자신이 가진 역량이 0이라면, AI로 곱해도 0에 가깝거나, 심지어 마이너스 생산성이 나올 수 있음

    • 우리 팀에도 LLM을 통해 새로운 영역을 과감히 시도하는 사람이 있지만, Claude 4 thinking agent를 모두에게 사용하도록 해도 엉뚱한 코드가 엄청 나오곤 함
      대부분의 코딩 커리어 동안 패턴 매칭에 익숙했다면 LLM 에이전트가 그 위에 또 패턴 매칭을 하는 셈인데, 이런 경험이 없는 팀원들에게는 오히려 골치가 아픔
      LLM 에이전트는 사람이 할 수 있는 패턴 매칭을 훨씬 빠르게 하지만, 범용적으로는 인간보다 딱히 뛰어난 것 같진 않음

    • 새로운 프레임워크 탐색뿐만 아니라 새로운 언어에도 유용함
      우리 팀은 Ruby를 쓰는데, Ruby는 읽기 쉬워서 문법을 굳이 배우지 않아도 LLM에게 코드를 작성하도록 시키고 직접 의사결정만 함
      Ruby를 몰라도 팀이 허용하는 수준의 코드를 곧장 쓸 수 있게 되어, 낯선 환경에서도 바로 생산적으로 일할 수 있음
      (참고: 팀원들이 Pull Request를 검토함)

    • "자신의 기술을 폭발적으로 증폭시키는 도구"라는 말이 이번 주에 작은 프로젝트를 10번 반복해서 만들어보는 과정에서 정말 체감됨
      AI로 어수선하게 만들어진 것들을 내가 가이드를 넣어서 마크업이나 스타일, JS 등을 깔끔하게 통합(consolidation)시키는 작업에서 진가가 발휘됨
      스타트업처럼 코딩 컨벤션이 약한 환경에서는 패턴 매칭 요청을 적용하기 어렵지만, 강력하고 성숙한 코드베이스에서는 전혀 다르게 효과를 볼 것이라고 상상함

  • 최대한 구체적으로 도메인 특화 키워드를 사용해서 프롬프트를 짜야 한다고 생각함
    특정 언어나 프레임워크에 대한 기술적 이해가 부족하면 프롬프트에 애매함이 생기고, 이 부분을 LLM이 임의로 채워넣기 때문에 의도와 다른 결과가 나오기 쉬움
    이런 애매함이 바로 버그의 원인이 됨
    "폭발적 증폭"의 이면임

    • "C 클래스에 튜플 생성자가 필요하다"고만 한다면, Claude가 "잠깐만요…"라고 답해주길 기대함

  • 이런 글을 읽으며, LLM 도입 전에는 수요에 비해 실제로 처리되는 일이 턱없이 부족했다는 점을 생각하게 됨

    • 나는 아직도 병목이 ‘실행’이 아닌 ‘시장성이 있는 아이디어’라고 생각함
      사람들이 실제로 돈을 내고 싶어하는 일의 수는 많지 않음

    • 항상 일거리가 모자라서가 아니라, 그 일을 할 선행 기술과 경험을 가진 사람이 부족해서 문제가 되는 것임
      커널 개발 경험이 없다면 아무리 프롬프트를 잘 짜도 글쓴이처럼 성과 나오기 어려움
      이론적으로는 모든 옛 드라이버를 최신 커널로 "현대화"하는 것이 LLM의 힘으로 가능할 것 같지만, 현실적으로는 반드시 인간의 감독(숙련자)이 있어야만 하고, 실제로 이런 전문가 수는 유지해야 할 드라이버 수에 비해 너무나 적음
      Alan Kay와 Joe Armstrong의 좋은 토론과 인터뷰가 있는데, 대부분의 코드는 명세 없이 타겟을 바꿔 컴파일하는 식으로 개발되지 않아 생기는 문제점을 언급함
      만약 공식 명세(spec)가 코드 외에 존재한다면 새 커널 타겟에 드라이버를 옮기는 일은 "명세를 새로 컴파일"하는 형태로 쉬울 것임
      하지만 지금은 명세가 아니라 옛 코드를 바탕으로 하니, 이전 코드를 현대 코드로 옮기는 과정에서 LLM은 비슷한 코드를 패턴 매칭할 뿐 진짜 의미를 이해하고 보장하지 못함—그래서 반드시 사람의 기술이 필요함

  • AI 덕분에 커널 해킹 진입 장벽이 낮아지겠다는 예감을 했었음
    매번 이게 사실임을 느끼고 있음
    곧 embedded/ARM 하드웨어 지원이 폭넓어지고, 새로운 경량 스마트 디바이스용 OS도 등장할 수 있을 것 같음

    • AI를 잘 활용하면 빠르게 실력을 끌어올릴 수 있음
      다만 대부분은 AI에 '집을 다 지어달라'고 요구하는데, 사실 '망치질을 도와주는 역할'로 사용해야 더 효과적임

  • AI의 역할과 한계에 대해 제대로 알고 적합하게 사용하는 개발자의 좋은 예라고 생각함
    특히 skepticism(비판적 시각) 덕분에 드라이버를 별도 모듈로 만든 점이 인상적임

  • 다른 사람이 언급하지 않은 ‘중대한 단서’를 짚고 싶음
    글쓴이가 “내가 커널 모듈 경험이 조금 있고 C 언어는 잘 다뤄서 Claude의 결과를 과도하게 띄우면 안 된다”고 명확히 밝힘
    즉, 정말로 세 번 묻자마자 커널 모듈이 완성된 게 아니고, 여러 번 대화를 주고받고 코드를 여러 차례 손으로 고쳤음
    기본적인 커널 모듈 내부 구조를 이해하지 못하면 결코 현대화 불가능했다고 말함—이 점은 어떤 코드 생성 툴을 쓰든 반드시 염두에 두어야 하는 콘텍스트임
    또 Claude Code와 협업하는 느낌이 “주니어 엔지니어와 함께하는 경험”과 비슷하다고 쓰였는데, 시키면 뭐든 하고, 실수 지적하면 바로 사과·칭찬하는 모습이 진짜 엔지니어라기보다는 아첨하는 스타일 같다고 평가함
    마지막으로, 글쓴이가 "진짜 원하면 혼자서도 이 작업을 할 수 있었지만, 25년 전 커널 개발 방식을 다시 배워야 했을 것"이라고 한 점에서
    결국 "레거시 솔루션을 정확히 이해하고 무엇이 필요한지 파악하는 것"이 현대화 작업의 본질임을 되짚음
    결정적으로, 배우지 않고 넘어가는 것이 이점으로 꼽힌 것 역시 흥미롭다고 생각함

    • 틀을 가르는 듯한 태도(gatekeeping)는 해로움
      agent가 내가 모르는 프로젝트를 설명해주는 게 매우 좋다고 느낌
      최근에 Firefox 소스를 클론하고 qwen-code를 사용해 Firefox의 AI 기능과 구현 방식을 묻고, 정말 멋지게 배움
      학습하는 방식이 훨씬 멋져졌음

  • 사람들에게 더 많은 힘을 실어주는 변화라고 생각함
    글쓴이는 오랜 기간 열정을 갖고 사이드 프로젝트를 해왔고, 도구 업그레이드는 정말 좋은 일임
    다만 분야가 너무 좁으면 커뮤니티에서 지원이 부족할 수 있는데, 여기서 LLM이 도와주면서 커스텀한 문제를 해결할 수 있음
    점점 진입 장벽이 낮아지고 있으며, 기술적 배경지식이 적은 사람도 더 단순한 특수 상황 문제까지 직접 풀 수 있는 시대가 올 것임
    더 많은 사람이 도전할 수 있게 해주는 긍정적인 변화임

  • 업그레이드 후 속도가 어떻게 바뀌었는지 궁금함

    • 같은 하드웨어를 같은 드라이버로 제어하니 속도는 똑같을 것임
답변달기