2021년 어느 날, 디자인 협업 도구 Figma는 직원들이 돌아가며 회사 소셜 계정을 운영하는 "테이크오버"를 진행했다. 그날 계정을 맡은 직원 한 명은 자신이 추적했던 한 가지 사건을 트위터 스레드로 풀어놓았고, 지금 남아 있는 글은 그 스레드를 보존한 아카이브다. 제목부터 도발적이다. "버그가 아니었던 Figma 버그 이야기." 핵심 주장은 간결하다. 사용자들이 명백한 버그라고 신고한 어떤 동작이, 알고 보니 수십 년 전에 내려진 키보드 관련 설계 결정이 뒤늦게 표면으로 떠오른 결과였다는 것이다.
이야기의 구체적인 기술적 메커니즘과 재현 과정은 원래 스레드 안에 담겨 있고, 이 글에서 새로 지어낼 수는 없다. 그러나 제목과 부제가 전하는 뼈대만으로도 소프트웨어를 만드는 사람에게는 익숙한 장면이 떠오른다. 분명히 우리 제품이 잘못 동작하는 것처럼 보이는데, 파고들수록 문제의 뿌리가 우리가 작성한 코드가 아니라 그 아래 수많은 계층, 더 거슬러 올라가면 운영체제와 입력 표준, 심지어 물리적 키보드의 오래된 약속에 있었던 경험 말이다.
버그라는 이름의 오해
현장에서 "버그"라는 단어는 생각보다 넓은 것을 덮어 가린다. 진짜 결함도 있지만, 상당수는 과거에 누군가가 의도를 가지고 내린 결정이 다른 맥락에서 낯설게 보이는 경우다. 하위 호환성을 지키기 위해 일부러 남겨 둔 동작, 특정 플랫폼의 관례를 따른 처리, 오래전 표준이 강제한 제약 같은 것들이 그렇다. 이런 동작은 그것이 만들어진 환경에서는 합리적이었지만, 환경이 바뀌고 세대가 교체되면 아무도 그 이유를 기억하지 못한 채 "이상한 버그"로 신고된다. Figma의 사례가 사람들의 공감을 산 지점도 바로 여기에 있다.
키보드와 문자 입력은 그런 오해가 쌓이기에 특히 좋은 지층이다. 사용자가 키를 누르는 순간부터 화면에 글자가 찍히기까지는 하드웨어, 운영체제의 입력 처리, 키 배열과 레이아웃 규약, 문자 인코딩, 애플리케이션의 이벤트 처리가 겹겹이 개입한다. 이 사슬의 어느 한 고리에 오래전 박아 둔 결정이 있으면, 그 위에 올라앉은 최신 웹 애플리케이션은 자신이 만들지도 않은 과거의 선택을 그대로 상속받는다. 수십 년 전의 결정이 "뒤늦게 역풍이 되어 돌아온다"는 부제는 이 상속 구조를 압축한 표현이다.
실무자에게 남는 교훈
실무적으로 이 이야기가 주는 첫 번째 시사점은 조사 방법에 있다. 재현되는 현상을 표면에서 판단하지 말고 입력 계층을 한 칸씩 내려가며 추적해야 한다는 것이다. 같은 조작이 운영체제나 키보드 레이아웃, 브라우저가 달라질 때 어떻게 변하는지 비교하면, 문제의 책임이 어느 지층에 있는지 좁혀진다. 두 번째는 오래된 동작을 함부로 "고치면" 안 된다는 점이다. 겉보기에 버그 같은 동작이라도 그 위에서 수많은 사용자의 작업 흐름이 균형을 잡고 있을 수 있어, 성급한 수정이 오히려 더 큰 회귀를 부른다.
세 번째는 제도적 기억의 가치다. 이런 추적담을 직원이 직접 들려줄 수 있었던 것은, 결국 누군가가 원인을 끝까지 파고들어 기록으로 남겼기 때문이다. 왜 이 동작이 이렇게 되어 있는지에 대한 배경 설명이 코드 주석이나 이슈 트래커에 남아 있는 조직과, 그렇지 않아 매번 같은 수수께끼를 처음부터 다시 푸는 조직의 차이는 시간이 갈수록 벌어진다. 겹겹의 호환성 계층 위에서 일하는 오늘의 개발자에게는 특히 그렇다.
읽을 때의 한계
다만 이 글을 받아들일 때 분명히 해 둘 점이 있다. 지금 남아 있는 것은 한 직원의 개인 스레드를 보존한 아카이브이며, 사건을 독립적으로 검증한 기술 문서가 아니다. 어떤 키, 어떤 운영체제, 어떤 입력 경로가 문제의 핵심이었는지 구체적인 재현 절차는 원 스레드에서 확인해야 하고, 그 세부를 추정으로 채우는 것은 바람직하지 않다. 또한 이것은 2021년의 이야기여서, 그사이 Figma나 관련 플랫폼의 동작이 바뀌었을 가능성도 열어 두어야 한다. 그럼에도 이 작은 일화가 오래 회자되는 이유는 분명하다. 우리가 매일 쓰는 소프트웨어가 얼마나 깊은 역사적 결정 위에 서 있는지, 그리고 그 결정이 언제든 현재의 버그 리포트로 되살아날 수 있음을 선명하게 보여 주기 때문이다.