Carnap Ten Years Later: Lessons Learned and Next Steps

당신이 45,000명의 학생들에게 논리 퍼즐을 푸는 법을 가르치고 있다고 상상해 보세요. 당신은 그들이 매일 연습하기를 원하지만, 수천 개의 손으로 쓴 증명들을 일일이 채점하는 것은 악몽과 같은 일입니다. 그래서 당신은 로봇 선생님을 만듭니다.

이것이 바로 그레이엄 리치-크로스(Graham Leach-Krouse)가 지난 10년 동안 전 세계 학생들을 위해 4백만 개 이상의 논리 문제를 채점해 온 웹 기반 도구인 **카르납(Carnap)**을 통해 실제로 한 일입니다. 하지만 이 로봇을 10년 동안 운영한 저자는 로봇이 다소 서툴러지고 있다는 것을 깨달았고, 이제 아주 매끄럽고 새로운 버전을 만들 때가 되었다는 것을 알게 되었습니다.

여기서 무엇이 잘 되었고, 무엇이 잘못되었으며, 이를 고치기 위해 어떤 반짝이는 새로운 도구들이 만들어지고 있는지에 대한 이야기가 있습니다.

원래의 로봇: 조금은 엉망인 천재

원래의 카르납은 거대한 올인원 스위스 아미 나이프처럼 만들어졌습니다. 그것은 해스켈(Haskell)이라는 매우 멋진 프로그래밍 언어로 작성되었습니다. 저자는 이것이 무료(학생들에게 비용이 들지 않도록)이고, 웹 기반(번거로운 소프트웨어 설치가 필요 없도록)이며, 유연(단순한 수학부터 복잡한 철학까지 모든 종류의 논리를 가르칠 수 있도록)이기를 원했습니다.

잘 된 점:

