날코딩
1. 개요
프로그램 개발자들의 은어. 막코딩이라고도 한다. 프로그래밍에 도움이 되는 개발도구를 거의 사용하지 않고 오직 텍스트 에디터로만 프로그램을 만드는 행위를 말한다.[1]반대말은 통합 개발 환경을 포괄하는 WYSIWYG.
2. 사용 이유
주로 웹개발 하는쪽에서 날코딩을 하는 사람들이 많은데, 웹개발의 특성상 수많은 언어들을 사용하게 된다. HTML, CSS, JavaScript는 기본에 PHP, JSP, ASP등의 서버 사이드 스크립트와 각종 템플릿 문법, 거기다 DB쿼리를 위한 SQL, 데이터 교환 포맷으로는 XML과 JSON을 사용한다. 이게 현업 레벨의 웹 개발에서 요구하는 사실상의 '''최소'''다. 이걸 전부 다 통합적으로 지원하는 IDE는 이클립스, VSCODE, 인텔리제이 울티메이트 정도있다.
Java의 경우 UI를 만들때 적당한 개발툴이 없다보니 역시 날코딩으로 UI를 만든다. 이클립스 플러그인으로 비주얼 스튜디오처럼 UI를 그릴수 있도록 해주는 물건도 있지만 쓰기 불편하고 비주얼 스튜디오에 비하면 불친절하거나 귀찮은 부분들이 많다. 더불어 개인이나 서드 파티에서 만드는 플러그인이라 불안정한 요소도 있고 하여 조금 익숙해지고 나면 코드를 직접 타이핑쳐서 해결하는 경우가 많다.
이러한 요소들 외에도 개발툴에서 제공하는 UI 기능을 사용할 때 자동으로 생성해주는 코드가 엉망이라서 마음에 안든다는 이유, 개발툴에서 제공하는 소스코드 자동 들여쓰기가 마음에 안든다는 이유 등으로 개발툴은 대충 클래스나 사용할 메소드 틀을 잡는데 쓰거나 아예 컴파일 돌릴 때만 쓰고, 코드 작성은 날코딩하는게 더 편하다는 이유로 텍스트 에디터만 고집하는 사람들도 제법 있다. 코드 작성은 vim/Emacs으로, 컴파일은 gcc와 Makefile로, 디버깅은 로그 찍거나 gdb로 하는 경우가 일반적.
3. 하기 위한 툴
메모장은 말 그대로 텍스트를 메모하는 용도이기 때문에 날코딩을 하기에 좋은 툴은 아니다. 그 때문에 변수나 메소드 등에 색깔을 넣어 예쁘게 꾸며주고, 함수의 영역을 표현해주거나 여는 괄호와 닫는 괄호 등의 위치를 파악할 수 있게 알려주는 텍스트 에디터들을 애용한다. 대표적으로 윈도우 환경에서는 VSCODE 나 서브라임 텍스트 등이 있다. 만약 비주얼 스튜디오를 사용한다면 Visual Assist라는 탁월한 도구를 사용할수 있다. Notepad++이라는 오픈소스 에디터도 있다.
유닉스 환경에서는 vim과 Emacs라는 탁월한 에디터계의 2강이 있다. 맥 환경에서는 Xcode라는 종결자가 있고. 그리고 상용 프로그램인 서브라임 텍스트도 있다. 언어를 굉장히 폭넓게 지원하는[2] Visual Studio Code도 가벼워서 날코딩용으로 쓰기에 좋다. 단 Visual Studio Code는 실행 후 메모리를 좀 많이 잡아먹는 편이다.
4. 여담
대학교에서 컴퓨터공학을 배울 때 본의 아니게 개발툴없이 날코딩을 하게 되는 경우가 있다. 바로 유닉스를 배울 때 쓰는 vi 에디터. 윈도우즈 환경의 다양한 개발툴에만 적응되어 있는 사람들은 십중팔구 버벅거리거나 헤맨다.[3] 물론 요즘은 세상이 좋아져서 유닉스 환경에서도 쓸 수 있는 좋은 IDE가 나와있기는 하지만, 별 수 없이 vi 에디터를 써야 할 상황 역시 굉장히 많다. 게다가 익숙해지면 CLI 환경에서 쓰는 에디터 중 vim만큼 강력한 것도 없다. 너무 익숙해진 나머지 윈도우에다가 gVIM을 깔아서 쓰기도 한다.
프로그래밍 실력과 날코딩은 아무 상관 없지만, 환경적 제약 때문에 텍스트 에디터가 더 편한 경우가 있으므로 날코딩에 어느 정도 익숙해져서 나쁠 것은 없다. C/유닉스 환경에서는 vim과 Emacs 같은 에디터로 코딩하고 빌드 스크립트 짜는 경우가 많고, Python은 간결한 언어라 날코딩을 해도 크게 생산성이 떨어지지 않아서 현업에서도 vim으로 상업용 코드를 짜는 사람도 있다.[4]
비슷하게(?) 종이에 펜, 연필으로 코딩을 하 는 경우도 있지만 그건 의사코드를 직관적으로 작성하거나 아이디어를 스케치하는 등의 목적이라 날코딩과는 맥락이 다르다. 라이브코딩 참조.
5. 프레임워크
날코딩의 조금 다른 의미는 프레임워크에서 찾아볼 수 있다. 프로그래밍에서 프레임워크 또는 그와 맞먹는 수준의 라이브러리가 등장하고 비약적으로 발전하면서, 날코딩은 이러한 기반 체계의 조력을 받지 않고 코딩하는 것을 의미하기도 한다.
게다가 어떤 프로그래밍 언어이든지 간에 잘 만들어진 프레임워크가 곧 그 언어의 킬러 어플리케이션으로 여겨지는 해외와 달리, 우리나라 개발 환경은 프레임워크처럼 갖춰진 체계의 조력을 받지 않는 날코딩으로 만드는 소프트웨어가 많고 개발자들이 날코딩을 익숙해한다.
우리나라에서는 프레임워크를 대형 프로젝트에서만 사용한다는 인식이 있기 때문에, 프레임워크를 소규모 및 취미 프로젝트에서 사용하는 빈도가 낮다. 이것은 Java의 영향이 큰데, 스프링 프레임워크를 주축으로 주변 라이브러리와 환경 설정을 하는데 전체 개발 일정의 60% 이상을 사용해도 이상할게 없을 정도로 유명새 만큼이나 악명도 가장 높다.
아무튼, 날코딩을 한다고 해서 전혀 문제될게 없는 이유는 오늘날 프로그래밍에서 요구하는 '''최소한의 기본'''만 지킨다면 프레임워크를 사용한 것에 견줄 수 있는 안정성을 갖출 수 있기 때문이다. 기본이 잘 지켜진 날코딩은 그 자체로 프레임워크가 된다.
하지만 그렇지 못한 경우가 있는데, 가령, 웹 프로그래밍을 한다는 개발자가 전역/지역 변수 구분을 전혀 못한다던지, 세션이나 요청이 유효한지 검증하는 노력을 전혀 못한다던지, SQL 및 필수 구성 요소의 잠재적인 약점을 아예 모른다던지 하는 상황은 최악이다. 프로그램의 안정성은 둘 째 치더라도, 이런 상황에서는 MVC는 커녕 최소한의 모듈화 조차 기대하기 힘들기 때문에, 기능을 모듈로 구분하는 현재의 개발을 생각해보면 프로젝트 자체를 어렵게 만들기도 한다.
개발자가 날코딩을 할 줄 안다고 이야기하는 것은 위에 기술한 이런 예외 사항도 직접 하나씩 고려하여 구현함을 의미한다. 현장에서는 프레임워크가 소프트웨어 기반과 관련된 모든 문제를 해결해주지 않기 때문에 반드시 이런 작업이 필요한 순간들이 많다. 아무리 프레임워크가 잘나왔다 한들 각 프레임워크는 적용된 주 분야와 개발된 해당 국가의 문화를 따르는 경우가 많으며, 실제 고객의 업무적 및 지역적 특성을 온전히 소화하기 위해선 날코딩이 부득이하게 필요한 순간들이 많기 때문이다. 즉, 날코딩을 한다는 자체보다 무엇을 고려하면서 날코딩을 하는지가 중요하다.
6. 관련 문서
[1] '날'자가 들어갔다고 해서 날로 먹는 코딩이란 의미가 아니다.[2] 마이크로소프트가 만들었지만 OS도 폭넓게 지원한다. 윈도우, 맥, 리눅스 모두에 포팅돼 있다.[3] vi에디터와 일반적인 윈도우에서의 키보드 기능은 대단히 상이하다.[4] 이 경우 오타 대비로 pylint 세팅은 기본적으로 갖고 있다.