이 글은 iOS의 애플리케이션 프레임워크와 언어를 전혀 모르는 상태에서 24시간 안에 IoT 앱을 만드는 과정을 다룬다. 소프트웨어 개발은 코딩이 아니라는 생각의 증명과 함께 혹독한 환경에서 무엇인가 느끼는 것이 목적이다. 개발 전 과정의 자료는 공개된 자료만을 사용해서 필자의 접근방법을 검증 또는 따라할 수 있게 했다.

프롤로그

24시간 내에 소프트웨어를 만드는 챌린지가 꽤 많다. 이 관점으로 보면, 이번 챌린지는 별 특성이 없어 보인다. 하지만 소프트웨어 개발에 중요시 됐던 프로그램밍 언어와 애플리케이션 프레임워크를 전혀 모르는 상태에서 24시간은 꽤 의미 있는 챌린지다. 이런 챌린지는 보통 특정 언어와 프레임워크에 매우 익숙한 사람들이 도전한다. 하지만 필자는 소프트웨어 개발은 코딩이 아니라고 생각한다.

무모하지만 즐겁다

iOS 개발용 프로그램밍 언어와 프레임워크를 모르는 상태에서 24시간 내에 개발을 완료하는 것이 이번 챌린지의 목적이다. 개발 내용은 모바일의 블루투스와 가속도센서, 진동 모터 제어, 카메라 제어를 포함해 디바이스의 네이티브 인터페이스를 활용해 블루투스 저전력 장치를 모니터하고 제어하는 앱을 개발하는 것이다.

컴퓨터공학을 전공한 아키텍트로서 일해 왔지만 소프트웨어 개발의 의미를 잘 모르겠다. 비유는 할 수 있다. 소프트웨어 개발은 마치 우주 같다. 매우 광대하고 모르는 부분이 많다. 하지만 확실히 말할 수 있다. 소프트웨어 개발은 코딩이 아니라고. 이번 챌린지를 통해 작은 사례이지만 소프트웨어 개발은 코딩이 아니라는 것을 증명하고 싶다. 그리고 혹독한 환경 노출을 통해 생존 본능을 깨워 무엇인가 느끼고 싶다.

SW 개발에서 언어와 프레임워크의 비중

소프트웨어 개발에서 프로그램밍 언어와 프레임워크의 비중이 얼마나 된다고 생각하는가? 필자는 25%로 생각한다. 한국의 소프트웨어 인력 채용은 개발 언어와 프레임워크에 대한 프로파일 중심적이다. 이력서 양식에 표 1과 비슷한 테이블이 들어있다. 인력 수준이 하향평준화된 시스템 통합 시장뿐만 아니라, 자사의 솔루션을 만드는 회사 양식에도 들어있다.



뿐만 아니라, 독자들이 소프트웨어 직종의 구인/구직 경험이 있다면, “어떤 언어/프레임워크를 해보셨나요?”라는 질문을 받거나 해봤을 것이다. 소프트웨어를 구현하기 위해서는 언어와 프레임워크가 필요하다. 하지만 소프트웨어 개발과 프로그램밍 언어/프레임워크 사용을 동일시하는 인식은 잘못 됐다. 모든 생산에는 공정이 있다. 소프트웨어는 분석→설계→개발→테스트→배포의 공정을 방법론에 따라서 수직 또는 수평으로 운영한다.

프로그램밍 언어와 프레임워크의 사용은 공정의 중간인 개발 영역과 설계의 작은 부분을 차지할 뿐이다. 안타깝게도 이것이 한국에서 소프트웨어 개발을 바라보는 시각이다. 정부의 소프트웨어 교육부터 시작해 회사의 채용까지 소프트웨어 개발을 코딩으로 생각한다. 그리고 소프트웨어를 모르는 사람들이 소프트웨어 관련된 중요한 일을 결정한다.

개발환경 준비

