The Story of Mel

3줄 요약

1. Mel’s Loop는 에드 네이더(Ed Nather)가 1983년 5월 21일 유즈넷에 올린 「The Story of Mel」을 행마다 번호를 붙여 싣고, 주석 26개와 용어 풀이 31개를 덧붙인 주석판 사이트다. 토메르 리크타시(Tomer Lichtash)와 데이비드 프렌키엘(David Frenkiel)이 만들었으며, 서문과 인물 조사, 해킹 재분석 같은 관련 기사도 함께 실었다.
2. 이야기 속에서 멜은 1950년대 말 Royal McBee에서 드럼 메모리 컴퓨터용 블랙잭 프로그램을 16진수 기계어로 짰다. 손님이 이기게 해 달라는 영업부의 요구를 받자, 멜은 스위치를 켜면 컴퓨터가 매번 이기도록 판정 조건을 반대로 만들었다. 멜이 떠난 뒤 그 코드를 맡은 네이더는 판정 조건이 없는데도 정상적으로 끝나는 루프의 원리를 알아내는 데 2주가 걸렸다고 한다.
3. 주석판의 조사에 따르면 멜 케이는 1931년에 태어나 2018년에 세상을 떠난 실존 인물이고, 이야기의 무대는 1959년에서 1960년 무렵 캘리포니아 글렌데일의 Librascope 사무실이다. 하지만 Mel’s Loop가 RPC-4000 매뉴얼에 실린 명령어 형식을 찾아 대조했더니, 오버플로가 연산 코드를 바꾸는 일은 그 기계의 비트 배열로는 일어날 수 없었다. 프렌키엘은 그 대신 멜이 조건부 점프 명령어를 썼을 가능성을 제시했다. RPC-4000에서는 오버플로가 일어나면 분기 제어 장치가 켜지는데, 멜이 이 성질을 이용하면 판정 명령어 없이도 루프를 끝낼 수 있었다고 한다.

Mel’s Loop와 원문

「The Story of Mel」은 해커 민담(hacker folklore)으로 불리는 글 가운데 가장 널리 알려진 작품에 속한다. 네이더는 이 글을 에드 포스트(Ed Post)가 1982년에 쓴 「Real Programmers Don’t Use PASCAL」에 대한 유머러스한 반박으로 썼다.¹ 포스트의 글은 구조적 프로그래밍 같은 현대적 기법을 약한 개발자나 쓰는 군더더기로 취급했고, “Real Programmer(진정한 프로그래머)는 FORTRAN으로 쓴다"고 주장했다. 네이더는 이 주장에 대해 이렇게 적었다.

Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

네이더는 라이트 맥주와 휴대용 계산기, “사용자 친화적” 소프트웨어가 나오기 전, 컴퓨터를 드럼과 진공관으로 만들던 시절에는 Real Programmer가 FORTRAN도 어셈블리도 쓰지 않고 16진수 기계어를 직접 썼다고 주장했다. 그는 새 세대 프로그래머가 이 시절을 모른 채 자라지 않도록 그런 프로그래머 한 사람이 코드를 어떻게 썼는지 기록해 두겠다고 했다. 그리고 그 사람을 “멜이라고 부르겠다, 이름이 멜이었으니까"라고 소개했다.

Mel’s Loop는 이 원문을 행 단위로 번호를 붙여 시처럼 배열했고, 문장마다 번호가 달린 주석과 용어 풀이 팝업을 연결했다. 주석의 출처에는 Librascope 사내지, 컴퓨터 매뉴얼, 족보 기록, 에릭 브런밴드(Erik Brunvand)가 먼저 만든 주석판 등이 포함된다. 사이트는 영어와 히브리어로 제공되며, 리크타시가 이 이야기를 히브리어로 번역했다. 그는 서문에서 이야기의 시점과 장소, 등장인물의 이후 삶을 물은 사람이 아무도 없었다는 것을 알게 됐고, 이를 계기로 조사를 시작했다고 밝혔다.

이야기의 줄거리

드럼 메모리 컴퓨터 두 대

