%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%84%A4%EA%B3%84

MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번 호출하는게 너무 불편합니다. 에러 처리하기도 그렇고요. 한 번의 호출로 만들어 달라고 요청했는데 거부 당했습니다. - 개발자 C 무엇이 문제인가?...

이번 포스팅도 어떤 백엔드 서비스의 코드를 리팩터링한 내용을 정리하는 것으로, 이번에는 코드 복잡도 줄인 리팩터링에 대한 내용을 정리한다. 이전에 포스팅했던 ' 가변 Context 클래스는 신중하게 사용하자 '와 ' 고차 함수로 의존성 줄이기 '로 코드의 의존성 문제들이 많이 정리된 상태라서 복잡도 줄이기를 진행할 수 있었다. 아래는 어떤 백엔드 서비스 코드의 리팩터링 전과 후의 코드 복잡도 Cyclomatic Complexity와 NPath Complexity의 수치 변화다. 많이 줄어든 것을 볼 수 있다....

스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브 서비스에 반영하였다. 이번 글은 오랜 세월의 흐름으로 서비스 의존성 그래프가 복잡해진 라이브 서비스를 리팩터링한 내용을 일반화하여 작은 예제로 만들어서 정리한다....

브런치에서 뉴스를 빠르고 유익하게 소비하는 사례 로 썼던 글을 popit의 주요 독자들이 흥미로워 할 주제라 생각에 이곳에도 옮겨봅니다. 두 가지 이야기를 하려고 합니다. 트레이드오프 즉, 상충관계에 대한 생각 개발자에게 아키텍트로 나아가는 길 먼저 트레이드오프는 과거 제가 소프트웨어 아키텍트 로 일할 때, 가장 자주 다루던 개념이자 주요 관심사였습니다. 서로 다른 이해관계를 갖는 참여자 사이에서 소프트웨어가 나아갈 길을 다룰 때, 선택의 갈림길에 항상 만나는 것이 트레이드오프였죠....

2016년, 중국 패션 리테일 영역의 클라우드 서비스 회사가 되겠다는 야심 찬 희망을 품고 아기 발걸음 [1] 을 시작했고, 2020년 현재 아래와 같은 구성을 갖추었다. 처음부터 이런 구성을 그려놓고 차근차근 갖춰 나간 것은 아니었다. 2016년 봄, 알리 클라우드에 3대의 리눅스 서버를 구매해서 1대에 대충 스테이징 환경과 각종 관리 툴을 세팅하고 2대 서버에 운영을 위한 최소한의 구성만 갖춘 채 첫 번째 기능을 출시했다. 매번 필요할 때마다 점진적으로 아키텍처를 개선해 나갔고, 4년이 지난 지금 꽤 그럴싸한(?) 모양을 갖추게 되었다. 지금 우리가 갖추고 있는 기술 셋을 소개해본다....

어제 글쓰기 흥미 [1] 를 자극하는 글 이 올라왔다. 조금 더 정확하게 말하면 글에서 인용한 이미지가 내 시선을 잡아 끌어 여러 가지 생각을 만들도록 했다. 그래서 아래 이미지에 기초해 주관적인 감상을 쓴다. 빙산의 일각을 비교해보자 그림이 주는 시각적 흡수가 오해일 수 있어 오류를 줄이려 원문을 찾아보았으나 원하는 설명은 없었다. 후에 확인을 하면 고치기로 하고 가정속에서 글을 써보자. 그림을 그린 이가 비교하려는 두 개의 빙산 즉, On-Premise와 Cloud Computing 이라는 묵직한 결정에 대해서 드러난 부분의 크기를 일부러 같은 사이즈로 그렸을까? 알 수 없다. 스스로 그리는 사람이라고 생각하고 상상해보자. 그러면, 그린 이의 의도를 짐작...

아침에 출근했더니 동료 가 나에게 링크 를 하나 던지며 이렇게 말했다. 위 블로그가 어제 말한 오퍼레이션 캐쉬 설명하는것 같은데 한번 검토해주실수있을까요? Why duplication isn’t always a bad thing in micro-services CTO님이 데이터 중복이 필요할 때가 있다고 설파하던 기억이 난다. 그 당시 대부분의 개발자들이 못알아듣는 눈치였는데, 역시 사람들이 배워서 써먹는 데에는 자기만의 시간이 있다. 귀로 듣거나 책으로만 읽어서는 알 수 없고, 자기 삶에서 그 장면을 만나야 한다. 반갑게도...

"이 글은 책을 소개하는 글입니다. 과도한 책 광고가 포함될 수 있습니다" 번역이라는 어두컴컴한 동굴을 빠져나와 출간을 앞두고 있습니다. 책에 대한 소개보다는 "번역"이라는 일을 시작하게된 개인적인 경험을 풀어써 보고자 합니다. 2010년... 때는 바야흐로 2010년. 팀을 이끌던 선배가 "질질 끌던" 번역 작업을 이제 마무리해야 한다며 리뷰를 부탁했습니다. 그 책은 켄 슈와버가 쓴 " 엔터프라이즈 스크럼 "이었습니다. 번역본 리뷰라는 것이 원서는 보지 않은 채, 번역된 초고를 읽으면서 어색한 문장이나 단어들, 오탈자를 제안하는 일이라는 것도 그때 처음 알았습니다. 그리고 번역본 초고가 원서 없이는 그 내용을 이해하는 것이 어려운 존재라는 것도 그때 알았습니다. 결국 리뷰를 하면서도 원서를 뒤적이며 꽤나 열심히 제안을 많이 해 드렸습니다. 그때 저의 성실함을 눈여겨 보신 선배가.......

이전 포스팅 ‘ 테스트 용이성(Testability) 향상을 위한 DI(Dependency Injection) ’에서 이어지는 내용이다. 종속성 문제 테스트 코드 없이 개발할 때는 잘 인지하지 못하다가 테스트 코드를 넣으려고 할 때 만나는 문제 중 하나로 종속성 문제가 있다. 테스트 환경에서 특정 객체 하나를 생성하기 위해서 너무 많은 객체가 필요해지는 상황과 특정 객체가 내부적으로 다른 객체를 직접 생성하는 상황이 그것이다. 이런 상황은 몇 가지 방법으로 개선을 할 수 있다....

[원본글] https://ericygkim.wordpress.com/2019/07/11/aws-ebselastic-block-storage-의-비용-최적화/ 애플리케이션 개발 후 AWS에 애플리케이션을 설치할 때 성능, 가용성, 확장성, 비용, 서비스 특성등 많은 요구사항들을 고려하여 복잡한 고민을 거쳐 EC2 인스턴스 사이즈등  AWS 자원들을 선택하게 됩니다. 그 중 중요한 요소 중 하나가 EC2인스턴스나 RDS에 연결되는 스토리지인 EBS(Elastic Block Storage)를 선택하는 일인데, 성능 및 비용까지 고려해서 선택하는 과정은 많은 고민을 할 수 밖에 없습니다.  EBS 볼륨의 크기를 정하는 것도 중요하지만 그것보다 더 중요한 것은 EBS 볼륨의 종류를 선택하고 성능과 비용 최적화 하는 것입니다. 얼마나 빠른 EBS 볼륨을 선택하는냐에 따라 애플리케이션, 데이터베이스의 성능에 큰 영향을 미치게 됩니다. 또한 EBS 볼륨의 유형에 따라 비용이 크게 달라집니다.  그러므로 요구되는 성능과 비용을 고려하여 적절한 스토리지 유형과 크기를 현명하게 선택하여야 합니다. 이와 관련된 기본 지식과 약간의 노하우를 공유할까 합니다....