1. SRP: 단일 책임 원칙 (Single Responsibility Principle)

"한 클래스(또는 모듈/함수)는 하나의 책임만 가져야 한다."

• 레거시의 문제: 현재 쿼리는 데이터 조회 + 수익 계산 + 수익률 계산 + 절대값 변환(UI 로직)을 모두 수행합니다. DB 담당자가 UI 기획(절대값 표시 여부)까지 신경 써야 하는 구조죠.
• 해결: 쿼리는 데이터 추출만 하고, 계산은 **도메인 서비스(PHP 클래스 등)**에서, 출력 형식은 UI 레이어에서 담당하게 나눕니다.

2. OCP: 개방-폐쇄 원칙 (Open/Closed Principle)

"확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다."

• 레거시의 문제: 만약 '해외 주식 수수료' 로직이 추가된다면, 기존의 복잡한 쿼리 수식을 직접 일일이 수정해야 합니다. 이때 기존 수식을 건드리다가 버그가 생길 위험이 큽니다.
• 해결: Calculator 인터페이스를 만들고 DomesticCalculator, OverseasCalculator를 구현하면, 기존 코드를 수정하지 않고도 새로운 계산 로직을 추가할 수 있습니다.

3. LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)

"자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다."

• 개념: 부모를 상속받은 자식 객체가 부모의 기능을 망가뜨리면 안 된다는 원칙입니다.
• 예시: 수익을 계산하는 부모 클래스가 있는데, 어떤 자식 클래스가 "수익이 마이너스면 에러를 던져버리게" 구현했다면 LSP 위반입니다. (부모가 예상하는 결과의 범위를 벗어나기 때문)

4. ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)

"사용하지 않는 메서드에 의존하도록 강제해서는 안 된다."

• 개념: 커다란 인터페이스 하나보다는, 구체적인 여러 개의 인터페이스가 낫다는 원칙입니다.
• 예시: TradeAction이라는 거대 인터페이스 안에 매수(), 매도(), 수익정산(), 세금신고()가 다 들어있으면, 단순 조회만 필요한 화면에서도 불필요한 기능에 의존하게 됩니다. 이를 각각 분리해야 합니다.

5. DIP: 의존역전 원칙 (Dependency Inversion Principle)

"고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다."

• 레거시의 문제: 현재 PHP 코드(고수준)가 특정 DB의 복잡한 SQL 수식(저수준)에 직접 의존하고 있습니다. DB 버전이 바뀌거나 수식이 바뀌면 PHP 코드 전체가 흔들립니다.
• 해결: PHP 코드는 ProfitRepository라는 **인터페이스(추상화)**를 바라보게 합니다. 실제 그 안에서 SQL이 도는지, 메모리에서 계산하는지는 나중에 갈아 끼울 수 있게 만드는 것입니다.