Hacker News 2026.05.19 63

주기율표가 아닌 '비주기율표'? 화학과 수학이 만나는 이상한 발상

우리가 아는 주기율표, 사실 좀 이상하지 않나요

학교 다닐 때 외웠던 주기율표 기억나시죠. 수헬리베붕탄질산… 멘델레예프가 만든 그 표예요. 원소들이 비슷한 성질끼리 줄을 맞춰 서 있다고 배웠는데, 사실 가만히 들여다보면 좀 이상해요. 1주기에는 원소가 두 개(수소, 헬륨)밖에 없는데, 그다음 주기는 갑자기 8개, 또 18개, 그러다 32개까지 늘어나거든요. 왜 이렇게 불규칙할까요?

최근 영국의 개발자 John Graham-Cumming이 자기 블로그에 올린 The Aperiodic Table(비주기율표)라는 글이 이 질문을 색다른 각도에서 풀어줘요. 그는 평소 컴퓨터 사이언스와 수학을 즐기는 사람으로 잘 알려져 있는데, 이번엔 주기율표를 "수학적으로 다시 그려보면 어떨까?" 하는 실험을 했어요. 결론부터 말하면, 주기율표는 사실 주기적이지 않다는 거예요. 우리가 그렇게 부를 뿐이죠.

양자역학이 만든 '계단식' 구조

주기율표가 왜 그런 모양인지 이해하려면 원자 안쪽으로 들어가야 해요. 원소의 성질을 결정하는 건 전자(electron)인데, 이 전자들은 아무 데나 자리 잡지 않아요. 오비탈(orbital)이라고 부르는 정해진 자리에 순서대로 들어가요. 이게 뭐냐면, 전자가 원자핵 주변에서 머무를 수 있는 '에너지 방' 같은 거예요.

이 방의 개수가 묘하게 정해져 있어요. s 오비탈은 2개, p는 6개, d는 10개, f는 14개. 잘 보면 2, 6, 10, 14… 4씩 차이 나는 짝수예요. 더 정확히는 2(2ℓ+1) 공식에서 나오는 수예요. 여기서 ℓ은 0, 1, 2, 3… 식으로 증가해요. 그래서 각 주기에 들어갈 수 있는 원소 수가 2, 8, 18, 32 식으로 늘어나는 거고요. 이건 자연수의 제곱을 두 배 한 수열(2×n²)이에요.

Graham-Cumming의 핵심 아이디어는 여기 있어요. 일반 주기율표는 이 수학적 구조를 억지로 같은 간격의 격자에 끼워 넣어서 그려요. 그래서 란타넘족, 악티늄족이 표 아래쪽에 "우리도 사실 위에 있어야 하는데" 하는 모양으로 따로 떨어져 나가 있죠. 그가 그린 비주기율표는 이걸 거짓말하지 않아요. 각 주기의 폭이 진짜로 2, 8, 18, 32 칸씩 커지는 계단 모양으로 펼쳐져요. 결과적으로 표는 좌우 비대칭에 들쭉날쭉한 모습이 되지만, 오히려 자연 그대로의 구조가 드러나요.

시각화 한 장의 힘

이 글이 흥미로운 건 단순히 "이렇게 그릴 수도 있다"가 아니라, 데이터 시각화의 본질을 건드린다는 점이에요. 우리는 흔히 표나 차트를 만들 때 "보기 좋게"를 위해 정보를 왜곡해요. 격자를 맞추고, 축을 자르고, 색을 통일하죠. 하지만 그 과정에서 데이터의 진짜 모양은 사라져요.

주기율표가 딱 그런 사례예요. 1869년에 멘델레예프가 만들 때만 해도 양자역학은 존재하지도 않았어요. 그는 원소를 원자량 순으로 나열하다가 "성질이 비슷한 게 일정 간격으로 반복된다"는 패턴을 발견했고, 그래서 "주기적(periodic)"이라고 이름 붙였어요. 그 뒤로 우리는 150년 넘게 그 시절의 시각화를 그대로 쓰고 있는 거예요. 슈뢰딩거 방정식이 나오고, 오비탈이 발견되고, 모든 게 다 밝혀졌는데도요.

비슷한 시도가 아예 없었던 건 아니에요. Theodor Benfey의 나선형 주기율표는 원소를 동심원으로 배치해서 "왜 비활성 기체가 같은 줄에 오는지"를 더 잘 보여줘요. 또 Janet's left-step periodic table은 헬륨을 베릴륨 위에 놓는 식으로 전자 배치 규칙을 우선시해요. 다 비주류지만, 화학 교육 쪽에서는 "멘델레예프 표 하나만 답이 아니다"라는 논의가 계속 있어 왔어요. Graham-Cumming의 글은 이 흐름에 개발자스러운 직설적인 시각을 더해준 셈이에요.

개발자에게 주는 교훈

이게 화학 이야기 같지만, 사실 개발자한테 더 와닿는 주제예요. 우리도 매일 데이터를 시각화하잖아요. 대시보드, 로그 그래프, 코드 의존성 다이어그램까지. 그때마다 "보기 좋게 정리"한다는 명목으로 진짜 구조를 가리고 있는 건 아닐까 생각해볼 만해요.

예를 들어 마이크로서비스 아키텍처 그림을 그릴 때, 실제로는 서비스 간 호출 빈도가 천차만별인데 박스 크기를 다 똑같이 그리는 경우가 많죠. 그러면 "어디가 병목인지" 한눈에 안 보여요. 데이터의 자연스러운 비대칭성을 살리는 시각화가 때로는 더 정직하고 유용해요.

또 하나, 이건 레거시 표현 방식을 의심하는 태도에 대한 이야기이기도 해요. 주기율표는 너무 익숙해서 아무도 "이거 진짜 맞나?" 안 물어봤어요. 코드베이스에도 이런 게 있어요. 10년 전에 누군가 만든 데이터 구조, 클래스 계층, 폴더 구조가 "원래 그런 거"가 되어버린 경우요. 가끔은 처음 만든 사람의 가정이 지금은 안 맞을 수도 있어요. 그걸 다시 그려보는 용기가 필요해요.