학생이 만든 앱, 출시하고 나면 누가 고칠까요?

앱이 완성된 다음 날을 생각해봅니다

아이가 학교 행사 안내 앱을 만들겠다고 합니다. 달력에 일정을 넣고, 신청 버튼과 알림을 붙이면 될 것 같습니다. 개발을 도와줄 사람을 찾기 전에 한 장면을 생각해보겠습니다. 행사 장소가 전날 바뀌면, 누가 앱에 들어가 안내를 고칠까요?

부모가 제작비를 정할 때는 화면과 기능에 눈이 갑니다. 그런데 실제 이용자가 생기면 정보 수정, 접속 오류, 문의 대응이 이어집니다. 저희는 앱이 완성되는 날과 학생이 운영을 마치는 날을 함께 정합니다. 발표에서 보여줄 시제품인지, 정해진 기간 동안 사람들이 사용할 서비스인지에 따라 준비할 일이 달라지기 때문입니다.

Timeless의 소개와 종료 공지를 나란히 읽습니다

Timeless는 Emma Yang이 가족의 경험을 계기로 만든 앱입니다. 이전 제품 소개에는 일정 기억, 가족과의 연결, 얼굴 인식 기능이 나옵니다. 로그인 설명에는 외부 기업 Kairos가 제공한 얼굴 인식 기술도 명시돼 있습니다. 앱 안의 기능이 학생이 작성한 코드만으로 이루어진 것은 아니었습니다.

한편 현재 홈페이지 첫 화면은 개발자의 종료 공지입니다. Emma는 2019년 App Store에 앱을 출시했지만, 대학에 간 뒤 유지와 홍보에서 조금씩 물러났다고 씁니다. 여러 기능을 계속 작동시키려면 큰 수정이 필요해 App Store에서 내리기로 했다는 설명이 이어집니다.

저희가 읽는 핵심은 좋은 아이디어도 유지할 일이 남는다는 점입니다. Timeless의 얼굴 로그인처럼 외부 기술을 쓰는 기능은, 화면 구현뿐 아니라 그 서비스를 계속 쓸 조건과 나중에 수정할 책임까지 확인해야 합니다. 이 공지는 특정 기술이나 업체가 종료 원인이었다고 말하지 않습니다. 다만 학생 프로젝트의 계획에 유지 작업이 들어가야 하는 이유를 보여줍니다.

Timeless 공식 안내 · Timeless · Emma Yang 공식 안내

행사 안내 앱에서는 달력보다 수정 화면이 먼저일 수 있습니다

다시 학교 행사 앱으로 돌아오겠습니다. 아래는 Timeless의 실제 기능이 아니라, 운영 문제를 살펴보기 위해 저희가 만든 예시입니다. 학생이 혼자 행사 정보를 입력한 시제품이 있고, 이제 학교 동아리 몇 곳에 써보게 하려 합니다.

동아리 담당자가 장소 변경을 학생에게 메시지로 보내고, 학생이 직접 앱을 고쳐야 한다면 이용자가 늘수록 요청도 쌓입니다. 이 상태에서 예쁜 달력이나 알림을 더 붙여도 수정하는 사람은 여전히 한 명입니다. 먼저 담당자가 자기 행사 정보를 고칠 수 있게 할지, 운영할 동아리 수를 줄일지 정해야 합니다.

반대로 행사 정보가 자주 바뀌지 않고 학생이 짧은 기간만 관리하기로 했다면, 별도의 관리 화면을 크게 만드는 일이 과할 수도 있습니다. 운영 기간과 사람 수를 좁혀 시험하고, 실제로 수정 요청이 생기는지 본 뒤 확장할 수 있습니다. ‘관리 화면이 반드시 필요하다’가 아니라, 현재 운영 약속을 지킬 수 있는 방법을 고르는 일입니다.

같은 시제품에서 출발해도, 다음 준비는 다릅니다

