블로그

[프로젝트 공유] 프레임워크에 덜 의존적인 UI 컴포넌트를 만들어봤습니다

안녕하세요.프론트엔드 개발을 하면서 React, Vue 등 여러 프레임워크를 오가다 보니항상 비슷한 고민을 하게 되었습니다.Select, Toast 같은 기본 UI 컴포넌트는프레임워크가 바뀔 때마다 다시 구현해야 할까?UI 동작과 UX는 거의 같은데,프레임워크에 묶여 있다는 이유로매번 새로 만드는 구조가 과연 효율적인지 의문이 들었습니다.그래서 개인 프로젝트로프레임워크에 덜 의존적인 UI 컴포넌트를 Web Components 기반으로 만들어보았습니다.🔧 어떤 것을 만들어봤나요?크게 두 가지 컴포넌트입니다.1⃣ Select 컴포넌트Web Component 기반 (의존성 없음)대용량 데이터 처리를 위한 가상 스크롤한글 초성 / 일본어 / 중국어 검색 지원키보드 접근성 및 스크린 리더 대응CSS Variables 기반 스타일 커스터마이징React, Vue 등에서 사용할 수 있도록 래퍼 제공2⃣ Toast 알림 컴포넌트프레임워크에 종속되지 않는 Toast UI여러 위치와 애니메이션 지원중복 메시지 자동 그룹핑SSR 환경 고려접근성(ARIA) 기본 지원🤔 Web Components를 선택한 이유Web Components를 선택한 이유는 단순합니다.브라우저 표준 기술이라 장기 유지에 유리특정 프레임워크 라이프사이클에 묶이지 않음여러 프로젝트에서 재사용 가능UI 프리미티브(Select, Toast 등)에 적합하다고 판단물론 프레임워크 전용 컴포넌트만큼의 DX는 아닐 수 있지만,장기적인 관점에서는 충분히 의미 있는 시도라고 생각했습니다.💬 커뮤니티 분들께 여쭤보고 싶습니다실무에서 Web Components를 사용해보신 경험이 있으신가요?프레임워크 변경 가능성이 있는 프로젝트에서UI 컴포넌트를 어떻게 관리하고 계신지 궁금합니다.이런 접근 방식이 현실적인 선택일지 의견을 듣고 싶습니다.아직은 실험적인 프로젝트이고,피드백을 받아가며 개선해보려는 단계입니다.편하게 의견 주시면 감사하겠습니다.🔗 참고 링크Select 컴포넌트: https://www.npmjs.com/package/seo-selectToast 컴포넌트: https://www.npmjs.com/package/seo-toast

테스트

123

[학습일기] HTTP 서비스 인증/인가 관련 이해한 내용 정리

