섣부른 최적화의 저주를 피하는 방법

거의 보장할 가치가 있습니다. 초보자에서 전문가에 이르기까지, 아키텍처에서 ASM에 이르기까지, 기계 성능에서 개발자 성능에 이르기까지 모든 것을 최적화하는 과정에서 귀하와 귀하의 팀이 목표를 달성하지 못할 가능성이 매우 높습니다.

뭐라고 요? 나? 내 팀?

그것은 수준에 대한 꽤 무거운 비난입니다. 설명하겠습니다.

최적화는 성배는 아니지만 얻기도 어려울 수 있습니다. 팀의 경험을 자기 파괴적 경험에서 조화, 성취감, 균형, 그리고 궁극적으로는 최적화로 바꾸는 데 도움이 되는 몇 가지 간단한 팁(및 수많은 함정)을 공유하고 싶습니다.

조기 최적화란 무엇입니까?

조기 최적화가 성능 최적화를 시도하고 있습니다.

1. 알고리즘을 처음 코딩할 때
2. 벤치마크 확인 전에 다음을 수행해야 합니다.
3. 프로파일링하기 전에 최적화를 귀찮게 해야 하는 부분을 정확히 지적합니다.
4. 현재 프로젝트에서 지시하는 것보다 낮은 수준에서

자, 나는 낙관주의자야, 옵티머스.

적어도 나는 이 글을 쓰는 동안 낙관론자 척 할 것이다. 당신의 이름이 Optimus인 척 할 수 있으므로 이것이 당신에게 더 직접적으로 말할 것입니다.

기술 분야의 사람으로서, 당신은 아마도 그것이 어떻게 $year 일 수 있는지 궁금할 것입니다. 그러나 우리의 모든 발전에도 불구하고 $task 가 그렇게 짜증나게 시간 소모적이라는 것은 어느 정도 수용 가능한 표준입니다. 당신은 날씬하고 싶어. 효율적인. 엄청난. 구인 공고가 요구하는 Rockstar 프로그래머와 같은 사람이지만 리더가 있습니다. 따라서 팀에서 코드를 작성할 때 처음에는 올바르게 작성하도록 권장합니다(여기서 "옳음"이 매우 상대적인 용어일지라도). 그들은 그것이 영리한 코더의 방식이며 또한 나중에 시간을 낭비할 필요가 없는 사람들의 방식이라는 것을 알고 있습니다.

나는 그것을 느낀다. 완벽주의의 힘은 때때로 내 안에서도 강하다. 모든 사람들이 "다른 사람들이 쓴 엉터리 코드(도대체 무슨 생각을 하고 있었나요?)" 의 공유에 몰두하고 있기 때문에 팀이 지금 약간 의 시간을 보내 나중에 많은 시간을 절약할 수 있기를 원합니다. 당신이 발음할 수 없는 두문자어를 좋아한다는 것을 알기 때문에 줄여서 SCOPWWHWTT입니다.

나는 또한 당신이 당신 팀의 코드가 자신이나 다른 사람을 위한 코드가 되는 것을 원하지 않는다는 것을 알고 있습니다.

따라서 팀을 올바른 방향으로 안내하기 위해 무엇을 할 수 있는지 알아보겠습니다.

최적화 해야 할 사항: 예술이 되는 것을 환영합니다

우선, 우리는 프로그램 최적화를 생각할 때 종종 즉시 성능에 대해 이야기하고 있다고 가정합니다. 그것 조차도 이미 보이는 것보다 더 모호하므로(속도? 메모리 사용량? 등) 바로 여기서 멈추겠습니다.

더 모호하게 해보자! 처음에는 그냥.

내 거미줄 같은 두뇌는 가능한 한 질서를 만드는 것을 좋아하므로 내가 말하려는 것이 좋은 것이라고 생각하려면 모든 낙관주의가 필요할 것 입니다.

Don't do it 이라는 간단한 (성능) 최적화 규칙이 있습니다. 이것은 엄격하게 따르기 매우 쉬운 것처럼 들리지만 모든 사람이 동의하는 것은 아닙니다. 저도 전적으로 동의하지 않습니다. 어떤 사람들은 다른 사람들보다 간단히 더 나은 코드를 작성할 것입니다. 바라건대, 주어진 사람에게 새로운 프로젝트에서 작성하는 코드의 품질은 일반적으로 시간이 지남에 따라 향상될 것입니다. 그러나 나는 많은 프로그래머에게 이것이 사실이 아닐 것이라는 것을 알고 있습니다. 왜냐하면 그들이 더 많이 알수록 더 많은 방법으로 성급하게 최적화하려는 유혹을 받을 것이기 때문입니다.