행사 목록과 신청 화면이 이미 작동한다고 가정하겠습니다. 학생에게 남은 준비 시간은 두 주이며, 추가 제작에 쓸 예산도 같습니다. 아직 실제 이용자를 받지는 않았습니다. 이때 어느 쪽으로 갈지는 프로젝트의 목적에 달려 있습니다.

대회 발표에서 아이디어와 구현을 설명하려는 단계라면 첫 번째 방향이 맞을 수 있습니다. 실제 운영을 했다고 꾸밀 필요가 없습니다. 이미 학교가 사용하기로 했고 학생이 정해진 기간을 책임질 준비가 됐다면 두 번째 방향을 검토합니다. 같은 두 주에 기능 확대와 운영 확대를 한꺼번에 약속하지 않는 편이 낫습니다.

개발 도움을 구할 때는 완성 뒤의 범위도 묻습니다

멘토가 필요한지 외부 제작 도움을 받을지 판단할 때, ‘앱을 만들어준다’는 말만으로는 범위가 흐립니다. 견적에 ‘로그인 포함’이라고 적혀 있다면 학생이 직접 구현할 부분, 외부 서비스가 맡는 부분, 계정을 관리할 사람을 나누어 물어봅니다. 도움을 받은 뒤 학생이 스스로 바꿀 수 있는지도 확인합니다.

실제 운영까지 생각한다면 처음 제작비와 계속 드는 비용을 나누어 확인합니다. 로그인, 알림, 서버 등 외부 서비스를 쓰는 기능은 현재 요금과 이용 조건, 계정을 관리할 사람을 따로 봅니다. 무료로 시작할 수 있다는 사실만으로 이후 비용이 없다고 계산하지 않습니다.

기능 추가가 먼저인지 운영 정리가 먼저인지 애매하다면, 멘토에게 앱이 잘 작동하는 장면 하나와 실패하는 장면 하나를 함께 보여주면 좋습니다. 행사 장소를 바꿨는데 옛 정보가 남는 상황처럼 구체적으로 보여주면, 화면을 고칠지 정보 수정 방식을 바꿀지 판단하기 쉽습니다.

하버드 진학 사례에서 무엇을 가져올까요?

Technovation은 Emma Yang을 Timeless 창립자로 소개합니다. Harvard 공학·응용과학대학의 2025년 학생 프로필에서도 Timeless 개발과 Technovation 참가 이력, 컴퓨터과학 학부 과정을 함께 확인할 수 있습니다. Timeless를 초기 Technovation 수상작과 같은 작품으로 읽어서는 안 됩니다. 이 글에서 읽은 것은 그 뒤에 개발한 앱의 소개와 종료 공지입니다.

부모와 학생이 여기서 가져올 질문은 ‘이런 앱을 만들면 그 대학에 갈까’보다 구체적입니다. 우리 아이는 어떤 기능을 직접 만들었고, 왜 그 방식을 골랐으며, 실제로 쓰게 한다면 무엇을 더 책임져야 할까요? 원서에 활동을 설명할 때도 시제품 제작, 제한된 시험 운영, 장기 서비스를 구분하면 아이가 한 일이 더 정확해집니다.

Technovation 공식 안내 · Harvard 공학·응용과학대학 공식 안내

이번 주에는 기능 한 개만 끝까지 따라가봅니다

앱을 처음부터 다시 설계할 필요는 없습니다. 아이가 이미 만든 기능 하나를 고르고, 정보가 들어오는 순간부터 바뀌고 지워지는 순간까지 함께 살펴봅니다. 행사 앱이라면 날짜 변경 하나면 충분합니다. 누가 수정하는지, 바뀐 정보를 어떻게 확인하는지, 학생이 앱을 관리하지 않는 날에는 어떻게 되는지 들어봅니다.

답이 흐릿한 곳이 다음에 도움받을 지점입니다. 시제품으로 마무리할지, 운영 범위를 줄일지, 관리 기능을 더 만들지부터 고르면 제작비와 멘토링 시간을 어디에 쓸지도 선명해집니다. 해외 학교에서 준비하는 학생이라면 현지 학교의 사용·운영 조건도 함께 확인합니다.