염산하

@purengom 여하간 사람들이 카톡을 어떻게 쓰는지 카톡만 몰랐던 것인가... 싶고요

@purengom 카톡은 AI 때문이라기엔... ㅎㅎ

맥북 에어에서 제일 마음 드는 포트를 하나 꼽으라고 하면 3.5mm 헤드폰 포트 라고 대답할까봐요. 정말 괜찮네요.

@me 사람이 어느 정도 간단히 상상할 수 있는 것들의 관계에서는 뉴턴 방식으로 생각하는 게 사실 더 직관적이긴 하죠 사과가 길을 따라가다니 뭔 소린가 싶고 ㅎㅎㅎ

궤도가 이동진의 파이아키아 채널에 나와서 인터스텔라 영화에 대해 이야기하는 영상을 봤다. 거기서

광자는 질량이 없는 것으로 여겨진다. 그런데 블랙홀은 빛도 탈출할 수 없는 곳이다. 뉴턴의 법칙에 따르면 광자가 질량이 없다면 중력과 상호작용하지 않을 것이다. 그래서 블랙홀이 있다고 해도 빛에 영향을 주지 않을 것이다. 중력이 시공간의 형태에 의해서 나타나는 현상이라고 해야 블랙홀로 빛이 끌려가는 현상이 설명 가능하다.

라는 취지로 설명하는 것을 들었는데, 이런 식의 설명은 처음 들어봤다. 오호...

@me 저도 이번에 깜짝 놀랐지 뭡니까...

종립님이 인상적이라고 하신 리스크 테이커를 읽기 시작했다. 이 사람이 네이트 실버구나... #독서

공부는 스스로, 하고 싶은 것을 배우고 익히는 것. 지식보다 사고력. 대학교육 자체는 통계적으로 유의미한 사고력 증진을 끌어내지 못했다.

공부의 재발견. 최근의 학습과학의 성과를 알리고 교육이 아닌 “공부”에 집중하고자 함, 이라고 서문에서 이야기하는 책. 마인드스케일 좋아하는데 요 책도 그래서 좋았다. 흠? 혹시 이 교수님도 유튜브 하시려나?

@me 저 그거 알아요 F1 피트 스탑!

@me 둘 다를 골라야 합니다 저는.

아니 사람들이 이렇게나 카톡 프로필에 사진을 많이 올렸었나? 인스타랑 다를 바가 없었네...

연구 결과 학습 방법과 무관하게 질문을 목표로 삼은 집단이 더 많은 수의 좋은 질문을 만들어 냈습니다. 더 놀라운 점은 질문 집단이 이해 집단(내용 이해를 목표로 삼은 집단)보다 학습 내용을 더 잘 이해했다는 겁니다. 책을 읽거나 강의를 들을 때 질문하는 행위 자체에 초점을 두어 보세요. 그 과정에서 이해는 절로 따라올 겁니다.

글의 내용에 동의하는지, 글의 느낌은 어떤지, 글의 장점과 단점은 무엇인지 분석하는 것도 반성적 읽기의 일환입니다. 이를 통해 우리는 글을 다각적으로 이해하거나 겉으로는 드러나지 않던 새로운 의미를 찾아낼 수 있습니다. 반성적 읽기 능력은 배경지식을 많이 가지고 있다고 해서 저절로 늘지 않습니다. 글의 내용을 평가하고, 비판하고, 발전시키려는 의도적인 노력을 기울여야 조금씩 발전합니다.

오, 애플 워치 시리즈 5 배터리 성능 수준 68% 라서 리퍼 받았는데 시리즈 6로 업글돼서 왔다! 두 세대 전 OS 쓰고 있었는데 최신 oS 설치가 되네!

소프트웨어는 시간이 지날수록 점점 복잡해지고, 원래 의도와 다르게 무너질 위험에 쉽게 노출됩니다. “한 클래스가 너무 많은 일을 한다”, “새로운 기능 하나 추가하려는데 기존 코드를 몽땅 뜯어고쳐야 한다”, “교체 가능한 구현체인데도 특정 코드에 딱 달라붙어버렸다”… 이런 상황을 겪어본 개발자는 많을 겁니다.

이러한 문제를 피하기 위해 정리된 다섯 가지 핵심 규칙이 바로 SOLID 원칙입니다. 이 개념은 소프트웨어 엔지니어 Robert C. Martin(일명 Uncle Bob) 이 다섯 가지 원칙을 하나의 묶음으로 제시하면서 널리 알려졌습니다. 이후로 사실상 “좋은 코드”를 판단하는 표준처럼 자리 잡았습니다.

