적어 놓은 글이 프로그램이 되기까지
번역 말고도 거쳐야 할 단계가 하나 더 있습니다.
소스 코드는 번역기를 거쳐야 실행됩니다. 미리 번역해 두는 쪽, 그러니까 컴파일러를 쓰는 경우를 조금 더 살펴보면 번역과 실행 사이에 단계가 하나 더 있습니다.
1. 편집 — 소스 코드를 적는다
사람이 읽을 수 있는 글자로 코드를 적어 소스 파일로 저장합니다. 구현 단계에서 하는 일이 이것입니다.
2. 컴파일 — 기계어로 옮긴다
소스 파일을 기계어로 번역해 목적 파일을 만듭니다. 여기서 문법 오류가 걸립니다. 규칙에 어긋난 곳이 있으면 이 단계에서 멈춥니다.
3. 링크 — 흩어진 것을 이어 붙인다
목적 파일들과 남이 미리 만들어 둔 기능 묶음을 하나로 이어 붙여 실행 파일을 만듭니다. 내가 적지 않았는데도 화면에 글자를 띄울 수 있는 것은 이 단계에서 그 기능이 붙기 때문입니다.
4. 실행 — 결과를 확인한다
만들어진 실행 파일을 실행합니다. 실행 오류와 논리 오류는 여기서부터 드러납니다.
왜 번역과 링크를 나누어 두었을까
프로그램이 커지면 소스 파일을 여러 개로 나누어 적습니다. 나누어 두면 고친 파일만 다시 번역하면 되므로 훨씬 빠릅니다. 번역이 끝난 조각들을 마지막에 한데 모으는 일이 링크입니다. 부분 하나를 떼어 시험하는 단위 테스트와 이어 붙여 시험하는 통합 테스트도 이 구조와 닮았습니다. 조각을 따로 만들어 확인하고, 이어 붙여서 다시 확인합니다.
실행하면서 번역하는 방식은 이 네 단계를 밟지 않습니다
이 네 단계는 미리 번역해 실행 파일을 만들어 두는 방식의 이야기입니다. 실행하면서 번역하는 방식에서는 실행 파일을 따로 만들지 않으므로 목적 파일도 링크도 눈에 보이지 않습니다. 적고 곧바로 실행하는 것처럼 보입니다. 번역 방식은 언어가 아니라 그 언어를 처리하는 도구가 정합니다.
따옴표를 한쪽만 적는 실수를 했다면 네 단계 중 어디에서 걸릴까요? 문법 오류 · 실행 오류 · 논리 오류 가운데 어느 것인지도 함께 말해 보세요.
도구를 한자리에 모아 둔 것
메모장으로도 코드는 적히는데, 무엇이 부족할까요?
코드를 적는 것은 글자를 적는 일이므로 어떤 글쓰기 프로그램으로도 됩니다. 문제는 적고 나서 해야 할 일이 많다는 것입니다. 번역기를 따로 불러 번역하고, 오류 메시지에 적힌 줄 번호를 보고 다시 편집기로 돌아가 그 줄을 찾고, 고쳐서 저장하고, 또 번역합니다. 도구 사이를 계속 오가야 합니다.
이 도구들을 한 프로그램 안에 모아 둔 것이 통합 개발 환경(IDE, Integrated Development Environment)입니다. 「통합」은 없던 기능을 새로 만들었다는 뜻이 아니라 따로 있던 것을 한자리에 모았다는 뜻입니다.
편집기
코드를 적는 자리입니다. 낱말의 종류에 따라 색을 달리 칠해 주고, 적다 만 이름을 추천해 주고, 괄호를 안 닫았으면 그 자리에 표시해 줍니다. 번역기가 하는 문법 검사를 적는 동안 미리 실행해 보는 것이라, 문법 오류를 번역하기도 전에 알아채게 해 줄 때가 많습니다.
번역기와 실행
단추 하나로 번역하고 곧바로 실행합니다. 오류가 나면 메시지의 줄 번호를 누르는 것만으로 그 줄로 데려다줍니다. 줄 번호를 눈으로 세어 찾아갈 일이 없습니다.
디버거
돌아가는 프로그램을 중간에 세우고 값을 살펴보게 해 줍니다. 「돌아가는 프로그램을 멈춰 세운다」 절에서 따로 봅니다.
그 밖의 것들
파일을 한눈에 보여 주는 목록, 남이 만든 기능 묶음을 받아 오는 기능, 바꾼 내용을 기록해 두는 기능 따위가 함께 들어 있는 경우가 많습니다.
어디에 설치하느냐로 두 갈래
내 컴퓨터에 설치해 쓰는 것은 기능이 많고 빠르지만 컴퓨터마다 따로 깔아야 하고, 같은 설정을 맞춰 두기가 번거롭습니다. 웹 브라우저로 접속해 쓰는 것은 깔 것이 없어 어느 컴퓨터에서든 바로 시작할 수 있지만 인터넷이 끊기면 손을 놓게 됩니다. 학교 컴퓨터실처럼 여러 사람이 번갈아 쓰는 곳에서는 브라우저로 쓰는 쪽이 편할 때가 많습니다.
어떤 제품이 있는지는 여기 적지 않습니다. 이름과 순위가 해마다 바뀌기 때문입니다. 무엇을 하는 도구인지를 알아 두면 어느 것을 만나도 같은 자리를 찾을 수 있습니다.
「통합 개발 환경을 쓰면 메모장으로는 못 만드는 프로그램을 만들 수 있다」 — 맞는 말일까요? 「통합」이 무슨 뜻인지를 근거로 답해 보세요.
돌아가는 프로그램을 멈춰 세운다
디버깅에서 「어디까지 맞는지 찾는」 일을 도와주는 도구입니다.
디버깅은 범위를 좁혀 원인을 가두는 일입니다. 그러려면 중간에 값이 어떻게 되어 있는지 봐야 하는데, 프로그램은 눈 깜짝할 사이에 끝까지 달려가 버립니다. 디버거(debugger)는 그 달리기를 원하는 자리에서 세우고 한 걸음씩 움직이게 해 주는 도구입니다.
중단점 — 여기서 멈춰라
줄 번호 옆을 눌러 표시를 걸어 두면 프로그램이 그 줄에 이르렀을 때 멈춥니다. 멈춘 상태에서 그 시점의 값들을 살펴볼 수 있습니다. 그래서 의심스러운 줄 바로 앞에 걸어 둡니다.
한 줄씩 실행 — 한 걸음만
멈춘 자리에서 딱 한 줄만 실행하고 다시 멈춥니다. 한 걸음마다 값이 어떻게 바뀌는지 보면 어느 줄에서 값이 어긋나기 시작했는지가 드러납니다.
안으로 들어가기 — 그 안은 어떤가
한 줄이 다른 곳에 적어 둔 덩어리를 불러 쓰는 줄이라면, 그 덩어리를 통째로 지나칠 수도 있고 안으로 따라 들어가 한 줄씩 볼 수도 있습니다. 바깥이 맞다는 것을 확인했으면 안으로 들어가 범위를 더 좁힙니다.
계속 실행 — 다음 표시까지 달려라
한 걸음씩 가기 답답한 구간은 다음 중단점까지 한 번에 건너뜁니다. 맞다고 확인한 구간에 시간을 쓰지 않아야 범위가 빨리 좁혀집니다.
값을 화면에 찍어 보는 것과 무엇이 다른가요
중간에 값을 화면에 내보내 확인하는 방법도 실제로 많이 씁니다. 다만 확인하려는 자리마다 코드를 넣었다 지워야 하고, 지우는 것을 잊으면 그대로 남습니다. 디버거는 코드를 건드리지 않고 바깥에서 세워 보는 것이라 그런 뒤처리가 없습니다. 둘 중 하나만 옳은 것이 아니라 상황에 따라 골라 씁니다.
디버거가 잘못된 곳을 찾아 주지는 않습니다
이름 때문에 눌러 두면 오류를 잡아 주는 도구처럼 들리지만 그렇지 않습니다. 디버거가 하는 일은 값을 보여 주는 것까지입니다. 어느 값이 이상한지 판단하는 것은 사람의 몫이고, 그러려면 그 자리에서 값이 얼마여야 하는지를 미리 알고 있어야 합니다. 테스트할 때 나와야 할 결과를 미리 적어 두는 것과 같은 이치입니다.
간식 나누기에서 「한 사람당 2개, 2개 남음」이 나왔습니다. 중단점을 어느 줄 앞에 걸어야 가장 빨리 원인에 닿을까요? 입력받기 · 사람 수 0 검사 · 몫 구하기 · 나머지 구하기 · 결과 보여 주기 가운데 어디가 의심스러운지 떠올려 보세요.
혼자 만드는 일이 드물다
같은 파일을 둘이 동시에 고치면 어떻게 될까요?
조금이라도 규모가 있는 프로그램은 여러 사람이 나누어 만듭니다. 그런데 파일을 주고받는 것만으로는 금세 엉킵니다. 누구나 한 번쯤 겪어 본 일입니다.
파일을 주고받으면 벌어지는 일
- 최종.hwp, 최종2.hwp, 진짜최종.hwp — 어느 것이 최신인지 아무도 모른다
- 둘이 같은 파일을 고쳐 왔다. 한쪽 것을 덮어쓰면 그 사람 작업이 사라진다
- 어제까지 되던 것이 안 된다. 무엇이 언제 바뀌었는지 알 방법이 없다
- 고쳐 봤는데 더 나빠졌다. 어제 상태로 되돌리고 싶은데 되돌릴 수가 없다
이런 엉킴을 한꺼번에 푸는 것이 버전 관리 시스템(version control system)입니다. 바꾼 내용을 남기기로 할 때마다 「무엇을 왜 바꿨는지」와 함께 기록해 두는 도구라고 보면 됩니다. 파일을 저장한다고 저절로 기록되지는 않습니다. 널리 쓰이는 것으로 Git이 있습니다.
되돌릴 수 있다
기록해 둔 내력이 남아 있어 기록한 어느 시점으로든 돌아갈 수 있습니다. 그래서 과감하게 고쳐 볼 수 있게 됩니다. 되돌릴 수 없으면 손대기가 무서워집니다.
누가 언제 왜 바꿨는지 남는다
기록을 살펴보면 어제까지 되던 것이 왜 안 되는지를 추적할 수 있습니다. 요구 사항과 설계를 글로 남겨 나중에 고칠 수 있게 하는 일을 도구가 함께 맡는 셈입니다.
따로 고치고 합칠 수 있다
각자 고친 것을 서로 덮어쓰지 않고 합칠 수 있습니다. 같은 부분을 둘이 서로 다르게 고쳤을 때만 도구가 멈춰 서서 어느 쪽을 택할지 사람에게 묻습니다.
확인을 자동으로 실행한다
버전 관리에 확인 도구를 이어 두면, 누군가 코드를 올릴 때마다 번역이 되는지, 준비해 둔 값들이 통과하는지를 자동으로 실행해 볼 수 있습니다. 테스트를 사람이 잊어도 기계가 대신 챙깁니다.
도구를 갖췄다고 협업이 되지는 않습니다
버전 관리는 엉킴을 풀어 주는 도구일 뿐입니다. 누가 어디까지 맡을지, 무엇을 먼저 만들지, 이름을 어떻게 지을지는 사람끼리 미리 정해 두어야 합니다. 정해 두지 않으면 합칠 때마다 같은 곳에서 부딪힙니다. 도구가 대신 정해 주지 않습니다.
버전 관리를 쓰면 「과감하게 고쳐 볼 수 있게 된다」고 했습니다. 되돌릴 수 있다는 것과 과감해지는 것 사이에 어떤 연결이 있을까요?
핵심 정리
실행 파일이 되기까지
편집 → 컴파일 → 링크 → 실행
- 컴파일은 목적 파일을, 링크는 실행 파일을 만든다
- 링크가 남이 만들어 둔 기능 묶음을 이어 붙인다
- 미리 번역해 두는 방식의 이야기다. 실행하면서 번역하는 방식에서는 따로 보이지 않는다
통합 개발 환경
IDE
- 편집기 · 번역기 · 디버거를 한자리에 모아 둔 것
- 없던 기능을 만든 것이 아니라 오가는 수고를 없앤 것
- 내 컴퓨터에 설치하는 것과 브라우저로 쓰는 것이 있다
디버거
멈춰 세우고 살펴본다
- 중단점에서 멈추고 한 줄씩 걸으며 값을 본다
- 맞다고 확인한 구간은 건너뛰어 범위를 좁힌다
- 오류를 찾아 주지는 않는다 — 판단은 사람이 한다
여럿이 함께 만들기
버전 관리 시스템
- 바꾼 내력을 남겨 기록한 어느 시점으로든 되돌릴 수 있다
- 따로 고친 것을 덮어쓰지 않고 합친다
- 도구는 엉킴을 풀 뿐, 나누는 일은 사람이 정한다
확인 퀴즈
배운 내용을 확인해 봅시다.
목적 파일들과 미리 만들어진 기능 묶음을 이어 붙여 실행 파일을 만드는 단계는?
디버거에 대한 설명으로 옳은 것은?
개발 환경에 대한 설명으로 옳지 않은 것은?