최근 수정 시각 : 2025-01-01 01:41:48

코딩

Coding에서 넘어옴
1. 컴퓨터 프로그램을 만드는 행위
1.1. 과정1.2. 코딩을 잘한다는 것
2. 코딩 교육3. 자동차 튜닝 중 하나4. 조사방법론 용어
4.1. 둘러보기

1. 컴퓨터 프로그램을 만드는 행위

한국어 코딩
영어 coding
중국어
하나 이상의 관련된 추상 알고리즘을 특정한 프로그래밍 언어를 이용해 구체적인 컴퓨터 프로그램으로 구현하는 기술을 말한다.

1.1. 과정

코딩이란 프로그래밍 코드를 어딘가에 적는 것을 말한다. 예를 들면 메모장을 켜고 평범한 글을 쓸 수도 있고 프로그램 코드를 쓸 수도 있는데, 후자를 하면 코딩이다. 보통은 코딩을 위한 전용 프로그램인 IDE를 사용하는데, 그 이유는 단지 메모장보다 더 편리하기 때문이다. 보통은 코딩을 할 때 컴퓨터를 이용하기에 키보드를 마구 두들겨 가며 코딩을 하겠지만, 종이나 화이트보드 위에 손으로 직접 코드를 써 가면서 코딩을 할 수도 있다.[1], 공학 전 분야, 특히 컴퓨터공학 전공자들이 많이 하는 행위이다.

구체적인 예를 들면 다음과 같다.

만약 우리가 게임을 만들고 싶다면 가장 처음에 해야할 게 뭘까? 어떤 게임을 만들지 정하는 것이다. 그 게임은 오버워치 같은 게임이 될 수도 있고 리그 오브 레전드 같은 게임이 될 수도 있고 클래시 오브 클랜이나 브롤스타즈, 배틀그라운드 같은 게임이 될 수도 있다. 어떤 게임이든 좋다. 정했다면 그 상상 속 게임의 내용을 어딘가에 적어두면 더 좋다. 생각만 하고 메모를 안 하면 나중에 필요할 때 까먹거나 헷갈릴 수도 있다.

어떤 게임을 만들게 될 지 정했으면, 그것에 대한 필요 기능에 대한 요구사항(requirements)을 제작하여 실제 게임으로 만들어 줄 수 있는 개발자에게 보내고 의뢰한다.

개발자는 우리가 쓴 게임에 대한 글을 읽고 이 게임이 어떤 게임인지, 완성되었다면 어떤 모습일지 산술적으로 필요한 계산 파트를 분할하여 파악한다. 기획서의 요구 사항을 컴퓨터가 (유저의 마우스 클릭 입력을 읽을 수 있고)/(데미지를 계산하여)/(적이 죽는 모습을 모니터 화면에 출력)/ 하는 일련의 계산식을 지닌 내용을 컴퓨터가 읽고 쓸 수 있도록 글을 바꿔 작성하는데, 이것이 개략적 개념에서의 코딩을 뜻한다.

우선 개발자는 메모장 같은 걸 켜고 거기에 해당 과정에 코드를 적고 저장한다. 만들어진 파일들은 당연히 평범한 텍스트 파일들이다. 여기까지가 코딩이다. 이렇게 저장된 파일들을 컴파일러 혹은 인터프리터라는 프로그램에 넣으면 알아서 컴퓨터 프로그램이나 스마트폰 애플리케이션 파일을 만들어준다.[2] 그리고 그렇게 만들어진 게임을 우리에게 보내주면 끝난다.
▲ 사람들의 상상 속 프로그래밍 VS 현실[3]
이렇듯 코딩이란 '단순히 코드를 적고 파일로 저장하는 것'이다. 메모장을 써도 되고 워드 한글을 써도 된다. 그러기만 하면 그걸 알아서 프로그램으로 만들어주는 프로그램까지 있다.