소프트웨어 개발을 코딩으로 생각하는 시각이라면, 준비 단계에서 필자가 해야 할 일은 “iOS 개발 일주일만 하면 된다”와 같은 책을 보면서 열심히 헬로월드(프로그램밍 언어를 실행하기 위한 최소한의 코드로 이루어진 샘플)부터 코딩해서 학습하는 것이다. 하지만 필자가 준비 과정에서 한 것은 요구사항 정의, 아키텍처 정의, 개발환경 구성 등의 분석/설계/준비 단계이다. 소프트웨어 개발에서 소외됐던 부분이다.



필자는 iOS의 개발경험도, 소유한 바도 없기 때문에 맥 컴퓨터와 iOS 디바이스가 필요했다.

소프트웨어 개발은 코딩뿐만 아니라 문서의 참조/작성, 테스트, 모니터링 등등 때문에 디스플레이가 많이 필요하다(그림 1). 미니 디스플레이 포트와 USB 그래픽 어댑터를 이용하면 다중 디스플레이를 사용할 수 있다.

소프트웨어 인력 충원이 당장 급하다면, 우선적으로 추가 대형 모니터와 책상 교체를 고려하는 것이 좋을 것이다. 언제 채용될지 모르는 인력보다 생산성 보존이 확실하다. 사업 론칭 후 퇴사자가 생기는 이유는 잘 되고 잘 안 된 이유가 아니라 너무 열악한 환경에서 일했기 때문이다.

필자가 구입한 제품은 2014년 9월에 생산된 것이라서 최신 운영체제로 업그레이드 하고 XCode 개발환경을 설치했다. 요구사항과 이슈를 관리할 비트나미 레드마인을 설치했다. 비트나미는 레드마인을 쉽게 설치할 수 있는 패키지를 제공한다. 이 패키지를 설치하면, 이슈 트래커 뿐만 아니라 SVN과 같은 형상관리 서버도 같이 설치된다.



소프트웨어 엔지니어링 서적을 보면, 구성관리자도 나오고 소프트웨어 관리자도 나온다. 형상관리나 개발 전반에 필요한 소프트웨어 관리는 이 사람들의 몫이다. 이런 역할자들은 소프트웨어 코딩을 하는 것은 아니지만 지속적으로 높은 수준의 소프트웨어를 사용자에게 제공하기 위해 필요하다.

[개발환경 준비 요약]
1. 불확실한 인력 충원보다는 인프라 개선에
집중하라
2. 지속적으로 높은 수준의 소프트웨어 제공을 위해서는 구성관리자와 소프트웨어 관리자도 필요하다

요구사항 정의

소프트웨어 개발에 요구사항이 필요한 이유는 요구사항은 소프트웨어 개발비용이기 때문이다. 요구사항 정의는 소프트웨어 개발비용을 결정한다. 따라서 이상적인 소프트웨어 개발은 요구사항을 정의하고, 요구사항을 근거로 비용을 책정한 다음에 의사결정 후 진행하는 것이다. 요구사항 정의 전에 프로젝트 비용을 책정하는 것은 시험에서 문제의 답을 몰라서 찍는 것과 같다. 이런 근거 없는 비용의 책정은 부실로 이어지고, 부실을 메꾸기 위해 추가 비용이 발생한다. 결국 세상에 공짜는 없다.




“Agile에서도 요구사항 정의는 반드시 필요하다.”

요구사항은 기능 요구사항과 비기능 요구사항으로 나뉜다. 기능 요구사항은 시스템의 인풋으로 인한 처리를 통한 아웃풋으로 기능적인 부분을 뜻하고, 비기능 요구사항은 그 외 요구사항으로 미적인 부분이 많다. 잘 정의된 기능 요구사항은 튼튼한 설계의 기반이 된다. 또한 프로젝트 진행을 수치화 할 수 있는 좋은 지표가 된다.

