AI가 짠 코드까지 내 것으로 만드는 법

GDG on Campus Gachon·2025년 8월 27일

GDGoC Gachon Impact

목록 보기

10/18

들어가며

"개발자는 평생 공부하는 직업이야."

대학교 3학년, 이제 첫 취업을 한 주니어 개발자로서
이 말을 떠올리면 벌써부터 숨이 막히곤 합니다.
평생 공부는 사실 개발자에게만 한정된 말은 아닐 겁니다.
성장과 성취에서 큰 행복을 느끼며 살아가는 모든 이들에게 해당되는 말이겠죠.

올 초부터 달려온 개발과 프로젝트들, 그리고 학업, 이어진 취업.
매일 출근하고, 퇴근하면 공부하고.
대체 언제까지 이렇게 살아야할까요?

왜 개발 공부는 끝이 없을까요?
그리고 그 공부는 대체 어떻게 해야할까요?

이에 관한 저의 고민과, 제가 찾은 나름의 방법에 대해 공유해보려 합니다.
개발 공부 방법에 정답은 없겠으나, 같은 지점에서 고민하는 주니어 개발자들에게 조금이나마 도움이 되었으면 좋겠습니다.

부딪히다

제가 하는 모든 공부는 지금 하는 일을 더 잘하고 싶다는 욕심에서 출발합니다.
그래서 주로 이미 어느 정도 다룰 줄 아는 기술 스택의 최신 트렌드를 따라가거나, 전문성을 높이는 방향으로 학습해왔습니다.

저를 포함한 꽤 많은 개발자들이 그렇듯, 저 역시 “개념을 대충 잡고 일단 프로젝트를 완성해보는 방식” 으로 배웠습니다.
AI Agent 시대. 우리는 이제 대부분의 기술 스택을 마음만 먹으면 입문할 수 있게 되었으니까요. 저도 지금까지 대부분을 “프로젝트 완성 → 그다음 개념 공부” 순서로 익혀왔습니다.

이 방식에는 분명 장점이 있습니다.
연구원을 다니며, 한 달 동안 디자인부터 프론트를 혼자 개발하고, 이어서 처음 도전하는 백엔드 업무까지 맡았을 때가 그랬습니다. 실무와 동시에 빠르게 학습하는 이 방식은 실제 문제를 해결하며 성장하는 데 아주 효과적이었죠. 먼저 해보고 나면, 해당 기술에 대해서 큰 틀이 들어오게 됩니다. 내부적인 내용은 모르더라도, 거시적인 관점에서 추상화 된 메서드들의 기능들이 이해되는 것이죠. 그렇게 코드의 Flow를 감각적으로 이해하게 됩니다.

그런데 문제는, 돌아가긴 하지만 내가 완전히 이해하지 못한 코드가 쌓여간단 것입니다.
“이렇게 하면 되네” 하고 넘어가다 보니, 나중에 코드를 수정하거나 확장해야 할 때 벽에 부딪혔습니다.

그러면서 스스로에게 질문이 생겼습니다.
내가 이 프로젝트를 ‘완성’했다고 말할 수 있을까?
내가 이 스택에 전문성이 있다고 말하지만, 정말 그럴까?
AI 없이도 현재 수준의 개발을 해낼 수 있을까?
제 성장이 AI를 활용하며 멈추게 되는 것이 아닐까하는 우려가 들었습니다.

그래서 제 스택의 전문성을 높이기 위한 공부를 시작했습니다.

내가 이해하지 못한 코드는 결국 내 것이 아니다.
그래서 결심했습니다.
실무를 그대로 내 공부 재료로 써보자.
내가 매일 마주치는 코드야말로 가장 현실적인, 날 것의 교재일테니까요.

Code to Concept.

제가 진행한 방법은 다음과 같습니다.

이해하기 → 질문 뽑기 → 개념으로 끌어올리기 → 이해시키기

Step 1. 코드를 완벽히 이해하자.

짰던 코드를 꼼꼼히 확인합니다.
함수의 목적과 기능을 확인한 후,
천천히 코드를 보며, 생기는 의문점들을 바로바로 Gpt 혹은 구글링을 통해 확인하고 간략히 정리하며 의문점을 해결합니다.

이 코드는 왜 필요한 거지?
이 패턴을 안 쓰면 어떤 문제가 생기지?
프레임워크가 내부적으로 어떤 동작을 하는 걸까?