많은 프로그래머에게… 더 많이 알면 알수록 성급하게 최적화하려는 유혹을 받는 더 많은 방법이 있습니다.

따라서 이 Don't do it 은 정확한 과학이 될 수 없지만 퍼즐을 풀고자 하는 전형적인 기술자의 내적 충동을 상쇄하기 위한 것일 뿐입니다. 이것은 결국 많은 프로그래머를 처음부터 기술에 끌어들이는 것입니다. 나는 그것을 이해한다. 그러나 유혹에 저항하기 위해 그것을 구 하도록 요청하십시오. 지금 당장 퍼즐을 풀 수 있는 콘센트가 필요하다면 일요일 신문의 스도쿠에 손을 대거나 멘사 책을 집어들거나 인공적인 문제로 코드 골프를 치러 갈 수 있습니다. 그러나 적절한 시간이 될 때까지 리포지토리에서 꺼내지 마십시오. 거의 항상 이것은 사전 최적화보다 현명한 방법입니다.

이 관행은 사람들이 섣부른 최적화가 모든 악의 근원인지 물어볼 만큼 악명이 높다는 것을 기억하십시오. (그렇게까지 하지는 않겠지만, 그 감정에 동의합니다.)

나는 우리가 디자인의 모든 수준에서 생각할 수 있는 가장 뇌사적인 방식을 선택해야 한다고 말하는 것이 아닙니다. 당연히 아니지. 그러나 가장 똑똑해 보이는 것을 선택하는 대신 다른 가치를 고려할 수 있습니다.

1. 신입사원에게 가장 쉽게 설명할 수 있는
2. 가장 노련한 개발자의 코드 검토를 통과할 가능성이 가장 높음
3. 가장 유지 보수가 쉬운
4. 가장 빠르게 작성
5. 테스트하기 가장 쉬운
6. 가장 휴대성이 좋은
7. 등.

그러나 여기서 문제 자체가 어렵다는 것을 알 수 있습니다. 속도, 코드 크기, 메모리 풋프린트, 유연성 또는 미래 경쟁력에 대한 최적화를 피하는 것만이 아닙니다. 그것은 균형에 관한 것이고 당신이 하고 있는 일이 실제로 당신의 가치와 목표와 일치하는지에 관한 것입니다. 그것은 전적으로 상황에 따라 다르며 때로는 객관적으로 측정하는 것이 불가능합니다.

이것이 왜 좋은 일입니까? 인생이 이와 같기 때문입니다. 지저분해. 우리의 프로그래밍 지향적인 두뇌는 때때로 혼란에 질서를 너무 심하게 만들고 싶어해서 결국 우리는 혼란을 가중시키게 됩니다. 누군가에게 당신을 사랑하도록 강요하는 것과 같은 역설입니다. 당신이 그것에 성공했다고 생각한다면 그것은 더 이상 사랑이 아닙니다. 한편, 당신은 인질로 잡혀 있고 아마도 그 어느 때보다 더 많은 사랑이 필요할 것입니다. 이 은유는 내가 고를 수 있는 가장 어색한 비유 중 하나가 되어야 합니다.

어쨌든, 당신이 무언가를 위한 완벽한 시스템을 찾았다고 생각한다면 음… 환상이 지속되는 동안 즐기십시오. 괜찮아요, 실패는 배울 수 있는 멋진 기회입니다.

UX를 ​​염두에 두십시오

사용자 경험이 이러한 잠재적 우선 순위에 어떻게 들어맞는지 살펴보겠습니다. 결국, 어떤 것이 잘 수행되기를 바라는 것조차도 어느 정도 UX에 관한 것입니다.

UI 작업을 하고 있다면 코드에서 사용하는 프레임워크나 언어에 상관없이 어느 정도의 상용구와 반복이 있을 것입니다. 프로그래머의 시간과 코드 명확성 측면에서 이를 줄이기 위해 노력하는 것이 확실히 가치가 있을 수 있습니다. 우선 순위의 균형을 맞추는 기술을 돕기 위해 몇 가지 이야기를 나누고 싶습니다.

