24.11.10~24.11.18

업무 공유

타겟 요소 조회 알고리즘 개선

현 서비스의 핵심 로직 중 하나인, 타겟 요소 조회 알고리즘을 개선했다.

 

타겟 요소 조회 알고리즘은 사용자가 선택한 요소를 가이드 실행 시 얼마나 정확하게 찾아가는지 를 의미하는데,

서비스 극 초창기 때 작성한 로직을 지금까지 사용하고 있었다.

 

당시만 하더라도, 서비스의 정확한 컨셉이나 사용 기업이 확정되지 않은 상태로

우연찮게 POC가 이뤄진 B사의 요구사항을 구현하는데 급급했다.

 

Azure, GCP 등 외부 서비스에서 사용자가 선택한 요소를 식별해야 했기 때문에

일반적인 식별자(대표적인 예시가 id)를 사용할 수 없었고

이로 인해 최대한 많은 예외 케이스를 고려해야만 했다.

 

하지만 점차 POC 기업이 늘어나면서

기존 알고리즘이 고려했던 예외 케이스로 인해, 오히려 조회 결과가 부정확해지는 문제가 발생했다.

얼핏 봤을 때 찾아야하는 요소를 찾지 못한다거나, 이상한 요소를 찾는 경우가 점점 늘어났던 것!

 

팀 내부적으로도 해당 알고리즘의 개선이 필요하다는 의견 일치가 있었고,

덕분에 약 1주일 정도를 투자해 타겟 요소 조회 알고리즘 개선 업무를 전담하게 되었다.

막중한 임무를 맡았다

프로덕션에서 사용 중인 고객사들의 기존 가이드 동작이 변경되어서는 안 되었고,

동시에 기존 로직으로는 올바르게 조회하지 못하던 요소를 조회할 수 있어야 했는데...

서비스의 핵심 로직인만큼 다양한 케이스를 상정하고, 논리를 계속해서 점검하며 테스트해 나갔다.

 

케케묵은 이슈 하나를 처리할 때의 기분이란!

최종적으로, 생성된 스무여 개의 기존 데이터 + 다양한 테스트 케이스들을 모두 커버할 수 있도록 점진적 필터링 형태의 알고리즘을 구현했고 → 테스트 후 배포만을 앞두고 있는 상황!

 

회고

좋은 코드, 나쁜 코드

사실 기존 알고리즘의 가장 큰 문제는, 요소 조회에 실패했을 때 왜 실패했는지 알 수 없던 것이었다.

그리고 그 이유는... 특정 의도에 따라 알고리즘이 작성된 것이 아니었기 때문!

 

알고리즘을 작성한 당시에는,

외부 클라우드 서비스에서 조회 로직이 정상적으로 동작할 수 있는가? 부터가 물음표였고 (상상 초월 예외 케이스가 나타나곤 했었다)

해당 서비스로 100% 피봇 할 것인가 조차 확실하지 않았었다.

때문에 어쩔 수 없이 당장 돌아가는 코드를 작성하는데 급급할 수밖에 없었다.

 

예외 케이스가 발견될 때마다 이를 대응하기 위한 코드를 막무가내로 추가했고,

이런 로직들이 쌓이고 쌓이다 보니, 전체적인 알고리즘 자체가 어떻게 동작하는지를 완벽하게 설명하기란 불가능에 가까웠다.

 

따라서 이번 작업을 할 때 가장 신경 썼던 부분은 → 각 논리들의 의도를 명확히 하는 것!

 

예외 케이스가 발생했을 때도

원인을 올바르게 추상화하고, 기존 논리의 문제점과 해결 방안을 명확히 도출해 내기 위해 많은 노력을 기울였다.

이를 통해 다른 예외 케이스가 발생하더라도, 기존 로직과의 비교 및 올바른 우선순위 판단을 이끌어낼 수 있었다.

 

그리고 다시 한번 든 생각.

가장 나쁜 코드는, 의도가 존재하지 않는 코드다.

 

성능이 좋지 않은 코드는, 성능을 개선하면 된다.

컨벤션에서 어긋나는 코드는, 여러 방안(ex lint)을 통해 방지 및 수정할 수 있다.

자기만 알아볼 수 있는 코드는, 당사자에게 물어보면 된다. 

 

하지만

의도가 담겨있지 않은 코드는 그 무엇으로도 해결할 수 없다.

 

왜 이렇게 작성했냐 고 물었을 때 코드 작성자도 대답할 수 없다면,

해당 논리가 무엇을 의미하는지 물었을 때 명확한 답변이 나올 수 없다면,

그 코드는 누구도 마음 놓고 수정할 수 없게 된다.

 

그리고 이를 반대로 말하자면

좋은 코드는, "왜 이렇게 작성했는지"를 명확히 대답할 수 있는 코드다.

 

코드의 의도가 명확하다면, 설사 틀려도 괜찮다. 다른 팀원(혹은 미래의 자신)이 고쳐줄 수 있으니.

코드의 의도가 명확하다면, 얼마든지 수정할 수 있다. 해당 의도를 구현하기만 하면 되니까.

그리고 이는 자연스레 높은 유지보수성과 지속 가능성으로 이어질 수 있다.

 

그리고 의도를 명확히 담는다는 것은, 단순히 코드를 작성하는 기술적인 행위에 그치지 않는다.

문제를 정의하고, 해결책을 설계하며, 현 상황에 대한 판단 기준을 논리적으로 녹여내는 과정.

결국은 이 과정이 있어야만 좋은 코드를 작성할 수 있다.