공산주의 시절 Apple II 클론과, 14년간 뭘 테스트하는지 모르고 테스트한 이야기

철의 장막 뒤에서 만들어진 Apple II

냉전 시대, 서방의 기술이 동구권으로 넘어가는 건 엄격히 통제되던 시절이 있었어요. 그런데 컴퓨터라는 물건이 워낙 매력적이다 보니, 동구권 엔지니어들은 서방 컴퓨터를 "역설계"해서 자체 클론을 만들어냈거든요. 루마니아에서는 Apple II를 기반으로 한 클론 컴퓨터들이 여럿 제작됐는데, 이건 단순한 복제가 아니라 나름의 엔지니어링이 들어간 작업이었어요.

이게 뭐냐면, 원본 칩셋을 구할 수 없으니 비슷한 동구권 부품으로 대체하고, 회로도를 새로 그리고, 때로는 원본보다 더 독창적인 설계를 넣기도 했다는 거예요. 마치 레시피만 대충 듣고 현지 재료로 요리를 재현하는 것과 비슷한데, 결과물이 꽤 그럴듯하게 돌아갔다는 게 놀라운 부분이에요.

14년간 뭘 테스트하는지 몰랐던 사연

이 글에서 정말 흥미로운 건 "14년간 자기가 뭘 테스트하고 있는지 몰랐다"는 이야기예요. 구체적으로는 특정 하드웨어나 소프트웨어의 호환성 테스트를 돌리면서, 자신이 테스트하고 있는 대상이 정확히 무엇인지 제대로 파악하지 못한 채 그냥 관성적으로 테스트를 수행해온 거예요.

이건 우리 업계에서 생각보다 자주 일어나는 일이에요. 테스트 코드가 레거시로 쌓이다 보면, 원래 왜 이 테스트를 작성했는지, 이 테스트가 실제로 검증하는 게 뭔지 아무도 모르는 상태가 되거든요. CI 파이프라인에서 초록불만 들어오면 "잘 돌아가나 보다" 하고 넘어가는 거죠. 그런데 그 초록불이 실제로는 아무것도 검증하지 않고 있다면요?

테스트의 본질: "내가 지금 뭘 검증하고 있지?"

이 이야기가 던지는 질문은 단순하지만 강력해요. "당신은 지금 자기가 뭘 테스트하고 있는지 정확히 알고 있나요?"

실무에서 흔히 보이는 패턴 몇 가지를 떠올려 볼게요. 커버리지 숫자를 올리기 위해 의미 없는 테스트를 작성하는 경우가 있어요. assert true와 다를 바 없는 테스트인데, 커버리지 리포트에서는 해당 라인이 "커버됨"으로 표시되죠. 또 외부 API를 모킹했는데, 모킹한 응답이 실제 API 응답과 전혀 다른 구조인 경우도 있어요. 이러면 테스트는 통과하지만, 실제 연동에서는 바로 깨지거든요.

레트로 컴퓨팅 고고학에서 배울 수 있는 건, 테스트 대상에 대한 깊은 이해 없이는 테스트 자체가 무의미해진다는 거예요. 공산권 Apple II 클론을 Apple II 테스트 스위트로 돌린다고 해서 그게 "Apple II와 호환된다"는 증명이 되는 건 아니에요. 클론 자체의 특성과 차이점을 이해하고, 그에 맞는 테스트를 설계해야 하거든요.

한국 개발자에게 주는 시사점

한국 IT 업계에서도 "테스트 커버리지 80% 달성"이 KPI로 잡히는 곳이 많은데요, 숫자 자체보다 중요한 건 각 테스트가 실제로 무엇을 보호하고 있는지 팀 전체가 이해하고 있느냐예요.

당장 해볼 수 있는 건 이런 거예요. 팀의 테스트 스위트를 열어서 무작위로 테스트 10개를 골라보세요. 각 테스트가 "어떤 비즈니스 시나리오를 보호하는지" 한 문장으로 설명할 수 있나요? 설명이 안 되는 테스트가 있다면, 그건 14년간 뭘 테스트하는지 모르고 돌린 것과 본질적으로 같은 상황이에요.

레거시 코드를 다루는 팀이라면 특히 주의가 필요해요. 원래 작성자가 퇴사하고, 요구사항이 바뀌고, 코드가 리팩터링된 뒤에도 테스트만 그대로 남아 있는 경우가 많거든요. 이런 "좀비 테스트"는 거짓된 안전감을 주기 때문에 오히려 테스트가 없는 것보다 위험할 수 있어요.

마무리

결국 핵심은 간단해요. 테스트를 작성하는 것보다 중요한 건, 그 테스트가 무엇을 검증하는지 아는 것. 냉전 시대 Apple II 클론이라는 독특한 소재에서 출발했지만, 메시지는 2026년 우리의 코드베이스에도 그대로 적용되는 이야기예요.

여러분 팀에서 "이 테스트 왜 있는지 아무도 모르는데 깨지면 안 되니까 그냥 두자"라고 한 적 있나요? 그런 테스트를 어떻게 처리하셨는지 궁금해요.