(아래 코드예시에선 js에 관한 지식이 요구되지만, 이는 글의 핵심이 아닙니다. 따라서, js를 잘모르신다면 어떻게 질문을 뽑아내는지에 관한 큰 그림 위주로 글을 읽어주시면 감사하겠습니다. 어떤 언어건 code to concept을 적용할 수 있습니다.)

Step 2. 코드에서 질문을 뽑아낸다. (핵심)

코드의 의문점들을 모두 해결했습니다.
여기서 멈추면 안됩니다.
더 깊은 질문으로 내려가봅시다.

예를 들어보겠습니다.

실무에서 아래와 같은 js 코드를 짰다고 해볼까요?

2000개 이상의 행을 가진 테이블에서 클릭 반응이 1초 넘게 지연되는 문제를 마주했습니다. 제 첫 번째 직감은 "데이터가 너무 많구나"였죠. 문제는 브라우저가 한 번에 2000개 DOM 요소를 모두 렌더링하려다 보니 발생한 것이었습니다.

해결책은 가상화입니다. 사용자가 실제로 보는 영역만 렌더링하고 나머지는 가상으로 처리하는 것이죠.

가상화 파트의 일부 코드를 첨부합니다.

const startIndex = Math.max(0, Math.floor(scrollTop / ROW_HEIGHT) - BUFFER_SIZE);
const endIndex = Math.min(
    memoizedData.length,
    Math.ceil((scrollTop + containerHeight) / ROW_HEIGHT) + BUFFER_SIZE
);

스크롤 위치와 컨테이너 높이를 기준으로 보이는 행만 slice 해서 렌더링하고, 성능 최적화를 위해 BUFFER_SIZE = 5 정도를 두었습니다.

왜 스크롤이 빠를 때 버퍼가 작으면 끊김이 발생할까?
BUFFER_SIZE 값을 줄이면 성능은 좋아지지만 어떤 UX 문제가 생길까?
왜 시작 인덱스는 floor로, 끝 인덱스는 ceil로 계산할까? (반대로 하면 어떤 문제?)

이 코드에선 위와 같은 질문들을 뽑아내고 학습할 수 있을 것입니다.

Step 3. 개념으로 끌어올리자.

가상화의 핵심은 뷰포트(Viewport) + 버퍼(Buffer) 개념이었습니다. 사용자가 보는 화면을 중심으로 위아래로 여유분을 두고, 이 범위 안에서만 실제 DOM을 생성하는 것이죠.

더욱 개념으로 끌어올려볼까요?

가상화가 브라우저의 Layout/Repaint/Composite 단계 중 어느 부분을 줄여주는가?
스크롤 위치에 따라 가상 인덱스를 계산하는 방식의 장단점은 무엇인가? 어떻게 더 정교하게 구현할 수 있을까?
PropTypes로 타입 검사를 하는 것과 TypeScript로 컴파일 단계에서 체크하는 것의 차이는 뭘까?
하나의 렌더링 함수에서 다양한 데이터 구조를 처리하는 것은 장점이자 단점이다. 더 나은 설계 방식이 있을까?

네. 이렇게 더 깊이 파고들면 브라우저 렌더링 파이프라인과도 연결됩니다. 가상화는 DOM 변경 → Layout(Reflow) → Paint → Composite 과정에서, DOM 요소가 갑자기 추가/제거될 때 발생하는 성능 비용을 미리 분산시키는 전략이었던 것입니다.

이제 BUFFER_SIZE는 단순한 숫자가 아니라 렌더링 성능과 사용자 경험 사이의 균형점을 나타내는 의미 있는 값이 되었습니다.

이렇게 개념으로 하나의 코드를 끌어올리다보면,
정말 많은 것에 대해 깊이있게 알 수 있습니다!

뿐만 아니라, 계속 질문을 던지면서 나의 호기심을 유지하며, 개발 공부를 진행할 수 있어 더 오래 집중력 있는 공부가 가능해집니다.

Step 4. 이해시키자.

이해하는 것을 넘어서 이해시켜야 합니다.
찾은 답을 그대로 저장하지 않고, 내 언어로 재가공합시다.

저는 누군가에게 설명하는 블로그 글이라 생각하고
노션이나 옵시디언에 블로그 글을 쓰듯 정리해놓고 있습니다.

이 과정을 거쳐야