네이더는 타자기 회사의 자회사였던 Royal McBee Computer Corp.에 입사해 멜을 처음 만났다.² 이 회사는 작고 값이 싼 드럼 메모리 컴퓨터 LGP-30을 만들고 있었고, 더 크고 빠른 후속기 RPC-4000의 생산을 막 시작한 때였다. 네이더는 당시 코어 메모리가 너무 비쌌다고 적었다. 그는 RPC-4000용 FORTRAN 컴파일러를 만들기 위해 고용됐고, 멜이 그에게 새 기계를 다루는 법을 가르쳐 주었다. 그런데 멜은 컴파일러를 좋게 보지 않았다.

“If a program can’t rewrite its own code”, he asked, “what good is it?”

멜이 16진수로 짠 블랙잭 프로그램은 회사가 가진 프로그램 가운데 가장 인기가 많았다. 컴퓨터 박람회에서 LGP-30이 잠재 고객을 상대로 블랙잭 게임을 하면 부스는 매번 사람으로 가득 찼고, IBM 영업사원들은 그 옆에서 자기들끼리 이야기만 나눴다고 한다. 네이더는 이것이 실제 컴퓨터 판매로 이어졌는지는 아무도 따져 보지 않았다고 덧붙였다.

멜이 맡은 일은 이 프로그램을 RPC-4000에 이식하는 것이었다. RPC-4000은 “1+1 주소 방식"을 썼다. 모든 명령어에는 연산 코드와 피연산자 주소 외에, 회전하는 드럼에서 다음 명령어가 저장된 주소가 하나 더 들어 있었다. 네이더는 이를 두고 모든 명령어 뒤에 GO TO가 붙어 있는 셈이라고 표현했다.

손으로 한 최적화

드럼은 쉬지 않고 회전했기 때문에, RPC-4000의 프로그램이 얼마나 빨리 실행되는지는 프로그래머가 각 명령어를 드럼의 어느 지점에 저장했느냐에 달려 있었다. 한 명령어가 끝나는 순간 다음 명령어가 막 읽기 헤드에 도착하도록 배치하면 기다리지 않고 바로 실행할 수 있었다. 이 작업을 대신해 주는 “최적화 어셈블러"가 있었지만 멜은 쓰지 않았다. 멜은 그 이유를 “그게 무엇을 어디에 둘지 알 수가 없으니 상수를 따로 써야 한다"고 설명했다.

네이더는 이 말을 한참 뒤에야 이해했다고 한다. 멜은 모든 연산 코드의 수치를 알고 있었고 드럼 주소도 직접 정했으므로, 그가 쓴 명령어의 값은 각각 수치 상수로도 쓸 수 있었다. 먼저 나온 덧셈 명령어의 값이 마침 필요한 수라면, 멜은 그 값을 곱셈에 필요한 상수로 썼다. 네이더는 그의 코드가 남이 고치기 쉽지 않았다고 적었다.

네이더가 멜이 손으로 최적화한 프로그램과 최적화 어셈블러로 처리한 같은 코드를 비교해 보았더니, 멜의 코드가 언제나 더 빨랐다. 멜은 프로그램에서 가장 안쪽 루프부터 먼저 써서, 그 루프가 드럼에서 가장 유리한 주소를 먼저 차지하게 했다. 네이더는 최적화 어셈블러가 그런 방식으로 작업할 만큼 영리하지 못했다고 평가했다.

멜은 시간 지연 루프도 쓰지 않았다. 출력 장치인 Flexowriter는 글자와 글자 사이에 지연을 두어야 제대로 작동했다.³ 멜은 다음 명령어가 필요한 순간에 그 명령어가 읽기 헤드를 막 지나친 지점에 있도록 배치했고, 그러면 드럼이 한 바퀴를 더 돌아야 다음 명령어를 읽을 수 있었다. 네이더에 따르면 사람들은 절대적인 말인 “최적(optimum)“을 “덜 최적”, “그다지 최적이 아닌"처럼 상대적으로 쓰곤 했다. 멜은 다음 명령어를 읽는 데 가장 오래 걸리는 주소를 “가장 비최적(most pessimum)“이라고 불렀다.

프로그램을 완성해 실행해 본 멜은 “초기화 루틴까지 최적화했다"고 자랑했다.

영업부의 변경 요청

얼마 뒤 영업부에서 변경 요청이 왔다. 프로그램은 잘 만든 난수 생성기로 카드를 섞고 나눠 줬는데, 일부 영업사원은 게임이 너무 공정해서 손님이 질 때가 있다고 여겼다. 그들은 콘솔의 센스 스위치를 켜면 확률을 바꿔 손님이 이기게 해 달라고 요구했다.

