AI에게 2009년 전후의 비트코인 (Bitcoin) C++ 코드를 보여준다.

아마 첫 번째 대답은 이럴 것이다.

"명명 규칙 (Naming convention)이 오래되었습니다."

네, 나왔습니다. 현대적인 코드 리뷰 (Code review).

nValue를 보고 눈살을 찌푸리고, //// TODO를 보고 빨간 펜을 휘두르며, 독자적인 매크로 (Macro)를 발견하고 "가독성에 문제가 있습니다"라고 말한다. 코드 리뷰 AI는 과거의 개발자에게도 용서가 없다.

하지만, 이 리뷰는 어디까지 옳은 것일까.

AI는 코드의 "현재"를 알고 있다

현대의 AI에게 오래된 C++ 코드를 리뷰하게 하면, 지적 사항은 상당히 쉽게 나온다.

int64 nValue;
uint256 hashBestChain;
vector<CTransaction> vtx;

현대의 기준에서 보면 신경 쓰이는 점이 여러 가지 있다.

• 타입 (Type)이 이름에 포함되어 있다
• 짧은 이름의 변수가 많다
• 표준 라이브러리 (Standard library)가 아닌 독자적인 매크로나 타입이 등장한다
• 테스트 (Test)나 책임 분할이 지금의 감각만큼 정돈되어 있지 않다

AI에게 "개선안을 작성해줘"라고 부탁하면, 더 현대적인 이름으로 변경하고, 함수를 분할하며, 예외 처리 (Exception handling)를 추가하고, 테스트 코드까지 제안해 줄 것이다.

그리고 아마 코드는 깨끗해질 것이다.

아마, 다른 코드가 될 것이다.

이 지점이 흥미롭다.

nValue는 정말 나쁜 이름인가

현대의 리뷰에서는 nValue는 "의미가 모호한 이름"으로 판정되기 쉽다.

하지만 이것은 단순한 변수명이 아니다. 초기 비트코인 코드 전체에는 타입 접두사를 사용하는 헝가리안 표기법 (Hungarian notation)의 변형이 통용되고 있다.

nValue, strHash, vtx.

이름을 보면 정수인지, 문자열인지, 배열인지 어느 정도 알 수 있다. 지금이라면 타입 추론 (Type inference)이나 보완 기능이 알려줄 정보를 이름에도 담아두었던 것이다.

AI는 "명명 규칙을 통일합시다"라고 말한다.

당시의 개발자 입장에서는 "통일되어 있기 때문에 읽을 수 있는 것 아닌가?"라고 생각할지도 모른다.

즉, AI의 지적은 틀리지 않았다.

다만, 코드가 태어난 시대의 도구 상자를 갖지 못한 채 채점하고 있을 뿐이다.

//// TODO에 화를 내는 AI

다음으로, 4중 슬래시의 TODO가 등장한다.

//// TODO: something

현대의 AI는 아마 이렇게 말할 것이다.

"TODO 관리 방법을 통일하고, 이슈 트래킹 시스템 (Issue tracking system)과 연동하십시오."

정론이다. 정론이지만, 2009년의 소스 코드에 이슈 트래킹 시스템 도입을 강요하는 것은 사막에서 폭포수 모델 (Waterfall model) 개발을 설파하는 것과 같다.

초기 비트코인의 기록에서는 처음부터 지금과 같은 팀 개발 도구가 갖춰져 있었던 것이 아니다. 공개 릴리스 (Release), 소스 배포, 커밋 히스토리 (Commit history), 타인에 의한 이식. 개발의 형태는 나중에 조금씩 변해간다.

AI는 완성된 후의 개발 현장을 알고 있다.

그래서 진행 중인 지면에도 완성된 후의 도로 표지판을 세우려 한다.

오래된 코드를 현대의 작법으로 고치면 무엇이 사라지는가

그렇다면 AI에게 코드를 전면적으로 다시 써보게 한다.

int64 nValue;를 다음과 같이 바꾼다.

std::int64_t value;

