몇 달 전 긱뉴스에서 Software development topics I’ve changed my mind on after 10 years in the industry라는 재미난 포스트를 본 적이 있어 비스무리하게 정리해보았다. 이 사람보다는 더 빈번히, 그리고 하나씩 매년 이정표 삼아 남기는 것도 재미있을 것 같다.
- Go라는 웹 프로그래밍의 또다른 선택지.
- OS 스레드를 거치는 오버헤드가 없는 Go 런타입에서 스케줄링이 되는 Goruntine의 유용함.
- C, C++, Java, TS, Go를 관통하는 타입의 중요성.
- 클래스, 객체, 메서드, 상속, 다형성이라는 객체지향의 핵심은 이름이나 구현 방식이 다를 뿐 Go에도 존재. 즉 근간은 똑같다.
- 프롬프트 사용은 일정 단축을 위한 악마와의 거래.
- 이왕 쓸 것이라면 차라리 프로젝트 구조나 보일러플레이터처럼 정형화한 패턴을 잡고 가는 것이 낫다. 바이브 코딩의 위험성.
- 창의성 < 명확성. 창의적인 코드라고 해도 로직이 눈에 잘 들어오지 않는다 싶으면, 장기적으로는 과감히 빼는 거가 나을지도.
- 무의미한 확장을 설계하는 것은 좋지 않은 습관. You Aren’t Gonna Need. 이 부분은 꼭 고쳐야 된다고 생각.
- 소프트웨어 아키텍처의 중요성. 불필요한 추상화는 회피해야 한다.
- 일반 어플리케이션 개발이라면 필요한 코드만 작성하는 것이 좋음. 라이브러리라면 이 레이어가 필요한지 초기 고민이 필요함.
- 복잡성보다 단순함을 위해 지속적인 노력을 들여야 함.
- ORM, 쿼리 빌더보다 직접 SQL을 작성하는 것이 일반적으로 낫다. sqlc처럼 타입 안정성이 보장되면 동적인 부분으로 인해 쿼리가 장황해진다거나, 뭔가 하자가 있다.
- 모든 내용은 기록해야 한다. 안 그러면 까먹는다…
- 로컬의 git 브랜치를 기록 용도로 쓰는 것은 괜찮은 것 같다.
- 기술 블로그도 나쁘지 않은듯, 그렇지만 읽기 좋은 글을 쓰기 위한 비용은 비싸므로 주의 필요.
- RDBMS ? NoSQL. 정확힌 데이터 정형화가 어려운 경우가 존재한다. 스키마 기반의 데이터 일관성 (ACID)나 수직 확장 (Scale-up)이, 혹은 Key-Value 형태의 데이터 유연성과 수평 확장 (Scale-out)이 유용할 때가 존재한다.
- 그렇지만 아직까지 대규모 트래픽을 요하는 NoSQL 서버를 보진 못했다. (기껏해야 사내 로그 서버 정도?) 이런 부분은 경험이 쌓여야 알 수 있을 부분.
- Infra의 재발견, OS의 중요함. 인프라 엔지니어와 같이 작업하면서 웹 개발에 국한된 시야를 많이 넓힘.
- 개념으로 알던 컨테이너 오케스트레이션, 모니터링·로그 시스템과 같은 DevOps 영역을 실무에서 처음 접해봄. (배움은 끝이 없음을 통감…)
- 홈서버를 하나 들여와서 사내에서처럼 Linux OS에 Xen, k8s를 굴려보는 중.
- Don’t Repeat Yourself. 중복보다는 재사용, 단일 원천 (Single Source of Truth) 유지.
- 유틸리티 함수는 패키지로 따로 빼서 관리. (util/ptr, util/time, …)
- 베스트 프랙티스는 상황마다 다름. 임기응변이 빛을 발할 때도 있다.
- 업무에 타임 리미트가 걸리면서 선 조치 후 개선을 염두에 둔 코드 작성이 많아짐. 근데 시간이 지나서 리펙토링하면 기존 것만 못할 때가 많음.
- 이력서는 6개월마다 업데이트해야 한다.
- 정작 아직 업데이트를 못한 것이 함정이지만… 업무에 매몰되면 간혹 내가 잘 하고 있는지 헷갈릴 때가 많음. 나 자신에 대한 비판적 피드백.
- 종이는 터미널, 연필은 커서.
- 다만 요새는 Markdown에 단어들만 나열해보거나 Mermaid도 그려보기도 하는 중.
- 이러니저러니 해도 Java는 좋은 언어. 다양한 이유로 Java를 싫어하는 사람을 생각보다 많이 봤지만, 그래도 Java를 메인으로 쓰는 조직을 들어가고 싶음.
- Java가 메모리를 많이 잡아먹는다는 지적은 JVM 최적화가 덜 된 것임. 물론 그래도 높긴 함.
- JVM 로딩 속도 문제는 Java 9에서 런타임 라이브러리 모듈화를 통해 개선되었음.
- GC를 탑재한 언어는 OS나 하드웨어 레벨을 위한 것이 아님. Go도 결국 C/C++의 대체제가 아니고 Java와 C#과 경쟁하고 있음.
- 예외 처리의 불편함은 Go의
if err != nil { ... }도 존재. 나는 Go의 에러를 확인하고 발생 시점에서 에러를 처리할 수 있다는 것은 좋다고 생각하지만, 이것도 Rust의 예외 처리가 낫다고 하는 사람도 있는 것을 보면 호불호를 타는 영역인듯.
- 결국. 프로젝트 매니징 능력이 가장 주된 것임은 변함이 없다.
- 프로그래밍 언어와 CS 지식은 그 능력을 위한 비료. 지속적으로 성장하기 위해 노력해야 한다.
- 제품은 가설의 조합, 엔지니어링의 핵심은 소통이다.
- 직군 간 정보 사일로 현상이 이러나는 것을 조직 내 누군가가 캐치하는 것이 필요.
- 빌드, 커밋 시점의 정적 분석은 프로젝트 초기에 넣어두면 문제 발견이나 코드 일관성 유지에 도움이 됨.