멜은 거부했다. 네이더는 멜이 이 요구를 명백한 부정행위로 여겼고, 그 판단이 옳았다고 적었다. 또 멜은 이 요구가 프로그래머로서의 원칙에 반한다고 느꼈으며, 네이더는 이 역시 맞는 말이었다고 덧붙였다. 영업부장과 사장, 사장의 권유를 받은 동료 프로그래머 몇 명이 멜을 설득했다. 멜은 끝내 코드를 썼지만 판정 조건을 반대로 만들었다. 스위치를 켜면 프로그램이 속임수를 써서 매번 컴퓨터가 이겼다. 멜은 이 결과를 기뻐하며 자기 무의식이 “어쩔 수 없이 윤리적"이라고 주장했고, 고쳐 달라는 요구를 끝까지 거절했다.

멜이 회사를 떠난 뒤 사장은 네이더에게 코드에서 그 판정 조건을 찾아 반대로 고쳐 달라고 했다. 네이더는 내키지 않았지만 일을 맡았고, 멜의 코드를 추적하는 일이 대단한 모험이었다고 회상했다.

판정 조건이 없는 루프

네이더는 프로그래밍을 같은 기예를 익힌 사람만 가치를 알아볼 수 있는 예술로 여겼다. 그는 16진수로 쓰인 코드라도 읽어 보면 그 사람에 대해 많은 것을 알 수 있다고 했고, 멜을 “알려지지 않은 천재"라고 불렀다.

네이더가 가장 크게 놀란 것은 판정 조건이 하나도 없는 루프였다. 상식대로라면 이 루프는 끝없이 반복되어야 했지만, 루프는 정상적으로 종료되었고 프로그램은 다음 단계를 실행했다. 네이더는 그 원리를 알아내는 데 2주가 걸렸다.

RPC-4000에는 인덱스 레지스터가 있었다. 루프의 명령어에 인덱스를 적용하면, 반복할 때마다 레지스터 값이 그 명령어의 주소에 더해진다. 그 결과 명령어는 다음 데이터를 참조하고, 프로그래머는 인덱스 레지스터를 1씩 늘리기만 하면 됐다. 멜은 이 기능을 쓰지 않았다. 그는 명령어를 레지스터로 불러와 주소에 1을 더하고 원래 주소에 다시 저장한 뒤, 고친 명령어를 레지스터에서 바로 실행했다. 멜은 이 추가 작업에 걸리는 시간까지 계산해서, 명령어 하나가 끝나는 순간 다음 명령어가 드럼의 읽기 헤드에 도착하도록 루프를 짰다.

실마리는 인덱스 레지스터 비트였다. 네이더의 기억에 따르면 이 비트는 명령어 워드에서 주소 필드와 연산 코드 필드 사이에 있었다. 멜은 인덱스 레지스터를 쓰지 않아서 값을 늘 0으로 두었는데, 이 비트는 켜져 있었다. 네이더는 그 의미를 깨달은 순간을 이렇게 적었다.

When the light went on it nearly blinded me.

멜은 처리할 데이터를 명령어가 지정할 수 있는 가장 큰 주소 근처에 저장해 두었다. 네이더의 설명에 따르면, 마지막 데이터까지 처리한 뒤에도 멜의 코드는 여느 때처럼 명령어의 주소에 1을 더했다. 이때 주소 필드에서 오버플로가 일어났고, 그 캐리가 연산 코드에 1을 더하는 바람에 명령어가 명령어 집합에서 다음 번호인 점프 명령어로 바뀌었다고 한다. 점프 대상인 다음 명령어는 0번지에 저장되어 있었고, 프로그램은 그대로 실행을 이어 갔다.

네이더는 멜과 연락이 끊겨서 멜이 이후 크게 바뀐 프로그래밍 기법을 받아들였는지는 모른다고 했다. 그러면서 받아들이지 않았으리라 믿고 싶다고 덧붙였다. 그는 이 루프에 감탄한 나머지 문제의 판정 조건 찾기를 그만두고, 사장에게 찾지 못했다고 보고했다. 사장은 놀라는 기색이 없었다고 한다. 네이더가 회사를 떠날 때까지도 블랙잭 프로그램은 스위치를 켜면 속임수를 썼고, 네이더는 그 상태가 옳다고 생각했다. 글의 마지막 문장은 다음과 같다.

