CS주의자와 행복한 개발자

컴퓨터과학이란게 정말 절대적인가요?

사실 제가 늘 생각했지만, 블로그에선 여러 번 삼가고 나서야 말해야겠다고 생각한 단어가 한 가지 있습니다.

CS주의자

음...뭔 얘기냐면요, 과학과 직관이란 게 항상 같지 않다는 얘기입니다.

재미있는 예시를 하나 들어 볼게요.

충분히 작은 N에 대해 삽입 정렬이 좋다는 것은 우리가 잘 알고 있어요. 그리고 그걸 구현하는 것은 일도 아니죠.

우리는 qsort(arr, arr_size, sizeof(arr_mem_t), asc_cmp); 대신 그 정도는 이해할 수 있어요.

그런데요, 만약 우리가 끊임없이 개선하고 수정해야 할 비즈니스 로직에, SIMD를 이용해서 O(N)을 O(N/k)으로 만들 수 있다고 해서 그걸 선택하는 것은 다른 얘기입니다.

만약 고성능 프레임워크처럼 잦은 수정보단 확립 후 유지보수로 가는 점이 크다면, SIMD도 좋고, 어셈블리를 박아 넣어도 나쁘지 않습니다.

그런데 10명의 사람들과 코드를 돌려 보면서 토론을 해야 하는데, SIMD를 넣는다고 해 봅시다.

장부에 자료가 들어가서 어떻게 처리되는지 보기 꽤 어렵습니다.

그리고 컴퓨터과학적으로 매력적인 해법은 여전히 SIMD인 경우가 있겠죠.

이 경우에 우리가 정말로 SIMD를 택하고, 이후 팀 내 교육을 강화하거나 해서 사람의 독해력을 키워야 할까요?

그렇게 늘려서 얻는 독해력이 우리가 협력하는 팀에도 있을 거라고는 보장할 수 없다는 얘기입니다.

그리고 개인 프로젝트에서도 이건 마찬가지입니다. 짜 두고 AI한테 맡기자는 말이 나올 수도 있지만, 수정 범위가 작고 예측 가능할 때 하는 소리죠.

이 블로그 엔진의 글을 파싱할 때 어셈블리 범벅으로 한다고 생각해 보세요.

그랬으면 벌써 이 엔진은 폐기되고, 글은 워드프레스로 이관되었을 겁니다.

하지만, 한 번 고성능으로 만들어 두고 유지보수하는 웹 프레임워크단은 그래도 됩니다.

만약 제가 이 블로그를 만들기 전에, 웹 프레임워크를 개발할 시의 언어가 바뀌었더라도 그건 비슷했을 거예요.

프레임워크가 자바로 짜였어도, 온갖 JVM 튜닝을 다 쑤셔 넣어서 기어이 벤치마크 상위권을 얻었을 테니까요.

그건 당연히 프레임워크는 안정화가 끝난 후에 통째로 재작성할 필요가 없는 얘기라서 그런 겁니다. 여기서 CS로 승부를 안 보기가 어렵죠.

그리고 여전히 많은 기업은 코딩 테스트로 채용합니다.

코딩 테스트의 골자는 알고리즘을 잘 알고, 과학적인 사람을 뽑는 겁니다.

그래서 제가 카카오 공채에서 고작 두세문제 풀고 떨어졌죠. 전 손이 느려서, CRT처럼 뻔한 걸 짤 때도 시간이 좀 걸리는데다, 기이한 알고리즘을 조합하는 데 관심이 있는 CS주의자가 아니거든요.

옛날 수학자들로 따지면 주판이나 산가지 몇 번 퉁겨 보고, 훅 털면 끝날 계산을 굳이 대수적인 풀이로 지루하게 서술한 다음, 소수점 50자리까지 근삿값을 구하는 부류의 괴짜들이 그런 걸 좀 잘 하겠죠.

저도 일부 사람들의 입장에선 알고리즘 파먹겠다고 한문을 배운 놈이니...참 희한하게 보일지도 모르겠지만, 저는 적어도 코드 주석에 한문으로 수식을 안 박습니다.

근데 웃기는 건, 코딩 테스트에서 손이 느린 사람이랑 작업물을 만들 때에 손이 느린 사람은 다르다는 겁니다.

당연하게도 작업물은 분기, 연도 등으로 돌아가지, 시간 단위로 안 돌아가거든요.

한편으로는, 코딩 테스트만큼 빠르고 효율적인 체가 없습니다. 적어도 똥차는 안 걸리거든요.

하지만 그 습관을 가지고 코딩하면 항상 승리하지는 못하는 거죠.

의외로 경쟁 코딩 플랫폼의 상위권 중 수학 전공자가 많습니다. 어째서냐고요? 그야 뭐...수학자들은 그런 알고리즘을 매우 방대하게 아니까요.

그런데 수학적으로 아주 우아한 코드들을 막상 읽어 보면 당황스럽습니다.

대수적으로 이렇다는게 왜 이 상태를 보장하지?

이걸 알아차리는 프로그래머만이 '실리콘 밸리식의 우아한 프로그래머'라고 하는 풍조도 있습니다.

제 개인적인 평가는, 그건 너무 프로크루스테스의 침대라는 거예요. 침대에 맞춰서 손님 키를 줄이고 늘이는 셈이죠.

그니까 다시 돌고 돌아 실사구시입니다.

잡식적으로 최신 기술 트렌드를 마구 먹고, 신기술이 나오면 회사에 도입하고, 다들 그렇게 하면 나아질 것이라고 생각합니다.

뭐...어느정도는 먹히는 일이죠. 2021년 당시, CGo를 배격한 순수 Go 프로그래밍을 중시한 대구대학교 MoNet 연구실도 당시엔 되게 파격이었을 겁니다. 그리고 생각보단 굴러갔구요.

하지만, ARM64에서 일부 syscall을 날릴 때, Go에 덜 구현되었거나, 아직 ARM64 대상으론 실험적인 syscall이 몇 있었습니다.

교수님과 CGo를 할지, 어쩔지 고민하다가 결국 그냥 C로 통신시켰죠.

IOCTL 쪽 구현은 Go에서 되긴 했는데, 가독성이 너무 나빴습니다. 게다가 Unlocked IOCTL이라 C만한 애가 없기도 했구요.

또 회의해보고는 C로 했습니다.

그렇다고 해서, 좋은 언어로 잘 굴릴 수 있는 파트를 C로 하자고요? 그러니까...이건 실사구시의 얘기입니다.

쿠버네티스 파트는 Go로 하고, 모션 인식 센서는 C++ SDK가 있으니 C++로 했습니다.

그리고, 잘 굴러갔고 잘 보고되었구요.

그래서 돌고 돌아서 실사구시가 되어야 한다는 겁니다.

기술 스택이 안 맞으면 서로 이래라 저래라 말하다가, "난 듣지 않겠어"가 될 때도 있습니다.

심한 경우에는, 기술적 추구미와 장인정신에 대한 순수성을 논하기도 하죠.

근데, 이건 자기가 놓인 선택압에서 잘 판단해야 하는 겁니다.

내가 그걸 해서 실용적이면 하는 거고, 다른 선택으로 갈아엎는 비용이 더 크다면 하지 않는 거죠.

그리고, 이제 틈만 나면 테크 유튜버들의 영상에서 나오는 이 훈계는 한 번 더 곱씹어 봐야 할 맥락이 됩니다.

CS 공부해라.

지금 나한테, CS를 죽어라 파는 게 당장 필요한가요?

그리고 지금 이 순간, 저는 "행복한 개발자"입니다. 물론, 제 맥락에서요.