긍정적 사고, 음식의 절제, 규칙적인 운동

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

...

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

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

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

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

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

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

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

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

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

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

누구나 할 것 없이

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

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

...

“과거는 잊어라” 소프트웨어 개발의 본질을 바꾸는 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 

사람이 자기의 인생으로부터 배울 수 있는 가장 큰 교훈은,
이 세상에는 고통만 있는 것이 아니라
그 고통을 극복해 승리를 거두는 것이
자기 자신에게 달려있다는 사실과, 더 나아가
그 고통을 참 기쁨으로 승화시킬 수 있는 능력 또한
자신 속에 있다는 것이다. - 라빈드라나드 타고르

“의지는 쉽고 조용히 개발될 수 없습니다.
오직 시련과 고통의 경험을 통해서만
영혼이 강해지며, 야망을 자극하며, 성공을 이룩할 수 있습니다”
헬렌 켈러의 글 함께 보내드립니다.

.

자바스크립트 레퍼런스 모음 -  https://trello.com/#b/DlJ9r6tg/dev-ref

https://trello.com/#b/DlJ9r6tg/dev-ref

Backbone.js Ebook입니다.
영문판이고요. 한글 번역이 있었는데. 해당 Github Page가 삭제되었더라고요.
http://addyosmani.github.io/backbone-fundamentals/

Dailyjs 에 연재되었던 Backbone Tutorial입니다.
http://dailyjs.com/2012/11/29/backbone-tutorial-1/

여러 자바스크립트 라이브러리가 카테고리로 분류되어 있는 사이트입니다.
http://jster.net/

프론트엔드 개발시 참고할만한 다양한 기술 스택에 대해 분리되어있습니다.
https://github.com/dypsilon/frontend-dev-bookmarks

자바스크립트 코딩 스타일 가이드 문서입니다.
영문판: https://github.com/rwldrn/idiomatic.js
한글: https://github.com/rwldrn/idiomatic.js/tree/master/translations/ko_KR

다양한 자바스크립트 MV* 프레임웍에 대해 TODO 웹앱이 예제로 분류되어 있습니다.
실제 각 프레임웍을 사용해 어떻게 SPA를 작성하는지 참고할만합니다.
http://todomvc.com/

JQUERY MOBILE + PHONEGAP + ENERGIZE.JS
가이드
http://teusink.blogspot.kr/2013/04/android-example-app-with-phonegap-and.html
 
모바일페이지
http://www.teusink.org/blog/JQM-example-app/
 
다운로드
http://www.teusink.org/blog/PG-JQMExampleApp.zip
 
참고 : http://jadefan.blog.me/70158768436

bootstrap 하시는 분들은 다 아실수도 있겠지만 처음접하는 저에게는 신기하네요.. 템플릿 바로 적용해볼 수 있고 샘플들도 있네요.
http://bootply.com/

Backbone.js 배우는 방법 가이드
http://mobicon.tistory.com/226
DEV.STUDY 멤버이신 윤영식님의 블로그 입니다.

How to build an app: 20 great tutorials

http://www.creativebloq.com/app-design/how-build-app-tutorials-12121473

iOS app tutorials

01. Get started as an iOS developer

Got an idea for a killer app but don’t know where to begin? Daniel Bramhall of Visioa explains everything you need to know to start programming for Apple devices.

02. Design an iPhone app user interface

Designing for iOS devices is totally different from designing for the web. Sarah Parmenter explains how to create the perfect user interface for your app.

03. Create an iPad game

Appcelerator Titanium is a fantastically versatile tool for creating mobile apps, as Anton Mills demonstrates with this game for the iPad.

04. Create an iPhone game

Hello Monday walks you through how to turn a rejected concept into a GPS-based arcade game.

05. How to distribute your app

Creating an application can be extremely exciting for any developer but before you get your application published, you need to get it ready. iOS and Mac developer/designer Daniel Bramhall explains how.

06. Get started with geofencing

Explore the location-based services provided by the iOS Core Location framework in Kevin McMahon's guide to building and testing a geofencing-enabled application.

07. Build an iPad app with Sencha Touch

Create a web app that feels native on the iPad and other mobile devices, using the Sencha Touch library. Robert Douglas of mobile design specialists ribot explains how.

Android app tutorials

08. Getting To Know The Android Platform

This article explains what you need to do to build a scalable app that looks and feels right at home on Android, how to test it and your options for distributing it. After reading this article, you should have a good understanding of what kinds of decisions and challenges you will face when creating an Android app.

09. Build your first Android app

This tutorial gets you started with Android development without requiring you to wade through pages of technical documentation. At the end, you'll have written a simple Android app and you will be able to deploy the application onto an emulator or a real Android device.

10. Design an Android app user interface

Android apps can be just as beautiful as their iOS counterparts. Richard Leggett, co-director of Bitmode Ltd, digs deep into the styling and theming and explains how to use just XML and image files to add a fresh look and feel to your app.

11. Automate your app testing

Don’t trust humans to do all of your testing - not even experts. John Senner, Koa Metter, and Emory Myers of MokaSocial reveal how to delegate the dirty work.

12. Make your Android app's voice output accessible

Integrating core accessibility into Android app development is relatively straightforward to do and should be considered as business as usual for every project. Here's how to do it.

Facebook app tutorials

13. Get started with Facebook’s app tools

Techlightenment's systems architect Chas Coppard gives us a rundown of the APIs and plug-ins available to connect your site to Facebook.

14. Build a Facebook app

Facebook recently unveiled the Open Graph as its next generation platform. Mat Clayton shows you how to build a simple demo app on the Open Graph.

App-building frameworks

15. Get started with PhoneGap

In this excerpt from the PhoneGap Beginner's Guide, Nitobi/Adobe's Andrew Lunny goes over the biggest roadblock developers find with the mobile development framework: getting started and building simple apps for iOS, Android, and BlackBerry.

16. Create a theme in jQuery Mobile

We present an exclusive excerpt from jQuery Mobile Web Development Essentials, on the basics of theming and building and using a custom theme for your app.

17. Build a login form with DHTMLX Touch

In this introduction to open source JavaScript framework DHTMLX Touch web developer Alexandra Klenova explains how you can implement a login form for a mobile web app and send form values to the server with Ajax.

18. Code a real-time survey with HTML5 WebSockets

Phil Leggetter explains how to use WebSockets and Pusher to build a demo application, plus how to layer a user experience on to an app using progressive enhancement.

19. Build a game for iOS and Android with Corona

Jonathan Beebe of Ansca, Inc explains how to easily create a fun 2D physics game for iOS and Android mobile platforms using Corona.

20. Style the UI of a Sencha app

In this exclusive excerpt from their book on the Sencha Touch mobile JavaScript framework, John Clark and Bryan Johnson explain how to customise your app and use the Sencha theme engine with SASS and Compass.

And that's it! Have you seen an app tutorial you'd like to recommend? Let us know about it in the comments!

Now read:

• The 30 best iPhone apps for designers
• The 50 best iPad apps for designers
• 15 beautiful Android app designs - click here
• The 20 best Android apps for creatives