[코드 냄새 #1] 스파게티 코드는 왜 스파게티일까
스파게티 코드가 가리키는 것은 길이나 지저분함이 아니라 제어 흐름입니다. 1968년 다익스트라의 goto 반대 편지에서 출발해 goto가 사라진 뒤에도 스파게티가 남은 이유와 순환 복잡도로 재는 법을 정리했습니다.
읽어보기DESIGN · 44 ARTICLES
Software Design
설계 원칙과 패턴을 외우지 않고 맥락과 선택 기준으로 이해합니다.
조기 최적화는 만악의 근원, 크누스가 진짜 하려던 말
"조기 최적화는 만악의 근원"이라는 크누스의 문장은 뒷부분이 잘린 인용입니다. 97%는 잊고 3%에 집중하라는 원문 맥락과, 프로파일러로 병목을 확인한 뒤 최적화하는 실무 기준을 정리했습니다.
읽어보기
코드 커버리지 100%의 함정, 몇 퍼센트가 적당할까
코드 커버리지 100%가 버그 없는 코드를 뜻하지는 않습니다. 실무에서 통용되는 70~80%대 기준과, 숫자보다 먼저 확인해야 할 미검증 분기를 골라내는 판단법을 정리했습니다.
읽어보기
레거시 코드에 테스트 붙이기, 리팩터링 전에 꼭 해야 할 일
레거시 코드는 리팩터링보다 현재 동작을 그대로 고정하는 특성화 테스트가 먼저입니다. 의존성 때문에 테스트가 붙지 않는 코드를 이음새로 끊어내는 순서까지 실전 절차로 정리했습니다.
읽어보기
DI·IoC·DIP 차이, 세 용어 한 번에 완벽 정리
DI·IoC·DIP는 층위가 다른 개념입니다. DIP는 무엇에 의존할지 정하는 원칙, IoC는 제어권을 누가 갖는지의 방향, DI는 의존성을 넣어주는 기법이라는 구분을 예제와 면접 답변까지 정리했습니다.
읽어보기
미디에이터 vs 옵저버 vs 퍼사드 완벽 비교, 객체 통신 패턴 3가지
미디에이터는 얽힌 객체 관계를 중앙에서 조정하고, 옵저버는 상태 변화를 일대다로 알리며, 퍼사드는 복잡한 내부를 단순한 창구로 감쌉니다. 세 패턴의 차이와 선택 기준을 Swift 예제로 비교했습니다.
읽어보기
팩토리 메서드(Factory Method) vs 추상 팩토리(Abstract Factory) 차이, 면접 단골 질문 한 번에 정리
디자인 패턴 공부하다 보면 꼭 한 번은 막히는 구간이 있어요.
읽어보기
OOP 다형성(Polymorphism) 완벽 정리, 오버라이딩부터 프로토콜까지 한 번에
OOP 다형성, 오버라이딩부터 프로토콜까지 한 번에 이해하려다 머리가 복잡해진 적 있으시죠?
읽어보기
[바이브 코더 #6] 어제는 됐는데 오늘 안 돼요, 코드 안 건드렸는데 왜 그럴까
"코드를 한 줄도 안 건드렸는데, 어제까지 잘 되던 앱이 오늘 안 돼요." 바이브 코딩 커뮤니티에서 가장 자주 보이는 하소연이고, 가장 미스터리처럼 느껴지는 상황입니다. 귀신이 곡할 노릇 같지만, 사실 이 사건의 용의자는 몇 명으로 정해져 있습니다. 순서대로 조사하면 대부분 오전…
읽어보기
어댑터 vs 퍼사드 vs 프록시 vs 데코레이터(Adapter·Facade·Proxy·Decorator), 래핑 패턴 4형제 완벽 구분법
디자인 패턴 공부하다 보면 꼭 벽에 부딪히는 지점이 있어요.
읽어보기
[바이브 코더 #4] 배포가 뭐길래, 내 컴퓨터에선 되던 앱이 인터넷에선 안 될까
앱이 완성됐습니다. 내 컴퓨터에서는 완벽하게 돌아갑니다. 친구에게 자랑하려고 주소창의 localhost:3000을 복사해서 보냈더니, 친구는 "안 열리는데?"라고 답합니다. 큰맘 먹고 배포라는 걸 했더니, 이번에는 내 컴퓨터에서 멀쩡하던 앱이 인터넷에서는 에러를 뿜습니다.
읽어보기
[바이브 코더 #2] API가 뭐길래, API 키는 왜 숨기라는 걸까
지난 1편에서 앱을 식당에 비유했습니다. 홀(프론트엔드), 주방(백엔드), 창고(DB). 이번에는 그 구조 위에서 바이브 코딩 사고가 가장 잦은 주제를 다룹니다. API, 그리고 API 키입니다. "키를 절대 노출하지 마세요"라는 경고는 다들 한 번쯤 봤을 텐데, 정작 그 키가…
읽어보기
Single Source of Truth, 같은 정보를 두 곳에 두면 반드시 어긋난다
배포 직전에 발견되는 버그 중에는 유형이 정해져 있는 것들이 있습니다. 프론트엔드는 할인율을 10%로 계산했는데 백엔드는 15%로 계산한다든가, 문서에는 필수라고 적힌 필드가 실제 API에서는 사라져 있다든가. 코드 자체는 둘 다 멀쩡합니다. 문제는 같은 정보가 두 곳에…
읽어보기
라이브러리 vs 프레임워크, 기준은 '누가 누구를 호출하나' (제어의 역전)
Alamofire는 라이브러리라고 부르고, SwiftUI는 프레임워크라고 부릅니다. 근데 둘 다 "남이 만든 코드를 가져다 쓰는 것" 아닌가요? 뭐가 다른 걸까요.
읽어보기
[모듈화 #1] 모듈화란 무엇일까? 코드를 나누는 진짜 이유 (응집도·결합도 총정리)
프로젝트가 커질수록 파일 하나 고치는 게 점점 무서워집니다. 어디까지 영향이 퍼지는지 가늠이 안 되니까요.
읽어보기
[모듈화 #3] Common 모듈이 쓰레기통이 되는 이유 (모듈 레이어 설계 총정리)
모듈화를 진행하는 팀 대부분이 어느 시점에 Common, Core, Utils 같은 이름의 모듈을 만듭니다.
읽어보기
의존성 주입(DI)이란? new를 클래스 밖으로 꺼내는 것부터 (예제·비유 총정리)
코드 안에서 필요한 객체가 있으면 그 자리에서 바로 생성해 쓰는 경우가 많아요. 그런데 테스트 코드를 짜려는 순간 벽에 부딪힙니다. 클래스 안에 콕 박힌 생성 코드 때문에 도무지 갈아끼울 수가 없거든요.
읽어보기
macOS 터미널 앱 6종 비교, iTerm2·Ghostty·Warp 뭘 써야 할까
맥을 쓰는 개발자라면 하루에 가장 오래 띄워놓는 앱이 아마 터미널일 거예요. 그런데 의외로 기본 터미널만 몇 년째 쓰는 분들이 많더라고요.
읽어보기
테스트 코드 왜 짜야 할까? 귀찮은데도 짜는 진짜 이유 (실무 정리)
"이거 언제 다 짜고 있어..." 기능 하나 만드는 데도 시간이 빠듯한데, 테스트 코드까지 짜라고 하면 솔직히 한숨부터 나옵니다.
읽어보기
[SOLID #2] SOLID 원칙 실무편 (하) ISP·DIP, 의존성 주입이 존재하는 이유
지난 편에서 SOLID의 앞 세 글자, SRP·OCP·LSP를 다뤘는데요. 오늘은 나머지 두 글자를 마저 정리합니다.
읽어보기
컴포지션(Composition) vs 상속(Inheritance), "상속 쓰지 말라"는 말의 진짜 의미
객체지향을 공부하다 보면 꼭 만나는 문장이 있어요. "상속보다 컴포지션을 써라(Favor composition over inheritance)."
읽어보기
[SOLID #1] SOLID 다섯 글자, 외우지 말고 이해하기 (SRP·OCP·LSP)
면접에서 "SOLID 원칙 설명해보세요"라는 질문, 다들 한 번쯤 받아보셨을 거예요.
읽어보기
코더 vs 소프트웨어 엔지니어, 진짜 뭐가 다를까? (연봉·역할 총정리)
개발 공부를 하다 보면 이런 궁금증이 한 번쯤 생깁니다. "나는 코더인가, 소프트웨어 엔지니어인가?"
읽어보기