학창 시절엔 ‘선생님’께서 정해놓으신 커리큘럼에 따라가기만 하면 큰 문제 없이 지식을 학습할 수 있었다. 거기에 주기적으로 치르는 시험을 통해 ‘점수’라는 평가 기준으로 얼마나 잘 성장했나를 검사하기도 한다. 졸업 후 어렵게 어렵게 취업에 성공을 하여 ‘신입 개발자’라는 배지를 달고 회사에 첫 출근. 그렇게 n 년이 지난 지금과 라떼 시절(?)을 비교해 보며 과연 ‘학습’에 대한 열정 그래프가 아직도 우상향 중인가? 하는 질문엔 일단 단전부터 올라오는 깊은 한숨과 함게 이상하게도 앞이 캄캄해진다.

　배워야 할게 너무 많다. 아니 그보다 배운 것을 이제 활용해야지 싶으면 또 새로운 기술이 등장한다. 그렇게 매너리즘에 빠지고. 거기다 회사일이 바쁘다는 핑계로 자기계발을 멈추다 보면 남들보다 뒤처진다는 생각에 괜히 자괴감이 들어 우울해 지곤 한다. (코로나 블루 때문만은 아니겠지…) 그 가운데 회사에는 정말 좋은 선배님들도 많고 멘토-멘티 관계를 잘 활용하면 충분히, 잘, 올바른 길로 성장할 수 있을 것이라 생각한다. 하지만 그렇게 누군가에게 ‘의존’만 하다 그 대상이 없어진다든지 심지어 그런 대상조차 없을 경우에는 어떻게 해야 할까? 점점 기술은 발전하고 배워야 할 것들은 홍수처럼 넘쳐흐르고 있는 가운데 ‘회사원’에서 나아가 ‘개발자’로써 성장을 하기 위해서는 어떠한 방법이 있을까?

　이번 포스팅에서는 개발자로 살아가면서 성장하기 위한즉, 자기계발의 ‘방법’에 대해 이야기해보려 한다. 이것이 정답이다 하는 은 탄환을 소개하려는 것은 아니다. 특히 개발자로서의 생을 마감(?) 할 때까지는 계속 배워야 하는 숙명과도 같은 직업이기에 첫 단추를 잘 끼워서 갑작스러운 기술의 변화에 일희일비 하지 않고 스펀지처럼 무엇이든 흡수하는. 말랑말랑한 정신을 갖기 위함이라고나 할까.

블로그

　개발자가 글도 써야 하나?라는 질문에는 필자가 예전에 정리해둔 개발하기 바쁜데 글까지 쓰라고? (글쓰는 개발자가 되자.)라는 글을 참고해봐도 좋을 것 같다. 해당 포스팅에서 수차례 강조하였지만 그만큼 개발자에게는 특히나 글쓰기가 중요하고 필요하다. 글을 꼭 ‘잘’써야 한다는 부담을 가질 필요는 없다. (필자도 그렇게 잘 쓰는 편은 아니다…) 다만 무언가를 기록하고 정리하고 자신만의 기준에 맞추어 재 정리하는 습관을 기르다 보면 이러한 생각들이 개발을 할 때에도 도움이 상당히 되었기 때문이다.

　복잡한 구조가 필요로 하는 개발을 해야 한다고 가정해보자. 연동하는 시스템도 많고 정말 다양한 요구 사항을 하나의 시스템에서 구현을 해야 할 경우 보통 개발을 하기에 앞서 ‘설계’라는 단계를 거치기 마련이다. 그때 글쓰기를 했을 때의 습관(스킬?)을 적용해 보면 요구 사항들 중에 중요한 feature 기준으로 정리를 하게 되고, 각 이해관계자들에게 정리한 부분을 공유하며 예외 상황을 보다 빠르게 확인할 수도 있다. 심지어 코드 레벨에서도 지난밤에 야식으로 먹은 라면 면발처럼 꼬여있는 부분들을 보다 개발하기 편하고 유지 보수가 용이하게 구조를 변경하는 ‘정리’의 습관 또한 글쓰기를 통해서 수련을 할 수 있다. 이러한 ‘꼼꼼함’을 기르는 데에는 글쓰기만 한 게 없다고 생각한다.

　우리는 다양한 개발 언어로 코딩을 하곤 한다. 왜 읽기좋은 코드가 좋은 코드라는 책이 있듯이 결국 코딩 또한 커뮤니케이션이 일종이라 생각한다. 내가 생각하는 로직을 개발 언어로 코딩을 해야 하는 상황이면, 결국 내가 생각하는 로직이 명료하고 정리가 잘 된 상태에서야 코드 또한 소위 ‘읽기 좋은 코드’가 되지 않을까 싶다.

