- Published on
4월 4주 있었던 일 정리
- Authors
- Name
- 이건창
Introduction
배치 작업 프로세스 개선
스프링 배치는 처리양을 조절 할 수 있고 작업 흐름을 쉽게 수정 가능하다. 그러나 처리양이 적은 상황에서는 계륵처럼 보일 수 있지만 이력 관리, 재사용성 등의 장점을 활용할 수 있다.
만약 초기 환경이 세팅된 템플릿을 구성한다면 팀은 쉽게 작업을 생성하고 격리된 테스트 환경에서 테스트하며 인프라에 쉽게 업로드 할 수 있게 된다.
특히나 배치 처리 후 결과를 새벽에 받지 않아도 된다. 일괄적으로 모았다가 전달하기 위한 작업은 추가할만큼 가치가 있지 않았는데, 배치 이력에서 하루 단위로 집계한다면 원하는 시간대에 결과를 받을 수 있다.
팀 작업은 다음처럼 진행된다.
젠킨슨은 선택하지 않은 이유는 배치 처리 작업 관리와 스케줄링 관리하지 않기 위해서 였고, 작업 관리는 최대한 AWS를 활용했다.
아쉬운건 인프라 작업의 파편화가 발생하는데 이전 프로세스와 동일한 상황이라 인프라 팀에게 부정적인 경험은 없어보인다.
오픈 소스 문제 해결
픽스처몽키 PR을 올리면서 부족함을 많이 느꼈다. 처음 기여할 때는 어떻게 멋지게 해결할 수 있을까?에 사로잡혀 집중할 시간을 뺏기고 정작 해결할 수 있는 시간에는 집중력이 떨어져서 힘에 부쳤다. 기여 과정에서 문제 해결과 코드 개선 관심사를 분리할 필요성을 다시금 느꼈다.
최근에 시간을 투자할 수록 답에 가까워진다는 걸 깨달았다. 그래서 문제를 해결하기 위해 금요일 저녁부터 밤을 샜며 하나씩 읽고 정리하면서 문제를 차근차근 살폈다.
처음에는 Duration 클래스를 주입하는 경우 값이 생성되지 않는 문제가 있었다. 픽스처 몽키는 리플렉션을 이용해 값을 주입하고 있는데, kotlin value class는 반환 값과 실제 값이 달라 반환 값을 받아와 실제 값으로 래핑해줘야 하는 문제가 있었다.
간단하게 설명하자면 아래 Introspector에서 context 정보를 읽어 값을 생성하게 된다.
class 구현된_Introspector : ArbitraryIntrospector, Matcher {
...
override fun introspect(context: ArbitraryGeneratorContext): ArbitraryIntrospectorResult {
...
}
}
그래서 value class 임을 표현하는 ValueClassProperty를 생성한 이후에 값을 생성하는 ValueClassIntrospector를 생성하는 방식으로 진행하려 했다.
그런데 계속 고민해보니 value class의 type 과 return type이 달라서 생긴 문제인데, 같으면 되지 않을까 생각하게 됐다. 내부에서는 AnnotatedType.type 을 이용해 memberParameter 를 등록하고 해당 값을 전달하다보니 value class 에 주입할 수 없게 된다. 그래서 returnType 이 아닌 실제 type 을 제공하면서 문제를 해결했다.
기여 과정에서 접근 방법이 결정하지 못하는 순간도 있었다. 대략 8개의 모듈에서 수정할 모듈을 결정할 때 어떤 모듈이 사이드 이펙트가 적을지 가늠이 안됐기 때문이다. 그래서 메인테이너에게 직접적으로 물어보기도 하며 함께 문제를 풀어나가는 소속감을 느껴서 꽤나 재밌었다.
처음에는 코드를 잘 짜고 싶어서 입문했는데, 방대한 코드에서 어떻게 살아남을 수 있을지 고민했다. 정리도 해보고 디버깅도 해보며 느낀건 방대한 코드에서 코드를 수정하는 자신감을 준건 단위 테스트라는 점이다. 단위 테스트 덕분에 구현하고 싶은 영역까지 달릴 수 있었다. 값진 경험이다.