TedDev

말하기, 커뮤니케이션, 프레젠테이션 등 AI시대가 도래함에 따라 이 스킬들은 굉장히 중요한 부분이 되어가는 것 같다.따라서 말하는 방법에 대해 도움될 수 있는 어떤 중요한 포인트나 테크닉이 있을지 관심을 가지게 되는 것 같다이 책은 말하기나 프레젠테이션에서 간단하게 적용해 볼 수 있는 기술들을 소개하면서말하기를 할 때의 마음가짐이나 태도에 대해서도 많이 언급하고 있다. "완벽하지 않아도 괜찮다"말하기를 할 때 가장 어렵게 하는 부분이 완벽주의 때문이라는데 이 부분이 공감이 되었다.남의 시선이나 평가 이런 것들을 두려워 하기 보다 스스로를 믿는 것이 가장 중요한 부분임이 맞는 것 같다. (사실 쉽지 않긴 하다) 아래는 책에서 소개한 말하기에서 간단하게 적용해볼 수 있는 팁에 대해 간략하게 정리해 보았다 ..

애플리케이션 기반 공통 기능애플리케이션 기반에 공통적으로 필요한 기능인증 : 사용자를 식별하고 시스템을 정상적으로 이용할 수 있는 사용자인지 확인인가 : 사용자에게 시스템 리소스에 대한 접근 권한 부여세션 관리 : 사용자별 상태 관리오류 처리 : 시스템에서 발생한 오류를 적절히 제어하고 사용자에게 알림을 제공로깅 : 사용자의 조작과 시스템 처리 상황을 등을 로그로 남김보안 : 크로스 사이트 스크립틍(XSS), 크로스 사이트 요청 위조(CSRF) 등의 보안 조치트랜잭션 제어 : 주로 데이터베이스와 같은 시스팀 자원의 무결성과 일관성을 유지데이터베이스 접근 : 데이터베이스에 대한 접근 수단 제공국제화 : 사용자의 Locale에 따라 언어와 데이터 형식 전환문서 출력 : PDF 등의 형식으로 정형화된 문서 출..

기능 명세서 표준화기능 명세서는 요구사항 분식이 마무리될 무렵 작성된다. 아래는 표준화하는 방법, 주의사항 등을 나타낸다.​유스케이스 다이어그램유스케이스 다이어그램은 사용자와 유스케이스 간 관계를 시각적으로 파악하기 위해 작성UML이라는 표준화 기법이 있지만 작성자에 따라 다이어그램의 단위, 유스케이스 세분화 수준, 표현 방식이 달라질 수 있어 일정한 정책이 필요할 수 있다.​유스케이스 다이어그램은 요소 간 의존 관계를 나타내기 위해 아래 개념을 사용한다.일반화 관계 : 공통된 동작을 가진 여러 유스케이스를 묶어 추상적인 부모 유스케이스와 구체적인 자식 유스케이스 간의 관계를 표현포함 관계 : 여러 유스케이스에서 반복되는 공통 기능을 하나의 유스케이스로 분리, 상위 유스케이스가 이를 호출하는 관계확장 관..

최근 말을 잘하는 법에 대한 중요성을 굉장히 많이 생각하게 되었다.많은 사람들 앞에서 발표를 해야한다던가 업무 관련 커뮤니케이션,그리고 최근 필요에 의해 이직을 위한 면접 기회를 자주 접하다 보니 말을 잘 할 수 있는 방법에 대한 필요성을 느끼게 되었다. 그래서 우선 책을 통해 방법을 찾아보고자 했다. 제일 먼저 눈에 띄었던 책이 '대화의 정석' 이라는 책이었고 이 책을 읽어보기 시작했다. 사실 이 책은 대화, 말을 잘 할 수있도록 스킬이나 기술, 방법 등을 알려주는 책인 줄 알았다.그런데 천천히 읽어 나가다보니 그런 방법적인 부분 보다는 대화를 할 때 가져야하는마음가짐, 태도, 자세 등에 더 많은 설명을 하고 있었다.그리고 더 나아가 누군가와 대화를 할 때는 마음가짐은 삶을 살아갈 때 가져야 하는자세..

아키텍처 기술서아키텍처 기술서에 포함되는 항목목적 : 개요, 문서의 목적, 대상 독자, 아키텍처의 목표 및 지향점아키텍처 드라이버 : 아키텍처 설계 시 고려해야할 요소 (제약, 품질속성, 영향을 미치는 기능 요구 등)전체 시스템 구성 사용자와 이해관계자 : 사용자 및 아키텍처가 영향을 주거나 받는 이해관계자 (PO, 개발자, QA엔지니어 등)아키텍처 모델 : 아키텍처를 다양한 관점에서 모델링하여 문서화 아키텍처 모델이해관계자들은 관심사가 달라 아키텍처에서 알고 싶은 관점이 다르다이러한 관심사와 관점에 따라 아키텍처를 파악하는 방법을 뷰포인트라 한다. 뷰포인트에 따라 실제로 아키텍처를 모델로 표현한 개별 도면을 뷰라 한다대표적인 뷰포인트 세트(여러 개의 뷰포인트를 체계적으로 정리하여 하나의 프레임워크 형태..

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

애플리케이션 아키텍처 검토할 때 중요한 기준은 애플리케이션 설계 원칙으로 선정한 아키텍처 스타일이다.애플리케이션 아키텍처 스타일로는 레이어드 아키텍처파이프라인 아키텍처마이크로커널 아키텍처가 있다. 레이어드 아키텍처애플리케이션을 여러 개의 레이어로 나누고 각 계층의 역할에 맞는 컴포넌트를 배치하는 아키텍처일반적으로는 아래의 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)소프트웨어 구성 요소(클래스, 모듈, 함수 등) 확장에..