45. 배움에 지친 당신에게

---

마지막 수정일: 2023-12-17

여기는 강좌의 절반정도 온 지점입니다. 분위기를 환기시킬 겸 여러분의 효율적인 학습을 위해 드리고 싶은 말이 여러 개 있습니다. 이번 만큼은 키보드에서 손을 떼고, 편하게 봐주셔도 좋습니다.

제가 보는 여러분에 대하여

프로그래밍을 배우기로 결심한 여러분은 참 대단한 사람입니다. 오토핫키와 같은 비주류 프로그래밍 언어는 가르치는 교육기관이 극히 드뭅니다. 취업에 도움이 된다고 할 수도 없고, 대학에서 가르치는 것도 아닙니다.

그럼 오토핫키를 배우고 계신 여러분은 스스로 원해서 프로그래밍을 배우고 계신 것입니다. 대학 컴퓨터공학과 신입생 중에서도 프로그래밍을 접하지 않고 진학한 학생이 수두룩합니다. 그만큼 '의무'가 아닌 '스스로' 프로그래밍을 배운다는 것은 남들과는 다른 '배움'을 하고 계신 것입니다.

저는 그런 여러분을 참 멋있다고 생각하고 있습니다.

제 강좌로 배우시는데 어떠신지 모르겠습니다. 무언가를 새로 배울 땐 당연히 여러 좌절을 맛보게 됩니다. 그렇지 않은 사람은 드물며, 우리는 그들을 천재라고 부릅니다. 그런 면에서 '난 좀 배우는게 느린 것 같아'라는 생각은 지극히 정상이며, 결코 그렇지 않다고 말씀드리고 싶습니다.

한 번 본 이론을 전부 기억하는 사람은 없습니다. 그렇기 때문에 새로 어떤 것을 배울 땐 분명 한 번 봤던 내용인데도 불구하고 그 이론을 다시 살펴보게 됩니다. 이곳 강좌도 마찬가지로, 모든 이론을 매번 다시 설명할 수 없기 때문에 여러분은 이전 강을 다시 보는 경우가 많았을 것입니다. 그러나 그것이 뒤처지는 것은 아닙니다.

한 번이라도 지난 강으로 돌아가서 모르는 부분을 다시 찾아보았다면, 여러분은 스스로 복습의 노하우를 깨우친 '달인'입니다.

컴퓨팅 사고에 대하여

저는 모든 배움은 기초가 중요하다고 생각하는 사람이라, 제 강좌도 이론적인 부분이 많습니다. 일상 생활에선 프로그래밍 이론과 같은 개념을 접할 수 없습니다. 당연히 여러분은 처음 보는 이론을 배우고 계신 것이고, 이해가 되지 않는 것은 당연합니다.

우리는 인간이기에 주관적으로 '딱' 말하면 '척' 알아듣습니다. "쓰레기 좀 대문 앞에 내놓아라" 하면 봉투를 묶어 신발을 신고 쓰레기 봉투를 버리러 나갔다 오죠. 그러나 컴퓨터는 우리와 달라서, 어떤 동작을 반복과 조건을 이용하여 일일이 명령해주어야 합니다.

이렇게 컴퓨터에게 명령을 내리는 식으로(=코드를 작성하는 식으로) 생각하는 과정을 컴퓨팅 사고(思考)라고 합니다. 일상 생활에서 우리가 어떤 동작을 하기 위해 추상적으로 생각하는 것과는 완전히 다른 사고방식입니다. 그동안 컴퓨팅 사고를 하지 않아도 잘 살아왔기 때문에 익숙하지 않으리라 생각합니다. 결국, 프로그래밍을 처음 접했다면 우리가 원하는 동작이 있어도 이를 코드로 어떻게 구성해야 하는지 잘 모를 수밖에 없습니다.

그러나 어느 순간 탁 트이는 날이 옵니다. 우리가 일상 생활에서 아주 평범한 일을 할 때, 그 일을 어떻게 해야 하는지 하나씩 고려하면서 하진 않습니다. 이미 그 '추상적 사고'에 익숙해졌기 때문입니다. '컴퓨팅 사고' 역시 익숙해지면 마치 일상 생활에서의 추상적 사고처럼 자연스럽게 할 수 있습니다.

여러분이 컴퓨팅 사고에 익숙해지기 전까진 프로그래밍 문제를 보고 '어떤 코드 흐름으로 구성해야 하는지' 알지 못합니다. 그것은 당연한 것입니다. 저도 그랬고, 대부분의 사람이 겪는 일종의 성장통입니다. 그러나 컴퓨팅 사고가 트이는 날이 분명 옵니다. 그러니 조금만 더 파이팅입니다.

속도와 복습에 대하여

프날 오토핫키 강좌 v2는 하루에 4~5강씩, 총 20일 정도의 학습 기간을 염두해 두고 작성한 강좌입니다. 이해가 빠르다면 그보다 더 많이, 느리다면 더 조금씩 진행하셔도 되오나 하루에 10강 이상의 학습은 권장드리지 않습니다.

