TedDev

매니저 역할에 대한 고민은 계속 하게 되는 것 같다.자연히 팀장, 관리자 역할과 관련된 책에 관심이 쏠릴 수 밖에 없는데 이 책은 관리자로서 생길 수 있는 상황, 고민 등을 개별 케이스와 주제로 나열해서 솔루션이나 접근하는 방향 등을 이해하기 쉽게 정리해 놓은 책이다.특정 상황에서 취할 수 있는 구체적인 행동이나 방법을 고민할 때 방향성을 먼저 정하고 꼭 염두에 두어야 하는 포인트 등을 확인할 수 있는 좋은 의견들이 많은 책이다.​"공감", "구성원과의 잦은 소통을 통한 탐색" 등이 언급되는데 리더로서의 본인만의 가치관이나 신념을 정립하는데도 도움이 될 것 같다.​아래는 리더의 역할에 대한 내용 위주로 정리해보았다. 리더의 역할감독(director) : 방향(프로젝트, 구성원의 성장)을 제시하고 길을..

분산 시스템을 구축할 때 가장 어려운 문제 중 하나는 데이터베이스 상태 변경과 이벤트 메시지 발행 사이의 일관성을 유지하는 것이다. 이를 도와줄 수 있는 것이 아웃박스 패턴(Outbox Pattern)이다. 1. 아웃박스 패턴이 왜 필요할까마이크로서비스 아키텍처에서 서비스들은 메시지 브로커(Kafka, RabbitMQ 등)를 통해 비동기적으로 통신하며 서로의 상태 변화를 전달한다. 일반적인 문제 시나리오 주문 서비스가 새 주문을 생성하는 상황을 가정해본다.데이터베이스 업데이트 : 주문 서비스는 트랜잭션을 열고 주문 테이블에 새로운 주문 정보를 저장한다.메시지 발행 : 주문 서비스는 메시지 브로커로 주문 생성 이벤트를 발행하려 한다.만약 1번이 성공한 직후 네트워크 문제나 브로커 다운 등으로 메시지 발행에..

최근 이직을 했다.이직을 하면서 역할이 변경되었는데 개발자에서 엔지니어링 매니저로서 새로운 도전을 하게 된 것이다. 그런데 막상 제대로 매니저 역할을 하려니 내가 당장 무엇을 해야할지 잘 모르겠다.전혀 감도 안오고 그래서 우선 당장 내가 해볼 수 있는 구체적이고 명확한 액션 포인트가 무엇인지에 대한 도움이 필요했다. 그래서 이 책을 읽게 되었고 지금 당장 시도해 볼 수 있는 부분이 무엇인지 위주로 읽어보았다. 사람관리새로운 보고 체계 만들기정기적으로 원온원 미팅하기경력 성장, 목표 달성, 개선된 영역 및 근거 있는 칭찬 등 정기적인 피드백 하기팀원이 학습할 영역을 찾고 프로젝트 업무, 외부 교육이나 멘토링 등을 통해 성장 돕기 팀 관리팀 성공을 위해 개발 프로세스의 병목지점과 장애물을 찾고 이를 제거하..

Spring Cloud Data Flow 란?실시간 데이터 파이프라인(stream)과 배치(job)을 손쉽게 정의, 배포, 운영할 수 있게 해주는 오케스트레이션 플랫폼즉, SCDF 자체는 데이터를 처리하지 않고 "데이터를 처리하는 마이크로 서비스들을 조합, 배포, 관리하는 관리자" 역할을 한다​핵심 구성요소Data Flow ServerSCDF의 두뇌 (컨트롤 플레인)사용자가 정의한 Stream/Task 정보를 저장하고 "어떻게 배포할지" Skipper에 명령을 내린다Web Dashboard, CLI, REST API 모두 여기로 요청이 들어옴Skipper Server배포 관리자 (Deployment Manager)롤링 업데이트, Blue-Green 방식, 롤백 등을 지원Kubernetes, CloudFo..

모듈러 모놀리식 아키텍처는 전통적인 모놀리식 아키텍처의 강점을 유지하면서 마이크로서비스의 모듈화 원칙을 적용한 아키텍처이다.​핵심 개념단일 배포 단위 + 높은 모듈화애플리케이션은 하나의 프로세스로 배포되지만 내부적으로는 명확히 분리된 모듈들로 구성된다.각 모듈은 독립적인 도메인 책임을 가지며 명확한 인터페이스를 통해서만 통신한다.​주요 특정강한 모듈 경계각 모듈은 자체 데이터베이스 스키마나 테이블을 가질 수 있다다른 모듈의 내부 구현에 직접 접근할 수 없다공개 API/인터페이스를 통해서만 상호작용한다독립적인 개발각 모듈은 독립적인 팀이 담당할 수 있다모듈 내부 변경이 다른 모듈에 영향을 주지 않는다단, 공개 인터페이스 변경 시에는 조율이 필요하다단순한 운영단일 배포로 전체 시스템이 업데이트 된다분산 시스..

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

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

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

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

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

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

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

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

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

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