　블로그를 시작할 때 어디서부터 시작해야 하나 막막하다면, 오늘의 배운 내용 (개발자들 사이에서 유행처럼 번지고 있는 TIL에 대해서 정리해 보는 것부터 추천한다. 경력이 1년 차여도 10년 차여도 개발을 하다 보면 새로운 것을 발견하기 마련이다. 그렇게 조금씩 적절한 블로그 플랫폼에 정리를 해 나가다 보면 어느새 자신만의 개발 히스토리가 만들어지고, 나아가 글쓰기가 전해주는 긍정적인 효과를 만끽하리라 자부한다.

　한동안 글을 쓰지 않았다. 글을 쓰지 않은 것일까 쓰지 못한 것일까. 이런저런 이유로 번아웃 늪에 빠져버려 아무것도 하기 싫어서라는 핑계가 어울릴 수도 있겠다만. 요즘 들어 더욱더 무기력함이 극도로 뿜뿜대는 가운데 문득, 개발자로써 얼마나 잘 지내왔는가 뒤를 돌아보고 싶었다. 앞만 보고 달리는 것보다 내 생각과 내 호흡을 점검하는 것 또한 중요하다고 생각했기에 당분간은 더 나은 개발자가 되기 위한 여러 가지 주제로 글을 써보려 한다. 이름하여 그런 개발자로 괜찮은가 XX 편

어디까지나 필자의 생각에 대해 적는 것일 뿐 내용이 잘못되었을 수도 있다. 즉, 정답이 아니라는 이야기. 필자의 이러한 포스팅으로 이 글을 읽는 여러분들도 자신만의 가치관을 정립해보는 기회가 되고 나아가 모두가 더 나은 개발자로 한걸음 올라서는 아름다운 세상을 꿈꾸는 마음으로 작은 날갯짓을 해본다.

　개발자로 살아가는 데 있어 가장 중요한 게 무엇일까? 물론 개발할 수 있는 기술이 가장 중요하겠지만 몇 년 전부터 기술의 발전이 급변하는 세상 속에서 과연 기술만이 중요할까? 기술만 잘 알고 있으면 복잡하게 꼬인 스파게티 면 같은 문제 많은 코드를 술술 풀어헤치고, 언제 어디서든 개발자로써 행복한 삶을 영유할 수 있을까?

　여러 가지 중요한 요소들 중 가장 첫 번째로 떠오르는 키워드는 바로 문화(Culture)가 아닐까 싶다. 그럼 왜 문화가 개발자에게 중요하고 어떤 식으로 문화를 만들어 가는 게 좋을지에 대해 정리해보고자 한다.

　개발자라는 직업을 가지고 있는 분들 중에 프리랜서나 1인 스타트업을 운영하는 분들은 제외하고. 대부분의 사람들은 여러 명과 함께 공동의 목표를 달성하기 위한 “팀"이라는 단위에 소속되어 개발을 하고 있다. 야근을 매일 밥 먹듯이 하는 조직도 있을 테고 이른바 워라벨을 잘 지키며 듣기만 해도 반가운 소리인 “칼퇴"를 밥 먹듯이 하는 조직도 있을 테고. 여기서 말하고자 함은 이러한 야근 vs 칼퇴처럼 “근무 시간의 양"에 대해 이야기하려는 건 아니다. 회사, 더 깊게는 팀 내에서 어떤 문화 안에서 개발자로 살아가고 있는지에 대해 이야기하려 한다.

코드리뷰

　팀에 속해서 개발을 하다 보면 같은 코드를 동시에 작업하곤 한다. 그래서 형상관리 도구 (요즘 git 을 안 쓰는 곳이 없을 정도…)를 사용해서 동시에 개발을 진행해도 전혀 무리가 없을 정도인데 결국 작업한 결과물을 한 곳으로 병합 (merge) 해야 하는 시점이 오기 마련이고 그때엔 (온라인/오프라인) 코드 리뷰를 하게 된다. 어떠한 사연으로 코드 리뷰 없이 빨리 merge 해야 하는 건 이해되지만 가급적 한 명 이상의 리뷰어가 승인을 한 뒤에 merge 가 돼야 한다고 생각한다. (pullRequest를 단순 merge 용으로 사용하는 건 정말 잘못된 방법 중 하나) 중복된 코드를 만들었거나 작업자가 예상하지 못한 부분들을 릴리스 전에 서로 이야기해보면서 버그를 수정하거나 팀 컨벤션, 설계/구조를 더 효율적으로 가져갈 수 있는 절호의 찬스.

　여기서 중요한 포인트는 리뷰를 받는 ‘리뷰이’ 와 리뷰를 해주는 ‘리뷰어’들의 문화적인 측면에서 생각을 해볼 필요가 있다.

• 리뷰이(Reviewee)
  • 리뷰어의 소중한 시간을 할애해서 자신의 코드가 이상이 없는지에 대한 ‘도움’을 요청하는 것이기 때문에 최대한 설명을 잘 적어서 리뷰하는 데 도움을 줄 수 있어야 한다.
  • 작업을 하다 보면 한 번에 몰아서 코드 리뷰를 받는 경우가 대부분이지만 개발 생산성 측면과 코드 리뷰 시간을 줄이는 측면에서는 최대한 작은 단위로 리뷰를 요청해야 한다.
  • 리뷰가 진행이 되지 못하여 다음 작업 또한 진행을 못하는 경우가 생기는 것을 방지하기 위해 최대한 코드 리뷰 받는 부분과 의존성이 없도록 작업이 돼야 하며 그도 아니라면 정중하게 리뷰어에게 ‘부탁’을 해야 한다. (요청 이 아니라는 점!)
  • 리뷰어의 리뷰는 “지적” 이 아니라 “함께 작업하는 코드에 대한 조언"으로 받아들여야 한다. 혹 리뷰 내용이 자신의 생각과 다르다면 토론을 통해 합의점을 찾도록 해야 한다. (무조건 리뷰어가 리뷰했다고 기계적으로 고치는 것 또한 잘못된 부분)
• 리뷰어(Reviewer)
  • 리뷰이는 당신의 한마디를 간절하게 기다리고 있을 수도 있으니 최대한 정성껏 리뷰를 해주자.
  • 온라인 코드 리뷰를 하게 된다면 “텍스트"라는 제한적인 상황에서 최대한 유연한 멘트로 코드 리뷰를 해야 한다. (자칫 잘못하다간 서로 오해가 있을 수 있으니…)

코드 리뷰 관련된 문화에 대한 내용들은 잠깐만 검색해봐도 훌륭한 포스팅들이 나오니 참고해봐도 좋을 것 같다. Line | 효과적인 코드리뷰를 위해서 Kakao | 코드 리뷰, 어디까지 해봤니? Jandi | 코드리뷰, 이렇게 하고 있습니다.

웹 어플리케이션에서 필터를 사용하면 중복으로 처리되는 내용을 한곳에서 처리할 수 있다거나 서비스의 다양한 니즈를 충족시키기에 안성맞춤인 장치인것 같다. 필터란 무엇인가 에 대한 내용은 워낙에 다른 블로그나 공식 도큐먼트에서 자세하게 그리고 다양하게 설명하고 있기에 기본 개념에 대해서는 설명하지 않도록 하려 한다. 이번 포스팅에서는 스프링 부트를 사용하면서 어노테이션이라는 간편함에 취해(?) “돌격 앞으로, 닥공” 의 자세로 개발을 하려했던 필자를 보고 “반성"의 자세로 필터를 등록하는 방법에 대해 명확하게 정리를 하고자 한다. 마지막으로는 아주 간단하면서도 엄청나게 위험한 필터 설정 사례에 대해서도 짚고 넘어가보자. 그냥 넘어가면 아쉬우니, 한번이라도 ‘spring’ 이라는 framework 를 접해본 사람이라면 봤을법한 그림을 첨부하는것으로 필터란 무엇인가 에 대한 설명을 대신하는게 좋겠다.

방법을 설명하기 전에 동일하게 사용될 필터와 컨트롤러 코드를 보면 다음과 같다.

• 필터

@Slf4j
public class MyFilter implements Filter {

	@Override
	public void init(FilterConfig filterConfig) throws ServletException {
		log.info("init MyFilter");
	}

	@Override
	public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)
		throws IOException, ServletException {
		log.info("doFilter MyFilter, uri : {}", ((HttpServletRequest)servletRequest).getRequestURI());
		filterChain.doFilter(servletRequest, servletResponse);
	}

	@Override
	public void destroy() {
		log.info("destroy MyFilter");
	}
}

