본문 바로가기

비개발자의 개발 일지

현장 팀장에서 수출 ERP까지 — AI와 함께 시스템을 만든 기록

시리즈 보기
비개발자의 개발 일지_Episode

5편 — 문법은 다 배웠는데, 왜 만들 줄은 모를까

by 왕진 2026. 6. 13.
반응형

 

 

Dev Story · 5편 — 개발의 현실

문법은 다 배웠는데,
왜 '만들 줄'은 모를까

비개발자의 첫 시스템 — 진짜 어려웠던 건 문법이 아니었다

앞의 네 편을 만들면서 계속 들었던 생각이 있어요. "나 분명 1년 독학으로 문법은 다 뗐는데, 왜 이렇게까지 힘들지?" 오늘은 그 이야기입니다.

1 문법은 '끝'이 아니라 '시작'이었다

독학을 마쳤을 때, 저는 솔직히 이제 만들기만 하면 될 줄 알았습니다. 변수도 알고, 반복문도 알고, 함수도 알고, DB도 다룰 줄 아니까요.

그런데 막상 시스템을 만들기 시작하니, 문법은 전체의 10%였습니다. 나머지 90%는 문제집엔 한 번도 안 나오던 것들이었어요. 앞에서 얘기한 기획·설계·연결고리·스코프… 그게 다가 아니었습니다.


2 첫 번째 — "왜 안 되지"의 미궁 (디버깅)

AI와 같이 짠 코드인데도, 분명 맞는 것 같은데 안 됩니다. 화면은 하얗고, 에러 메시지는 외계어 같고요. (AI가 짜 줘도 에러는 나고, 그걸 같이 붙들고 고치는 게 개발이더라고요.)

Fatal error: Uncaught Error: Call to a member function ... on null in /.../Controller.php:42 ↑ 이게 무슨 말이지… (한참을 노려봄)

책에선 코드가 항상 깔끔하게 '됐'습니다. 그런데 진짜 개발은 대부분의 시간이 '왜 안 되는지'를 찾는 일이더라고요. 반나절을 헤매다 결국 오타 하나, 콤마 하나였던 적이 셀 수 없습니다.

코딩은 '짜는 시간'보다 '안 되는 걸 고치는 시간'이 훨씬 길다. 이걸 아무도 안 알려줬어요.

반응형
3 두 번째 — 채점해 줄 사람이 없다

독학할 땐 문제집에 정답이 있었습니다. 내가 푼 게 맞는지 바로 확인이 됐죠. 그런데 내 시스템엔 정답지가 없습니다.

"이 구조가 맞나? 이렇게 설계하면 나중에 안 터지나? 이게 최선인가?" — 끝없이 묻는데, '이 길이 맞다'고 책임지고 말해 줄 사람이 없었습니다. 곁에 AI는 있었지만, AI는 의견을 줄 뿐 — 그 결정을 같이 책임져 줄 사람 동료는 없었으니까요. 모든 결정이 오롯이 제 몫이었습니다.

이게 1인 개발의 진짜 무게였어요. 기술이 어려운 게 아니라, "이게 맞는 길인지 아무도 확인해 주지 않는다"는 외로움이요.
4 세 번째 — 끝을 내가 정해야 한다

"조금만 더 다듬으면 완벽할 것 같은데." 이 생각이 가장 위험했습니다. 다듬을 곳은 끝이 없거든요. 버튼 색 하나, 정렬 하나에 며칠씩 붙잡혀 있기도 했어요.

아무도 "이제 됐으니 그만"이라고 말해 주지 않습니다. '이 정도면 충분하다'는 선을 스스로 그어야 합니다. 그걸 못 그으면, 완성은 영원히 안 옵니다. (1편에서 "최소부터"를 택한 게, 사실 이 늪에 안 빠지려는 몸부림이기도 했어요.)


5 그래서 — AI를 '같이 생각하는 팀'으로 곁에 뒀다

이 막막함을 혼자 다 짊어지지 않을 수 있었던 건, AI(팀)를 곁에 뒀기 때문입니다. 막힌 코드를 같이 짚어 주고, 구현도 함께해 줬어요. 정답지도 사람 동료도 없던 자리에, '멈춰서 같이 생각해 주는 상대'가 있었던 거죠.

다만 한 가지는 분명히 해둘게요 — 저는 코드를 한 줄 한 줄 읽거나 이해하려 들지 않았습니다. 수천 줄을 일일이 볼 수도 없고, 그럴 필요도 없었어요. 제가 본 건 딱 하나였습니다 — "이 구현이, 내가 기획한 대로 돌아가는가." 코드 자체가 아니라 결과가 내 의도와 일맥상통하는지를 봤어요.

나는 코드를 읽지 않았다. 대신 "이게 내가 그린 그림과 같은가"를 봤다.

6 이번 편의 산출물 — '개발이 막막할 때' 체크리스트

막히고 무너질 것 같을 때, 저는 이 다섯 가지를 스스로에게 물었습니다.

☑ 막혔을 때 점검 체크리스트
☐ 지금 막힌 게 '문법'인가, '무엇을 만들지'인가? (대개 후자)
☐ 에러라면 — 메시지를 끝까지 한 줄씩 읽었나? (대부분 거기 답이 있다)
완벽하게 하려다 멈춰 있진 않나? 일단 굴러가게 한 뒤 고치자
☐ 혼자 끙끙댄 지 30분이 넘었나? → 묻자 (검색·AI)
☐ 나온 결과가 '내가 의도한 대로' 동작하나? (코드를 다 이해 못 해도, 기획과 맞는지는 판단할 수 있다)

7 AI가 갈린 지점 / 사람이 결정한 지점

🤝 이번 편의 결정

AI(팀)가 한 것: 구현을 도맡았습니다 — 수천 줄의 코드를요. 막히면 고치고, 새로 짜고.
사람이 한 것: 저는 그 코드를 읽지도, 다 이해하지도 않았습니다. 대신 "이게 내가 기획한 대로 동작하는가"만 봤어요. 코드 리뷰가 아니라 '의도-구현 일치' 검수였죠.
교훈: 비개발자가 AI로 시스템을 끝까지 끌고 가는 힘은 코드를 읽는 능력이 아니었습니다 — '무엇을 원하는지 명확히 하고, 나온 결과가 그것과 맞는지 판별하는' 능력이었어요. (다음 편 — 드디어 이 첫 시스템을 세상에 처음 올려 본, 무료 호스팅 배포 이야기.)

핵심 한 줄 요약

착각문법 떼면 만들 수 있을 줄 알았다 (문법은 10%)
어려움 1디버깅 — '왜 안 되지'를 찾는 게 대부분의 시간
어려움 2정답지도 동료도 없음 (1인 개발의 외로움)
어려움 3끝을 스스로 그어야 함 (완벽주의의 늪)
버틴 법AI를 '같이 생각하는 팀'으로 — 코드 말고 '기획과 맞는지'를 검수
다음 글6편 — 첫 배포, 무료 호스팅에 처음 올려 본 날

Tags

#개발어려움 #디버깅 #1인개발 #비개발자 #완벽주의 #첫프로젝트 #회고 #AI협업 #학습법 #멘탈관리 #웹개발 #티스토리
▼ 티스토리 태그 입력란 복사용
개발어려움, 디버깅, 1인개발, 비개발자, 완벽주의, 첫프로젝트, 회고, AI협업, 학습법, 멘탈관리, 웹개발, 티스토리
반응형

댓글