단, 프로그래밍 언어를 조금 이상하게 사용했을 경우 프로그램이 만들어지지 않거나, 만들어져도 쓰는 도중에 마음대로 꺼진다.[4] 또는 성능을 마구 잡아먹거나, 기능이 이상하게 돌아가거나, 해킹에 사용될 수 있는 약점이 만들어지기도 한다.[5] 이럴 때는 잘못된 부분을 고쳐주어야 한다.[6] 위의 유튜브 영상에서 갑자기 구글을 찾아보는 이유가 디버깅 때문이라고 할 수 있다.

1.2. 코딩을 잘한다는 것

"코딩을 잘한다"는 것은 어려운 문제를 더 간단하고 쉬운 개념을 이용하여 효율적으로 풀어나가는 것을 의미한다.

C급 개발자와 S급 개발자는 구현 방식이 달라지는 경우가 많은데, 가장 흔한 예시로 Python의 itertools나 regex의 활용을 들 수 있다. 보통 생각하기에는 Python에서 Function Call만 하면 끝나는 구문을 하나하나 다 구현하고 있다면, 이것이 C급 개발자일 것이라고 생각하기 쉽다.

그러나 코딩의 목적에 따라 이런 판단은 확연히 갈릴 수 있다. 만약 코딩 목적이 "최적화 된 Source Code의 완성"이라면 Function Call 만 하면 끝나는 Python 코딩이 가장 적합한 결과물이 될 수 있다. 그런데 목적이 "메모리 Usage의 최소화"라면 Function Call 이라는 메모리를 잡아먹는 방식보다는, C++로 동작 하나하나를 구현하여 메모리 사용량을 줄이는 것이 훨씬 효율적이다. 또한 만약 외주를 받아 "C++ Source Code"를 납품해야 하는 경우로 가정해도 Python의 Function을 C++로 일일이 구현하는 것이 맞는 결과물이 된다.

여기에서 알 수 있듯, "코딩을 잘한다"는 것은 목적에 부합하는 결과물을 빠르게 만들어내는 능력을 말한다. 극단적으로 이야기하면 알고리즘의 구현은 당연히 할 수 있어야 하고, 그것을 여러가지 방법으로 할 수 있어야 한다. 이를 위해서는 다양한 프로그래밍 언어에 대한 숙달은 기본 조건이며, 각 언어별 특징을 파악하고 있어 현재 프로젝트에 어떤 언어가 필요할지 선택 가능해야 한다. 이때 퍼포먼스 측면도 중요하지만 앞서 언급했듯 "빠르게" 만들어야 하는 점도 굉장히 중요하다. 게다가 컴퓨터 프로그램이나 모바일 애플리케이션을 써보면 알겠지만, 코딩의 품질은 난데없이 등장하는 버그 및 에러가 있느냐 없느냐에 달려있다. 이것을 얼마나 구체적이고 세부적으로 대비하였는지 여부가 코드의 퀄리티를 보장하는데, 퍼포먼스와 납기를 맞추면서 고 퀄리티의 디버그 코드까지 넣는 것이 얼마나 어려운 일인지는 말이 필요 없을 것이다.

더불어 이것을 만드는 것이 한 사람이 아니라 여러 사람이라는 점도 주요한 점이다. 한 사람이 역전의 용사급 역량을 갖추고 있다고 해도, 팀 인원이 이 역량에 따라가지 못한다면 결과물은 저열한 물건이 나올 수밖에 없다.

종합하면, "코딩을 잘한다"는 것은 기본 코딩 능력 및 일정과 인원에 대한 관리 능력의 총합을 이야기하는 것이다. 단순하게 코드를 잘 구현하는 것과는 확연히 다르다는 이해가 필요하다. 물론 프론트엔드 백엔드 간의 차이나 업무 환경의 차이 등을 모두 동등하게 평가할 수는 없을 것이므로 현실적으로는 치우치는 경우도 있음은 고려해야 할 것이다.

