안녕하세요! 그로스로그 입니다!😊 🌱
경진대회에 나가려고 앱 개발 방식 네 가지를 비교한 기록, 그리고 이름이 비슷해 헷갈리는 자료구조들을 갈라본 기록. 3기 7회차 두 번째입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
앞선 큐레이션에서 UI 라이브러리와 CI/CD를 다뤘는데요, 이번 두 편은 고르기 위해 비교한 글입니다. 그리고 둘 다 표로 정리하고 결론까지 냅니다.
01
📱 모바일 앱 개발 방식의 종류와 특징
박지수B 님
교내 소프트웨어 경진대회에 나가려는데 앱 개발 경험이 없습니다. 그래서 방식부터 조사했어요.
네이티브 앱 · 모바일 웹 · 웹 앱 · 하이브리드 앱 네 가지를 각각 설명하고, 배포 방식·설치 여부·사용 기술·UI/UX·하드웨어 접근·성능·개발 비용·대표 예시를 한 표에 모았습니다.
그리고 자기 상황에 맞는 답을 냅니다. "시간이 부족하니 웹 앱으로 MVP를 만들고, 필요하면 하이브리드로 확장하자."
1·2·3회차에 JVM·GC·도커를 정리하셨던 그분입니다. 이번엔 만들기 전에 방식을 정하는 단계예요.
조금 더 들어가 보면
네 가지를 가르는 축이 사실 두 개입니다.
① 어떤 기술로 만드는가 — 각 OS 전용 언어냐, 웹 기술(HTML/CSS/JS)이냐
② 어떻게 사용자에게 닿는가 — 앱스토어에 올려 설치하냐, URL로 접속하냐
이 두 축을 조합하면 네 칸이 나옵니다.
| URL 접속 | 앱스토어 설치 | |
|---|---|---|
| 웹 기술 | 모바일 웹 / 웹 앱 | 하이브리드 앱 |
| 전용 언어 | — | 네이티브 앱 |
하이브리드 앱이 재미있는 자리에 있습니다. 글의 표현이 정확해요. "외형은 앱이지만 내부는 웹이다."
이게 가능한 건 WebView 덕분입니다. 네이티브 앱 안에 브라우저 화면을 하나 띄워놓고 웹 페이지를 보여주는 거예요. 사용자는 앱을 켰다고 생각하지만 실제로는 웹을 보고 있습니다.
"카카오T 초기 버전"을 예로 든 게 좋았어요. 실제로 많은 서비스가 이렇게 시작합니다. 빠르게 내놓고, 반응이 좋으면 화면부터 하나씩 네이티브로 바꿔가는 경로죠.
🧭 모바일 웹과 웹 앱의 차이
글이 따로 상자를 빼서 설명한 부분입니다. 둘 다 웹 기술인데 뭐가 다를까요.
✅ 모바일 웹 : '모바일 화면에 맞게' 풀 브라우저 방식(Full Browsing)
SPA(Single Page Application)는 처음에 페이지를 통째로 받아두고, 이후에는 바뀌는 부분만 갈아끼웁니다. 화면이 깜빡이지 않아 앱처럼 느껴져요.
풀 브라우징은 화면이 바뀔 때마다 서버에서 페이지 전체를 새로 받습니다. 글이 짚은 단점이 실무적이에요.
이동 중이라는 조건이 중요합니다. 지하철에서 터널을 지날 때, 엘리베이터를 탈 때 연결이 끊기죠. 그때 페이지 전체를 다시 받아야 하는 구조면 화면이 통째로 날아갑니다. 반면 SPA는 이미 받아둔 게 있으니 버팁니다.
이게 3기 1회차의 SSR 이야기와도 이어집니다. SPA는 앱 같은 경험을 주지만 SEO가 약하고, 서버 렌더링은 반대죠. 각 방식마다 얻는 것과 잃는 것이 있습니다.
🧭 그리고 결론까지 낸 것
이 글이 좋은 이유는 비교로 끝나지 않았다는 점입니다.
세 가지가 들어 있습니다.
제약을 인정했습니다. "시간이 부족하다"요. 경진대회에는 마감이 있고, 앱 개발 경험이 없는 상태니까요.
지금 목표를 정했습니다. MVP요. 완성품이 아니라 동작하는 최소한을 먼저 만드는 겁니다.
다음 경로를 열어뒀습니다. "필요에 따라 하이브리드로 확장"이요. 지금 선택이 막다른 길이 아니라는 걸 확인한 거죠.
되돌릴 수 있는 선택인지 확인하는 것 — 기술 선택에서 가장 중요한 부분입니다. 웹 앱으로 만들어두면 나중에 WebView로 감싸는 건 어렵지 않아요. 반대로 네이티브로 시작했다가 시간이 부족해지면 되돌릴 방법이 없습니다.
큐레이터 노트
모르는 걸 인정하고 조사부터 한 기록이라 뽑았습니다.
첫 문장이 "나는 모바일 앱 개발 경험이 없어서 사전 조사를 해보았다"입니다. 경험이 없는 상태에서 바로 코드를 쓰지 않고 선택지부터 파악한 순서예요.
이게 왜 중요한가 하면, 처음 고른 방식을 나중에 바꾸기가 가장 어렵기 때문입니다. 프레임워크는 바꿀 수 있고 라이브러리도 갈아탈 수 있지만, "네이티브로 갈까 웹으로 갈까"는 프로젝트 전체를 다시 짜야 하는 결정이거든요.
표로 정리한 형태도 실용적입니다. 여덟 개 항목을 네 방식에 걸쳐 채워뒀어요. 같은 고민을 하는 사람이 그대로 펼쳐놓고 볼 수 있습니다.
이 저자는 3기 내내 자기가 지금 필요한 것을 정리하는 방식으로 기록하고 계세요. JVM을 공부할 땐 JVM을, 스터디를 할 땐 도커를, 대회를 준비할 땐 앱 개발 방식을요. 공부와 기록이 붙어 있습니다.
02
📚 헷갈리는 배열 정리해보기
황유정 님
자바를 공부하다 만나는
List, ArrayList, LinkedList를 갈라 정리한 글입니다.그리고
ArrayList<String>과 String[]의 차이도 이어서 다뤄요. 크기 유연성, 사용 가능한 메서드, 제네릭 지원까지요.각 절 끝마다 "언제 뭘 써야 할까" 표가 붙습니다. 개념 정리가 곧 선택 기준이 되는 구조예요.
이름이 비슷해서 헷갈리는 것들을 하나씩 세워 비교한 글입니다.
조금 더 들어가 보면
글이 가장 먼저 잡는 게 List의 정체입니다.
List는 클래스가 아니라 인터페이스다. 쉽게 말하면, 어떤 기능을 제공할지 약속만 해놓은 틀 같은 거다."여기가 시작점입니다. List는 "순서대로 담고, 인덱스로 꺼내고, 추가·삭제할 수 있다"는 약속만 합니다. 어떻게 담을지는 안 정해요.
그 "어떻게"를 정하는 게 ArrayList와 LinkedList입니다. 같은 약속을 다른 방식으로 지키는 거죠.
📦 배열 기반 vs 노드 기반
· ArrayList — 내부적으로 배열을 씁니다. 인덱스 접근이 빠르고, 중간 삽입·삭제가 느립니다
· LinkedList — 노드들이 서로 연결된 구조(이중 연결 리스트)입니다. 중간 삽입·삭제가 빠르고, 인덱스 접근이 느립니다
왜 이렇게 갈릴까요. 저장 방식이 성능을 정하기 때문입니다.
배열은 한 줄로 붙어 있습니다. 그래서 get(500)을 부르면 시작 주소에 500칸을 더해 바로 갑니다. 계산 한 번이면 끝이에요.
대신 중간에 끼워 넣으려면 뒤를 전부 밀어야 합니다. 1000개짜리 리스트의 앞에 하나 넣으면 999개를 옮겨야 해요.
연결 리스트는 반대입니다. 각 노드가 다음 노드의 위치만 들고 있어요. 중간에 끼워 넣는 건 양옆의 연결만 고쳐 잡으면 끝입니다.
대신 get(500)을 하려면 처음부터 500번을 따라가야 합니다. 지름길이 없어요.
한 줄로 붙어 있으니 찾기 쉽고 끼우기 어렵다 / 흩어져 있으니 찾기 어렵고 끼우기 쉽다 — 이 대비가 전부입니다.
🧭 그런데 실무에서는 대개 ArrayList
글의 결론이 실전과 정확히 맞습니다.
ArrayList를 사용하는 게 더 효율적이다."이론상으로는 삽입·삭제가 많으면 LinkedList가 유리해 보이는데, 실제로는 그렇지 않은 경우가 많습니다. 이유가 있어요.
중간에 넣으려면 그 자리를 먼저 찾아야 하거든요. 노드 연결을 바꾸는 건 빠르지만, 500번째 자리로 가는 데 이미 오래 걸립니다. 결국 전체 시간은 비슷해지죠.
게다가 배열은 메모리에 붙어 있어서 CPU 캐시에 잘 올라갑니다. 순회할 때 실제 속도 차이가 꽤 나요.
LinkedList가 확실히 유리한 자리는 글이 짚은 그곳입니다. 큐(Queue)처럼 앞뒤로 넣고 빼는 경우요.
Queue<String> queue = new LinkedList<>();
queue.offer("apple");
queue.poll(); // 가장 앞의 요소 제거
맨 앞과 맨 뒤는 찾을 필요가 없으니까요. 연결 리스트가 양 끝을 항상 기억하고 있어서 바로 접근됩니다.
그리고 이 조언이 가장 실용적입니다.
List로 선언해두고, 상황에 따라 구현체만 바꾸는 방식이 가장 유연하다."List<String> items = new ArrayList<>(); // 나중에 LinkedList로 바꿔도 나머지 코드는 그대로
변수 타입은 약속(List)으로, 실제 물건은 구현체로 — 4회차의 클린 아키텍처에서 나온 "인터페이스에 의존하라"와 정확히 같은 이야기입니다. 자료구조 하나를 고르는 데도 그 원칙이 쓰이는 거죠.
🧭 배열과 ArrayList
후반부의 비교도 실용적입니다.
String[] arr = new String[3]; arr[0] = "A"; arr[1] = "B"; arr[2] = "C"; // arr[3] = "D"; // 에러 발생
ArrayList<String> list = new ArrayList<>();
list.add("A"); list.add("B"); list.add("C");
list.add("D"); // 문제 없음
크기가 고정이냐 아니냐가 가장 큰 차이입니다. 그런데 여기서 재미있는 점이 있어요. ArrayList도 내부적으로는 배열을 씁니다. 다만 꽉 차면 더 큰 배열을 새로 만들어 옮겨 담아요.
그래서 글의 "상대적으로 느릴 수 있음"이 정확합니다. 그 옮겨 담는 비용이 가끔 들거든요. 대신 우리가 신경 쓰지 않아도 되죠.
큐레이터 노트
"헷갈린다"를 그대로 제목으로 쓴 글이라 뽑았습니다.
List와 ArrayList와 LinkedList. 자바를 배우는 사람이라면 다들 한 번씩 헷갈리는 지점이에요. 그걸 덮어두지 않고 세워서 비교한 기록입니다.
각 절 끝의 "언제 뭘 써야 할까" 표가 이 글을 쓸모 있게 만듭니다. 개념만 있으면 나중에 상황이 닥쳤을 때 다시 헤매는데, 선택 기준까지 정리해두면 바로 꺼내 쓸 수 있어요.
그리고 List로 선언하고 구현체를 바꾸라는 결론이 좋았습니다. 이건 문법 지식이 아니라 설계 습관이거든요. 자료구조를 배우면서 거기까지 갔다는 게 눈에 띄었습니다.
블로그 카테고리 이름이 "차곡차곡"이더라고요. 이름 그대로 쌓아가고 계신 기록입니다.
💡 두 편을 겹쳐 읽으며
한 편은 앱 개발 방식, 한 편은 자바 자료구조입니다. 규모가 완전히 다릅니다. 하나는 프로젝트 전체의 방향이고, 하나는 코드 한 줄의 선택이죠.
그런데 두 글의 구조가 똑같습니다.
선택지를 나열하고 → 각각의 특성을 비교하고 → 표로 정리하고 → 내 상황에 맞는 답을 낸다.
박지수B 님은 "시간이 부족하니 웹 앱"으로, 황유정 님은 "대부분의 경우 ArrayList"로 결론을 냅니다. 둘 다 조건이 붙어 있어요.
그리고 둘 다 나중에 바꿀 여지를 남겼습니다. 웹 앱은 하이브리드로 확장할 수 있고, List로 선언해두면 구현체를 갈아끼울 수 있죠.
되돌릴 수 있는 선택과 없는 선택을 구분하는 것 — 이게 좋은 결정의 핵심입니다. 되돌릴 수 있으면 빨리 정하고 가면 되고, 되돌리기 어려우면 시간을 더 써서 알아봐야 해요.
두 글 모두 "지금 정하되, 나중에 바꿀 수 있게"를 택했습니다. 규모는 달라도 판단하는 방식은 같았어요.
이번 회차에서 가져갈 것
1. 되돌릴 수 있는 선택인지 먼저 보기. 웹 앱 → 하이브리드는 쉽고, 네이티브 → 웹은 어렵습니다. 한 방향으로만 갈 수 있는 선택은 더 신중하게 고르세요.
2. 모바일에서는 "이동 중"을 가정하기. 지하철, 엘리베이터, 터널. 연결이 끊기는 게 예외가 아니라 일상입니다. 화면 전체를 매번 새로 받는 구조는 그때 무너져요.
3. 자료구조는 저장 방식으로 이해하기. 배열은 붙어 있어 찾기 쉽고 끼우기 어렵고, 연결 리스트는 흩어져 있어 반대입니다. 왜 그런지를 알면 새 자료구조도 예측할 수 있어요.
4. 변수는 인터페이스로 선언하기. List<String> items = new ArrayList<>(); 구현체를 바꿔도 나머지 코드가 안 흔들립니다. 자료구조에도 "인터페이스에 의존하라"가 적용돼요.
5. 비교했으면 결론까지 내기. 표만 만들고 끝내면 다음에 또 비교하게 됩니다. "내 상황에서는 이것"까지 적어두세요. 조건과 함께요.
좋은 글 남겨주신 박지수B 님, 황유정 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.