본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

개발자들이 꼽은 '우리에겐 너무 어려운 9가지 업무'

OSS 게시글 작성 시각 2013-10-22 15:37:57 게시글 조회수 5381

2013년 10월 21일 (월)

ⓒ CIO Korea, Phil Johnson | ITWorld


개발자가 아닌 사람들은 대부분 소프트웨어 개발이 어렵다고 생각한다. 그리고 실제로 코딩은 어렵다. 그렇다고 해서 얼마나 어려운지에 대해 일반인들이 알 수 있는 것은 아니다. 쿠오라(Quora) 웹 게시판의 최근 토론에서 개발자들이 업무를 하는 도중 직면하게 되는 가장 어렵다고 느끼는 부분에 대해 공유했다. 이 게시판과 우분투 포럼(Ubuntu Forums) 등 다른 포럼의 글을 모아 IT월드는 개발자들에게 가장 어려운 업무 9가지를 모아봤다. 이를 통해 알 수 있는 것은 코드 작성이 개발자들에게 있어 가장 어려운 부분이 아니라는 것이다. 전업 소프트웨어 개발자라면 여기서 소개하는 것들 중 몇 개나 여러분에게 해당되는지 살펴보자.


9. 솔루션 디자인
업무: 고객의 요구사항을 고려하여 IT솔루션의 구현을 디자인하고 설계하라. 여기에는 데이터 및 코드 구조, 기능적 알고리즘, 비즈니스 로직을 압축하고 안정된 사용을 보장하는 애플리케이션 플로우의 디자인도 포함된다.
문제: 고객의 요구사항을 충족하는 솔루션을 디자인하라. 이는 고객들이 합당하다고 생각해야 하며 일정표에 맞게 구축해야 한다.
인터넷 의견: “처음부터 끝까지 총체적으로 하나의 프로젝트를 완결 짓는 부분을 생각하는 것이 가장 어려운 부분이었다.” (ID : misconfiguration)
“만약 당신의 디자인이 너무나 육중하다면 그 자체의 무게로 무너질 것이다. 반대로 너무 빈약하다면 쓸모가 없다.” (ID : nvteighen)
“고객들과 일을 시작하기 전까지는 실제로 일이 어떻게 흘러가게 되는지에 대해 예상하기 어렵다.” (ID : jpkotta)
이미지 출처 : flickr/spare parts


8. 테스트 작성(Writing tests)
업무: 개별 기능과 루틴 점검을 통해 사전 정의된 기준을 준수하고자 소프트웨어의 일부 유닛에 대한 프로그래밍 테스트를 실시한다. 이것이 즉 유닛 테스트 작성(Write unit tests)이다. 이러한 테스트를 통해 개발 초기에 버그를 발견하고 코드가 수정되거나 업데이트 될 때 퇴행 테스팅(regression testing)을 가능하게 해주었다. 일부 개발 방법론은 코드 개발 전에 이루어 지는 테스트 시행을 유도하지만, 그 반대의 경우도 많다.
문제: 테스트를 선택하고 이를 코딩하는 것은 지루한 과정일 수 있다. 애플리케이션 개발이 더해 막중한 업무가 주어진다고 느끼게 될 것이다.
인터넷 의견: “테스트 작성(Writing tests)이 어려운 건 아니지만, 좋아하지 않는다. (ID : 익명)
이미지 출처 : flickr/Lachlan Hardy


7. 문서 작성(Writing documentation)
업무: 코드의 역할 설명이나 애플리케이션의 동작을 확인하기 위한 문서를 만들어라. 독립적인 문서나 코드 코멘트를 포함할 수도 있다. 그리고 사용자나 개발자들이 이를 읽게 될 사람들이다.
문제: 시간이 많이 소요될 수 있어 읽는 사람이 없을 경우 시간낭비로 여겨질 수 있다. 개발자들은 보통 문서를 만들기 위한 코드작성을 선호한다.
인터넷 의견: “아무도 읽지 않고 사용하지 않아도 단순히 ‘절차’의 일부기 때문에 문서를 작성하는 것은 불필요한 일이다.” (ID : Christian Dechery)
“적절히 잘 쓰여진 문서는 실제 내용이 무엇인지 코드를 살펴보지 않아도 알 수 있게 해준다.” (ID : Raghu Nandan)
“문서 작성은 간결하면서도 잘 설명돼 있어야 하며 동시에 우수해야 한다.” (ID : Ayush Goel)
이미지 출처 : flickr/United States Mission Geneva


6. 개발자 자신이 동의하지 않는 기능을 구현하는 것
업무: 어떠한 이유에서라도 개발자는 필요하다고 여기지 않는 반면, 고객이나 상사가 지속적으로 넣어야 한다고 주장하는 기능을 구현하는 것
문제: 개인적인 감정이나 의견을 제쳐두고 문제가 되는 기능을 구현하고 지원하기 위해 상당한 시간과 노력을 들여야 한다.
인터넷 의견: “일하다가 미쳐버릴 수도 있고 조기 은퇴를 고려할 수도 있다.” (ID : Sabbir Asgar)
이미지 출처 : flickr/osaka19