S급 개발자가 목표라면 관련 이야기가 좀 더 확장될 수 있다. 여러 코드에 대해 지식이 있다고 해도 주 종목 하나를 프로페셔널하게 잘 할 필요가 있고, 알고리즘에 대해서도 보다 심화된 지식을 지닐 필요가 있다. 다만 일반론적으로 따진다면 S급 개발자는 희귀종 수준이므로 참고로만 해두는 게 좋다. 박사 학위를 받은 개발자라도 3분의 1 만이 S급으로 분류되는 업계 현황을 고려한다면 더더욱 그렇다.

2. 코딩 교육

초중고 교육과목으로서 코딩 교육은 해당항목 참조.

3. 자동차 튜닝 중 하나

자동차의 튜닝 중 하나로서, 사용자가 변경할 수 없는 자동차의 특정 기능을 활성화 또는 비활성화하거나 수치를 변경하는 것을 의미한다.

자동차 브랜드들은 하나의 자동차를 만들어서 전세계로 수출하게 되는데, 제조사들은 지역별 규정이나 규제, 지역별 필요사향, 옵션과 등급의 차이 등에 전부 대응할 필요가 있다. 하지만 이 수많은 경우의 수에 전부 대응하는 각기 다른 모델을 개발하여 생산하면 많은 비용이 들기 때문에 제품 자체는 단일화시켜 생산히고 모델에 따라 특정 기능을 소프트웨어적으로 활성화 / 비활성화시켜 출고하는 경우가 많다.

코딩은 이런 식으로 비활성화된 기능들을 다시 살려내 사용할 수 있도록 하거나 필요하지 않은 기능을 끄는 튜닝을 의미한다.

따로 부품을 살 필요 없이 컴퓨터와 OBD2 케이블과 프로그램만 있으면 상대적으로 쉽게 할 수 있는 튜닝 중 하나이며 옵션을 추가하거나 특정 옵션이 있는 트림을 구매하는 돈에 비해 저렴하다 보니 만족도가 높은 편이다.

예를 들면 BMW의 잠금 시 사이드미러 접힘 시간을 줄인다던가[7] BMW M 로고를 계기판이나 아이 드라이브에 시동 시 띄우거나 변수를 바꿔 편의 기능으로 활성화한다

또한 더욱 더 어려운 방법으로는 차량 첫 출고 때부터 해당 기능의 주요 부품이 장착되어 있거나 없어도 간단 설치로 호환이 된다면 해당 스위치나 부품을 구매하여 장착 후 다른 차량의 기능 인증서(FSC)를 추출해 임의적으로 삽입하여 넣기도 한다 그런 식으로 하는 것을 “VO코딩” 또는 “레트로핏(Retrofit)” 이라 한다.

이베이 등지에서 1만원 ~ 2만원사이에 FSC 인증서를 구매해 Apple CarPlay 를 활성화 하거나 Android Auto 를 활성화 하거나[8] 다른 차에서 추출한 인증서를 임의로 삽입하여 인식하게 하는 방식이 있다.[9] 또한 제조사에서도 제조사 수리용 프로그램을 실행하면 강제 활성된 기능을 자동 해제하긴 하지만 이베이에서 1~3만원 사이에 리얼 인증서를 구해 넣는다면 그마저도 해제되지 않는다.

자동차 코딩이 활성화된 차량 브랜드로는 주로 BMW가 널리 알려져 있으나, 아우디 토요타와 같은 다른 회사들의 차량에서도 어느 정도 코딩이 가능한 것으로 알려져 있다.

4. 조사방법론 용어

조사방법론에서 코딩은 흔히 부호화로 번역되며, 양적으로 처리 가능한 각각의 값(value) 혹은 문자 부호에 질적인 의미를 대응시키는 과정이다. 척도를 활용한 질문지에서 코딩은 굳이 필요치 않거나 혹은 질문지 개발 단계에 포함되나, 개방형으로 수집된 주관적인 자료의 경우 수집 이후에 반드시 코딩이 뒤따르게 된다. 가장 대표적이고 이해하기 쉬운 코딩의 사례로는 "남성"=1, "여성"=2 같은 식으로 처리하는 것이 있지만, 코딩이 문제가 되는 대부분의 상황에서 코딩은 이보다 훨씬 더 복잡하다.

