반응형

 

리액트를 빌드하던 중 위와 같이 멈추고 더 이상 진행되지 않는 경우가 있다.

메모리가 부족하게 되면 위 현상이 나타나게 된다.

특히 AWS 프리티어를 쓰는 경우 t2.micro 사양을 사용하게 되는데 램이 1기가밖에 되지 않는다.

조금만 빌드 규모가 커져도 위와 같은 증상을 발견하게 된다.

 

해결 방법은 여러가지가 있다. 

 

1. 빌드시 GENERATE_SOURCEMAP 옵션을 꺼준다.

위와 같이 package.json 파일을 열면 build 부분에 GENERATE_SOURCEMAP를 false로 설정해준다.

어짜피 프로덕션시에는 결국 이 옵션은 꺼주는게 맞기는 하다.

노출되지 않아야 하는 코드들을 보호해주는 역할도 해주기 때문이다.

그리고 해당 속성이 켜져있을 경우 디버깅 정보가 포함되어 빌드되기 때문에 빌드 용량이 커지게 되며,

이는 곧 메모리 부족으로 이어지므로 꺼주게 되면 어느정도 메모리 부족 현상도 해결해주게 된다.

 

2. 메모리 스왑을 통한 메모리 부족 현상 처리

위의 GENERATE_SOURCEMAP 옵션을 끄더라도 결국 빌드 규모가 커질 경우 메모리를 많이 차지할 수 밖에 없다.

즉, 1번 방법으로도 해결되지 않을 경우 이 메모리 스왑 방법을 써볼 수 있다.

메모리 스왑은 간단히 설명하면 메모리의 부족한 부분을 디스크의 일부를 사용하여 대신 사용할 수 있는 기능이다.

메모리에 비해 디스크가 속도가 훨씬 느리기 때문에 스왑 사용시 속도가 느려진다는 단점은 있다.

AWS에서 프리티어는 써야하고 메모리 부족 현상은 해결해야 할 때 써볼만 할 것이다.

 

위 스크린샷은 SSH를 통해 AWS의 메모리 현황을 표시해본 것이다.

보면 기본적으로 AWS 인스턴스는 스왑 메모리가 지정되어있지 않아서 0으로 표시된다.

 

(1) sudo dd if=/dev/zero of=/mnt/swapfile bs=1M count=2048

(2) sudo mkswap /mnt/swapfile

(3) sudo swapon /mnt/swapfile

위 세 명령어를 입력하여 스왑 메모리를 생성해준다.

 

 

위와 같이 메모리를 확인해보면 스왑 메모리가 2기가가 잡혀있는 것을 확인할 수 있다.

그리고 다시 빌드하면 메모리 부족 현상으로 인한 빌드 멈춤 문제는 해결될 것이다.

 

하지만 이처럼 가상 메모리를 쓰게 되면 퍼포먼스의 문제가 발생하므로 임시 방편으로 쓰고 사양을 올릴 것을 추천한다.

 

※ 스왑메모리 해제 방법

sudo swapoff -v /mnt/swapfile
sudo rm /mnt/swapfile

위 두 명령어로 스왑메모리를 해제할 수 있다.

 

이상 리액트 빌드시 멈춤 현상을 해결하는 방법에 대해 설명하였다.

이 외에도 다른 방법들도 있기는 하다. 빌드 규모를 줄이기 위한 코드 스플리팅이나,

위 메모리 스왑 이전에 캐시 메모리가 많이 존재한다면 캐시 메모리를 초기화해주는 방법 등이 있다.

필자 또한 임시적으로 문제를 해결해야 했기 때문에 위에 언급한 2가지 문제로 충분히 해결이 가능했다.

반응형
반응형

 

많은 사람들이 앱 서비스를 개발하여 성공하기를 갈망한다.

아무래도 휴대폰이 필수 기기가 된 이 시대에 사용자에게 쉽게 다가가기 위한 서비스가 앱이기 때문일 것이다.

웹 또한 인터넷을 통해 쉽게 접근이 가능하지만, 외부에 있다던지 밤 늦게 침대에서 자유롭게 사용하기에는 휴대폰만한게 없기 때문에 앱이 접근성 면에서는 더욱 유리하다.

 

앱은 사용자가 접근하기에는 매우 편리한 서비스지만, 웹에 비해 개발에 신경써야할 것이 더 많다고 생각한다.

다양한 이유가 있지만 간단히 말하면, 웹은 인터넷 하나로 통하지만, 앱은 Android, IOS 두가지 플랫폼을 신경써주어야 하기 때문이다.

 