예를 들어 전체 기능 요구사항이 40개이고 20개를 충족했다면 전체 공정은 50%라고 말할 수 있다. 반면 비기능 요구사항은 요구사항의 충족 여부를 사람의 주관에 의지하기 때문에 불안정하다. 디자인을 포함한 UX가 중요한 것은 사실이나, 이 때문에 기능 요구사항을 소홀히 하는 것은 매우 위험하다. 프로토타입이나 목업이 요구사항 정의를 대신할 수 없다.

간혹 우리 프로젝트는 Agile(효과적인 개발을 위한 개발 방법론)을 기반으로 하기 때문에, 요구사항 정의를 소홀히 해도 괜찮다는 주장을 들을 수 있다. Agile은 불필요한 것을 막고 커뮤니케이션을 활용해서 생산성을 극대화하는 것이다. 요구사항 정의는 불필요한 것이 아니다. 요구사항 정의를 한다는 구실로 불필요한 인력까지 드래프트도 없는 상태에서 회의실에 가둬놓고 요구사항 1번부터 작성하는 것이 불필요한 것이다.

“요구사항은 프로젝트의 수호자다.”

엔지니어가 요구사항에 없는 것에 집중하거나 관리자가 요구사항 외의 것을 요구할 때가 있다. 소프트웨어 개발은 창의적인 작업이기 때문에 자율성은 존중돼야 한다. 하지만 이 자율성은 최소 요구사항을 만족시키고 나서 주장해야 한다. 요구를 할 때는 반드시 요구사항 정의서를 수정하고, 요청자의 이름과 내용을 기록하고, 요청자에게 이로 인한 비용이 추가됨을 통보해야 한다.

요구사항 관리는 요구사항 전문 툴로 관리할 수 있으나, 이럴 경우 현장의 개발인력과 거리가 멀어지게 된다. 따라서 요구사항을 이슈 트래커로 등록하고 구체적인 개발활동을 해당 이슈(요구사항)와 연결하는 것이 좋다.

“이슈 트래커를 사용하는 시간이 하루에 20분을 초과하면 잘못 사용하고 있는 것이다.”

하지만 이슈 트래커를 남용하면 안 된다. 버그질라나 레드마인은 소프트웨어 개발 전반에 발생하는 이슈들을 효과적으로 관리할 수 있는 훌륭한 도구다. 하지만 이러한 본래의 목적을 넘어서 활용하게 되면 소프트웨어 개발에 참여하는 인력들이 오히려 시간을 뺏기게 된다. 예를 들어 이슈 트래커를 ERP 프로그램으로도 사용할 수 있는데, 이를 소프트웨어 개발 인력까지 강요하게 되면 이슈 관리에 스트레스를 받게 되고, 이슈 관리의 수준이 떨어져 효과적으로 이슈를 관리할 수 없다.

그림 2에서 보는 바와 같이, 요구사항을 정의하고 레드마인을 통해 요구사항을 입력했다.

분석/시스템 설계

분석과 설계 단계에서 프레임워크와 언어적 특성을 반영하면 매우 구체화된다. 이런 특성을 반영하면 구현 단계에서 빈칸만 채우는 식으로 개발도 가능하다. 하지만 이럴 경우 이번 챌린지에서는 부정행위이기 때문에 챌린지 전에는 추상화 단계에서의 분석/설계만 한다. 다행히 이전의 추상화된 아키텍처를 재이용할 수가 있었다. 해당 설계는 안드로이드 플랫폼에서 구현됐으나 언어와 프레임워크를 반영하지 않은 설계이기 때문에 iOS에도 그대로 사용할 수가 있다.

“설계 시 추상화와 구체화 단계를 나누어 설계하면, 이종 플랫폼에서도 동일한 아키텍처를 유지할 수 있다. 동일한 아키텍처 사용은 비용절감과 안정성을 뜻한다.”

다음은 좀더 구체화 단계의 아키텍처다. 이 레벨까지 iOS에도 적용 가능하다고 생각한다.