한 직장에서 내가 근무한 회사는 독단적인 기술 스택을 기반으로 하는 폐쇄 소스 엔터프라이즈 시스템을 사용했습니다. 사실, 우리에게 판매한 벤더가 스택의 의견에 맞지 않는 UI 사용자 정의를 거부할 정도로 너무 독단적이었습니다. 왜냐하면 그것은 개발자에게 너무 고통스러웠기 때문입니다. 나는 그들의 스택을 사용한 적이 없으므로 이것에 대해 그들을 비난하지 않습니다. 그러나 사실은 이 "프로그래머에게는 좋고 사용자에게는 나쁘다"라는 절충안이 특정 상황에서 동료들에게 너무 성가신 일이어서 내가 끝냈습니다. 시스템 UI의 이 부분을 다시 구현하는 타사 애드온을 작성합니다. (그것은 엄청난 생산성 향상이었습니다. 제 동료들은 그것을 좋아했습니다! 10년이 지난 후에도 여전히 모든 사람들의 시간과 좌절을 절약하고 있습니다.)

나는 의견이 그 자체로 문제라고 말하는 것이 아닙니다. 너무 많은 부분이 우리의 경우 문제가 되었습니다. 반례로 Ruby on Rails의 가장 큰 장점 중 하나는 너무 많은 선택권으로 인해 현기증을 일으키기 쉬운 프론트 엔드 생태계에서 독단적이라는 점 입니다 . (내 의견이 무엇인지 알 수 있을 때까지 의견을 제시하세요!)

대조적으로, 당신은 프로젝트에서 UX를 만물의 왕으로 칭하고 싶은 유혹을 받을 수 있습니다. 가치 있는 목표지만 두 번째 이야기를 할게요.

위 프로젝트가 성공하고 몇 년 후, 동료 중 한 명이 나에게 가끔 발생하는 특정 지저분한 실생활 시나리오를 자동화하여 UX를 최적화하여 한 번의 클릭으로 해결할 수 있도록 UX를 최적화하도록 요청했습니다. 시나리오의 많고 이상한 엣지 케이스 때문에 오탐이나 부정이 없는 알고리즘을 설계하는 것이 가능한지 여부를 분석하기 시작했습니다. 동료와 그것에 대해 이야기하면 할수록 요구 사항이 충족되지 않는다는 것을 더 많이 깨달았습니다. 시나리오는 한 달에 한 번만 발생했으며 현재 한 사람이 해결하는 데 몇 분이 걸렸습니다. 버그 없이 성공적으로 자동화할 수 있다 하더라도 필요한 개발 및 유지 관리 시간을 동료가 절약한 시간으로 환산하려면 수백 년이 걸릴 것입니다. 내 안의 사람을 기쁘게 하는 사람은 "아니오"라고 말하는 어려운 순간을 겪었지만 나는 대화를 짧게 잘라야 했습니다.

따라서 컴퓨터가 사용자를 돕기 위해 할 수 있는 일을 하도록 내버려 두십시오. 그런데 그것이 어느 정도인지 어떻게 압니까?

내가 취하고 싶은 접근 방식은 개발자가 코드를 프로파일링하는 것처럼 UX를 프로파일링하는 것입니다. 사용자가 같은 것을 계속해서 클릭하거나 입력하는 데 가장 많은 시간을 보내는 위치를 찾아내고 이러한 상호작용을 최적화할 수 있는지 확인하십시오. 귀하의 코드가 입력할 가능성이 가장 높은 것에 대해 교육받은 추측을 하고 이를 입력 없음 기본값으로 설정할 수 있습니까? 특정 금지된 상황(노 클릭 EULA 확인?)을 제외하고는 사용자의 생산성과 행복에 큰 영향을 미칠 수 있습니다. 가능하면 복도 사용성 테스트를 수행하십시오. 때로는 컴퓨터가 도움이 되는 것과 그렇지 않은 것을 설명하는 데 어려움을 겪을 수 있습니다. 하지만 전반적으로 이 값은 사용자에게 매우 중요합니다.

섣부른 최적화 방지: 최적화 시기와 방법

다른 컨텍스트에 대한 탐색에도 불구하고 이제 이 기사의 나머지 부분에서 원시 머신 성능의 일부 측면 을 최적화한다고 명시적으로 가정하겠습니다. 내가 제안한 접근 방식은 유연성과 같은 다른 대상에도 적용되지만 각 대상에는 고유한 문제가 있습니다. 요점은 섣부른 최적화는 실패할 가능성이 높다는 것 입니다.

