내가 해결한 문제 중 가장 어려운 문제는 무엇이었나?

실질적인 결과물이 없었다

나는 그동안 어떤 어려운 문제를 해결했을까? 어려운 문제는 사람마다 정의가 다르다. 나는 누군가 쉽게 해결하지 못하는 것을 어려운 문제라고 생각하는데, 아직까지 이러한 어려운 문제를 해결한 경험이 없는 것 같다. 이런 저런 고민들만 많이 했지만, 실질적으로 그 문제를 해결하는 결과물을 만들어내지 못 했다. 마이크로 서비스 아키텍쳐를 운영하면서 어떻게 빠르게 개발하고 안정적으로 배포할 수 있을지 고민을 많이 했다. Domain Driven Design 방법론을 활용하면 근본적으로 마이크로 서비스의 경계를 더 분명하게 나눌 수 있지 않을까 생각했었고, 그것을 동료들과 공유하기도 하였다. 그 영향으로 Event stroming이라는 방식으로 우리의 비지니스 로직들을 분석해보는 시간을 가졌지만, 개발자끼리만 진행한 Event Storming은 실질적인 결과를 내지 못하고 몇 번 시도 뒤 중단하게 되었다. Integration Testing도 고민을 많이 했고, Consumer Driven Contract testing을 할 수 있는 Pact라는 Tool을 동료들과 공유했었다. 나에게 호출하는 다른 서비스들에게 하위 호환성을 CI 과정에서 체크하여, 전체 시스템의 에러를 발생하지 않고 개별 서비스를 안정적으로 어느 때나 배포할 수 있지 않을까 생각했다. 하지만 이 Tool을 도입하는 비용이 더 크다는 피드백들이 있어서 실제로 적용하지 못 하였다. 다양한 마이크로 서비스 아키텍쳐 관련 도서, 적용 사례에 대한 컨퍼런스 영상, 블로그등 많은 자료들을 찾으면서 이 문제에 대해서 해결책을 찾을려고 했지만 실질적인 해결책을 적용한 것은 없었다. 다음에 다시 마이크로 서비스 아키텍쳐로 전환하는 기회를 가지게 된다면, 이 경험을 바탕으로 더 잘해보고 싶다라는 생각을 가지기만 했다. 그러한 기회를 만들고 배웠던 내용들을 적용하여 그때보다 더 발전한 마이크로 서비스 아키텍쳐를 구현하는 것을 실질적으로 해보지 않았다.

IaS로 인프라를 관리하는 상황에서 어떻게 변화하는 인프라를 장애없이 잘 관리할 수 있을지에 대한 문제는 충분히 어려운 문제라고 생각한다. AWS 리전별로 동일한 리소스들이 생성되어야 하는 경우에 Terraform보다는 Cloudformation의 Stackset이 더 효율적일것 같아서 일부 도입을 하기도 했다. Taskcat을 활용하여 IaC로 운영하는 인프라도 CI/CD 파이프라인으로 관리하는 것을 테스트해보기도 하였다. 하지만 이것도 내가 문제를 정의하고 그것들을 해결하는 실질적인 결과물이 없었다. 기존에 잘 구성되었던 틀에 맞춰서 잘 운영하기만 했고, 그 운영과정에서 개선해야될 문제들을 실질적으로 해결하는 경험은 만들지 못했다.

이런 것들을 어려운 문제였다고 말할 수 있을까?

물론 개발자 커리어를 가져오면서 이런저런 작은 문제들을 해결했었다. 서버리스 아키텍쳐를 구성하면서 AWS SAM이라는 tool을 사용하여 파이프라인을 구성한 적이 있다. 좀더 간결한 IaC 문법을 제공하고, Docker container를 띄어 로컬에서 Lambda를 invoke하는 것처럼 테스트해볼 수도 있었다. 그리고 PyCharm이나 vscode에 plugin을 설치하면 개발자도구에서도 편리하게 AWS SAM과 연동할 수 있고, Breakpoint를 걸면서 테스트해 볼 수 있었다. 따라서 기존에 사용하는 Terraform 대신에 AWS SAM을 사용하여 배포 파이프라인을 만들었다. 오픈소스를 조금 수정하여 사용하고 있던 cirtcuit breaker 패키지에서 중대한 버그를 발견한 적도 있었다. 서비스간의 통신에서 트래픽이 많은 것도 아닌데 circuit breaker가 open되어서 에러가 많이 발생하는 문제가 있었는데, 소스코드를 분석하면서 Redis로 error 횟수를 counting하는 부분이 이상하다는 것을 발견하게 되었다. circuit breaker의 bug가 패치되면서 에러율이 현저하게 줄어들게 되었다. 젠킨스 프로세스가 OOM이 발생하는 문제가 있는 적도 있었는데, 먼저 메모리를 늘리고 G1 방식의 Garbage Collector를 적용하였다. 그리고 Prometheus plugin을 설치하여 Metric을 확인하게 되었고, old generation heap영역이 계속해서 차는 것을 확인하게 되었다. 그래서 jmap으로 heap dump한 것을 분석해봤는데, 하나의 object가 수 GB를 차지하고 있었다. 해당 class를 사용하는 것을 추적해보니 Jenkins plugin중에 뭔가 만들어진 리소스를 지우는 게 있었는데 권한 문제로 해당 file을 제거하지 못하면서 계속 참조되고 있었던 것이었다. 권한 문제를 해결해서 정상적으로 처리하게 했고, Heap memory는 정상적으로 GC되면서 안정적으로 유지되었다. AWS VPN client 인증을 위한 client certificate를 수동으로 발급하고 관리하던 것을 SAML 인증 방식으로 이미 사용하고 있던 Google Workspace를 통해서 하도록 구성한 것도 있다. workspace의 group의 권한으로 VPN 연결을 허가할 수 있게 되었다. 메뉴얼하게 웹 테스트를 하는 것을 알게 되고, Chrome Recorder 기능으로 반복적인 테스트 과정을 좀 더 효율적으로 할 수 있는 방법을 공유하기도 하였다. Code를 기반의 testing framework를 사용하지 않기 때문에 개발 백그라운드가 없어도 쉽게 적용해볼 수 있다고 생각했다. 하지만 이러한 것들을 뭔가 어려운 문제라고 정의하기에는 부족하다. 왜냐하면 누구나 해결할 수 있는 정답들을 쉽게 찾을 수 있기 때문이다.

당당히 말할 수 있는 경험을 이제부터라도 만들어보자

오늘 나를 돌이켜보면서 난해만 문제들을 정의하고 그것들을 해결해나가는 실질적인 경험이 너무 부족하다는 것을 느꼈다. "나는 진짜 어려운 문제를 해결한 적이 없었는데... 이걸 어려운 문제라고 할 수 있을까...?" 이러한 고민에 주저하지 않고 당당히 말할 수 있는 경험들을 앞으로라도 만들어 나가야겠다.