336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
얼마 전 분산 저장소에 대한 팀 내 관심이 뜨거웠다. 때마침 실험적 시도를 할 수 있는 작은 프로젝트를 진행하게 되었는데, 프로젝트 참여자들과 논의하여 Git 도입을 시도했다. Git을 사용해보며 여러 가지 요소를 평가 중인데, 그 중 개인적으로 관심이 있는 부분은 Git이 내가 일하는 환경의 어떤 부분을 향상시켜 줄 수 있느냐이다. 좀 더 나아가 SVN을 사용하고 있는 우리 회사가 Git으로 전환해야 하는지에 대해서도 관심이 있다.

1. Git의 특징

예전에는 중앙 저장소가 있고 모든 개발자가 중앙 저장소에 자신의 작업을 커밋했다. 반면 Git은 분산 저장소를 제공한다. 따라서 중앙 저장소가 있더라도 해당 저장소를 로컬에 복사(clone)하는 순간 로컬에 나만의 저장소가 생긴다. 따라서 예전처럼 원격 저장소에 영향을 미치지 않고 로컬 내에서 브랜치를 만들고, 커밋하고, 롤백하는 일 모두 가능하다. 

만약 중앙 저장소에 내 작업을 넣고 싶으면 어떻게 할까? 예를 들어 어떤 저장소를 로컬에 복사한다. 그리고 파일 하나를 수정한다. 원격 저장소에 변경사항을 반영(push)하려하면 변경사항이 없다고 나온다. 이는 예전과는 달리 사용자와 중앙 저장소의 입장이 아닌 로컬 저장소와 원격 저장소의 입장이 되기 때문에 발생하는 일이다. 즉, 로컬 저장소에 커밋을 하지 않았기 때문에 변경이 없다고 보는 것이다. 로컬 저장소에 커밋을 한다. 그리고 다시 변경 사항을 반영해본다. 이제서야  변경사항이 원격 저장소에 적용된다. 방금 얘기한 것이 Git의 가장 기본적 흐름이다.

2. 오픈소스가 Git으로 전환하는 이유에 대한 견해

오픈소스는 소수의 커밋터(Committer)와 다수의 공헌자(Contributor)로 구성된다. 커밋터를 제외한 공헌자는 익명으로 소스를 체크아웃하고 로컬에서 작업한다. 작업이 어느정도 완료되면 패치를 만들어 커밋터에게 적용을 요청한다. 이 모델은 대부분 오픈소스에서 사용하는 개발모델이다. 그런데 문제점이 있다. 바로 공헌자는 패치를 완료하기 전까지 SCM의 이점을 전혀 못 누린다는 점이다. 저장소가 없으므로 중간에 커밋을 할 수도 없고 롤백도 할 수 없다. 당연히 브랜치도 만들 수 없다. 따라서 어떤 공헌자가 한 프로젝트에 대해 여러 패치를 동시에 작업해야 한다면 이는 기존 SVN 환경에서 쉽지 않은 일이다. 

Git을 이용하면 방금 얘기한 문제가 해결된다. 중앙 저장소에 권한이 없더라도, 로컬에서 얼마든지 SCM의 장점을 누릴 수가 있다. 작업하다 잘못되면 롤백을 할 수도 있고, 몇 개 브랜치를 만들어 여러 패치를 동시에 작업할 수도 있다. 난 이런 이유로 오픈소스진영에서는 Git을 반길 수밖에 없다고 생각한다.

3. 그럼 회사에서도 Git이 필요할까?

Git에 대해 긍정적 의견을 내비치는 사람의 근거 중 하나는 오픈소스진영이 점차 Git으로 전환하고 있다는 점이다. 오픈소스 진영은 기술적 트렌드에 민감한 편이고, 오픈소스에 먼저 적용한 기술이 시간이 흘러 대중화되는 것은 매우 자연스러운 흐름이다. 그렇다면 회사에 Git을 도입하는 것은 어떨까? 난 아래 두 가지 이유로 신중한 접근이 필요하다고 본다.

첫째 회사는 오픈소스진영과 개발상황이 다르기 때문이다. 가장 큰 차이점은 오픈소스에는 흔한 공헌자가 없다는 것이다. 팀원 모두 커밋터고, 팀은 저장소 하나를 공유하며 함께 작업한다. 따라서 수정한 것이 있으면 바로 커밋을 하면 된다. 팀원 모두 커밋터로써 SCM의 장점을 충분히 누릴 수 있다.