• 웹: 웹사이트에 배치한 것은 큰 승리였습니다. 학생들은 설치 화면과 싸울 필요 없이 그냥 링크를 클릭하기만 하면 되었습니다.
• 피드백 루프: 가장 좋았던 부분은 "즉각적인 피드백"이었습니다. 학생이 증명을 입력하면 로봇은 줄 단위로 확인했습니다. 만약 실수를 하면, 즉시 "아니요, 다시 시도하세요"라고 말해주었습니다. 이는 학생들이 숙제를 하는 것이 아니라 게임을 하는 것처럼 느끼는 "플로우 상태(flow state)"를 유지할 수 있게 해주었습니다.
• 유연성: 저자는 휴트 알고리즘(Huet's algorithm)이라는 영리한 트릭을 사용하여 로봇이 수십 권의 논리 교과서를 이해할 수 있도록 했습니다. 그것은 마치 모든 논리 방언을 즉시 말할 수 있는 번역기를 가진 것과 같았습니다.

잘 안 된 점:

• "올인원"의 함정: 저자는 모든 것을 하나의 커다란 코드 블록 안에 담으려 했습니다. 그림을 그리는 부분, 수학을 체크하는 부분, 성적을 저장하는 부분이 모두 뒤엉켜 있었습니다. 만약 수학 체크 기능을 수정하기 위해 작은 버그 하나를 고치려 한다면, 실수로 성적 저장 시스템을 망가뜨릴 수도 있었습니다. 그것은 마치 바퀴가 여전히 돌아가고 있는 자동차의 엔진을 수리하려는 것과 같았습니다.
• "버스 요인(Bus Factor)": 코드가 너무 엉켜 있고 설치가 까다로운 특정 설정을 사용했기 때문에, 다른 사람들이 도움을 주는 것이 거의 불가능했습니다. 만약 메인 제작자가 버스에 치기라도 한다면(시스템 작동 방식을 아는 유일한 사람을 잃는 것에 대한 프로그래머들의 고전적인 농담입니다), 프로젝트는 끝날 수도 있었습니다.
• 신뢰 문제: 학생들은 로봇을 신뢰해야 합니다. 만약 로봇이 오작동하거나, 혼란스러운 에러 메시지를 주거나, 이상하게 행동한다면, 학생들은 논리 자체를 의심하기 시작합니다. 그들은 "내가 틀렸다"라고 생각하는 대신 "로봇이 고장 났다"라고 생각하게 됩니다. 기존 시스템에는 이러한 신뢰를 깨뜨리는 작은 결함들이 너무 많았습니다.

진단: 왜 오래된 로봇은 은퇴해야 하는가

저자는 오래된 시스템을 살펴보고 그것이 "이중 모놀리스(dual-monolith)" 구조로 구축되었다는 것을 깨달았습니다. 이것은 주방, 침실, 화장실이 벽 없이 하나의 거대한 방으로 되어 있는 집과 같습니다. 주방을 개조하려면 화장실을 허물어야 하는 식입니다.

구체적인 문제는 브라우저에서 실행하기 위해 사용된 기술이었습니다. 저자는 자신의 멋진 코드를 웹 코드로 변환하기 위해 GHCJS라는 도구를 사용했습니다. 하지만 이 도구는 이제 "사용 중단(deprecated)" 되었습니다(기본적으로 제작자에 의해 은퇴했다는 뜻입니다). 오래된 시스템을 업데이트하려는 시도는 더 이상 맞지 않는 부품으로 자동차 엔진을 교체하려는 것과 같습니다. 그것은 고통스럽고, 비용이 많이 들며, 실패할 가능성이 높습니다.

새로운 설계: "모듈형"의 꿈

이 논문은 거대한 로봇을 서로 대화하는 세 개의 전문화된 작은 로봇으로 나누는 완전한 재설계를 제안합니다.

1. 작은 검증기 (mm0-zig): 이것은 증명이 실제로 옳은지 확인하는 "두뇌"입니다. 이것은 Zig라는 새로운 언어로 작성되었으며 매우 작습니다—코드 라인이 약 4,500줄에 불정합니다. 매우 작기 때문에 인간이 전체를 읽고 "그래, 이건 믿을 수 있어"라고 말할 수 있습니다. 이것은 거대한 수학 라이브러리에 대해 200밀리초 미만으로 증명을 순식간에 확인하도록 설계되었습니다.
2. 컴파일러 (Aufbau Bytecode Compiler 또는 abc): 이것은 "번역기"입니다. 이것은 학생이 쓰는 복잡하고 무질서한 방식(예: 화려한 비주얼 에디터 사용)을 가져와서 깔끔한 바이너리 인증서로 변환합니다. 이것은 학생이 어떻게 썼는지는 상관하지 않습니다. 단지 최종 결과가 유효한지만 확인합니다.
3. 서버: 이것은 단순히 "파일 캐비닛"입니다. 과제와 성적을 저장합니다. 무거운 생각을 하지 않고, 단지 데이터를 관리할 뿐입니다.

새로운 시스템의 마법:

• 더 이상 엉킨 전선은 없다: 만약 새로운 유형의 논리(예: 새로운 교과서)를 추가하고 싶다면, 두뇌나 파일 캐비닛을 다시 쓸 필요가 없습니다. 컴파일러에 새로운 규칙 세트만 주면 됩니다.
• 신뢰할 수 있음: "두뇌"(mm0-zig)는 매우 작고 단순하여 한 사람이 감사(audit)할 수 있습니다. 일단 확인되면, 더 이상 바꿀 필요가 없습니다.
• 빠름: 새로운 검증기는 기존의 C 기반 버전만큼 빠르며, 특정 테스트 케이스에 대해 평균 7.1밀리초로 실행됩니다(기존의 6.1밀리초와 비교했을 때). 이는 인간에게 즉각적으로 느껴지기에 충분히 빠른 속도입니다.

미래: 다음 단계는?

저자는 새로운 시스템이 아직 완성되지 않았음을 인정합니다. 현재 "번역기"(abc)는 텍스트 에디터와 가장 잘 작동하는데, 이는 논리 수업을 처음 듣는 초보자에게는 여전히 무섭게 느껴질 수 있습니다. 계획은 번역기와 대화하는 더 풍부한 시각적 인터페이스(예: 드래그 앤 드롭 방식의 증명 트리)를 구축하는 것입니다.

여기서의 큰 교훈은 단지 코드에 관한 것이 아니라, 신뢰에 관한 것입니다. 당신이 학생이든, 교사든, 혹은 코더든, 당신이 사용하는 도구를 신뢰해야 합니다. 예전의 카르납은 제 역할을 해낸 영웅이었지만, 엉망이었습니다. 새로운 카르납은 학생들이 소프트웨어와 싸우는 것이 아니라 논리에 집중할 수 있도록, 더 가볍고, 강력하며, 투명하게 구축되고 있습니다.

요약하자면, 예전의 로봇은 천재적이지만 엉망인 천재였습니다. 새로운 로봇은 전문적이고 신뢰할 수 있는 전문가 팀이며, 다음 세대의 사상가들이 혼란의 중력을 벗어나 자신들의 추론에서 "탈출 속도"에 도달할 수 있도록 도울 준비가 되어 있습니다.