5. 다른 사람이 작성한 코드를 다루는 것
업무: 다른 개발자가 작성한 코드의 일부분이나 애플리케이션의 유지, 디버깅, 개선을 도모하는 것
문제: 기존 코드의 작동을 이해하고 원 개발자의 의도를 이해하고자 노력해야 한다. 하지만 이는 개발자가 주변에 있지 않거나 코드가 잘못 짜여졌거나 설명이 충분하지 않거나 관련 문서가 없는 경우 더 어려워진다.
인터넷 의견: “제대로 작성되지 않은 코드를 개선시키고자 한다.” (ID : Omar Diab)
“능력이 떨어지는 사람들이 짜놓은 코드를 찾아내는데 많은 시간을 보내고 있다. 왜냐하면 이러한 코드들은 사실...” (ID : Nani Tatiana Isobel)
“코멘트가 달려있지 않은(uncommented) 수천 라인의 코드를 해독해야 한다.” (ID : Simon Zhu)
이미지 출처 : flickr/Garrett


4. 사람을 대하는 것
업무: 고객으로부터 요구사항을 확인하고 경영진에게 현황보고서를 제출하고 프로젝트에 대해 테스터들과 같이 일하고 엔지니어들에게 상의하는 것
문제: 비전문가들에게 기술적 내용에 대해서 설명하는 것, 다른 이들로부터 업무 간섭을 받는 것, QA쪽 관계자나 다른 개발자들의 의견에 맞서는 것
인터넷 의견: “사람들과 일하는 것 보다 차라리 프로세서를 납득 시키는 것이 더 편하다.” (ID : Marko Poutiainen)
“엔지니어가 아닌 사람들이 간섭할 때 이를 해결하는 것, 엔지니어들이 코드작성과 관련해 이야기 할 때 이를 해결하는 것…” (ID : 익명)
“…IT지식이 없는 사람들과의 의사소통은 어렵다.” (ID : lnostdal)
“우리를 막고 있는 다른 팀이 업무를 마무리 지을 때 까지 기다리는 것…” (ID : 익명)
이미지 출처 : flickr/Ray Crane


3. 업무 완료에 필요한 시간을 예상하는 것
업무: 프로젝트 시작부터 업무 완수에 필요한 예상시간을 산정하는 것
문제: 업무를 시작해보기 전에 얼마나 오래 걸릴지 예상하는 것은 어려운 일이다. 예상시간을 내놓더라도 요구사항이 명확하지 않고 예상치 못했던 문제에 대해 해결할 시간도 할당해야 하기 때문이다.
인터넷 의견: “프로그래밍 단계 이전에 얼마나 많은 프로그래밍 관련 문제가 발생할지 예측하는 것은 매우 어려운 일이다.” (ID : Jan Christian Meyer)
“대부분의 사람들은 예상시간을 제시할 때 이에 거의 맞게 프로젝트가 완료된다고 생각하기 때문에 쉽게 이를 제시하기가 쉽지 않다.” (ID : Samnang Chhun)
“프로젝트 종료시점을 예상하는 것은 사실상 불가능하다…” (ID : Jack Menendez)
이미지 출처 : flickr/Faith Raider


2. 무엇이 내 업무고 무엇이 아닌 지를 설명하기
업무: 개발자가 아닌 사람들(가족, 친구, IT종사자가 아닌 사람)에게 업무상 어떤 일을 하고 어떤 일을 하지 않는지 설명하는 것
문제: 자신이 생계를 위해 어떤 일을 하는지 가족과 친지들이 이해하지 못한다는 점이다. 컴퓨터와 관련된 문제라면 어떤 것이라도 지속적으로 질문 받는다.
인터넷 의견: “내가 그들의 컴퓨터를 고칠 줄 모른다는 사실을 설명해야 한다.” (ID : Brandon P-Lost)
“가족들에게 설명하는 것이 실제로 내가 하는 것이다.” (ID : Utsav Singh Rathour)
“보통사람들에게 하루 종일 프로그래밍만 하는 것이 아님을 설명한다.” (ID : Anand Safi)
“사람들에게 내가 그들의 PC에 사용할 수 있는 모든 해적 OS나 소프트웨어를 갖고 있는 것이 아님을 설명한다.” (ID : Anbu Jey)
이미지 출처 : flickr/Bruce Turner


1. 작명(Naming things)
업무: 변수(variables), 프로시저(procedures), 함수(function), 클래스(classes), 오브젝트(objects), 데이터베이스 컴포넌트(database components) 등에 대해 이름을 짓는 것
문제: 소규모 프로그램이나 애플리케이션이라고 해도 이름을 지어줘야 한다. 애플리케이션의 특성을 역할 고려하여 간략한 이름을 짓는 것이 필요하다.
인터넷 의견: “의미에 부합하는 다양한 이름을 내놓아야 한다.” (ID : Aditya Muraletharan)
“데이터 멤버와 기능을 위해 의미 있는 이름을 만드는 것.” (ID : Lakshman Siripurapu)
“컴퓨터과학에서 중요한 것은 단 두 가지뿐이다. 캐시 무효화(cache invalidation)과 이름 작명이다.” (ID : Phil Karlton)
“…잘못 지어진 이름을 고치고 중복된 부분을 제거할 수 있게 되고 난 후에야, 객체 지향 디자인(object-oriented design)을 배울 차례다.” (ID : J. B. Rainsberger)
이미지 출처 : flickr/Jeremy Keith




※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지



[원문출처 : http://www.ciokorea.com/slideshow/18711]

맨 위로
맨 위로