둘째 지속적 통합에 대한 부정적 영향을 미칠 가능성이 있기 때문이다. 여럿이서 저장소 하나를 대상으로 함께 작업하다 보면 지속적 통합이 무척 중요하다. 다시 말해 동작하는 버전을 자주 커밋하는 게 강력히 권장된다. 이를 잘 지키면 다른 동료에게 빠른 피드백을 줄 수 있고, 통합 시점(보통 QA 혹은 배포 전)에 소스가 충돌이 나 소스를 급하게 수정하는 일도 줄어든다. 그렇다면 Git은 어떨까? 난 Git은 지속적 통합이 추구하는 바에는 잘 안 맞는 것 같다고 생각한다. Git은 로컬 저장소를 제공하기 때문에 로컬에서 커밋하고 롤백하며 작업할 수 있는 좋은 토양을 제공한다. 이로 인해 자주 통합하기보다는 소스를 로컬에 오래 가지고 있는 상황이 생기지 않을까라는 우려가 든다.

4. Git에서도 지속적 통합이 가능하다?

누군가는 이렇게 얘기할 수 있다. '로컬 저장소가 제공되는 Git을 쓰자. 그리고 예전처럼 자주 커밋하자. 예전과 다를 바가 없지 않나?' 그런데 여기 약간의 걸림돌이 있다. Git은 SVN, CVS와 달리 중앙 저장소에 바로 커밋할 수 없기 때문이다. Git은 로컬 그 자체가 저장소이기 때문에 우선 로컬 저장소에 커밋을 수행한 후에 로컬 저장소를 원격 저장소에 머지(push)하는 방식으로 통합한다. SVN, CVS를 사용할 때는 단순한 파일 하나를 수정할 때 커밋을 하면 끝이었다. 하지만 Git은 로컬 저장소에 커밋하고 원격 저장소로 머지해야 한다. 즉, 두 단계가 필요한 것이다. 별것 아닌 것 같지만, 개발자가 가장 많이 수행하는 흐름이 좀 더 길어진 것이다. 물론 두 단계를 한꺼번에 수행해주는 도구를 개발하면 쉽게 해결되는 문제이다. 하지만, 도구를 쓰는 단계까지 간다면 Git을 써야 하는 이유가 많이 퇴색되는 게 아닐까?

5. 커밋터에게 로컬 저장소가 필요한가?

앞서 소개했지만, Git의 가장 큰 장점은 로컬에 나만의 저장소를 둘 수 있다는 점으로 보인다. 그런데 과연 이 특성이 현장에서 얼마나 필요할까? 예전에 가끔 로컬에서 중간 중간 커밋하고 싶다는 생각을 한 적이 있다. 하지만, 당시 내가 그런 생각을 했던 이유는 지속적 통합을 하지 않고 있었기 때문이었다. 나는 소스를 광범위하게 고치고 있었고, 다음 수정에서 무엇인가 잘못되어 예전에 작업한 부분도 없어질까 봐 두려웠다. 하지만, 지속적 통합을 실천하며 다시 이런 생각을 한적은 없었다. 항상 동작하는 버전을 자주 커밋했다. 때로 1시간에 수십회를 커밋하기도 했다. 테스트가 통과하면 바로바로 커밋하기 때문이다. 

6. Git은 머지가 편하다?

