12가지 필수적인 소프트웨어 개발 원칙과 개념

 


업계에 처음 발을 들여놓는 젊은 개발자들은 한꺼번에 많은 원칙과 개념에 대한 이야기를 듣게 된다. 관리자로 올라서는 경력 개발자는 그동안 피해 왔지만, 기술적인 측면에 폭넓은 영향을 미치는 비즈니스 개념에 대한 이야기를 듣게 된다.


다음은 지난 20년 동안 소프트웨어, 그리고 소프트웨어 비즈니스에 있어 가장 중요한 12가지 개념이다.

 

1. 권한 없는 책임

경력이 어느 정도 된다면 권한 없는 책임을 접해봤을 것이다.


극단적인 사례를 들면 경비원에게 분기별 수익 책임을 지우는 것이다. 경비원이 아무리 노력해도 회사의 수익성을 높일 수는 없다. 경비원이 영업 회의에 참석한다 해도 신참 영업 사원이 전화를 더 많이 걸도록 유도할 수는 없다. 영업 사원을 움직일 영향력이 없기 때문이다. 마케팅 회의에 참석해봤자 마케팅 부서에서 새로운 캠페인을 구상하도록 이끌 수도 없다.


물론 극단적인 예다. 그러나 짊어지는 책임과 실제 행사할 수 있는 영향력 사이의 격차는 그 정도가 얼만큼이든 스트레스의 원천이다. 권한 없는 책임은 조직적인 기능 장애를 나타내는 징후이며(모든 조직에 어느 정도는 있음), 해결책은 권한을 높이거나 책임을 낮추는 것밖에 없다.


2. 반복하지 말 것

 “반복하지 말 것” 원칙은 시스템에서 표현은 명확하게, 한 번만 해야 한다는 것이다. 코드 한 블록을 잘라내서 여러 곳에 붙여 넣을 경우 그 설계에는 결함이 발생한다. 그 결함을 가장 먼저 수정해야 한다.


이 원칙을 위반할 경우 시간을 낭비할 뿐만 아니라 유지보수 문제도 발생한다. 여러 지점에서 잘라내서 붙여넣기한 버그를 모두 찾아 수정해야 한다. 또한 보안 결함이 복제되는 경우를 상상해 보라.


이 문제를 수정하는 방법은 전체 아키텍처를 수정하는 것부터 코드 생성기, 종속성 주입에 이르기까지 많지만 어떤 방법을 사용하든 일단 수정해야 한다!


3. 필요할 일이 없다

앞으로 필요할 것 같아서가 아니라, 지금 필요한 기능을 구현하라. 앞으로 필요할 것 같다면 십중팔구 필요할 일이 없다. 나중에 정말 필요해지면 그때 가서 넣으면 된다.


모듈을 설계하면서 그 모듈이 이번 릴리스와 앞으로의 릴리스에서 해야 할 모든 작업을 미리 생각하고 반영하려 한다면 앞으로 일어나지 않을지도 모르는 기능까지 지원하는 쓸데없이 복잡한 소프트웨어를 만들게 된다.


미래를 예측하는 것보다 현실을 이해하는 편이 훨씬 더 정확하다. 현재에 집중하라.


4. 최소 실행 가능 제품

새로운 무언가를 만들 때 최선은 *할 수 있는* 모든 일을 시원찮게 하는 것보다 정말 잘 할 수 있는 최소한의 일을 하도록 하는 것이다. 이것을 최소 실행 가능 제품(Minimum Viable Product, MVP)이라고 한다.


MVP를 하면 사용자나 고객에게 유용성을 시연하기가 더 쉬워진다. 또한 잘못될 경우 고쳐야 할 부분도 더 적고 실패할 경우 잃을 투자도 더 적다.


5. 좁고 깊게

이 개념은 MVP와 관련된다. 모든 사람에게 모든 것을 줄 수는 없다.


제품이나 기업이 더 많은 일을 하려고 노력할수록 잘 할 수 있는 가능성은 낮아지고 비용과 복잡성은 높아진다. 넓고 얕은 것은 바람직하지 않다.


집중의 문제다. 규모가 큰 조직이나 성숙한 소프트웨어는 “플랫폼”과 사업부를 만들어 더 많은 리소스를 적용할 수 있지만 작은 회사는 한꺼번에 너무 많은 것을 하면 안 된다.


그러나 대규모 조직에도 “좁고 깊게” 원칙은 필요하다. 조직 또는 플랫폼의 각 부분에 대한 원칙으로 두어야 한다. 개별적인 폭이 모여 넓게 될 수는 있지만 각각의 요소는 깊어야 한다.


6a. 최소 비용(운영의 탁월성)

6b. 최고의 제품(제품 리더십)

6c. 최고의 토털 솔루션(고객 친밀성)

 “최고의” 또는 가장 효과적인 조직은 이 세 가지 전략 중 하나를 추구하는 조직이다. 결과적으로 이러한 조직은 가장 비용이 낮은 조직, 최고의 조직, 또는 최고의 서비스를 제공하는 조직이다.