• 테스트 할 컨트롤러

@Slf4j
@RestController
public class SampleController {

	@GetMapping("/test")
	public String test() {
		return "test";
	}

	@GetMapping("/filtered/test")
	public String filteredTest() {
		return "filtered";
	}
}

방법 1 : FilterRegistrationBean

아주 간단하게, 일반 url 하나와 필터에 적용할 url 두개를 만들고 설정하려 한다. FilterRegistrationBean 을 이용해서 위에서 만들었던 필터를 아래처럼 등록해보자.

@SpringBootApplication
public class Method1Application {

	public static void main(String[] args) {
		SpringApplication.run(Method1Application.class, args);
	}

	@Bean
	public FilterRegistrationBean setFilterRegistration() {
		FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new MyFilter());
		// filterRegistrationBean.setUrlPatterns(Collections.singletonList("/filtered/*")); // list 를 받는 메소드
		filterRegistrationBean.addUrlPatterns("/filtered/*"); // string 여러개를 가변인자로 받는 메소드
		return filterRegistrationBean;
	}
}

위 주석에도 적었지만 filterRegistrationBean 의 “setUrlPatterns” 와 “addUrlPatterns” 의 차이는 별거 없다. list 자체를 받을건지 아니면 가변인자로 계속 추가 할것인지. 이렇게 되면 “/filtered/“으로 “시작"하는 패턴의 url의 요청이 오게 되면 등록한 필터를 통과하게 된다.