가끔 Git과 같은 분산저장소를 사용하면 머지가 편해진다는 얘기를 듣는다. SVN에서 소스충돌은 다른 개발자가 같은 라인을 수정해서 발생하기도 했고, 어떤 때는 SVN의 오판으로 발생하기도 했다. 소스충돌이 일어났을 때 소스를 정리하는 작업은 정말 어렵고 힘들다. 따라서 Git이 머지를 편하게 해준다면 이는 큰 매력이다. 하지만 Git홈페이지(http://git-scm.com/about)를 보면 여러 장점을 소개하지만 머지에 대한 언급은 없다. 어디서 이런 얘기가 나왔는지는 모르겠지만, 확인이 필요한 부분 같다.

7. 결론

Git이 제공하는 가장 주요한 특징은 분산 저장소이다. 많은 오픈소스에서 Git을 잘 쓰고 있는 것처럼, 분명히 분산 저장소라는 특징이 빛나는 상황이 있을 것이라 생각한다. 하지만, 이 점이 Git으로 전환할 만한 충분한 이유가 될까? 난 아직 잘 모르겠다. 지금까지 내가 이해한 수준에서는 전환비용을 감당하면서도 넘어가야 할 이유를 찾기 어렵기 때문이다. 오히려 가뜩이나 잘 되지 않는 지속적 통합을 더 악화시키지 않을까라는 우려가 있다. 하지만 Git이 SVN 보다 머지기능이 탁월하다는 것이 밝혀진다면, 이는 Git으로 전환해야 하는 좋은 근거가 되리라 생각한다.

8. 참고

1) C와 같은 개발 환경에서는 Git이 지속적 통합에 해가 된다기 보다는 오히려 여러 장점이 있다는 의견을 담은 글
http://hyukhur.tumblr.com/post/4126008077/git-for-more-continuous-building 

2) 덧글 중 benelog님의 반대 의견도 참고

3) benelog님의 Git 유랑기 



WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
앞선 글에서 영향력 검토, 검증방법, 검증시점이 리팩토링 후 검증에 있어 필수적으로 고려해야 하는 부분이며 검증비용에도 영향을 미친다고 얘기했습니다. 이에 따라 단위 테스트를 분류 해보자면 검증방법으로써 분류될 수 있습니다. 하지만 단위 테스트의 탁월한 점은 단위 테스트가 검증방법으로써 가장 탁월한 선택 중 하나가 되면서 동시에 영향력 검토와 검증시점에도 긍정적 영향을 미친다는 점입니다. 위 세 가지 관점에서 단위 테스트를 평가해보았습니다.

첫째 단위 테스트는 영향력을 줄이는 데 도움이 됩니다. 단위 테스트를 하게 되면 자연스레 의존성에 대해 생각하게 됩니다. 어떤 대상에 대해 테스트를 하려면 해당 대상을 테스트 가능한 상태로 준비시켜야 하는데 이때 의존성을 없애고 단위 테스트로서의 초점을 좀 더 명확하게 하기 위해 의존성 중지(Dependency Breaking)를 하게 됩니다. 즉, 데이터베이스에 질의하는 부분을 담당하는 DAO(Data Access Object)를 사용하고 있다면 테스트 시 관심초점이 아닌 데이터베이스에 질의하는 부분을 실제로 수행하기보다는 해당 DAO를 데이터베이스에 성공적으로 질의한 것처럼 행동하는 가짜(Stub, Fake Object, Mock 등)로 바꾸는 것입니다. 이런 과정을 통해 개발자는 여러 의존성을 느끼게 됩니다. 너무 많은 의존성이 있다고 느끼는 것은 그만큼 연결된 곳이 많다는 증거이고, 이는 영향 범위를 다시 생각해보라는 신호가 될 수 있습니다. 만약 이 신호에 귀를 기울인다면 영향범위를 좀더 줄여볼 수 있습니다. 이것은 OOP(Object Oriented Programming)에서 강조하는 의존성 최소화(Loosed Coupling)와 같은 맥락입니다.

둘째 단위 테스트는 검증비용을 줄여줍니다. 검증비용을 줄이는 데에는 크게 두 가지 부분이 작용합니다. 단위 테스트는 매우 빠르게 수행된다는 점과 한번 작성해놓은 단위 테스트는 큰 노력 없이 다시 실행할 수 있다는 점입니다. 이 부분은 사람이 테스트를 수행하는 것과 비교할 때 좀 더 명확해집니다. 사람이 어떤 기능 10개를 테스트 할 때 하나에 1분씩 본다고 해도 10분이 걸립니다. 또한 나중에 같은 테스트를 해보려면 또 10분을 투자해야 합니다. 하지만 단위 테스트를 그렇지 않습니다.

