- 오늘 프로젝트를 정리하다가 네이밍도 손질을 해야 겠다는 생각이 들었다. 그것은 기존의 View Control의 이름이 상당히 헷갈렸기 때문이다. Control라는 별도의 폴더에는 각각의 컨트롤들이 모여 있는데, 여기서 View Control의 이름은 중간 곳곳에 박혀 있어서 찾기도 어려웠다. 다음과 같았다.

ContractsControl.cs
ContractsStatusViewControl.cs
CustomControl.cs
RoomsControl.cs
RoomsStatusViewControl.cs

위와 같이 중간 중간에 뭔가 긴 이름이 있는데 이게 View인지는 정확히 확인할 수가 없었다. 그래서 이것을 다음과 같이 수정했다. ContractsStatusControlView.cs, RoomsStatusControlsView.cs 이렇게 하면 좋지 않을까했다. 그런데 딥시크는 매우 좋지 않다고 한다. 이 이름이 일단 영어문법적인 관점에서도 모호할 뿐만이 아니라 나중에 확장을 위해서 뒤에 접미사가 추가될 경우 더 애매해질 수 있다는 것이었다. 그래? 그렇다면 ContractsStatusControl_View.cs, RoomsStatusControls_View.cs 이렇게 하면 되지 않을까하고 계속 우겼는데, 결국 DeepSeek가 View와 같은 커다란 분류의 관점을 뒤에다가 두는 것은 앞으로의 접두어, 접미사의 일관성을 해칠 뿐만이 아니라 또, 솔루션 탐색기에서 기존과 마찬가지로 중간중간에 튀어나와서 오히려 관리를 어렵게 한다는 말에 설득당했다. 그래서 다음과 같이 수정하였다. View_ContractsStatusControl.cs, View_RoomsStatusControls.cs 이렇게 변경하고보니 솔루션 탐색기에서도 그럴듯하게 View만 모여졌다.

- 위 이름을 가지고 이번에는 구글 제미나이에게 물었더니 엄청 부정적인 답변을 내놓았다. 우선 C#의 네이밍에서 클래스와 파일의 이름에는 언더바를 붙이지 않는다는 것이다. 이것을 DeepSeek에게 맞냐고 물었더니 그게 맞다고 한다. 그러면 왜 View_와 같은 이름을 추천했냐고 물었더니 잘못했다고 사과한다. 쩝... 그렇게해서 최종 결과는 다음과 같이 되었다. ViewContractsStatusControl.cs, ViewRoomsStatusControls.cs 이렇게 모두 변경을 하였다.

- 사실 나는 델파이 파스칼 네이밍에 익숙해져 있어서 파일명이나 클래스의 이름에 접두어 보다는 접미사를 붙이는 것을 선호해왔다. 델파이에서 접두어는 예약된 것이 많아서였다. 그래서 혼란을 피하기 위해서 주로 접미사를 사용해왔다. 그런데 C#에는 관습적인 접두어 예약어가 거의 없었다. 그래서 큰 분류는 접두어로, 작은 분류는 접미사로 설정하는 것이 좋겠다는 생각이... C#에서는 들었다. 그것이 솔루션 탐색기에서 편하게 볼 수 있기도 하고, 앞으로 그런 규칙에 따른다면 훨씬 관리가 편하지 않을까하는 생각이 들었다. 그런데 이번에 제미나이는 다른 문제점을 들고 나왔다.

- 보통 영어권에서는 RoomsStatus와 같은 표현을 사용하지 않는다는 것이다. 그래서 이것을 RoomStatus로 수정해야 한다고 주장했다. 그래서 내가 물었다. 그렇다면 테이블명은 rooms로 하고 클래스나 변수 이름은 Room이라는 단수로 해야 한다는 것인가 하고 물었더니, 그렇다고 했다. 그런데 나는 이 생각이 매우 의아했다. 우선 프로젝트가 영어권이 아니라 비영어권인데 이런것을 영어적인 정서에 맞춰야 하는가에 대한 의문이 들었다. 한국인 프로그래머가 Rooms라는 단어를 본다면 아, 이것은 복수구나하고 어떤 집합체를 떠올릴 것이다. RoomsStatus도 마찬가지이다. 영어권 사용자를 위해서 영어적인 정서까지 포함해서 네이밍을 해야 한다는 것은 일단 가혹했다. 그리고 다른 더 중요한 문제가 있었다.

- 일반적으로 is라는 접두어는 단수와 복수를 가리지 않고 사용한다. is가 단어의 가장 첫 부분에 나왔다는 것은 단지 이것이 bool이라는 의미일 뿐이지, 이것이 영문법적인 기능을 하는 것은 아니라는 것이다. 따라서 네이밍은 영어적인 정서를 그대로 사용하는 것이 아니라 오히려 일관성과 명확한 관점을 더 중요하게 생각해야 한다고 본다. 그리고 이 보다 더 중요한 사실이 있다.

- 그것은 추상화와 네이밍을 헷갈려하는 것이다. 일반적으로 네이밍은 추상화가 아니다. 추상화일 경우, 우리는 영어적인 정서까지 포함될 수가 있다. 그러나 네이밍은 그렇게 하면 안된다. 네이밍은 일관성과 관점의 뚜렷한 분류가 핵심이 되어야 한다. 어떤 프로젝트에서 전체의 구조적인 설계가 없다면, 거기에는 추상화가 없다고 봐야 한다. 단지 네이밍만 있을 뿐이다. 우리는 전체 설계가 없는 상태에서 추상화적인 관점을 목마른 갈증처럼 풀기 위해서 네이밍에 영어의 정서적인 표현을 하곤 한다. 그러나 이러한 네이밍은 오히려 혼란을 가중시킬 뿐이다.

- 실제로 제미나이도 이러한 사실을 인정하였다. 사실 s에 대한 사용에 그동안 많은 혼란과 갈등이 있었다고 한다. DB테이블은 복수, 엔티티 클래스는 단수, 컬렉션 변수는 복수, UI컨트롤은 기준이 아예 없다고 한다. 이렇게 왔다갔다 하면서 기준이 없었고, 사실 지금도 싸우고 있다고 한다. 결국 제미나이도 나의 관점에 동의하였다. 그 동의는 비영어권에 의한 관점의 기준이 아니라, s라른 복수형이 네이밍적인 관점에서 일관성과 뚜렷한 분류의 관점을 제공한다는 점에서였다. 나는 제미나이와의 대화에서 s의 사용에 있어서의 이런 혼란이 추상화와 네이밍에 대한 분별을 하지 못하였기 때문에 발생하였을 것이라고 생각한다. 추상화는 좀 더 거대한 분류이며, 또한 상당히 현실적인 비유와 상징을 통해서 만들어지기 때문에 영어적인 정서가 매우 많이 포함되어질 수 있다고 본다. 하지만 네이밍은 그래서는 안된다. 매우 일관적이고 분류적인 관점이 있어야 한다. is의 사용처럼 말이다.


범진소프트
https://cafe.naver.com/bumjinsoft