들어가며인증과 인가와 관련해서 공부를 할 때 원리가 이해가 안 되어서 로그인과 CSRF와 같은 개념을 그냥 예시를 통해서 귀납적으로 학습하는 데에 그쳤다. 당연히 뭔가 답답한 느낌이 들었고 CSRF의 경우 외우고 까먹고를 반복했다.그러다가 최근에 갑자기 이 내용이 이해가 되었다. 방금 깨달은 사람의 따끈따끈한 이해를 말아드리고 싶어서 이 블로그글을 작성하게 되었다. (이랬는데 알고 보니 틀린 이해일 수도 있습니다ㅠㅠ 혹시 틀린 부분을 발견하시면 댓글 달아주시면 감사합니다!!)이해한 부분네트워크 서비스의 인증 및 인가와 관련해서 이해하는 데 개인적으로 다음 활동이 굉장히 도움이 많이 되었다.특정 사용자를 인증하기 위한 필요충분조건을 논리식으로 작성하기특정 서비스의 사용을 인가하기 위한 필요충분조건을 논리식으로 작성하기 이 관점에서 인증 및 인가를 다음과 같이 정리하게 되었다.인증(Authentication, Authn)정의위키피디아에서 찾아본 인증의 정의는 다음과 같다.특정 사용자의 본인확인을 증명하는 과정. 다시 말해, 특정 사용자가 본인이라고 주장하는 사람이 맞는지 확인하는 과정인증이라는 개념이 왜 필요하게 되었는지를 웹 서버의 입장이 되어 생각해보자.일반적인 웹 서비스에서 사용하는 웹 서버의 경우 대부분의 ip로부터 요청을 받을 수 있다. 비유하자면 불특정 다수로부터 쪽지를 받는 것과 같다. 다음 쪽지를 받았다고 가정해보자.안녕하세요, 미스터 비스트 유튜브 팀에서 연락드렸습니다.저희가 이번에 만들고 있는 영상에 초대드리고 싶습니다.아래의 주소에 접근해서 설명을 따라 주시면, 다음 영상에 출연하실 수 있습니다.https://example.com?phishing=true문제가 한두개가 아니다. 일단 미스터 비스트가 내게로 연락을 보낼 리가 없고, 글솜씨가 허접하다. (글쓴이의 글쓰기 스킬 이슈입니다.) 하지만 웹서버 입장에서 중요한 문제는 따로 있다. 본인이 알고 있는 주소에서만 접근하는 것도 아니고 불특정 다수의 ip 주소로부터 HTTP 요청을 받기 때문에 요청을 보낸 것이 실제 미스터 비스트인지 미스터 비스트인 척 하는 김 아무개씨인지를 확인할 방법이 없다. 다시 말해 웹 서비스에 가입한 특정 사용자 A가 있을 때, 본인이 사용자 A라고 주장하는 요청이 실제 사용자 A가 보낸 것인지 아닌지 확인하는 과정이 필요하다. 이런 맥락에서 인증이라는 개념이 자연스럽게 필요해진 것 같다.간단한 웹 서비스에서의 사용자 인증비밀번호를 통한 인증소개 및 필요충분조건웹 서비스를 누군가는 처음 만들었을 것이다. 만들면서 인증에 대한 문제를 다음과 같이 풀 생각을 하지 않았을까? (즉, 뇌피셜입니다.)인증의 문제를 다음과 같이 해결하면 어떨까?하나, 사용자 A가 가입하는 시점에 A와 웹 서비스 둘이서만 아는 비밀번호를 공유한다.둘, 앞으로 HTTP 요청을 보낼 때 본인이 A라고 주장하며 동일한 비밀번호를 제시하면, 그 사람은 A라고 유추할 수 있다.현재까지의 사고 과정을 필요충분조건으로 정리하면 다음과 같다.(사용자 A 인증) <=> (HTTP 요청 시 A의 비밀번호가 제시됨)문제점위의 인증 방식은 조금만 생각해보면 사용성 또는 보안에서 엄청난 문제점이 있는 것을 확인할 수 있다. 웹사이트에 요청을 보낼 때마다 비밀번호를 제시해야 하기 때문이다. 사용자가 본인 페이지 내에서 이동할 때마다 비밀번호를 입력하게 하자니 사용성에서 하자가 있다. 또한 매 요청마다 평문으로 비밀번호가 전송되기 때문에 요청 중 하나라도 감청당한다면 비밀번호가 그대로 노출되게 된다.비밀번호 및 세션 토큰을 통한 인증소개사용자가 웹 서비스를 사용할 때 특정 시각부터 특정 시각까지 대화가 오가는 패턴이 자주 등장한다. 대화에서와 마찬가지로 이 대화 내의 나중의 요청은 이전의 요청들에 의해 쌓인 맥락을 가지고 있다. 이렇게 특정 시간 범위 동안 존재하는 고수준 양방향 연결을 세션이라고 한다. 보통 세션은 이전 요청들에서 쌓인 맥락을 가지고 있기에 stateful하다.이렇게 웹 서비스에서 흔하게 존재하는 세션이라는 개념을 활용하면 "매 요청마다 비밀번호가 평문으로 전송된다"는 문제를 다음과 같이 해결할 수 있다.이미 사용자 A에 대한 세션이 있는 경우 A의 세션에 대한 접근 권한을 A의 비밀번호 대신 사용할 수 있다.이 경우 연결이 감청당한 경우에도 세션 접근 권한 정보는 세션이 존재하는 동안만 유효하기 때문에 비밀번호가 유출되는 확률을 낮출 수 있다. (추가: 그러나 세션이 탈취당한 상황에서 이게 얼마나 의미가 있는지는 모르겠습니다.)따라서 매번 비밀번호를 입력받는 과정을 다음의 세 단계 과정으로 대체할 수 있다.하나, 사용자 A에 대한 아이디와 비밀번호를 받아서 서버에서 세션 저장소에 A를 위한 세션의 정보를 저장하고, 세션 정보에 접근할 수 있는 권한을 응답에 반환한다. 이를 보통 "로그인"이라고 칭한다.둘, 로그인 상태에서는 세션 접근 권한을 비밀번호 대신 인증 수단으로 사용한다.셋, 특정 시간이 지나거나 사용자가 직접 요청하는 경우 세션 정보를 파기한다. 이를 "로그아웃"이라고 칭한다.토큰 소개오해를 방지하기 위해 토큰에 대해서 짚고 넘어가보자. 위키피디아에 의하면 토큰의 정의는 다음과 같다.특정 작업에 대한 권한을 표현하는 소프트웨어 혹은 하드웨어 객체따라서 꼭 JWT의 형식이 아니더라도 세션 접근에 대한 권한을 표현하는 데이터를 모두 "세션 토큰"이라고 칭할 수 있는 것으로 보인다. (혹시 아니라면 알려주시면 감사드립니다!)필요충분조건위에서 정리한 내용을 필요충분조건으로 정리하면 다음과 같다.(사용자 A 인증) <=> (A 비밀번호 제시) OR (현재 존재하는 A의 세션에 대한 토큰 제시)여기서 인상적인 점이 토큰이라는 개념은 바로 뒤에 다룰 내용인 인가에 대한 내용이지만, 인증 정책의 일환으로 A의 세션에 대한 권한이 있는 사용자를 A에 대한 인증의 충분조건으로 사용했기에 여기에 등장했다는 사실이다.정리여기까지 인증에 대한 내용을 간단하게나마 살펴보았다. 인증으로 접근 권한도 퉁쳐서 나타내면 안 되는 걸까? 여기서는 CSRF의 사례를 들어 둘을 분리해야 하는 이유 중 하나를 살펴보겠다.인가정의위키피디아에서는 다음과 같이 서술하고 있다.리소스에 접근할 수 있는 권한을 명시하는 것인증과 구별해야 하는 이유여기서 "A로 인증했으면 A가 권한이 있는 작업들을 모두 허용해도 되는 것 아닌가?"라는 의문이 당연하게 들 수 있다. 이 둘을 일치시켰을 때 발생할 수 있는 문제 중 하나로 CSRF 공격을 예로 들어보겠다.CSRFCSRF는 Cross-Site Request Forgery의 약자로, "사이트 간 요청 위조"를 뜻한다. 쉽게 말해 S1 사이트에서 사용자 A에게 본인의 의사와는 무관하게 S2 사이트로 특정 요청을 보내도록 시키는 공격이다. 예를 들어 S1이 해커 사이트이고, S2가 은행 사이트이고, S2가 CSRF에 대한 보호가 안 되어 있는 경우, S1 사이트에서 HTML Form과 자바스크립트를 통해 S1에 접속한 사용자 A로 하여금 해커에게 송금을 하라는 요청을 S2에 보내도록 시킬 수 있다. 자세한 정보는 MDN에서 잘 설명되어 있다.CSRF가 발생할 수 있는 이유는 사용자가 브라우저에서 S1 사이트를 방문했을 때 S2 사이트에 대신 요청을 보내도록 하는 것이 너무 쉽게 가능하기 때문이다. Form 태그의 action attribute를 활용하면 사용자로 하여금 다른 사이트에 요청을 보내도록 할 수 있고, 이 때 cookie에 저장된 인증 정보가 같이 전송되기 때문에 문제가 된다.CSRF 발생 원인 분석 및 해결사이트 S2 입장에서 다음과 같은 정책을 생각할 수 있다.(사용자 A의 송금 서비스 접근 권한) <=> (사용자 A의 인증 정보)이렇게 할 경우 문제가 안 생기는 맥락이 어디엔가 있을지도 모르지만, 안타깝게도 웹 서비스 환경에서는 위에서 기술한 이유로 인해서 요청한 사용자가 정상적으로 웹 서비스를 사용해서 나온 요청인지, CSRF 공격의 피해를 당해서 발생하는 요청인지 구분할 수 없다.이에 대응해서 정상적으로 웹 서비스를 사용하는 사람에게만 발급해주는 토큰을 사용해서 해결할 수 있다. 구체적으로 HTML Form으로 웹 서비스를 제공하는 경우, Form의 hidden field에다가 매번 바뀌는 랜덤 문자열 토큰을 삽입해주고, Form을 제출했을 때 이 토큰을 확인함으로써 해결할 수 있다. 이 경우 토큰은 사이트 외부에서 접근 가능한 정보가 아니지만 요청에 꼭 필요한 정보이기 때문에, CSRF로 요청을 위조하는 것이 불가능하게 된다.이를 논리식으로 나타내면 다음과 같다.(사용자 A의 송금 서비스 접근 권한) <=> (사용자 A의 인증 정보) AND (CSRF 방지 토큰 소유)정리하며생각보다 시간이 많이 걸렸습니다. 잘 이해했는지 모르겠네요...