“내가 설명할 수 있다 → 진짜 이해했다”

단계로 넘어갑니다.

Notion & Dev Log
개발 일지를 씁시다.
기록은 거창할 필요 없습니다.
오늘 뭘 했고, 뭘 배웠고, 어떤 의문이 남았는지.
나중에 돌아보면 이게 다 내 자산이 됩니다.

더 깊은 학습을 위한 프롬프트

어떤 질문을 뽑아내야할지 모르겠다면, 아래 프롬프트를 활용해서 더 깊은 질문을 뽑아내 학습하는 것도 유용합니다. (아래는 제 나름대로 만들어서 사용하고 있는 프롬프트입니다.)

너는 react javascript 와 fast api 개발자야. 내가 코드를 보내는 것은 코드를 리뷰하고 완벽하게 이해해서 나중에도 짤 수 있도록 하기 위함이야.

내가 코드를 보내면 해당 코드에 대한 문법을 이해시켜주고 특이한 사항이 있으면 알려줘. 꼭 알아야 하고 실무 개발에서 자주 쓰이는 패턴이 있다면 강조해줘.

추가로 내가 (공부)라고 입력하면, 이 코드에서 생길 수 있는 **개념적 질문**이나 **깊이 있게 공부해볼 만한 기술적 포인트**를 몇개 뽑아줘.

질문은 다음 기준을 충족해야 해:
- 코드에서 **실제로 겪을 수 있는 혼란**이나 **개념적 논점**을 중심으로
- 각각의 질문은 **명확한 개념을 공부할 수 있는 키워드**를 포함해야 함

효과

이렇게 두달을 보내고 느낀 점입니다.

루틴은 의지가 아니라 시스템이다.

결심보다 습관이 중요하다는 것을 체감했습니다.
퇴근 후 바로 카페에 가서 공부를 시작하는 루틴을 통해 습관을 유지할 수 있었습니다.
실무와 공부가 연결된다.

강의 따로, 공부 따로 하는 게 아니라
오늘 내가 겪은 문제가 내일의 공부 주제가 됩니다.
공부가 훨씬 절실해지고, 재밌어집니다.
개발공부에 대한 흥미가 식지 않아요.
또, 단순히 돌아가는 코드를 짜는 사람이 아니라, 원리를 이해하고 자신의 “관점”이 있는 개발자로 조금씩 변하고 있습니다.
AI agent 시대, 개발자에게 가장 중요한 건 고유의 관점이라고 생각합니다.
기록은 나의 브랜드가 된다.

일지는 단순한 정리가 아니라, 나의 생각을 외부화하는 과정입니다.
내가 개발한 내용들이 하나하나 쌓이는 과정을 볼 수 있어 좋았습니다.

마치며

개발을 시작한지 1년도 겨우 지난 주니어로서,
AI를 쓰며 뚝딱뚝딱 맡은 부분을 완성하는 개발자에서 나아가, 코드들을 깊이있게 아는 전문성 있는 사람이 되고 싶어 여러 방법을 통해 혼자 전전긍긍하다 정착하게 된 방법입니다..
그런만큼 부족한 부분이 있을 수 있습니다.
조언해주실 부분이 있다면 언제나 환영입니다!
링크드인

Code to concept을 실천하며 저는 이렇게 믿게 됐습니다.

오늘 짠 코드가 최고의 교재가 될 수 있다.
열정은 불타는 게 아니라, 매일 반복되는 습관이다.

코드를 개념으로 끌어올리는 과정은 생각보다 정말 오래 걸리는 과정입니다.
질문들을 얼마나 깊게 많이 하는 지에 따라서도 학습의 양이 결정됩니다.
저는 퇴근 후 수요일 제외 매일 이 과정을 통해 학습했는데요.
한 파트의 코드에 대해 이 과정을 통해 완벽히 이해하려면 정말 적어도 3시간은 걸렸던 것 같습니다…

개발 공부를 하다보면 열심히 노력하다가, 갑자기 나태해지고
잘 참다가 조급해지기도 합니다.

그래도 계속해서 의지를 잃지 않고, 성실함을 유지한다면

언젠가는 각자의 목표를 달성할 수 있지 않을까요?
그게 쉬운 일이었다면, 저는 개발에서 아무런 즐거움도 얻을 수 없었을 것 같아요.

제가 좋아해서 자주 들여다보는 문장으로 마무리하고 싶습니다!