TedDev

비교 평가 매트릭스를 활용한 트레이드 오프 분석아키텍처 선택 과정은 트레이드 오프의 연속이다완벽한 가장 좋은 것을 선택하기 보다 가낭 '나은' 것을 선택하는 작업이다비즈니스 요구사항을 총족시키기 위해 품질 속성을 비롯한 요소, 즉 아키텍처 드라이버와 이를 세분화한 요소들이 평가 기준이 된다.아래는 서비스 분할 과정의 비교 평가 매트릭스 예시이다평가 항목단일 서비스 방식세분화된 서비스 방식시간 반응성△ 현재 예상되는 트랜잭션량으로는 문제 없지만 향후 증가할 경우 전체의 스케일업 필요○ 필요에 따라 개별적 스케일링 가능분석성 (로그)○ 문제없음△ 서비스 분할됨에 따라 로그 추적이 어려움. 별도 대응 필요분석성 (성능)△ 응답지연이나 처리량 저하 등 발생 시 규명이 어려움○ 성능 문제가 발생한 특정 서비스 파..

애플리케이션 아키텍처 검토할 때 중요한 기준은 애플리케이션 설계 원칙으로 선정한 아키텍처 스타일이다.애플리케이션 아키텍처 스타일로는 레이어드 아키텍처파이프라인 아키텍처마이크로커널 아키텍처가 있다. 레이어드 아키텍처애플리케이션을 여러 개의 레이어로 나누고 각 계층의 역할에 맞는 컴포넌트를 배치하는 아키텍처일반적으로는 아래의 3계층으로 이루어진다 프레젠테이션 계층 : 사용자 인터페이스에서 받은 요청을 해석하여 도메인 계층의 로직을 호출하고 결과를 클라이언트에 반환한다도메인 계층(비즈니스 로직 계층) : 업무 규칙에 따라 데이터 가공이나 계산 등 비즈니스 로직을 실행한다데이터 액세스 계층 : 외부 리소스에 대해 데이터를 읽고 쓴다레이어드 아키텍처는 단일 책임 원칙을 애플리케이션 수준에서 적용한 구조이다간단하고..

요즘과 같이 바쁘고 정신이 없는 때에 나 자신을 돌볼 틈조차 없는 것이너무 아쉽기도 하고 힘들게 하기도 하는 것 같았다그래서 매일 하루 한 문장, 한 페이지를 필사하면서마음을 차분하게 하는 시간을 가지면 좋지 않을까 생각되어 읽게 되었다.초반에는 필사를 하긴 했지만 솔직히 매일 한 페이지씩 필사를 하는 것을꾸준히 유지하는 것도 쉽지는 않은 일이었다.그래서 매일 아침마다 출근 전 한 두페이지 씩 차분히 읽고 되새기는 방식으로 바꿔나갔다.이렇게 하니 부담도 없고 읽었던 내용을 출근하면서 다시 되새기면서나 자신과 마주하기도 하고 성찰하기도 좋았던 것 같다. 한 페이지 짧은 글속에서 담백하면서도 따뜻한 내용들은힘들고 지친 마음에 위로가 되어주기도 했었고어떤 문장들은 그 힘든 마음을 극복할 수 있도록삶의 방향을..

누가 내 험담을 했다는 것을 알았을 때,보통은 '내가 뭘 잘못한 게 있었나?' 하고생각하며 자신의 말과 행동을 돌아본다.그건 자신의 내면을 파괴하는 나쁜 선택이다.타인이 못된 짓을 했는데왜 애꿏은 자신을 괴롭히는가.타인이 내 험담을 했을 땐,'그렇게 생각하는구나' 하고생각하며 지나가는게 가장 지혜롭다 다른 사람이 나에 대해 하는 험담 뿐만 아니라 평가 이런 것들로 본인 스스로를 괴롭히지 않는 것이 좋을 것 같다이런 것들을 대수롭지 않게 잘 넘기는 것도 스스로를 보호하고 아끼는 방법 중 하나가 아닐까 생각된다.​

아키텍처 선정 시 주요 고려 사항1. 아키텍처 선정은 트레이드오프 이다모든 품질 속성을 만족하는 아키텍처 개발은 사실상 불가능이다.우선적으로 고려해야 할 품질 속성을 선정하고 이를 바탕으로 아키텍처 목록을 정리하고 종합적으로 가장 타당한 방안을 선택해야 한다. 즉, 아키텍처 선정은 단순한 선택이 아니라 각 품질 속성을 조정하며 최적의 균형점을 신중히 찾아가는 트레이드오프 과정이다. 2. 아키텍처 패턴을 활용한다설계 과정에서 시점마다 주목하는 추상화 레벨과 관점에 따라 적절한 패턴을 선택해야 한다. 시스템 아키텍처 검토먼저 시스템 전체 구조를 어떻게 설계할지 시스템 아키텍처를 검토한다.모놀리식 아키텍처를 선택할지 분산형 아키텍처를 선택할지 결정하는 것이다. 모놀리식 아키텍처시스템이 필요한 기능을 하나의 대..