[인프런 클론 6주 완성 챌린지] 선택 및 집중 과정에서 포기해야 하는 것들에 대한 고민

지난주는 nextjs에 익숙해지는 데 많은 시간을 할애했다.주어진 속도로는 시간을 최대한으로 투자해도 진도를 정해진 일정대로 따라가는 것은 무리라고 판단하였다. 그래서 어차피 챌린지 일정이 밀릴거라면, 1-2주차처럼 무리해서 시간을 배분하지 말고 챌린지 외 일정들을 챙기면서 진도를 천천히 따라가자는 계산을 했다.사실 지난주와 지금을 비교해봤을 때 실력적으로 큰 차이가 있지는 않지만 비슷한 패턴을 여러 번 반복해서 보다 보니 심적으로 익숙해지게 되었다. 그래서 다시 챌린지로 돌아와 프런트엔드 코드를 작성할 때 (할 일 계획) + (nextjs 코드 작성 및 이해)의 두 가지 변수 중에 후자가 해결되어 cursor에게 어떻게 일을 시킬지에 집중할 수 있게 되었고, 문제였던 불안도 어느 정도 해결되었다.각설하고 이제 급한 문제를 해결하고 보니 절대적인 시간이 부족하게 되어, 챌린지 기간 동안 어떤 부분을 챙기고 어떤 부분을 포기할지를 고민해야 하는 상황이다. 사실 이 생각을 하게 된 구체적인 이유가 있다.인프런의 지식공유자 강의 수정 화면은 다음과 같이 구성되어 있다.페이지상단 헤더: 현재 수정중인 강의 제목, 저장 및 제출 버튼 등메인 영역사이드바: 수정 과정의 모든 단계들 및 현재 단계 표시 강의 수정 영역: 강의 수정 정보 입력 폼반면 챌린지의 화면은 다음과 같이 구성되어 있다.페이지 사이드바메인 영역상단 헤더강의 수정 영역개인적으로 느끼기에 챌린지의 화면 구성이 훨씬 고민거리가 적기 때문에 챌린지 설계 과정에서 훌륭한 트레이드오프가 들어간 게 아닌가 생각하고 있다. (아닌가요...? 죄송합니다ㅠㅠ)이 파트를 구현하면서 챌린지 화면 구성에서 끝내도 되는 줄 모르고 이를 인프런 화면 구성으로 리팩터링을 시도하느라 하루를 보냈다. (결국 오늘 더 시간 쓰고 싶지 않아서 revert했습니다.) 이와 관련해서 글의 주제와는 관련 없는 몇 가지 흥미로운 생각이 들었는데 [여담]에서 따로 기술하였다.이 문제를 해결하면서 한 고민들은 nextjs를 이해하는 데 도움은 되었지만, 챌린지의 맥락에서 봤을 때 너무 지엽적인 내용인 것 같았다. 그래서 오늘 챌린지 전체 과정을 한 번 훑어보면서 내가 어떤 부분을 취하고 어떤 부분을 버려야 할지 다시 한 번 생각하게 되었다.개인적으로 챌린지를 하면서 가져가고 싶은 부분은 다음과 같다.백엔드 실 서비스 개발의 전체 흐름을 직접 경험해보기 (상세한 디테일은 챌린지 목차에서 확인 가능)이를 위해서 nextjs에 대한 이해는, 챌린지 코드의 큰 구조 및 데이터 흐름 및 AI 생성 코드를 이해할 수 있는 만큼만 가져가기로 결정했다. 그리고 "인프런 화면 구성 구현하기"는 이 관점에서 살펴봤을 때 욕심이라는 생각이 들었다.이상입니다. 읽어주셔서 감사드립니다.[여담] 여담이지만 위 현상을 경험하면서 몇 가지 생각이 들었다.스스로 무언가를 해보면서 발생하는 문제 상황을 해결할 때 배우는 게 많다. (주관적인 생각입니다.)AI가 이 과정을 방해한다고 생각했는데, 방금 배운 것을 돌아보니 AI를 활용한다고 해도 이 과정이 바뀌지는 않는구나 싶은 생각이 들었다.나는 AI가 작성하는 코드를 이해하고 싶은 마음이 크다. 혹시 관련이 있을지도?Context 왜 쓰는지 백날 고민해봤는데 한 번 리팩터링하면서 와닿는 게 더 많았다. 역시 직접경험이 짱인 것 같다.UI가 응집되는 방향성과 데이터/함수/메소드가 응집되는 방향성이 달라서 발생하는 문제를 해결한다고 생각했었고 이번 리팩터링에서 이를 실감했다. 개인적으로는 현재 리액트 주류 스택이나 MobX 활용 스택이나 주인공을 컴포넌트로 둘 것인지 객체로 둘 것인지의 관점의 차이만 있지 둘 다 이 문제를 훌륭하게 해결한다고 느꼈다. (물론 저는 말하는 감자입니다. 감자가 느낀 것을 그대로 믿으시면 안됩니다.)내가 초기 스타트업에서 일을 하는 상황이었다면 챌린지 화면처럼 구현하자고 기획자와 승부를 봐서 타협을 했을 것 같다.나는 AI가 작성한 코드를 더 쉽게 이해하고 싶어서 스타일링 최소화한 ui 코드 만들기 / 스타일링하기의 2단계로 쪼개서 일을 시키는 것을 좋아한다.또 리팩터링을 설계하고 AI 생성 코드를 이해하는 과정에서 다음과 같은 고민들을 했거나 진행중이다. 내가 생각하기에 괜찮은 고민인 것 같다.nextjs에서 서버 컴포넌트로 ViewModel A에 대한 초기 json 데이터를 얻고, 클라이언트 컴포넌트에서 A를 업데이트하는 패턴이 보이는데, 이 패턴을 공통으로 묶을 수 없을까? (고민중)인프런 화면 구성을 구현하려면 Layout 컴포넌트를 어떻게 설계해야 할까? (마음에 드는 솔루션 하나 확인)