하지만 SOLID는 객체지향 프로그래밍 전용 규칙이 아닙니다. 함수형 프로그래밍에도 적용할 수 있고, React 같은 UI 라이브러리, 오픈소스 프레임워크 내부 구조를 설계할 때도 그대로 통하는 일반적인 소프트웨어 설계 원칙 입니다. 이번 글에서는 NestJS를 예시로 삼아, 각 원칙이 어떤 문제를 해결하고 실제 코드에 어떻게 녹여낼 수 있는지 살펴보겠습니다.

SRP – 단일 책임 원칙

SRP는 “한 클래스는 오직 하나의 책임만 가져야 한다” 는 원칙으로, 여러 기능이 한곳에 얽히면 서로 다른 이유로 동시에 수정되어야 하므로 유지보수가 어려워집니다. NestJS가 Controller, Service, Repository를 나누는 구조를 제공하는 것도 사실 이 원칙을 실현하기 위함입니다.

❌ 위반 사례

@Controller('users')
export class UserController {
  constructor(private readonly repo: Repository<User>) {}

  @Get(':id')
  async getUser(@Param('id') id: string) {
    const user = await this.repo.findOneBy({ id });
    if (!user?.isActive) throw new Error('Inactive user');
    return { id: user.id, name: user.name };
  }
}

✅ 개선 사례

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Get(':id')
  getUser(@Param('id') id: string) {
    return this.userService.findOne(id);
  }
}

@Injectable()
export class UserService {
  constructor(private readonly repo: Repository<User>) {}

  async findOne(id: string) {
    const user = await this.repo.findOneBy({ id });
    if (!user?.isActive) throw new Error('Inactive user');
    return user;
  }
}

개선 이유

Controller는 요청과 응답만 담당하고, Service는 비즈니스 로직만 다루며, Repository는 데이터베이스 접근에만 집중하게 나누면 각 계층이 독립적으로 바뀔 수 있고 코드의 응집도와 유지보수성이 높아집니다.

📊 다이어그램

OCP – 개방-폐쇄 원칙

OCP는 “소프트웨어 개체는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다” 는 원칙입니다. 즉, 새로운 기능을 넣더라도 기존 코드를 직접 수정하지 않고 확장 방식으로 처리할 수 있어야 한다는 뜻입니다.

❌ 위반 사례

@Injectable()
export class UserService {
  async findOne(id: string) {
    console.log(`[LOG] fetching user ${id}`);
    return { id };
  }
}

✅ 개선 사례

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler) {
    const req = context.switchToHttp().getRequest();
    console.log(`[LOG] ${req.method} ${req.url}`);
    return next.handle();
  }
}

@Module({
  providers: [{ provide: APP_INTERCEPTOR, useClass: LoggingInterceptor }],
})
export class AppModule {}

개선 이유

UserService는 오직 사용자 로직만 담당하도록 두고, 로깅은 Interceptor로 분리하면 로깅 전략을 바꾸거나 새로운 로깅 방식을 추가할 때 기존 코드를 건드리지 않고 확장만으로 대응할 수 있습니다.

📊 다이어그램

LSP – 리스코프 치환 원칙

LSP는 “상위 타입을 사용하는 코드는 하위 타입으로 교체하더라도 정상적으로 동작해야 한다” 는 원칙입니다. MIT의 Barbara Liskov 교수가 1987년 발표한 개념으로, 인터페이스를 구현한 객체라면 언제든 안정적으로 대체 가능해야 한다는 점을 강조합니다.

❌ 위반 사례

export class StripeGateway {
  pay(amount: number): string {
    return `Paid ${amount} via Stripe`;
  }
}

export class TossGateway extends StripeGateway {
  pay(amount: number): string {
    throw new Error('Toss unavailable ❌');
  }
}

✅ 개선 사례

export interface PaymentGateway {
  pay(amount: number): string;
}

export class StripeGateway implements PaymentGateway {
  pay(amount: number) {
    return `Paid ${amount} via Stripe`;
  }
}

export class TossGateway implements PaymentGateway {
  pay(amount: number) {
    return `Paid ${amount} via Toss`;
  }
}

개선 이유