앱 개발에 관심을 갖는 사람들은 많지만 정작 개발하려면 어떻게 시작해야할지 막막하고,

자신이 직접 개발을 하지 않고 외주 등을 통해 진행하려한다해도 최소한의 개발이 어떻게 진행되는지는 알아야 할 것이다.

 

이에 따라, 나는 앱 서비스 개발에 대해 전혀 감을 잡지 못하는 분들에게 최소한의 개발 과정을 이해시키고

사업을 진행하는데 있어서 도움이 되길 바라는 마음에서 이 글을 쓴다.

(참고로 앱에 대해 한정해서 얘기하지만 전반적으로 웹이든, 다른 분야든 어느 정도 통용은 된다.)

 

먼저 서비스 개발의 모든 것은 아이디어를 떠올리는 것부터 시작된다.

'이 앱을 만들면 성공할 것 같다.', '이 앱은 기존에 없는 앱이다', '이건 무언가 불편한데...', '이렇게 하면 재밌겠다.' 등등 내가 겪은 무언가를 통하거나 여러 이유에서 새로운 서비스를 만들어야겠다는 필요성을 느끼게 된다.

 

이제 여기서 서비스 개발을 위해 다음 단계를 진행하게 되는데,

이 단계에서 많은 사람들이 착각하는 것이 이 상태에서 바로 개발을 진행하려한다는 것이다.

개발자를 만나서 '지금 내가 이런 아이템을 생각하고 있습니다. 이렇게 만들어주세요.' 이렇게 말하면,

제대로 된 개발자라면 거절하거나, 정리된 기획 문서를 요구한다.

물론, 돈이 궁하다던지, 경험이 별로 없는 개발자 혹은, 추후 리스크를 감수할 수 있는 개발자라면 그냥 받아서 진행하는 경우도 있다. 이 경우 순탄하게 개발이 진행되는 경우는 흔치 않다.

갑자기 잠수를 탄다던지, 중간에 포기를 선언한다던지 하는 경우가 꽤 드물지 않게 존재한다.

그 이유는 개발자가 생각하는 개발의 규모와 외뢰자가 생각하는 개발의 규모가 다르기 때문이다.

애초에 정확한 설계도가 없는 상태에서 각자가 생각하는 것이 동일할 수가 없기 때문에 어쩌면 당연한 것이다.

 

아이디어를 떠올렸다면 '기획'을 진행해야 한다. 기획이란 아이디어를 구체화시키는 것이라 보면 된다.

기획에는 많은 것들이 내포되어있다. 시장성 조사, 사업계획서 작성, 스토리보드 작성, 추후 추진 계획 등...

여기서는 개발 진행에 필요한 최소한의 것만 설명할 것이다.

 

개발자가 원활하게 개발을 진행하려면 스토리보드 & 와이어프레임이 필요하다.

(아주 간단한 앱이라면 구두로만 해도 진행은 가능하다.)

위를 보면 앱 화면들이 나열되어있다.

내가 만들고 싶은 아이디어를 구체화 시키는 작업이 필요한데, 개발자를 쉽게 이해시키고 개발을 요청하기 위해

위와 같이 내가 만들 앱의 모든 화면을 구현해놓은 것을 스토리보드라 한다.

스토리보드에서 어떤 버튼을 터치하면 어디로 연결이 되는지 등의 정보를 와이어로 연결해준 것을 와이어프레임이라고 한다. 와이어프레임이 있어야 앱 화면간의 유기적인 동작 구조를 이해할 수 있기 때문이다.

뭐 스토리보드만 있어도 개발이 불가능한건 아니니 스토리보드만 요청하는 경우도 있기는 하다.

 

어쨌든 저러한 스토리보드 작성을 본인이 직접 하던가, 앱 기획자를 외주로 구하던지 해서 만들어내야 한다.

애초에 앱에 대한 지식이 별로 없다면 본인이 작성하여도 이해시키기 어려울 가능성이 높으므로 앱 기획자를 고용하는게 순탄하게 진행할 수 있는 방법일 것이다.

스토리보드 작성을 위한 툴은 여러가지가 있는데, 대표적으로 Adobe XD, Sketch, Axure 등이 있다.

기획자마다 작업하는 툴이 다를 수 있고, 되도록 내가 원하는 툴로 작업해줄 것을 요청하는게 좋다.

