1. 개요
프로그램 개발자들의 은어로, 막코딩이라고도 한다. 프로그래밍에 도움이 되는 개발도구를 거의 사용하지 않고 오직 텍스트 에디터로만 프로그램을 만드는 행위를 말한다.'날'자가 들어갔다고 해서 날로 먹는(...) 코딩이란 의미가 아니다. 날것(Raw)의 코딩이라는 뜻이다.
반대말은 통합 개발 환경을 포괄하는 WYSIWYG.
2. 사용 이유
주로 웹개발 하는쪽에서 날코딩을 하는 사람들이 많은데, 웹개발의 특성상 수많은 언어들을 사용하게 된다. HTML, CSS, JavaScript는 기본에 PHP, JSP, ASP등의 서버 사이드 스크립트와 각종 템플릿 문법, 거기다 DB쿼리를 위한 SQL, 데이터 교환 포맷으로는 XML과 JSON을 사용한다. 이게 현업 레벨의 웹 개발에서 요구하는 사실상의 최소다. 이걸 전부 다 통합적으로 지원하는 IDE는 이클립스, 비주얼 스튜디오 코드, 인텔리제이 울티메이트 정도있다.Java의 경우 UI를 만들때 적당한 개발툴이 없다보니 역시 날코딩으로 UI를 만든다.[1]
C나 C++의 경우에는 플랫폼에 따라 달라진다. Windows 환경에서는 자사가 직접 제공하는 Visual Studio가 존재하기 때문에, 오히려 Visual Studio를 사용하지 않고, MINGW-gcc를 사용하는 것은 조심할 필요가 있다.[2]
Embedded 환경에서의 펌웨어 또는 애플리케이션 개발 같은 경우에도, 공급사에서 IDE를 제공한다면, 웬만해서는 해당 IDE를 사용하는게 편안하다. 특히 Embedded 환경 같은 경우, 시스템 초기화나 메모리 영역 초기화 등의 작업을 어떻게 하는지는 개발사가 더욱 잘 알고 있기 때문에, 사용하는 것이 좋다.[3]
macOS 같은 경우에도 Windows와 비슷한 이유 이유로 Xcode를 사용하는 경우가 있지만, Unix-like 운영체제인만큼, Xcode 프로그램이 무거워 반대로 기본적인 Compiler Configuration 및 라이브러리와 프레임워크를 확인하고, GNU Make를 직접 작성하는 경우도 매우 많다.[4]
마지막으로 Linux & Unix 같은 경우에는 Qt 같은 프레임워크 혹은 GUI 개발이 아니면, IDE를 그리 선호하지 않은 편이다.
Windows나 macOS와 달리, 리눅스를 위한 뚜렷한 IDE가 따로 없으며, 애초에 Linux & Unix에서 사용되는 애플리케이션 파일들이 대부분 특정 IDE 파일로 관리되는 것이 아닌, Makefile로 빌드하고 관리한다.[5]
굳이 Makefile이 아니더라도, 자체 Built Tool 명령어를 타이핑하여, 빌드하도록 되어있는 것이 대부분이다.
이러한 대부분의 영향은 과거 GUI가 없었던 Unix 시절 vi와 Makefile같은 빌드 툴만을 이용하여, 터미널에서도 충분히 개발이 가능했었기 때문이라고 추정된다.[6]
이러한 요소들 외에도 개발툴에서 제공하는 UI 기능을 사용할 때 자동으로 생성해주는 코드가 엉망이라서 마음에 안든다는 이유[7], 개발툴에서 제공하는 소스코드 자동 들여쓰기가 마음에 안든다는 이유 등으로 개발툴은 대충 클래스나 사용할 메소드 틀을 잡는데 쓰거나 아예 컴파일 돌릴 때만 쓰고, 코드 작성은 날코딩하는게 더 편하다는 이유로 텍스트 에디터만 고집하는 사람들도 제법 있다.
3. 하기 위한 툴
메모장은 말 그대로 텍스트를 메모하는 용도이기 때문에 날코딩을 하기에 좋은 툴은 아니다. 그 때문에 변수나 메소드 등에 색깔을 넣어 예쁘게 꾸며주고, 함수의 영역을 표현해주거나 여는 괄호와 닫는 괄호 등의 위치를 파악할 수 있게 알려주는 텍스트 에디터들을 애용한다. 대표적으로 윈도우 환경에서는 VSCODE 나 서브라임 텍스트 등이 있다. 만약 비주얼 스튜디오를 사용한다면 Visual Assist라는 탁월한 도구를 사용할수 있다. Notepad++이라는 오픈소스 에디터도 있다.유닉스 환경에서는 vim과 Emacs라는 탁월한 에디터계의 2강이 있다. 그리고 상용 프로그램인 서브라임 텍스트도 있다. 언어를 굉장히 폭넓게 지원하는[8] Visual Studio Code도 가벼워서 날코딩용으로 쓰기에 좋다. 단 Visual Studio Code는 실행 후 메모리를 좀 많이 잡아먹는 편이다.
물론 UI 작성 부분만 마음에 들지 않아 날코딩을 하는 경우에는 나머지 프로그램을 작성하던 IDE를 그대로 활용하여 날코딩을 한다.
하지만 vim이나 Emacs, Nano, Visual Studio Code에 IDE수준의 개발환경을 깔아주는 확장등이 나오면서 이들 툴로 하는게 날코딩이냐고 부를수 있냐는 말도 많다.
4. 기타
대학교에서 컴퓨터공학을 배울 때 본의 아니게 개발툴없이 날코딩을 하게 되는 경우가 있다. 바로 유닉스를 배울 때 쓰는 vi 에디터. 윈도우즈 환경의 다양한 개발툴에만 적응되어 있는 사람들은 십중팔구 버벅거리거나 헤맨다.[9] 물론 요즘은 세상이 좋아져서 유닉스 환경에서도 쓸 수 있는 좋은 IDE가 나와있기는 하지만, 별 수 없이 vi 에디터를 써야 할 상황 역시 굉장히 많다. 게다가 익숙해지면 CLI 환경에서 쓰는 에디터 중 vim만큼 강력한 것도 없다.프로그래밍 실력과 날코딩은 아무 상관 없지만, 환경적 제약 때문에 텍스트 에디터가 더 편한 경우가 있으므로 날코딩에 어느 정도 익숙해져서 나쁠 것은 없다. C/ 유닉스 환경에서는 vim과 Emacs 같은 에디터로 코딩하고 빌드 스크립트 짜는 경우가 많고, Python은 간결한 언어라 날코딩을 해도 크게 생산성이 떨어지지 않아서 현업에서도 vim으로 상업용 코드를 짜는 사람도 있다.[10]
서버에서 로그분석이나 배치 스크립트 작성등의 사유로 간단한 Bash/Python 스크립트를 작성해야 하는 상황에서 vim에디터를 통한 날코딩이 이루어진다.(윈도우에서 IDE로 작업해서 언제 올리고 있냐...)
비슷하게(?) 종이에 펜, 연필으로 코딩을 하
5. 프레임워크
날코딩의 조금 다른 의미는 프레임워크에서 찾아볼 수 있다. 프로그래밍에서 프레임워크 또는 그와 맞먹는 수준의 라이브러리가 등장하고 비약적으로 발전하면서, 날코딩은 이러한 기반 체계의 조력을 받지 않고 코딩하는 것을 의미하기도 한다.게다가 어떤 프로그래밍 언어이든지 간에 잘 만들어진 프레임워크가 곧 그 언어의 킬러 어플리케이션으로 여겨지는 해외와 달리, 우리나라 개발 환경은 프레임워크처럼 갖춰진 체계의 조력을 받지 않는 날코딩으로 만드는 소프트웨어가 많고 개발자들이 날코딩을 익숙해한다.
우리나라에서는 프레임워크를 대형 프로젝트에서만 사용한다는 인식이 있기 때문에, 프레임워크를 소규모 및 취미 프로젝트에서 사용하는 빈도가 낮다. 이것은 Java의 영향이 큰데, 스프링 프레임워크를 주축으로 주변 라이브러리와 환경 설정을 하는데 전체 개발 일정의 60% 이상을 사용해도 이상할게 없을 정도로 인기 만큼이나 악명도 가장 높다.
아무튼, 날코딩을 한다고 해서 전혀 문제될게 없는 이유는 오늘날 프로그래밍에서 요구하는 최소한의 기본만 지킨다면 프레임워크를 사용한 것에 견줄 수 있는 안정성을 갖출 수 있기 때문이다. 기본이 잘 지켜진 날코딩은 그 자체로 프레임워크가 된다.
하지만 그렇지 못한 경우가 있는데, 가령, 웹 프로그래밍을 한다는 개발자가 전역/지역 변수 구분을 전혀 못한다든지, 세션이나 요청이 유효한지 검증하는 노력을 전혀 못한다든지, SQL 및 필수 구성 요소의 잠재적인 약점을 아예 모른다든지 하는 상황은 최악이다.
개발자가 날코딩을 할 줄 안다고 이야기하는 것은 위에 기술한 이런 예외 사항도 직접 하나씩 고려하여 구현함을 의미한다. 현장에서는 프레임워크가 소프트웨어 기반과 관련된 모든 문제를 해결해주지 않기 때문에 반드시 이런 작업이 필요한 순간들이 많다. 아무리 프레임워크가 잘나왔다 한들 각 프레임워크는 적용된 주 분야와 개발된 해당 국가의 문화를 따르는 경우가 많으며, 실제 고객의 업무적 및 지역적 특성을 온전히 소화하기 위해선 날코딩이 부득이하게 필요한 순간들이 많기 때문이다. 즉, 날코딩을 한다는 자체보다 무엇을 고려하면서 날코딩을 하는지가 중요하다.
6. 관련 문서
[1]
다만 Java의 GUI 패키지 중 JavaFX의 경우 JavaFX Scene Builder라는 프로그램을 통해 GUI에서 UI 구현이 가능하다. 다만 이런 경우에는 FXML이라는 일종의 XML 파일로 UI 정보가 저장된다는 것이 특징.
[2]
Windows 같은 경우에는 Win32 API 부터 WDK(Windows Driver Kit)까지
Windows 플랫폼에서의 High / Low Level 개발을 모두 제공해주면서도, 자사의 Private API까지 지원해주고 업데이트 되기 때문이다. 애초에 MINGW같은 경우, 주로 Cygwin이나, Visual Studio 제외 IDE들을 위한 컴파일러들에 가까운지라, 큰 사유가 없다면,
Visual Studio를 사용하는게 편할 것이다.
[3]
대표적으로, ST사의 STM32CubeIDE나, ARM사에서 제공하는 Keil IDE 등이 있다. 두 회사에서 제공하는 IDE를 사용하는 것이 더욱 효율적인데, STM32CubeIDE 같은 경우에는 MCU 디버깅을 위해서는 디버깅 서버를 열어야, gdb로 접근이 가능해지기 때문이다. Keil IDE 같은 경우에는 자체 Build Tool과 컴파일러를 사용하고 있다. 그외에도 QNX Momentics나 VxWorks Tornado 그리고 NEOSPACE와 같은 RTOS 상에서의 애플리케이션 개발을 위한 IDE같은 경우에는 테스크 스케쥴러부터 커널 소스 제공 등 말 그대로, IDE를 사용할 수 밖에 없는 상황들이기에, 필수로 사용해야한다. 또한 이들은 모두 크로스 컴파일링이기 때문에, 만들어진 펌웨어, 애플리케이션을 보드에 자동으로 업로드하는 기능도 기본적으로 제공된다.
[4]
GUI 관련 작업이 아닌 CLI Application 같은 경우에는 Xcode를 사용하지 않고 개발하는 경우가 많으며, 특히
조지 호츠 같은 경우에는 Xcode를 사용하지도 거의 건들지도 않는다.
[5]
대부분의 오픈소스 리눅스 애플리케이션 같은 경우, ReadMe로 make && make install을 입력하여 설치하세요라고 적을 정도이다.
[6]
이러한 이유도 있을 수 있지만, 사실상 타자랑 명령어만 외워두기만 해도, IDE에 비해 매우 가벼운 환경으로 개발이 가능한 것도 있다.
[7]
13 이전의
iOS에서 지원한 Storyboard UI 툴이 대표적이다. XML이 매우 지저분해지기 때문에 여러 개발자가 협업하는 순간 지옥도가 열리기 마련. 그래서 13부터는 SwiftUI라고 해서
React에 가까운 방식이 새로 생겼다.
[8]
마이크로소프트가 만들었지만 OS도 폭넓게 지원한다. 윈도우, 맥, 리눅스 모두에 포팅돼 있다.
[9]
vi에디터와 일반적인 윈도우에서의 키보드 기능은 대단히 상이하다.
[10]
이 경우 오타 대비로 pylint 세팅은 기본적으로 갖고 있다.
[11]
라이브코딩