자료수집에 있어 개방성이 높아지고 구조성이 낮아질수록, 수집 이후의 코딩의 노고는 그만큼 증가하게 된다. 단순히 노가다라서 문제라는 것이 아니라, 조사든 연구든 간에 그것이 실제로 사회적 가치를 갖기 위해서는 코딩 과정에서의 엄격성과 체계성을 만족시켜야 하기 때문에, 힘들다고 적당적당히 하고 넘길 수 있는 작업이 아니다. 질적 연구자들이 대개 그렇듯이 코딩 작업 중에는 여러 사람들이 몇 시간 이상씩은 있는 힘을 다해 전심으로 집중해야 할 정도로 정신적으로 고되다.

코딩의 어려움은 개방형 질문에서 응답자들이 응답한 각각의 답변들을 어떻게 처리할 것인지 고민하는 데 기인한다. 사람들마다 천차만별로 답하기는 했어도, 조사자는 그들 중 일부는 서로 비슷한 생각을 서로 다르게 표현했을 수 있다는 가능성을 놓지 말아야 한다. 결과적으로 비슷한 것끼리는 서로 묶어주고, 이 각각의 묶음들의 응답 빈도가 어느 정도인지 식별하는 분류 작업이 코딩의 상당수 시간을 차지하게 된다. 결과적으로 가장 빈번하게 수집된 응답의 묶음들에 양적인 값들을 부여하게 되는데, 이와 같은 분류의 과정을 탤리(tally)라고 부른다.
Q. 귀하는 나무위키에 대해서 어떤 의견을 갖고 계십니까?
① 긍정적이다
② 부정적이다
③ 별 생각 없다
④ 기타 의견         
응답별 빈도
문항
빈도​(단위: 명)
① 긍정적이다 196 1
② 부정적이다 278 2
③ 별 생각 없다 402 3
④ 기타: 긍정적이면서 부정적이다 57 4
④ 기타: 긍정도 부정도 아니다 15 5
④ 기타: 있으면 좋지만 없어도 상관없다 10 6
④ 기타: 그때그때 다르다 8 7

여기서 만일 어떤 응답자가 "머리로는 나쁘다는 걸 아는데 마음으로는 재미있다" 로 4번에 적었다고 해 보자. 이 응답을 "기타: 긍정적이면서 부정적이다" 쪽으로 어렵잖게 분류하는 조사자들도 많을 것이다. 그런데 만일 "고민 중이다" 로 응답한 사람이 나왔다면, 이건 "기타: 긍정도 부정도 아니다" 에 함께 분류하는 것이 옳을까? 또는, 만일 " 나무위키는 의견을 물을 가치조차 없는 사이트이므로 이런 조사는 하지 말아야 한다" 고 응답한 사람이 나왔다면, 이 의견은 기타 의견란에 길게 썼지만 어쨌든 조사자가 임의로 "부정적이다" 쪽으로 이해해서 코딩해도 될까? 이런 판단은 엄청난 시간과 고민을 요하며 여러 조사자들 사이의 협의가 필요할 수도 있다. 개방형 질문에서 코딩이 힘들다는 말은 바로 이런 의미다.

