%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4

2022-09-22
스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브 서비스에 반영하였다. 이번 글은 오랜 세월의 흐름으로 서비스 의존성 그래프가 복잡해진 라이브 서비스를 리팩터링한 내용을 일반화하여 작은 예제로 만들어서 정리한다....
2022-09-02
나는 ‘ 개발자를 코칭하며 배운 7 가지 ’ 라는 제목의 글을 쓴 적이 있는데 내가 코칭한 대부분의 개발자들이 토로하는 고민이 있었다. 프론트를 해야 할지 백엔드를 해야 할지 잘 모르겠어요. 내 경험에 의하면 많은 이들이 자신에게 물어야 할 질문을 남에게 묻는다. 왜 그럴까? 자신이 무엇을 좋아하는지, 무엇을 하고 싶은지 잘 모르기 때문이다. 그래서 자신에게 해야 할 질문을 남에게 한다. 그렇지만 그 답답한 마음을 왜 모르겠는가. 그래서 나는 서부른 조언보다는 대화에서 스스로 힌트라도 찾을 수 있도록 충분히 들어 주는 편이다. 그럼에도 불구하고 ‘프론트냐 백엔드냐’를 고민하는 이들에게 작은 도움이라도 되길 바라는 마음으로 이 글을 쓴다....
2022-08-18
배경 최근에 읽은 ‘ 구글 엔지니어는 이렇게 일한다. ’에서 컴파일러 버전업에 대한 이야기가 나와서 예전에 작업했던 GCC 컴파일러 버전업에 대한 내용을 정리해본다. 몇 년 전 새로운 팀에 합류했을 때 서비스 중인 서버군들 중에서 C++ 구현된 서버군이 gcc 4.4.7을 사용하고 있었고, 컴파일러 버전이 낮아서 모던 C++의 시작인 C++ 11를 사용할 수 없었다. GCC 4.4.7은 C++ 0x까지 지원한다. C++ 11을 사용하려면 최소한 GCC 4.7 이상이 필요하다. 버전업 타깃은 CentOS 7 Base repo에 있는 GCC 4.8.5 버전으로 맞추고 진행했었다. 작업 당시 오랜 세월의 흔적으로 개발, 배포, 서비스 환경 등 각각 OS 버전이 달랐다. OS 버전이 다르다는 것은 OS가 기본적으로 가지고 있는 C 표준 라이브러리...
2022-08-16
마이크로서비스 아키텍처가 많이 보급 되면서 클라이언트와 서버 간의 인증 상태를 유지하는 기존의 전통적인 서버 세션 방식과는 다른  클라이드 사이드 세션인 JWT(JSON Web Token) 방식이 많이 활용되고 있습니다. 필자도 처음에는 "마이크로 서비스에서는 인증은 주로 JWT를 사용한다" 라는 의견에 공감하면서 그냥 생각없이 사용하고 있었는데 한번은 정리해야 할 필요성을 느껴 정리해볼까 합니다. 이번글에서는 기존의 세션 방식과 JWT Token 방식은 어떤  차이가 있으며 마이크로 서비스에서는 왜 JWT가 사용되는지, 보안적으로는 어떤 고려할 사항들은 어떤 것들이 있는지 알아 보겠습니다....
2022-08-11
나는 2020년 10월을 시작으로 지금까지 여러 명의 개발자들을 코칭하고 있다. 초보 코치로써 약 1년 5개월 동안 배운 것을 정리했다. 1. 코치는 그저 거들 뿐이다 함께 개발을 하면서 코칭을 하다보니 해결하기 어려운 문제를 만나면 내가 주도적으로 해결했다. 결과적으로 내게 의존성이 높아졌으며 어려운 문제가 생기면 나를 찾았다. 보다 본질적인 문제는 코치가 아닌 개발자 본인이 성장하지 못한다는 것이었다. 성장은 자신이 주도적으로 문제를 해결해 가며 겪는 수 많은 실수와 실패의 집합이다. 다른 사람이 문제를 해결해 버리면 단기적으로 좋을지 모르겠지만 장기적으로는 성장의 기회가 사라진다....
2022-04-18
요즘 라이브 서비스의 레거시 코드 리팩터링을 하고 있다. 흔히 가변 상태를 관리하는 Context 클래스가 레거시 코드에 있는 건 새삼스럽지 않았지만, 과도하게 사용하고 있어서 정리가 필요했다. 가변 상태 Context 사용 시 문제점 가변 상태를 가지는 Context 클래스가 2, 3개도 도 아니고 10개쯤 되면 과하다고 생각한다. 이렇게 많은 Context 클래스들이 서로 물고 물리는 종속성을 가지고 각기 다른 클래스에 넘기고, 넘겨받고, 가변 Context의 레퍼런스가 다양한 함수들로 넘겨져 전역 변수처럼 여기저기서 사용되면서 어딘가에서 A가 set을 하고 다른 곳에서는 B가 get을 하는 상황은 코드를 매우 읽기 어렵게 만들었다. 읽기 어렵다는 것은 Context를 수정할 때, 사용처를 모두 추적하는 것이 어렵고, 문제 발생 시 디버깅 역시 어렵다는 것이다.   다른 것보다 이걸 먼저 해결하기로 했다. 이 Context 클래스를 정리하는 리팩터링을 점진적으로 진행하여 총 10개에서 6개를 삭제하고 2개는 사이즈를 많이 줄였다. 프로덕션 코드에서 총 568라인을 삭제했다. 당연히 기능에 변화는 없다. Context를 정리하는 리팩터링이 일단락되어 ...
2022-03-27
나는 최근 몇 년 간 Golang(이하 Go)을 사용하고 있지만 이전에는 주로 Java로 개발했었다. Java는 오류를 Exception으로 다루며 오류가 발생하면 개발자가 별도 처리하지 않아도 Strack Trace를 출력한다. 아래 그림을 보자. C의 23줄에서 오류가 발생한 상황이다. Stack Trace로 표현하면 아래와 같다. 오류와 어떤 경로로 발생했는지 보여주는 것이다. C의 C-1 함수 23 줄에서 오류 발생 B의 B-1 함수가 C의 C-1 함수 호출 A가 B의 B-1 함수 호출 Go에서는 오류를 Error로 다룬다. 아쉽게도...
2021-12-13
자바 객체를 영속화하는 방법의 하나로 자바 직렬화를 사용할 수 있다. 단순하게는 Serializable 인터페이스를 구현하거나 더 확장성 있는 방법으로는 Externalizable 인터페이스를 구현하는 것을 선택할 수 있고, 자바 직렬화에 종속되지 않는 다른 방법을 선택할 수도 있다. 일단, Serializable 인터페이스를 구현한 클래스의 인스턴스가 외부 저장소에 영속화되면 호환성을 유지하면서 해당 클래스의 필드를 수정하기는 어렵다. ( https://docs.oracle.com/en/java/javase/11/docs/specs/serialization/version.html...
2021-12-12
최근 log4j의 보안 취약점이 크게 이슈가 되고 있습니다. 많은 개발자나 운영자들이 이 조치를 위해 정신이 없을것 같아 간단하게 글로 남겨 봅니다. log4j는 자바를 사용하는 많은 프로젝트에 사용되기 때문에 직접 개발한 코드 뿐만 아니라 자바 개발된 서버 사이드 솔루션들도 모두 점검을 해봐야 합니다. 일반적으로 가장 많이 사용되는 자바로 개발된 서버 사이드 솔루션은  대략 다음과 같습니다. Tomcat JBoss Jenkins ElasticSearch Hadoop Kafka Spark 등등 방화벽 안쪽에 있는 서버나 포트가 외부에 공개되지 않은 서버라도 모두 취약점의 대상이 될 수 있습니다. 이유는 다음과 같은 취약성 때문입니다....
2021-08-13
요즘은 프론트엔드, 백엔드 등으로 개발이 분업화 되었고 또한 최근 많은 곳에서 마이크로서비스 아키텍처 Microservice Architecture 를 도입하면서 하나의 언어가 아닌 여러 언어로 개발하는 것이 추세인 듯하다. 여러 언어로 개발하다 보면 테스트 커버리지와 코드 코드 정적 분석 Static program analysis 결과를 각각 보면 매우 불편한데 통합하여 한곳에서 볼 수 있으면 편할 것 이다. SonarSouce 에서 만든 SonarQube 는 코드를 분석하여 중복, 테스트 커버리지, 코드 복잡도, 버그, 보안 취약성 등을 보여주는 도구이다. 특히...
더보기