Victor

[연재] 도구 하나가 나오기까지 — 기획·코드·검증의 실제 흐름

연재 · 2026-07-27

사진 2만 6천 장을 정리했더니 전부 "기타"로 갔습니다

 

오늘은 도구 하나를 처음부터 끝까지 따라가 보려고 합니다. 사진 정리 봇이에요.

 

외장 하드에 사진이 몇 년치 쌓여 있잖아요. 그걸 연도별·월별로 나누고, 사진 내용까지 봐서 폴더를 갈라주는 물건입니다. 만드는 데 세 시간쯤 걸렸어요.

 

다 만들고 진짜 제 사진을 처음 돌려봤습니다. 그랬더니요.

 

사진이 전부 "기타" 폴더로 갔습니다. 인물도 기타, 풍경도 기타, 음식도 기타. 하나도 안 갈렸어요.

 

 

그날 밤에 찍힌 기록입니다. 세 줄인데요.

 

  • 21시 10분 — 실제 사진이 전부 '기타'로 분류되던 문제
  • 21시 48분 — 비슷한 사진 찾는 게 2만 6천 장 규모에서 감당이 안 되던 문제
  • 22시 14분 — 카메라 원본 파일들이 잘못 합쳐지거나 사라지던 문제

 

셋 다 진짜 사진을 넣기 전에는 하나도 안 보이던 것들입니다. 그전까지 검사는 전부 통과하고 있었어요.

 

오늘 글은 이 세 줄이 어떻게 그날 밤 안에 다 잡혔는지에 관한 얘기입니다. 도구를 열몇 개 만들면서 굳어진 순서가 있는데, 그 순서 덕에 저기서 멈췄지 안 그랬으면 사진 2만 6천 장이 이미 엉뚱한 데 복사돼 있었을 거예요.

 

만들기 전에 채우는 다섯 칸

 

지금은 도구를 하나 만들 때마다 같은 칸을 채웁니다. 코드는 그 다음이에요.

 

 

사진 정리 봇의 설계 문서 일부입니다. 아직 코드는 한 줄도 없는 상태에서 적힌 것들이에요. 어떤 폴더 구조로 나눌지, 사진 내용을 어떻게 볼지, 무엇을 쓰고 무엇을 안 쓸지 같은 것들이 먼저 못 박혀 있습니다.

 

칸은 다섯 개예요. 하나씩 보여드릴게요.

 

① 뭘 만들지보다 뭘 안 만들지를 먼저 적는다

 

3편에서도 나온 칸인데, 이게 정말 매번 나옵니다.

 

 

사진 정리 봇의 제외 목록입니다. 사진 편집·보정, 클라우드 업로드, 얼굴로 사람 이름 붙이기, 화면 있는 프로그램. 전부 "있으면 좋지만 이번엔 안 한다"로 적어뒀어요.

 

왜 굳이 적느냐면요. 안 적으면 없어지는 게 아니라 몰래 들어옵니다. 만들다 보면 "사진 고르는 김에 자동 보정도 넣을까" 하면서 슬금슬금 커지거든요. 그러다 어느 순간 뭘 만들고 있는지 모르게 돼요.

 

이 칸이 AI와 일할 때 특히 중요하더라고요. 뭘 물어보든 "이런 것도 넣으면 좋습니다"가 계속 나옵니다. 그것도 하나같이 맞는 말이에요. 얼굴을 알아보면 사진 정리가 더 편해지는 건 사실이잖아요. 그래서 더 위험합니다. 틀린 제안은 거절하기 쉬운데, 맞는데 지금은 안 되는 제안은 거절할 근거가 필요하거든요. "범위 밖"이라고 적어둔 종이가 그 근거입니다.

 

② 만들기 전에 진짜 데이터를 본다

 

이 칸이 제일 값을 비싸게 치르고 얻은 칸이에요.

 

 

설계 문서의 두 번째 절인데 코드 얘기가 하나도 없습니다. 대신 이런 게 적혀 있어요.

 

  • 정리할 사진이 있는 곳: 외장 SSD 안의 백업 폴더
  • 규모: 약 26,885개 파일, 77GB
  • 종류: jpg 24,229 · png 1,070 · cr2 744 · jpeg 647 · gif 23 · mp4 66 · mov 18 · pdf 29 · hwp 8 · 압축파일 10 …

 

만들기 전에 제 외장 하드를 열어서 실제로 세어본 것입니다.

 

세어보니까 미리 정해야 할 게 나오더라고요.

 

