홈

기술 부채란? 기술 부채는 Ward Cunningham이 1992년도에 만든 표현이다. 오늘날 기술 부채 및 코드 부채는 개발 팀이 애플리케이션을 개발 시 빠른 코드를 작성하는 것을 선택할 때 발생한다. (일정에 쫓겨서 개발) 신속한 코드 전달은 프로젝트 완료일을 맞추는데 도움이 되고 이에 대한 기술 부채를 감내한다고 했을 때, 비지니스 관점에서는 문제가 없어 보일 순 있지만, 향후 부정적인 결과를 초래할 수 도 있다. 기술 부채를 발생시키기로 결정했다면 부정적인 결과가 생기는걸 고려해야 한다. 기술 부채는 처리하기가 복잡하고 특정 지표와 연결되어 있지 않다. 기술 부채를 해결하는데 필요한 정확한 자원을 추정하는...

얼마전 프로젝트 진행 시, RESTful의 엔드포인트에 대해서 문제가 생겼었다. 구현상에 문제는 없지만 Addressability를 보장해야 하는 DX관점에서의 문제였다. 지금이야 REST로 API를 만들어서 제공하지만, 상황에 따라 gRPC 혹은 GraphQL을 사용해야 할 경우도 생기기에 각 표준에 대해서 정리하고자 한다. 통신 방식의 비교 이미지 출처: https://www.sensedia.com/post/apis-rest-graphql-or-grpc-who-wins-this-game 기술별 특성 비교 이미지 출처: https://www.sensedia.com/post/apis-rest-graph...

서비스를 기획할 때는 UX(User Experience)관점에서 진행되는 경우가 많다. 오늘은 DX(Developer Experience)에 대해서 언급하고자 한다. 내가 하는 일이 개발자를 위한 제품을 만드는 것은 아니지만, 내부적으로 개발을 하게되면 어느 순간 다른 개발자가 조인하여 구현된 코드를 인계받아 업무를 진행하는 사례도 많기 때문에 DX 관점에서 개발을 진행할 필요성이 있어 보였다. 둘은 비슷해 보일 수 있다. DX에 대해서 정의하자면 “개발자를 위한 사용자 경험”이 아니다. DX는 기술 언어 및 도구를 이용해 사용자에 초점을 맞춘 UX의 확장이다. DX도 UX의 핵심 원칙을 따르지만 개발자가 기술...

오래된 어르신 시스템을 구조개선 준비 중이다. 예전에는 비즈니스 로직 대부분을 PL/SQL로 했는지, 자바단에는 비즈니스 로직이 거의 없는 상황이다. PL/SQL을 Java로 자동 변환을 해주는 Converting Tool이 있지 않을까? 하는 마음에 찾아서 테스트를 해보았다. (사람은 게으르다.) 솔루션 벤더사의 트릭에 속은 느낌이다. 대부분 업체들은 “PL/SQL Convert to Java” 문장으로 마케팅을 하고 있었다. 하지만, 지금 시점에 일반 Java만 사용하는 곳이 없기 때문에 일반 Java로 마이그레이션을 할 필요가 없는 것이었다. ORM으로의 마이그레이션 필요한 것이었다. 왜 PL/SQL을 마...

현실에서 마이크로 서비스 관련 설계를 진행하다 보면, 적합하지 않은 상황이 발생하곤 한다. 이런 상황에 대해서 언급하는 글(https://dzone.com/articles/chopping-the-monolith-the-demo)을 발견해서 내용을 작성한다. 저자는 전자 상거래 영역에서 몇 년간 일을 했다고 한다. 전자 상거래의 상당 부분이 가격 책정에 전념하고 있고 가격 책정 규칙은 매우 자주 변경된다고 한다. 특정 제품의 재고가 너무 많음 시즌 종료: 새 상품에 대한 물류 센터 공간을 확보해야 하기에, 가격을 낮춰서 판매한다. 연구에 따르면 마진을 낮추면 제품 판매가 증가하여 전반적으로 더 많은 수...

프로젝트를 준비하고 있다. DB Schema가 중요한 부분이지만 형상 관리가 되어 있지 않다. 사람에 의해서 관리가 되고 있는 실정이다. 소스 코드는 형상 관리를 하고 있지만 DB Schema는 형상 관리를 하고 있지 않기에 관련해서 정보를 찾아보았다. 데이터베이스에 대해서도 지속적인 통합이 필요하다. 본 글에서는 오픈소스 DB 형상 관리 툴인 Liquibase와 Flyway에 대해서 비교하고 bytebase에 대해서 언급하고자 한다. Liquibase와 Flyway의 유사점 Liquibase와 Flyway는 진화되는 데이터베이스 설계를 원칙으로 하기에 유사한 기능들이 많다. 일부 오픈소스이며 데이터베이스...

모놀리스 분석 대부분 현재 시스템을 잘 설명해주는 문서는 존재하지 않는다. 존재한다고 해도 현행화가 되어 있지 않기에, 오해의 여지가 발생하기도 한다. 상황이 어떻든 최소한 아래의 정보는 수집해야 한다. 애플리케이션의 기능 모듈 및 상호간의 관계 API 및 서비스 인터페이스 모듈에 대한 설명이 있는 논리 다이어그램 시스템 구성을 알 수 있는 물리 다이어그램 데이터 어떤 데이터를 다루는지 알 필요가 있다. 각 모듈별 어떤 데이터를 다루는지 추출을 해야 향후 마이크로서비스로 전환시 경계를 설정할 수 있다. 현황 파악 기능이 이미 외부에 존재하는 경우도 있다. 이 경우 외부 서비스를 재사용...

이쪽 업종에서 일하는 분들이라면 Monolith으로 구현되어 있는 레거시 시스템을 마이크로서비스로 마이그레이션 하고자 하는 Needs가 있을 것이다. 비즈니스를 분석해서 새롭게 만드는 것이 가장 좋은 방법이겠지만, 레거시와 병행해서 개선을 해야 할 상황도 존재하기에 새롭게 만드는 것이 여의치 않은 경우도 많을 것이다. 나도 레거시 시스템을 분석하면서 어떻게 구조 개선을 할 것인지에 대한 고민이 있고, 새롭게 코드를 짜던 기존 코드를 마이그레이션을 하던 가장 유리한 방식을 채택할 계획이다. 위 관점에서 Dzone에 도움이 되는 글이 있길래, 번역을 하였다. 모놀리스 아키텍처 모놀리스 애플리케이션은 복잡도가 ...