하루에 많은 양을 학습하지 마세요. 시간이 남는다면 지난 내용을 복습하고, 헤맸던 프로그래밍 문제를 다시 풀어보세요. 만약 많은 양을 한번에 배운다면 분명 이해했던 것 같아도 나중에 곧잘 잊어먹곤 합니다. 대부분 사람은 한번에 많은 양을 오래 기억하는 재주가 없습니다.

또한, 지난 내용 중 이해가 안되고 넘긴 부분이 있다면 돌아가서 이해하는 것이 좋습니다. 강좌를 진행하다 보면 그 전에 배웠던 개념을 이용하는 경우가 많습니다. 놓친 개념이 있다면 그런 상황에서 학습에 장애가 있을 수 있기 때문에, 매 강의 내용은 매번 이해하고 넘어가는 것이 바람직합니다.

혹여나 강좌 진행 중 이해에 어려움이 있다면, 좌측 메뉴의 '질문하기' 메뉴를 눌러 나오는 질문 페이지를 이용해주세요.

코드의 당연한 성질에 대하여

코드는 거짓말을 하지 않습니다. 작성한 코드가 올바르고, 시험이 정확하다면 그 코드는 작동할 것입니다. 그것은 코드의 당연한 성질입니다.

여러분이 작성한 코드가 올바르게 작동하지 않다면 그것은 코드의 문제로 보는 것이 타당합니다. 오류 메시지가 나타나진 않아도 실제로는 잘못 작성한 코드가 있을 가능성이 큽니다. 많은 사람들이 '분명 되는 코드인데 왜 안되지'라는 생각을 합니다. 저도 간혹 그럽니다. 그러나 타당한 생각은 아닐 것입니다. 안되는 코드라서 안되는 것입니다.

혹은 시험이 정확하지 않을 수도 있습니다. 예를 들어서, ImageSearch 함수를 사용할 때 실제 화상과 다르게 캡처된 이미지 파일을 사용했을수도 있습니다. 아니면 화상이 미세하게 변했음에도 그것을 인지하지 못하고 하나의 이미지 파일로만 ImageSearch를 사용했을 수도 있습니다. 아니면 좌표 유형을 생각과 다르게 사용하여 엉뚱한 곳을 탐색하고 있었을지도 모릅니다.

오류를 잡는 과정을 '디버깅'이라고 합니다. 프로그램이 올바르게 작동하지 않는 것을 '버그가 있다'라고 표현하죠? '지우다'라는 뜻을 가진 접두사 'De'에 오류를 뜻하는 'Bug', 행위를 뜻하는 'ing'가 붙어서 Debugging 입니다.

디버깅 도구를 사용하여 효율적으로 디버깅을 할 수 있지만, 가장 원시적이며 간단한 방법은 '값 점검'일 것입니다. 여러 곳에서 변수의 값을 점검하여 함수가 제대로 동작했는지, 엉뚱한 값을 받아오진 않는지를 확인하는 것입니다. 점검이라고 쓰니 되게 거창한 것 같지만, MsgBox로 변수의 값을 출력해보자는 뜻입니다. 그렇게 해서 변수의 값이 이상한 곳이 있다면, 그 전의 코드에 문제가 있다고 짐작할 수 있습니다. 몇 번 반복하면 정확히 어느 줄이 문제임을 알 수 있죠.

그럼에도 코드의 오류가 잘 보이지 않을 때도 많습니다. 이럴때 사용할 수 있는 경험적으로 가장 좋은 방법은 코드에서 눈을 떼는 것입니다. 잠시 커피라도 타오거나, 세수를 하는 등 말입니다. 너무 '나무'만 보고 있어서 놓치는 부분이 많습니다. 그래서 많은 학습자들이 막상 질문하자마자 스스로 해결책을 찾곤 합니다. 질문글을 작성하느라 코드에서 한 발짝 멀어지게 되거든요.

다만 다른 프로그램과 상호작용하는 경우, 예를 들어서 '다른 프로그램'의 버튼을 클릭하거나, '다른 프로그램'의 화상을 찾는 등의 동작을 하면 올바른 코드임에도 불구하고 원하는 동작이 되지 않을 수 있습니다. 모든 프로그램이 만들어진 방식이 같지 않기 때문입니다. 그것은 코드의 문제가 아니기에, 원인과 해결책이 다양합니다.

그 원인 중 하나는 해당 프로그램의 개발자가 의도적으로 이러한 동작을 제한한 경우입니다. 이를 우회하거나 편법을 사용하여 그들이 원하지 않았던 동작을 하는 것은 도덕적으로 옳지 못함을 말씀드립니다. 기술적인 가능 여부와 별개로, 이런 경우엔 '해결할 수 없음'으로 취급하는 것이 옳습니다.

•  44. 프로그래밍 문제 (6)
• 46. 지나쳤던 내용 