그렇다면 성능 측면에서 실제로 따라야 할 최적화 방법은 무엇입니까? 파헤쳐 봅시다.

이것은 풀뿌리 이니셔티브가 아니라 Triple-Eh입니다.

TL;DR은 다음과 같습니다. 위에서 아래로 작업합니다. 높은 수준의 최적화는 프로젝트 초기에 수행할 수 있으며 낮은 수준의 최적화는 나중에 남겨두어야 합니다. 이것이 "조기 최적화"라는 문구의 대부분의 의미를 이해하는 데 필요한 전부입니다. 이 순서에 맞지 않는 일을 하면 팀의 시간을 낭비하고 역효과를 낼 가능성이 높습니다. 결국, 처음부터 전체 프로젝트를 기계어로 작성하지 않습니까? 따라서 우리의 AAA 방식 작업 은 다음 순서로 최적화하는 것입니다.

1. 건축물
2. 알고리즘
3. 집회

알고리즘과 데이터 구조는 최소한 성능과 관련하여 최적화하기에 가장 효과적인 장소라는 것이 일반적인 상식입니다. 그러나 아키텍처에 따라 사용할 수 있는 알고리즘과 데이터 구조가 결정되는 경우가 있습니다.

나는 한 번 모든 단일 금융 거래에 대해 SQL 데이터베이스를 여러 번 쿼리한 다음 클라이언트 측에서 매우 기본적인 계산을 수행하여 재무 보고서를 수행하는 소프트웨어를 발견했습니다. 소규모 기업에서 소프트웨어를 사용한 지 불과 몇 개월 밖에 되지 않아 상대적으로 적은 양의 재무 데이터에도 불구하고 새로운 데스크탑과 상당히 강력한 서버를 사용하여 보고서 생성 시간이 이미 몇 분에 이르렀다는 것을 의미했습니다. 그들은 꽤 자주 사용하는 데 필요했습니다. 나는 합산 논리가 포함된 간단한 SQL 문을 작성하게 되었습니다. 모든 중복과 네트워크 왕복을 피하기 위해 작업을 서버로 이동하여 아키텍처를 방해하고 몇 년 동안의 데이터를 나중에 내 버전에서 생성할 수도 있습니다. 동일한 오래된 하드웨어에서 밀리초 단위로 동일한 보고서를 생성합니다.

때로는 아키텍처 변경이 실현 가능하기에는 프로젝트에서 너무 늦기 때문에 프로젝트 아키텍처에 영향을 미치지 않습니다. 때로는 개발자가 위의 예에서 했던 것처럼 주변을 둘러볼 수 있습니다. 그러나 프로젝트 시작 단계에 있고 아키텍처에 대해 의견이 있다면 지금이 이를 최적화할 때입니다.

건축물

프로젝트에서 아키텍처는 사실 이후에 변경하기에 가장 비용이 많이 드는 부분이므로 초기에 최적화하는 것이 합리적일 수 있는 곳입니다. 예를 들어 앱이 타조를 통해 데이터를 전달하는 경우 나쁜 병목 현상을 더욱 악화시키지 않도록 저빈도, 높은 페이로드 패킷으로 구성하는 것이 좋습니다. 이 경우 사용자를 즐겁게 하기 위해 Tetris를 완벽하게 구현하는 것이 좋습니다. 로딩 스피너가 잘리지 않기 때문입니다. (농담: 몇 년 전에 나는 나의 첫 번째 Linux 배포판인 Corel Linux 2.0을 설치하고 있었고 장기 실행 설치 프로세스에 그런 것이 포함되어 있다는 사실에 기뻤습니다. Windows 95 설치 프로그램의 정보 광고 화면을 너무 많이 보았을 때 외웠습니다. 그 당시 신선한 공기의 호흡이었다.)

