혼자 만들 때 기술을 고르는 기준

혼자 만들 때 가장 중요한 기준은 성능도 유행도 아닙니다. 6개월 뒤의 내가 고칠 수 있는가입니다.

세 가지만 봅니다

1. 내가 이미 아는가 — 배우면서 만들면 두 배로 걸립니다
2. 자료가 많은가 — 막혔을 때 검색으로 풀리는지
3. 혼자 배포할 수 있는가 — 인프라가 복잡하면 유지가 안 됩니다

복잡도를 늘리는 선택들

단순하게 시작해도 됩니다

초기 사용자 수에서는 서버 한 대와 데이터베이스 하나로 충분한 경우가 대부분입니다. 확장은 필요해진 뒤에 해도 늦지 않습니다.

미리 대비한 확장 구조가 실제로는 한 번도 안 쓰이는 경우가 훨씬 많습니다.

다만 이건 처음부터

• HTTPS — 나중에 붙이면 링크가 다 깨집니다
• 백업 — 사고는 항상 백업 없을 때 납니다
• 로그 — 없으면 원인을 못 찾습니다
• 에러 알림 — 사용자가 알려주기 전에 알아야 합니다

6개월 뒤의 내가 고칠 수 있는가

혼자 만드는 서비스는 매일 손대지 않습니다. 몇 달 방치했다가 급하게 고쳐야 하는 상황이 반드시 옵니다.

그때 코드를 열었는데 무슨 일을 하는지 모르겠다면 기술 선택이 틀린 것입니다. 성능이 아무리 좋아도 소용없습니다.

• 익숙한 언어 하나로 끝까지 가기
• 구조를 단순하게 — 파일을 열면 흐름이 보이게
• 추상화는 세 번 반복된 뒤에
• 주석은 왜를 남기기 (무엇은 코드가 말합니다)

선택이 만드는 장기 비용

관리형 서비스는 돈으로 시간을 사는 선택입니다. 혼자라면 대개 이쪽이 맞습니다. 데이터베이스를 직접 운영하는 데 드는 시간이 요금보다 비쌉니다.

처음부터 넣어야 하는 다섯 가지

1. HTTPS — 나중에 붙이면 링크·쿠키·리다이렉트가 다 꼬입니다
2. 환경변수 분리 — 키를 코드에 넣으면 반드시 사고가 납니다
3. 로그 — 없으면 원인을 못 찾습니다
4. 백업 — 사고는 백업 없을 때 납니다
5. 에러 알림 — 사용자가 알려주기 전에 알아야 합니다

데이터베이스는 특히 신중하게

코드는 다시 쓸 수 있지만 데이터는 못 되돌립니다. 그래서 데이터베이스 선택과 스키마 설계는 다른 것보다 신중해야 합니다.

• 관계형으로 시작하는 편이 대체로 안전합니다
• 삭제는 실제 삭제인지 미리 정하기
• 시간 정보는 UTC로 저장하고 표시할 때 변환
• 금액은 정수(원 단위)로 — 소수점 오차를 피합니다
• 마이그레이션 도구를 처음부터 쓰기

무엇을 직접 만들지 말아야 하나

직접 만들면 재미있지만 유지보수가 평생 따라옵니다. 핵심 가치가 아니라면 남의 것을 쓰는 편이 낫습니다.