cr2가 744장 있는데 이건 카메라 원본 파일이라 일반 사진 프로그램이 잘 못 엽니다. 그냥 두면 744장이 통째로 빠지거나 에러가 나겠죠. 동영상 84개는요? 사진처럼 내용을 볼 수가 없습니다. 한글 문서랑 압축 파일도 섞여 있고요.

 

그래서 셋 다 처리 방법을 따로 정했습니다. 사진은 전체 분류, 동영상은 날짜별로만, 나머지는 손대지 않고 목록에만.

 

그리고 저 숫자가 나중에 두 번 더 값을 합니다. 도입에 적은 21시 48분과 22시 14분이 각각 "2만 6천 장"과 "cr2 744장" 때문에 터진 거였거든요. 그건 뒤에서 다시 말씀드릴게요.

 

③ 한 덩어리로 만들지 않는다

 

 

사진 정리 봇은 일곱 칸으로 갈라져 있습니다. 사진 2만 6천 장을 한 번에 처리하는 게 아니라 한 칸씩 통과시키는 거예요.

 

이렇게 갈라두면 좋은 게 하나 있습니다. "복사실행" 바로 앞까지만 돌려볼 수 있어요. 어디에 뭐가 갈지 다 계산해놓고 실제 복사는 안 하는 거죠. 그 결과를 보고 마음에 들면 그때 마지막 칸을 돌립니다.

 

도입의 "전부 기타"를 여기서 봤습니다. 복사하기 전 단계의 결과를 열어봤더니 전부 기타로 가 있었어요. 한 덩어리로 뭉쳐놨으면 이게 안 됩니다. "일단 돌려보고 결과를 본다"가 곧 "사진 2만 6천 장이 이미 복사됐다"가 되니까요.

 

갈라놓는 건 구조 취향이 아니라 중간에 멈춰 설 자리를 만드는 일이었습니다.

 

④ 어떻게 확인할지를 코드보다 먼저 정한다

 

칸을 갈라두면 따라오는 게 있어요. 칸마다 따로 검사를 붙일 수 있습니다.

 

 

검사 파일 목록인데, 칸 이름과 거의 하나씩 짝이 맞죠. 훑는 칸, 중복 찾는 칸, 촬영일시 읽는 칸, 분류하는 칸, 계획 세우는 칸, 복사하는 칸 각각에 붙어 있습니다.

 

이 칸이 처음엔 제일 이상했어요. 아직 만들지도 않았는데 어떻게 확인할지를 먼저 정한다니까요. 그런데 몇 번 해보니 알겠더라고요. "이걸 어떻게 확인하지?"에 답을 못 하면, 그건 아직 뭘 만들지가 안 정해진 겁니다.

 

3편의 그 장면이 이 칸에서 나온 거예요.

 

 

육아휴직 계산기에서 "통상임금 60만 원인 사람에게 하한 70만 원을 주면 안 된다"를 찾은 것 말입니다. 만들기 전에 "이런 경우엔 얼마가 나와야 하지?"를 적다가 나왔어요. 코드를 다 짜고 나서 봤으면 아마 못 봤을 겁니다.

 

다만 오늘 사진 봇이 보여주는 게 하나 더 있습니다. 검사가 전부 통과하는데도 실제 사진에서는 전부 기타가 나왔어요. 검사는 제가 상상한 경우만 봅니다. 그 얘기는 조금 뒤에요.

 

⑤ 지켜야 할 선을 문장으로 적어둔다

 

마지막 칸이 제일 짧은데 제일 중요합니다.

 

 

  • 원본 파일을 수정·이동·삭제하지 않는다 (복사만 한다)
  • 기본은 미리보기다. 진짜로 복사하려면 따로 명령해야 한다
  • 다시 돌려도 같은 걸 두 번 복사하지 않는다
  • 못 다루는 파일은 건드리지 않고 목록에만 적는다

 

사진 26,885장을 옮기는 프로그램이잖아요. 여기서 뭔가 잘못되면 되돌릴 수가 없습니다. 그래서 "원본은 절대 안 건드린다"를 제일 위에 적어놨어요.

 

이 한 줄이 있으면 나중에 코드를 고칠 때도 그 선을 넘는 제안이 들어오면 바로 보입니다. "이미 정리된 원본은 지워서 공간을 아끼자" 같은 게 나와도 논쟁할 필요가 없어요. 안 하기로 적어둔 거니까요.

 

그리고 이 원칙 덕에 도입의 세 사고가 전부 되돌릴 수 있는 사고로 끝났습니다. 원본은 그대로 있었으니까요.

 

계획서를 고치는 게 코드를 고치는 것보다 쌉니다

 

설계가 끝나면 그걸 할 일 목록으로 잘게 쪼갭니다.

 

 