자주 거론되는 코드로는 다음과 같은 종류가 있다.
  • 순서 코드(sequence code): 모든 질적 의미들을 단순히 순서대로 숫자에 대응시킨다. 가장 간단해 보이지만 나중에 코드를 손보기가 힘들고, 단순한 순서에 입각했기 때문에 숫자만 보고는 이게 원래 무슨 뜻이었는지 짐작하기가 어렵다. 그래도 객관식 조사에 잘 어울리고, 숫자를 쓰기에도 가장 경제적인지라 종합사회조사 같은 대규모 조사에서는 순서 코드 외에는 생각하기가 어렵다. 이 경우 코드의 각 값의 해독을 위해 코드북(codebook)이 있어야 한다.
    • 완전 순서 코드(complete sequence code): 순서 코드의 중간중간에 예비용으로 빈 공간을 만들어서 추후 코드 체계의 수정을 용이하게 한다. 하술할 블록 코드와 비슷하게 쓸 수도 있다.
  • 블록 코드(block code): 먼저 자료를 분류하여 여럿으로 나누는 블록화 작업을 하고, 각각의 블록마다 순서 코드의 형태로 의미를 숫자에 대응시킨다. 이 경우 블록 체계가 복잡하면 블록화하는 의미가 없다.
  • 집단 분류 코드(group classification code): 일정한 분류기준을 사전에 잡아둔 후 대·중·소분류를 나누고, 각 집단 속에서 순서 코드의 형태로 숫자의 각 자릿수에 의미를 대응시킨다. 가장 체계적이지만 가장 낭비되는 숫자가 많다. 직업분류코드, 주민등록번호, 우편번호가 대표적인 사례다.
  • 의미 코드(mnemonic code): 본래 의미를 연상할 수 있도록 문자 기호에 대응시킨 코드. 직관성은 높지만 통계적 처리는 불가능하다. 공항 코드가 대표적이며, 증권 분야에서도 AMZ, GGL, F 따위의 코드를 활용하고 있다.

코딩은 늘 잘못 입력할 가능성을 내포한다. 오류에도 대표적인 몇 가지 종류가 있다.
  • 전사 오류(transcription error): 하나의 숫자나 문자 기호를 다른 것으로 잘못 입력한 경우이다. 12345라는 코드를 잘못해서 12245로 입력하는 것이 그 사례.
  • 전위 오류(transposition error): 두 숫자나 문자 기호의 위치를 서로 뒤바꾸어 입력한 경우이다. 12345를 잘못해서 13245로 입력하는 것을 말한다.
  • 생략 오류(omission error): 원래 입력해야 할 숫자나 문자 기호를 입력하지 않은 경우이다. 12345를 입력해야 하는데 1245만 입력해 놓은 상황을 가리킨다.
  • 추가 오류(addition error): 원래 입력해서는 안 될 숫자나 문자 기호를 입력한 경우이다. 12345를 입력하다가 잘못해서 123345로 입력하는 오류가 이것.

무엇이 오류임을 찾아내는 것도 쉽지 않다. 예컨대 5지선다 객관식 조사의 다섯 문항이 14245로 코딩되어야 한다고 가정해 보자. 잘못해서 키보드의 손 위치를 엉뚱한 데 올려놓아 47578로 코딩했다면, 이 부분에서 오류가 생겼음을 눈치채기는 쉽다. 그런데 14145로 잘못 코딩했다면, 이 경우에는 질문지 원본을 처음부터 다시 대조하지 않는 이상 그것이 오류임을 눈치채기 어렵다. 이런 문제를 해결하기 위해서는 조사자 2명 이상이 동일한 자료를 중복으로 코딩하면서 서로의 코딩 결과에 달라지는 부분이 있는지를 점검하는 방법이 있지만, 엄청난 인력 낭비이기 때문에(…) 잘 쓰이지는 않는다. 이처럼 오류의 발생 여부를 찾아내는 활동을 가리켜 클리닝(cleaning)이라고 한다.

리커트 척도(Likert scale)의 경우 역코딩(reverse coding)이라는 활동이 추가로 요청될 수 있다. 예컨대 국민들의 행복을 측정하기 위해서 '매우 그렇다'~'매우 아니다' 의 5점 척도를 제작했다고 가정하자. 각각의 문항들이 "귀하는 지금 행복하십니까?", "귀하는 다음 생에도 지금 같은 삶을 원하십니까?", "귀하는 삶의 의미를 추구하고 계십니까?", "귀하는 원하는 바를 이루고 계십니까?" 같은 질문들로 구성되어 있는데, 그 중의 하나는 뜬금없이 "귀하는 지금 우울하십니까?" 를 질문하고 있다. 이것을 그냥 코딩하게 되면 문항 간 신뢰도가 약해지게 된다. 다른 모든 문항에는 그렇다고 응답한 사람은 이 문항에만 아니라고 응답할 것이고, 다른 모든 문항에 부정적인 사람은 이 문항에만 긍정적일 것이기 때문이다. 그렇기 때문에 여기서만 1→5, 2→4, 4→2, 5→1 형태로 코딩을 뒤집어 줄 필요가 있다.

