설계 철학 및 원칙

​

설계 철학

OP Stack은 단순성(simplicity), 실용성(pragmatism), 지속 가능성(sustainability), 그리고 물론 **낙관주의(optimism)**라는 네 가지 주요 기둥에 기반한 확고한 설계 철학에 따라 구축되었습니다. 이 기둥들은 Optimism 전체의 설계에 큰 영향을 미치므로 이해하는 것이 중요합니다.

​

단순성

Optimism은 제공하는 기능 세트에 비해 최대한 단순하도록 설계되었습니다. 이상적으로 Optimism은 안전하고 확장 가능하며 유연한 L2 시스템에 필요한 최소한의 구성 요소로 이루어져야 합니다. 이러한 단순성 덕분에 Optimism의 설계는 더 복잡한 다른 L2 구조에 비해 여러 가지 중요한 이점을 갖습니다. 단순성은 엔지니어링 오버헤드를 줄여 주며, 이는 곧 기존 기능을 다시 만드는 대신 새로운 기능을 개발하는 데 시간을 쓸 수 있다는 의미입니다. Optimism은 가능한 한 실전에서 검증된 기존 Ethereum 코드와 인프라를 사용하는 것을 선호합니다. 이 철학이 실제로 적용된 가장 눈에 띄는 예는 Optimism의 클라이언트 소프트웨어로 Geth를 사용하기로 한 선택입니다. 중요 인프라를 다룰 때는 단순성이 곧 보안이기도 합니다. 작성하는 모든 코드 한 줄 한 줄이 의도치 않은 버그를 유발할 수 있는 기회가 됩니다. 프로토콜이 단순하다는 것은 작성할 코드가 적다는 뜻이며, 결과적으로 잠재적인 실수가 발생할 수 있는 영역도 줄어듭니다. 깔끔하고 최소한의 코드베이스는 외부 기여자와 감사자에게도 더 접근하기 쉽습니다. 이 모든 것이 Optimism 프로토콜의 보안성과 정확성을 극대화하는 데 기여합니다. 단순성은 Optimism의 장기적인 비전에도 중요합니다. Ethereum 도구 위에 작성하는 코드의 양을 제한함으로써, 대부분의 시간을 기존 코드베이스와 직접 작업하는 데 쓸 수 있습니다. Optimism에 투입된 엔지니어링 노력은 Ethereum에도 직접적인 혜택이 될 수 있으며, 그 반대도 마찬가지입니다. 이는 Optimism 프로토콜이 안정화되고 기존 리소스를 핵심 Ethereum 인프라로 돌릴 수 있게 될수록 더욱 두드러질 것입니다.

​

실용성

이상주의에도 불구하고, Optimism의 설계 프로세스는 궁극적으로 실용성에 의해 이끌어집니다. Optimism 핵심 팀에는 현실적인 제약이 있고, Optimism 위에 구축하는 프로젝트에는 현실적인 요구가 있으며, Optimism을 사용하는 사용자에게는 현실적인 문제가 있습니다. Optimism의 설계 철학은 이론적 완벽함보다 사용자와 개발자의 요구를 우선시합니다. 때로는 가장 좋은 해결책이 가장 보기 좋은 해결책은 아닙니다. Optimism은 또한 어떤 핵심 팀이든 전문 분야가 제한적일 수밖에 없다는 이해를 바탕으로 개발됩니다. Optimism은 반복적으로 개발되며, 사용자로부터 지속적으로 피드백을 얻기 위해 노력합니다. 현재 Optimism의 많은 핵심 기능(예: EVM 동등성)은 이러한 반복적인 프로토콜 개발 방식 덕분에 가능했습니다.

​

지속 가능성

Optimism은 장기적인 관점으로 운영됩니다. 애플리케이션 개발자는 자신이 구축하는 플랫폼이 장기간에 걸쳐 단순히 운영되는 것뿐만 아니라 경쟁력을 유지할 것이라는 확신이 필요합니다. Optimism의 설계 프로세스는 장기적인 지속 가능성을 중심으로 구성되며, 확장성을 위해 지름길을 택하지 않습니다. 결국, 확장 가능한 시스템도 그것을 지탱하는 생태계가 없으면 아무 의미가 없습니다. 지속 가능성은 단순성 철학과 맞물려 Optimism의 프로토콜 설계에 적극적으로 영향을 미칩니다. 코드베이스가 복잡할수록 핵심 개발 팀 외부의 사람들이 적극적으로 기여하기가 더 어려워집니다. 코드베이스를 단순하게 유지함으로써, 장기적으로 프로토콜 유지 관리를 도울 수 있는 더 큰 기여자 커뮤니티를 구축할 수 있습니다.

​

낙관주의

