제품 만들기 ·
앱 개발 언어 · 기술 스택, 맡기는 대표님이 알아야 할 것만
앱 개발 기술 스택은 화면 · 서버 · 데이터베이스 · 호스팅 · 앱 프레임워크로 나뉘어요. 앱 개발 언어와 플러터를 비개발자 말로 풀고, 업체에 물어볼 질문 5개와 유행보다 인수인계를 먼저 볼 이유를 정리했어요.
개발 업체와 미팅을 하면 낯선 단어가 쏟아져요. 리액트, 플러터, 노드, 스프링, AWS, 포스트그레스 같은 이름이에요.
대표님이 이 기술을 다 알 필요는 없어요. 하지만 업체에 어떤 질문을 해야 하는지는 알아야 해요. 처음 고른 기술이 나중에 사람 구하기와 매달 나가는 운영비를 정하거든요.
저는 에이전시를 8년간 운영하며 개발자 100명을 채용했어요. 사람이 바뀔 때마다 코드를 넘기고 받았어요. 그때마다 문제가 된 건 기술 이름이 아니라 인수인계 준비였어요.
앱 개발 기술 스택은 무엇인가요
기술 스택은 서비스를 만드는 데 쓴 기술의 묶음이에요. 가게에 비유하면 이해하기 쉬워요.
| 층 | 가게로 치면 | 하는 일 |
|---|---|---|
| 프론트엔드 | 손님이 보는 매장 | 눈에 보이는 화면, 버튼, 입력칸을 만들어요 |
| 백엔드 | 주방 | 주문을 받아 처리하고 계산한 뒤 저장을 시켜요 |
| 데이터베이스 | 장부 · 창고 | 회원, 주문, 글 같은 기록을 보관해요 |
| 서버 · 호스팅 | 가게 건물 | 화면, 주방, 장부가 돌아가는 컴퓨터를 빌려 써요 |
| 앱 프레임워크 | 배달 포장 | 같은 서비스를 아이폰 · 안드로이드 앱으로 내보내요 |
웹 서비스만 만들면 앞의 네 층만 써요. 스토어에 올리는 앱까지 내면 다섯 번째 층이 붙어요.
앱 개발 언어는 무엇이 있나요
층마다 자주 쓰는 기술이 달라요. 이름만 눈에 익혀 두면 미팅에서 덜 당황해요.
아래 표에서 프레임워크는 자주 쓰는 기능을 미리 짜 둔 '개발 틀'을 뜻해요.
| 층 | 자주 듣는 이름 | 대표님이 알 것 |
|---|---|---|
| 프론트엔드 | HTML · CSS · 자바스크립트, 리액트(React), 넥스트(Next.js), 뷰(Vue) | 웹 화면은 결국 자바스크립트로 만들어요. 리액트 · 뷰는 그걸 편하게 쓰는 도구예요 |
| 백엔드 | 루비온레일즈(Ruby), 장고(Python), 스프링(Java · Kotlin), 노드(Node.js), 라라벨(PHP) | 괄호 안의 언어 이름보다 앞의 개발 틀(프레임워크) 이름이 더 중요해요 |
| 데이터베이스 | PostgreSQL, MySQL, SQLite, 파이어베이스 · 수파베이스 | 앞의 셋은 표준 데이터베이스예요. 뒤의 둘은 서버 기능까지 묶어 빌려 쓰는 서비스형이에요 |
| 서버 · 호스팅 | AWS, 구글 클라우드, 디지털오션, 버셀 | 기술 이름보다 누구 명의 계정인지가 더 중요해요 |
| 앱 프레임워크 | 스위프트(아이폰), 코틀린(안드로이드), 플러터, 리액트 네이티브, 웹을 감싸는 하이브리드 | 아이폰 · 안드로이드 앱을 따로 두 벌 만들지, 한 벌로 같이 낼지가 갈려요 |
표에 있는 주류 기술이라면 웬만한 서비스는 무엇으로든 만들 수 있어요. 예약, 결제, 채팅, 관리자 화면은 어떤 조합으로도 구현돼요.
그래서 "어떤 기술이 제일 좋아요?"라는 질문에는 답이 잘 안 나와요. 대신 아래 질문들이 실제 차이를 만들어요.
플러터는 무엇인가요
플러터(Flutter)는 구글이 만든 앱 개발 도구예요. 다트(Dart)라는 언어로 한 번 만들면 아이폰과 안드로이드 앱이 같이 나와요.
비슷한 도구로 메타가 만든 리액트 네이티브가 있어요. 이 도구는 자바스크립트를 써요. 둘 다 앱을 한 벌로 내는 방식이에요.
창업자 입장에서 둘을 비교하는 기준은 플러터 vs 리액트 네이티브, 창업자가 볼 건 '개발팀이 떠난 뒤'예요에 따로 적었어요. 앱 개발 방식 전체 비교는 네이티브 · 하이브리드 · 크로스플랫폼 비교를 보세요.
기술 스택이 대표님에게 왜 중요한가요
기술은 만드는 순간보다 만든 뒤에 더 큰 영향을 줘요. 꼭 봐야 할 건 세 가지예요.
- 다음 개발자를 구할 수 있나요. 쓰는 사람이 적은 기술이면 사람 찾기가 어려워요. 반대로 많이 쓰는 기술이라도 코드가 엉망이면 이어받기 힘들어요.
- 매달 얼마가 나가나요. 같은 서비스도 구조에 따라 서버비가 몇십 배 차이 나요. 특히 빌려 쓰는 서비스형 데이터베이스는 사용량이 늘면 요금도 따라 올라요.
- 다른 곳으로 옮길 수 있나요. 특정 회사의 도구에서만 돌아가는 코드는 이사하기 어려워요. 그 회사 정책이 바뀔 때 서비스도 같이 흔들려요.
이 세 가지는 기술 이름 하나만으로 정해지지 않아요. 그래서 계약 전에 업체에 직접 물어봐야 해요.
업체에 물어볼 질문 5개
계약 전에 아래 다섯 가지를 물어보세요. 답을 들으면 그 업체가 인수인계를 어떻게 생각하는지 바로 보여요.
| 질문 | 좋은 답 | 다시 물어볼 답 |
|---|---|---|
| 1. 다른 개발자가 이 코드를 이어받을 수 있나요? | 표준 구조로 만들고, 설명 문서와 자동 테스트를 같이 드려요 | 저희가 계속 맡으면 되니까 괜찮아요 |
| 2. 내 계정으로 배포되나요? | 서버 · 도메인 · 스토어 개발자 계정을 대표님 명의로 만들어요 | 저희 서버에 올려 드릴게요 |
| 3. 코드 저장소는 누구 소유인가요? | 대표님 계정으로 소유권을 넘겨요 | 저장소에 초대해 드릴게요 |
| 4. 출시 뒤 매달 얼마가 나가나요? | 서버 · 외부 서비스 · 데이터베이스 비용을 항목별로 적어 줘요 | 쓰는 만큼 나와요 |
| 5. 이 기술을 고른 이유는 뭔가요? 다른 곳으로 옮기려면요? | 이 서비스에 맞는 이유와, 옮길 때 걸리는 점을 말해 줘요 | 요즘 다 이걸로 해요 |
1번(이어받기)이 가장 중요해요. 나중에 업체가 바뀌거나 개발자를 직접 뽑을 때, 또는 AI로 직접 고칠 때 이 준비가 안 되어 있으면 발목을 잡혀요.
2번과 3번(명의)은 소유권 문제예요. 여기서 배포는 서비스를 서버와 스토어에 올려 실제로 켜는 일이고, 코드 저장소는 원본 코드를 보관하는 곳이에요.
업체 명의로 만든 서버와 저장소는 관계가 틀어지면 돌려받기 어려워요. 저장소를 제대로 넘겨받는 방법은 외주 끝나고 코드 받을 때, 초대가 아니라 소유권 이전에 적었어요.
4번(월 운영비)은 개발 견적서에 잘 안 나오는 돈이에요. 외주 개발 견적서 읽는 법의 숨은 비용 일곱 가지와 같이 확인해 보세요.
5번(기술 선택 이유)은 정해진 정답이 없어요. 왜 그 기술을 골랐는지 설명할 수 있는지가 중요해요. "저희 팀이 이 기술을 가장 잘 다뤄서요"도 좋은 답이에요.
유행하는 기술을 골라야 하나요
꼭 그렇지 않아요. 유행하는 기술은 그저 개발자가 새로 배우고 싶은 기술인 경우가 많아요.
대표님에게 필요한 건 3년 뒤에도 고칠 수 있는 코드예요. 최신 기술로 만들어도 설명 문서와 테스트가 없으면 남이 이어받기 어려워요. 반대로 오래된 기술이라도 구조가 표준이고 문서가 있으면 금방 이어받아요.
기술 이름보다 먼저 챙길 것을 순서대로 적으면 이래요.
- 코드와 계정이 대표님 명의인가요.
- 배포 · 복구 방법이 문서로 저장소 안에 정리되어 있나요.
- 고친 뒤 다른 곳이 고장 나지 않았는지 스스로 검사하는 자동 테스트가 있나요.
- 그다음이 기술 이름이에요.
AI로 코드를 고치는 시대라 4번의 무게는 더 줄었어요. 대신 1~3번이 훨씬 중요해졌어요. AI도 문서와 테스트가 있는 코드를 훨씬 잘 고치거든요.
헤이제임스는 무엇으로 만드나요
(주)헤이제임스는 루비온레일즈를 써요. 필요한 기능이 거의 다 들어 있고, 구조가 일정해 AI가 덜 헤매기 때문이에요. 자세한 이유는 왜 루비온레일즈인가에 적었어요.
서버는 여러 대로 복잡하게 나누지 않고 레일즈 8 단일 서버로 올려요. 지금 보시는 이 사이트 같은 구성이 월 21달러 안팎이에요.
장점만 있는 건 아니에요. 국내에 레일즈 개발자가 자바스크립트 개발자보다 적은 건 사실이에요. 이 부분은 레일즈로 만들면 나중에 개발자 구할 수 있나요?에 솔직하게 적었어요.
그래서 인수인계와 운영 문제를 이렇게 풀어요.
- 소스코드 · 저작권 · 서버 · 도메인 계정은 모두 대표님 명의로 넘겨요.
- 저장소 안에 설명 파일을 남겨서, 사람도 AI도 서버 주소와 배포 방법을 바로 알 수 있어요.
- 직접 이어가기 어려우면 연 단위 유지보수 계약으로 몇 년씩 맡길 수 있어요.
물론 레일즈가 맞지 않는 경우도 있어요. 실시간 그래픽이 쉬지 않고 움직이는 화면이 중심인 서비스가 그래요. 이미 다른 기술을 잘 다루는 팀이 있을 때도 그 기술로 가는 게 나아요.
정리하면
- 기술 스택은 화면 · 처리 · 기록 · 건물 · 앱 포장 다섯 층이에요. 주류 기술이면 웬만한 서비스는 다 만들어요.
- 기술 이름보다 다음 개발자, 매달 나가는 돈, 옮길 수 있는지가 대표님에게 중요해요.
- 계약 전에 이어받기 · 배포 명의 · 저장소 소유 · 월 운영비 · 고른 이유 다섯 가지를 물어요.
- 유행보다 문서 · 테스트 · 명의가 있는 코드가 오래 가요.
만들 서비스의 화면 수와 견적을 먼저 보고 싶으면 셀프 견적에 설명을 넣어 보세요. AI가 화면 프로토타입을 그리고 견적서까지 내려받을 수 있어요.
자주 묻는 질문
앱 개발 언어는 무엇을 배워야 하나요?
맡기는 대표님이라면 직접 배울 필요는 없어요. 대신 화면 · 서버 · 데이터베이스 · 호스팅 · 앱 프레임워크가 어떻게 나뉘는지만 알아 두세요. 그 정도면 업체 설명을 따라가고 필요한 질문을 할 수 있어요.
플러터로 만들면 나중에 문제가 되나요?
플러터 자체가 문제는 아니에요. 다만 다트를 다루는 개발자를 따로 구해야 하고, 웹 화면은 별도로 만들게 되는 경우가 많아요. 만든 팀이 떠난 뒤 누가 이어받을지를 먼저 생각해 보세요.
업체가 제안한 기술이 맞는지 어떻게 확인하나요?
그 기술을 고른 이유와, 다른 곳으로 옮길 때 무엇이 걸리는지 물어보세요. 이유를 서비스에 맞춰 설명하면 믿을 만해요. 계정 명의와 문서, 테스트를 같이 확인하면 기술이 무엇이든 위험이 줄어요.
쓴 사람 — 제임스
연세대 컴퓨터과학을 전공한 23년차 개발자예요. 개발 에이전시를 8년간 운영하며 스타트업 플랫폼 350개를 만들었고, 연매출 100억 원 커머스 기업의 CTO를 지냈어요. 정부지원사업을 받아도 봤고 심사위원도 해 봤어요. 최근 2년은 AI로 개발을 효율화하는 데 집중하고 있어요.