개발도구의 역사 - vi 에디터부터 아톰까지

[컴퓨터월드]

▲ 김차영 투비소프트 국내사업본부 프리세일즈팀 팀장

과거 필자가 처음 IT업계에 발을 들여 놓은 2000년 이전에는 파워빌더(PowerBuilder)나 델파이(Delphi)같은 RAD(Rapid Application Development) 도구가 많이 사용되던 시기였다. 하지만 필자가 처음 접한 것은 vi(Visual Editor)였다.

당시 팀장의 반강제적인 권유로 일부 업무를 vi로 진행했다. 그 시기에 불편한 라인 에디터를 사용했던 개발자들에겐 vi는 가볍고 강력한 기능을 제공했었다. vi는 경쟁적으로 많이 사용됐던 이맥스(Emacs)와 함께 50년 넘게 사용되고 있다.

▲ vi와 경쟁구도를 만들었던 이맥스

과거부터 개발도구는 언제나 더 빠르고 품질 좋은 소프트웨어 개발을 목표로 변화해 왔으며, 그 중 생산성 향상은 새로운 도구가 가져야 할 중요한 덕목 중에 하나였다. 1983년에 터보 파스칼(Turbo Pascal)이 출시되면서 상용 통합개발환경(IDE, Integrated Development Environments)의 시작을 알렸고 개발자들이 생산성에 대해서 고민하게 되는 계기가 됐다. 이후 파워빌더와 델파이는 위지윅(WYSIWYG, What You See Is What You Get)이라는 혁신적인 인터페이스로 RAD 또는 4GL(4 Generation Language) 도구로 인식되며 생산성 최강자로 등극했다.

한편, 개발 도구의 명가인 마이크로소프트는 비주얼 스튜디오(Microsoft Visual Studio)를 제공하면서 강력한 기능과 개발 편의성을 기반으로 프로그램, 웹 사이트, 웹 프로그램 등을 폭넓게 지원하였고, 마이크로소프트 개발자 네트워크(Microsoft Developer Network, MSDN)를 통해 체계적이고 방대한 기술정보를 제공함으로써 개발자들의 적극적인 지지를 받았다.

▲ 개발도구 분류

이렇게 견고한 마이크로소프트와 비주얼 스튜디오 생태계를 겨냥해서 오픈소스 진영에서는 막강한 기능의 이클립스(Eclipse)를 내놓았다. 이클립스는 원래 IBM의 웹스피어 스튜디오 애플리케이션 디벨로퍼(WebSpheare Studio Application Developer)라는 이름으로 개발됐던 것인데, 엔진부분을 오픈소스로 공개하면서 지금의 이클립스로 발전해왔다.

다양한 플랫폼에서 사용할 수 있는 이클립스는 자바를 비롯한 여러 언어를 지원하며 현재는 OSGi(Open Service Gateway initiative)를 도입, 범용 응용 소프트웨어 플랫폼으로 진화했다.

▲ 웹 개발도구 서브라임텍스트와 아톰

2014년 10월 HTML5가 표준으로 확정되면서 웹 개발도구가 우후죽순처럼 시장에 나왔다. 예전에는 마크업을 손쉽게 도와주는 드림위버(Dreamweaver)같은 편집기가 유행했으나 불필요한 태그들을 남발하거나 유연성이 부족했다. 요즘에는 가볍고 확장성이 좋은 서브라임텍스트(SublimeText)나 아톰(Atom)을 국내외 많은 개발자들이 사용하고 있으며, 다양한 플러그인을 제공하면서 그 편의성이 날로 향상되고 있다.


개발도구의 선택은 어떻게 해야 할까?
고객사 담당자를 만나보면 프로젝트를 앞두고 개발도구를 결정하는 경우가 있는데, 객관적으로 보기엔 고객사나 프로젝트 상황과 다소 동떨어진 선택으로 프로젝트에 악영향을 미치곤 한다.

예를 들면 개발자들의 의견이 반영되지 않고 비용만을 기준으로 삼는 경우, 의사결정자나 SI 수행사가 특정 벤더와의 친분으로 그 제품만을 고집하는 경우에 프로젝트가 힘들어지거나 좋지 않은 결과로 이어지는 경우가 많다. 따라서 개발자들의 의견을 적극 수용하고 고객사나 시스템 성격을 고려해 사전 검증과 절차를 거쳐 선택해야 한다. 그렇다면 어떤 기준과 절차로 선택하는 것이 현명할까?