이것은 읽기 쉽다. 현대의 개발에서는 이쪽을 선택하는 경우가 많다.

독자적인 매크로도 표준적인 구문으로 교체하고, 함수를 세밀하게 분할하며, 테스트를 추가한다. 리뷰로서는 훌륭하다.

다만, 그 순간 사라지는 것이 있다.

그 코드가 어떤 개발 환경에서 작성되었는지. 어떤 라이브러리를 조합했고, 어떤 배포 방법으로 사용자에게 전달되었는지. 코드의 습관이 개인의 취향인지, 당시 Windows 개발 환경의 영향인지.

깨끗하게 만든 코드는 현재의 소프트웨어로서는 읽기 쉽다.

하지만 사료 (Historical document)로서는 읽기 어려워진다.

리뷰 AI에게는 타임머신이 없다

여기서 AI를 탓할 필요는 없다.

AI는 주어진 기준에 대해 잘 작동하고 있다. 현대의 안전성, 유지보수성, 테스트 용이성, 명명 규칙. 그런 관점에서는 지적할 수 있는 것이 많다.

문제는 질문 쪽이다.

"이 코드를 현대의 C++로서 리뷰해줘"라고 부탁하면 현대의 C++로서 리뷰한다.

"이 코드를 2009년의 개발자가 선택할 수 있었던 도구와 제약 속에서 읽어줘"라고 부탁하면 다른 답이 나온다.

리뷰 대상은 같더라도 질문이 바뀌면 화를 내는 지점이 바뀐다.

현대의 리뷰: 왜 이런 식으로 작성했지?
역사의 리뷰: 왜 이런 방식이 성립했지?

전자는 코드 품질을 본다. 후자는 코드와 환경의 조합을 본다.

사토시의 코드를 읽을 때 후자를 제외하면, AI뿐만 아니라 누구라도 "옛날 사람들은 지금의 관례를 모르는구나"라는 감상에 도달하기 쉽다.

코드는 신원을 밝히지 않는다

여기까지 읽으면, "그렇다면 이 코딩 스타일을 통해 사토시의 정체를 알 수 있는 것 아닌가"라고 말하고 싶어질 것이다.

AI에게 후보자를 물으면 분명 그럴듯한 인물 이름을 여러 명 제시할 것이다. 코드의 습관, 활동 시간, 사용했던 환경. 재료를 건네주면 이야기는 금방 구성된다.

하지만 코드에서 비교적 읽어낼 수 있는 것은 작성 방식과 환경의 흔적까지다.

그것이 특정 한 사람의 이름으로 변환되는 지점에서, 이야기는 갑자기 위험해진다.

코드 리뷰 (Code Review) AI가 화를 낸 상대는 사토시가 아니다.

자신이 가져온 현대의 채점표와 2009년의 소스 코드 (Source Code) 사이에 존재하는 시차다.

실제 코드를 현대의 채점표에서 일단 분리하기

초기 비트코인 (Bitcoin)의 코드에는 현대의 기준에서 보면 신경 쓰이는 부분이 있다. 헝가리안 표기법 (Hungarian notation), 독자적인 매크로 (Macro), 4중 슬래시로 된 TODO, Windows 중심의 개발 환경.

하지만 그 나열을 "오래되었다"로 끝내버리면, 코드가 남기고 있는 정보를 놓치게 된다.

우선 코드의 습관이 어느 버전에서 이어졌고, 어느 시점에 변했으며, 어떤 개발 환경과 함께 나타났는지를 본다.

거기까지 확인한 뒤에 AI에게 다시 한번 리뷰를 시킨다.

아마 여전히 화를 낼 것이다.

다만, 이번에는 무엇에 화를 내고 있는지가 조금은 보인다.

현대의 리뷰를 가져오기 전에, 코드가 작성되었던 책상 위를 조금 살펴본다. 오래된 모니터, 오래된 컴파일러 (Compiler), 오래된 배포 방식. 거기까지 갖춰지고 나서야 비로소 빨간 펜의 의미가 바뀐다.

Discussion