물론 이 모든 것은 낙관주의 없이는 불가능합니다. Ethereum 비전에 대한 낙관이 이 프로젝트를 계속 앞으로 나아가게 합니다. 우리는 Ethereum의 낙관적인 미래, 즉 우리의 삶을 조율하는 기관들과의 관계를 새롭게 설계할 수 있는 미래를 믿습니다. Optimism은 독립적인 블록체인처럼 보이지만, 궁극적으로 Ethereum의 확장으로 설계되었습니다. 새로운 기능을 만들거나 기존 기능을 단순화하려고 할 때마다 이 점을 염두에 둡니다. Optimism이 최대한 Ethereum에 가깝게 유지되는 것은 실용적인 이유 때문만이 아니라, Optimism이 Ethereum의 성공을 위해 존재하기 때문입니다. Optimism의 설계를 살펴보면서 이 철학의 영향을 확인할 수 있기를 바랍니다.

​

USEful 소프트웨어를 위한 설계 원칙

OP Stack은 USEful 소프트웨어입니다. OP Stack은 L2 블록체인 생태계를 구축하기 위한 소프트웨어 구성 요소 세트로, Optimism을 구동하기 위해 Optimism Collective가 구축했습니다. OP Stack에 추가되는 구성 요소는 **유용성(Utility), **단순성(Simplicity), **확장성(Extensibility)이라는 세 가지 핵심 설계 원칙에 따라 구축되어야 합니다. 이러한 원칙을 따르는 소프트웨어는 Optimism Collective를 위한 USEful 소프트웨어입니다!

​

유용성

OP Stack의 일부가 되려면 Optimism Collective를 구동하는 데 도움이 되어야 합니다. 이 조건은 스택에 포함될 수 있는 소프트웨어의 유형을 결정하는 데 지침이 됩니다. 예를 들어, 사용자가 OP Stack 체인을 더 쉽게 살펴볼 수 있게 해 주는 강력한 오픈 소스 블록 탐색기는 OP Stack에 훌륭한 추가 요소가 될 것입니다. OP Stack에 포함되려면 유용성이 중요하지만, 실험을 두려워할 필요는 없습니다. 과감한 시도를 해 보십시오. 명확한 유용성이 없더라도 지금까지 만들어진 적 없는 무언가를 만들어 보십시오. 이모지를 위한 블록체인이든 무엇이든 만들어 보십시오. 즐기십시오!

​

단순성

복잡한 코드는 확장되지 않습니다. OP Stack에 포함되는 코드는 단순해야 합니다. 단순성은 엔지니어링 오버헤드를 줄여 주며, 이는 곧 Collective가 기존 기능을 다시 만드는 대신 새로운 기능을 개발하는 데 시간을 쓸 수 있다는 의미입니다. OP Stack은 가능한 한 실전에서 검증된 기존 코드와 인프라를 사용하는 것을 선호합니다. 이 철학이 실제로 적용된 가장 눈에 띄는 예는 OP Stack의 기본 실행 엔진으로 Geth를 사용하기로 한 선택입니다. 중요 인프라를 다룰 때는 단순성이 곧 보안이자 유지 보수성이기도 합니다. 작성되는 모든 코드 한 줄 한 줄이 버그와 취약점을 유발할 수 있는 기회가 됩니다. 프로토콜이 단순하다는 것은 작성할 코드가 적다는 뜻이며, 결과적으로 잠재적인 실수가 발생할 수 있는 영역도 줄어듭니다. 깔끔하고 최소한의 코드베이스는 외부 기여자와 감사자에게도 더 접근하기 쉽습니다. 이 모든 것이 OP Stack의 보안성과 정확성을 극대화하는 데 기여합니다.

​

확장성

좋은 OP Stack 코드는 본질적으로 개방적이고, 협력적이며, 확장 가능합니다. 협업을 통해 고립된 개발에서 벗어날 수 있습니다. 협업을 통해 동일한 구성 요소를 반복해서 다시 만드는 데 드는 시간을 줄이고, 서로의 작업 위에 구축하는 데 더 많은 시간을 쓸 수 있습니다. 협업은 우리가 함께 성공하는 방법입니다. 확장 가능한 코드는 다른 사람들이 그 코드를 사용하고 그 위에 구축하고 싶어 할 것이라는 생각으로 설계되어야 합니다. 실제로 이는 코드가 (허용적 라이선스하에) 오픈 소스여야 하고, 깔끔한 API를 노출해야 하며, 다른 개발자가 비교적 쉽게 코드의 기능을 확장할 수 있도록 전반적으로 모듈화되어 있어야 한다는 것을 의미합니다. 확장성은 Optimism Collective 생태계 내에서 협업이라는 강력한 힘을 이끌어 내는 핵심 설계 원칙입니다.