# 상위 1% 엔지니어의 7가지 간단한 습관

> Clean Markdown view of GeekNews topic #11362. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=11362](https://news.hada.io/topic?id=11362)
- GeekNews Markdown: [https://news.hada.io/topic/11362.md](https://news.hada.io/topic/11362.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2023-10-16T11:06:02+09:00
- Updated: 2023-10-16T11:06:02+09:00
- Original source: [engineercodex.substack.com](https://engineercodex.substack.com/p/7-simple-habits-of-the-top-1-of-engineers)
- Points: 107
- Comments: 11

## Topic Body

- "엘리트 코더가 다른 코더보다 뛰어난 능력을 발휘하는 방법"  
### 코더가 아닌 엔지니어가 될 것 (Be an engineer, not a coder)  
- 엔지니어링은 문제를 해결하는 것   
- 최고의 엔지니어는 코드를 목적 달성을 위한 수단으로 생각함   
- 코드를 작성하는 즐거움은 있지만 목적이 없는 코드를 작성하는 것은 의미가 없음. 대신 코드는 사용자를 위한 솔루션을 설계하는 데 사용됨  
- 코딩은 창의성을 추구함! 창의력은 제약 조건 하에서 많이 발생함. 해결해야 할 명확한 문제라는 '제약'을 추가하면 엔지니어는 자신이 적합하다고 생각하는 방식으로 솔루션을 탐색하고 만들 수 있는 자유를 누릴 수 있음   
- 최고의 엔지니어들은 제품 중심적이며, 무엇보다도 사람을 위한 문제 해결을 최우선으로 생각하며, 이는 다음 단계로 이어짐   
### 컴퓨터가 아닌 인간을 위한 코드 (Code for the human, not the computer)  
> "바보라도 누구나 컴퓨터가 이해할 수 있는 코드를 작성할 수 있습니다. 훌륭한 프로그래머는 인간이 이해할 수 있는 코드를 작성합니다." - 마틴 파울러  
- 코드는 컴퓨터뿐만 아니라 인간을 위한 것  
- 코드는 그 코드를 읽고, 유지 관리하고, 당신의 코드 위에 빌드하는 같은 팀 엔지니어를 위한 것  
- 코드는 휴대전화를 사용하는 어린아이, API를 호출하는 개발자, 본인 등 사용자를 위한 것  
- 최고의 엔지니어들은 항상 모든 사용자를 위해 코드의 가치를 평가했음   
- 만약 그들이 고객 중 한 명이라도 만족시키지 못하면 그 코드는 프로덕션에 적용되지 못했음   
### 코드 자체에서 벗어나기 (Detach from the code itself)  
- 뛰어난 엔지니어는 코드 자체에 집착하지 않음   
- 그들은 최종 결과물이 전반적으로 더 좋아질 수 있다면 90% 정도 완성된 코드라도 삭제하고 다시 시작하는 것을 두려워하지 않음   
- 코드는 개인적인 것이 아니기 때문에 피드백을 적극적으로 받아들임   
- 코드는 완벽하지 않음. 아무도 완벽한 코드에 관심을 두지 않음. 변화를 가져오는 코드에 관심이 있을 뿐  
- 코드에 집착하지 않도록 스스로를 가르치는 가장 좋은 방법은 "20년 후에는 당신 코드의 대부분이 기술 부채가 되거나 더 이상 사용되지 않거나 다시 작성될 가능성이 높다는 것을 깨닫는 것"  
### 일관된 표준 사용 (Use consistent standards)  
- 코드를 작성할 때 일관된 표준과 코딩 스타일을 고수할 것  
- 일관성(Consistency)을 유지하면 미래의 당신과 팀원 모두가 코드를 더 쉽게 읽고 이해할 수 있게 해줌   
- 일관된 스타일 가이드를 사용하면 팀과 코드베이스 모두 더 쉽게 확장할 수 있음  
  - 이게 Meta/Google 같은 회사가 시간이 지나도 코드베이스를 읽을 수 없거나 유지 관리할 수 없게 되는 일 없이 많은 코드를 신속하게 배포하는 방법  
- 모든 뛰어난 성과를 내는 기업은 스타일 가이드를 내재화하고 그 이점을 알고 최대한 이를 따랐음   
  - 구글은 일부 스타일 가이드를 오픈소스로 공개했음   
  - 메타는 그들의 일부 오픈소스에 C++ 스타일 가이드가 있음   
- 팁: 당신의 팀을 위해서 Linter를 포맷팅하는 것은 확실히 시간을 들여 설정할 가치가 있음   
### 간단한 코드를 작성 (Write simple code)  
- 내가 아는 모든 엘리트 엔지니어는 생성하기엔 복잡했을 수도 있지만, 결국엔 읽고 이해하기 쉬운 코드를 생성했음   
- 이에 대해 내가 한 가장 좋은 말은 그들의 코드가 "미학적으로 만족스럽다는 것"  
- 그들의 코드는 깔끔하고, 체계적이며, 논리적(clean, organized, and logical)  
- 코드에서 내린 각 결정은 의미가 있었고, 그렇지 않은 경우엔 코드내에 잘 문서화 되어 있었음   
- 깔끔한 코드를 작성하는 좋은 방법은 SOLID 원칙과 같은 원칙을 따르는 것. 처음에는 OOP(객체 지향 프로그래밍)를 염두에 두고 설계되었지만 일반 프로그래밍에도 확장할 수 있음   
  - Single Responsibility: 한 클래스는 하나의 책임만 가져야 함   
  - Open-Closed: 소프트웨어 객체(클래스, 모듈 등)는 확장에는 개방적이지만 수정에는 폐쇄적이어야 예측 가능하고 유지 관리 가능한 코드를 만들 수 있음   
  - Liskov Substitution: 하위 유형은 프로그램의 정확성에 영향을 주지 않으면서 기본 유형으로 대체할 수 있어야 함   
  - Interface Segregation: 코드가 모든 것을 사용하지 않는 거대한 인터페이스에 종속되어서는 안 됨. 대신 패키지는 더 작은 특정 인터페이스를 포함하고 임포트할 수 있도록 허용해야 함  
  - Dependency Inversion: 상위 레벨 모듈이 하위 레벨 모듈에 종속되어서는 안 되며, 둘 다 추상화에 종속되어 보다 유연하고 분리된 시스템 설계를 촉진해야 함   
- 그 예로 이름 짓기(Naming)를 들 수 있음: 좋은 이름에는 마법의 값이 없고, 구분이 명확하며, 설명적인 함수 이름과 이해하기 쉬운 변수를 표현함   
### 의외성을 허용하지 않음 (Don’t allow surprises)  
- 코드는 예상치 못한 결과를 만들어서는 안 됨. 이는 코드 원칙을 따르고 적절한 테스트를 작성함으로써 가능  
- 좋은 코드는 예측 가능함   
- 테스트는 코드의 명확성과 예측 가능성을 강화하고, 자신감을 줌. 우수한 자동화된 테스트를 통해 팀은 보이지 않는 부분을 깨뜨릴 염려 없이 코드를 변경할 수 있음   
- 몇가지 테스트 유형   
  - 개별 컴포넌트 및 격리된 함수에 대한 단위 테스트  
  - 여러 컴포넌트 간의 상호 작용을 위한 통합 테스트  
  - 사용자 관점에서 전체 시스템의 기능을 평가하는 엔드투엔드 테스트  
- 테스트는 간단해야 함. 실패한 테스트를 읽었을 때 무엇이 잘못되었는지 쉽게 파악할 수 있어야 됨   
- 테스트하지 말아야 할 항목을 아는 것도 중요  
  - 예를 들어, 엔드투엔드 테스트의 수고가 프로그램의 실제 이점보다 크다면 테스트는 신중한 문서화, 모니터링 및 적절한 사람(예: 코드 소유자)에게 알림을 보내는 것으로 대체  
  - 또한 테스트는 프론트엔드 코드에서 특정 CSS 선택기를 테스트하는 것과 데이터 속성 또는 스크린샷 테스트만을 사용하는 것과 같이 코드 내의 구현 세부 사항을 테스트해서는 안 됨   
### 자주 소통하기 (Communicate often)  
- 훌륭한 시스템은 혼자서 만들어지지 않음. 훌륭한 엔지니어들은 설계 검토를 거치고, 피드백을 요청하고, 코드에 대한 초기 설계를 계속 반복했음   
- 누구나 자신의 지식에는 다른 사람이 채워줄 수 있는 빈틈이 있음. 새로운 관점은 종종 코드를 더 명확하게 만들거나 이전에는 생각하지 못했던 새로운 접근 방식을 제공하는 데 도움이 될 수 있음   
- 최고의 엔지니어들은 더 나은 최종 결과물을 얻기 위해 시간을 들여 함께 작업하는 것을 두려워하지 않고 소통과 협업을 중시  
- 문서에 대한 빠른 검토를 위해 팀원에게 핑을 보내거나 중요한 풀 리퀘스트에 코드 검토자를 추가하는 것처럼 간단하게 할 수 있음   
### 빠르게... 그리고 느리게 코딩하기 (Code fast… and slow)  
- 내가 아는 최고의 엔지니어들은 프로젝트를 빠르게 완료하지만 코딩은 느리게 함   
- 이상하게 들리죠?  
  - 위의 모든 원칙과 습관은 코딩의 첫 번째 단계에 더 많은 시간을 추가함. 하지만 이러한 원칙과 습관을 통해 엔지니어는 프로젝트의 진행 상황을 한 단계씩 발전시킬 수 있음   
  - 표준을 사용하고, 제대로 테스트하고, 원칙을 사용하고, 자주 소통하는 데 시간을 할애함으로써 장기적으로 더 많은 시간을 절약할 수 있음   
- 인턴과 주니어 엔지니어 시절에 제가 직접 경험했고, 다른 많은 엔지니어들도 마찬가지겠지만, 3보 전진을 서두르다 장애물에 부딪혀 5보 후퇴하게 될 수 있음   
### 맹목적으로 규칙을 따르지 말 것 (Don’t follow rules blindly)  
- 위의 '규칙'과 '원칙'은 단순한 가이드라인일 뿐. 모든 것이 가이드라인에 깔끔하게 잘 들어맞는 것은 아님   
- 때로는 작성 중인 코드가 원 안에 들어가지 않는 정사각형일 수도 있지만 괜찮음  
  - 이 경우 코드가 특정 방식으로 작성된 이유를 문서화할 것   
  - 그렇지 않으면 미래의 여러분과 같은 누군가가 나중에 코드를 보고 "와, 그때는 내가 멍청했었지. 왜 이게 우리 표준을 따르지 않는 거지?"라고 생각할 수 있음   
  - 그러면 그들은 이전과 같은 결론에 도달하기 위해 20시간 동안 표준에 맞게 다시 코딩하는 데 시간을 소비할 것  
- 소프트웨어 개발의 현실은 모든 코드가 깔끔하거나 규칙을 완벽하게 따를 수 없다는 것  
- 하지만 일관성 있고, 깔끔하고, 이해하기 쉽고, 테스트할 수 있고, 가치 있는 코드는 존재할 수 있음   
- 최고의 엔지니어에게서 발견한 또 다른 패턴들   
  - **적어도 한 가지 분야에 대한 깊은 도메인 지식을 가짐.** 제가 기록했던 모든 엔지니어는 프론트엔드 인프라, 분산 시스템, 깔끔한 UI 등 특정 분야에 집중하여 전문가가 되었기 때문에 현재 해당 분야에서 최고의 자리에 올랐음   
  - **자신을 자주 그리고 적절하게 마케팅함.** 이 엔지니어들은 눈에 잘 띄지 않는 곳에 숨어 있지 않았음. 팀원들과 함께 일하는 모든 사람들이 자신의 가치와 전문성을 알고 있었고, 이는 적절한 마케팅과 영향력 있는 프로젝트를 수행한 결과

## Comments



### Comment 26249

- Author: greety
- Created: 2024-06-14T09:32:46+09:00
- Points: 1

좋은 인사이트를 얻었어요. 감사해요 :)

### Comment 20071

- Author: geekbini
- Created: 2023-10-22T23:35:47+09:00
- Points: 1

좋은 글이네요!

### Comment 19970

- Author: nina514
- Created: 2023-10-18T15:03:19+09:00
- Points: 1

기술도 중요하지만 역시 사람을 이롭게 하는 프러덕트를 만드는게 중요하다는걸 다시 한번 생각하게 되네요!!!

### Comment 19933

- Author: functor
- Created: 2023-10-17T10:21:06+09:00
- Points: 1

좋은 글 감사합니다!

### Comment 19934

- Author: functor
- Created: 2023-10-17T10:21:21+09:00
- Points: 1
- Parent comment: 19933
- Depth: 1

이제보니 7가지 습관인데 내용은 9가지네요 ㅋㅋ

### Comment 19943

- Author: xguru
- Created: 2023-10-17T11:06:48+09:00
- Points: 1
- Parent comment: 19934
- Depth: 2

저도 세어봤는데.. 맨 뒤랑 맨 앞은 그냥 타이틀인거 같아요! ㅎㅎ

### Comment 19914

- Author: saalome
- Created: 2023-10-16T12:00:02+09:00
- Points: 1

와 대부분 공감되는 멋진글 ㅎ

### Comment 19917

- Author: saalome
- Created: 2023-10-16T14:41:30+09:00
- Points: 1
- Parent comment: 19914
- Depth: 1

지금 까지 봤던 이런 류의 글중에서 역대급 컨텐츠

### Comment 19913

- Author: rsm0503
- Created: 2023-10-16T11:36:16+09:00
- Points: 1

조금만 일반화하면 모든 사람에게 도움이 될 좋은 글이네요

### Comment 19911

- Author: kuroneko
- Created: 2023-10-16T11:11:27+09:00
- Points: 1

이정도면 요약이 아니라 번역 같긴 하지만... 요약 너무 감사합니다.  
수시로 읽어볼만한 글이네요.

### Comment 19912

- Author: piriri11
- Created: 2023-10-16T11:34:02+09:00
- Points: 1
- Parent comment: 19911
- Depth: 1

정말 그렇네요ㅋㅋㅋ저도 두고두고 읽어보려 합니다.
