밤 열 시, 작은 게임을 만들려고 편집기를 켰습니다. 오늘의 목표는 블록 하나를 오른쪽으로 움직이는 것입니다. 그런데 잠깐 본 글에는 AI가 개발자의 일을 모두 대신한다고 적혀 있습니다. 다른 글에는 AI를 쓰면 기초가 무너진다고 적혀 있습니다.
“그래서 켜라는 걸까, 끄라는 걸까?”
편집기는 그대로인데 고민만 커졌습니다. 이 글에서는 그 밤의 개발자와 함께 작은 게임 하나를 만들어보려 합니다. 상황 속 인물과 대화는 설명을 위한 가상 사례입니다. 결론을 먼저 말하면, 배워야 할 것은 생성된 코드를 내 조건에 맞게 이해하고, 확인하고, 고치고, 끝내는 능력입니다. 그 능력을 어디서부터 연습할지 한 장면씩 따라가 봅시다.
실행 버튼은 눌렸는데, 내 머릿속에서는 아직 실행되지 않았다
AI에게 블록 이동 코드를 부탁하니 금세 답이 나옵니다. 붙여넣고 실행합니다. 블록이 움직입니다. 신이 나서 오른쪽 키를 계속 눌렀더니 벽을 넘어갑니다. 다시 고쳐달라고 합니다. 이번에는 벽 앞에서 멈추지만 회전이 고장 납니다.
수정을 반복한 끝에 화면은 그럴듯해졌습니다. 그런데 친구가 “왜 벽 앞에서는 멈추는 거야?”라고 묻자 설명이 막힙니다. 결과물을 얻은 경험과 규칙을 이해한 경험이 아직 만나지 않은 것입니다.
이때 AI를 전부 꺼야 한다는 결론으로 급히 갈 필요는 없습니다. 지금 무엇을 배우려는지 먼저 정하면 됩니다. 충돌 검사가 공부의 목표라면 그 판단 순서는 직접 생각해봅니다. 이미 이해한 반복 코드나 단순한 형식 정리는 도움을 받을 수 있습니다. 학습할 부분과 생산성을 높일 부분을 의식적으로 나누는 것입니다. 시험이나 과제라면 해당 도구 사용 규칙이 우선입니다.
오류는 새 코드를 부탁하기 전에 읽어볼 단서다
어느 날 반복문이 다섯 번 돌아야 하는데 네 번만 돕니다. 평소처럼 전체 코드를 바꿔달라고 하려다가 잠깐 멈춥니다. 기대한 결과를 적고, 실제로 무엇이 나왔는지 확인합니다.
그림 1 · 원본 02:59. 다섯 번을 기대했는데 네 번 실행된 상황을 보여주는 자체 제작 도식. 먼저 기대값과 실제값을 나누면, ‘안 돼요’가 ‘어느 조건에서 한 번 부족한가’라는 질문으로 바뀝니다.
중단점을 걸어봅니다. 중단점은 프로그램 실행을 지정한 곳에서 잠시 멈추게 하는 표시입니다. 그 순간 반복문의 값과 조건을 보고, 한 줄씩 진행하며 처음 예상과 달라지는 지점을 찾습니다. VS Code의 디버깅 안내에서도 이런 실행 제어와 변수 확인을 설명합니다.
디버깅을 시작할 때는 세 가지를 짧게 적어두면 좋습니다. 어떤 입력으로 문제가 생기는지, 원래 기대한 결과는 무엇인지, 실제 결과는 무엇인지입니다. 그다음 가능한 원인을 하나씩 확인합니다. 한꺼번에 다섯 군데를 바꾸면 고쳐져도 무엇이 원인이었는지 알기 어렵습니다.
AI에 물어보는 말도 바뀔 수 있습니다. “다 고쳐줘” 대신 “이 입력에서 반복 횟수가 하나 부족하다. 먼저 확인할 조건을 한 가지씩 제안해줘”라고 요청합니다. 답을 받은 뒤에는 직접 값을 보고 같은 입력으로 다시 확인합니다. 마지막에 왜 틀렸는지 한 문장으로 적을 수 있다면, 이번 오류는 다음에도 꺼내 쓸 경험으로 남습니다.
기초는 전부 외운 뒤 입장하는 자격증이 아니다
기초 공부 목록을 열면 자료 구조, 알고리즘, 운영체제, 네트워크가 줄을 섭니다. 이걸 모두 끝내야 작은 게임을 만들 수 있는 걸까요? 그 생각을 하면 시작부터 지칩니다.
오늘 만들 기능에서 질문을 꺼내봅시다. 기다리는 행동을 먼저 들어온 순서대로 처리하고 싶습니다. 그렇다면 줄을 서는 것처럼 데이터를 꺼내는 큐를 검토할 수 있습니다. 아이템 이름으로 정보를 찾고 싶다면 키로 값을 찾는 사전 같은 구조를 생각할 수 있습니다.
그림 2 · 원본 04:23. 왼쪽은 순서를 따라 꺼내는 큐, 오른쪽은 이름표로 값을 찾는 사전을 설명합니다. 자료 구조를 고르는 출발점은 멋진 이름보다 데이터를 어떻게 넣고 꺼낼지입니다.
같은 물건도 서랍에 넣을지 줄 세울지는 사용하는 방법에 달려 있습니다. 데이터도 마찬가지입니다. Python의 deque처럼 양쪽 끝에 넣고 빼는 연산을 효율적으로 제공하는 도구도 있습니다. 이름을 외우는 것에 더해 어떤 연산을 자주 할지 말해보면 선택 이유가 생깁니다. Python 자료 구조 문서
공부와 만들기를 번갈아 해봅시다. 기능을 만들다 설명하지 못한 부분을 발견하면 기초로 돌아갑니다. 배운 개념을 다시 작은 기능에 적용합니다. 이 순환은 공부 범위를 평생 작은 프로젝트 안에 가둔다는 뜻이 아닙니다. 당장의 질문을 발판으로 삼아 점차 더 넓은 원리를 배우는 방법입니다.
기술 선택도 같은 질문으로 설명할 수 있습니다. “AI가 추천했어요”에서 멈추지 않고, 왜 내 데이터와 규모에 맞는지, 무엇이 편해지고 어떤 제약을 받아들이는지 말해봅니다. 작은 혼자 쓰는 게임이라면 복잡한 서버 구성을 줄인 이유도 충분히 의미 있는 판단입니다.
빈 파일 앞에서는 먼저 말로 순서를 만든다
완성된 코드를 읽으면 이해되는 것 같지만, 빈 파일에서는 첫 줄부터 막힐 수 있습니다. 답을 알아보는 것과 답을 만드는 순서를 세우는 것은 다른 연습입니다. 시험에서 한 번 막혔다고 실력이 전부 없다는 뜻은 아닙니다. 긴장과 시간 압박도 영향을 줍니다. 다만 혼자 시작하는 과정은 따로 경험할 필요가 있습니다.
“중복된 이름을 빼되 처음 나온 순서는 유지하자.” 이 작은 문제를 받아봅시다. 민수, 지수, 민수가 들어오면 민수, 지수가 남아야 합니다. 첫 민수는 결과에 넣고 봤다고 기억합니다. 지수도 넣습니다. 두 번째 민수는 이미 봤으니 지나갑니다.
이제 코드로 옮길 판단이 생겼습니다. 이미 본 이름을 기억할 곳과 결과를 순서대로 모을 곳이 필요합니다. 함수 이름이 생각나지 않으면 문서를 볼 수 있습니다. 핵심은 문법을 모두 암기하는 것보다 입력에서 결과까지의 순서를 내가 정해보는 것입니다.
도움을 받았다면 답을 닫고 입력을 조금 바꾸어 다시 풀어봅니다. 빈 목록이면 어떻게 되는지, 같은 이름만 들어오면 어떻게 되는지도 확인합니다. 베낀 문장을 기억하는 대신 생각의 순서를 다시 꺼내보는 연습입니다.
블록 하나를 움직이는 일에도 작은 설계가 들어 있다
이제 블록 퍼즐로 돌아갑시다. 판은 칸이 모인 이차원 배열로 표현할 수 있습니다. 블록은 몇 개의 칸 좌표로 표현합니다. 오른쪽 키를 눌렀을 때 현재 좌표부터 바꾸기보다, 먼저 오른쪽으로 한 칸 옮긴 후보 위치를 만듭니다.
그 후보의 모든 칸이 판 안에 있고, 이미 쌓인 블록과 겹치지 않는지 검사합니다. 가능하면 실제 좌표에 반영하고, 불가능하면 이전 위치를 유지합니다. 입력 하나가 ‘후보 만들기 → 검사하기 → 반영하기’라는 과정으로 나뉩니다.
그림 3 · 원본 08:52. 판, 이동 후보의 충돌 검사, 블록 고정, 줄 삭제를 나눈 자체 제작 도식. 블록을 그리는 것과 게임 규칙을 연결하는 것은 별개의 단계이며 둘 다 필요합니다.
시간이 지나면 블록을 아래로 움직일 후보도 검사합니다. 더 내려갈 수 없다면 판에 고정하고, 가득 찬 줄을 확인합니다. 줄을 지운 뒤에는 위의 줄을 내려야 합니다. 새 블록이 나타날 자리가 없을 때는 어떻게 끝낼지도 정합니다.
이 작은 게임 안에 입력, 자료 구조, 좌표, 조건 판단, 상태 변경이 들어 있습니다. 거대한 기능 목록보다 이런 연결을 끝까지 완성하고 설명해보는 경험이 먼저 필요할 수 있습니다. 특정 게임 하나를 만들면 취업이 보장된다는 뜻은 아닙니다. 내가 이해하고 마무리할 수 있는 단위를 정해보자는 것입니다.
친구가 벽에 붙어서 회전 버튼을 연타했다
시연할 때는 중앙에서 블록을 예쁘게 떨어뜨렸습니다. 그런데 친구는 곧장 벽에 붙어 회전합니다. “왜 굳이 거기서 돌려?”라는 말이 나오려다가 멈춥니다. 그 입력을 할 수 있게 만든 것도 내 게임이었습니다.
그림 4 · 원본 10:35. 벽, 겹침, 여러 줄 삭제, 게임 종료 뒤 입력을 따로 살펴보는 도식. 개발자가 보여주고 싶은 정상 장면 밖에서도 규칙이 유지되는지 확인합니다.
먼저 기대하는 규칙을 적습니다. 벽을 넘어가는 회전은 거절할지, 옆으로 보정할지 정해야 합니다. 두 줄이 동시에 가득 찼을 때는 둘 다 지워져야 합니다. 게임이 끝난 뒤 이동 입력은 무시할지, 재시작 메뉴로 넘길지 정합니다. 테스트는 이 기대와 실제 결과를 비교하는 일입니다.
두 줄 삭제에 문제가 있다면 그 상황을 바로 만드는 작은 판을 준비합니다. 매번 긴 게임을 처음부터 하지 않아도 같은 조건을 다시 실행할 수 있습니다. 문제가 있었던 입력과 기대 결과를 자동 테스트로 남기면 다음 수정에서 같은 오류가 돌아오는지도 확인할 수 있습니다. Python의 단위 테스트 설명
AI에게 놓친 경계 조건을 제안해달라고 할 수도 있습니다. 다만 제안된 결과가 게임 규칙과 맞는지 결정하는 일은 남습니다. 테스트를 통과했다는 말에는 어떤 조건을 검사했는지도 붙여야 합니다. 검사하지 않은 모든 상황까지 보장되는 것은 아니기 때문입니다.
“거의 다 됐어요”를 더 정확한 문장으로 바꾼다
화면에서 블록이 움직입니다. 거의 다 된 것 같습니다. 하지만 종료 후 입력은 남아 있고, 저장 실패도 처리하지 않았고, 다른 기능과 연결했을 때의 확인도 끝나지 않았습니다. 화면이 돌아가기 시작한 때와 일이 완료된 때 사이에 일이 남아 있습니다.
그림 5 · 원본 13:25. 정상 입력, 실패 처리, 저장 결과, 다른 기능과의 연결을 나눠 확인하는 자체 제작 화면. 실제 회사의 평가 자료가 아니라 완료 조건을 설명하기 위한 예시입니다.
완료 조건을 먼저 맞춰봅시다. 저장 기능이라면 버튼이 눌리는 것뿐 아니라 값이 남는지, 실패했는데 성공했다고 표시하지는 않는지, 다시 시도할 수 있는지도 볼 수 있습니다. AI가 만든 코드도 그 조건에 맞춰 확인합니다.
진행 상황도 구체적으로 말할 수 있습니다. “정상 이동은 됩니다. 벽 옆 회전에서 겹치는 문제가 남았고, 이 입력으로 재현됩니다.” 이렇게 말하면 도움을 줄 사람도 어디를 봐야 하는지 알 수 있습니다.
일이 늦어진 이유가 언제나 개인의 실력만은 아닙니다. 요구가 바뀌거나 확인할 사람이 없을 수도 있습니다. 그래서 남은 일을 드러내고 완료 기준을 함께 맞추는 능력도 개발 공부의 일부입니다. 혼자 모든 문제를 책임지는 사람이 되기보다, 확인한 사실과 막힌 조건을 나눌 수 있는 사람이 되는 것입니다.
도구를 쓴 시간과 배운 내용을 따로 돌아본다
AI가 첫 답을 빨리 냈다고 전체 작업도 반드시 빨리 끝나는 것은 아닙니다. 재시도와 수정, 결과 확인에 쓴 시간까지 살펴봅시다. 비용도 실제 사용 조건과 작업 전체를 기준으로 판단해야 합니다. 이 글은 특정 서비스의 현재 요금이나 향후 가격을 예측하지 않습니다.
가끔은 기능 하나의 자동 완성을 잠시 끄고 시작해봅니다. 블록을 한 칸 옮기는 정도면 충분합니다. 필요한 문서를 보되 입력, 검사, 반영의 순서는 직접 정합니다. 막히면 힌트를 받고 다시 답을 닫아봅니다. 도구를 금지하는 의식이 아니라, 어느 부분에서 스스로 출발할 수 있고 어디에서 도움이 필요한지 알아보는 시간입니다.
밤 열 시에 켰던 편집기로 돌아왔습니다. 오늘 끝낸 것은 거대한 게임이 아닙니다. 블록을 옮기기 전에 다음 칸을 검사하는 작은 기능 하나입니다. 대신 왜 그렇게 만들었고 어떤 입력으로 확인했는지 말할 수 있습니다.
내일은 그 설명 위에 다음 기능을 놓을 수 있습니다. AI가 있으면 도움을 받아 더 빠르게 만들고, 답이 틀리면 틀린 이유를 확인하고, 도구가 잠시 없더라도 어디서부터 시작할지 아는 것. 오늘의 작은 완성을 그런 방향으로 쌓아가면 됩니다.
자료와 그림
얌얌코딩 「AI가 코딩해 주는데, 개발자는 무엇을 배워야 할까?」 주제의 대본 v6와 17분 36.6초 검토 영상에서 재구성했습니다. 모든 그림은 영상의 자체 제작 설명 화면입니다. 외부 강연의 출연자나 특정 회사가 본문의 가상 대화를 했다는 뜻이 아닙니다.
기술 참고: VS Code 디버깅, Python collections, Python unittest. 제시한 공부 순서는 작은 완성 경험을 만들기 위한 제안이며 유일한 학습법이나 진로 보장은 아닙니다.