PaymentService는 인터페이스인 PaymentGateway에만 의존하고, 실제 구현체는 계약(pay 메서드)만 지키면 언제든 교체 가능하므로, 코드의 일관성과 신뢰성이 보장됩니다.

📊 다이어그램

ISP – 인터페이스 분리 원칙

ISP는 “클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다” 는 원칙으로, 거대한 인터페이스가 불필요한 의존을 강제하는 문제를 막고자 합니다. NestJS에서는 Guard, Pipe, Interceptor, Filter 등이 이 원칙을 잘 반영합니다.

❌ 위반 사례

class UglyRequestHandler {
  handle(req: any): any {
    try {
      this.authenticate(req);
      this.validate(req);
      this.log(req);
      const result = this.execute(req);
      return { statusCode: 201, message: '회원가입 성공', data: result };
    } catch (err: any) {
      return this.catchError(err);
    }
  }

  private authenticate(req: any) { /* ... */ }
  private validate(req: any) { /* ... */ }
  private log(req: any) { /* ... */ }
  private execute(req: any) { /* ... */ }
  private catchError(err: any) { /* ... */ }
}

✅ 개선 사례

@Controller('auth')
@UseFilters(HttpExceptionFilter)
export class AuthController {
  constructor(private readonly authService: AuthService) {}

  @UseGuards(GuestOnlyGuard)
  @UsePipes(new ValidationPipe())
  @UseInterceptors(LoggingInterceptor)
  @Post('signup')
  async signup(@Body() dto: CreateUserDto) {
    return this.authService.signup(dto);
  }
}

개선 이유

인증은 Guard, 검증은 Pipe, 로깅은 Interceptor, 에러 처리는 Filter가 담당하도록 분리하면 각 기능을 독립적으로 교체하거나 확장할 수 있고, 컨트롤러는 핵심 흐름만 관리할 수 있어 불필요한 의존이 사라집니다.

📊 다이어그램

DIP – 의존 역전 원칙

DIP는 “고수준 모듈은 저수준 모듈에 의존하지 않고, 추상화에 의존해야 한다” 는 원칙입니다. 구체 구현체에 묶여버리면 교체가 어려워지고, 시스템 전체가 쉽게 깨지기 때문에 등장한 개념입니다.

❌ 위반 사례

@Injectable()
export class UserService {
  async createUser(name: string) {
    console.log('User created:', name);
  }
}

✅ 개선 사례

export interface LoggerPort {
  log(message: string): void;
}

@Injectable()
export class ConsoleLogger implements LoggerPort {
  log(message: string) {
    console.log(message);
  }
}

@Injectable()
export class UserService {
  constructor(private readonly logger: LoggerPort) {}

  async createUser(name: string) {
    this.logger.log(`User created: ${name}`);
  }
}

@Module({
  providers: [{ provide: 'LOGGER', useClass: ConsoleLogger }],
})
export class AppModule {}

개선 이유

UserService는 LoggerPort라는 추상화에만 의존하고, 실제 구현은 DI 컨테이너에서 주입되므로 언제든 다른 로거(ConsoleLogger, WinstonLogger, LogtapeLogger, FileLogger 등)로 교체할 수 있어 코드가 훨씬 유연해집니다.

📊 다이어그램

마치며

SOLID는 오래 살아남는 코드를 위한 다섯 가지 약속입니다. 책임을 분리해 응집도를 높이고(SRP), 기존 코드를 건드리지 않고 확장할 수 있도록 만들며(OCP), 계약을 지켜 일관성을 유지하고(LSP), 불필요한 의존을 줄이고(ISP), 추상화를 통해 교체 가능성을 확보합니다(DIP).

세부적인 구현은 둘째치더라도 NestJS는 Guard, Pipe, Interceptor, DI Container 등 이미 SOLID를 녹여낼 수 있는 구조적 도구들을 제공합니다. SOLID는 특정 프레임워크의 패턴이 아니라, 현대 소프트웨어 전반에 알게 모르게 스며들어 있는 보편적 원칙이라고 할 수 있습니다.

글을 읽으시다가 사실과 다른 부분이 보이거나 설명이 모호해 보이는 지점, 혹은 보완하면 더 나아질 것 같은 아이디어가 떠오르신다면, 사소한 것이라도 편하게 지적해 주세요—빠르게 반영하며 글과 코드를 함께 다듬어 보겠습니다.