비용이 많이 드는 아키텍처 변경의 예로 앞서 언급한 SQL 보고서가 애초에 확장 불가능했던 이유는 그 역사에서 분명합니다. 이 앱은 MS-DOS에 뿌리를 두고 있으며 원래 다중 사용자도 아니었던 자체 개발한 맞춤형 데이터베이스에서 시간이 지남에 따라 진화했습니다. 공급업체가 마침내 SQL로 전환했을 때 스키마와 보고 코드가 일대일로 이식된 것처럼 보입니다. 이로 인해 주어진 보고서에 대해 SQL의 장점을 실제로 사용하여 아키텍처 전환을 완료할 때마다 업데이트 전체에 걸쳐 1,000% 이상의 인상적인 성능 향상을 수년 동안 사용할 수 있었습니다. 당시 고용주와 같은 종속된 클라이언트와 비즈니스에 적합하고 초기 전환 동안 코딩 효율성의 우선 순위를 분명히 하려고 합니다. 그러나 어떤 경우에는 망치가 나사를 돌리는 것만큼 효과적으로 고객의 요구를 충족합니다.

아키텍처는 부분적으로 프로젝트를 확장할 수 있어야 하는 정도와 방법을 예측하는 것입니다. 아키텍처는 매우 높은 수준이기 때문에 특정 기술과 영역으로 초점을 좁히지 않고는 "해야 할 일과 하지 말아야 할 일"을 구체적으로 정의하기가 어렵습니다.

나는 그렇게 부르지 않겠지만 다른 사람들은 다 그렇게 부른다

고맙게도 인터넷은 이제까지 꿈꿔왔던 대부분의 모든 종류의 건축에 ​​대한 수집된 지혜로 가득 차 있습니다. 아키텍처를 최적화해야 할 때라는 것을 알게 되면 함정에 대한 조사는 곧 당신의 멋진 비전을 설명하는 유행어를 알아내는 것으로 귀결됩니다. 누군가가 당신과 같은 방식으로 생각하고, 시도하고, 실패하고, 반복하고, 블로그나 책에 그것에 대해 게시할 가능성이 있습니다.

유행어 식별은 검색만으로는 달성하기 까다로울 수 있습니다. FLDSMDFR이라고 하는 것에 대해 다른 사람이 이미 SCOPWWHWTT라는 용어를 만들어 냈고 그들은 당신이 풀고 있는 동일한 문제를 설명하지만 당신과 완전히 다른 어휘를 사용하기 때문입니다. 구출에 개발자 커뮤니티! 가능한 한 철저한 설명과 함께 귀하의 아키텍처 가 아닌 모든 유행어를 사용하여 StackExchange 또는 HashNode를 방문하여 귀하가 충분한 사전 조사를 수행했음을 알 수 있습니다. 누군가가 당신을 기쁘게 해 줄 것입니다.

한편, 몇 가지 일반적인 조언은 생각할 거리가 될 수 있습니다.

알고리즘 및 어셈블리

도움이 되는 아키텍처가 주어지면 여기에서 팀의 코더가 시간 동안 가장 많은 T-bling을 얻을 수 있습니다. 조기 최적화의 기본적인 방지는 여기에도 적용되지만 프로그래머는 이 수준에서 몇 가지 세부 사항을 고려하는 것이 좋습니다. 구현 세부 사항에 관해서는 생각할 것이 너무 많아서 일선 및 선임 코더를 대상으로 하는 코드 최적화에 대한 별도의 기사를 작성했습니다.

그러나 일단 당신과 당신의 팀이 성능 면에서 최적화되지 않은 무언가를 구현했다면, 정말로 그것을 하지 않습니까? 최적화를 하지 않습니까?

네가 옳아. 다음 규칙은 전문가에게만 적용됩니다. Don't do it yet 입니다.

벤치마킹할 시간입니다!

코드가 작동합니다. 너무 느려서 최적화가 필요하다는 것을 이미 알고 있을 수도 있습니다. 자주 실행되는 코드이기 때문입니다. 확실하지 않거나 O(n) 알고리즘이 있고 아마도 괜찮을 것이라고 생각할 수 있습니다. 어떤 경우이든 이 알고리즘이 최적화할 가치가 있다면 이 시점에서 내 권장 사항은 동일합니다. 간단한 벤치마크를 실행합니다.

왜요? 내 O(n³) 알고리즘이 다른 어떤 것보다 더 나쁠 수 없다는 것이 분명하지 않습니까? 글쎄, 두 가지 이유:

1. 현재 충족되고 있는지 여부에 관계없이 성능 목표의 객관적인 측정으로 벤치마크를 테스트 제품군에 추가할 수 있습니다.
2. 전문가라도 실수로 작업 속도를 늦출 수 있습니다. 뻔한 것 같으면서도. 정말 분명합니다.

그 두 번째 점에서 나를 믿지 않습니까?

