주니어 시절 맹신했지만 실무에서 깨진 "베스트 프랙티스"들.txt

실무에서 5년간 굴러보니 깨달음. 블로그에선 완벽해 보이는 "베스트 프랙티스"들도 마감, 스케일, 사람 앞에선 무용지물일 때가 많음.

내 생각을 바꿔놓은 몇 가지 사례임.

1. 컴포넌트는 무조건 작게?

이론상으론 맞음. 근데 실무에서 과도하게 쪼개면 오히려 디버깅이랑 온보딩(인수인계)만 헬이 됨. 아무도 이해 못 하는 파일 12개보다, 술술 읽히는 300줄짜리 컴포넌트 하나가 훨씬 나음.

2. 테스트 코드는 다다익선?

테스트 중요함. 근데 커버리지(%)보다 '뭘' 검증하는지가 핵심임. 설익은 테스트 코드는 팀 발목만 잡는 걸 많이 봄. 자잘한 것보다 핵심 로직(Critical Path) 검증이 최우선임.

3. 싹 갈아엎고 새로 짜기(Rewrite)?

개발자 뽕은 채워주지만 비즈니스적으론 위험한 도박임. 내가 본 성공적인 시스템을 지킨 건 언제나 '점진적인 리팩토링'이었음.

4. 프레임워크 선택이 성공의 열쇠?

React냐 Vue냐, 요즘 뜨는 기술이냐 안 중요함. 진짜 성공을 가르는 건 팀 얼라인먼트(Alignment), 코드 오너십, 그리고 리뷰 문화임.

베스트 프랙티스가 쓸모없다는 게 아님. 그냥 언제나 규칙보다 맥락(Context)이 우선이라는 거임.

님들은 초년생 땐 종교처럼 믿었는데 지금은 생각 바뀐 거 뭐 있음?