가장 낮은 비용에 초점을 맞출 경우 그 분야에서 최고의 제품이 될 수 있는 최신 기능 일부를 구현하지 못하게 된다.


최고의 서비스(고객 친밀)를 제공하는 데 초점을 맞출 경우 일반적으로 제품이 여러 방향으로 분산되어 각 고객에 따라 대폭 맞춤 제작된다. 이 경우 혁신과 사용 편의성 측면에서 대가를 치르게 된다.


이 목표 중 규모의 확장이 용이한 것은 두 개뿐이다. 가장 낮은 비용 또는 최고의 제품이다. 원하는 검색 결과를 얻지 못할 때 구글 고객 서비스에 전화를 걸 수 없는 이유가 여기에 있다.


7. 테스트 먼저

현대 IDE에서는 테스트를 가장 먼저 해야 한다. 이는 단위 테스트를 먼저 작성한 다음 여기서 클래스 등을 생성해야 함을 의미한다. 결과적으로 테스트가 용이한 소프트웨어가 되므로 더 높은 품질의 소프트웨어가 만들어진다. 또한 계약에 의한 설계와 같은 다른 설계 원칙을 따르도록 유도하는 효과도 있다.


8. 계약에 의한 설계

각 루틴에 대해 그 루틴이 어떤 작업을 하고 그 작업을 위해 무엇이 필요한지를 알아야 한다. 방법은 계약에 의한 설계(Design by Contract)다. 여기서 계약은 소프트웨어의 각 요소를 위한 형식적이고 간결하며 확인 가능한 인터페이스 사양을 말한다. 이 접근 방법을 사용하면 부작용, 전역 변수 및 기타 여러 가지 잘못된 것들을 피할 수 있다.


9. 경합 조건에 주의

일반적으로 경합 조건은 계약에 의한 설계의 다중 쓰레드 위반을 의미한다.


가장 단순한 형태로 보자. 두 개의 쓰레드가 동일한 변수를 변경할 때 한 쓰레드가 먼저 한다면 문제 없다. 그러나 두 번째 쓰레드가 변수를 먼저 변경하는 경우 오류가 발생하고 이것이 경합 조건이다.


이러한 종류의 설계 결함을 탐지하는 것이 불가능할 때도 있다. 간헐적이며 부하가 큰 경우에만 발생하는 경우가 많으므로 단위 테스트로 포착할 수 없다. 고도의 방어적 설계와 쓰레드 간 협업을 피하는 것이 경합 조건을 방지하기 위한 좋은 방법이다. 그러나 메시징 및 이벤트 지향 소프트웨어에서도 다른 버전의 경합 조건이 발생할 가능성은 있다(다만 확률이 낮을 뿐임). 동시성은 어렵다.


10. 콘웨이의 법칙

