Kenny's Java Programming

[원문]: Writing Software is Like Writing 프로그래밍은 글 쓰기와 같다 

by Bruce Eckel April 21, 2009 - Artima Developer Blog, 번역: 이현우(bless2k@nate.com)

번역

Writing Software is Like ... Writing

가끔 비유가 필요한 경우가 있다. 우리는 우리가 무엇을 하는지를 잘 알고 있다. 우리는 컴퓨터에게 일을 시킨다(Program). 그것이 할 수 있는 모든 것을. 그리고 우리는 그 일을 하기 때문에 그 일이 무엇을 의미하는지 잘 알고 있다.

그러나, 의사 결정권자 – 관리자, CEO, 고객, 이익 당사자, 등등 – 에게 소프트웨어 개발은 미스테리이다. 그들은 개발의 모든 것에 대해서 알고 싶어하지는 않지만 소프트웨어 개발을 대충이라도 예측할 수 있을 정도는 알고 싶어한다.

따라서 이해 당사자들에게 추상화(Abstraction)이 필요하다. 즉, 비유 말이다. 그러나 이러한 비유가 유용하기 위해서는 중요하지 않은 것을 숨기고 있는 그대로 보여주는 것이 필요하다. 우리는 오랫동안 이런 문제를 해결하지 못했고 언제나 우리의 언어로만 표현하였다. 그것은 우리들에게는 말이 되지만 우리는 유용한 비유나 그렇지 못한 것을 구별하지 못한다.

수학자나 엔지니어들이 초기의 프로그래머였기 때문에 우리는 자연스럽게 프로그래밍을 과학이나 엔지니어링으로 생각한다. 하지만 우리가 프로그래밍을 아무리 수학 공식이나 교량 건설과 같은 것으로 만들려고 해도 그렇게 되지 않는다.

이해 당사자들은 우리의 비유를 추종하며 그들이 관심 있는 것에 대해서 묻는다. “만약, 프로그램이 수학과 같은 것이라면 왜 항상 고장나는가? 수학은 옳거나 그러지만 소프트웨어는 단지 동작하지 않는다.” 그리고 나중에는 우리는 과학과의 비유를 포기한다. “만약 프로그램이 공학이라면 한 사람의 프로그래머를 다른 사람과 바꿔도 비슷한 결과를 얻어야 하는 것 아닌가?”

후자에 대해서는 이해 당사자들을 매우 놀라게 하는 원인이었다. 어쨌든 엔지니어들의생산성 수준은 비슷하다. 그리고, 최종적인 산출물도 검증이 가능하다. 엔지니어링에는 모순이 별로 없으며 따라서 “소프트웨어 엔지니어링”이라고 부를 수 있다면 비슷하게 모순이 없어야 한다.

이러한 문제에 대한 해결책으로는 두 가지 대표적인 접근 방법이 있다. 큰 부정(모든 차이를 부정하고 모든 소프트웨어 개발이 같은 척하기) 또는 작은 부정(이러한 차이는 우연한 것이고 모순은 제거할 수 있다)이다.

큰 부정은 전혀 들어맞지 않는다. 그러나 작은 부정은 계속적으로 “소프트웨어 엔지니어들의 표준화” 시도를 양산해 내었다. 대표적인 것이 자격증(certificaiton)이다. 만약 자격 검증 과정만 있다면 논란은 해소되고 소프트웨어 엔지니어 들은 진정한 엔지니어가 될 것이다. 그리고 그들 또한 모순이 없을 것이다.

다행히도 자격 검증은 한번도 제대로 된 적이 없다. 소프트웨어 개발자들이 그러한 것에 심각하게 신경 쓰지 않기 때문이다. 그리고 고용주들은 자격증이나 학위에 상관없이 가장 좋은 프로그래머들을 고용하기를 바라기 때문이다. 그리고 자격 검증 프로그램(기사 자격증, SCJP, OCP 등등)들은 언제나 돈을 벌기 위한 것이기 때문에 결국에는 시들해진다. 예를 들어서 나는 SCJP를 심각하게 고려하는 사람을 본 적이 없다. 좀 더 고수준의 자격증은 좀 더 재미있다. 하지만 그것들은 워크샵과 같아서 나에게는 시험처럼 느껴지지 않는다.

한 때 나는 모든 프로그래머들의 역할을 단순한 타이핑으로 제한함으로써 기계의 부속품과 같이 취급하려는 시도들을 조롱했다.

우리는 과학자가 아니며, 우리는 엔지니어가 아니다. 그렇다면 우리를 프로그래머가 아닌 사람에게 어떻게 설명해야 타당할 까? 어떻게 하면 프로그래머들과 프로젝트의 개개의 차이점과 프로젝트의 성패의 차이를 잘 설명할 수 있을까?

나는 이렇게 제안한다. 나는 이것이 모든 것을 설명할 수 있다고 생각한다. 비록 이것이 예측 가능한 행동을 바라며 한 프로그래머를 다른 프로그래머와 교체해도 동일한 결과를 얻기를 바라는 의사 결정권자들을 실망시킬 수 있지만 말이다. (이러한 작업들은 아직도 진행중이다. 예측 불가능 성을 보정하는 유일한 방법은 Agile 방법론 뿐이다. 이는 이해 당사자들과의 커뮤니케이션 대역폭(bandwidth)를 늘려준다.)

프로그래머는 작가와 같다.

... 이하 생략