열 칸이에요. 그리고 칸 하나하나 안이 또 이렇게 생겼습니다.

 

Task 5: 중복 그룹화
  · 어떤 파일을 건드리나
  · 무엇을 내놓는 함수인가
  1) 실패하는 검사를 먼저 쓴다
  2) 정말 실패하는지 돌려서 확인한다
  3) 통과할 만큼만 짠다
  4) 통과하는지 돌려서 확인한다
  5) 커밋한다

 

"정말 실패하는지 돌려서 확인한다"가 왜 따로 한 줄을 차지하나 싶으실 텐데요. 이게 빠지면 검사가 통과했을 때 그게 진짜 통과인지, 검사가 애초에 아무것도 안 보고 있는 건지 구분이 안 됩니다.

 

계획서에서 한 줄 고치는 건 1분입니다. 같은 걸 코드가 다 짜인 뒤에 고치면 반나절이 갈 수도 있고요. 제일 싼 순간에 고치는 것, 그게 이 순서의 이유 절반쯤 됩니다.

 

그런데 다섯 칸을 다 채웠는데도 전부 "기타"였습니다

 

이제 도입으로 돌아갈게요.

 

설계 썼고, 실제 데이터 셌고, 일곱 칸으로 갈랐고, 칸마다 검사 붙였고, 안전 원칙도 적었습니다. 검사는 전부 통과였어요. 그런데 진짜 사진을 넣으니 전부 기타로 갔습니다.

 

원인은 사진 내용을 보고 점수를 매기는 방식에 있었어요. 원래는 "이 사진이 인물인가?"를 각각 따로 물어보고 점수가 일정 이상이면 그 폴더로 보내는 식이었는데, 실제 사진에서는 그 점수가 대체로 낮게 나오더라고요. 그래서 전부 "잘 모르겠음" 칸으로 떨어진 겁니다.

 

그래서 "넷 중 어느 쪽에 제일 가까운가"를 묻는 방식으로 바꿨습니다. 확신이 정말 없을 때만 기타로 가게요. 21시 10분 기록이 그겁니다.

 

나머지 두 개도 같은 성격이었어요.

 

21시 48분 — 비슷한 사진끼리 묶는 기능이 있는데, 원래 방식은 사진을 전부 서로 비교했습니다. 첫 장을 나머지 전부와, 둘째 장을 나머지 전부와… 이런 식으로요. 스무 장이면 190번이라 눈 깜짝할 새죠. 그런데 2만 6천 장이면 3억 6천만 번이 됩니다. 장수가 천 배 늘면 비교는 백만 배가 되는 셈이에요.

 

검사할 때는 사진 몇 장으로 했으니 당연히 멀쩡했습니다. 실제 규모에서만 터지는 종류였어요. 결국 "전부 서로 비교" 대신 비슷한 것끼리 미리 묶어두고 가까운 것만 찾아보는 방식으로 바꿨습니다.

 

22시 14분 — 카메라 원본 파일(cr2) 744장이 서로 중복이라고 잘못 묶였습니다. 원본을 직접 못 읽으니까 안에 든 작은 미리보기 그림으로 비교했는데, 그 미리보기들이 서로 너무 비슷했던 거예요. 그대로 뒀으면 서로 다른 사진 744장이 몇 장으로 합쳐지고 나머지는 빠졌을 겁니다.

 

세 개의 공통점이 보이시나요. 전부 "실제 사진을 넣기 전에는 알 수 없는" 것들입니다.

 

그래서 이 순서에 대해 정직하게 말씀드리면 이렇습니다. 다섯 칸은 실수를 없애주지 않아요. 실수를 되돌릴 수 있는 자리에서 나게 만들 뿐입니다. 복사 직전에 멈춰 설 자리가 있었고, 원본을 안 건드린다는 원칙이 있었기 때문에 저 셋이 전부 "밤에 고치면 되는 일"로 끝났어요. 없었으면 사진 2만 6천 장이 이미 엉뚱한 데 가 있었을 겁니다.

 

이 순서를 안 쓴 것도 있습니다

 

하나 더 정직하게 말씀드리면, 이 홈페이지 자체는 설계 문서 없이 만들었습니다.

 

 

첫날 기록인데요. 설계도 계획서도 없이 "초안"이라는 한 줄로 시작해서, 두 시간 안에 모바일 정리·댓글·조회수까지 차례로 붙었습니다.

 

왜 그랬냐면요. 여기엔 맞고 틀린 게 없거든요.

 