코딩에서 또 다른 중요한 문제가 바로 결측값(missing value) 혹은 무응답(no answer)의 처리 방안이다. 웹 기반 질문지의 경우 응답하지 않은 문항이 있으면 설문 진행을 막는 기능도 있지만, 지필 질문지는 별도의 조사원이 붙지 않으면 결측값을 방지하지 못하는데다, 배포식으로 진행하는 조사는 응답자가 다른 데 한눈이 팔리거나 대충대충 응답하는 상황을 통제할 수가 없다. 여러 이유로 결측값은 흔히 발생할 수밖에 없고, 이에 대응하는 방법들도 다양하게 고안되었다.
  • 결측값 제외: 가장 흔한 방법. 이후의 통계적 처리에서 결측값으로 지정된 값이 보이면 무조건 빼도록 조치한다. 이를 위해, 8 이하의 숫자들로 값이 지정된 경우에는 9를, 두 자릿수까지 값이 올라가는 경우에는 99를, 세 자릿수까지 올라가면 999를 지정하는 것이 관행이 되어 있다. SPSS 같은 프로그램에서도 이런 숫자가 보이면 자동으로 계산에서 빼도록 지시할 수 있다. 일부 통계 분석의 경우, 그 내적인 논리 상 결측값이 존재하면 분석 자체가 안 되는 경우가 있다.
  • 평균 삽입: 결측값이 발생한 변인에서 그 문항의 빈 칸을 빼기보다는 그 변인의 평균으로 채워 넣는다. 한 반의 수학 점수 평균이 72점인데 학생 한 명이 시험지를 제출하지 않았다면, 그 학생의 수학 점수가 72점일 거라고 가정하는 방식이다. 따라서 평균에 영향을 주지 않는 방식으로 결측값을 보정하지만, 그만큼 통계량의 산포(dispersion)가 과소 추정되는 문제가 발생한다.
  • 최빈값 삽입: 평균 삽입과 같은 논리이지만, 여기서는 최빈값을 삽입한다. 결측값을 보인 응답자의 실제 응답은 가장 흔하게 나타나는 응답일 가능성이 높다고 전제하는 것이다. 이 경우 응답의 분포가 편포라면 평균에도 영향을 줄 수 있다.
  • 회귀식 예측: 흔하게 택할 수 있는 방법 중에서는 가장 엄밀한 방법. 회귀 분석이 예측에 적합한 분석이라는 점에 착안하여 데이터의 빈 자리에 들어갈 값이 무엇인지를 회귀식을 세워서 예측한다. 그러나 이 역시 산포를 정확하게 추정할 수는 없다.
  • 보삽법(interpolation): 시계열 분석에서 활용되는 방법. 전체적인 추세를 확인한 후, 누락된 시기의 결측값을 추세에 맞게 채워넣는다. 예컨대 2000년에서 2020년까지의 주민등록인구 자료가 있는데 2018년 자료만 없는 상태라면, 해당 연도에는 전체적인 인구변화 추세에 부합하는 숫자를 넣는 것이다.
  • 유사 응답자 확인: 결측값을 보인 응답자의 전반적인 응답 패턴을 파악하고, 그 응답자와 가장 비슷한 응답을 한 다른 응답자를 찾는다. 그리고 그 응답자가 해당 문항에 어떻게 응답했는지 살펴서 문제의 결측값에 그 값을 채워넣는다.

