정확히 2018년 07월 12일 필자의 첫 토이 프로젝트인 ‘기술 블로그 구독 서비스’를 오픈하게 된다. 얼마나 많이 구독(가입) 하겠어 하는 생각이 부끄러울 만큼 6개월이 지나 구독자 수는 1,000명을 넘기고 1년이 지나 2,000명. 어느덧 달력을 보니 오늘이 정확하게 토이 프로젝트를 서비스한지 벌써 2년이 되는 날. 구독자 수는 어느덧 3,000명을 넘어선다. 뭔가 뿌듯하면서도 서비스를 좀 더 디벨롭 하지 못한 필자 자신을 돌아보니 괜히 마음이 무거워지고.

　지난 2년 동안을 돌이켜보며 서비스를 어떻게 운영해 왔는지, 그리고 토이 프로젝트가 필자에게 어떤 영향을 주었는지 되돌아보며 셀프 리뷰를 해 보고자 한다.

서비스 자체 평가

심플한 기능

　말 그대로 토이 프로젝트이기 때문에 기능 또한 아주 간단하다. awesome-devblog에서 제공하는 개인/단체 블로그들의 포스팅을 조회하여 어제 작성된 글들만 모아 발송한다. 거기에 주간 많이 클릭된 포스팅을 모아서 한 번 더 발송하는 기능까지. 추가적인 기능을 더 디벨롭 해야 하는데 아이디어가 없어서 인지 디벨롭 할 힘이 안 나서 인지 유지만 하고 있는 상태다.

서비스에 없어서는 안될 ‘로깅(Logging)’

　형식을 막론하고 컴퓨터로 돌아가는 모든 ‘프로그램’은 상황에 따라 미리 만들어 놓은 로직에 따라 움직이는 로봇에 불과하다. 물론 요즘에는 머신러닝이나 AI 같은 기술들로 컴퓨터가 스스로 학습하는 경우도 있지만 그 또한 미리 코딩을 통해 만들어진 부분들. 그렇기 때문에 2년이 지난 지금 이제까지 서비스가 어떻게 돌아갔는지를 확인하기 위해서는 사전에 준비해야 할 것이 있다. 그것은 바로 ‘로깅’. 서비스 투입 전부터 프론트부터 백엔드까지 다양한 로깅을 해서인지 2년이 지난 지금, 기록된 로그로 다양한 서비스 지표를 확인해 볼 수 있음에 다행이라 생각한다.

각종 지표

　먼저 봐야 할 지표는 당연히 가입/해지 추이. 드라마틱 한 선형 그래프는 아니지만 당연히(?) 해지 보다 가입이 더 많고 시간이 지날수록 어느 정도 꾸준하게 가입자가 들어오는 것을 보면 어떻게 알고 가입을 하러 오는지 신기할 따름이다. 하지만 마냥 신기해하지만 말고 해지하는 원인을 분석해야 할 필요가 있어 보인다. 아마도 수집하는 블로그들 중 간혹 개발과 관련되지 않는 글들이 종종 수집되어서 그런 것 같기도 하다.

　다음으로는 클릭수. 눈치가 빠른 분들은 이미 알고 있겠지만 이메일에서 클릭 시 서버에서 각종 로깅을 하고 넘어가게 된다. 그러다 보니 클릭 성향(?)에 대해 집계도 가능한데 아래 지표를 보면 오전 일과를 시작하면서 메일로 종합된 기술 블로그 들을 읽기 시작하고 그중에서 특히 월요일 - 10시가 가장 많은 클릭수가 집계되었다.

　이 포스팅을 작성하고 있는 지금까지 약 19,000여 개의 포스팅을 수집하고 발행하였는데 그중에서 가장 인기 있었던 포스팅 TOP 30 은 다음과 같다. 아무래도 단체 블로그의 포스팅을 메일 상단에 위치하고 노란색으로 테두리를 표시해서인지 대부분의 글들이 단체 블로그의 포스팅인 것을 알 수 있다.

• 이 회사, 이 세상 쿨함이 아니다
• 대놓고 자랑하는 글
• LINE 신입 SW 개발자 코딩 테스트, 이렇게 만들어졌습니다
• 우테코에서 찾은 나만의 효과적인 공부법
• LINE 서버 개발자가 되기까지 내가 준비한 것들
• 연봉을 높이는 가장 쉬운 방법은?
• 학교에서 알려주지 않는 17가지 실무 개발 기술 리뷰
• 간단하게 만드는 이상한 알람
• 팀 문화의 탄생
• LINE에서 전 직원이 재택 근무하면서 생산성을 유지하는 방법
• Flutter, 왜 선택하지 못했나
• 주석 달 시간에 프로그래밍을 제대로 하기
• 우아한테크코스 : 새로운 시작
• 기획자는 필요없다.
• 간단하게 구축해 보는 JavaScript 개발 환경
• 우아한테크코스 : 나만의 항로 찾기
• 코드리뷰 모음 서비스를 소개합니다.
• NAVER Tech Talk: Android 밋업(2018년 11월, 2019년 11월)
• 2019년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)
• 타다 웹 프론트엔드의 모든 것
• 개발 문화, 사무실 문화
• 그런 개발자로 괜찮은가 - 자기개발 편
• 주니어 개발자의 클린 아키텍처 맛보기
• 우리도 채팅있으면 좋을 것 같아요.
• 코드 가독성에 대해 – 1. 도입과 원칙
• 메인 데이터베이스 IDC 탈출 성공기
• 코드 가독성에 대해 – 3. 상태와 절차
• 그런 개발자로 괜찮은가 - 문화 편
• [2019. 9. 3] 카페24 개발자 세미나
• 진짜 카카오 티스토리 서비스 개판이다

그렇다면 수익은 얼마나 있었을까? 음?! 이 서비스의 수익이 있다고?? 우선 아래 차트를 보자.

　학창 시절엔 ‘선생님’께서 정해놓으신 커리큘럼에 따라가기만 하면 큰 문제 없이 지식을 학습할 수 있었다. 거기에 주기적으로 치르는 시험을 통해 ‘점수’라는 평가 기준으로 얼마나 잘 성장했나를 검사하기도 한다. 졸업 후 어렵게 어렵게 취업에 성공을 하여 ‘신입 개발자’라는 배지를 달고 회사에 첫 출근. 그렇게 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가 쓴 책을 옮겨서 다시 써진 책이었다. 그만큼 전혀 특유의 번역 느낌(?)은 없었고 오히려 한국 문화에 맞춰 다시 써진 건 아닐까 싶을 정도로 너무 술술 잘 읽혔다.