사진 봇은 사진이 엉뚱한 폴더로 가면 그게 틀린 겁니다. 눈으로는 2만 6천 장을 확인할 수 없으니 검사를 미리 정해야 하고, 그러려면 설계가 있어야 해요. 그런데 홈페이지는 "글 목록이 보기 좋은가"가 전부입니다. 이건 만들어서 띄워놓고 봐야 알아요. 문서에 "보기 좋게 한다"라고 적어봐야 아무 의미가 없고요.

 

실제로 그렇게 굴러갔습니다. 만들어보니 아래쪽 정보가 좌측 메뉴 칸을 침범하고 있어서 밖으로 뺐고, 사진이 너무 커서 줄였고, 제목 문구를 바꿨어요. 전부 화면을 보고 나서 안 것들입니다.

 

그래서 다섯 칸은 "틀려도 티가 안 나는 도구"에 맞는 순서예요. 계산기, 사진 정리처럼 결과를 눈으로 검산할 수 없는 것들이요. 보기에 관한 일은 빨리 만들어 띄워놓고 고치는 쪽이 낫더라고요. 어느 쪽인지 고르는 것부터가 사실 한 단계입니다.

 

그래서 사람은 어디에 있었나

 

다섯 칸을 다시 보면 이렇습니다.

 

하는 일누가 잘하나
① 안 만들 것범위를 자른다사람
② 진짜 데이터실제를 세어본다반반
③ 갈라놓기멈춰 설 자리를 만든다AI
④ 확인 방법검사를 먼저 적는다AI
⑤ 지켜야 할 선넘으면 안 되는 것사람

 

가운데 셋은 AI가 잘합니다. 흐름을 어떻게 나눌지, 경계값을 어떻게 훑을지, 3억 번 비교를 어떻게 줄일지 — 정확하고 빠르고 지치지 않아요. 도입의 세 사고도 원인을 찾고 고친 건 대부분 AI 쪽이었습니다.

 

양 끝의 두 칸이 사람 자리입니다.

 

①은 뭘 포기할지예요. 감당할 수 있는 크기는 만드는 사람만 압니다. 물어보면 "이것도 넣으면 좋습니다"가 계속 나오는데, 틀린 말이 아니라서 더 위험해요.

 

⑤는 뭘 넘으면 안 되는지입니다. "원본을 절대 안 건드린다" 같은 문장이요. 이건 기술이 아니라 잘못됐을 때 내가 감당할 수 있느냐의 문제라, 물어봐서 나오는 답이 아니더라고요.

 

②는 반반이라고 적었는데요. 실제 자료를 열어서 세고 어긋난 걸 찾는 건 AI가 훨씬 잘합니다. 다만 "진짜 사진으로 한번 돌려봤나?"라고 물어보는 건 사람이 해야 해요. 안 물어보면 검사만 통과하고 끝납니다. 그날 밤 세 줄이 딱 그 질문 하나에서 나왔어요.

 

다음 편에

 

여기까지가 "생성" 부의 실제 내용이었습니다. 다음 편은 이 부의 마지막이자 첫 번째 실패편이에요.

 

✗ 만들었는데 안 쓰게 된 것들 — 한 달 동안 도구를 열몇 개 만들었는데 그중 매일 여는 건 몇 개 안 됩니다. 나머지는 왜 안 쓰게 됐는지, 만들 때는 왜 몰랐는지를 적어볼게요. 잘 된 것보다 이쪽이 더 쓸모 있을 것 같아서요.

 

읽다가 궁금한 게 있으면 댓글로 남겨주세요. 로그인 없이 쓸 수 있습니다.

 


 

#사진정리 #사진백업 #외장하드정리 #개발프로세스 #기획 #설계문서 #요구사항 #스펙 #프로젝트관리 #AI코딩 #클로드 #ClaudeCode #바이브코딩 #1인개발 #사이드프로젝트 #개인개발 #파이썬 #자동화 #업무자동화 #테스트코드 #TDD #코드리뷰 #리팩토링 #데이터품질 #머신러닝 #이미지분류 #휴먼인더루프 #AI활용법 #AI와사이트만들기 #빅터하우스

댓글

    로그인 없이 쓰는 대신, 등록한 댓글은 직접 지울 수 없습니다. 지워야 할 댓글은 옆의 신고를 눌러주세요.
    네이버 블로그글 원문 보러가기 →유튜브 쇼츠만드는 장면 20초로 보기 →
    관리자 Victor · 문의는 우상단 신고·제안으로 남겨주세요.
    글과 화면은 정적 파일로 만듭니다. 댓글과 조회수만 외부 데이터베이스에 저장합니다 — 개인정보처리방침

    오류 신고 · 제안

    관리자 Victor에게 전달됩니다