시리즈: [AI와 같이 고친 에러들]
이번 작업은 거창한 개발이 아니었다. 김부장이 리눅스 민트에서 외장 메모리에 들어 있는 영상을 보려고 했고, 처음에는 “그냥 더블클릭하면 열리겠지” 정도로 생각했다. 그런데 파일 확장자도 낯설고, 기본 플레이어로 바로 열리지 않았다. 비개발자 입장에서는 여기서부터 막힌다. 이게 영상 파일이 맞는지, 코덱 문제인지, 파일이 깨진 건지 구분이 안 되기 때문이다.
첫 번째 막힘: 파일은 있는데 정체를 모르겠다
AI와 먼저 한 일은 폴더 안의 파일을 무작정 실행하는 게 아니라, 파일 목록과 형식을 확인하는 일이었다. 로그에는 .jdr 파일들이 보였고, file, strings, xxd 같은 도구로 앞부분을 살펴봤다. 저한테는 생소한 명령어들이지만, AI가 설명해준 핵심은 단순했다. “겉으로는 일반 동영상처럼 안 보여도, 안쪽에는 H.264 영상 데이터 흔적이 있다”는 것이었다.
여기서 배운 점이 있다. 리눅스에서 무언가 안 열린다고 해서 바로 포기할 필요는 없었다. 파일 확장자보다 실제 내부 형식을 확인하는 과정이 먼저였다. 비개발자인 저는 이 단계가 특히 좋았다. “왜 안 되지?”에서 “무엇이 안 되는지”로 질문이 바뀌었기 때문이다.
두 번째 막힘: 코덱 설치는 됐는데 apt가 깨끗하지 않다
영상 재생을 위해 필요한 패키지를 설치하려고 했다. 그런데 설치 과정 끝에서 전혀 다른 에러가 튀어나왔다. H.264 코덱 문제가 아니라, 예전에 설치된 무선랜 드라이버 DKMS 모듈이 새 커널에서 빌드 실패를 낸 것이다. 로그에는 rtl88x2bu, dkms autoinstall, linux-headers, dpkg returned an error code 같은 말들이 줄줄이 나왔다.
처음 봤을 때는 겁이 났다. “영상 보려고 코덱 하나 깔았는데 리눅스가 망가진 건가?” 싶었다. 그런데 AI는 바로 결론부터 내리지 않았다. 현재 커널, 실제 연결된 와이파이 장치, 로드된 드라이버, DKMS 상태를 나눠서 확인했다. 그 결과 실제 사용 중인 무선랜은 다른 드라이버로 동작하고 있었고, 실패한 DKMS 모듈은 현재 연결 자체를 담당하는 핵심 드라이버가 아니라는 점을 알 수 있었다.
세 번째 막힘: 에러가 있어도 결과물은 검증해야 한다
재미있는 건, apt는 끝에서 에러를 냈지만 필요한 도구 일부는 설치되어 있었다는 점이다. AI는 ffmpeg, ffprobe, gst-play, celluloid가 실제로 존재하는지 다시 확인했다. 그리고 샘플 파일을 읽어 H.264로 인식되는지, 짧은 MP4 미리보기로 변환되는지까지 확인했다. “설치 명령이 에러로 끝났다”와 “아무것도 설치되지 않았다”는 같은 말이 아니었다.
이 부분이 오늘의 핵심 교훈이었다. 비개발자는 빨간 에러 한 줄만 보면 전체가 실패한 것처럼 느낀다. 하지만 실제로는 어느 단계까지 성공했고, 어느 단계에서 실패했는지를 나눠 봐야 한다. 이번에는 코덱과 변환 도구는 들어왔고, 별도로 정리해야 할 문제는 오래된 DKMS 드라이버와 dpkg 상태였다.
AI와 같이 하니 좋았던 점
제가 혼자였다면 검색창에 에러 메시지 전체를 붙여넣고, 아무 해결책이나 따라 했을 가능성이 크다. 특히 “lock 파일을 지워라”, “드라이버를 다시 깔아라” 같은 위험한 글을 봤을 수도 있다. 하지만 AI와 같이 보니 순서가 달랐다. 먼저 현재 상태를 읽고, 필요한 도구가 설치됐는지 확인하고, 실제 사용하는 드라이버와 실패한 드라이버를 분리했다.
김부장에게 바이브코딩은 코드를 많이 치는 일이 아니라, 이런 식으로 컴퓨터가 내놓는 메시지를 해석하는 훈련에 가깝다. 에러를 없애는 것보다 더 중요한 건, 에러가 가리키는 범위를 좁히는 일이었다.
다음 편 예고
다음에는 이 흐름에서 이어진 “오래된 노트북을 실습용 가상머신 환경으로 만들기” 이야기를 따로 정리해보려고 한다. 리눅스 민트, KVM, Windows VM, 그리고 오래된 하드웨어에서 무리하지 않는 선택 기준까지 김부장식으로 남겨두면 나중에 같은 실수를 덜 할 것 같다.