I didn’t feel comfortable hacking up the code of a Real Programmer.

주석이 더한 기록

Mel’s Loop의 주석은 원문의 각 문장에 당시 기록을 덧붙인다. 이야기에 등장하는 사람과 기계에 관한 주요 내용은 다음과 같다.

박람회 장면에 붙은 주석은 1955년 11월 14일부터 17일까지 시카고 네이비 피어에서 열린 자동화 박람회에 관한 Librascope 사내지 Librazette의 기사를 인용한다. 기사에 따르면 LGP-30을 전시한 부스는 관람객 1만 2천 명이 찾은 박람회장에서 가장 인기 있는 곳이 되었고, 남부 캘리포니아의 한 경쟁 컴퓨터 제조사 직원은 반쯤 농담으로 “솔직히 걱정된다"고 말했다고 한다.⁴

그림 1. 1956년 10월 멜 케이가 서명한 LGP-30 코딩 시트 「Hexadecimal Punch or Print」. 출처: Mel’s Loop(Bill Breiner 아카이브)

블랙잭 프로그램의 사용 설명서

멜이 RPC-4000용으로 이식한 블랙잭 프로그램(Program W1-01.0)에는 그가 직접 쓴 사용 설명서가 남아 있다. 플레이어는 Flexowriter 타자기로 입력하고 출력을 받았다. 설명서에 적힌 진행 순서는 다음과 같다.

1. 컴퓨터가 “How much do you bet?“라고 묻는다. 플레이어는 금액 뒤에 정지 코드인 별표를 붙여 입력한다. 150*는 1.50달러를 건다는 뜻이다.
2. 컴퓨터가 “Shuffling"을 출력하고 카드 섞기를 시뮬레이션한다. 플레이어가 SENSE SWITCH 1을 올려야 섞기가 멈춘다.
3. “Cut"이 출력되면 플레이어가 SENSE SWITCH 1을 내려 카드 떼기를 끝낸다. 그다음 카드가 배분되고 게임이 진행된다.
4. 모든 질문에는 키보드로 답하고 정지 코드를 붙인다. 긍정은 yes*, ok*, si*, ja*, oui*로, 부정은 no*, non*, nein*, nope*나 별표 하나로 답한다.

게임을 시작하기 전에는 타자기 탭 정지 네 개를 설정해야 했다. 폭 15칸인 첫 열에는 질문과 플레이어의 답이, 폭 12칸인 나머지 세 열에는 플레이어의 카드, 딜러인 컴퓨터의 카드, 판마다의 점수가 인쇄됐다. 설명서 끝에는 프로그램 테이프를 메모리에 저장하면 제어가 00000번지로 전달되며, 블랙잭 프로그램이 00000번지에서 시작하므로 실행하기가 매우 쉽다는 메모가 붙어 있다.⁵

그림 2. 멜 케이가 쓴 RPC-4000 블랙잭 프로그램 설명서의 첫 장. 출처: Mel’s Loop

멜의 마지막 이메일

멜은 해커 문화에서 얻은 명성을 원한 적도, 스스로 언급한 적도 없다. 2012년 4월 17일, 프로그래머 앤서니 쿠오조(Anthony Cuozzo)는 추적 끝에 알아낸 주소로 “Librascope나 Royal McBee에서 일하신 적이 있습니까?“라는 메일을 보냈다. 한 시간이 지나기 전에 답장이 왔다.

Yes, I did, many, many years ago I worked for both of them. I believe I worked for Royal McBee first. Mel Kaye

쿠오조는 대화를 이어 가려 했지만 멜은 더 답하지 않았다. Mel’s Loop는 멜이 2018년 세상을 떠나 로스앤젤레스의 Pierce Brothers Valley Oaks-Griffin Memorial Park에 묻혔다고 기록했다.

그 해킹은 RPC-4000에서 가능했는가