UML은 좋은 설계 언어다. UML을 사용하고 싶다면, 유스케이스와 시퀀스 중심으로 쓰기를 바란다. 지속적으로 커뮤니케이션에 사용되고 개발에도 큰 도움을 주는 구체화된 설계이기 때문이다. 필자는 클래스 다이어그램에 대해서는 부정적이다. 클래스 다이어그램은 분석 단계에서 비즈니스 도메인의 용어를 통해 도출된다. 이 도메인은 논리 모델과 일치한다. 데이터 설계와 클래스 설계가 중복됨을 뜻한다.

또한 프로세싱 역할을 하는 클래스는 시퀀스 다이어그램으로 표현된다. 따라서 데이터를 담는 컨테이너 역할을 하는 클래스는 데이터 설계로 대체하고, 프로세싱 역할을 하는 클래스는 시퀀스로 대체하는 것이 좋다.

자동화 도구를 통해 설계를 하고 설계를 코드로 제너레이션 한다면 매우 효과적이나, 그렇지 못하다면 오히려 업무가 과중된다.
“설계에 UML을 활용한다면 유스케이스와 시퀀스만 사용하라. 자동화 도구 없는 UML 사용은 업무를 더 가중시킨다.”

iOS8 앱 개발하기 - 8시간

소프트웨어 개발을 코딩이라는 관점에서 보면, 필자는 아무런 준비가 안 된 상태다. iOS 개발에 필요한 프로그램밍 언어도, 애플리케이션이 실행되는 프레임워크도 모르기 때문이다. 이를 전제로 24시간 내에 IoT 앱을 만드는 과정 중 먼저 8시간을 다루고자 한다. 개발 전 과정의 자료는 공개된 자료만을 사용해서 필자의 접근방법을 검증 또는 따라할 수 있게 했다.

0시간 - 챌린지 시작

챌린지에 필요한 모든 재료가 준비됐다. 노트북과 아이폰의 운영체제를 업데이트 했다.

그림 7은 챌린지 시작 직전의 모습이다. 태블릿에 타이머를 8시간으로 맞췄다. 연속으로 24시간을 진행하는 것은 여건이 안 되므로 시간이 되는대로 8시간씩 3일을 진행했다. 책상 위에 작업에 필요한 모든 것이 한눈에 들어오게 배치했다. 중앙에는 Xcode6를, 왼쪽에는 애플 개발 레퍼런스, 노트북에는 iBook에서 받은 Swift 언어 교재와 Object C 언어 교재를 배치했다. 아이폰은 클립을 이용해서 기기 테스트가 편하게 배치했다.

0.2시간 - Object C와 Swift, 프로그램밍 언어의 선택

iOS 앱은 기존의 Object C나 iOS8과 같이 발표된 Swift 언어를 이용해 개발한다. 각각의 언어로 빈 프로젝트를 만들고, 만들어진 소스 코드를 분석했다. Object C는 필자가 아는 C 언어와 차이가 컸다. Swift도 기존에 알고 있던 언어와 차이가 있었다. 결국 Object C를 선택하든 Swift를 선택하든, 모르는 것은 마찬가지다. 하지만 Object C는 함수 호출 방식의 가독성이 떨어졌고 Swift 언어의 이름이 마음에 들어 Swift를 선택했다.

하지만 Swift는 역사가 짧고 인터넷의 레퍼런스 대부분이 Object C이기 때문에, Swift를 선택할 경우 Object C로 짠 코드를 읽을 수 있어야 한다는 추가 비용이 발생한다. 하지만 큰 문제는 없다고 예상했다. 왜냐하면 우리가 사용하는 한국어와 같은 자연언어와 프로그램밍 언어는 다르기 때문이다. 자연어는 문화를 반영하여 풍부한 표현의 성격이 있지만 프로그램밍 언어는 인위적으로 만든 언어이기 때문에 효율성을 고려해 기본 원리가 전체 언어에 녹아 있기 때문에, 이 원리만 알면 쉽게 익힐 수 있다.