1. 해당 고객사의 상황과 시스템의 성격을 파악한다.
해당 전산환경이 닷넷 혹은 자바 기반인지, 구축 대상 시스템이 데스크탑 혹은 모바일인지, 내부업무 혹은 외부업무 여부 등 환경적 상황과 기술적 상황을 고려해야 한다.

2. 개발자의 의견을 적극 반영해 선택 기준을 마련한다.
개발자들이 필요로 하는 컴포넌트 또는 API가 제공되는지, 디버깅이 쉬운지, 기술지원은 원활한지 등을 꼼꼼히 따져봐야 한다. 예를 들면 특정 기능에 대해서 컴포넌트로 제공하는지 또는 구현을 해야 하는지 살펴보고 디버깅의 경우도 중단점(Break Point), 콜 스택(Call Stack), 배리어블(Variables), 왓칭(Watch) 등을 체크해 원하는 수준의 디버깅을 할 수 있는지 확인해야 한다.

3. 다양한 개발도구를 직접 사용해 본다.
도구에 대한 소개 자료만으로는 개발자들이 생각하는 것과 간극이 있을 수 있다. 사전에 벤더사 또는 오픈 커뮤니티 등의 교육 및 강좌도 받고 트라이얼 버전 등으로 직접 사용해볼 필요가 있다. 해당 객체의 속성, 메소드를 코드 인스펙터나 도움말 등으로 확인해 어느 정도 수준으로 구현해야 하는지 살펴보는 등, 중요하고 핵심적인 것들은 직접 확인하는 과정이 필요하다.


개발도구가 생산성을 보장할까?
위와 같이 개발자의 의견을 적극 반영하여 상황에 맞게 선택하면 생산성은 향상될까?

프로젝트에서는 개발 기간과 개발 분량, 그리고 투입 인력의 경력과 인력 수 등을 고려해 월 단위 인력투입(M/M, Men per Months)으로 비용을 산정한다. 하지만 프로젝트의 각 이해관계자들의 상이한 판단으로 프로젝트는 늘 쫓기듯 진행된다. 이런 부분을 감안해서 고객사와 개발사 등 상호 신뢰를 쌓을 수 있도록 객관적인 산정기법을 적용해 왔다.

▲ 비용산정 방식

하지만 프로젝트에서는 제조업과 달리 ‘사람’이라는 변수에 따라 많은 오차가 발생한다. 제조업의 경우 목표에 맞춰 생산 공정라인을 가동하면 인풋(Input)에 따라 기대한 아웃풋(Output)이 발생되나, 프로젝트에서는 개발자의 능력이나 컨디션에 따라 결과물이 천차만별일 수 있다.

1960년대 새크먼(Sackman H), 에릭슨(Erikson WJ), 그랜트(Grant EE)등에 의해 진행된 연구에서 평균 7년의 경력을 가진 전문적인 개발자들의 생산성을 비교했는데, 코딩시간의 경우 최고와 최악의 개발자간 격차는 약 20배, 디버깅 시간은 약 25배, 프로그램 사이즈는 5배, 프로그램 실행속도는 약 10배 차이가 나는 결과가 도출됐다. 생산성 차이는 프로젝트 관리 프로세스, 개발 방법론 등 다양한 원인이 있겠지만 사람, 즉 개발자의 역량과 그 개발자가 사용하는 도구에 따라서 달라질 수 있다.


결론
SW개발 트렌드는 20여년 전 폭포수(waterfall) 방식부터 10여년 전 애자일(agile) 방법론, 그리고 그 뒤를 잇는 개발(development)과 운영(operation)의 통합을 뜻하는 데브옵스(DevOps), 최근 주목 받고 있는 마이크로서비스 아키텍처(MicroService Architecture, MSA)까지 변화를 거듭하고 있다. 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화와 방식 및 도구에 대한 고민은 계속 이어지고 있다.

이제 개발 도구는 단순히 개발을 도와주는 유틸리티가 아니다. 개발에 필요한 요구분석, 설계, 개발, 테스트, 배포, 운영관리 등과 같은 전 프로그램 개발과정(라이프사이클)을 통합해 애플리케이션의 품질과 수명을 좌우하고, 통합관리를 통해 개발자 본인의 생산성은 물론 IT 조직 생산성을 한 단계 높일 수 있다는 인식이 확산되고 있다.

인간의 역사는 도구의 역사이기도 하다. 인간은 도구를 쓰면서 자연스레 손을 사용하였고 이는 두뇌발달의 영향을 미쳤다. 도구는 도구일 뿐이지만 도구를 통해서 인간이 얻게 된 열매를 돌이켜 보면 개발자에게 도구는 생산성 그 이상이다.

저작권자 © 아이티데일리 무단전재 및 재배포 금지