마지막으로 단위 테스트는 검증시점을 앞당겨 줍니다. 예전에 여러 코드에 존재하는 잘못된 코드 관례(Code Convention)를 수정해야 했습니다. 이 작업을 수동으로 하기엔 작업범위가 넓었기 때문에 정규표현식을 이용하여 한꺼번에 수천 개의 파일을 수정했습니다. 수정 후 특별히 컴파일 오류가 발생하지 않았고 저는 잘 되었다고 생각하고 커밋(Commit)을 했습니다. 그런데 몇 분 후 CI서버에서 메일이 한 통 왔습니다. 내용을 보니 특정 단위 테스트가 실패했다는 메일이었습니다. 자세히 살펴보니 방금 수정하면서 오류가 새롭게 생겨 발생한 문제였습니다. 저는 바로 코드를 롤백(Rollback)했고, 정규표현식을 고쳐 다시 파일을 수정한 후 일을 마무리 지을 수 있었습니다. 만약 단위 테스트가 없었더라면 어떤 결과가 일어났을까요? 코드 관례에 관계 되어 다소 부담이 적은 수정이었고 컴파일 오류 또한 발생하지 않았기 때문에 십중팔구 그냥 모르고 지나갔을 것입니다. 게다가 너무 광범위한 수정이라 QA를 받기 어려워 QA를 따로 받지 않았을 것입니다. 결국 서비스 중에 문제가 발생했을 테고 고객문의가 들어왔을 것입니다. 하지만 단위 테스트가 있었고 CI가 커밋이 되는 순간 테스트를 수행하고 실패한 경우 메일을 보내주었기 때문에 문제를 조기에 인식할 수 있었습니다.

이렇게 단위 테스트는 모든 방면에 있어 탁월함을 자랑하며 이로 인해 리팩토링에 대한 투자비용을 상당부분 줄여줍다. 다만 단위 테스트를 작성하는 데는 다소의 초기비용이 필요합니다. 하지만 리팩토링 뿐 아니라 어떤 형태로든 코드는 계속 변한다는 점을 생각해볼 때 단위 테스트를 작성해놓는 것은 계속적으로 도움을 줄 것이고 시간이 가면 갈수록 현명한 투자라고 느끼게 될 것입니다.

이어 단위 테스트는 인터페이스 변경 없이 내부코드만 변경이 있을 경우 그 영향력이 아무리 넓다 하더라도 영향력을 깨끗이 제거해줄 수 있습니다. 변경범위의 측면에서 내부코드의 변경은 인터페이스 변경과는 확연하게 구분되는 중요한 특징을 가집니다. 그것은 인터페이스 변경은 영향을 받는 곳 즉 해당 인터페이스를 사용하는 곳의 변경도 필요한 반면, 내부코드 변경의 경우는 영향 받는 곳의 코드변경은 없다는 점입니다. 이 점을 통해 알 수 있는 사실은 만약 우리가 변경되는 내부코드의 변경 전/후의 동일성을 확실히 보장한다면 내부코드 수정으로 말미암아 영향 받는 부분에 대해서는 더는 신경 쓰지 않아도 된다는 것입니다. 왜냐하면 변경이 발생한 곳은 내부코드뿐이고 내부코드의 동작은 전과 동일하기 때문입니다. 그리고 이것을 가능하게 해주는 것이 단위 테스트입니다. 그렇다면 단위 테스트를 이용하여 변경 전/후의 동일성을 확실히 보장하기 위해서는 어떻게 해야 할까요? 이 부분은 무척 어려운 주제라 생각하지만 본인의 개인적인 경험을 이야기하면 약간의 참고가 될 수 있으리라 봅니다.

저는 지난 리팩토링 프로젝트에서 리팩토링을 시작하기 전, 즉 변경 전 기준으로 단위 테스트를 신중하게 작성했습니다. 가장 먼저 주요하게 자주 실행되는 부분(주 흐름, Main Flow)에 대해서 테스트를 작성했습니다. 만약 테스트가 통과하면 예외적 흐름에 대해서도 테스트를 작성했습니다. 제가 인지하고 있는 모든 흐름을 테스트 한 후에는 커버리지(Coverage) 측정 도구를 수행해보았습니다. 커버리지 측정 도구는 아래 그림처럼 실행 된 코드 경로는 녹색으로 보여주었고 단위 테스트가 실행하지 않은 부분은 빨간색으로 보여주었습니다. 그리고 만약 빨간색 부분이 보이면 그 부분이 실행되도록 단위 테스트를 더 보강하였습니다.


그림#1. 실행 된 부분과 실행되지 않는 부분을 구분할 수 있다. 위 화면은 Undercover를 이용하여 생성했다.