프로그래머가 코딩을 하면 테스트를 하기 위해 컴파일을 한다. 컴파일 절차 중 가장 처음 하는 것이 Lexical 분석이다. 언어의 정의대로 문자, 숫자, 기호 등이 적절히 왔는지 확인하는 절차다. 이 구조를 바탕으로 문법을 추론할 수 있다. 필자에게 익숙한 자바 언어와 차이를 추론한 결과는 다음과 같다.

1. 구문의 끝에 ';' 필요 없음
2. if 구문에 '(', ')' 필요 없음
3. 변수 선언에 '!', '?'가 사용됨
4. for 문에 '(', ')'를 안 쓸 수 있음
5. 타이프 캐스팅에는 is, as가 쓰임
6. 변수의 값은 nil이 될 수 있음
7. 다중 상속이 가능하며, 상속 대상은 ':' 뒤에 쓰고 ','로 구분함
8. init은 예약어
9. main과 같은 명시적 진입점이 필요 없음
10. 배열에서 [key, value]의 형태로 쓸 수 있음
Lexical 구조를 바탕으로 기존에 알고 있던 자바 언어를 머리 속에서 재구성했다. 핼로월드와 튜토리얼로 접근할 시간이 없기 때문에 추론한 Swift 문법으로 마음대로 코딩했다.
0.5시간 - Application Life-Cycle

애플리케이션 라이프사이클은 프레임워크에 의해 애플리케이션이 로딩되고, 실행되고, 대기 상태로 가고, 종료되는 사이클을 말한다. 이 사이클이 중요한 이유는 어떤 부분이 가장 먼저 실행되는지 알 수 있고, 자원 반환은 어디서 해야 하는지 알 수 있기 때문이다. 프레임워크 초반에 반드시 이 설명이 들어 있다.

답답하게도 설명에서는 어떤 시점에 앱이 종료되는지 명확한 명시가 없다. 언제든 리소스 반환을 위해 종료될 수 있으니 항상 상태를 저장해야 한다는 가이드만 있다.

iOS 프레임워크는 Model-View-Control로 구성된다. 이 세 가지를 만들면 된다. 여기까지 가상의 나만의 Swift 문법과 프레임워크를 파악하게 된다.

0.8시간 - Xcode 6 - 더블클릭하면 안 됨

Xcode는 MSDN이나 이클립스와 같은 모던 통합개발환경과 비슷해 쉽게 접근할 수 있다. 하지만 명령 아이콘이 낯설어 메뉴만을 이용했다. Xcode를 쓰면서 당황한 부분은 더블클릭이다. 소스 코드를 더블클릭하면 보던 화면이 사라지고 새창이 뜨는 데, 이유를 몰라서 어리둥절했다. 보던 화면을 불러오는 방법을 몰라서 다시 껐다 켜기도 했다. 더블클릭 하면 새창에서 열리고, 원클릭을 하면 보던 창에서 열린다.

1시간 - 실제 기기에 실행하려면 11만원을 내시오

많은 사람들이 필자의 도전에 격려와 조언을 해주었는데, 애플 개발자 등록을 미리 하라는 것이었다. 개발자 등록은 Apple ID 등록과 프로그램 등록이 있다. 필자는 ID 등록으로 이해해서 계정만 등록한 상태였다. 아이폰을 케이블로 연결하면 Xcode에 기기가 보인다. 대상을 기기로 선택하고 실행을 하면 시뮬레이터 대신에 기기에서 테스트가 가능하다.

이번 도전은 블루투스를 사용하기 때문에 시뮬레이터에서 테스트를 할 수가 없다. 기기 연결/선택 후 실행을 누르면 개발자 계정을 연결하고 등록하라는 메시지가 나온다. 개인정보를 입력하고 한화로 11만 원을 내면 1년간 2번의 기술지원과 애플 스토어에 배포할 권리를 갖게 된다.
Xcode6 이전에는 배포에 사용할 인증서 만드는 절차가 번거로운 것 같은데, 6에서는 개발자 프로그램 등록을 하면 쉽게 된다. 넥스트만 몇 번 클릭하면 된다. 기기를 대상으로 실행 시 USB 허브로 연결하면 잘 안 된다. 본체에 꼽는 것을 권한다.




