성장을 위해 완벽주의를 버리다

나는 어렸을 때부턴 KOI(한국정보올림피아드)를 준비하면서 코딩을 배우기 시작했다. KOI와 같이 알고리즘 문제를 푸는 대회는 어느 정도 "명확히 정답이 있는" 문제를 풀게 된다. 문제의 입력 조건에서 N의 크기를 보면 이문제를 O(N)으로 해결해야 할지 O(NlogN)으로 해결해야 될지 어느정도 추측을 할 수 있고 이런 추측에 따라 문제를 풀게 된다. ACM-ICPC와 달리 KOI의 경우 한번 코드를 제출하면 수정을 하고 다시 재제출을 할 수 없기 때문에 코드를 작성할 때 명확히 요구사항을 모두 만족했는지, 입력의 코너 케이스에도 문제없이 잘 동작하는지 등 꼼꼼히 코드를 읽고 테스트를 해보는 것이 습관이 되었다. KOI와 ACM-ICPC과 같은 알고리즘 대회에서 좋은 성적을 얻기 위해서는 완벽한 코드를 작성하는 것은 필수적이다.
이렇게 꼼꼼히 코드의 오류를 찾아내고 여러 코너 케이스를 찾아내는 습관은 엔지니어로서 주니어 시절을 보낼 때도 좋은 영향을 주었다. 주어진 요구사항에 맞게 꼼꼼히 작성을 하고 알고리즘을 배운 덕에 코드의 성능까지 챙길 수 있는 코드를 작성할 수 있었다. 제품의 새로운 서비스를 준비하는 과정에서도 다른 사람이 생각하지 못했던 여러 케이스에 대해 생각해내고 추가 제안을 하는 경우가 많았다. 이것은 나에게 큰 장점이라고 스스로 생각했다.
하지만 최근 이런 나의 완벽주의가 더 이상 장점으로 느껴지지 않았다. 우리가 사는 세상에는 알고리즘 대회와 같이 명확히 정답이 있는 문제가 아니기 때문이다. 정답이 없는 문제를 놓고 고민을 하다보니 스트레스를 많이 받게 되었다. 내가 겪었던 예시를 한번 들어보면, 팀 내에서 백엔드 코딩 컨벤션에 대해서 논의하는 미팅 중이었다. 'A가 좋을까요? B가 좋을까요?'와 같은 미팅이었다. 이런 류의 논의는 대게 명확한 정답이라는 것이 없기 마련이다. 하지만 완벽주의의 성향이 있던 나는 이런 미팅이 스트레스였다. 모두들 A가 좋을까 B가 좋을까 논의하고 있지만, 나는 속으로 'A를 선택하면 이런 문제가 있고, B를 선택하면 이런 문제가 있는데.. 뭔가 둘다를 만족하는 C는 없을까'를 계속 고민한다. 완벽하게 모든 케이스를 만족하는 C를 찾기 위해 노력하지만 이런 C는 우리가 사는 세상에는 거의 존재하지 않는다.
페이스북에는 "Done is better than perfect"이라는 문구가 있다고 한다. 나는 이것을 내것으로 받아들이고 생각을 바꾸는 데까지 꽤 오랜 시간이 걸렸다. 나는 아무리 완벽해 보이지 않는 것이라도 그것의 장단점을 이해하고 선택하고 함께 일하는 동료로부터 피드백을 통해 개선해 나가야 했다. 이렇게 나의 장점이라고 생각했던 완벽주의적 성향을 버리는 것이 고통스러웠지만, 나의 성장을 위해서 필수적이었다. 나와 내 동료 그리고 나의 팀은 완벽할 수 없다. 지금은 완벽하지 않지만 우리의 상황에 맞는 최선의 선택을 계속해나가면서 개선해나가다 보면 어느새 문제라고 보였던 것이 자연스럽게 해결되어 성장해 있는 자신을 볼 수 있지 않을까 싶다. 이렇게 나는 성장을 위해 내가 갖고 있던 완벽주의를 버렸다.