Sketch는 인기가 많은 툴이지만 맥OS에서만 구동이 가능하고 나의 경우 주로 윈도우 환경에서 작업하기 때문에,

기획 문서를 요청시 Adobe XD로 작업을 요구한다. 규모에 따라 다르지만 보통 기획 작업은 3~6주 정도 걸린다.

 

자, 그럼 스토리보드를 진행 완료하고 그 다음 작업은 무엇일까?

바로 앱 디자인이다. 앱 기획자는 디자이너가 아니기 때문에, UX/UI 디자인을 고려하기 어려운 경우가 많다.

그렇기에 깔끔하고 유저들이 사용하기 쉬운 디자인을 구현하기 위하여 앱 디자인을 진행하게 된다.

앱 디자인은 저렇게 만들어진 스토리보드를 앱 디자이너에게 넘겨주기만 하면 된다.

그럼 앱 디자이너는 저 스토리보드에 새로운 디자인을 씌워서 넘겨줄 것이다.

(참고로 기획자가 작성한 스토리보드 수준의 디자인만으로 충분하다면 굳이 앱 디자인을 진행하지 않고 맡겨도 된다.)

앱 디자인 기간은 보통 화면 개수에 따라 달라지게 되는데, 보통 3~4주 정도 걸리게 된다.

단가의 경우 디자이너마다 다르지만, 앱 화면 하나당(중복화면 제외) 단가 2~6만원으로 잡고 진행하는 듯 하다.

 

여기까지 완료되었으면 이제는 개발자에게 요청할 수 있는 단계가 된다.

개발자는 스토리보드를 넘겨받으면 자신이 이 스토리보드를 보고 어느정도 일정 내에 소화 가능한지, 어느정도 비용이 들 것인지를 산정하게 된다.

여기서가 중요한데, 개발을 어떤 방식으로 진행할지에 대한 부분을 결정해야 한다.

앱 개발하는 방법은 여러가지가 있는데, 크게 웹앱, 하이브리드앱, 크로스플랫폼 앱, 네이티브 앱 4개 단계로 나눠진다.

 

[웹앱]

웹앱은 모바일 웹이라고 보면 된다. 개발 단가는 가장 싼 편에 속하지만, 브라우저로 접근해야된다는 단점이 있다.

웹이기 때문에 구현하고나면 Android/IOS 상관없이 접속이 가능하다.

 

[하이브리드 앱]

모바일 웹을 네이티브로 감싼 앱이라고 보면 된다. 즉, 기기에서 아이콘을 눌러서 앱을 실행하지만 그 내부는

웹뷰(브라우저)로 되어있는 것이다. 웹앱보다 편리한 접근을 원하거나, 푸시 알림 등의 네이티브 기능이 필요할 때

하이브리드 앱으로 구현을 한다. 이전에는 네이티브로 Android/IOS 각각 브라우저로 감싸서 별도의 결과물을 만들어냈지만, 최근에는 크로스플랫폼 개발툴을 이용하여 Android/IOS 결과물을 동시에 만들어내기도 한다.

어쨌든 결국엔 웹앱을 감싼 것이기 때문에 퀄리티면에서는 조금 부족할 수밖에 없다.

 

[크로스플랫폼 앱]

Android/IOS 개발을 동시에 진행하지만 최종적으로는 각각의 결과물을 만들어준다.

네이티브에 비해 생산성이 월등하다. 하지만, 네이티브 종속적인 기능을 구현할 때는 개발에 어려움이 생길 여지가 있다.

최근 스타트업들이 대부분 이 크로스플랫폼 앱으로 개발을 진행한다. 아무래도 네이티브로 진행할 경우 안드로이드, IOS 개발자를 각각 구하여 각각 개발해야 하기 때문에 매우 비효율적이기 때문이다.

성능이나 퀄리티면에서도 하이브리드 앱과는 다르게 네이티브에 가깝게 구현할 수 있다.

 

[네이티브 앱]

휴대폰의 능력을 100% 활용하여 앱을 개발할 수 있다. 단, 안드로이드, IOS 각각 개발을 따로 진행해야한다는 점이 단점이다. 네이티브 종속적인 기능을 활용해야 하는 경우가 아니라면 크로스플랫폼 앱 개발로 진행하는 것을 추천한다.

개발 시간이 크로스플랫폼 앱 개발에 비해 거의 2배 이상 들게 되며, 비용 또한 상당히 높아지게 된다.

 

위 개발 방법 중 자신이 개발할 앱이 어느쪽에 적합한지 확인한 후에 개발자에게 요청하게 된다.

