디자인을 과하게, 빌드는 충분히

Source: Dev.to

“과잉 설계는 미숙한 엔지니어의 특징이다”

소개

“가장 단순한 해결책이 언제나 최선이다”라는 이야기는 전 세계 컴퓨터 과학 교실에서 가르쳐집니다. 저도 그 말을 믿고 시스템을 가능한 한 단순하게 만들기 위해 몇 시간을 들여 재설계했지만, 결국 너무 지나쳐 다시 설계해야 했습니다. 하루가 끝날 무렵, 구현보다 설계 수정에 더 많은 시간을 쓰게 되었습니다.

인턴십 동안 선임 엔지니어들과 나눈 대화는 과잉 설계가 자산이 될 수도 있음을 보여주었습니다. 예를 들어 로봇공학에서는 과잉 설계를 억제해야 할 악덕이 아니라 받아들여야 할 기술로 보게 되었습니다.

진실은 단순한 구현이 과잉 설계된 구현보다 낫다는 것이지만, 과잉 설계된 디자인은 그 단순한 구현이 올바른지 확인하는 데 유용한 도구라는 점입니다.

기본 규칙

과잉 설계는 위험합니다. 사람들에게 경고하는 이유가 있습니다. 해를 최소화하고 이득을 얻으려면 엄격한 규칙을 따라야 합니다.

과잉 설계된 솔루션은 절대 완전히 구현해서는 안 된다

가능한 한 많은 엣지 케이스를 고려한 광범위한 설계를 만든 뒤, 구현 단계에서 무자비하게 단순화합니다. 설계 단계에서 실패 모드를 생각해 보는 것이 나중에 발견하는 것보다 쉽습니다. 과잉 설계를 생산용 청사진이 아니라 정신적 스트레스 테스트로 여기세요.

솔루션 복잡도는 문제 복잡도에 맞춰야 한다

할 일 목록 앱에 가상 머신 수준의 아키텍처가 필요하지는 않습니다. 복잡한 문제에 과잉 설계하는 것은 위험 관리가 될 수 있지만, 단순한 문제에 과잉 설계하는 것은 단지 미루는 행위일 뿐입니다.

영리함보다 명료함

최종 솔루션은 명확해야 합니다. 이해를 방해하는 영리한 한 줄 코드나 “10배 엔지니어” 트릭에 아무도 관심을 갖지 않습니다. 다른 사람(그리고 미래의 자신)이 읽을 수 있는 견고한 코드를 작성하고, 무엇보다 왜를 문서화하세요.

문제 영역 이해하기

“나는 아무것도 모른다는 것만 안다.” – 소크라테스

과잉 설계는 과시가 아니라 탐구입니다. 모든 문제에 대해 모든 것을 알 수는 없으며, 무엇을 알아야 할지 판단하기 어려울 때가 많습니다. 과잉 설계는 올바른 질문을 하게 만듭니다:

• 내 시뮬레이터가 공간 해싱을 사용해야 할까, 아니면 오버헤드가 너무 클까?
• 내 웨어 레벨링 알고리즘에 비트 마스킹을 포함해야 할까, 아니면 불필요한 정보를 저장하고 있는 걸까?

디자인에 맞지 않는 무언가를 억지로 끼워 넣을 필요는 없지만, 제외 기준은 높게 잡아야 합니다. 특정 문제가 특정 솔루션을 필요로 하지 않는다는 이유를 정확히 아는 것이, 필요하다는 이유를 아는 것만큼 중요합니다.

디자인의 표면적을 늘리는 것은 숨은 이점도 제공합니다.

실패 커버리지

“코드를 작성하기 전에 발생할 수 있는 모든 문제를 파악하는 것이 가장 좋은 일이다. 나중에 수정하는 것보다 비문제들을 걸러내는 것이 훨씬 낫다.”

내 웨어 레벨링 솔루션에 대해 기술 리드가 남긴 일회성 코멘트가 기억에 남았습니다. 처음에는 모든 가능한 오류—페이지 마모, 전원 손실 중간 쓰기, 방사선에 의한 비트 플립 등—를 처리하려고 했습니다. 한 번에 모두 구현하는 것은 불가능했지만, 어떤 엣지 케이스가 실제로 중요한지 파악하는 연습이 되었습니다.

설계 단계에서 과잉 설계하면 미래의 자신에게 더 큰 도움이 됩니다. 구현 자체가 이미 어렵고, 예기치 않은 실패 모드를 커버하기 위해 새로운 설계 부분을 발명해야 한다면 결정 피로도가 늘어날 뿐입니다.

이점은 순수히 실용적인 것만은 아닙니다. 과잉 설계는 재미있을 수 있습니다—탐구적인 놀이가 동기를 부여하죠. 과잉 설계 경향이 있다면, 이를 받아들이되 적절히 억제하세요.