얼마 전 페이스북에서 대화하던 중 프로그래밍 생산성에 있어서 누가 개발하느냐가 중요하지 어떤 언어를 사용하느냐는 중요하지 않다는 의견을 들었는데 저는 강하게 반대하는 입장이지만 여건 상 길지 않게 의견을 전달했습니다. 아마 잘 설득하진 못했을 겁니다. 그런데 오늘 Java 언어에서 속성의 읽기 접근자(getter)와 쓰기 접근자(setter) 작성에 대한 괴로움이 주제인 논의를 발견했습니다. 이 문제에 대해 역시 페이스북에서 얘기를 하던 중 프로그래밍 언어가 가지는 생산성에 대한 영향력의 한 예가 떠올라 적어봅니다.

Stone and metal knives

Stone and metal knives

 

이 글이 작성되는 시점의 최신 Java 언어 스펙(8)에 따르면 속성은 다음과 같이 작성됩니다.

private String myProperty;

public String getMyProperty() {
    return myProperty;
}

public void setMyProperty(String value) {
    myProperty = value;
}

이것이 너무 장황해서(verbosy) 짜증나니(생산성이 떨어지니) 무결성 확보 등을 위해 접근자 논리를 제공해야할 높지 않은 경우의 수는 닥치게 되면 그 때 가서 고민하고 일단 그냥 공용(public) 필드를 사용하는 것이 어떻겠느냐 하는 것이 발의자의 의견입니다. 본 게시글은 이 문제제기의 정당성이나 해답보다는 왜 이런 고민이 생겨났는지에 대해 얘기합니다.

위에서 본 코드를 공용 필드로 작성하면 이렇습니다.

public String myProperty;

간결하네요. 그런데 만약 myPropertynull 상태를 허용하지 않는다던가 하는 규칙이 추가되면 쓰기 접근자가 필요해지고 처음에 봤던 코드와 유사한 형태로 코드를 변경해야합니다.

private String myProperty;

public String getMyProperty() {
    return myProperty;
}

public void setMyProperty(String value) {
    // Validation logic
    myProperty = value;
}

다시 길어졌습니다. 이번엔 필요한 코드가 들어갔기 때문에 장황하다고 말하기는 어렵습니다. 문제는 다른 곳에 있습니다. 인터페이스에 큰 변화(breaking change)가 생겼기 때문에 모든 클라이언트 코드가 동작하지 않게됩니다. 그나마 같은 프로젝트의 클라이언트라면 어떤 도구가 도움을 줄 수도 있지만 그렇지 않은 경우라면 문제가 심각합니다. 공용 필드를 사용하면 당장 약간의 수고는 줄어들지만 디자인의 유연함은 크게 잃어버립니다.

자, 그런데 만약 애초에 프로그래밍 언어가 속성 접근자 작성에 피로도를 주지 않는다면 어떨까요? 필드를 공용으로 노출할 생각은 들지 않을겁니다. Java와 비교해 속성 지원 문법을 풍부하게 제공하는 C#의 경우 별다른 제어 논리를 가지지 않는 속성은 다음과 같이 작성할 수 있습니다.

public string MyProperty { get; set; }

Java에서 공용 필드를 작성하는 것과 비교해 괴로움을 느낄 정도로 장황하지 않습니다. 여기서 쓰기 접근자에 검증 논리를 추가하면 이렇습니다.

private string _myProperty;

public string MyProperty
{
    get { return _myProperty; }
    set
    {
        // Validation logic
        _myProperty = value;
    }
}

중요한 것은 구현부가 달라졌을 뿐 인터페이스는 변경되지 않았다는 것입니다. 클라이언트 코드는 변경될 필요가 전혀 없습니다.

정리해보죠. Java 언어를 사용할 경우 개체가 속성을 제공하기 위해 접근자를 작성하는데 특별한 논리의 필요성이 없을 때 접근자 작성이 요구하는 노동력이 합리적이지 않다는 주장이 있습니다. 생산성이 낮아서 괴롭다는 것이죠. 그렇다고 공용 필드로 시작하자니 접근 논리를 추가해야 할 때 훨씬 큰 노동력을 필요로 할 수 있습니다. 여기서도 낮은 생산성으로 고통받습니다. 이래저래 기대 생산성은 낮습니다.

반면 속성 지원을 풍부하게 해주는 C#을 사용하면 두 가지 경우 모두 고민거리가 아닙니다. 고민을 위한 비용도 불합리한 코딩 비용도 들어가지 않습니다. 이 예시에 대해서는 C#이 Java보다 생산성이 높습니다.

모든 프로그래밍 언어들은 생산성에 영향을 주는 다양한 요소들을 가지고 있습니다. 각 요소들은 특정 상황에서 생산성을 높이거나 낮춥니다. 생산성에 영향을 주는 정도 역시 다양합니다. 어떤 언어들은 요즘 자주 발생하는 문제들을 해결할 때 생산성을 높일 수 있는 기능을 많이 제공하고 다른 언어들은 그렇지 못합니다. 동일한 문제를 풀기 위해 누가 코딩을 하느냐도 중요하지만 어떤 언어를 사용하느냐도 문제해결 생산성에 영향을 많이 미칩니다. 생산성 높은 언어를 사용해 절약한 자원은 다른 곳(예를 들면 느리고 지루한 TDD 따위)에 사용할 수 있습니다.