이렇게 했던 이유는 단위 테스트에 의해 실행되지 않는 부분이 테스트 되지 않아 동일성 보장에 허점이 생기는 것을 방지하기 위함이었습니다. 이렇게 변경 전 기준으로 테스트 작성을 완료하고 나서야 리팩토링을 시작했습니다. 조금 고치고 테스트 수행을 해서 통과하면 다시 조금 고치는 것을 반복했습니다. 그리고 모든 리팩토링이 완료 되면 QA 부서에 리팩토링 완료를 알렸습니다. 하지만 때때로 영향력 범위 등의 문제로 QA가 검증하는 것이 합리적이지 않다고 판단하면 QA부서를 통하지 않고 리팩토링을 바로 완료시키기도 했습니다. 이것은 제가 무모해서가 아니라 단위 테스트에 의해 동일성이 보장되었다는 자신감이 있었기 때문에 가능했던 일입니다.

동일성을 보장했음에도 QA단계를 거쳤던 것은 계속적으로 강조했던 것처럼 이중검증을 해서 단위 테스트에서 동일성 보장을 하려 했음에도 실수 등으로 인해 생길 수 있는 문제를 발견하기 위해서였습니다. 이 판단은 틀리지 않았는데 아무리 신경 써서 단위 테스트를 만들어도 이후에 때로 잘못된 부분이 발생되곤 했기 때문입니다. 이로 인해 단위 테스트만으로는 부족함이 있다는 것을 깨달았으며 인수(Acceptance Testing) 테스트의 필요성을 느꼈습니다.

추가로 이렇게 많은 도움을 주는 단위 테스트를 만드는 것도 중요하지만 제가 코드 관례를 수정할 때 경험했던 것처럼 단위 테스트를 실제로 실행하여 잘못된 부분에 대한 피드백(Feedback)을 빠르게 받는 것도 매우 중요합니다. 하지만 큰 규모의 환경에서 순수한 단위 테스트와 데이터베이스 혹은 외부 네트워크와 통신하는 통합 테스트가 섞여 있을 때 로컬 개발 환경에서 무엇인가를 수정 할 때마다 모든 테스트를 수행해보는 것은 실행속도 때문에 개발자에게 부담스러운 일이 됩니다. 따라서 빠른 개발을 위해 본인이 현재 고치고 있는 부분에 대해서만 테스트를 수행하게 되는 경향이 있습니다. 하지만 내가 부분적으로 고치고 있다고 생각하는 부분이 다른 곳에도 영향을 주는 경우는 많습니다. 이런 경우 CI 서버의 커밋빌드를 활용하면 좋습니다.

유명한 CI 서버 대다수가 커밋빌드 기능을 제공합니다. 커밋빌드란 소스가 저장소에 커밋 되는 순간 CI 서버가 알아차리고 빌드와 테스트를 수행하는 기능입니다. 만약 컴파일이나 테스트가 실패하면 CI 서버는 커밋한 개발자에게 메일이나 SMS를 발송하여 실패를 알립니다. 개발자는 이런 알림을 이용하여 빠르게 문제발생을 인지할 수 있고 결국 검증시점이 앞당겨지는 것과 동일한 효과를 취하게 됩니다.

수정 이력
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.


WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
인터페이스를 수정하는 경우 제게 있어 가장 인상 깊었던 부분은 컴파일러가 영향력 검토에 있어 매우 중요한 역할을 한다는 것이었습니다. 예를 들어 특정 메서드의 인자를 변경해야 한다고 가정해봅시다. 해당 메서드의 인자를 변경하고 컴파일을 수행합니다. 이때 만약 컴파일 오류가 발생한다면 해당 메서드를 사용하고 있는 곳이 있다는 뜻이며 변경에 따라 영향을 받는 곳이 있다는 증거입니다. 실제로 컴파일은 이클립스와 같은 IDE를 통해 실시간으로 이뤄지기 때문에 개발자는 매우 빠르고 정확하게 영향력 검토를 할 수 있습니다.