• DRY는 진짜 위험할 수 있음. 코드 재사용하겠답시고 너무 멀리 가서 엉망진창인 추상화를 만드는 사람들이 너무 많음. 코드 재사용이 좋긴 한데 그게 전부는 아님.

  • DRY(Don't Repeat Yourself)하기 전에 WET해야 함. WET: Write Everything Twice(모든 걸 두 번 써라). 세 번째 볼 때 추상화하는 거임.

    • 3의 법칙이지.

    • ㄴㄴ 두 번 필요하자마자 재사용해야 할 것도 많음(다 그런 건 아니지만). 님 댓글은 추상화가 복잡한 케이스에만 적용해야 하는데, 초보자들이 문자 그대로 받아들이고 아무 데나 적용할까 봐 위험함. 결국 진짜 규칙은 '논리적으로 같은 건 한 번만, 겉보기에만 같고 논리적으로 다른 건 따로' 작성해야 한다는 거임.

  • 근데 세 번째 상황이 한참 뒤에 생기면 어쩔? 그때 되면 님이나 동료들이 앞의 두 번을 기억 못 할 텐데? 세 번째를 어떻게 놓치지 않고 잡을 거임?

  • 설령 두 번째 상황에서 미리 추상화했다 쳐도, 그 추상화가 명확하고 문서화 잘 안 되어 있으면 또 다시 구현하게 될 위험이 있음.

  • 게다가 두 가지 케이스에만 맞춰 추상화해놔서 과적합(Overfitted)됐을 확률이 높음. 세 번째 케이스 오면 대공사해야 할걸.

  • 아니면 좀 더 실용적으로 생각하셈. 그 코드 덩어리에 이름을 붙일 수 있으면, 추상화해도 되는 거임.

  • ㅇㅇ, 어떤 사람들은 코드 몇 줄 비슷하게 생겼다고 걍 맹목적으로 DRY 적용함.

  • 두 군데에 비슷한 코드 3줄 있어서 함수로 뺐는데, 그 함수 결과값 확인하느라 호출하고 체크하는 코드 3줄 다시 생기는 거 볼 때가 제일 웃김.

  • 내가 제일 좋아하는 건 비슷한 코드 블록이라고 합쳐놨는데, 제대로 작동시키려면 파라미터 12개 넘겨야 하는 경우임. 그냥 뒀으면 정보 두 개만 있으면 됐을 텐데.

  • Utility-CSS 같은 타입 정의 본 적 있음(농담임. 나 유틸리티 CSS 좋아함). Foo, Bar 같은 이름만 비슷하고 의미는 완전 다른 속성들을 가진 타입 A, B가 있는데, 이걸 억지로 extends HasFoo, HasBar 이런 식으로 추상화해버림.

  • 이런 거 오버엔지니어링 하는 거 보면 미치겠음. 뭐 디버깅하려고 보면 30개가 넘는 한 줄짜리 함수들이 여기저기 흩어져 있고 딱 한 번씩만 쓰임. 보통 한 번만 쓰이고 말 것들이라, 실제로 두 번 이상 필요할 때까지는 DRY 생각도 하지 말라는 거임.

  • DRY는 소프트웨어 엔지니어들에게 주어진 조언 중 제일 암적인 존재임. 그냥 복붙하고 두 컴포넌트 각각 수정하는 게 더 빠르면, 무조건 복붙해야 함.

  • 이거임. 여러 구체적인 컴포넌트를 하나로 합쳐서 '모든 걸 다 하는' 컴포넌트 만드는 거 너무 많이 봄. 그럼 그 컴포넌트는 거대한 조건문 덩어리가 됨. 가능한 상태 값이 기하급수적으로 늘어나서 뭐가 가능하고 불가능한지 아무도 모르게 됨.

  • DRY의 반대도 똑같이 위험함. 내가 본 사람들은 '최소 2~3번은 나와야 DRY 적용한다'는 규칙 때문에 뻔한 공통 코드 호출조차 거부하더라. 로직이 포함된 코드 블록을 그냥 복붙해버림. 추상화 없이 리팩토링만 한 번 해두면 훨씬 간단했을 텐데.

  • 비슷하지만 미묘하게 다른 2~3가지 시나리오를 처리하려고 추상화 로직을 짜야 하는 경우도 있음. 그럴 땐 차라리 코드 복사하는 게 읽기도 좋고 유지보수하기도 쉬움. 결론: 상황에 맞지도 않는 도그마(교리) 따르지 말고 상식적으로 하셈.

  • 가끔은 공통 코드를 호출하기 위해 거창한 추상화가 필요 없는 경우도 있음. 그냥 정적 공통 코드 대충 어딘가에 던져놓는 구린 방식이라도 작동은 함. 근데 로직이 들어있는 코드를 복붙하는 건 진짜 끔찍함. 다른 코드처럼 유지보수해야 하니까. 결론: 상황에 안 맞는 도그마에 집착하지 말고 상식 좀 쓰라고.

  • 반대 경우도 끔찍함. 내가 일하는 곳은 오래된 PHP 코드베이스인데 DRY가 전혀 안 되어 있어서 아무도 고칠 수 없는 버그 지옥임.

  • 예전에 일했던 PHP 회사는 HTML을 구성하려고 클래스랑 메서드를 만들었음. component->opendiv() 같은 식이었는데... 잘못된 곳에 과도하게 DRY를 적용한 사례임.

• 300줄짜리 컴포넌트는 큰 게 아님. 5000줄 정도는 돼야 큰 거지. 사람들이 컴포넌트 너무 크다고 말릴 땐 그런 걸 말하는 거임.

• 컴포넌트는 항상 작게 유지하라: 300줄은 여전히 작음! 피해야 할 건 3000줄짜리 괴물인데, 생각보다 흔하다는 게 문제임.

• 진짜 뭐 하냐에 따라 다름. 웹 개발에선 큰 거지만, 복잡한 API 임포터라면? 300줄은 정상임. 물론 메서드를 잘게 쪼갤 순 있겠지. 근데 깊이 들어갈 때마다 클릭해야 되면 탐색만 힘들어지고, 큰 그림은 놓치고 간접 참조(indirection)만 늘어남. 가끔은 피할 수 없지만, 간접 참조야말로 현대 개발에서 생산성 잡아먹는 주범임.

  • ㅇㅇ, 입력/출력이 명확하고 이름 짓기 쉬운 덩어리라면 메서드로 나누는 게 말이 됨. 아니면 각 덩어리를 테스트하고 싶을 때라던가. 그게 아니라 한 곳에서만 호출되는데 굳이 메서드로 만들 이유는 없음.

• ABC 메트릭한테 그거 좀 설명해봐라. 린터(Linter)에 맹목적으로 따르다간 우리 다 죽음. 내 말 명심하셈.

• 꼭 크기만의 문제는 아님. 큰 컴포넌트들이 문제인 건 보통 구조가 엉망이라서 그런 거임. 예를 들어 컴포넌트 안에서 날것의 API 요청 보내고 비즈니스 로직 처리하고 난리 치는 경우들.

• 초창기엔 뭐든 다 추상화해버리는 나쁜 버릇이 있었음. 처음엔 좋아 보이는데 나중엔 진짜 감당 안 되게 지저분해짐. 지금은 읽기 쉬운 단순한 코드를 짜고, 진짜 필요할 때만 추상화함.

• 너무 일찍 추상화하는 걸 조심하는 게 내가 배운 가장 큰 교훈 중 하나임. 설익은 추상화의 고통이 컴포넌트가 너무 큰 고통보다 훨씬 큼.

• 난 규칙 하나 있음. 뭐 추상화해야겠다 싶으면 내 머리 한 대 때림. 그러면 좀 진정됨.

• 이게 정답임. DRY는 이론상으론 좋은데, 거의 모든 프로그래머가 결국엔 이 결론에 도달하는 것 같음. 의심 가면 Kent C. Dodds의 'AHA 프로그래밍'이라는 블로그 글 읽어보셈. 진짜 명글임.

• ㅇㅇ.. 그거 진짜 명언이지.

• 모든 코드를 재사용할 필요는 없음. 꼬인 로직 가진 프랑켄슈타인 괴물 하나 만드느니, 코드 중복 좀 있더라도 비슷한 컴포넌트 두 개 만드는 게 나음. 제발 모든 곳에 OOP(객체지향) 억지로 끼워 맞추지 마셈. 보통은 구성(Composition)을 활용한 단순 절차적 코드가 훨씬 나음. 복잡하게 만들지 마!

  • OOP 이제 한물간 거 아님? 요즘은 함수형 프로그래밍, 불변성(Immutability), 부분 적용(Partial Application) 이런 거 하는 시대 아니었음?

  • 기술이나 도메인에 따라 다르겠지. 근데 님 리스트 중에 불변성은 대부분의 경우에 확실히 좋음.

  • 상속(Inheritance)이 한물가고 구성(Composition)이 뜬 거지. 구성은 OOP에도 적용됨.

• 내 경험상 경영진이 '어제까지 만들어내'라고 하면 모든 모범 사례는 창문 밖으로 던져짐. 😬

  • 전적으로 동감함.

  • 전적으로 동의 못 함. 제대로 하는 게 제일 빠른 길임.

• 난 이제 라이브러리 잔뜩 만들거나 너무 일반화하려는 유혹을 참음. 새 프로젝트 시작할 때쯤 되면 예전 코드는 호환도 안 되고 그냥 갖다 쓸 수가 없더라.

• 지금 타입스크립트 프로젝트 하나 하는데, 파편화 끝판왕이라 함수 하나당 파일 하나씩 있음. 이론상으론 그럴듯한데, 실제 함수 소스 찾으러 가는 게 너무 번거로움. 거기다 타입만 export하고 소스 보려면 레포 받아서 수동으로 뒤져야 하는 패키지까지 겹치면...

  • 정책(Policy) - 처리(Handling) - 런타임(Runtime) | 앞의 두 개는 테스트하고, 마지막 건 로그 남기고 테스트하셈.

    • 오 꿀팁이네.

• 또 5년, 10년, 15년 지나봐라. 베스트 프랙티스는 또 바뀜. 오늘 유행하고 진보적이라던 게 내일은 레거시고 안티 패턴 됨. 이거 놀라울 정도로 규칙적으로 일어남. 내 초창기 베스트 프랙티스? 스택 공간 아껴라. 재사용할 수 있으면 하고, CPU 사이클 낭비하지 마라. 확실히 돌아갈 때까지 컴파일 돌리지 마라. 종이에 다 짜기 전까진 터미널 앞에 앉지도 마라. 스카치테이프는 새거여야 하고... 뭐 이런 거. 절반은 지금 말도 안 되는 소리임. 스카치테이프가 뭔 상관임. 근데 딱 하나, 지금도 기꺼이 따르고 싶은, 아니 다들 따랐으면 하는 건 있음: 문서화 먼저(Documentation first).

  • 문서화 먼저. Knuth의 문학적 프로그래밍(Literate Programming)이 부활해야 함. 수십 년 전 코드라도 그런 스타일로 짜인 건 언어 몰라도 뭘 하는지, 왜 하는지, 어떻게 하는지 다 보임. 문서화 잘 된 코드 놔두고 '자체 문서화 코드(Self-documenting code)' 보면서 그게 끔찍한 혼종이 아니라고 주장하는 건 이해가 안 감.

  • 자체 문서화 코드의 핵심은 함수랑 변수 이름 잘 짓고 적당히 쪼개서, 주석 없이도 흐름 따라가기 쉽게 만드는 거임. 주석은 뻔하지 않은 것, '왜' 그렇게 했는지, 특이한 부분에만 다는 거임. 상상의 초보자를 위해 일일이 설명하는 건 시간 낭비고, 주석 업데이트 유지보수 비용만 늘어남. 피할 수 없는 난해한 부분에만 주석 다는 게 맞음.

  • 자체 문서화 코드 좋아하는 사람들은 비판받으면 꼭 방어하려 드는데, 그 자체가 뭔가 잘못됐다는 신호 아님? 모호한 의도가 드러날 때 문제가 터짐('왜' 같은 거). 이런 모호함 때문에 도메인 지식 없으면 코드가 이해 안 됨... 전혀 '자체 문서화'가 아님. 예를 들어 변수명은 기막힌데, 그 뒤에 숨겨진 결정이나 비즈니스 이유는 안 보임. 구조 잡기엔 좋지만 소통엔 별로라 문서화가 필요한 거임. 물론 문학적 프로그래밍도 너무 장황하고 유지보수 비용 비싸다는 단점은 인정함. 이건 주석 문제가 아니라 TDD 같은 설계 방법론에 가까움. 코드 레벨보다 인간 레벨의 사고를 하는 거지. 경험 많은 개발자들은 하이브리드로 감. 핵심 맥락이랑 의도는 문서/주석으로 남기고, 나머지는 간결하게. 난 문학적 스타일 코드베이스에서 일해봐서 그 트레이드오프 받아들임.

    • '자체 문서화 코드 좋아하는 사람들은 방어하려 든다 = 뭔가 잘못됐다'는 논리는 좀 이상함. '안전벨트 매는 사람들은 비판받으면 방어하려 든다 = 안전벨트에 문제 있다'랑 뭐가 다름? 이상하잖음? 자체 문서화가 주석을 아예 안 쓴다는 게 아님. 피한다는 거지. 독자가 언어랑 변수명 읽을 줄 안다고 가정하는 거임. '어떻게'보다 '왜'를 전달하는 게 훨씬 중요함. 구현 설명하는 주석은 보통 잡음이거나 읽기 힘든 코드에 붙이는 반창고일 뿐임. 그리고 주석은 거짓말을 자주 함. 코드가 진짜 설명이지, 주변 영어가 아님.

  • 결국 그렇게 될 거임. LLM 기반 소프트웨어가 제대로 돌아가게 하려면 그게 '유일한' 방법임. 중요한 시점에 맥락을 주입해 주는 거니까. AI가 처음에 못 알아먹어도 추가 맥락 있으면 알아서 고침.

  • 문서화 모범 사례 따르던 회사들이 LLM 시대에 제일 이득 본다면 좀 아이러니할 듯. 어느 정도 맞말인데, 제한된 용도 외에는 LLM이 '제대로' 작동할 거라곤 안 믿음. 문서화 잘 된 코드는 컨텍스트 윈도우 한계에 더 빨리 부딪힘. LLM 무시하는 건 아니고 유용하긴 한데, 과대포장된 잠재력만큼은 못 할 거라 봄.

  • 내 LLM은 문서 업데이트 안 하고 코드만 수정하던데. 사람처럼.

• 내 웹 앱(Blazor)에서 초기 다운로드 줄이려고 지연 로딩(Lazy loading)을 너무 빡세게 적용했었음. 몇백 kb 줄여서 뿌듯하긴 했는데, 다른 사람이 내 코드 건드리면 지연 로딩된 서비스 때문에 여기저기서 걸려 넘어질 게 뻔함. 전형적인 '조기 최적화' 삽질이었음. 지연 로딩 다 없앨까 생각 중. 사이트 로딩 속도 지표는 요즘 좀 화물 숭배(Cargo cult) 같음. SEO는 몇 밀리초 빨라지는 것보다 훨씬 많은 요소에 달려있는데.

• 베스트 프랙티스는 아니지만 내 커리어 초반에 도움 됐던 마인드셋: '완벽한 것보다 완료된 게 낫다(Done is better than perfect).' 예전엔 작동하는 거 만들기도 전에 최고의 해결책 찾느라 꽉 막혀 있었는데, 이젠 일단 돌아가게 만들고 나서 최적화함.

• 맞말임! 나도 맥락이 진짜 중요하다는 걸 느낌. 처음엔 모든 컴포넌트 작게 만들고 모든 줄 테스트하려고 했는데, 실제 프로덕션에선 읽기 쉽고 약간 큰 컴포넌트에 집중된 테스트가 더 유용하더라. 팀 얼라인먼트랑 코드 오너십이 리라이트나 프레임워크 논쟁보다 훨씬 영향력 큼.

• '베스트 프랙티스'는 보통 상황에 따라 다름. 20명이 거대 엔터프라이즈 코드 유지보수할 때 중요한 게, 혼자서 작은 CRUD 앱 20개 관리하는 개발자한텐 쓸데없는 짐일 뿐임. 난 후자로 20년 일해서, 블로그에 글 쓰는 FAANG 애들이랑은 베스트 프랙티스에 대한 생각이 아주 다름. 인플루언서들이 'X 도구 써야 함! 아참 Y 도구! X는 작년 거임!' 하고 떠들어도, 본인 시나리오 가성비 따져서 판단해야 함.

• 4번 포인트(팀 정렬, 코드 오너십, 리뷰) 진짜 공감함. 기술 부채나 유사한 관행에 대해 서로 책임지게 하면, 몇 달 동안 안 본 코드에 버그 잡거나 새 기능 넣을 때 진짜 편함. 비즈니스 로직 무거운 대형 앱에선 '모듈'을 작은 우주처럼 나누는 게 베스트 프랙티스더라. 추상화는 그 작은 세계 안에서만 함. 전역 버튼 같은 건 공유하지만, 판매 문서 관리 쪽 가격 정책 컴포넌트를 다른 데서 재사용 안 함. 모든 걸 재사용하려고 안 함. 비슷한 로직이 똑같은 로직은 아니니까. 제일 중요한 건 합의된 코딩 컨벤션(네이밍 포함) 따르는 거임. 내가 짠 기능 아니어도 어디에 뭐 있는지 바로 알 수 있음. 모든 앱에 일관성 유지하니까 팀원들이 다른 앱 작업하기도 편함.

• '컴포넌트 작게 유지해라'는 말 그대로 받아들이면 오해하기 쉬움. 진짜 의미는 '단일 목적을 갖게 해라'임. 보통은 작아지지만 항상 그런 건 아님. 리팩토링이 핵심임. 청소랑 똑같음. 바닥에 양말 떨어져 있을 때마다 빨래바구니에 넣는 습관 있으면 집 깨끗하게 유지하기 쉬움. 근데 쌓이게 놔두면 집은 항상 더럽고 치우는 데 시간만 오래 걸림.

• 프레임워크 전쟁은 그냥 인터넷 드라마임. 걍 프레임워크 특징이랑 사용 사례 배우고, 프로젝트에 적합하고 팀이 편한 거 쓰면 됨.

• 관심사의 분리(Separation of concerns). 틀린 말은 아닌데, 주니어들이나 꽉 막힌 사람들은 종종 잘못 이해함. 난 '강아지를 닭처럼 부위별로 자르지 마라, 부위가 아니라 품종별로 나눠라'라고 함. 캐시를 데이터베이스로 만들거나 전혀 관계없는 두 시스템 합쳐서 버그 유발하는 커플링 만드는 거 많이 봄. 관심사가 아니라 명사(Noun)로 분리하셈. 그리고 DRY 관련해서, 나중에 코드 바뀔 것 같거나 유틸리티 호출이 부적절해 보이면 난 그냥 중복해서 씀. 부적절한 커플링 막아주니까. 가끔 패턴 두 번 나왔다고 바로 DRY 적용하는데, 최소 3~4번은 돼야 함. 그리고 TDD는 매니저 있으면 안 먹힘. 걔네는 불 끄는 시도 따위 이해 못 하고, 그냥 소화기랑 소화기 제조 기계만 팔고 싶어 함. 사무실에 불나는 꼴을 못 봄. 브랜치 파고, 테스트 짜고, 저장할 때마다 자동화 툴이 감지해서 코드 완성될 때까지 알림 테러당함. 괴롭힘 수준임. 차라리 똥 같은 코드 짜서 배포하고 망가지면 '아 다시 해봄' 하는 게 감정적으로 더 편함. 테스트 코드로 단단하게 만드는 게 낫긴 한데... 그리고 YAGNI(You Aren't Gonna Need It)? 아니... 필요할 거임. 기획 회의 때 딴짓 안 했으면 PM이 필요할 거라고 말한 거 들었겠지. 회의 때 데이터 흐름 질문만 잘해도 프로젝트 기간 몇 달은 줄임. 작은 클래스? 복잡한 객체 다룰 땐 개소리임. DB에서 데이터 퍼 오는 POJO만 있는 게 아님. 함수형으로 억지로 할 순 있는데, C# 같은 데서 그러면 문맥 하나도 없는 파일 열었을 때 읽기 힘듦. 크기는 복잡도에 따라 다른 거임. 일단 큰 클래스 만들고 그 안에서 발견되는 작은 걸 캡슐화하는 게 계획하는 것보다 나음.

• 다시 짜기(Rewrites)는 처음부터 잘 만들면 피할 수 있음. 변수명 잘 짓고, 일반화 잘하고, 주석 잘 달고, 수정하기 쉽게 만들면 됨. 그럼 처음 개발할 때 수정하니까 나중에 다시 짤 필요 없음. 문제는 회사에서 빨리 내놓으라고 닦달해서 제대로 코딩 못 하게 하는 거임. 아직 학교 과제나 개인 프로젝트만 해봐서 확실친 않음. 웹 개발자가 아니라 컴공과 학생이라 다를 수도 있고.

• 난 여전히 300줄이면 100~200줄짜리 2개로 깔끔하게 나눌 수 있다고 믿음. 그래도 예전보단 '작은 컴포넌트'에서 '로컬리티(Locality)' 챙기는 쪽으로 바뀌긴 했음.

• Em dash(—) 다시 쓴다고 AI 똥글이 아닌 게 되는 건 아님.

• '컴포넌트 작게 유지하기'에 대해. 맹목적으로 따르면 코드 파편화 심해짐. 근데 반대도 문제임. '쪼개기엔 너무 작다'면서 모든 걸 메서드 하나에 때려 박는 것도 나쁨.

• 이론상으론 맞지. 실무에선 과도한 파편화가 디버깅이랑 온보딩 더 어렵게 만듦. 아무도 이해 못 하는 파일 12개보다 읽기 쉬운 300줄 컴포넌트가 나음. 근데 이건 프레임워크 따라 다름. Angular는 컴포넌트 하나가 파일 3개 이상(HTML, CSS, TS)이라 너무 쪼개면 가독성 해침. 코드 15줄짜리 파일 들어있는 폴더 뒤지는 거 아무도 안 좋아함. React는 함수 하나로도 되니까, 메인 컴포넌트랑 헬퍼 컴포넌트들을 한 파일에 몰아넣는 경우 많음. 다른 코드베이스에서 React 컴포넌트 엄청 길고 중첩된 거 보면 좀 별로임. React는 쪼개기 쉬우니까 쪼개는 게 나음. 물론 React도 과하면 안 좋지만, 일반적으로 Angular보단 더 쪼개야 함.

• 목표가 목표가 되어야지, 도구나 규칙이 목표가 되면 안 됨. 가독성을 원해서 작은 파일이 도움이 되면 쓰는 거임. 작은 파일 자체가 목표는 아님. 커버리지, 리팩토링, 프레임워크 다 마찬가지.

• 테스트 커버리지 %보다 무엇을 테스트하느냐가 중요함. 여기에 덧붙이자면, 특정 동작을 테스트해야 하는지, 아니면 라이브러리 유지보수자가 할 일인지 물어봐야 함. 흑백 논리는 아니지만, 내 애플리케이션의 동작에 집중하는 게 시간 아끼고 테스트 비대해지는 거 막아줌. Next 프로젝트 예로 들면, showFoo props 있으면 화면에 나온다는 테스트 같은 거. 이런 거 실제로 봤는데, 커버리지 숫자는 올려주지만 가치가 있나? 우리 앱 코드가 아니라 React 코드가 잘 도는지 테스트하는 꼴임. 그건 우리 책임 아님. React 렌더러가 고장 나면 애초에 빌드도 안 될 거고 CI에서 걸러짐. 물론 예외는 있겠지만, React가 고장 날까 봐 테스트하는 건 아니라고 봄.

• 여기에 하나 더, 잘 언급 안 되는 베스트 프랙티스는 '최대한 빨리 피드백 받기'임. 이슈 빨리 잡고 사람들한테 알리는 게 프로젝트에서 큰 역할 함. 사용자 피드백이 진짜 도움 많이 됨.

• 기능이 있다고 꼭 써야 하는 건 아님. 그냥 데이터 필드 몇 개랑 함수 몇 개 있는 단순한 클래스(Basic bitch class) 짜도 됨. 다중 상속, 구성, 의존성 주입, 클로저, 람다, 제네릭, 리플렉션... 안 써도 됨. 못 박을 땐 망치만 있으면 됨.

• 테스트는 가치 있지만 커버리지 %보다 뭘 테스트하느냐가 중요함. 격하게 동의함.

• 난 이제 규칙 딱 두 개임. 이해하기 쉬운가? 변경하기 쉬운가? 유지보수에 문제 생길 때까지 한 파일에 다 때려 넣음. 500줄이라도 유지보수 쉬우면 문제없음. 문제 터지기도 전에 파일 정리하고 깔끔하게 만드는 데 집착하는 엔지니어 너무 많음. 테스트도 짜기 쉽고 이해하기 쉽고 바꾸기 쉬워야 함. 아니면 안 씀. 테스트는 멍청할 정도로 단순하고 추가하기 쉬워야 함. 테스트가 본 코드보다 복잡해서 5분 동안 들여다보고 있으면 안 됨.

• '개발 시작 전에 디자인은 픽셀 퍼펙트해야 한다.' 커리어 초반엔 핸드오프 하면 끝인 줄 알았음. 근데 최고의 프로덕트는 디자인을 살아있는 대화로 취급함. 피그마에선 완벽해도 실제 데이터 넣고 엣지 케이스 만나면 수정해야 함. 이제 초기 디자인은 스펙이 아니라 가설로 취급함. 비슷하게 내놓고 테스트하고 반복함. 처음에 완벽하려고 드는 비용이 수정 비용보다 비쌈. '디자인 시스템 정확히 따르세요'도 마찬가지. 디자인 시스템은 감옥이 아니라 시작점임. 시스템이 16px 패딩 쓰라는데 콘텐츠가 20px 필요하면 20px 쓰는 거임. 일관성 중요하지만 사용성보다 중요하진 않음. 문맥이 규칙을 이긴다. 딱 맞는 말임.

• 난 '무슨 수를 써서라도 DRY'였음. 특히 UI 코드에서. 예전엔 중복 피하려고 모든 걸 거대하고 일반적인 BaseWhatever로 뽑아냈는데, 1년 뒤에 수정할 때마다 지뢰밭이었음. 요즘은 의도가 명확하고 온보딩이나 리팩토링 덜 고통스럽다면, 약간 중복된 컴포넌트 두 개 있어도 행복함.

• 최고의 도구나 프로세스도 썩은 문화를 이길 순 없음. 좋은 회사 문화는 쓰레기 도구 써도 길을 찾아냄. 여기서 리더십이랑 매니지먼트 차이가 드러남. 매니저는 고양이 몰기 힘들다고 불평하고, 리더는 안 그럼.

• 동의함. 약타입 언어에선 통합 테스트가 단위 테스트보다 더 중요하게 느껴짐. 강타입은 반대고. 함수 목적은 라이프사이클 동안 변할 수 있고, 2025년에 그렇게 결합도 낮은(decoupled) 코드베이스는 보기 힘듦.

• 프레임워크 선택이 성공을 결정한다? 언제부터 이게 베스트 프랙티스였음?

• 1번 진짜 뼈 때리네. 간단한 20줄짜리 메서드면 될 걸 12개 파일로 추상화해놔서 디버깅도 못 하고 읽지도 못하게 해놓은 거 극혐함. 학문적으로는 맞을지 몰라도 수확 체감의 법칙이 적용되는 지점이 분명히 있음.

from reddit

주니어 시절 맹신했지만 실무에서 깨진 "베스트 프랙티스"들이 있나요?!