1.5시간 - MVC 중 어떤 것을 먼저 만드는 것이 효과적일까?

이 챌린지 전에 물어봤다면 망설임 없이 Model이라고 말했을 것이다. 하지만 이번 챌린지처럼 혹독한 상황이라면 Control부터 만드는 것이 효과적이다. 왜냐하면 그동안의 프로젝트 경험으로 비춰 볼 때 실제 프로젝트에서 사용하는 모델보다 과도하게 모델을 만드는 경향이 있기 때문이다. Control부터 만들면 전체 애플리케이션이 보인다. 때문에 과하게 개발하는 것을 막을 수 있다.

반드시 소프트웨어 엔지니어는 애플리케이션 아키텍처를 기반으로 하여 자신이 개발하는 애플리케이션의 전체 흐름을 설명할 수 있어야 한다. 그 흐름의 중심은 Control이다. 그동안 Model과 View에 치어서 괄시 받던 존재다.

2시간-첫 번째 요구사항을 처리하다

2시간이 조금 지난 후에 첫 번째 요구사항인 기기의 상태를 보여주는 요구사항을 처리했다. 결과 화면에서 보듯이(그림 12) 아이폰은 상태창이 앱 위에 오버레이 되기 때문에 화면 설계의 수정이 필요했다. 이런 추가 사항은 바로 처리하는 것보다 일단 일감으로 등록하는 것이 좋다. 개발 진행의 흐름을 유지할 수 있고 더 좋은 방법을 찾을 수 있기 때문이다. 화면이 잘리는 문제와 이전 화면으로 갈 수 없는 것도 문제다.

3시간 - 클래스의 설계

하나의 클래스는 하나의 대상만 처리한다. 메소드는 하나의 목적만 수행한다. 이 두 가지는 클래스 설계에 매우 중요한 기본원칙이다. Xcode로 프로젝트를 생성하면 기본적으로 App Delegate와 ViewController가 만들어진다. 이곳에 모든 코드를 넣을 수 있다. 하지만 이럴 경우 가독성이 떨어지고 문제를 찾기 어렵기 때문에 비콘 모델을 관리하고 제어할 수 있는 클래스를 추가했다.

Swift는 강력한 타입 체크와 변수형태 체크를 한다. 우측에 제시한 코드 중 CBCentralManager!는 해당 변수는 값이 없는 상태를 허용한다는 뜻이다. 이러한 명시적인 변수형태 때문에 강력한 예외처리를 제공하는 자바 언어보다 fatal error가 작게 발생한다. 이러한 요소 때문에 결과물의 신뢰성이 올라간다.

4시간 - 굉음을 내는 쿨링팬과 쓰러지는 Xcode

사용한 개발 기기는 맥북에어 2014이다. 쿨링팬이 굉음을 내고 Xcode가 3번 정도 비정상 종료됐다. 개발환경 뿐만 아니라 iOS 자체의 경험이 많지 않기 때문에 평균 40개의 자료를 화면에 올려놓고 15개의 자료를 참고해야 했다. 모니터를 2개 더 쓰기 위해서 USB 그래픽 카드도 하나 연결한 상태에서 노트북에 부하가 걸리기 시작했다. 부하를 줄이기 위해 웹서버는 윈도우 데스크톱으로 연결하고 원격제어 대신에 인풋이 2개인 모니터의 입력 전환으로 제어했다. 웹 리소스는 윈도우 PC에서 개발했다.

6시간 - 블루투스 Gatt 제어