하지만 이 같은 컴파일러의 지원에도 영향력 검토가 쉽지 않은 경우가 있습니다. 대표적인 경우 중 하나는 클래스 경로 정보를 갖고 있는 설정 파일입니다. 최근 많이 사용되는 여러 프레임웍에서는 설정 파일에 클래스 경로를 적게 하고 실행 시에 그 정보를 이용하여 클래스를 동적으로 생성합니다. 이런 경우 해당 클래스의 이름이나 위치가 변경되었을 때 컴파일러를 통해서는 영향력을 확인할 수 없게 됩니다. 또 한 가지 대표적인 경우는 JSP의 표현식(Expression Language)에서 특정 클래스의 메서드를 참조하는 경우입니다. 이 경우에도 역시 컴파일러를 통해서는 영향력을 확인할 수 없습니다. 따라서 이런 부분에 대해 자동으로 영향력 검토를 해주는 도구가 없는 경우, 설정 파일이나 JSP의 표현식과 같은 영역에 대해서는 개발자가 직접 검색을 하는 등의 방법을 통해 영향력 검토를 수행해야 합니다. 이런 경우 컴파일러만을 이용하여 영향력 검토를 할 경우보다 훨씬 더 큰 비용이 필요해지며 사람이 개입함으로 인해 실수가 생길 확률도 높아지게 됩니다. 따라서 컴파일러를 이용한 영향력 검토는 한계가 있다고 볼 수 있습니다.

한편 컴파일러를 검증방법으로써도 활용할 수 있습니다. 마틴 파울러의 리팩토링을 보면 메서드의 이름을 이해하기 좋게 바꾸거나 세부적인 코드의 변경 없이 특정 메서드를 다른 클래스로 옮기거나 하는 것도 리팩토링으로 분류하고 있습니다. 저 역시 지난 프로젝트에서 이러한 유형의 리팩토링을 많이 했습니다. 특히 첫 번째 리팩토링 프로젝트에서 코드를 수정하기 보다는 클래스나 메서드를 옮기고 이름을 바꾸는 등의 일을 많이 했습니다. 당시 저는 리팩토링 후 코드가 전과 같이 문제 없는 상태로 있다는 것을 어떻게 확신 할 수 있는지에 대해 부단히 고민했습니다. 그리고 위와 같이 클래스를 옮기는 등에 리팩토링을 가만히 살펴보았더니 이들에 대한 검증은 컴파일러가 맡고 있었습니다. 예전에는 컴파일러는 자바코드를 JVM이 실행 가능한 바이트 코드(Byte Code)로 변경해주는 도구라고만 생각했었습니다. 그러나 위 경험을 통해 컴파일러의 검증기능에 주목하기 시작했고 이어 컴파일러의 검증범위에 대해 생각해보게 되었습니다. 당시 작업을 하며 가장 어려울 때는 전에 얘기한 설정파일이나 JSP 표현식이였습니다. 이 부분은 컴파일러에서 검증하지 못했습니다. 결국 컴파일러의 검증범위 밖에 있는 것들이 문제였고 이런 부분들도 컴파일러에서 검증할 수 있으면 얼마나 좋을까라는 생각을 했습니다. 즉 컴파일러의 검증범위가 좀더 넓어졌으면 좋겠다고 생각한 것입니다.

이 때문인지 몰라도 Effective Java 2판의 저자인 Joshua Bloch는 그의 책을 통해 무엇인가 잘못 되었을 때 컴파일러가 알아차릴 수 있게 코드를 작성하는 것을 강조합니다. 저는 컴파일러가 검증방법으로써 이점이 있지만 한계 또한 있다는 점을 이미 언급했습니다. 하지만 컴파일러 검증을 이용하면 테스트 보다 더 이른 시점에 검증이 가능하다는 점과 단위 테스트와 검증부분이 중복 된다 하더라도 이중검증을 할 수 있다라는 점 때문에 Effective Java 2판의 내용과 같이 컴파일러의 검증범위를 넓히려는 노력은 매우 합리적이라 봅니다.

아래는 Effective Java 2판에서 저자가 강조했던 내용 중 실무에서 자주 발생하는 사례를 정리한 것으로써 컴파일러의 검증범위를 넓히기 위해 활용될 수 있습니다.

1. Generic 활용

Generic을 사용하지 않는 코드
List myIntList = new LinkedList();
myIntList.add(new Integer(0));
String x = (String) myIntList.iterator().next();

위 예제는 Generic을 사용하지 않고 List를 사용하는 예제입니다. 위 코드는 정상적으로 컴파일이 되지만 실행시점에 ClassCastingException이 발생합니다. 왜냐하면 두 번째 줄에서 Integer객체를 생성해 넣었는데, 세 번째 줄에서는 해당 객체를 String 사용하려고 했기 때문입니다. 여기서 주목해야 할 점은 오류를 컴파일 시에는 발견할 수 없었다는 점입니다. 하지만 자바 1.5에서 도입 된 Generic로 말미암아 컴파일 시점에 위 오류를 발견할 수 있게 되었습니다.