주석 25번은 네이더의 묘사를 비트 배열로 다시 적는다. 비트 번호가 낮은 순서대로 피연산자 주소, 인덱스 비트, 연산 코드, 다음 주소로 구성된다는 설명이다. 주석은 조사 결과 이 배열이 RPC-4000 하드웨어의 실제 배열과 일치하지 않는다고 밝힌다. 이 불일치를 자세히 다룬 글이 Mel’s Loop의 관련 기사인 데이비드 프렌키엘의 「The Missing Bits: A Closer Reading of Mel’s Hack」(2022년 7월 22일)이다.

원문대로의 해킹은 불가능하다

프렌키엘은 30년 동안 이 해킹을 막힘없이 설명할 수 있다고 자부했지만, 이 사이트의 주석을 교정하다가 설명에서 누락된 단계를 발견했다고 한다. 점프 명령어가 0이라는 목적지 주소를 어디에서 얻는지 네이더는 설명하지 않았다. 의문을 풀기 위해 프렌키엘은 RPC-4000 매뉴얼을 찾아보았고, 명령어 형식 그림에서 답을 얻었다.

그림 3. RPC-4000 명령어 형식. 출처: RPC-4000 매뉴얼, Mel’s Loop 재수록

프렌키엘의 판독에 따르면 RPC-4000의 연산 코드는 명령어의 최하위 비트에 있다. 연산 코드보다 상위 비트에 있는 주소 필드에서 오버플로가 일어나도, 그 캐리는 더 상위의 비트로만 전달된다. 따라서 연산 코드의 값은 바뀌지 않는다. 그는 근거를 하나 더 들었다. RPC-4000의 0번 연산 코드는 점프 명령어가 아닌 다른 연산이었으므로, 비트 배열이 네이더의 기억과 같았더라도 원문의 해킹은 성립할 수 없었다고 한다. 이 두 가지 근거를 들어, 프렌키엘은 네이더가 묘사한 그대로의 해킹은 RPC-4000에서 실현될 수 없다는 결론을 내렸다.⁶

두 가지 재구성

RPC-4000의 사양만으로도 이야기와 비슷한 결과를 내는 시나리오가 두 가지 있다고 프렌키엘은 설명했다.

첫 번째 시나리오는 오버플로만으로 같은 결과를 만든다. 피연산자 주소와 다음 주소가 모두 최댓값이고 인덱스 비트가 0인 명령어에서 피연산자 주소에 1을 더하면, 오버플로가 다음 주소 필드까지 전파된다. 두 필드는 모두 0이 되고 최상위의 인덱스 비트는 1로 바뀐다. 이 명령어는 원래의 연산을 수행한 뒤 0번지의 명령어를 실행하므로, 네이더가 적은 것과 같은 결과가 나온다. 이때 인덱스 비트가 켜진다는 점에 프렌키엘은 주목했다. 쓰지도 않는 인덱스 비트가 켜져 있었다는 네이더의 기억이 바로 이 현상에서 비롯되었을 수 있다고 그는 보았다.

두 번째 시나리오의 개요는 해커 뉴스 토론에서 스타사 팟산치스(Stassa Patsantzis)가 제시했다. 프렌키엘은 이 시나리오가 이야기와 더 잘 맞는다고 평가했다. RPC-4000의 23번 연산 코드 10111은 TBC(Transfer on Branch Control)라는 조건부 점프 명령어였다. TBC는 분기 제어 장치(Branch Control Unit)가 켜져 있으면 피연산자 주소로 점프하고, 꺼져 있으면 다음 주소 필드가 가리키는 명령어를 실행했다. 매뉴얼에 따르면 분기 제어 장치는 비교가 성공했을 때뿐 아니라 오버플로가 일어났을 때도 자동으로 켜졌다.

그림 4. 분기 제어 장치에 관한 RPC-4000 매뉴얼의 설명. 출처: RPC-4000 매뉴얼, Mel’s Loop 재수록

당시의 조건부 분기는 두 수를 비교하는 판정 명령어와 그 직후 실행하는 TBC, 두 단계로 이루어졌다. 멜은 판정 명령어 없이 피연산자 주소만 계속 1씩 늘렸다. 인덱스 비트가 1인 상태였으므로 주소 값이 최댓값을 초과하는 순간 명령어 워드 전체에서 오버플로가 일어났다. 오버플로가 분기 제어 장치를 켜면, 그때까지 아무 동작도 하지 않던 TBC가 0이 된 피연산자 주소로 점프한다. 프렌키엘은 이 대목을 네이더의 착각으로 설명했다. 네이더가 오버플로로도 분기 제어 장치가 켜진다는 점을 몰랐다면, 그는 판정 명령어가 먼저 실행되지 않는 TBC를 보고 “판정 조건이 없는 루프"라고 판단했을 것이다. 표준적인 조건 분기만 배운 RPC-4000 프로그래머라면 그렇게 판단하는 것이 자연스러웠다고 프렌키엘은 보았다.