코딩 가독성 최적화 방법

[인프런 클론 6주 완성 챌린지] 배우기와 익히기의 밸런스

개인적으로 이번 챌린지를 신청하는 데 많은 용기가 필요했다.하나는 타인의 문제 해결을 클론코딩하면서 내가 문제를 해결하는 문제해결력이 떨어지는 것이 아닌가 걱정했기 때문이고,다른 하나는 내 자신의 문제해결력에 하자가 있다는 것을 인정해야 했기 때문이다. (주의: 개인적인 맥락 하에서만 맞는 얘기입니다. 일반적으로 클론코딩 수업을 듣는다고 문제해결력에 하자가 있다고는 생각하지 않습니다.)이번 챌린지를 신청했을 때 했던 생각은 약간 자포자기하는 심정으로 '내 문제해결력이 떨어지는 리스크를 감수해서라도 나는 백엔드 개발을 한 바퀴를 돌려봐서 흐름을 파악해야겠다'였다. 또 '지금 못해도 배워서 잘 하면 되지'라는 말로 못하는 내 자신을 용서하는 과정도 필요했다.뚜껑을 열어보니 예상외로 챌린지에 참여하기를 정말 잘한 것 같다는 생각이 들었다. 일단 지금까지는 그렇다. 모방하고 이를 돌아보는 과정에서 내 문제 해결의 어떤 부분에서 하자가 있는지를 파악할 수 있었기 때문이다.실마리는 불안한 상태에서도 퍼포먼스를 내는 방법을 고민하면서 찾아왔다. 문득 '불안한 상태에서도 손이 자동적으로 나가도록 무지성 연습을 하면 불안할 때도 내 실행 능력의 저점은 보장되지 않을까?'라는 생각이 들었다. 그래서 nestjs 첫 프로젝트 수업을 2회, 컨트롤러는 3회 반복해서 구현했다. 반복하면서 다음 생각이 들었다.내가 불안감을 느끼면서 막혔던 이유는 동시에 문제 2-3개를 해결해야 해서 압도당했기 때문이다.예를 들면 nestjs controller 구현 + 클론 코딩 과정에서 현재 단계에 대한 이해작업이 어려워서가 아니라 코드가 손에 안 익어서 막힌다.간단한 게시글에 대한 crud 작업 연습에서 사실 "이해"가 필요한 부분은 거의 없다. 반복하면서 막혔던 이유는 전부 nest가 손에 안 익어서였다.그러면서 이런 생각이 들었다.모든 학습 과정은 배우기('학')와 익히기('습')가 동반된다. 프로그래밍의 경우 과목 특성인지 배움 없이 익히기에 치중한 학습자들이 많아서인지는 모르겠지만 이 중 정확한 이해를 통한 배우기가 특히 강조된다고 개인적으로 느꼈다.배우기와 익히기의 비중은 프로그래밍의 하위 분야에 따라 많이 다른 것 같다. 알고리즘 학습의 경우 (PS만큼 어렵지는 않은 맥락에서는) 배우기를 잘 하면 익히기는 상대적으로 수월하게 되는 것 같고, 웹 개발의 경우 배우기와 익히기 둘 다 의식적인 노력이 필요한 것 같다.나는 지금까지 내가 알고리즘은 못하더라도 "뭔가 잘 맞고" 웹 개발은 "뭔가 잘 안 맞는다"고 생각했는데, 적성의 문제가 아니라 학습 방법의 문제인 것 같다는 생각이 들었다.이제 앞으로 할 일은 막힐 때 어떤 부분으로 인해 병목이 생기는지를 파악해서 그 부분의 문제를 하나씩 해결하면 되지 않을까 싶다.