TIL 세면대 뒤편이 좁은데 수전 교체를 해야한다면 전용 렌치를 사용한다. 별게 다 있네. https://link.coupang.com/a/cSfkZj

TIL 세면대 뒤편이 좁은데 수전 교체를 해야한다면 전용 렌치를 사용한다. 별게 다 있네. https://link.coupang.com/a/cSfkZj

TIL 세면대 뒤편이 좁은데 수전 교체를 해야한다면 전용 렌치를 사용한다. 별게 다 있네. https://link.coupang.com/a/cSfkZj

@kodingwarrior 윈도우에서 파워쉘을 패널 나눠서 쓰는 건가요?!!?

커널형 완전 무선 이어폰을 안전하게 사용하기 위하여

부끄럽지만 저도 귓병이 생겼습니다. 커널형 완전 무선 이어폰의 전성시대라고 해도 과언이 아닙니다. 회사마다 거의 매년 한 두개 쯤의 플래그십 신제품을 내놓고 있고, 보급형까지 포함하면 이루 셀 수 없을 정도로 많은 제품이 나오고 있습니다. 부끄러운 얘기지만 저는 2009년부터 인이어형(소위 말하는 커널형) 이어폰을 사용해왔었는데 에어팟이 나오고 완전 무선 이어폰을 사용하기 시작한 이후에, 커널형으로 된 완전 무선 이어폰을 사용하게 된 이후로 왼쪽 귀에 경도의 외이도염을 앓고 있습니다.

https://purengom.com/2023/07/17/%ec%bb%a4%eb%84%90%ed%98%95-%ec%99%84%ec%a0%84-%eb%ac%b4%ec%84%a0-%ec%9d%b4%ec%96%b4%ed%8f%b0%ec%9d%84-%ec%95%88%ec%a0%84%ed%95%98%ea%b2%8c-%ec%82%ac%ec%9a%a9%ed%95%98%ea%b8%b0-%ec%9c%84%ed%95%98/?utm_source=mastodon&utm_medium=jetpack_social

New release of my llm-openrouter plugin adds support for reasoning options and tool usage, which means you can now execute tools against 179 models made available via OpenRouter
https://simonwillison.net/2025/Sep/21/llm-openrouter/

제가 죄송합니다

RE: https://hackers.pub/@2chanhaeng/01996496-49a8-7ba1-b1b9-cb126d1748cb

좋은 실수를 저지르기 위한 핵심 수법은 실수를 (특히, 스스로에게서) 감추지 않는 것이다. 실수를 저질렀을 때 부인하거나 외면하지 말고 자신의 실수가 마치 예술품인 양 머릿속에서 요모조모 뜯어보는 감정가가 되어야 한다. 어떻게 보면 예술품이 맞기도 하다. . 그러니 실수를 저질렀을 때는 숨을 깊이 들이마시고 이를 악물고 실수를 최대한 냉철하게 들여다보기 바란다. 쉬운 일은 아니다. 실수를 저질렀을 때 당황하고 화내는 것은 자연스러운 반응이다. 이런 정서적 반응을 극복하려면 무척 애써야 한다. 실수를 음미하고, 나를 헤매게 만들 별난 이상異常을 밝혀내는 데서 즐거움을 느끼는 기묘한 습관이 몸에 배도록 해야한다

#독서 공부의 재발견

〈내가 LLM과 함께 코딩하는 방식〉이라는 글을 써 봤습니다…만 이미 LLM 많이 활용하는 분들은 잘 알고 계실 내용들이긴 합니다.

RE: https://hackers.pub/@hongminhee/2025/how-i-code-with-llms

이건 뭐 주기적으로 통신사도 바꾸고 주기적으로 카드도 재발급해야하는건가 이럴거면 주기적으로 주민번호도 바꿔줘 다 털릴거면

홀로... 이상태로 천년만년 업데이트 안하고 문제없이 잘 돌았으면 좋겠... (아직 0.5.x)

왜 내가 쓰는 클로드는 바보 같지... 지피티5 씽킹이 일단 최고시다. 아 딥리서치도.

#독서 공부의 재발견

iOS 26 RC, 쓸 데없어 보이는 글라스 효과 때문에 UI 가 무거워졌을 거라고 생각했는데, 희한하게 오히려 반응성은 더 경쾌해졌다. 탭 했을 때 메뉴 뜨는거나 메뉴 뜨는 반응 등에서. 아이폰 14 프로.