블루투스는 표준화된 기술이기 때문에 기존의 블루투스 지식을 바탕으로 필요 API만 찾는 식으로 빠르게 개발됐다. 이식성 때문에 표준기술의 사용은 중요하다.

애플의 문서는 블루투스를 몰라도 개발이 쉽도록 좋은 문서를 제공한다. 세부 코드는 Object C로 된 자료라서 다시 Swift로 바꿔야 해서 약간 어려웠다.
8시간-느낀 점 정리

언어의 lexical format만으로 언어의 대부분을 파악할 수 있다.

요즘 언어 책들은 Lexical을 다루지 않는다. 수많은 예제로 언어 학습을 유도한다. 프로그램밍 언어는 자연어와 다르다. 프로그램밍 언어 학습 방법을 바꿔보자.

타이핑을 줄여준다고 개발속도가 빨라지는 것은 아니다. 쉬운 표현식은 쾌속 개발의 큰 요인이 아니다.

프로젝트 진행시 소프트웨어 엔지니어들이 새로운 언어의 사용을 원할 때가 있다. 새로운 언어의 장점으로 많이 내세우는 것이 쉬운 표현식, 다르게 말하면 적게 타이핑하고 만들 수 있다는 점이다. 하지만 프로젝트가 타이핑이 많아서 늦어지는 것이 아니다. 코드는 빠르게 만드는 것보다 만든 코드를 쉽게 이해하고 신뢰할 수 있는 코드를 만드는 것이 중요하다.

프로그래밍 언어론+아무 언어 경험은 새로운 언어를 가장 빠르게 배우는 방법이다.

케케묵은 이야기를 하나 하자면, 소프트웨어 개발에서 전공이 도움이 되느냐는 이야기를 꺼낸다. 당연히 도움이 된다. 전산 관련 전공에는 커리큘럼에 프로그래밍 언어론이 포함돼 있다. 언어를 이용해서 만드는 법이 아닌 언어의 원리와 평가 방법을 배우는 과정이다. 이를 통해 언어 설계와 컴파일러 설계 머신 설계를 할 수 있다. 뿐만 아니라 필자처럼 연역법으로 프로그램밍 언어를 익히고 사용할 수 있다.

노트북에서 빠른 개발은 무리다. 노트북은 모바일 기기다.

아무리 빠른 노트북도 모바일 기기이다. 하드웨어 설계 포인트가 다른 기기이다. 소프트웨어 엔지니어에게 노트북을 주고 일을 하라는 것은 건강을 생각해서 쉬엄쉬엄 하라는 뜻이다.

시뮬레이터보다 실 기기로 개발하는 것이 빠르다.

과거에는 기기가 매우 고가이고 접근이 어려워서 시뮬레이터를 많이 사용했으나 지금은 실 기기로 개발하는 것이 효과적이다.

집중에는 약간의 소음이 필요하다.

 챌린지를 시작할 때 비와 천둥소리를 백색소음으로 사용했다. 완전 고요는 인간의 섭리에 안 맞는다. 백색소음을 사용해보자.(참고, http://www.noisli.com/)

정보의 소비 속도가 빠르다면 다수의 큰 디스플레이로 생산력을 올릴 수 있다.

과거에는 소프트웨어 엔지니어 채용 시 회사의 장점으로 모니터 2대 주는 것을 자랑한 적이 있다. 사실 모니터 여러 개 주면 엔지니어가 좋은 게 아니라 회사가 좋은 것이다.

모던 언어는 다수의 디바이스에서 구동되는 것을 목표로 하기 때문에 가상 머신을 사용하고 특성이 비슷하다.

바로 원시 코드로 컴파일 되어 실행되는 구조가 아니라 가상 머신에 의해 해석되는 구조로 실행된다. 가상 머신이 끼면 언어의 특성이 비슷해진다. 따라서 우리가 모든 플랫폼을 경험하는 것은 어렵기 때문에 모든 플랫폼을 아키텍처적으로 추상화하여 연역법으로 접근하는 것이 필요하다.