본문 바로가기

짧게 쓰기/칼럼

코드에 주석은 어느정도 까지 다는것이 좋은가

개발자 신입은 사수에게 코딩의 기본 원칙과 지켜야할 규칙을 배우게 되죠. 그중에 코딩할때 주석을 잘 달으라는 얘기를 많이 듣습니다.


저도 신입으로 코딩할때 주석을 잘 달아야 겠다고 다짐했습니다. 그러나 저는 개발하다보니 코드에 주석다는 습관을 갖추기가 몹시 어렵다는 것을 알게 되었어요. 먼저, 주석에 신경 쓸만큼의 개발 기간이 주어지지 않는 경우가 대부분 이에요. 이것은 핑계가 아니라 중요한 사실입니다. 보통 위에서 개발 기간을 줄때 코드 품질을 신경 쓸 만큼의 시간을 주지 않아요. 일단 코드가 작동되는 것이 중요하고 주석 다는 작업은 우선순위에서 뒤쳐져요. 그리고 주석 다는 작업은 꽤 귀찮은 작업입니다. 코딩가이드에 명시한 주석다는 규칙은 화려하고 복잡하다는 생각을 했어요. 주석다는 규칙이 화려하고 번거롭다 보니 주석을 달기 위해 손이 잘 움직여지지 않습니다.


그래도 옛날에는 귀찮아도 주석은 달아야 겠다는 생각을 했습니다만~ 지금에 와서는 주석을 꼭 달 필요가 있을까 라는 생각도 하게 되었어요. 진짜 프로그래밍 고수는 화려한 주석을 달지 않아도 그 코드가 간결하고 가독성이 좋아 누가 그 코드를 보더라도 왜 이렇게 짰는지 알수있게 해야 한다라는 생각을 하게 됐어요. 화려한 주석을 달기 보다는 코드를 더 간결하고 더 읽기 쉽게, 짜임새 있게 짜는 것이 더 효과적이라고 생각했어요.


그러나 아무리 프로그래밍 고수라도, 스프링을 만든 로드 존슨 이라도 우리나라 IT 환경의 과도한 일정 압박 에서는 결과물 내기가 우선이고 코드 품질은 뒷전이 되기 때문에 좋은 코드를 만들기가 어렵습니다.  그래서 갑이 요구하는 과도한 일정 압박 때문에 화려하고 복잡한 주석을 달기가 힘들고, 주석없이도 이해되는 좋은 코드를 만들기가 어려운 상황이라면, 적당한 주석을 틈틈이 다는 것이 좋은 타협점이라고 생각합니다.


최근 제가 어느 프로젝트 iOS파트의 PL을 담당한적이 있었는데요. 처음에 코딩 가이드를 이렇게 제안했습니다.


/**

 로그인 관련 처리 수행, 필드 검증, 로그인 입력값 처리 등

 @param sender

 @return

 @remark

 */

- (IBAction)loginProc:(id)sender


위의 예를 보시면 주석에 설명, 파라미터, 리턴값 등 적어줘야할 내용이 많군요.


개발자들에게 이렇게 주석을 작성하자라고 했더니 한창 프로젝트 일정 스트레스가 최고조에 이를때는 아무도 주석을 다는 사람이 없었습니다. 저는 아무도 하기 싫은 번거로운 규칙을 가진 주석을 다느니, 이렇게 한줄짜리 주석을 달자고 제안을 했죠.


// 로그인 관련 처리 수행, 필드 검증, 로그인 입력값 처리 등

- (IBAction)loginProc:(id)sender


// 로 한줄짜리 설명문만 다는 것입니다.  그 결과 어떻게 됐을까요. 개발자들이 주석 다는 경우가 100%로 획기적으로 늘지는 않았습니다만, 그들이 어느정도 주석을 달아주는 경우가 늘어나는 긍정적인 효과를 얻었어요. 사실 @param, @return은 그냥 코드를 보면 파라미터가 뭔지 리턴값이 뭔지 알수 있거든요. 꼭 파라미터나 리턴값까지 명시하여 달 필요가 있을까요. (다만, 주석을 바탕으로 도큐맨트 파일을 생성하면 얘기가 달라지겠죠.)


제가 하고싶은 얘기는 보통 현실적으로 주석까지 배려하지 않는 일정때문에 화려하고 복잡한 주석은 달기 힘들고, 또 역시 현실적으로 코드품질까지 배려하지 않는 일정때문에 주석도 필요없는 아름답고 읽기 쉬운 코드를 만들기 힘들기 때문에, 코드에 번거롭지 않은 실용적인 주석을 다는 것이 좋은 대안이라는 생각이 듭는다.