$7,000 하드웨어보다 $1,400 하드웨어에서 더 나은 결과를 얻는 방법

StackOverflow로 유명한 Jeff Atwood는 최적화에 귀중한 프로그래머 시간을 보내는 것보다 더 나은 하드웨어를 구입하는 것이 때때로(일반적으로 그의 의견으로는) 더 비용 효율적일 수 있다고 지적한 적이 있습니다. 자, 여러분의 프로젝트가 이 시나리오에 적합하다는 합리적이고 객관적인 결론에 도달했다고 가정해 보겠습니다. 더 나아가 최적화하려고 하는 것이 컴파일 시간이라고 가정해 보겠습니다. 작업 중인 Swift 프로젝트가 매우 크고 이것이 개발자 병목 현상이 상당히 크기 때문입니다. 하드웨어 쇼핑 시간!

무엇을 사야 합니까? 글쎄, 분명히 엔당 엔, 더 비싼 하드웨어가 더 저렴한 하드웨어보다 더 나은 성능을 발휘하는 경향이 있습니다. 따라서 분명히 7,000달러짜리 Mac Pro는 일부 중급 Mac Mini보다 더 빠르게 소프트웨어를 컴파일해야 합니다. 그렇죠?

잘못된!

때때로 더 많은 코어가 더 효율적인 컴파일을 의미한다는 것이 밝혀졌습니다... 그리고 이 특별한 경우에 LinkedIn은 스택에 대해 그 반대가 사실이라는 어려운 방법을 발견했습니다.

그러나 경영진이 한 가지 실수를 더 하는 것을 보았습니다. 그들은 전후에 벤치마크조차 하지 않았고 하드웨어 업그레이드가 소프트웨어를 더 빠르게 "느끼게"하지 않는다는 것을 발견했습니다. 그러나 확실히 알 수 있는 방법은 없었습니다. 더 나아가 그들은 병목 현상이 어디에 있는지 알지 못했기 때문에 문제에 할당할 시간과 돈을 다 써버렸지만 성능에 대해 여전히 불만이 있었습니다.

알겠습니다. 이미 벤치마킹했습니다. 실제로 아직 최적화할 수 있습니까 ??

예, 필요하다고 결정했다고 가정합니다. 그러나 아마도 그 결정은 더 많은/모든 다른 알고리즘도 구현될 때까지 기다려야 하므로 프로파일링을 통해 움직이는 부분이 어떻게 서로 맞고 어떤 것이 가장 중요한지 알 수 있습니다. 이것은 작은 앱의 앱 수준이거나 하나의 하위 시스템에만 적용될 수 있습니다. 어느 쪽이든 특정 알고리즘이 전체 앱에 중요해 보일 수 있지만 전문가, 특히 전문가라도 이를 오진하기 쉽습니다.

방해하기 전에 생각하십시오

"나는 너희들에 대해 잘 모르지만..."

마지막으로 생각할 거리로 잘못된 최적화라는 아이디어를 프로젝트나 회사 자체, 심지어 경제의 한 부문과 같은 훨씬 더 넓은 관점에 적용하는 방법을 고려하십시오.

기술이 세상을 구할 것이며 우리가 그 일을 가능하게 하는 영웅이 될 수 있다고 생각하는 것이 유혹적이라는 것을 압니다.

게다가 우리가 하지 않으면 다른 사람이 하게 됩니다.

그러나 최선의 의도에도 불구하고 권력은 부패한다는 것을 기억하십시오. 여기에 특정 기사를 링크하지는 않겠지만, 아무 기사도 건너뛰지 않았다면 경제를 혼란에 빠뜨리는 광범위한 영향과 이것이 때때로 궁극적으로 누구에게 도움이 되는지에 대해 찾아볼 가치가 있습니다. 최적화를 통해 세상을 구하려는 시도의 일부 부작용에 놀랄 수 있습니다.

추신

뭔가 눈치채셨나요, 옵티머스? 내가 너를 옵티머스라고 부른 건 처음과 끝이였을 때뿐이야. 기사 전체에서 당신은 Optimus라고 불리지 않았습니다. 솔직히 말할게요, 잊어버렸어요. 나는 당신을 Optimus라고 부르지 않고 전체 기사를 썼습니다. 내가 돌아가서 텍스트 전체에 당신의 이름을 뿌려야한다는 것을 깨달았을 때 내 안의 작은 목소리가 말했습니다. 하지 마십시오 .