노트 전체 보기 · 게시일 2026-10-22
TOEIC 앱 하나는 대체 얼마나 클까요? 숫자로 보는 핸디 990의 규모: 65만 줄의 코드, 28,640문제, 8만 개의 오디오 파일
핸디 990은 첫 코드를 작성한 날부터 오늘까지 딱 156일이 되었어요. 프로젝트 전체를 샅샅이 뒤져서 코드, 문제, 학습 자료, 이미지, 오디오 파일, 동영상, 변경 기록, 출시 버전, 글, 설계 문서까지 전부 세어 보았어요. 이 글에서는 그 모든 숫자를 펼쳐 놓고 각각 어떻게 계산했는지 설명하는 김에, 앱에서 "문제 신고"를 누르면 실제로 어떤 일이 벌어지는지, 그리고 어떤 숫자는 너무 진지하게 받아들이지 않아도 되는지 함께 이야기해 볼게요.
결론부터: 한눈에 보는 요약표
| 항목 | 수치 |
|---|---|
| 개발 일수 | 156일(2026-05-19 첫 저장) |
| 코드 | 654,678줄 |
| 자동화 테스트 | 5,069개 |
| 문제(TOEIC 7개 파트 + 보충 연습) | 28,640문제 |
| 문제와 학습 자료 속 영어 | 약 116만 단어 |
| 번역 대조 문자열 | 976,479개 |
| 이미지 | 7,153장(앱 프로젝트 내) + 그림 2,538점(클라우드) |
| 오디오 파일 | 79,854개, 약 80시간 |
| 동영상 | 24편 |
| 코드 변경 / 병합 요청 / 티켓 | 5,523회 / 1,521건 / 1,226건 |
| 출시 버전 | 81개(1.0.0 → 1.74.0) |
| 공식 웹사이트 페이지 / 글(이 글 게시 전) | 445페이지 / 84편 |
| 설계 및 엔지니어링 문서 | 234건, 57,536줄 |
아래에서 항목별로 하나씩 살펴볼게요.
코드: 65만 줄, 가장 큰 파일에는 로직이 한 줄도 없어요
| 영역 | 파일 수 | 줄 수 |
|---|---|---|
| 앱 본체 | 301 | 297,228 |
| 자동화 테스트 | 303 | 133,087 |
| 웹 버전 | 426 | 116,584 |
| 콘텐츠 생성, 검사, 배포 스크립트 | 336 | 89,262 |
| 클라우드 백엔드(신고 전달, 구독 검증…) | 25 | 10,256 |
| 공식 웹사이트 생성기 | 8 | 7,568 |
| 모바일 OS별 전용 코드 조각 | 5 | 693 |
| 합계 | 1,404 | 654,678 |
알아 두면 재미있는 몇 가지 디테일이에요:
- 가장 큰 파일은 인터페이스 텍스트 파일로, 20,712줄이나 되지만 그 안에 "프로그램" 코드는 단 한 줄도 없어요. 앱에 나오는 모든 문장이 여기에 살고 있어요: 인터페이스 문구 2,960개, 문자열 16,839개예요. 두 번째로 큰 파일은 홈 화면으로 17,232줄이에요. 알아요, 우리도 정말 쪼개고 싶어요.
- 앱 본체의 29.7만 줄 가운데 약 1.9만 줄은 데이터에서 자동으로 생성된 테이블이에요(예: 어근 수업의 확장 테이블, 문제 풀이 철칙의 품사 테이블). 이 줄들은 직접 "작성"했다고 보긴 어렵지만, 분명히 컴파일되고 테스트도 거쳐야 해요.
- 앱 본체에는 3,945개의 프로그램 단위가 있고, 그중 1,550개는 화면 컴포넌트이며 약 380개는 온전한 화면이에요. 기기 간에 동기화되는 데이터는 98종인데, 종류마다 각자의 병합 규칙이 있어요 — 이건 다음에 다른 글에서 다룰 주제예요.
- 테스트 코드 13.3만 줄은 앱 본체 크기의 45%에 달해요. 자동화 테스트는 총 5,069개인데, 모든 변경은 이 테스트를 전부 통과해야만 정식 버전에 합쳐질 수 있어요. 웹 버전에는 별도로 2.1만 줄의 테스트가 있어요.
덧붙이자면, "코드 줄 수"는 세상에서 가장 형편없는 생산성 지표예요. 품질을 측정하는 게 아니라 유지보수해야 할 대상이 얼마나 많은지를 보여 줄 뿐이거든요. 65만 줄이라는 말의 진짜 뜻은, 무엇을 건드리든 내가 망가뜨릴 수 있는 코드가 65만 줄이나 있다는 뜻이에요.
문제: 28,640문제, 두 무더기로 나뉘어요
첫 번째 무더기는 TOEIC 본연의 7개 파트로, 4,364개의 문제 세트에 담긴 11,032문제예요:
| Part | 문제 수 |
|---|---|
| Part 1 사진 묘사 | 335 |
| Part 2 질의응답 | 1,375 |
| Part 3 짧은 대화 | 2,082 |
| Part 4 짧은 담화 | 1,536 |
| Part 5 단문 빈칸 채우기 | 1,216 |
| Part 6 장문 빈칸 채우기 | 680 |
| Part 7 독해 | 3,808 |
두 번째 무더기는 보충 연습 17,608문제예요: 숙어 9,417, 단어 3,834, 문법 2,445, 연어 1,000, 문장 배열 441, 오류 찾기 246, 억양 구별 225.
문제는 출제만 했다고 끝이 아니에요. Part 1부터 Part 7까지 모든 문제에는 난이도 표시와 뜻풀이가 붙어 있어요 — Part 3~7은 선택지마다, 선택지를 귀로 듣는 Part 1과 2는 스크립트에 붙어 있죠. 그중 8,329문제(사분의 삼)에는 정답 근거 — 지문이나 대화의 어느 문장이 이 정답을 뒷받침하는지 — 가 함께 들어 있어요. Part 5와 Part 6에는 문법 태그가 따로 붙어 있고, Part 5–7의 5,682문제에는 상세 해설도 수록되어 있어요. 문제 은행이 과연 충분한지는 TOEIC 문제 은행, 이 정도면 충분할까요?(중국어)에서 9,854개의 클라우드 백업 데이터를 바탕으로 계산해 보았어요.
학습 자료: 문제보다 문제 밖의 자료가 더 많아요
"문제"는 연습으로 들어가는 입구일 뿐이에요. 단어, 숙어, 문법 같은 모듈 아래에는 저마다 겹겹이 쌓인 데이터가 자리 잡고 있어요:
- 단어 3,834개, 단어마다 사전적 의미, 어원 이야기, 연어(총 19,930세트), 세 가지 억양의 발음, 예문 낭독이 들어 있어요. 여기에 737개의 단어 패밀리, 201세트의 파생어, 152개의 어근과 접사, 145장의 테마 맵, 그리고 어떤 단어든 길게 누르면 바로 찾아볼 수 있는 10,176개 표제어 사전이 있어요.
- 숙어 3,022개, 9,417문제가 196개의 숙어 패밀리로 묶여 있고, 149개의 숙어에는 유래 이야기가 담겨 있어요.
- 문법 48개 주제, 주제마다 설명이 있고, 이와 별도로 총 46장 구성에 절마다 만화가 한 컷씩 들어간 〈문법 책〉(만화 총 139컷)이 있어요.
- 생활 실용 영어: 영어 속담 290문장(12개 주제), 발음하기 까다로운 단어 230개(8가지 함정 유형), 문화 유래 이야기 480편(9개 파트), 황당한 단어 이야기 136편(34개 레벨, 레벨당 네 편씩).
- 기타: 어근 수업 93강, 팁 카드 83장, 받아쓰기 문장 240개, 억양 비교 225문제(문제당 세 가지 억양), 77개 레벨의 단어 플레이리스트, 단어 그림 2,538점, 그리고 현재 10화까지 공개하고 여러분의 의견을 묻고 있는 단어 라디오(참고로 약 860화가 이미 녹음되어 대기 중이에요)가 있어요.
이 텍스트를 전부 합치면 문제와 스크립트 속 영어만 약 116만 단어(독해 48.7만, 듣기 스크립트 67.3만)이고, 대조용 번역 문자열은 976,479개에 달해요. 전체 콘텐츠의 데이터 파일은 563개, 총 230 MB예요. 한 페이지에 250단어, 한 권에 400페이지인 책으로 치면 대략 열한 권 반 분량이에요.
이미지, 오디오 파일, 동영상
이미지는 앱 프로젝트 안에 7,153장이 있어요:
| 유형 | 장수 |
|---|---|
| 단어 뜻 스티커 | 3,672 |
| 스토어 스크린샷 및 홍보 이미지 | 1,029 |
| 공식 웹사이트 일러스트, 스크린샷, 공유 카드 | 565 |
| 문화 유래 이야기 일러스트 | 484 |
| 듣기 Part 1 사진 및 도표 | 357 |
| 문법 책 만화 | 139 |
| 단어 이야기 일러스트 | 136 |
| 단어 공성전 성채 | 78 |
| Happysaur 마스코트 포즈별 이미지 | 29 |
| 아이콘, 브랜드, 라디오 캐릭터, 기타 | 664 |
이 밖에도 단어 그림 2,538점이 클라우드에 올라가 있는데, 앱에 기본 포함되지 않고 해당 단어를 열 때만 다운로드돼요.
오디오 파일은 가장 큰 덩어리예요. 프로젝트 안에 79,854개의 오디오 파일이 있어요. 무작위로 250개를 뽑아 길이를 잰 뒤 전체 개수를 곱해 보니 총길이는 약 80시간으로 추산돼요 — 잠을 자지 않고 처음부터 끝까지 들으려면 사흘이 넘게 걸리는 분량이에요:
| 유형 | 파일 수 | 추정 길이 |
|---|---|---|
| 듣기 문제 오디오(Part 1–4) | 9,306 | ≈ 21시간 |
| 단어 플레이리스트(단어, 뜻풀이, 철자, 예문, 연어) | 54,996 | ≈ 40시간 |
| 단어 예문 낭독 | 6,639 | ≈ 10시간 |
| 단어 발음(미국식) | 3,834 | ≈ 1시간 |
| 숙어 낭독 | 3,064 | ≈ 1시간 |
| 억양 훈련 | 1,365 | ≈ 1시간 |
| 워밍업 문제, 까다로운 발음 | 650 | < 1시간 |
여기에 더해 클라우드에 두고 필요할 때만 내려받는 영국식·호주식 단어 발음 7,668개와, 프로젝트 곳곳에 들어 있는 받아쓰기 240문장, 이야기 낭독 136편, 고사장 현장 소음 159개 트랙은 아직 포함하지도 않은 숫자예요. 단어 플레이리스트의 파일 54,996개 중 3,834개는 단어를 알파벳 한 글자씩 철자대로 읽어 주는 파일인데 — 이걸 직접 입으로 녹음하고 싶은 사람은 아무도 없어서 컴퓨터에게 부탁했어요.
동영상이 가장 적어요: 공식 웹사이트에서 연결되는 YouTube 동영상 24편(쇼츠 23편과 긴 영상 1편)이 2개의 재생목록으로 나뉘어 있어요. 프로젝트 안에는 시연용 동영상 파일이 딱 1개뿐이에요. 동영상 만들 시간은 대부분 위에 적힌 것들을 만드는 데 썼거든요.
개발 기록: 5,523번의 변경, 1,521건의 병합 요청, 81개의 버전
먼저 세 가지 용어를 설명할게요. 코드를 정식 기록으로 한 번 저장할 때마다 이를 commit(변경)이라고 불러요. 한 묶음의 변경은 다른 사람의 검토를 거치고 테스트를 통과해야만 정식 버전에 합쳐질 수 있는데, 이 묶음을 PR(병합 요청)이라고 해요. 그리고 모든 버그, 신고, 제안은 하나의 issue(티켓)가 돼요.
- 5,523번의 변경, 156일, 주말을 포함해 하루 평균 35번꼴이에요. 7월의 1,408번이 정점이었고, 그 이후로는 매달 1,250에서 1,400 사이를 유지하고 있어요.
- 1,521건의 병합 요청 중 1,509건이 병합되었어요. 모든 병합 요청은 먼저 5,069개의 자동화 테스트를 전부 통과해야 해요. 그중 213건에는 댓글이 다섯 개 이상 달렸는데, 대개 검토자와 작성자가 몇 차례씩 의견을 주고받은 흔적이에요.
- 1,226건의 티켓 중 1,190건이 닫혔어요. 이 가운데 562건은 문제 신고이고, 534건은 의견 피드백이에요 — 다시 말해 1,096건(89%)은 여러분이 앱에서 "문제 신고"를 눌러서 만든 거예요. 이 프로젝트 최대 규모의 테스트 팀은 무급으로 일하고 있는 셈이죠. 나머지 130건은 우리가 직접 연 티켓이에요: 기능 제안, 버그, 해야 할 일이죠. 이 처리 과정은 바로 아래에서 따로 한 섹션을 할애해 설명할 만해요.
- 81개의 출시 버전, 5월 19일의 1.0.0부터 오늘의 1.74.0까지 평균 1.9일에 한 버전씩 나왔어요. 처음부터 계획한 건 아니고, 뒤돌아보니 그렇게 되어 있었어요.
- 그 밖에도 몇 차례의 설문조사를 포함해 앱 내 공지를 106건 보냈는데, 가장 최근 설문 결과는 사용자들이 우리 방향이 틀렸다고 했다(중국어)에 정리해 두었어요.
"문제 신고"를 누르면 어떤 일이 벌어질까요?
문제를 풀다가 "문제 신고"를 누르고, 두 문장쯤 적어서 보내요. 그러면 그다음에는 이런 일이 벌어져요:
- 몇 초 안에 티켓 하나로 바뀌어 우리의 추적 시스템에 들어가고, 위에서 말한 1,226건과 나란히 줄을 서요. 여러분이 직접 적지 않은 정보는 앱이 대신 첨부해 줘요: 해당 문제 번호, 앱 버전, 휴대폰 모델, OS 버전, 사용 언어까지요. 버그를 잡을 때 가장 절실하지만, 이메일을 보내는 분들은 거의 언제나 적기를 깜빡하는 바로 그 정보들이에요.
- 여러분의 휴대폰이 이 티켓 번호를 기억해요. "설정 → 내 신고 내역"에 들어가면 현재 상태를 볼 수 있어요: 접수됨 → 처리 중 → 수정 완료. 만약 무슨 뜻인지 우리가 이해하지 못하면 상태가 "추가 정보 필요"로 바뀌고, 옆에 내용을 덧붙일 수 있는 버튼이 나타나요. 계정도, 이메일도, 어디에 로그인할 필요도 없어요.
- 우리가 티켓에 남긴 모든 답변은 원문 그대로 여러분의 휴대폰에 나타나요. 거기에 다시 답장을 보내거나 스크린샷을 추가할 수도 있고, 우리가 완료 처리한 뒤에 다시 열어서 "아직 안 고쳐졌어요"라고 말할 수도 있어요.
- 수정이 끝나면 티켓에 수정된 버전이 표시되고, 여러분 화면에는 "1.xx에서 수정됨"이라고 뜨며 홈 화면에도 "신고 내역이 업데이트되었습니다"라는 알림이 나타나요. 업데이트할 때가 되었다는 것도, 왜 업데이트해야 하는지도 바로 알 수 있어요.
바로 이런 이유 때문에 다른 경로가 아니라 꼭 앱 안의 "문제 신고"를 이용해 달라고 거듭 부탁드리고 있어요:
- 이메일: 문제 번호도, 버전도, 기기 모델도 없어서 우리가 먼저 세 가지 질문을 담아 답장을 보내야 해요. 게다가 추적 시스템에 들어가지 않으니 다음 이메일에 묻혀 버리기도 쉬워요.
- 설문조사: 설문조사는 익명이라 문제를 확인하더라도 자세한 상황을 물어볼 사람을 찾을 수 없고, 수정이 끝났다고 알려 드릴 방법도 없어요.
- 스토어 리뷰(가장 난감한 경로): 공개 답글을 한 번 달 수는 있지만 대화가 이어지지는 않아요. 문제 번호나 버전을 되물을 수도, 수정됐다고 알려 드릴 수도 없어요. 더 안타까운 건 "1,204번 문제 정답이 틀렸어요"라는 별점 한 개짜리 리뷰는 바로 다음 날 문제가 수정된 뒤에도 스토어 페이지에 몇 년이고 그대로 남아 있다는 점이에요.
앱에서 "문제 신고"를 눌러 접수된 1,096건의 티켓은 단 한 건도 빠짐없이 사람이 직접 읽고, 답장하고, 수정 후 알림까지 보내 드렸어요. 다른 곳으로 보내 주신 의견은 그저 최선을 다해 챙겨 볼 뿐이에요.
공식 웹사이트: 445페이지, 84편의 글
이 글을 올리기 전 기준으로 공식 웹사이트 handy990.happysaur.com에는 445개의 웹페이지가 있고, 그중 번체 중국어판이 102페이지예요. 글은 다섯 섹션으로 나뉘며 총 84편이에요: 기술 문서 24편, 영어 지식 33편, TOEIC 가이드 14편, 실전 리포트 3편, 개발 노트 10편 — 그리고 지금 읽고 계신 이 글이 11번째 개발 노트예요.
설계 문서: 234건, 5.7만 줄
보통은 아무도 세어 보지 않는 항목이지만, 아마 "이 프로젝트를 어떻게 만들고 있는가"를 가장 잘 보여 주는 숫자일 거예요. 모든 기능은 코드를 작성하기 전에 설계 문서부터 먼저 작성해요: 어떤 문제를 해결하려는지, 왜 다른 방식이 아니라 이 방식을 택했는지, 데이터는 어떻게 저장하고 어떻게 테스트할지, 그리고 어떤 것은 의도적으로 하지 않을지까지 적어 두죠. 기능이 출시된 뒤에도 문서는 그대로 남아서, 다음에 그 기능을 수정하는 사람이 문서를 먼저 읽게 돼요.
| 분류 | 문서 수 |
|---|---|
| 기능 설계 | 81건, 31,142줄 |
| 콘텐츠 집필 규격 및 검수 | 24 |
| 엔지니어링(동기화, 계정, 텔레메트리, 미디어 호스팅, 웹 버전) | 18 |
| 마케팅 | 16 |
| 홍보 문구 | 57 |
| 비즈니스 모델 | 4 |
| 스토어 문구 | 6 |
| 기타 | 28 |
그 옆에는 "도구를 위한 도구" 세트도 갖춰져 있어요: 336개의 스크립트, 51개의 원클릭 빌드 명령어, 11세트의 패키지화된 워크플로(문제 출제, 문제 검수, 버전 배포, 버그 수정, 지금 같은 글 쓰기…)가 있죠. 이것들은 단 한 줄도 앱 안에 나타나지 않지만, 이것들이 없었다면 위에 나열한 콘텐츠는 만들어질 수 없었어요.
어디에 넣기 애매한 몇 가지 숫자 더
- 프로젝트 안에는 117,208개의 파일이 있고 용량은 5.06 GB예요. 여기에 모든 변경의 전체 기록까지 더하면 8.7 GB예요.
- 아직 검수를 통과하지 못해 앱에 들어가지 않은 반제품 상태의 콘텐츠가 별도로 2.4 GB 있어요.
- 32개의 보충 연습 모듈이 있어요(속담, 발음, 문화 유래, 이야기 같은 "생활 실용 영어"는 제외한 숫자예요).
- 9월 8일 기준, 9,854개의 클라우드 백업이 있어요.
조그만 일곱 명짜리 팀이 어떻게 해냈을까요?
핸디 990은 일곱 명이 156일 동안 만들었어요. (일곱 명짜리 팀이라는 건 이 사이트가 줄곧 고수해 온 공식 설정이에요. 혹시 앱의 "개발팀 소개" 페이지에서 "1인 개발"이라는 말을 보셨더라도 못 본 척해 주세요. 아래 이야기를 아무리 세어 봐도 사람이 한 명밖에 안 나오는 것 같다면, 그건 나머지 여섯 분이 워낙 조용히 지내는 편이라 그래요.) 솔직히 말해서 특별한 비결 같은 건 없고, 첫날에 정해 둔 뒤로 단 한 번도 어기지 않은 몇 가지 원칙만 있어요:
- 문서를 먼저 쓰고, 코드는 그다음에 짜요. 위에 나온 81건의 기능 설계 문서는 나중에 뒷북으로 채워 넣은 게 아니에요. 어떤 기능에 대해 "왜 하는지"와 "무엇을 하지 않을지"가 명확하지 않으면 아예 첫 삽을 뜨지 않아요.
- 모든 콘텐츠는 똑같은 생산 라인을 거쳐요. 모든 문제는 출제 → 기존 문제 은행과의 중복 검사 → 사람의 직접 검수 → 출시 단계를 거쳐요. Part 7의 독해 지문이든 속담 한 줄의 번역이든 예외가 없어요. 도구(AI 도구를 포함해서요)가 초안을 만들고 문제점을 찾는 걸 도와주지만, 사람이 직접 눈으로 확인하지 않고 올라가는 문제는 단 하나도 없어요.
- 테스트가 문 앞을 지키고 있어요. 5,069개의 자동화 테스트를 모든 변경 묶음이 전부 통과해야 해요. 우리가 겁도 없이 1.9일마다 새 버전을 낼 수 있는 이유예요.
- 쓰는 분들이 어디가 고장 났는지 알려 줘요. 티켓의 89%가 앱 안의 "문제 신고" 버튼에서 나와요. 우리는 모든 티켓에 답장을 남기고, 수정이 끝나면 앱 안에서 신고해 주신 분께 직접 알려 드려요.
일곱 명(일단 그렇다고 해 두죠), 156일, 65만 줄이라고 하면 무척 빨라 보여요. 하지만 진짜 시간이 걸리는 일은 언제나 "만들어 내는 것"이 아니라 "만들어 놓은 뒤에 그게 맞는지 판단하는 것"이에요 — 문서와 테스트는 바로 그 판단들을 남겨 두는 방법이고요.
하지만 솔직히 말하면요
늘 그렇듯 이 점은 분명히 짚고 넘어갈게요:
- 크다고 다 좋은 건 아니에요. 65만 줄, 2.8만 문제, 80시간 분량의 오디오 파일은 내일 여러분이 할 연습에 아무런 의미가 없어요. 중요한 건 오늘 여러분에게 추천된 그 10문제가 제대로 골라졌는가예요. 이 숫자들은 "돌봐야 할 살림이 얼마나 많은지"를 보여 줄 뿐, "얼마나 훌륭한지"를 말해 주지 않아요.
- 오디오 길이는 표본 추출로 추정한 값이라 몇 시간 정도 오차가 있을 수 있어요. 영어 단어 수도 언어학적 의미의 "단어"가 아니라 띄어쓰기를 기준으로 자른 거예요.
- 줄 수에는 프로그램 코드가 아닌 것들이 대거 포함되어 있어요: 인터페이스 텍스트, 자동 생성된 테이블, 테스트 코드 같은 것들이요. 진짜 프로그램 로직만 따진다면 아마 위에 적힌 숫자의 절반쯤 될 거예요.
- 562건의 문제 신고는 훈장이 아니에요. 한 건 한 건이 모두 결함 있는 문제 때문에 누군가 소중한 시간을 뺏겼다는 뜻이니까요. 숫자가 크다는 건 문제 은행이 크고 쓰는 사람이 많다는 뜻이기도 하지만, 우리가 갚아야 할 수정 부채가 많았다는 뜻이기도 해요.
- 모든 숫자는 2026년 10월 22일 당일 기준이에요. 다음 주면 다 틀린 숫자가 될 거예요.
이 글은 핸디 990의 개발 노트예요. 관련 글: 사용 기록으로 문제 은행 커버리지를 살펴본 TOEIC 문제 은행, 이 정도면 충분할까요?(중국어), 가장 최근 설문조사 결과를 담은 사용자들이 우리 방향이 틀렸다고 했다(중국어).