이 시나리오는 두 가지 점에서 원문과 다르다. 연산 코드는 한 번도 바뀌지 않는다. 그리고 해킹이 마법처럼 보인 이유의 상당 부분은 네이더가 기계를 완전히 이해하지 못한 데 있다. 네이더가 TBC와 오버플로의 관계를 알았다면 문제를 곧바로 풀었을 테고, 그러면 후세에 남을 이야기도 없었을 것이라고 프렌키엘은 적었다.

프렌키엘의 평가

어느 시나리오가 맞든 네이더의 서술은 부정확한 기억에서 나왔으며, RPC-4000에 대한 그의 이해도 불완전했을 것이라고 프렌키엘은 판단했다. 그러면서도 이 발견이 이야기의 매력을 떨어뜨리지는 않는다고 했다. 남이 짠 “불가능한” 코드를 힘들게 해독해 본 경험에는 대부분의 개발자가 공감할 수 있고, 자기 자신을 고쳐 쓰는 프로그램의 매력도 그대로이며, 두 시나리오 모두 해킹으로서 인상적이라고 했다.

그는 비판도 덧붙였다. 평범한 루프를 썼더라도 프로그램 성능은 눈에 띄게 떨어지지 않았을 것이므로, 판정 조건이 없는 루프는 불필요하게 복잡도를 늘렸을 뿐이라고 했다. 오늘날의 개발팀에도 단순한 루프를 알아보기 힘든 코드로 바꿔 놓고 동료가 당혹스러워하는 모습을 즐기는 개발자가 있다고도 했다. 그러나 프렌키엘은 멜과 그런 개발자 사이에 결정적인 차이가 하나 있다고 보았다. 멜은 이 해킹을 회사의 누구에게도 자랑하지 않았고, 네이더가 코드를 해독하느라 애를 먹었다는 점이 그 증거라고 했다. 그는 글을 이렇게 맺었다.

An epitome of a real programmer, Mel Kaye was perfectly content watching his code run and feeling very, very clever.

가장 흥미로운 지점

읽고 나서 계속 생각난 것은 네이더와 프렌키엘의 깨달음이 정반대였다는 점이다. 네이더는 루프의 원리를 깨달았을 때 눈이 멀 뻔했다고 적었다. 프렌키엘은 자신이 겪은 “멜의 순간"이 그와 정반대였다고 표현했다. 한순간에 모든 것이 이해된 네이더와 달리, 프렌키엘은 알고 있다고 믿었던 해킹의 설명을 조금씩 의심하게 되었다. 그리고 그 과정에서 자신이 이 이야기를 얼마나 허술하게 읽었는지 깨달았다고 한다.

두 번째 시나리오가 맞다면 이 이야기를 만든 것은 멜의 솜씨와 네이더의 착각이다. 네이더가 매뉴얼의 분기 제어 장치 항목을 끝까지 읽었다면 해독에 2주를 들이지 않았을 것이고, 1983년의 유즈넷 글도 나오지 않았을 것이다. 해커 민담의 대표작이 기억의 오류에서 비롯되었다는 분석을, 이 이야기를 누구보다 아끼는 사람들이 직접 써서 주석판에 함께 실었다. 나는 그 점에 가장 감탄했다.

출처

• 원문: Ed Nather, 「The Story of Mel」, Usenet, 1983년 5월 21일
• 주석판: Mel’s Loop, 「The Story of Mel」(Tomer Lichtash, David Frenkiel)
• 관련 기사: Tomer Lichtash, 「A Software Legend That Really Happened: A Preface to The Story of Mel」(2021년 4월 7일), 「Mel Kaye – CV」(2023년 5월 20일). David Frenkiel, 「The Missing Bits: A Closer Reading of Mel’s Hack」(2022년 7월 22일)
• 이미지: 모두 Mel’s Loop 게재본

원문: https://melsloop.com/stories/the-story-of-mel