[인프런 클론 6주 완성 챌린지] 오늘을 기억하고 싶다.

오늘은 처음으로 불안에 직면했을 때 긍정적인 피드백을 받은 날이다.처음 노트북을 꺼내들었을 때는 불안에 떨고 있었는데, 중간에 tailwind 스타일링 할 때 따라해보면서 변주를 주는 과정에서 몰입이 되었고, 시간 가는 줄 모르고 강의 끝까지 따라치게 되었다. 강의가 끝났을 때의 성취감, 효능감이 장난이 아니었다.물론 객관적으로는 한 것은 정말 아무것도 없다. 강의에서의 로그인 플로우를 따라 친 것이 전부이다. 그리고 냉정하게 돌아본다면 내가 몰입할 수 있는 일의 난이도는 tailwind 스타일링 및 강의를 그대로 따라치는 수준에 불과하다.하지만 오늘은 그런 것보다도 일주일동안 불안한 상태로 애쓴 내 자신에게 고생했다는 말을 해주고 싶다.그리고 미래에는 조금씩 더 어려운 일들에도 직면할 수 있을지도 모르니 희망을 잃지 말자는 생각이 들었다.이 순간을 기억하기 위해 조금만 쉬었다 다음 강의로 넘어가야겠다.

레거시 결제/정산 백엔드 서비스 재구축