콘웨이의 법칙(Conway's Law)이란 팀의 커뮤니케이션 구조를 반영하는 소프트웨어를 개발할 수밖에 없다는 법칙이다. 바꿔 말하면 팀의 근본적인 구조를 바꾸지 않고서는(바꾸기는 무척 어려움) 소프트웨어의 근본적인 구조를 바꿀 수 없다.


11. 빠른 실패

 “빠른 실패(Fail Fast)” 원칙은 실리콘 밸리에서 인기 있지만 어디에 적용해도 좋다. 기본적인 개념은 오류가 발생할 경우 소프트웨어는 대놓고, 거침없이 그 오류를 드러내야 한다는 것이다.


아마추어 프로그래머는 모든 변수에서 null을 확인하고, null이 될 수 없는 경우에도 이를 0이나 빈 문자열 등으로 대체한다. 그런 다음 불가능하고 잘못된 상황이 발생했는데도 코드를 계속 실행시킨다. 최고의 개발자는 소프트웨어가 null 포인터 예외를 뱉거나 실제 오류 자체를 내뱉도록 한다.


프로젝트 관리에서 빠른 실패란 존재할 수 있는 정치적 또는 기술적 장벽을 최대한 조기에 찾아내는 것을 의미한다.


비즈니스에서 빠른 실패란 궁극적인 실패를 향해 또는 이른바 ‘라면 수익’을 향해 천천히 투자하기보다 상품이나 비즈니스를 입증하거나 반증하는 대담한 계획을 추진하는 것을 의미한다.


12. 맨먼스 미신

프로젝트 종반에 인력을 추가하면 프로젝트는 더 늦어진다. 고전 ‘맨먼스 미신(The Mythical Man-Month)’은 40년도 넘은 과거의 책임에도 오늘날 소프트웨어 엔지니어링의 많은 오류를 설명한다.


이 용어는 “언제 끝나요?”라는 질문에 냉소적으로 답하는 데도 사용된다. 내 일정은 나도 모른다. 다른 일이 없었다면 신비한 3인일(man-days) 내에 이미 마쳤겠지만, 회의가 6번 더 남았고 그 회의에서도 누군가는 똑 같은 질문을 던질 것이다.


원문보기: 

https://www.infoworld.com/article/3233866/application-development/12-essential-software-development-principles-and-concepts.html




...

Posted by 홍반장水 홍반장水

늘 베타 테스트 상태에 있어라.

실리콘밸리에서 유일한 욕설은

“끝났다(finished)” 라는 걸 기억하라.

만약 당신이 스스로 최종적으로 완성된 제품이라고 생각한다면

당신은 그야말로 끝나버린 존재라는 뜻이다.

언제나 자신을 85%쯤 개발되었지만 끊임없이 향상시키고

개선하며 개조할 필요가 있는 상태라고 생각하라.

- 링크트인 창업자 리드 호프만 


다 배웠다고, 더 이상 배울 것이 없다고 생각하는 순간

누구에게나 후퇴가 시작됩니다.

누구나 할 것 없이

새로운 소프트웨어가 거듭되는 시험을 거치면서 향상될 수 있듯이,

언제나 끊임없이 개선될 수 있는 상태를 유지해야합니다.



...

Posted by 홍반장水 홍반장水

“과거는 잊어라” 소프트웨어 개발의 본질을 바꾸는 21가지 기술

아주 오래 전에 개발자들은 빠르고 가벼운 어셈블리 언어로 개발했다. 코드를 입력하기 위해 기계 전면의 스위치를 조작해 줄 사람을 고용할 수 있을 정도로 예산이 많은 적도 있었고, 상황이 좋지 않을 때는 개발자가 직접 그 일을 했다. 복잡할 것이 전혀 없었다. 당시의 소프트웨어는 메모리에서 데이터를 읽어 들여 약간의 연산을 한 뒤 결과물을 내놓는 것이 전부였다.


오늘날의 개발자는 전 세계 출신의 다양한 언어를 구사하는, 무엇보다 제각기 다른 버전의 컴파일러를 사용하는 팀원들과 함께 일해야만 한다. 게다가 어떤 코드는 새로 개발된 것이고, 어떤 코드는 소스 코드가 제공되지 않는, 10년도 넘은 라이브러리를 활용한 것일 수도 있다. 오늘날 개발자가 되기 위해서는 협동심과 인내력부터 키워야 한다.


불과 5년 전과 비교하더라도 컴퓨터에 작업을 지시하는 것에는 대단한 차이가 있다. 지난 10년 동안 영화 ‘올드보이’의 오대수처럼 어딘가에 납치됐다 풀려난 개발자가 있다면, 오늘날의 컴퓨팅 세계에서 아무것도 할 수 없을지도 모른다. 모든 것이 그 어느 때보다 빠르게 변하고 있다.


프로그래밍의 본성을 바꾸어 놓는 21가지 기술을 살펴본다. 이 기술들로 인해 개발자의 협업 방식, 고객 지원 방식, 코딩 방식이 바뀌고 있다. 개발자라면 정신을 바짝 차리기 바란다.


지속적인 통합(Continuous Integration) 

과거에는 리포지토리(Repository)에 코드를 커밋하고 나면 보통 커피를 마시며 한숨 돌리거나 점심을 먹을 여유가 있었다. 하지만 더 이상은 아니다. 오늘날의 리포지토리는 지속적인 빌드 시스템과 밀접하게 연결되어 있기 때문이다. 지속적인 빌드 시스템은 코드를 다시 컴파일하고, 아키텍처를 검사하고, 코드에 수백 가지 테스트를 수행해 오류의 가능성을 표시해 준다. 이 때문에 개발자는 지속적인 빌드 시스템이 보내는 작업 수정 요청 메일과 문자 메시지 때문에 책상에서 한치도 벗어나기 어렵다. 지속적인 빌드 시스템은 개발자에게 늘 새로운 일거리를 던져 준다.


더 똑똑한 언어

초창기의 컴퓨터 언어는 컴퓨터를 사용해 어떤 일을 쉽게 하기 위한 목적으로 고안됐다. 최신 언어의 초점은 정상적인 작업 이외의 다른 일은 하기 어렵거나 거의 불가능하도록 하는 데 있다. 프로그래밍 커뮤니티는 오랜 시간에 걸쳐 사람들이 어떻게 실수를 해서 프로그램을 망치는지를 학습했다. 그렇게 해서 나쁜 습관 목록을 작성했고, 이제 몇몇 언어 설계자들은 아예 가드레일을 치고 구속복을 입혀가며 프로그래머들이 널 포인터 역참조 또는 경합 조건과 같은 과거 세대의 실수를 반복하지 않도록 하기 위해 애쓰고 있다.


예를 들어 러스트(Rust)에는 변하지 않는 변수 클래스가 있다. 변할 수 없는 변수라니 이상하게 들리겠지만, 경합 조건을 차단하고 코드 실행 속도를 더 빠르게 하기 위한 유일한 방법이다. 이와 같은 수백 가지의 혁신 덕분에 프로그래머들은 더 좋은 코드를 작성할 수 있다.


물론 이러한 제약은 완벽하지 않으며, 나쁜 습관을 반사적으로 피해가는 유능한 프로그래머에게는 오히려 성가신 요소가 되기도 한다. 그러나 많은 프로그래머들이 새로운 언어들의 엄격한 규율과 부가적인 구조를 반갑게 받아들이는 중이다.


더 좋은 데이터베이스

최초의 데이터베이스는 기적이었다. 데이터베이스가 정보를 큰 테이블에 집어넣는 표준 방법을 제공한 덕분에 전 세계 프로그래머들은 오래 전부터 시달리던 힘든 작업에서 벗어날 수 있었다. 오늘날의 데이터베이스는 그 외에도 소셜 네트워크 유지 관리, 위치 추적, 이미지 저장 등의 많은 부하를 짊어진다. 이러한 모든 작업을 하면서 서로 다른 대륙에 위치하기도 하는 시스템 클러스터 전반으로 부하를 분산시킨다.


관심이 폭증하면서 프로그래머들은 다양한 틈새 수요를 충족하는 수십 가지 데이터베이스를 만들었다. 초고속으로 대답이 필요하며, 데이터에 미세한 비일관성이 발생하는 정도는 신경 쓰지 않는다면? 트랜잭션을 사용하지 않는 메모리 내 데이터베이스를 사용하면 된다. 절대적으로 귀중한 데이터라서 손실되는 일이 없어야 한다면? 서로 다른 시간대 또는 서로 다른 반구에 위치한 데이터센터로 정보를 자동으로 복제하는 데이터베이스를 사용하면 된다. 수십 가지 옵션이 있고, 한 가지 제품에서도 구성 파일을 조금 손보는 방법으로 다양한 요구 사항에 대처할 수 있다.


프레임워크(Framework) 

근래에는 다른 사람의 작업물을 활용하지 않고 온전히 자신의 힘으로만 프로그램 전체를 개발하는 경우는 드물다. 대신 적당한 프레임워크(Framework)를 선택한 다음 API를 조사하고, 원하는 기능에 부합하지만, 서로 호환되지 않는 일부 API를 연결하기 위한 접합 코드를 개발하는 방식을 선호한다. 이제 누구도 HTML이나 CSS로 웹 페이지를 개발하지 않는다. Ext JS나 ExpressJS 혹은 기반이 되는 코드 컬렉션을 이용한다.


물론, 모든 것을 처음부터 만드는 개척자가 될 수도 있지만, 이는 자살 행위나 다름없다. 다른 사람들이 이미 완성해 놓은 것을 모두 다 처음부터 만들 수는 없는 노릇이다. 개발자는 ‘장인’이 아닌, ‘프레임워크를 조작하는 사람’임을 명심해야 한다. 만약 직접 코드를 개발할 생각을 하고 있다면 당장 멈추고 이미 개발된 프레임워크를 찾아보길 바란다.


라이브러리(Library)

루틴(Routine)의 집합소인 라이브러리는 프레임워크의 사촌 격으로, 거의 모든 곳에서 사용되고 있어 이제 라이브러리 없이는 개발이 어려울 정도다. 과연 jQuery 없이 브라우저를 위한 코드 개발이 가능할까? GetElementByID라는 함수가 있다는 것을 기억하는 사람이 있기나 할까? 물론, ‘No’다. 오늘날에는 jQuery 같은 라이브러리가 소프트웨어 스택 전체를 지배하고 있다.


사람들은 자신이 좋아하는 언어에 대해서는 잘 이야기하면서도 어떻게 개발하는지는 좀처럼 이야기하지 않는다. 따라서 개발자를 고용할 때는 라이브러리 지식에 관해 물어볼 필요가 있다. 자바스크립트 개발자라면 jQuery, 아니면 Dojo 쪽인지, 게임 개발자라면 C++보다는 Allegro나 Unity, Corona 등에 대해 알고 있는지를 물어야 한다. 라이브러리에 대한 지식은 언어를 잘 아는 것만큼 중요하다.


Node.js와 자바스크립트

과거의 웹 서버는 정적인 HTML을 서비스하는 역할을 했는데, 그 이후 데이터베이스와 상호작용할 수 있는 동적인 웹 서버를 만드는 방법이 고안됐다. 모든 개발팀에서는 데이터베이스를 프로그래밍할 수 있는 SQL 전문가와 서버 코드를 개발할 수 있는 PHP 혹은 자바 개발자, HTML 템플릿을 디자인할 수 있는 디자이너를 한 명씩 고용했다. 클라이언트 쪽에서 실행되는 AJAX와 자바스크립트가 유행하자 이런 언어를 다룰 줄 아는 개발자가 추가됐다.


지금은 모든 것이 자바스크립트로 되어 있다. 브라우저는 물론이고, 서버(Node.js)와 데이터베이스(MongoDB, CouchDB) 계층도 마찬가지다. 클라이언트 쪽에서 HTML을 생성해 주는 jQueryMobile이나 EXT JS 같은 프레임워크에서는 종종 HTML까지도 자바스크립트코드로 되어 있다.


트랜스파일러(Transpiler)

프로그래머도 인간인지라 선호하는 언어도 저마다 다르다. 누구는 A라는 언어를 선호하고, 누구는 A를 기피하고 B나 C 또는 D를 선호한다. 사용할 언어를 결정하는 데 걸리는 시간이 작업 시간보다 많을 지경이다. 많은 현대 프로그래밍 언어의 장점은 자동으로 다른 프로그램 언어로 재작성하는 기능이다.


“트랜스파일러” 또는 “크로스 컴파일러”는 특정 언어로 작성된 프로그램의 기본 구조를 뽑아내서 다른 언어에서 실행되도록 변환한다. 완벽하지 못한 경우도 있고 프로그래머의 기발한 트릭이나 이디엄을 제대로 포착하지 못하는 경우도 있지만 최적화할 수 있는 부분을 인식하는 기능 덕분에 가끔은 원본보다 오히려 더 나은 결과물을 내줄 때도 있다.


트랜스파일러의 가장 큰 목표 언어 중 하나는 모든 브라우저의 국제 공통어 자바스크립트다. C++에서 파이썬까지 어느 언어든 변환기에 집어넣으면 모든 웹페이지에서 이미지 및 텍스트와 함께 나란히 실행되는 자바스크립트로 바꿔준다. 커피스크립트(CoffeeScript)와 타입스크립트(TypeScript)가 있으니 자바스크립트 프로그래머도 개선된 자바스크립트를 일반 자바스크립트로 변환할 수 있다.


코드 검토와 스타일 규칙

과거에는 N명의 프로그래머들이 제작한 대규모 프로그램 코드에는 최소 N개의 뚜렷한 스타일이 존재했고, 정신분열적인 프로그래머들로 인해 그보다 더 많은 스타일이 혼재하는 경우도 흔했다. 지금은 각 프로그래머 팀들은 이디엄과 설계 패턴의 일관성을 지켜 코드를 더 알아보기 쉽도록 하기 위해 균일한 스타일을 강제하는 메커니즘을 개발하고 있어 이러한 스타일의 차이도 차츰 옛날 일이 되고 있다.


그러나 균일한 스타일에 순응해야 하는 것이 달갑지 않은 프로그래머도 있다. 재능이 남달리 뛰어난 프로그래머 또는 자기 주장이 강한 프로그래머는 자신의 기량이 억눌린다고 느끼는 경우가 많다. 코드 검토는 때때로 노골적인 대립으로 이어져 팀원들 간 감정적인 상처와 팀 분열로 이어지기도 한다. 최악의 경우 방향성을 상실하여 죽도 밥도 아닌 결과물을 내놓게 된다.


이와 같은 모든 문제점에도 불구하고 관리자들은 이러한 아이디어를 계속해서 도입하고 있다. 프로그래머의 좋지 않은 습관을 차단하고 불완전한 코드를 걸러내는 유일한 방법이기 때문이다. 소수 천재의 창의성을 좌절시키는 결과를 초래하기도 하지만 그 정도는 감수해야 한다.


전처리기와 린팅(Preprocessors and linting)

과거에는 컴파일러가 사용되지 않는 변수를 발견하기라도 하면 재수가 좋다고 느끼곤 했다. 지금은 논리 또는 스타일에서 오류를 잡아내는 코드 전처리 툴이 넘쳐난다. 변수를 선언하지 않았다면? 더 나쁜 경우로, 공백과 탭의 조합을 잘못 사용했다면?


에어비엔비(Airbnb) 소속 팀은 자바스크립트 코드를 위한 스타일 가이드를 공표하면서 인터넷에서 유명세를 탔다. 이 가이드는 유능한 프로그래머는 더하기 기호의 양쪽 모두에 공백을 넣으며, 그 외의 모든 형태는 나쁘다고까지 명시했다. 이처럼 가혹할 만큼의 균일성이 좋은 것일까? 어쩌면 이 규칙을 만든 이들은 사람들이 난감해 하는 모습을 보며 만족스러운 미소를 짓고 있을지도 모른다. 그러나 최소한 이들은 개발자가 자신의 어리석은 실수를 세상에 내보이기 전에 잡아낼 수 있는 도구를 제공한다.


가상머신

오늘날의 코드 대부분은 실리콘 칩이 이해할 수 있게 변환해 주는 가상머신 위에서 실행된다. 자바 가상머신, C#/.Net 가상머신, 그리고 지금은 자바스크립트 엔진이 코드의 주요 대상이다.


가상 머신의 인기는 소프트웨어 스택 전체를 흡수할 만큼 높아졌다. 과거에는 새로운 언어를 만들 때 전처리기에서부터 레지스터 할당기까지 스택 전체를 개발해야 했다. 하지만 오늘날에는 새로운 언어가 기존의 가상머신 위에 위치한다. Clojoure, Scala, Jython, JRuby 등은 오라클의 일부가 된 썬의 위대한 업적에 편승한 언어들이다.


브라우저 세계에서도 비슷한 현상이 나타나고 있다. 물론 자신만의 브라우저와 언어를 개발할 수도 있지만, 자바스크립트로 크로스컴파일할 수 있게 만들 수도 있다. 이는 CoffeeScript 같은 도구에 사용된 방법이기도 하다. 구글은 자바를 자바스크립트로 변환해 주는 GWT(Google Web Toolkit)를 내놓기도 했다.


API

과거 개발자들은 주로 데이터 구조에 대해 고민했다. 모든 정보를 바이트 블록으로 묶고, 바이트를 하나하나 센 다음 어떤 값이 특정 포인터를 기준으로 정확한 거리에 위치하는지를 확인해야 했다. 다행히 지금은 컴파일러가 이와 같은 작업 대부분을 대신해 준다.


오늘날에는 이보다 훨씬 더 정확한 인터페이스인 API로 작업할 수 있다. API는 보통 완전히 다른 디바이스에서 서비스되며, 다른 업체에서 제공하는 서비스를 매 호출 시마다 요금을 지불하고 이용할 수도 있다. 주소와 우편번호를 위도와 경도로 바꾸고 싶을 경우, 비용을 지불한 뒤 원하는 결과를 얻을 수 있는 API를 사용하면 된다.


일반적으로 데이터는 그리 치밀한 구조화가 필요 없다. 바이트의 수를 세는 예전 방식은 JSON이나 XML처럼 파싱이 가능한 데이터 구조로 대체된 지 오래다. 그저 구분 점을 올바른 위치에 찍었는지만 확실히 하면 되며, 이를 처리해 주는 라이브러리도 있다.


새로운 사용자 인터페이스

‘사용자 인터페이스(User Interface)’라는 용어는 한때 명령줄, 또는 클릭 가능한 그림 및 아이콘으로 구성된 GUI, 둘 중 하나를 결정하는 의미로 사용됐다. 지금은 텔레비전도 웹사이트를 열고 모든 전화기에 시리나 코타나 같은 개인 비서가 있는 “스마트”한 시대다. 곧 모든 부엌과 거실에는 누군가 불러 주기를 상시 기다리는 마이크가 존재하게 된다. 텔레파시가 구현될 날이 머지않은 듯이 느껴진다.


다양한 구조와 메타포를 사용하는 새로운 라이브러리와 툴을 익혀야 하는 프로그래머들에게 이런 현상은 모두 과제다. 새로운 영역은 곧 프로그래머가 차용하거나 기반으로 삼을 정립된 방식이 거의 없다는 것을 의미한다. 모든 것을 처음부터 새로 만들어야 한다. 다만 이 새로운 길에서는 프로그래머가 해야 할 작업이 간소화될 수 있다. 사용자가 단순히 온도를 알고 싶어 한다면, 굳이 온전한 앱이나 멋진 사용자 인터페이스를 만들 이유가 없기 때문이다. 그냥 음성으로 숫자를 말해주면 끝이다. 작은 앱 하나를 만들기 위해 몇 기가바이트나 되는 용량의 애플 엑스코드(Xcode)를 오후 내내 다운로드했던 경험이 있는 사람에게 이 단순함은 생소하기까지 하다.


브라우저

과거에는 데스크톱, 서버, 혹은 디바이스에 따라 각각 다른 소프트웨어를 개발했다. 이런 소프트웨어는 사용자와 상호작용하는 나름의 방식을 가지고 있었다. 하지만 지금은 모든 것이 브라우저를 경유한다. 예를 들어, 음악을 저장하기 위한 로컬 파일 서버를 구축할 때 URL로 접속해 웹 사이트에서 작업할 수도 있다. 애플의 데스크톱 위젯 역시 자바스크립트와 HTML로 개발하기 시작한 지 오래며, 많은 크로스 플랫폼 모바일 앱이 아파치 코르도바(Apache Cordova)를 통해 HTML이나 자바스크립트로 개발되고 있다.


물론 기존의 방식을 고집하는 분야도 있다. 예를 들어, 게임 분야에서는 브라우저를 거의 사용하지 않는다. 하지만 스크린 캔버스 객체를 다룰 줄 아는 자바스크립트 개발자가 늘면서 이 분야 역시 변하고 있다. 일례로 앵그리 버드(Angry Birds)는 브라우저에서도 실행할 수 있다.


도커와 컨테이너

과거에는 서버를 구축하는 작업이 쉽지 않았다. 먼저 작업을 완료한 개발자는 소프트웨어를 설치할 서버 팀에 메모를 보낸다. 그러면 서버 팀은 정확한 라이브러리를 받는 경우도 있고 그렇지 않은 경우도 있었지만, 어쨌든 결국에는 서버가 동작하게 했다.


오늘날에는 도커(Docker) 같은 애플리케이션 컨테이너를 이용해 올바른 라이브러리가 모두 포함된 컨테이너를 손쉽게 전달할 수 있다. 테스트 기기에서 잘 동작하는 컨테이너라면 실제 서버에서도 거의 잘 동작한다. 또 모든 것이 묶음으로 제공되기 때문에 데스크톱과 서버 사이의 비호환성 문제도 거의 없다.


데브옵스 도구

과거의 개발자는 소프트웨어를 서버에 일일이 설치했다. 하지만 지금은 수십, 수백, 많게는 수천 대의 서버를 한 번에 대여하는 시대다. 이들 서버는 대부분 요청과 동시에 새로 생성되어야 하고, 최신 소프트웨어도 설치되어 있어야 하므로 사실상 수작업으로는 불가능한 일이다.


셰프(Chef), 퍼핏(Puppet) 같은 서버 관리 툴을 통해 ‘데브옵스(devops)’로 입문하면 된다. 새로운 소프트웨어를 클라우드에 올리기만 하면 이들 툴은 모든 기기에서 같은 코드를 실행하며, 과거에 한 대의 기기에서 수작업으로 했던 일을 자동화해 준다.


구글 앱 엔진(Google App Engine) 같은 서비스는 이런 자동화 과정을 내부적으로 처리하고 있다. 개발자는 자신이 개발한 앱을 던져주기만 하면 된다. 그러면 자동으로 프로비저닝이 일어난다. 내부적으로 어떤 일이 일어나는지 알 필요도 없다. 그저 사용한 CPU 시간만큼 요금만 납부하면 된다.


IaaS 

서버의 경우, 클라우드 계층으로 흡수됐다. 이제 새로운 프로젝트를 위한 서버를 구축해 달라고 요청하는 개발자는 거의 없다. 대신 IaaS 사이트에 로그인한 다음 버튼만 누르면 운용할 수 있는 서버를 얻을 수 있다. 과거와 비교하면 훨씬 간단하다.


PaaS

과연 지금도 웹 사이트를 직접 구축하는 사람이 있을까? 아마도 다른 웹 사이트에 계정을 만든 다음 커스터마이징하는 방법을 택할 것이다. 웹 서식에 몇 개의 필드를 채우기만 하면 나머지는 웹 사이트가 다 알아서 해주기 때문이다. 이는 유튜브에 고양이 비디오를 올리거나 이베이에서 페즈(Pez) 디스펜서를 입찰하는 것과 다르지 않다.


물론 여기에는 약간의 과장이 섞여 있다. 현존하는 대다수의 PaaS가 웹 서식에 적절한 값을 채우는 데 개발자의 지식이 필요하다. 일례로, 마이크로소프트 애저의 경우 웹 사이트의 응답 방식을 정의하려면 몇 가지 자바스크립트 함수를 작성해야 한다. 그러면 애저가 이들 함수를 적절한 라이브러리로 랩핑해 Node.js에서 실행시키는 식이다.


플러그인을 판매하는 마켓플레이스

고품질의 그래픽 게임을 개발하기 위해 그래픽 디자이너 또는 개발자를 추가로 고용하거나, 유니티 어셋 스토어(Unity Asset Store) 같은 스토어에서 필요한 플러그인을 모조리 구입할 수도 있다. 유니티 어셋 스토어의 상품 가운데 "모든 규모의 하수구 장면 개발이 가능한 모듈 형태의" 지하 감옥 하수구 타일 키트는 45달러에 판매되고 있기도 하다. 이처럼 저렴한 가격에 그래픽을 구현할 수 있는 상황에서, 개발자나 그래픽 디자이너를 고용하려고 할지 잘 모르겠다.


그 외에도 플러그인이나 확장 모듈, 라이브러리, 다른 부가적인 것들을 판매하는 스토어가 점점 더 많이 생겨나고 있다. 라이브러리나 프레임워크와 마찬가지로 이런 것들도 적절히 잘 구입하면 그만큼 개발 시간과 인력, 비용을 줄일 수 있다.


소셜 미디어 포탈

인터넷 초기에는 웹 사이트를 만든 다음 타인의 방문을 무작정 기다려야만 했으며, 방문자는 해당 웹 사이트의 URL을 기억해야만 했다. 오늘날에는 점점 더 많은 웹이 페이스북이나 세일즈포스 같은 대형 사이트로 흡수되고 있다. 직접 웹 사이트를 구축한다면, 전 세계의 인구가 페이스북이나 세일즈포스를 클릭하는 것을 구경만 해야 할 것이다.


해결책은 당연히 페이스북이나 세일즈포스 앱을 만드는 것이다. 이들 서비스는 어느 정도 플랫폼을 통합할 수 있도록 해줄 것이다. 하지만 플랫폼에 종속될 경우, 언제든지 버림 받을 수 있다는 점을 고려해야 한다. 대형 포털 사이트의 노예가 되거나, 구경만 하거나 둘 가운데 하나를 선택할 수 있는 갈림길에 서 있다.


깃허브와 소셜 코드 공유

오픈소스 시대의 연 것은 코드 공유 사이트라 해도 과언이 아니다. 소스포지 같은 서비스가 있기 전에는 소프트웨어 개발은 ‘혼자’만의 작업일 뿐이었다. 타인의 코드를 보기 위해서는 그들이 기꺼이 코드를 전송해 주기를 마냥 기다려야만 했다.


오늘날, 코드 공유는 일종의 ‘소셜 네트워크’다. 소스포지나 깃허브 같은 사이트는 누구나 모든 코드를 보거나 수정할 수 있게 했다. 더불어 코드를 관리하고, 공유하고, 의논하는 과정이 한 곳에서 이루어질 수 있도록 통합했다. 덕분에 개발자는 하나의 인터페이스를 통해 코드를 보고, 수정을 제안할 수 있다. 불과 일주일 만에 수천, 수만 번 다운로드를 기록하는 프로젝트도 어렵지 않게 찾아볼 수 있다. 하지만 과거에는 절대 불가능한 일이었다.


이제 코드 공유 모델은 소유권이 있는 프로젝트에서도 따르고 있을 정도로 당연한 것이 되었다. 깃허브나 비트버킷(BitBucket) 같은 사이트는 제한된 그룹의 사람들에게만 공유 기능을 제한하는 비공개 코드 저장소를 유료로 제공함으로써 서비스를 유지하고 있다.


성능 모니터링

처음에는 코드의 성능을 추적하기가 수월했다. 코드가 시작될 때의 시간을 출력한 다음 끝날 때 시간을 출력하면 됐다. 좀 더 성실한 개발자는 여기에 시간차를 계산하는 식을 추가하기도 했다.


하지만 이 방법은 더는 쓸 수 없게 됐다. 여러 기기에 걸쳐 많은 문제가 나타나기 때문이다. 과거와 같은 방식의 분석을 적용하더라도, 비정상적인 통신이나 데이터베이스의 지연에 의한 진짜 병목 지점은 찾을 수 없다. 오늘날의 모니터링 도구는 모듈별 성능뿐 아니라 네트워크로 연결된 소프트웨어를 위해 네트워크 호출도 추적한다. 이렇게 해야만 무엇이 정상이고 무엇이 비정상인지 제대로 파악할 수 있다.



원문보기: 
http://www.itworld.co.kr/news/105902#csidx8b13929fe904043ac23852adb7b0f7c 

Posted by 홍반장水 홍반장水
소프트웨어 품질, 누가 책임져야 할까?

 

성공하는 소프트웨어를 개발하는 원칙.

 - 소프트웨어 개발 시 요구사항이 계속 변화하는 것에 대해 어덯게 대응할 것인가?

 - 소프트웨어 개발 시 반복되는 작업을 어떻게 최소화 할 것인가?

 - 사용자가 요구한 기능보다 좀더 나은 기능을 구현하는 방법은 없나?

 

개발 조직이 반드시 고려해야 할 것

1.소프트웨어를 개발한 후 버전 컨트롤을 하는가?

2.자동으로 빌드하고 자동으로 테스트하는 시스템이 있는가?

3.전체적인 소프트웨어 개발을 모니터링하고 있는가?

4.테스터의 롤이 별도로 있거나 테스팅 환경을 구축하고 있는가?

5.버그 트랙킹 시스템을 구축하고 있는가?

 

소프트웨어 개발이 실패할 경우 그에 대한 책임은 해당 소프트웨어를 개발한 모든 사람에게 있다.

 

가장 훌륭한 소프트웨어 개발 조직은 똑같은 실패를 다시 반복하지 않는 조직이다.

문제가 있는 상황을 인지하고, 문제를 해결하기 위해 노력하면서 그 상황을 변화시키려는 조직이라야

유기적이고 유동적으로 해당 문제를 해결할 수 있다.

 

"소프트웨어 개발에 있어서 특정 형식에 얽매이는 행위야말로 삽질이다."

 

 

 

Posted by 홍반장水 홍반장水

국제화시 고려해야할 49가지

소프트웨어를 국제화해야 하기 위해서는 고려해야할 것이 한두가지가 아니다.
그런데 많은 회사들은 메세지나 번역하면 되는 것으로 안다.
그렇게 쉽게 접근했다가는 해외 진출을 하면 할수록 문제가 커지고 비용이 늘어나서 점점 어려워진다.

국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다.

기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할 수 있는 기본 기술이고
지역화(L10N)은 각 Locale을 지우너하는 것이다.

이 과정에서 고려해야 할 것은 수백가지가 넘는다. 그 중에서 49가지만 알아보자. 만약에 국제화된 소프트웨어를
개발하고 있는 개발자라면 이중에서 몇가지나 알고 있는지 세어보자.
어떤 항목은 그 하나가 엄청나게 큰 것도 있다. 특별하게 순서를 가지고 정리한 것은 아니지만 하나씩 살펴보자.


1~49번까지의 항목들이 제목만 본다고 쉽게 해결할 수 있는 것은 아니다.
하나의 항목을 가지고 10년 넘게 연구하고 개발하고 있는 것도 있을 정도로 크고 복잡한 것도 있다.
제대로 국제화를 적용하고 싶다면 국제화 전문가의 도움을 받는 것도 한 방법이다.
이것을 처음부터 제대로 하지 않고 시행착오를 거쳐서 고객이 버그를 찾을 때마다 하나씩 고쳐주는 것은
끝도 없고 제품의 이미지도 처음부터 추락할 것이다.

확실한 것은 국제화를 스스로 생각해서 직접 개발하면 잘못될 가능성이 99%이다.
대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

국제화 기술이 소프트웨어 해외 진출 필수임을 잊지 말자.



Posted by 홍반장水 홍반장水

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 


http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0


우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.


옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?


두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.


또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.


두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.


그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.


그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?


조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.


첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.


회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

Posted by 홍반장水 홍반장水