물론 본격적인 통계학의 영역으로 들어가자면 이보다 더 복잡한 방법들도 얼마든지 쓰일 수 있다. 예컨대 단순확률대치법(single stochastic imputation)에 속하는 Hot-Deck 방법이라든지, 부트스트랩의 논리를 활용하여 최종 추론의 자유도를 조정하는 다중대치법(multiple imputation) 같은 것들도 있다.

4.1. 둘러보기

🏬 사회과학 조사·연구 방법론 둘러보기
{{{#!wiki style="margin: 0px -10px -5px; min-height: 26px"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -2px -11px"
<colbgcolor=#C1F3FF>📝 서론 <colbgcolor=#F7FFFF,#191919> 사회과학 · 과학적 방법 · 사회조사 · 연구 · 가설 · 이론( 이론적 조망) · 연구윤리
🔍 조사방법론 I 변인 · 정의 · 상관관계와 인과관계 · 실험( 실험설계 · 통제 · 통제집단과 실험집단) · 사례연구
자료 · 자료수집( 면접법 · 초점집단면접법 · 질문지법 · 관찰법) · 코딩
📈 조사방법론 II 표본조사 · 지표 · 측정 · 신뢰도와 타당도 · 지수 · 척도
📊 사회통계 통계적 방법 · 기술통계학 · 확률 및 분포 · 추론통계학 · SPSS · 분석기법( 분산분석 · 회귀분석)
👔 공인 자격증 사회조사분석사 · 빅데이터분석기사 · 국가공인 데이터분석 전문가
📂 메타 문서 연구방법론 관련 정보
상기 문서들은 한국통계진흥원 및 한국산업인력공단의 출제범위에 의거하여 엄격히 망라되어 있으며, 동 기관의 과목별 구분·명명에 의거하여 조사방법론은 2파트로 구분됨
}}}}}}}}} ||



[1] 이런 것을 손코딩이라고 부른다. 굉장히 무식한(?) 노가다 같아 보이지만, 2020년 전면 개정 정보처리기사 시험이나 개발자로서의 구직 면접을 본다면 손코딩을 이가 갈리도록 반복해야 할지도 모른다. 손코딩 '면접' 정도 되면 거의 이공계 지망 대학(원)입시 수험생들이 치르던 구술 면접과도 비슷해진다. 이 손코딩이라는 것에 있어서도 교육자, 학습자, 현업 프로그래머 등의 취향이 갈리는데, 코딩 교육에 있어 전공자들의 입장에서야 귀찮아 보일지 몰라도 기초부터 가르칠 때에는 수학 시간에 공리, 정의, 정리, 증명을 손으로 써 가듯 컴퓨터 없이 손으로만 써가며 사고력을 키우는 것이 중요하다고 보는 사람이 있는가 하면, 모티베이션 고갈을 우려하여 오히려 기초과정일수록 적당한 교육용 프로그램에다 해야 한다는 사람도 있다. [2] 이 과정을 컴파일(compile)이라고 한다. 단순한 텍스트 파일을 프로그램으로 바꾸어 주는 과정이다. [3] 마치 해킹을 하는 것 같다만 실상은 해당 언어 프로그램에 맞는 코드를 쓰고 디버깅을 하고 오류 문구가 뜨자 그걸 검색하는(...) 내용이다. [4] 이것들을 오류, 혹은 에러(Error)라고 부른다. 전자는 에러 중에서도 특별히 컴파일 에러(compile error)라고 부르고, 후자는 런타임 에러(runtime error)라고 부른다. 컴파일 중에 에러가 발생하는지, 실행 중에 에러가 발생하는 지에 따라 달라진다. [5] 이것을 버그(bug)라고 부른다. [6] 이 과정을 디버깅(debugging)이라고 부른다. [7] 기존은 3초이상 눌러줘야지 실행된다 [8] 그마저도 제공되는 툴로 클릭 몇 번 하면 활성화 된다 [9] 주로 차선 이탈 방지나 전방 충돌 경고 등 고급 기능을 많이 활성화 한다