20260324 with claude

claude와 고민 상담을 했다. 개발자로의 주관이 크게 없는 느낌을 많이 받는다. 리뷰를 수동적으로 반영하는 느낌인데, 이 자세가 스스로 보기에도 결코 좋아보이지 않았다. 

 

오히려 PR 리뷰를 받을 수 있는 것은 좋은 기회라고 본다. 스스로의 코드를 점검하면서, 제안해주신 방안을 보면서 '왜 이런 방안을 제안했을까'를 생각해 보면, '어떤 기준으로 코드를 판단할 수 있을지'를 알 수 있겠다. 그리고 정답이 없다는 것도 참 잊지 말아야 할 자세인데 자꾸 잊는다. 

 

그래서 앞으로는 PR 리뷰를 받을 때 이 리뷰들을 분석해 봐야겠다. 그러다 보면 스스로도 코드를 작성하기 전에 점검하게 되는 일련의 기준들이 생길 것이고, 그게 곧 내가 생각하는 좋은 코드를 위한 하나의 기준이 될 것이니 말이다.

---

 

Comment 1

파이썬은 GIL이 걸려있다. global interpreter lock인데, 이게 걸려 있어서 결국 멀티스레딩 환경에서도 한 번의 하나의 스레드만 인터프리터를 점유할 수 있다. 이렇게 제한한 이유는 스레드 간 동시성 문제를 방지하기 위해서라고 알고 있다. 물론 CPython은 그러하고, pypy나 다른 구현체를 사용하면 GIL을 사용하지 않고, 병렬 프로그래밍을 할 수 있다. 그런데 왜 CPython에서는 GIL이 걸리고, Pypy에서는 GIL을 사용하지 않았는지도 궁금하고, Pypy와 CPython의 차이가 그것뿐인지도 궁금하다. 또, 파이썬이 아닌 다른 언어에서도 이 부분을 고려했을 텐데 다른 언어에서는 왜 이런 방식을 사용하지 않았는지도 궁금하다.

 

 

Comment 2

GIL을 사용하지 않는 것은 pypy가 아니라 Jython 등의 구현체이다. CPython이 GIL을 사용하는 이유는, 메모리 관리 문제와 연결된다. CPython은 메모리를 정리할 때 객체마다 reference counter(참조 카운터)를 둔다. 그리고 어떤 객체의 참조 카운트가 0이 될 때, 앞으로 더 이상 해당 객체가 사용되지 않음으로 간주하고 해당 객체의 메모리를 해제한다. 다른 언어들은 다른 방식을 택했다. GC(garbage collection)에 대해서, 예를 들면 java는 jvm을 사용한다. JVM은 tracing GC라고 해서, 주기적으로 garbage collector가 프로세스의 heap(동적으로 할당된 메모리를 관리하는 공간)을 스캔하면서 사용되지 않는 메모리 공간을 해제한다. 그리고 C나 C++은 아예 이 메모리 관리 문제를 개발자의 책임 소관 안에 두어서 별도의 참조 카운터가 없다.

 

 

Comment 3

그런데 쓰다보니 또 궁금한 게 있다. 여기서 python이 유일한 인터프리터 언어라고 알고 있다. C, java 모두 컴파일 언어로, 소스 코드를 기계어로 컴파일한 다음 컴파일러는 그 기계어를 실행한다. 언어의 이런 특징 차이가 GC나 참조 카운터 등의 메모리 관리 방식의 차이에도 영향을 미쳤을까? 인터프리터 언어가 어떻게 실행되는지는 정확히 모른다. ‘인터프리터’와 ‘컴파일러’의 차이가 정확히 뭘까? 인터프리터는 코드 전체를 컴파일하는 대신, 코드 한 줄 한 줄을 바이트코드로 바꿔서 그걸 인터프리터가 해석하는 거라고만 이해하고 있는데 맞을까?