- 4년 전에도 같은 주제로 글을 작성했고, 10년째에 돌아보기로 해서 다시 작성함
바뀐 생각들
- 단순함은 저절로 주어지지 않고, 지속적 노력이 필요한 요소임
- 복잡성을 관리하거나 이해하는 것에 자부심을 가질 이유가 없음을 깨달았음
- 다양한 경험 수준이 섞인 팀에서는 Typed 언어가 필수적임
- Java는 재미없어서 오히려 훌륭한 언어임
- REPL은 설계 도구로서는 유용하지 않지만 탐색적 용도로는 유용함
- 실제 프로그래밍은 코드를 작성하기 전 단계에서 거의 다 이루어져야 함
- Frontend 개발은 Kafkaesque 악몽과 같은 영역이 되었고, 더 이상 즐겁지 않음
- 우아함이라는 개념은 실제 측정 지표가 되지 못함
- 제대로 된 매니지먼트는 매우 귀중한 존재임 (오랜 경력 동안 제대로 된 매니지먼트를 거의 보지 못했음)
- DynamoDB는 특정 워크로드에 정확히 부합한다면 좋은 데이터베이스임
- 객체지향은 잘 맞는 영역에서 탁월한 방식임. Functional만 맹신하는 태도는 어리석음
얻게 된 의견들
- 엔지니어링의 핵심은 소통
- Java에서 Monad 개념을 너무 심하게 적용하면 안 됨
- Query Planner는 혹독한 존재임
- 어떤 것이 '쉽다'고 느끼는 순간은 사실 제대로 이해하지 못했다는 신호임
- 신입 개발자에게 탐구와 실수를 할 수 있는 여유를 주어야 함
- Soft skill을 적극적으로 발전시켜야 함. 투자 효과가 즉각적으로 나타남
- 일반 애플리케이션 개발에서는 '진짜 범용 추상화'라는 것이 거의 없음. 필요한 코드만 작성하는 편이 좋음
- 반면, 라이브러리 개발은 추상을 설계하는 일임. 올바른 구조(알제브라적 형태)를 찾는 데 시간을 들여야 함
- ORM은 모든 언어, 모든 구현에서 문제가 많음. 그냥 SQL을 직접 작성하는 편이 나음
- Functional 프로그래밍의 문제는 종종 그 신봉자들 때문임
- 충분히 오랜 기간이 지나면 Serverless Functions 위에 시스템을 쌓은 것을 크게 후회하게 됨
- Type은 우리가 세상을 바라보며 내리는 단언임
- 분산 락은 여전히 대단히 어려운 문제임
- 형식적 모델링과 분석 능력은 반드시 갖춰야 할 역량임
- 통합 테스트 스위트에서 가장 중요한 특성은 격리성임
- DynamoDB는 일반 애플리케이션 개발을 위한 최악의 선택이 될 수도 있음
- 대부분의 사람들은 코드 '장인 정신'에 크게 관심이 없음. 관심을 가지는 사람을 소중히 대하되, 나머지 사람들과는 그들이 있는 자리에서 협업해야 함
- Gradual, dependently typed 언어가 미래라는 생각임
- 테스트 코드에는 아무리 많은 주석을 달아도 부족함이 없다는 확신임
바뀌지 않은 의견들
- 코드 스타일, 린팅 규칙 등 사소한 문제에 집착하는 사람들은 여전히 이상한 부류라고 생각함. 더 중요한 것에 집중해야 함
- 코드 커버리지는 코드 품질과 무관하다는 입장을 유지함 (많은 경우 반비례하는 경향도 있음)
- Monolith는 여전히 괜찮은 선택이라고 여김
- 수십 년간 축적된 RDBMS 연구와 개선을 이기는 것은 어렵다는 점을 인정함
- Micro-service를 적용하려면 합당한 이유가 필수적임 (요즘 점점 당연시되는 경향이 아쉬움)
- 대부분의 프로젝트(심지어 AWS 내부 프로젝트도 마찬가지)는 실제로 '스케일링'이 필요 없고, 오히려 스케일링을 전제로 설계하면 해가 되는 경우가 많음
- 프로젝트 매니저의 93%, 어쩌면 95.2% 정도는 사라져도 별 영향이 없거나 오히려 효율성이 높아질 것이라는 생각임 (4년 전보다 비율이 상승했음)
- 15년 차에는 또 어떻게 달라질지 지켜볼 예정임