Generic을 활용한 코드
List<Integer> myIntList = new LinkedList()<Integer>;
myIntList.add(new Integer(0));
String x = myIntList.iterator().next();

위 예제는 Generic을 사용하여 바뀐 코드입니다. 위 예제는 첫 번째 예제와는 달리 세 번째 줄에서 컴파일 오류가 발생합니다. 왜냐하면 해당 List는 Integer로 사용하기로 결정되었기 때문에 String으로 사용할 수 없기 때문입니다. 위와 같이 Generic을 이용하면 컴파일러에서 더 많은 검증을 할 수 있습니다.

2. Enum 활용

Enum을 사용하지 않는 코드
public boolean isModifable(String osType) {
... // 유효한 osType은 Linux, Window이다.
}

위 코드에서 볼 수 있듯이 예전에는 누군가가 실수하여 type에 "Computer"라는 문자열이 잘못 들어와도 컴파일러가 검증할 방법이 없었습니다. 예를 들어 허용되지 않는 문자열인 Computer가 데이터베이스에 저장되어도 그것을 특별히 검사하는 코드가 없다면 문제를 발견하기 어려웠습니다. 하지만 Enum에 도입으로 컴파일 시점에 오류를 발견할 수 있게 되었습니다.

Enum을 활용한 코드
public boolean isModifable(OSType osType) {
...
}

public enum OSType {
LINUX, WINDOW
}
        
위와 같이 Enum에 사용으로 OSType에 미리 정의되지 않은 값은 넘길 수 없게 되었습니다. 만약 LINUX나 WINDOW가 아닌 다른 타입을 넘기려고 하면 컴파일 오류가 발생할 것입니다.  

3. Switch 문을 Constant-specific methods 로 변경

Constant-specific methods를 사용하지 않는 코드
public enum Operation {
  PLUS, MINUS, TIMES, DIVIDE, POWER;

  double eval(double x, double y) {
    switch(this) {
      case PLUS:   return x + y;
      case MINUS:  return x - y;
      case TIMES:  return x * y;
      case DIVIDE: return x / y;
    }
    throw new AssertionError("Unknown op: " + this);
  }
}

위 예는 SUN의 공식 문서에서 가져온 예입니다. 위 예는 컴파일도 잘 되고 동작도 잘 됩니다. 하지만 자세히 보면 POWER 타입이 추가 되었는데 실수로 switch 문에 새로운 타입에 대한 코드를 넣지 않았음을 볼 수 있습니다. 이 때 컴파일은 잘 되지만 실행 중 오류가 발생합니다.

Constant-specific methods를 사용하지 않는 코드에 Type 추가 시
public enum Operation {
  PLUS   { double eval(double x, double y) { return x + y; } },
  MINUS  { double eval(double x, double y) { return x - y; } },
  TIMES  { double eval(double x, double y) { return x * y; } },
  DIVIDE { double eval(double x, double y) { return x / y; } };

  abstract double eval(double x, double y);
}

그래서 코드를 위와 같이 작성하면 eval 메서드를 사용하는 측에서는 코드 변경이 전혀 없으면서도, 타입이 추가 되었을 때 eval 메서드를 구현하지 않으면 컴파일 오류가 발생하게 됩니다.

저는 컴파일러를 이용한 영향력 검토와 검증방법으로써 사용이 가능하지만 한계가 있다는 점을 설명했습니다. 또한 Effective 2판의 조언에 따라 컴파일러 검증범위의 확장이 가능한 점 또한 설명했습니다. 하지만 여전히 컴파일러의 검증범위는 미비하며 컴파일러를 아무리 잘 활용해도 검증하지 못하는 범위가 많음을 알 수 있습니다. 따라서 컴파일러를 적극적으로 활용해야 할 필요는 있지만 한편으로는 컴파일러가 하지 못하는 부분에 대한 검증을 시도해야 할 필요가 있습니다. 이 점이 바로 단위 테스트, 인수 테스트, End-To-End 테스트와 같은 테스트가 필요한 이유입니다.

수정 이력
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,