아키텍처 드라이버시스템의 구조를 검토할 때 중요한 고려사항이 되는 요구사항제약, 품질 속성, 영향력 있는 기능 요구사항, 기타 영향을 미치는 요소 제약시스템의 개발부터 운영 환경 배포까지 전 과정에서 부과되는 특정 조건비즈니스적 제약 : 프로젝트의 예산, 일정 또는 운영 시 유지보수 및 관리에 대한 비용 등기술적 제약 : 사용해야 하는 프로그래밍 언어, 라이브러리, 프레임워크, 개발 환경 등 조건 품질 속성소프트웨어 품질을 측정 가능한 속성으로 정의한 것기능 적합성 : 기능의 성숙도, 정확도, 타당성수행 효율성 : 처리 응답 시간, 처리량, 시스템 리소스 크기 등 시스템의 성능을 나타내는 속성호환성 : 다른 시스템에 영향을 주지 않으면서 환경과 자원을 공유할 수 있는지(공존), 여러 시스템 간 연계가 ..

아키텍처의 정의아키텍처시스템이 처한 환경 속에서 시스템의 요소, 관계, 그리고 설계와 발전의 원칙에 따라 구체화된 시스템의 기본 개념과 특성 시스템은 특정 과제를 해결하고 사용자에게 가치를 제공하는 것을 목표로하고 이를 위해서 미리 갖춰야 할 특성을 구현하는 과정이 아키텍처이다. 즉, 소프트웨어를 어떻게 설계하고 앞으로 어떻게 발전시킬지를 결정하는 기본 원리와 원칙을 뜻한다. 설계 과정아키텍처로 달성해야 할 것시스템이 누구를 위해, 어떤 목적으로 만들어지는지 구체화비즈니스적 요구사항, 기능, 품질 속성 정의설계판단구현을 위해 아키텍처를 선정하는 과정. 선정에 이르게 된 판단 근거, 이유 기록비교 평가 매트릭스, 아키텍처 의사 결정 기록(ADR)시스템 구성도형성된 논리적 구조를 도식화개발 문서와 규약, 가..