앱의 개발 기간은 프로젝트 내용에 따라 천차만별이다. 또 위의 개발 방식에 따라서도 달라지게 된다.

아주 간단한 프로젝트는 1개월만에도 만들어지기도 하지만, 복잡한 프로젝트는 최소 6개월~1년이 걸리기도 한다.

즉, 자신이 생각하는 프로젝트 규모에 따라 적절한 개발 인력을 산정하는 것도 중요하다.

그리고 개발이 시작된다면, 적어도 1주일에 한번 정도라도 주기적인 미팅으로 개발 진행 단계를 파악할 것을 권장한다.

그냥 개발자만 믿고 놔두다가는 마지막에 가서 어떤 오류에 부딪혀서 계속 고민중이라느니,

다른 사정이 있어서 못했다는 등의 이유로 거의 개발이 되어있지 않는 경우도 종종 존재한다.

실제로 이러한 경우로 프로젝트가 무산되는 경우도 꽤 있다.

 

개발이 완료되면 최종적으로 스토어에 올리는 작업을 진행하게 된다.

(보통은 테스트 단계에서 테스트 버전으로 미리 등록된다.)

이 경우 스토어에 앱에 대한 디테일한 정보를 개발자에게 알려주고 세팅을 요청할 수도 있다.

그리고 추후 유지보수를 위해 개발자에게 소스코드 또한 반드시 넘겨 받는다.

 

이제 앱이 심사를 받고 심사가 끝나게 되면 실제로 스토어에서 개발한 앱을 검색할 수 있게 된다.

당연히 앱의 활성화를 위해 마케팅은 개발 단계에서든지, 개발 이후에서든 진행을 해야할 것이다.

나름 간단하게 쓴다고 썼는데, 별 내용이 없는 듯한데도 너무 길어진 듯 하다.

추가적으로 궁금한 사항은 댓글 등을 통해 메일을 남겨주시거나 하면 답변드리겠습니다.

반응형
반응형

 

SVG 이미지는 픽셀 단위로 이루어진 비트맵 방식의 PNG와 다르게 벡터 이미지 방식을 사용하고 있다.

장점은 크기를 자유롭게 조정하여도 이미지 깨짐이 발생하지 않는다는 것이다.

 

휴대폰은 기종별로 다양한 해상도를 갖고 있으며, 개발자들은 이에 대응할 수 있어야 한다.

PNG 파일 하나를 이용해서 해상도별로 크기를 조정해가면서 사용할 경우 이미지 깨짐이 발생할 수 있고,

그렇다고 PNG 파일을 해상도별로 나누어 사용하기에는 소모 비용이 너무 크다.

 

이 때 사용할 수 있는 것이 바로 SVG 이미지이다.

플러터에서는 SVG를 쉽게 사용할 수 있도록 제공하는 플러그인이 존재한다.

 

flutter_svg 라는 플러그인인데, 아래의 순서대로 따라해보도록 하자.

 

위와 같이 pubspec.yaml 파일을 열고 flutter_svg: 0.17.4 를 추가해준다.

 

실제로 사용할 이미지를 추가해준다.

경로는 원하는 곳에 넣어도 상관없다.

 

위에서 추가한 파일을 pubspec.yaml에도 적어준다.

flutter pub get 명령으로 해당 내용을 반영해준다.

 

이제 flutter_svg 플러그인을 사용하기 위해 위와 같이 import 해준다.

 

위와 같이 SvgPicture 객체를 사용하여 SVG 이미지를 뿌려줄 수 있다.

width, height 속성을 이용하여 크기를 자유롭게 변경할 수 있으며,

SVG 벡터 이미지이므로 이미지 깨짐이 없다.

 

아주 깔끔하게 출력되었다.

 

참고로 SvgPicture.network() 함수를 통해 외부 네트워크에 있는 이미지를 표시할 수도 있다.

 

앱 내에서 아이콘이 차지하는 비중이 상당히 높기 때문에 SVG 파일을 이용하면,

이미지 용량도 절약할 수 있고 사이즈에 구애 받지 않기 때문에 더 효율적인 작업이 가능하다.

 

단, 아이콘이 아닌 복잡한 형태의 이미지는 PNG를 사용하는 것이 낫다.

단순하지 않은 이미지는 오히려 PNG 이미지보다 용량이 더 커질 수 있고, 속도에도 영향을 미칠 수 있기 때문이다.

반응형

+ Recent posts