최소 4번의 클릭(생성-이미지선택-다음-만들기)만으로 만드는 움짤! 누구보다 빠르게 찌고 누구보다 빠르게 공유합시다.
걍 좀 움직이면 되는데 프레임 하나하나 손 많이 가는 움짤! 이제 일괄보정으로 한방에 쉽게 만들어봅시다.
움짤 보정의 기본은 밝기/대비/감마! 필터도 물론 지원합니다.
만들었으면 공유도 해야죠. 움짤 전용 저장소에서 공유할 수도 있고, 다른 앱으로도 마음껏 공유하세요.
저장한 이미지들을 이어붙여서 만드는 움짤은 기본 중의 기본이죠. 여러장 찍은 사진들을 이미지 하나로 만들어보세요.
기존에 만든 움짤을 수정하거나 프레임을 추가하고 싶다고요? 당연히 가능합니다. 직접 만든 움짤은 물론, 다른 사람이 만든 움짤도 수정할 수 있습니다.
그동안 심혈을 기울여 프레임 하나하나 장인정신으로 찍어서 움짤 만들던 당신, 이제 편하게 만드세요.
내가 제작한 움짤에 왜 앱 낙인박혀 있나요? ㄴㄴ '모두의 움짤'은 낙인 같은거 박지 않아요. 낙인 디자인하기도 힘들거든요.
움짤로 당신의 유머, 아이디어, 덕심을 표현해 보세요
움짤은 능력자만 만드는게 아니에요. 지금 당장 만들어보세요.
필터에서 벗어난 밝기/대비/감마 보정! 내 마음대로 변경해보세요.
만들었으면 공유도 해야죠. 낙인 같은거 박지 않아요. 마음껏 공유하세요.
더 많은 움짤러들과 나의 움짤을 공유하고, 다른 움짤러들의 움짤도 확인해보세요.
내가 만든 움짤들은 폰의 폴더 하나에 모아져 있어요. 쌓일수록 뿌듯하죠!
움짤을 만들어봅시다. 우선, 첫화면 오른쪽 아래 '+' 버튼을 눌러 움짤 생성 화면으로 이동하세요. 그럼 저장된 이미지들이 뜰껀데, 하나하나 선택해서 움짤을 만들어보세요. 옆으로 밀어서 움짤을 불러올 수도 있어요. 그 옆에 '...'은 뭐냐구요? 폰에 설치된 갤러리 앱으로 이미지나 움짤을 가져오거나, 비디오에서 움짤을 만들 수 있는 버튼이에요. 프레임을 다 추가했으면 오른쪽 위 '->' 화살표를 누르세요. ( 최대 프레임은 10개 입니다. 길면 공유하기 힘들잖아요. 움짤은 짧아야 제맛! )
저장한 이미지들을 이어붙여서 만드는 움짤은 기본 중의 기본이죠. 여러장 찍은 사진들을 이미지 하나로 만들어보세요.
기존에 만든 움짤을 수정하거나 프레임을 추가하고 싶다고요? 당연히 가능합니다. 직접 만든 움짤은 물론, 다른 사람이 만든 움짤도 수정할 수 있습니다.
그동안 심혈을 기울여 프레임 하나하나 장인정신으로 찍어서 움짤 만들던 당신, 이제 편하게 만드세요.
움짤을 보정한다 함은, 일괄 보정이죠! 더이상 프레임마다 똑같은 보정작업을 반복하지 마세요. 한방에 해결합시다!
이미지의 흰색 양을 변경합니다.밝기를 오른쪽으로 증가시키면 이미지 내의 흰색이 차지하는 비중이 커져 이미지가 밝게 보입니다.
이미지의 밝은 부분과 어두운 부분 사이의 차이를 변경합니다. 대비를 오른쪽으로 증가시키면 밝은 부분이 더 밝아지고 어두운 부분이 더 어두워집니다. 밝은 영역과 어두운 영역 사이의 가장자리가 뚜렷해집니다.
화면 이미지의 톤을 조정합니다. 사람 눈 특성과 컴퓨터의 색 표현 방식의 차이로 인한 손상을 특정 지수함수를 이용해 이미지를 보정합니다.
앱에 개발자가 넣어둔 필터를 적용합니다. StarLit, BlueMess, AweStruckVibe, LimeStutter, NightWhisper가 들어 있으며, 자체 필터 E-plus, E-minor도 추가되었습니다.
뭔가 재밌는걸 만들었는데 공유할 곳이 없어서 슬픈 아싸(?)님들을 위해, 그리고 내 움짤의 영향력을 확인하기 위해! 자체 저장소를 탑재했습니다.
유머/힐링/인물 카테고리가 있으니 카테고리 별로 올려보세요! 이미지와 함께 15자 이내의 움짤 이름을 같이 올릴 수 있는데, 무슨 의미인지 알죠? 잘 지은 제목가 백마디 말보다 낫습니다!
Android NDK GIF(움짤 생성), AndroidPhotoFilters(이미지 보정)
MediaMetadataRetriever(영상 데이터 추출)
Glide(이미지 로딩) , Firebase(자체 이미지 공유 서버)
EventBus(컴포넌트간 데이터 전송), ButterKnife(개발 편의 및 간결함) 등
* 사용 기술 :
- AnimatedGifEncoder (움짤 생성-초고화질)
- Android NDK GIF (움짤 생성-저/중/고화질)
- Spinner/AlertDialog(Custom) (움짤 이름 및 화질 입력)
* 주요 이슈 :
- GIF 파일 생성 속도
- GIF 파일 생성시 이미지 깨짐 현상 해결
- 파일 생성시 이름 중복 해결 등
우선, 움짤(.gif 파일)을 생성하기 위해 맨 처음 Glide에 포함된 AnimatedGifEncoder와 이 것에 필요한 소스들 가져와 구현하였으나, 인코딩 속도가 너무 느렸고, 이 것을 개선하기 위해서는 다른 소스를 찾거나 직접 NDK를 이용해 구현해야 했다.
검색 및 관련 앱들에서 찾으려했으나, 분명 오픈소스 라이브러리를 쓴 것 같은, 그 사용 방식이나 결과물이 비슷한 앱들에서 사용 라이브러리 및 라이선스를 명시하지 않아 찾는데 어려움을 겪었다.
그러던 중 튜터님이 보여주신 관련 앱에서 Android NDK GIF 찾고, 이 것을 이용해서 적용 및 테스트를 해 본 결과, 빠른 속도로 gif파일을 생성할 수 있었지만 설정을 다양하게 변경하더라도 기존 방법보다 화질이 상대적으로 떨어지는 결과물이 나왔다.
그래서 각각의 장단점을 가진 두 방식 모두 이용하며, Spinner를 이용해서 사용자에게 화질 선택권 넘기도록 하였다.
또한 Android NDK GIF의 경우, gif 이미지를 구성하는 프레임들 중 크기가 1px이라도 차이가 나는 경우 결과물의 이미지 형태가 완전히 깨지는 현상이 발생했다. 그래서 프레임의 크기를 통일할 필요가 생겼는데, 여백을 주어 통일을 시킬지, 프레임을 resizing하여 통일 시킬지 선택을 해야 했다.
이 때, 여백으로 통일할 시 이미지간 미세한 차이로 사이즈가 다른 경우 여백이 테두리처럼 보여 움짤의 품질이 떨어져보이는 문제가 생겨, 여백을 없애고 resizing하는 방법으로 결정하고, 프레임을 추가할 때 프레임 리스트 내의 기존 프레임들의 크기로 Resize하여 추가되도록 했다.
* 사용 기술 :
- FFmpegMediaMetadataRetriever (Frame 추출)
- BetterVideoPlayer (비디오 재생 및 편리한 위치 이동)
* 주요 이슈 :
- 캡처 희망 부분 탐색
- 프레임을 추출하지 못하는 경우의 처리
- 연속적 프레임 추출 시 동일 프레임 추출 현상 해결
- 큰 이미지를 불러올 시 리사이즈 및 Bitmap 관리(recycle) 등
동영상 캡처 시 사용자에게서 입력이 필요한 값은 3가지로, '캡처를 시작하는 위치', '캡처하는 프레임 수', '캡처 프레임간 딜레이'로 파악했다.
원하는 부분의 캡처를 보다 손쉽게 하기 위해 앱 내에서 동영상을 재생하도록 했으며, 동영상을 재생하는 화면 하단에 SeekBar를 이용하여 캡처할 프레임 수와 딜레이를 조절할 수 있도록 했다. 그래서 사용자가 앱 내 동영상 플레이어에서 보고있는 위치부터 지정한 프레임 딜레이마다 지정한 수만큼 캡처할 수 있도록 했다.
그러나, 캡처에 Android의 MediaMetadataRetriever를 이용했을 때 프레임 딜레이가 1s보다 짧은 경우 같은 프레임들을 여러번 불러오는 경우가 잦은 문제가 생겼다.
MediaMetadataRetriever의 설명에 원하는 us의 근처 프레임을 가져온다고 하여 한계점으로 파악하고, 우선 OPTION_NEXT_SYNC를 이용하고 비디오소스를 Uri에서 file path로 변경하여 횟수 조금 줄여 보았다.
이후 FFmpegMediaMetadataRetriever를 이용하여 이 문제를 해결 했으나, FFmpegMediaMetadataRetriever는 원하는 us근처에 알맞은 프레임이 없는 경우 Null을 반환하는 경우가 발생하여 이 경우의 처리도 필요했다.
* 사용 기술 :
- DragSortAdapter (프레임 위치 변경)
* 주요 이슈 :
- 편리한 프레임 순서 변경
- View 위치 변경으로 인한 접근 데이터 변경 해결
사용자가 임의로 프레임들 일부 순서 변경 및 삭제가 가능하도록 한다.
이때 순서 변경 방법으로 drag를 사용했을 때 RecyclerView의 스크롤과 겹쳐서 사용자가 원치않는 동작할 가능성이 생겨 long click을 했을 때 프레임 순서 변경이 가능하도록 했다.
AdvancedRecyclerView로 구현했을 때 드래그 동작에 어려움이 있어 DragSortAdapter로 변경하고 LayoutManager로 여러 프레임들을 보기 좋은 Gird를 사용하다 드래그의 불편함과 공간을 많이 차지한다는 단점으로 인해 Linear를 변경했다.
또, swap으로 인해 뷰를 클릭했을 때 다른 데이터가 호출되는 문제가 발생하여 position 대신 id 값을 이용해 데이터에 접근하도록 했다.
* 사용 기술 :
- Glide (이미지 로딩)
- AVLoadingIndicatorView (이미지 로딩 시 보여줄 뷰)
- EventBus (프레임 추가 화면에서 선택된 파일 정보 전달)
- SQLite (숨긴파일 제외한 단말 내 이미지 불러오기)
- Android Storage (지정된 폴더 내 모든 파일 접근)
* 주요 이슈 :
- 갤러리 이미지 배치(UI)
- EventBus를 이용한 파일 정보 전달로 프레임 추가(jpg/png/gif)
- . 혹은 .nomedia로 숨긴 파일에 대한 처리
- 여러 이미지를 동시에 불러올 때 placeholder를 대신할 좋은 로딩 화면 등
앱에서 단말 내부 이미지들을 가져오기 위해 처음 Intent를 이용하여 구현했으나, UI적으로도 좋지 않고, 사용자가 원하는 이미지를 선택하기 위한 화면으로 가기 위해 많은 선택량이 필요한 단점을 극복하기 위해 자체 Gallery를 구현했다.
Gallery는 여러 Activity에서 사용할 목적으로 만들어 졌으며, 프레임 추가 화면에서는 원활히 프레임을 추가하기 위해 EventBus를 통해 File 정보를 송신하도록 구현하였다.
이 Gallery는 첫 화면에서 앱 자체 폴더 내의 움짤(사용자가 생성한 움짤)들을 보여주며, 첫 화면에서 이미지를 선택할 시 전체 화면으로 이미지를 보여주는 동작을 하며, 프레임 추가 화면에서 이미지를 선택할 시 선택한 이미지를 프레임으로 추가하는 동작을 수행한다.
* 사용 기술 :
- Glide (이미지 로딩)
- AndroidPhotoFilters (이미지 보정)
- EventBus (보정량을 정하는 Fragment로 부터 보정 정보 전달)
- Discrete SeekBar (보정량 조절)
* 주요 이슈 :
- 보정으로 인한 Bitmap 관리
- 보정 단위 변형
- 보정 화면 UI/UX 구성
OpenCV를 이용할 예정이었으나, 공부하던 중 NDK를 이용하는 좋은 라이브러리(Android Photo Filter)를 찾아 사용해 보기로 결정했다. 밝기/대비/감마 보정을 가장 필요로 했는데, 이 부분이 잘 되어 있어 이 라이브러리를 적용해 보고, 만족할만한 성능을 보여 사용하기로 결정하였다.
다만, 감마 보정시 y축 값이 그래프를 넘어서는 curve를 그리면 앱이 강제 종료되는 현상이 있어, 값의 범위를 1차 축소 하였으며, 실제 사용시 세부 보정의 어려움으로 인해 한번에 보정하는 범위를 한 번 더 축소하고, 중첩보정이 가능하도록 변경하였다.
앱 내에서 사용하는 보정량은 밝기는 -100~100(기본값:0), 대비는 0.0f~2.0f(기본값 1.0f), 감마는 (0,0)~(255,255)(기본값 (128,128))이나, 이런 다양한 수치 변경은 사용자가 불편해할 가능성이 커 -30~30의 범위로 축소 및 단위 변경하여 UI에 보이도록 하였다.
* 사용 기술 :
- Handler (반복 주기마다 다음 프레임 재생)
* 주요 이슈 :
- 보정으로 인한 Bitmap 처리 후 recycle()시 view가 나타내고 있는 이미지에 대한 처리
- 보정 도중 이미지 접근 처리
- Handler의 반복 주기 변경 및 정지
- 재시작 타이밍 등
움짤이 생성 되었을 때 예상되는 모습을 보정 화면에서 그대로 보여주도록 한다. 이 미리보기와 생성 결과의 움짤은 눈으로 확인했을 때 충분히 동일해야 한다.
이런 미리보기 화면을 구현하기 위해, 지정한 프레임 딜레이마다 메모리에 존재하는 다음 프레임(Bitmap)을 가져와서 읽을 필요가 있다.
일정 주기로 반복되는 작업이므로 처음에 Timer를 이용하여 구현했으나, 프레임 딜레이(반복 주기)를 변경하는 작업이 빠르게 여러번 일어나야 할 필요가 있는데, 이런 작업에 Timer가 효율적이지 않으므로 Handler로 작업 교체하고 delay마다 Handler를 반복 호출하도록 하였다.
단, onPause()시 removeCallbacks()하여 예정된 작업을 중지하였으며, onResume()에서는 postDelayed()하여 다시 반복작업을 수행하도록 하였다.
* 사용 기술 :
- AndroidPhotoFilters (이미지 보정)
* 주요 이슈 :
- History 동작 방식,
- History 저장 시작 지점 및 종료 지점
- 보정 전 후 Bitmap 관리
- 뷰 이미지 변경과 참조 해제 시점( Looper 문제 )
보정 작업은 그 과정 중 언제든지 이전 상황으로 돌아가 다시 보정할 필요가 있다.
우선 최대, 최소 화소 값이나 감마 변경의 경우 보정 후 Bitmap을 이용하여 보정 전의 Bitmap으로 돌아가는 것이 힘듬을 확인하였다. 그래서 보정 전 Bitmap과 보정 후 Bitmap을 구분하여 따로 관리하도록 하였으며, 사용자가 보정 중에는 보정 후 Bitmap을 확인하도록 getItem()을 변경하였다.
이후 사용자가 해당 보정 작업을 적용(apply)하는가 취소(reset)하는가에 따라 보정 전 Bitmap과 보정 후 Bitmap을 Swap하고 recycle하였다.
그러나 빠르게 연달아 일괄 보정하는 본 앱의 특성상 기존에 화면에 표시하던 이미지가 보정된 이미지로 미처 전환되기도 전에 기존 이미지의 참조를 너무 빨리 해제해서 Looper에서 뷰를 다시 그릴 때 문제가 발생하는 경우가 있었다. 이 부분은 보정 처리를 한 후 notify를 통해 프레임 리스트에 반영하고 미리보기 화면에도 반영하여 사용자의 화면에서 보정 이전 Bitmap에 해당하는 이미지가 없도록 모두 전환처리 한 이후 recycle()을 시도하도록 변경하였다.
특히 이 문제는 로그에 Looper에서 발생한 문제라고는 나왔는데, 정확히 어느 부분에서 발생한 것인지 파악도 힘들었고, 같은 상황으로 테스트해도 언제는 발생하고 언제는 발생하지 않는 문제라 찾기가 힘들었다. 그래서 문제가 발생한 그 화면에서 출력하는 모든 뷰들이 현재 뭘 보여주고 있고, 어떤 작업이 예약되어 있고, 백그라운드에서는 어떤 작업들이 일어나고 있는지 모두를 그려가면서 문제를 찾아냈다.
이후 튜터님이 직전 단계 취소만이 아닌 여러 단계의 보정 취소도 가능하도록 하는 것이 좋겠다는 의견을 주셔서 해당 기능의 구현 방법을 고민하던 중,
각 단계의 Bitmap을 임시파일로 저장하는 방법과, 원본 Bitmap을 기억하고 보정 정보만을 기억한 뒤 보정 취소 시 원본부터 직전 단계까지의 보정 작업을 일괄 처리하여 이전 단계로 돌아갈 수 있는 방법을 생각했다.
모바일 앱이며, Bitmap 처리인 점을 고려하여 후자로 구현하였으며, 히스토리를 열고 닫을 수 있도록 처리하고, 히스토리의 각 단계별로 돌아가거나, 직전 단계로 돌아갈 수 있는 버튼을 추가 하였다.
* 사용 기술 :
- Glide (이미지 로딩)
- Firebase (이미지 서버로 전송)
- Realm (담아가기 구현)
* 주요 이슈 :
- 비회원제에서의 담아가기 처리
- 서버의 이미지 파일 및 DB 관리
- 저장소 UI/UX
다른 앱으로의 움짤 공유는 Intent를 이용하며, 기본적으로 카카오톡, 구글 드라이브, 페이스북은 한 번의 클릭만으로 공유할 수 있도록 한다. 이 세 개의 앱으로 공유할 때는 해당 앱이 단말 내 존재하지 않으면 설치 페이지(Play Store)로 이동하며, 이 세 개의 앱 외의 다른 앱으로 공유할 때는 '...' 버튼을 이용하여 사용자의 단말에서 파일을 공유할 수 있는 앱들을 선택할 수 있도록 한다.
자체 서버의 저장소는 움짤과 15자 이내의 움짤 제목만을 이용해 업로드하며, 업로드 시 firebase database, storage를 이용한다. 카테고리는 유머/힐링/인물로 나뉘어 있으며, 사용자에게는 '저장소'라는 탭을 추가하여 사용자가 서버에서 선택한 움짤들을 모아서 볼 수 있도록 하는 환경을 제공한다. 서버 저장소 내의 모든 움짤은 long click하여 쉽게 다운로드할 수 있도록 하며, 사용자의 번거로움을 덜고자 비회원제로 운영한다. 비회원제 이므로 '저장소'로 담아가는 행동은 사용자의 단말로 저장되며, 이 때에는 Realm을 이용했다.
* 사용 기술 :
- ButterKnife (개발 편의)
- SweetAlertDialog, LabelView, BoomMenu, Discrete SeekBar, DiscreteScrollView, AVLoadingIndicatorView (UI 개선)
* 주요 이슈 :
- 주요 및 부수적 색상
- 뷰 배치
- 사용자의 편리
언제나 UI가 문제다. 특히 PPT나 APP같은 여러 뷰로 이루어지고 여러 화면들로 이루어진 UI에서 뷰를 어디에 배치할 것인가, 어떤 색을 쓸 것인가가 너무 어렵다.
일단 기능 위주로 만들었을 때는 튜터님께서 너무 칙칙해 보인다고 하셨고, 그래서 민트색으로 밝기만 확 올렸을 때도 역시 별로여서 다시 흑백으로 변경하고 톤을 올리며 부수적인 색을 적용했다.
튜터님께 지도받아서 뷰 위치들을 전면 개편하고 Intent로 가져오던 이미지도 Fragment 위에 Gallery를 구현해서 좀더 일관성있고 개발자가 덜 꾸며도 사용자가 자기 컨텐츠로 스스로 꾸미도록 해보았다.
색은 도저히 몰라서 튜터님이 추천해주신 ImgPlay를 참고하고 안드로이드 머티리얼 디자인 가이드에서 색상코드를 가져와서 적용해보면서 괜찮아보이는 걸로 골랐고, 갤러리 디자인은 ImgPlay, 히스토리 디자인은 Snapseed에서 가져왔다.
기존에 BoomMenu를 이용해 밝기/대비/감마 조절 Fragment로 이동하던 방식을 TabLayout으로 변경하고 BoomMenu에는 대신 필터를 넣어넣고 TabLayout과 묶어 background를 적용하였으며, 밝기/대비와 감마보정은 curve로 하여 snapseed 처럼 2차원 보정하는 것은 초보 사용자가 이해하기 어렵고 UI적으로도 별로인것 같다는 주위 의견을 받아들여 1차원 SeedBar로 고정하고 조정창 크기를 축소하는 대신 미리보기 화면을 확대했다.
움짤의 특성상 화질이 좋지않아 작게 띄우던 다이얼로그는 그 디자인이 별로이며 뒤의 배경(Gallery)이 너무 화려해서 눈에 잘 들어오지 않는다는 의견을 듣고 전체화면으로 구현해봤는데, 때마침 기능구현에서 움짤 생성 시간 단축과 화질 개선이 있어 움짤의 전체화면도 별 문제는 없었다.
실행화면 스크린샷입니다. 참고하세요.
" 열심히하는 팀원들의 모습에 나도 더 집중해서 만들 수 있었고,
튜터님들도 많이 도와주셔서 만들어보고 싶었던 앱을 보다 완성도 있게 개발할 수 있었다.
그리고 그 그 과정에서 내게 부족한 부분을 찾고 더 많은 것을 배울 수 있었다. "
최근에 Android를 이용한 프로젝트, OpenCV를 이용한 프로젝트를 진행해서 이 두 프로젝트에서 배운 내용을 이용해서 새로운 프로젝트를 해보고 싶었다. 그리고 평소 PC로 비디오 플레이어와 포토샵을 이용해서 움짤을 만들기도 했기 때문에 그냥 단순히 만들고 싶은 앱이기도 했다. 그래서 또 다른 하나의 기획안보다 여기에 더 많은 시간과 정성을 쏟았다. 필요 기술도 찾아서 모아두면서 '혹시 지금 당장 만들기 힘들다 해도 나중에 한 번 만들어 봐야지' 하고 생각한 프로젝트였다.
그리고 본격적으로 만들기 시작했을 때, 필요 기술을 미리 찾아두어서인지 생각보다 빠르게 주요 기능을 구현할 수 있었다. 사실 이렇게 하루의 긴 시간을 개발에만 매달린 적이 없기도 했다. 다른 프로젝트의 경우 회의도 반복하고, 회의 결과 DB나 전체 디자인이 뒤집히고 하고, 다른 팀원이 막히는 부분을 돕기도 하고, 창업 프로젝트의 경우 특허나 발표준비를 돕기도 하고, 학기 중에는 학교 공부도 해야 했으니 이렇게 하루에 약 12시간씩 내 마음대로 개발에만 매진하는 건 처음이었던 것 같다.
그리고 이렇게 처음으로 1인 개발한 결과물은 개인적으로 아주 만족스럽다. 물론 이 앱은 아직 추가할 기능도 많고, 수정해야 할 부분도 많고, 다른 사람이 보기에 별거 아닌 것처럼 보일 수도 있지만, 앞으로 언제든 발전사항을 추가해 넣을 수 있는 기반이 되는 움짤 생성 및 보정 앱을 만들었다는 것에 큰 의의를 둔다. 하루의 많은 시간을 사용하긴 했지만, 기간으로 보자면 학습 기간을 포함해 길어야 2개월이라는 짧은 기간 안에 이렇게 앱을 만든 것에는 크게 3가지의 이유가 있다고 생각한다.
하나는 옆에서 같이 개발하고 있는 팀원들이 열심히 하는 모습을 보다 보니 계속해서 나태해지는 생각도 바로잡을 수 있었다는 것이다. 언제나 '이 정도 됐지'하고 생각하던 것도, 옆에서 팀원들이 열심히 하는 모습에 자극받아 '조금 더, 조금 더' 하면서 부수적인 기능과 추가 기능을 구현하고, UI도 신경 쓰면서 앱을 만들어 낸 것 같다.
둘째로 막혔을 때 언제나 물어볼 수 있는 옆에 있는 팀원들과 팀원들도 모를 때 물어볼 수 있는 튜터님이 있어서 앱을 좀 더 빠르고 안정적으로 만들 수 있었던 것 같다. 전에 창업 프로젝트를 할 때는 컴퓨터에 대해서 고작 3년 배운 학부생이 앱 개발을 총괄하면서 'A가 맞는 건인지, B가 맞는 건인지' 아무것도 모르고 개발부터 시작했고, 디자인팀이랑 얘기할 때도 '이게 기간안에 되는건지, 안되는 건지' 알 수가 없었는데, 부스트캠프를 통해 옆에 같은 기술에 대해 같이 공부하고 개발하고 있는 동료들이 있어서 많은 의견을 듣고 방법을 떠올릴 수 있었고, 개발 방향을 잡을 수 있었다.
마지막으로 튜터님들이 앱을 보고 보완해야 할 점을 알려주셔서 앱의 완성도를 높힐 수 있었던 것 같다. 처음에는 UI에 하나도 신경쓰지 않고 주요 기능만 만들었었는데 뷰의 배치나 앱의 디자인에 대해서 많은 것을 배울 수 있었고, 그렇게 UI/UX가 바뀌면서 더 추가해야 할 기능들이 보였다. 또 튜터님이 추가해 보라고 한 기능도 추가하면서 더 많은 것을 배우고 익히는 기회도 되었다.
물론 개발하면서 어려워서 막힌 부분도 있었고, 한 마디 에러조차 뜨지 않는 오작동을 보며 고민하고, 좀 더 효율적으로 구현하려면 어떻게 해야하는가 생각하면서 힘든 점도 있었다. 그러나 이렇게 부스트캠프를 통해 개발해보고 싶었던 앱을 보다 완성도 있게 개발할 수 있게 되면서 그 과정에서 많은 것을 배울 수 있게 되었고, 내가 앱 개발에서 신경 쓰지 않고 있던 부분도 파악할 수 있었다. 또, 무엇보다 부스트캠프를 통해 확신이 서지 않던 내 개발 방식을 되짚어보고, 어떤 것을 더 공부해야 할지 알 수 있어서 앞으로도 더 큰 도움이 될 경험이 되었다고 생각한다.
아주 좋은 앱이다! 이 앱을 만난 후 나는 프레임마다 보정하는 기계같은 작업에서 해방되었다!
프로 움짤러 A씨움짤 만드는 사람들보면 능력자인줄 알았죠. 근데 이 앱으로 움짤을 만들고 나서는, '아무나 쉽게 만들 수 있는거구나!' 깨달았어요.
네티즌 B씨요즘 움짤 만드는게 재밌네요. 방송을 보던 중에 내가 원하는 부분을 움짤로 가지고 싶어서 커뮤니티에 요청한 적이 있었는데, 이제 직접 만들고 내가 공유도 해요!
사용자 C씨여러분 그거 알아요? 이거 모든 보정은 중첩이 돼요! 어두운 사진이 감마 보정으로 밝고 또렷한 사진이 됐네요!
지나가던 D씨이 앱은 오픈소스로, https://github.com/gemini1024/Emoge 에서 모든 소스를 확인할 수 있습니다. 기능을 추가하고 싶거나 개발에 참여하고 싶다면, 언제든지 도와주세요.
개발자 E씨사실 옆에 모든 인물은 동일인 입니다. ㅎ
개발자Google App Store에서 다운로드 하실 수 있습니다.