• 실행 : 필터 생성

 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.2.6.RELEASE)

2020-04-06 23:45:01.225  INFO 14672 --- [           main] c.t.s.method1.Method1Application         : No active profile set, falling back to default profiles: default
2020-04-06 23:45:02.153  INFO 14672 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2020-04-06 23:45:02.168  INFO 14672 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2020-04-06 23:45:02.168  INFO 14672 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.33]
2020-04-06 23:45:02.361  INFO 14672 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2020-04-06 23:45:02.362 DEBUG 14672 --- [           main] o.s.web.context.ContextLoader            : Published root WebApplicationContext as ServletContext attribute with name [org.springframework.web.context.WebApplicationContext.ROOT]
2020-04-06 23:45:02.362  INFO 14672 --- [           main] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 1082 ms
2020-04-06 23:45:02.391 DEBUG 14672 --- [           main] o.s.b.w.s.ServletContextInitializerBeans : Mapping filters: filterRegistrationBean urls=[/filtered/*] order=2147483647, characterEncodingFilter urls=[/*] order=-2147483648, formContentFilter urls=[/*] order=-9900, requestContextFilter urls=[/*] order=-105
2020-04-06 23:45:02.391 DEBUG 14672 --- [           main] o.s.b.w.s.ServletContextInitializerBeans : Mapping servlets: dispatcherServlet urls=[/]
2020-04-06 23:45:02.409 DEBUG 14672 --- [           main] o.s.b.w.s.f.OrderedRequestContextFilter  : Filter 'requestContextFilter' configured for use
2020-04-06 23:45:02.409 DEBUG 14672 --- [           main] s.b.w.s.f.OrderedCharacterEncodingFilter : Filter 'characterEncodingFilter' configured for use

// 필터가 생성 되었다!
2020-04-06 23:45:02.410  INFO 14672 --- [           main] c.t.springbootfilter.method1.MyFilter    : init MyFilter

2020-04-06 23:45:02.410 DEBUG 14672 --- [           main] o.s.b.w.s.f.OrderedFormContentFilter     : Filter 'formContentFilter' configured for use
2020-04-06 23:45:02.544  INFO 14672 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'

• 일반 url

2020-04-06 23:45:27.526 DEBUG 14672 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : GET "/test", parameters={}
2020-04-06 23:45:27.528 DEBUG 14672 --- [nio-8080-exec-1] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.taetaetae.springbootfilter.method1.SampleController#test()
2020-04-06 23:45:27.548 DEBUG 14672 --- [nio-8080-exec-1] m.m.a.RequestResponseBodyMethodProcessor : Using 'text/html', given [text/html, application/xhtml+xml, image/webp, image/apng, application/xml;q=0.9, application/signed-exchange;v=b3;q=0.9, */*;q=0.8] and supported [text/plain, */*, text/plain, */*, application/json, application/*+json, application/json, application/*+json]
2020-04-06 23:45:27.548 DEBUG 14672 --- [nio-8080-exec-1] m.m.a.RequestResponseBodyMethodProcessor : Writing ["test"]
2020-04-06 23:45:27.555 DEBUG 14672 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed 200 OK

• 필터링 url

// 필터에 들어온것 확인!
2020-04-06 23:45:37.455  INFO 14672 --- [nio-8080-exec-2] c.t.springbootfilter.method1.MyFilter    : doFilter MyFilter, uri : /filtered/test

2020-04-06 23:45:37.456 DEBUG 14672 --- [nio-8080-exec-2] o.s.web.servlet.DispatcherServlet        : GET "/filtered/test", parameters={}
2020-04-06 23:45:37.456 DEBUG 14672 --- [nio-8080-exec-2] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.taetaetae.springbootfilter.method1.SampleController#filteredTest()
2020-04-06 23:45:37.457 DEBUG 14672 --- [nio-8080-exec-2] m.m.a.RequestResponseBodyMethodProcessor : Using 'text/html', given [text/html, application/xhtml+xml, image/webp, image/apng, application/xml;q=0.9, application/signed-exchange;v=b3;q=0.9, */*;q=0.8] and supported [text/plain, */*, text/plain, */*, application/json, application/*+json, application/json, application/*+json]
2020-04-06 23:45:37.457 DEBUG 14672 --- [nio-8080-exec-2] m.m.a.RequestResponseBodyMethodProcessor : Writing ["filtered"]
2020-04-06 23:45:37.459 DEBUG 14672 --- [nio-8080-exec-2] o.s.web.servlet.DispatcherServlet        : Completed 200 OK

방법 2 : @WebFilter + @ServletComponentScan

@ServletComponentScan 어노테이션을 @Configuration 어노테이션이 설정되어 있는곳에 걸어준 다음 위에서 설정한 필터에 @WebFilter 어노테이션을 설정해주면 아주 간단하게 끝이 난다.

지난 포스팅에서는 Retryable 를 활용해서 간헐적인 네트워크 오류를 “재시도"를 함으로써 아주 간단하면서도 강력하게 해결할 수 있는 방법에 대해 알아보았다. 실제로 필자가 운영하는 서비스 에서도 Retryable 를 이용하기 전과 후를 비교해보면 간헐적인 네트워크 오류의 빈도수가 확실히 줄어든것을 확인할 수 있었다.

이렇게 “재시도"를 해서 요청했을때 성공 응답을 받을 경우엔 문제가 안되지만 네트워크 오류가 아닌 실제로 호출을 받는 해당 서버에서 문제가 발생했다면 어떨까? 예컨대, 해당 서버에서 DB를 조회하는 API를 호출한다고 가정했을때 DB 자체에서 어떠한 오류가 난다면. 이런 경우는 단순히 “재시도"로 해결할 수 없는 문제다.

물론 Retryable 의 Recover 어노테이션을 활용했기 때문에 클라이언트 즉, 사용자에게는 오류응답이 발생을 안했겠지만 호출 받는 서버 자체에서의 에러가 발생하는데 이런식의 재시도를 계속 시도한다면 호출 받는 서버 입장에서는 이 “재시도” request 또한 “부하” 로 받게 되고 결국 2차, 3차 장애가 이어질 수 밖에 없다.

기존 한덩어리로 관리되던 Monolithic Architecture 에서는 자체적으로 관리하기 때문에 이러한 에러 컨트롤 또한 자체적으로 관리를 할 수 있지만, 모듈이 모듈을 호출하게 되는 Microservice Architecture 로 바뀌다보니 이런 “연쇄 장애(?)” 같은 현상이 발생하게 되는 경우가 있다. 호출을 받는 서버의 상태가 이상하면 (에러응답이 지정한 임계치를 벗어나는 수준으로 맞춰서 발생한다면) 적절하게 호출을 하지 않고 (2차 장애를 내지 않도록 호출 자체를 하지 않고) 어느정도 기다리다 클라이언트에게는 에러응답이 아닌 미리 정해둔 응답을 내려주고, 에러가 복구되면 다시 호출하도록 하는 “무언가” 가 필요하지 않을까?

지난 포스팅에 이어 이번 포스팅 에서는 그 “무언가”. 즉, Circuit-breaker 에 대해 알아보고 직접 구현 및 테스트 하면서 돌아가는 원리에 대해 이해 해보고자 한다. 막상 개념은 머릿속에 있지만 직접 구현해보지 않으면 내것이 아니기에, 직접 구현하고 설정값들을 바꿔가면서 언젠가 필요한 순간에 꺼내서 사용할 수 있는 나만의 “무기” 를 만들어 보고자 한다.

Circuit breaker ?

(한국 발음으로) 서킷브레이커를 검색해보면 주식시장 관련된 내용이 꽤 나온다. (앗, 잠깐 눈물좀…) 서킷 브레이커. 이 용어는 다양한 곳에서 사용되는데 “회로 차단기” 라고도 검색이 된다. 해당 내용을 발췌해보면 다음과 같다.

회로 차단기는 전기 회로에서 과부하가 걸리거나 단락으로 인한 피해를 막기 위해 자동으로 회로를 정지시키는 장치이다. 과부하 차단기와 누전 차단기로 나뉜다. 퓨즈와 다른 점은, 차단기는 어느 정도 시간이 지난 뒤, 원래의 기능이 동작하도록 복귀된다.

여기서 가장 중요한 문장은 “피해를 막기 위해 자동으로 회로를 정지시키는”, “어느정도 시간이 지난뒤 원래의 기능이 동작하도록 복귀된다” 이 부분이 가장 중요한 것 같다. 시스템 구성이 점점 Microservice Architecture 로 바뀌어 가는 시점에서 이러한 “서킷브레이커"는 자동으로 모듈간의 호출 에러를 감지하고 위에서 말한 “연쇄 장애"를 사전에 막을 수 있는 아주 중요한 기능이라 생각된다.

“circuit breaker spring” 이라는 키워드로 검색해보면 이러한 고민을 이미 Netflix 라는 회사에서 Hystrix 라는 이름으로 개발이 된것을 알 수 있다. 이 core 모듈을 Spring 에서 한번 더 감싸서 Spring Boot 에서 사용하기 좋게 spring-cloud-starter-netflix-hystrix 라는 이름으로 만들어 둔 것이 있는데 이것을 활용해 보기로 하자.

구현

늘 그랬듯이 SpringBoot 프로젝트를 만들고 테스트할 Controller 를 만들어 주자. 원래대로라면 호출을 하는 모듈과 호출을 받는 모듈, 2개의 모듈을 만들어서 테스트 해야 하지만 편의를 위해 하나의 모듈에서 두개의 Controller 을 만들고 테스트 해보는 것으로 하자.

@RestController
public class MainController {

	private final MainService mainService;

	@GetMapping("index")
	public String index(String key){
		return mainService.getResult(key);
	}

	public MainController(MainService mainService) {
		this.mainService = mainService;
	}
}

@Slf4j
@Service
public class MainService {

	private RestTemplate restTemplate;

	public String getResult(String key) {
		return restTemplate.getForObject("http://localhost:8080/target?key=" + key, String.class);
	}

	public MainService(RestTemplate restTemplate) {
		this.restTemplate = restTemplate;
	}
}


@Slf4j
@RestController
public class TargetContoller {

	@GetMapping("/target")
	public String target(String key) {
		log.info("input key : {}", key);
		if (!StringUtils.equals("taetaetae", key)) {
			throw new RuntimeException("Invalid key");
		}
		return "target";
	}
}

사실 설명할 부분도 없긴 하지만 그래도 적어보면, /index라는 주소와 key라는 파라미터로 요청을 하면 /target이라는 컨트롤러가 받아서 key 값에 따라 정상 응답을 줄지 아니면 에러를 응답하는 코드이다. 목표로 하는건, 파라미터를 일부러 잘못줘서 에러를 발생하는데 Hystrix를 적용해서 설정한 기준에 따라 응답은 미리 정해둔 응답을, TargetContoller에서는 잠시동안 요청을 받지 않다가 조금있다가 다시 호출하면 요청을 받는 시나리오로 작성해 보려 한다. 우선 필요한 dependency를 추가해준다.

개발자로서의 커리어는 정말 다양하지만 필자가 보고 들은 경험을 아주 일반화 시켜 정리해 보자면 다음과 같다.

처음엔 전공/비전공을 불문하고 신입으로 개발을 시작하여 다양한 개발 경험을 하게 된다. 사수에게 혼나기도 해보고 또는 혼내줄 사수가 없어 혼자 끙끙 밤도 새보고, 다크서클과 거북목을 겸비한 이른바 “삽질"을 하며 고통의 시절을 보내고 나면 어느덧 승진(진급)을 하며 일정 규모의 “팀장(혹은 관리자)“이 된다. 그게 자의든 타의든. 개발자는 다소 “기술"이라는 특수성을 가지고 있지만 어느 직군이든 간에 이러한 커리어 패스의 흐름은 매우 비슷하게 흘러가는 것 같다. 적어도 필자가 보고 들은 것만 보면 말이다. (예외 케이스는 항상 있지만…)

하루는 팀장님과의 면담 중에 “이제는 마냥 눈앞에 있는 개발만 할 것이 아니다. 기술을 좀 더 깊게 들여다보는 자리와 사람을 관리하며 주어진 과제를 진행하는 자리, 둘 중 선택해야 하는 시기가 온 것 같다. 더 높고 더 멀리, 그리고 더 넓게 볼 줄 알아야 한다.“라는 말씀을 듣게 된다. 어느덧 “그 시점"이 다가온 것이다. 개인적으로 필자는 팀장님이 말씀하신 두 가지 중 전자에 좀 더 가깝게 다가가고 싶다. 그만큼 오래오래 “실무 개발"을 하고 싶고, 또 그만큼 개발이 재밌기 때문이다. 아직도 눈앞의 문제를 해결하기 위해 개발하며 시간 가는 줄 모를 만큼 밤을 새우는 게 재미있는 걸 보면…

어느 날 SNS 피드에 개발 관련된 소식들을 받아보다가 개발 7년차. 매니저 1일차라는 제목의 책을 보게 된다. 뭐야, 이거 내 이야기 아니야? 하며 귀신에 홀린 듯 사서 읽어보려는 찰나, 마침 한빛미디어 에서 주최하는 나는 리뷰어다 라는 이벤트를 발견하게 된다. 결국 리뷰어에 당첨이 되고 운 좋게 해당 책을 받아볼 수 있었다. (이 책을 읽게 해준 한빛미디어 측에게 이 글로나마 감사의 인사를 전하고 싶다.)

이번 포스팅에서는 우선 책에 대한 리뷰를 간단히 적어보고 거기에 필자의 생각을 조금 더 얹어보고 싶다. 필자를 두고 만들어진 책 같아서 아직도 책 표지만 봐도 신기하고 설렌다. 일단 책 표지나 제목이 맘에 든 건 감출 수 없는 사실이다.

신입 혹은 주니어 개발자가 읽어봐도 좋을 책.

제목만 보면 이제 갓 팀장 혹은 매니저를 하게 되는 사람에게만 해당되는 책으로 보인다. 표지 상단에 “개발만 해왔던 내가, 어느 날 갑자기 ‘팀’을 맡았다!” 적혀있기도 했으니까. 하지만 책을 읽다 보면 꼭 그렇지마는 않다. 멘토링을 할 때엔 멘토와 멘티 각자의 위치에서 어떤 자세로 서로를 맞이해야 하는 방법에 대해서도 알려주기도 하고 무작정 눈앞에 있는 기능 개발만을 하며 안갯속을 걷는 주니어 개발자가 미리 미래를 경험해보는 좋은 사례를 들어 알려주고 있기 때문이다.

꼭 누군가 혹은 무언가를 “관리"하는 입장이 아닌 “팀"이라는 공동체 사회, 특히 개발 팀에서 팀원들과 협력하는 방법론을 살펴보고 있고, 경력이 낮으면 안 보이는 부분들까지 마치 멀리 있는 것을 대신 망원경으로 보여주는 느낌이 들었다. 앞부분에는 “이 책을 읽는 방법"이라며 상황별로 읽는 챕터를 가이드 해주고 있지만 사실 어느 하나 중요하지 않을 내용이 없어서 처음부터 무언가에 홀린 듯 읽을 수밖에 없었고 선배님이 앞서 지나간 길을 올바르게 지나갈 수 있도록 가이드 해주는 느낌으로 중간중간 사례가 있어서 현업에 있어서 그런지 좀 더 쉽게 읽힐 수 있었다.

다 읽고서야 알아차린 번역서(?)라는 사실.

어떠한 XX 기술 서적에서는 Method를 ‘방법’, Overriding 을 ‘과적’이라고 번역한 책들이 있는가 반면, 이 책은 읽는 내내 국내 어떤 분이 쓰신 거라 생각하고 읽어내려 갔지만 다 읽고 보니 외국에 어느 CTO가 쓴 책을 옮겨서 다시 써진 책이었다. 그만큼 전혀 특유의 번역 느낌(?)은 없었고 오히려 한국 문화에 맞춰 다시 써진 건 아닐까 싶을 정도로 너무 술술 잘 읽혔다.

웹 어플리케이션을 만들면서 꼭 한번 쯤 만나게 되는 “RestTemplate”. 접근 가능한 외부 HTTP URL(보통 API)을 호출하는 방법중에 하나로 springframework 에서 제공해주는 모듈이다. 특히 큰 한덩어리로 관리되던 Monolithic Architecture 에서 요청을 하고(client) 응답을 주는(server) 즉, Endpoint가 작은 단위로 분리되는 Microservice Architecture 로 바뀌면서 각 서비스간 호출방식이 HTTP 일 경우 자주 사용되곤 하는 것 같다. (webClient 등 다른 여러 호출 방법들이 있다.) 만약, 요청을 하는 클라이언트 입장에서 응답을 주는 서버의 상태가 불안정 하다고 가정했을때, 어떤식으로 처리해야 할까? 예컨대, 요청 10번에 한번은 어떠한 이슈로 응답이 지연되거나 서버에러가 발생한다고 하면 클라이언트를 사용하는 사용자 입장에서는 간헐적인 오류응답에 답답함을 호소할 수도 있다. 그럼 잠시 눈을 감고 생각해보자. 가볍게 생각하면 아래처럼 아주 간단하게 “예외처리"를 이용할 수도 있다.

try {
	// http call
} catch (Exception e){
	// 서버에러가 아닌 약속된 에러응답을 리턴
}

하지만 이것도 정답이 아닐수 있는게, “간헐적인 오류"로 인해 사용자는 오류화면을 봐야하기 때문에 클라이언트에 대한 신뢰를 저버릴 수밖에 없다. 그럼 어떻게 해야할까? 여러가지 해결방법이 있겠지만 간단하면서도 강력하다고 생각되는 방법이 바로 “재시도” 라고 생각한다. 클라이언트를 사용하는 사용자가 눈치 못챌만큼 빠르게 재시도를 한다면 에러가 나도 다시한번 호출해서 성공할 수 있는 가능성이 높기 때문이다. (그치만 근본적인 원인은 해결해야…)

이번 포스팅에서는 RestTemplate 를 이용할때 “재시도” 할 수 있는 방법에 대해 알아보고자 한다. 아주 간단할지 모르지만 노력에 비해 효과가 상당하다고 생각하기 때문에 정리해 두고 싶었다.

Spring Retry

공식 Github에 소개를 빌리자면, Spring 어플리케이션에 대한 재시도 지원을 제공한다고 한다. 위에서 이야기 했던 “RestTemplate"과는 사실 무관하고, 이를 활용해서 재시도 하는 “RetryRestTemplate"를 구현해보려 하는것이다. 우선 이 “Spring-Retry"의 예제를 보면 아주 심플하게 사용할 수 있다. 우선 pom에 구현에 필요한 dependency 를 추가하고 아래 코드를 보자.

<dependency>
	<groupId>org.springframework.retry</groupId>
	<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-aop</artifactId>
</dependency>

@Configuration
@EnableRetry // 1
public class Application {

    @Bean
    public Service service() {
        return new Service();
    }

}

@Service
class Service {
    @Retryable(RemoteAccessException.class) // 2
    public void service() {
        // ... do something
    }
    @Recover // 3
    public void recover(RemoteAccessException e) {
       // ... panic
    }
}

1. @EnableRetry 어노테이션을 @Configuration을 지정한 클래스 중 하나에 추가한다.
2. 재시도 하려는 메소드에 @Retryable 어노테이션을 지정해준다.
3. 재시도가 완료되는 시점에서 실행하고 싶을때 선언하는 어노테이션, @Retryable 동일한 클래스에서 선언되어야 하고 return type 은 @Retryable을 지정한 메소드와 동일해야 한다.

Retry Rest Template

이렇게 springframework 에서 제공해주는 spring-retry 를 이용해서 이번 포스팅의 목표인 재시도를 하는 Retry Rest Template 를 구성해보자. 우선, RestTemplate 를 Bean 으로 등록하고, 위에서 이야기 한 어노테이션들로 구성해보자.

@EnableRetry
@Configuration
public class RetryableRestTemplateConfiguration {

	@Bean
	public RestTemplate retryableRestTemplate() {
		SimpleClientHttpRequestFactory clientHttpRequestFactory = new SimpleClientHttpRequestFactory(); // 1
		clientHttpRequestFactory.setReadTimeout(2000);
		clientHttpRequestFactory.setConnectTimeout(500);

		RestTemplate restTemplate = new RestTemplate(clientHttpRequestFactory) {
			@Override
			@Retryable(value = RestClientException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000)) // 2
			public <T> ResponseEntity<T> exchange(URI url, HttpMethod method, HttpEntity<?> requestEntity, Class<T> responseType)
				throws RestClientException {
				return super.exchange(url, method, requestEntity, responseType); 
			}

			@Recover
			public <T> ResponseEntity<String> exchangeRecover(RestClientException e) {
				return ResponseEntity.badRequest().body("bad request T.T"); // 3
			}
		};

		return restTemplate;
	}
}

1. SimpleClientHttpRequestFactory 를 만들고 각 타임아웃을 설정해준 다음 RestTemplate 파라미터로 넘겨준다.
2. 사용하는 곳에서 exchange 메소드를 이용할 것이므로 해당 메소드를 오버라이드 해준다. 먼저 해당 메소드에서 “RestClientException"이 발생할 경우 Retry 로직을 수행한다고 정해주고, 최대 시도는 3번, backoff 설정중 delay를 1000ms(1초)로 지정해서 재시도가 진행되도록 해준다.
3. 2 에서 지정한 재시도가 끝나면 (재시도를 전부 다 하면) 해당 메소드를 수행하게 되어있고, 임의로 응답에 지정한 문구를 넘겨준다.

이렇게 하고 실제로 사용하는 로직에서 일부러 잘못된 URL을 호출해 보도록 하자. 그리고서 로그를 자세히 보도록 application.properties 에 “debug=true” 설정을 해준다.