Spring AI는 Spring 생태계에서 LLM 과 생성형 AI 기능을 쉽게 통합할 수 있도록 만든 프로젝트이다.Spring Boot 기반 애플리케이션에서 GPT, Hugging Face, Vertex AI 같은 모델을 마치 기존의 JdbcTemplate이나 RestTemplate을 쓰듯히 자연스럽고 쉽게 활용할 수 있게 해준다. 목표와 철학Spring 개발자 친화적이다. 기존 스프링 방식(빈 주입, 설정, 프로퍼티 기반, 스타터 의존성 관리 등)에 맞춰져 있어 러닝커브가 낮다.OpenAI, Azure OpenAI, Hugging Face, Ollama, Vertex AI 등 다양한 백엔드 모델을 추상화 계층을 통해 통합Vector DB와 연동하여 RAG(Retrieval-Augmented Genera..

시간이 날 때마다 자신을 돌아보라.이런 성찰의 시간을 아깝게 생각하지 마라.마흔은 이룬 게 없는 게 정상이니주변의 모습에 흔들릴 필요가 없다.또한 좋은 습관은 기적이라는 선물을 주니 늘 유지하자. 자꾸 증명하려고 하지 않아도 된다.내 안에 있는 게 무엇인지 이미 다 알고 있으니,굳이 그것을 타인에게 보여줄 필요는 없다.마지막으로, 모두 다 내려놓으라는 세상의 말에 속지 말자.자존감과 품격은 마흔의 소중한 자산이다. 이전에는 그러지 않았던 것 같은데 어떻게 된 것인지 나이가 들수록 주변의 모습과 사람들의 시선, 평가에 더 신경쓰여지는 것 같다.그래서 더 힘들고 스스로를 갉아먹게 되는 듯 하다.남을 신경쓸 것이 아니라 자신을 살펴보도록 하자.그리고 조그마한 습관부터 하나 만들어 꾸준히 해나가도록 하자.나 자..

SOLID 원칙로버트 C. 마틴이 2000년에 발표한 논문 에서 정리한 객체 지향 설계 원칙이다. 단일 책임 원칙 (SRP)클래스를 변경하는 이유는 단 하나뿐이어야 한다. 단일 책임 원칙은 클래스가 오직 하나의 명확한 역할을 가져야 한다는 원칙이다.만약 여러 역할을 맡으면 클래스가 비대해지고 비효율적인 코드가 될 가능성이 있다. 또한 의존하는 다른 클래스의 수도 늘어나 의존 관계가 복잡해질 수도 있다. 따라서 객체 지향 설계에서는 하나의 역할을 맡는 작고 독립적인 클래스로 나누는 것을 기본으로 한다.다만, 클래스의 역할을 정의할 때 중요한 것은 클래스를 사용하는 클라이언트(다른 클래스) 관점에서 요구되는 역할로 고려해야한다. 개발-폐쇄 원칙 (OCP)소프트웨어 구성 요소(클래스, 모듈, 함수 등) 확장에..

Redis Streams는 Redis 5.0부터 도입된 데이터 타입으로, 로그처럼 append-only로 데이터를 추가해 나가는 구조이다.각 엔트리는 고유의 ID(타임스탬프 기반)와 key-value 쌍으로 이루어져 있다. 주요 특징과 개념Stream : 하나의 키에 여러 개의 메시지(레코드)가 쌓이는 큐 또는 로그 구조Entry(메시지) 구조 : 각 Entry는 ID와 데이터 field-value 쌍으로 저장된다.append only : 데이터는 순차적으로만 추가되고(삭제는 직접 명령) 기본적으로 메시지가 사라지지 않는다.Consumer / Consumer GroupRedis Streams는 Kafka와 유사하게 Producer, Consumer 모델을 지원한다.여러 Consumer가 하나의 Stre..

소프트웨어 설계에는 크게 네 가지 추상화 레벨이 존재한다.각 레벨마다 추상화 정도나 설계 범위가 달라지게 된다. 클래스 설계클래스 설계는 프로그램의 최소 단위가 되는 구성 요소를 설계하는 과정이다. 컴포넌트 설계컴포넌트 설계는 클래스 설계 보다 높은 추상화 레벨에서 컴포넌트의 구성 방식과 협력 방식을 결정하는 과정이다컴포넌트란특정 동작을 수행하는 책임을 가지며, 명확한 인터페이스로 정의된 소프트웨어의 구성 요소를 의미한다. 여러 클래스로 구성되기도 한다.여기서 OrderRepository라는 인터페이스를 구현한 OrderRepositoryImpl 클래스가 컴포넌트의 실체이다.하지만 이 클래스만으로 모든 처리를 수행하지 않고 일부 작업을 Helper 라는 다른 클래스들에게 위임하여 전체 작업을 완료하는데 ..

그럴 때는...빨리 움직여야 해요집 안에라도 돌아다니고설거지라도 한다든지안 뜯었던 소포를 뜯는다든지우울한 기분이 들때그 기분에 진짜 속지 않으려고 노력해요이 기분 절대 영원하지 않고 5분 안에 내가 바꿀 수 있어몸을 움직여야 해요 진짜로! 기분이 안 좋을 때 우울한 상태에 빠져나오기 힘든 느낌이 든다는 점에 공감한다. 그런 상황에서 몸을 움직이면 다른 상황에 집중하게 되고, 우울함에서 벗어나는 데 도움이 된다는 깨달음을 얻었다. 또한, 평소에도 우울한 기분에 빠질 일이 적도록 일부러라도 몸을 움직일 수 있는 간단한 운동을 취미로 시작해보는 것도 괜찮을 것 같다는 생각이 들었다.

소프트웨어는 고객의 문제를 해결하는 등 고객의 요구를 충족시키기 위해 개발된다.소프트웨어 개발 프로세스는 구체화되지 않은 고객 요구사항에서 출발하여 단계를 거치면서 작동 가능한 코드로 변환하는 일련 활동을 의미한다. 요구사항 분석고객의 현재 업무에 대해 인터뷰를 진행하고 업무의 흐름과 규칙을 정리한 후 설계한다.사용자에게 제공해야할 기능은 유스케이스 모델로 정의한다.유스케이스 다이어그램유스케이스 기술서클래스 다이어그램이후 각 유스케이스를 구현하기 위해 필요한 기능을 정의한다.화면 단위, 업무 산출물, 외부 시스템 연동 등 설계요구사항 분석 단계에서 정한 요구사항 명세를 프로그래밍 언어, 프레임워크, 라이브러리를 사용하여 구현하는 방법을 구체적으로 계획한다.복잡한 대규모 시스템은 하나의 프로그램으로 처리..

이 책은 니체의 대표적인 개념인 '위버멘쉬'를 중심으로 우리가 어떻게 자기 자신을 극복하고 더 나은 삶을 살아갈 수 있을지 이야기 한다. 어려운 철학 내용이라기 보다는 짧고 직설적인 문장 구조로 읽기 어렵지 않다."자신만의 길을 찾아라", "고독과 시련을 두려워 말라" 등 일상에 바로 적용할 수 있는 조언이 많다.가볍게 읽으면서 삶에 작은 변화를 줄 수 있는 책으로 추천한다. 기록해두고 새겨두고 싶은 내용 몇 가지 정리해본다.타인의 기대가 아니라 내가 진심으로 믿고 만들어낸 기준을 따라 살아야 할 순간이다.......자신만의 방향을 찾고, 그 방향을 꿋꿋이 지켜낼 때, 우리는 비로소 진정한 자유를 얻는다.......인생은 주어진 길을 걸어가는 것이 아니다. 스스로 길을 만들어가는 여정이다. 인간은 본능적..