1. 프로젝트 소개>프로젝트 목표:현재 운영 중인 레거시 결제/정산 백엔드 시스템의 구조적 문제점(낮은 유지보수성, 강한 종속성, 불안정한 확장성)을 해결하고, 클린 아키텍처를 적용하여 고도로 안정적이며 변화에 유연하게 대응할 수 있는 차세대 결제/정산 시스템으로 전환하는 것입니다.>주요 기능:핵심 결제 로직 재구현: 안정적인 결제 승인, 취소, 환불 로직 처리.정산 시스템 고도화: 일별/월별 정산 데이터 생성 및 관리, 복잡한 수수료 및 분배 로직 처리.PG사 연동 모듈 분리: 다양한 외부 결제대행업체(PG사) 및 금융기관 연동을 위한 인터페이스(Gateway)를 명확히 분리하여, PG사 변경이나 추가에 유연하게 대응.고성능 트랜잭션 처리: 대량의 결제 트래픽을 안정적으로 처리할 수 있는 성능과 트랜잭션 무결성 확보.2. 클린 아키텍처 선택 동기-기존 레거시 방식의 문제점기존 레거시 결제/정산 시스템은 다음과 같은 구조적 문제점을 내포하고 있어, 장기적인 운영 및 개발에 심각한 어려움을 초래했습니다.DB/프레임워크에 종속된 비즈니스 로직:핵심 결제 및 정산 비즈니스 규칙이 데이터베이스 접근 코드(SQL, ORM)나 특정 웹 프레임워크(예: Spring Controller, Django View)의 구현체에 강하게 결합되어 있었습니다.이로 인해 DB 스키마나 프레임워크 버전이 변경될 때마다 핵심 비즈니스 로직까지 대규모의 수정이 필요했습니다.-낮은 유지보수성과 확장성:시스템의 핵심인 결제 로직이 외부 기술과 얽혀있어, 새로운 결제 수단이나 복잡한 정산 정책이 추가될 경우 코드 전체를 건드려야 했으며, 이 과정에서 코드의 유연성과 유지보수성이 현저히 저하되었습니다.-테스트의 어려움:순수한 비즈니스 로직을 테스트하기 위해서도 반드시 데이터베이스 연결이나 웹 환경 설정이 필요하여, 단위 테스트 작성이 어렵고, 기능 변경 후 안정성을 신속하게 검증하기 어려웠습니다.-클린 아키텍처 적용 동기결제/정산 시스템은 회사의 수익과 직결되는 미션 크리티컬(Mission-Critical)한 핵심 도메인입니다. 클린 아키텍처는 이러한 핵심 도메인의 안정성과 장기적인 유지보수성을 극대화하는 최적의 솔루션입니다.-핵심 비즈니스 로직 보호 (Independent of Frameworks, DBs, UIs):클린 아키텍처는 핵심 비즈니스 규칙(도메인)을 DB, Web Framework, UI와 같은 외부 기술 요소로부터 완벽하게 분리하여 보호합니다.이는 시스템의 생명주기가 길어질수록, 프레임워크의 변화나 DB 마이그레이션과 같은 외부적인 변화에도 결제/정산 로직의 안정성을 흔들림 없이 유지할 수 있게 합니다.-높은 테스트 용이성 확보:Use Case(유스케이스, Interactor) 계층에 비즈니스 로직을 집중하고, 이를 외부 인프라(DB Repository)의 구현체에 의존하지 않도록 설계합니다.결과적으로 DB 연결 없이도 순수한 비즈니스 로직만을 독립적으로 테스트할 수 있어, 리팩토링 및 기능 확장 시 안정성을 매우 높일 수 있습니다.-SOLID 원칙 준수 및 장기적인 유지보수 극대화:클린 아키텍처는 SOLID 원칙을 자연스럽게 유도하며, 특히 SRP(단일 책임 원칙)와 OCP(개방-폐쇄 원칙)에 따라 시스템을 설계하도록 장려합니다. 이는 결제, 정산, 환불 등 각 기능별 유스케이스의 책임을 명확히 하고, 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있는 유연하고 확장 가능한 구조를 확립합니다.