Google for Developers Korea Blog

TensorFlow 2.0에서 기호형 API와 명령형 API란?

2019년 5월 29일 수요일

.post-body span { white-space: normal !important; } 게시자: Josh Gordon <블로그 원문은 이곳에서 확인하실 수 있습니다> 필자가 TensorFlow 2.0에서 가장 좋아하는 것 중 하나는 TensorFlow 2.0이 여러 가지 수준의 추상화를 제공하므로 자신의 프로젝트에 적합한 추상화를 선택할 수 있다는 점입니다. 이 게시물에서는 신경망을 만드는 데 사용할 수 있는 두 가지 스타일 사이의 절충점에 대해 설명하겠습니다. 첫 번째는 계층의 그래프를 조작하여 모델을 빌드하는 기호형 스타일입니다. 두 번째는 클래스를 확장하여 모델을 빌드하는 명령형 스타일입니다. 이 두 가지 스타일을 소개하고 중요한 디자인 및 사용성 고려 사항에 관해 특기할 점을 공유하고 알맞은 스타일의 선택에 도움이 되는 간단한 권장 사항을 제시하는 것으로 마무리하겠습니다. 기호형 (또는 선언형) API 우리가 신경망을 생각할 때 흔히 사용하는 정신 모델은 아래 이미지에 묘사되어 있는 것과 같은 '계층의 그래프'입니다.

우리가 신경망을 생각할 때 흔히 사용하는 정신 모델은 계층의 그래프입니다(이미지는 Inception-ResNet에 대한 스키마임).
이 그래프는 왼쪽에 표시된 DAG이거나 오른쪽에 표시된 스택일 수 있습니다. 모델을 기호로 빌드할 때는 이 그래프의 구조를 기술하는 방식으로 빌드합니다. 이 말이 기술적인 얘기로 들리세요? Keras를 사용해본 적이 있는 분이라면 이미 이런 경험이 있다는 사실을 알고서는 놀라실지 모르겠습니다. 다음은 Keras Sequential API를 사용하여 모델을 기호 방식으로 빌드하는 간단한 예시입니다.

Keras Sequential API를 사용하여 기호 방식으로 빌드한 신경망. 이 예시는 여기에서 실행할 수 있습니다.
위 예시에서, 우리는 계층 스택을 정의한 다음 내장된 훈련 루프인 model.fit을 사용하여 계층 스택을 훈련했습니다. Keras를 사용한 모델 빌드는 '레고 블록을 맞춰 끼우는 것'만큼이나 쉽게 느껴질 수 있습니다. 왜냐고요? 정신 모델과의 매칭 외에, 이후에 다룰 기술적 이유 때문에 이런 식으로 빌드한 모델은 프레임워크에서 제공되는 신중한 오류 메시지 덕분에 디버그하기 쉽습니다.

위의 코드로 만든 모델을 보여주는 그래프( plot_model로 빌드 시 이 게시물의 다음 예시에서 재사용할 수 있는 코드 스니펫이 있음). TensorFlow 2.0은 또 다른 기호 모델을 빌드하는 API인 Keras Functional을 제공합니다. Sequential은 스택용이고, 아마 짐작하셨겠지만 Functional은 DAG용입니다.

Functional API를 사용하여 다중 입력/다중 출력 모델을 만드는 간단한 예시 .
Functional API는 더욱 유연한 모델을 만들기 위한 수단입니다. 이 API는 비선형 토폴로지, 공유 계층을 포함한 모델, 다중 입력 또는 출력을 포함한 모델을 처리할 수 있습니다. 기본적으로, Functional API는 이러한 계층 그래프를 빌드하기 위한 도구 세트입니다. 우리는 현재 개발자를 위해 이 스타일로 두어 가지 새로운 튜토리얼을 만들고 있습니다. 이미 사용 경험이 있으실지도 모르는 다른 기호형 API도 있습니다. 예를 들어 TensorFlow v1(그리고 Theano)은 훨씬 낮은 수준의 API를 제공했습니다. 컴파일하고 실행하는 연산의 그래프를 만들어 모델을 빌드했을 것입니다. 때때로 이 API를 사용하는 것은 컴파일러와 직접 상호 작용하는 듯한 느낌이 들 수도 있습니다. (저자를 포함한) 많은 사람들에게는 사용하기 어려운 API였습니다. 반대로, Keras에서는 추상화 수준이 정신 모델과 일치하므로 마치 레고 블록처럼 끼워 맞춘 계층의 그래프가 생성됩니다. 이는 사용하기에 자연스러운 느낌이 들고, 우리가 TensorFlow 2.0에서 표준화하고 있는 모델 빌드 접근 방식 중 하나입니다. 설명해드릴 다른 API가 있습니다. (이 API 역시 사용해봤거나 곧 사용해볼 가능성이 높은 API입니다.) 명령형 (또는 모델 하위 클래스) API 명령형 스타일에서는 NumPy를 작성하는 것처럼 모델을 작성합니다. 이 스타일로 모델을 빌드하는 것은 마치 객체 지향 Python 개발과 같은 느낌이 듭니다. 다음은 하위 클래스형 모델의 간단한 예시입니다.

명령형 스타일을 사용하여 주의를 포함한 이미지 캡션 을 위한 모델 빌드(참고: 예시는 현재 업데이트 중임). 개발자 관점에서 볼 때, 이 API는 프레임워크에 의해 정의된 Model 클래스를 확장하고 계층을 인스턴스화한 다음 모델의 순방향 전달을 명령형으로 작성하는 방식으로 작동합니다(역방향 전달은 자동으로 생성됨). TensorFlow 2.0은 Keras Subclassing API를 사용하여 별도의 구성 없이 이를 지원합니다. Sequential API 및 Functional API와 함께, 이는 TensorFlow 2.0에서 권장되는 모델 개발 방법 중 하나입니다. 이는 TensorFlow에는 새로운 스타일이지만, 2015년에 이미 Chainer에 도입되었던 스타일이라는 사실을 아시면 놀라실지 모르겠습니다. 세월은 참 빠르게도 흐릅니다. 그 이후로, 많은 프레임워크에서 Gluon, PyTorch, TensorFlow(Keras Subclassing 포함) 등을 비롯하여 유사한 접근 방식을 채택했습니다. 놀랍게도, 다양한 프레임워크에서 이 스타일로 작성된 코드가 서로 너무나 비슷해 보여 구분하기 어려울 수 있습니다! 이 스타일을 사용하면 뛰어난 유연성을 누릴 수 있지만, 명확하지 않은 사용성 및 유지 관리 비용이 수반된다는 단점이 있습니다. 그에 대해 좀 더 자세히 알아봅시다. 훈련 루프 Sequential, Functional 또는 Subclassing 스타일 중 하나로 정의된 모델은 두 가지 방식으로 훈련할 수 있습니다. 내장된 훈련 루틴과 손실 함수를 사용하거나(model.fit과 model.compile을 사용하는 첫 번째 예시 참조), 맞춤 훈련 루프(예: 자체적인 그래디언트 클리핑 코드를 작성하고 싶은 경우) 또는 손실 함수의 복잡성을 추가할 필요가 있는 경우에는 다음과 같이 손쉽게 그렇게 할 수 있습니다.

위 코드는 Pix2Pix에 대한 맞춤 훈련 루프와 손실 함수의 예입니다. 사용 가능한 이런 접근 방식을 둘 다 가지는 것이 중요하며, 그러면 간편하게 코드 복잡성과 유지 관리 비용을 줄일 수 있습니다. 기본적으로, 복잡성을 더하는 게 도움이 되면 이를 사용하고, 불필요하면 내장 메서드를 사용하고 남은 시간을 연구나 프로젝트에 활용할 수 있습니다. 이제 기호형 스타일과 명령형 스타일에 대한 감을 잡으셨을 것이니, 절충점을 살펴봅시다. 기호형 API의 이점과 제한 사항 이점 기호형 API를 사용한 모델은 그래프와 같은 데이터 구조입니다. 즉, 모델을 검사하거나 요약할 수 있다는 뜻입니다.

모델을 이미지로 플로팅하여 그래프를 표시하거나( keras.utils.plot_model사용) 단순히 model.summary() 를 사용하여 계층, 가중치 및 모양에 대한 설명을 볼 수 있습니다.

마찬가지로, 계층을 함께 끼워 맞출 때 라이브러리 디자이너는 (모델을 빌드하는 동안, 그리고 실행 이전에) 광범위한 계층 호환성 검사를 실행할 수 있습니다.

이는 컴파일러의 유형 검사와 비슷하며, 개발자 오류를 크게 줄여줄 수 있습니다.

모델 실행 단계가 아니라 모델 정의 단계 도중에 대부분의 디버깅이 이루어집니다. 컴파일하는 어떤 모델이든 실행을 보장합니다. 따라서 더 빠르게 반복하고 더 쉽게 디버깅할 수 있습니다.

기호 모델은 일관된 API를 제공합니다. 따라서 간단히 재사용하고 공유할 수 있습니다. 예를 들어 전이 학습에서는 중간 계층 활성화에 액세스하여 다음과 같이 기존 모델로부터 새 모델을 빌드할 수 있습니다. from tensorflow.keras.applications.vgg19 import VGG19 base = VGG19(weights=’imagenet’) model = Model(inputs=base.input, outputs=base_model.get_layer(‘block4_pool’).output) image = load(‘elephant.png’) block4_pool_features = model.predict(image) 기호 모델은 모델을 자연스럽게 복사하거나 복제할 수 있게 해주는 데이터 구조로 정의됩니다.

예를 들어 Sequential API와 Functional API는 (모델 정의 및 훈련에 사용되는 원본 코드에 액세스하지 않고) 단지 데이터 구조로부터 같은 모델을 다시 생성하는 기능과 함께 model.get_config(), model.to_json(), model.save(), clone_model(model)을 제공합니다.

제대로 설계된 API는 신경망을 위한 정신 모델과 일치해야겠지만, 프로그래머로서 우리가 가지고 있는 정신 모델과 일치하는 것도 똑같이 중요합니다. 우리 중 다수에게 그것은 명령형 프로그래밍 스타일입니다. 기호형 API에서는 '기호형 텐서'(아직 어떤 값도 가지고 있지 않은 텐서)를 조작하여 그래프를 빌드합니다. Keras Sequential API와 Functional API는 명령형 API와 같은 '느낌'입니다. 이들 API는 많은 개발자가 모델을 기호로 정의해왔음을 실감하지 못하도록 설계되었습니다. 제한 사항 현 세대의 기호형 AP는 계층의 비순환식 그래프로 방향이 설정된 모델 개발에 가장 적합합니다. 예컨대 트리-RNN과 같은 동적 네트워크와 재귀 네트워크 등, 이 깔끔한 추상화에 맞지 않는 몇몇 특수한 사용 사례도 있지만, 대부분의 사용 사례는 실제로 이에 해당합니다. 그것이 바로 TensorFlow가 명령형 모델 빌드 API 스타일(위에 표시된 Keras Subclassing)도 제공하는 이유입니다. Sequential API와 Functional API에서 친숙한 계층, 이니셜라이저 및 옵티마이저를 전부 사용하게 됩니다. 이 두 가지 스타일은 완전히 상호 운용 가능하기도 하므로 혼합하고 매칭할 수 있습니다(예: 한 모델 유형을 다른 모델 유형에 중첩할 수 있음). 기호형 모델을 택해 하위 클래스형 모델에서 계층으로 사용하거나 그 반대로 합니다. 명령형 API의 이점과 제한 사항 이점 순방향 전달은 명령형으로 작성되므로 자체 구현으로 라이브러리에 의해 구현된 부분(예: 계층, 활성화 또는 손실 함수)을 쉽게 바꿀 수 있습니다. 이는 프로그래밍하기에 자연스러운 느낌이며, 딥 러닝의 기본을 더 깊이 파고들 수 있는 훌륭한 방법입니다.

이는 새로운 아이디어를 빠르게 시험하기 용이하게 해주므로(DL 개발 워크플로가 객체 지향 Python과 같아짐), 연구자에게 특히 도움이 됩니다.

Python을 사용하여 모델의 순방향 전달 내에서 임의의 제어 흐름을 지정하기도 쉽습니다.

명령형 API는 최대의 유연성을 제공하지만 비용이 듭니다. 필자는 이 스타일로 코드를 작성하는 것도 좋아하지만, 잠시 제한 사항을 분명히 밝히고 싶습니다(절충점을 인식하는 것이 좋음). 제한 사항 명령형 API를 사용할 때 클래스 메서드의 본문에서 모델이 정의된다는 점이 중요합니다. 모델은 더 이상 투명한 데이터 구조가 아니라 불투명한 바이트코드 조각입니다. 이 스타일을 사용할 때는 유연성 확보를 위해 사용성 및 재사용성이 그만큼 저하됩니다. 모델을 정의할 때와는 반대로 실행 중에 디버깅이 이루어집니다.

입력 또는 계층 간 호환성에 대해 실행되는 검사는 거의 없으므로, 이 스타일을 사용할 때는 디버깅 부담이 대부분 프레임워크에서 개발자에게 넘어갑니다.

명령형 모델은 재사용하기 더 어려울 수 있습니다. 예를 들어 일치하는 API로 중간 계층이나 활성화에 액세스할 수 없습니다.

그 대신에 새로운 호출(또는 전달) 메서드로 새로운 클래스를 작성하여 활성화를 추출할 수 있습니다. 처음에는 이렇게 작성하는 것인 재미있을 수 있지만, 명확한 기준이 없으면 기술적 부채의 전형이 될 수 있습니다.

명령형 모드는 또한 검사, 복사 또는 복제가 더 어렵기도 합니다.

예를 들어, model.save(), model.get_config(), clone_model 은 하위 클래스형 모델에는 효과가 없습니다. 마찬가지로, model.summary() 는 계층의 목록만 제공합니다. 그리고 액세스할 수 없으므로 계층의 연결 방식에 관한 정보는 제공하지 않습니다.

ML 시스템의 기술적 부채 모델 빌드는 실제로는 머신러닝을 이용한 작업의 아주 작은 부분에 불과하다는 점을 기억하는 것이 중요합니다. 다음은 이 주제에 관해 필자가 즐겨 쓰는 그림입니다. 모델 자체(계층, 훈련 루프 등을 지정하는 코드 부분)는 중간에 있는 작은 상자입니다.

중간에 있는 작고 검은 상자로 표시된 것처럼, 실제 ML 시스템의 작은 부분만이 ML 코드로 구성됩니다. 출처: 머신러닝 시스템에 숨겨진 기술적 부채(Hidden Technical Debt in Machine Learning Systems). 기호로 정의되는 모델은 재사용성, 디버깅 및 테스트에 장점이 있습니다. 예를 들어 필자는 강의할 때 학생이 Sequential API를 사용 중인 경우 학생의 코드를 즉시 디버그할 수 있습니다. 하지만 (프레임워크와는 무관하게) 학생이 하위 클래스형 모델을 사용 중일 때는 시간이 더 오래 걸립니다(버그가 더 교묘하고 유형도 다양할 수 있음). 결론 TensorFlow 2.0은 별도의 구성 없이 이런 스타일을 둘 다 지원하므로 프로젝트에 적합한 추상화 및 복잡성 수준을 선택할 수 있습니다.

사용 편의성과 낮은 개념적 오버헤드를 목표로 하고 자신의 모델을 계층 그래프로 생각하고 싶다면 (마치 레고 블록을 끼워 맞추는 것과 같은) Keras Sequential API 또는 Functional API와 내장된 훈련 루프를 사용하세요. 이는 대부분의 문제에 들어맞는 적당한 방법입니다.

객체 지향 Python/Numpy 개발자로서 모델을 생각하고 싶고 유연성과 해킹 가능성을 우선한다면 Keras Subclassing이 적합한 API입니다.

이 글이 개요를 파악하는 데 도움이 되었기를 바라며 읽어주셔서 감사합니다! TensorFlow 2.0 스택과 이러한 모델 빌드 API 이상의 주제에 관한 자세한 내용을 보려면 이 게시물을 참조하세요. TensorFlow와 Keras 사이의 관계에 대해 자세히 알아보려면 여기를 참조하세요.

AMPproject.org가 amp.dev로 이전합니다!

2019년 5월 29일 수요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있습니다>
게시자: Paul Bakaus, Sebastian Benz, Crystal Lambert, Matt Ludwig (amp.dev의 핵심 유지 관리 담당자)

2017년 초, 최초의 AMP Conf 직전에 출시된 ampproject.org의 현재 버전을 선보인지 어느덧 2년여의 세월이 흘렀습니다. 그때 이후로 AMP 프로젝트는 크게 성장했고 이메일 및 스토리와 같이 웹에서 완전히 새로운 AMP 애플리케이션을 출시했습니다. 그뿐 아니라, AMP 리소스는 ampbyexample.com, ampstart.com 등의 여러 웹사이트에 널리 배포되었습니다. 우리는 그 모든 것들을 한데 모아 새롭고 더 나은 방식으로 구성되고 사용하기도 쉬운 뭔가를 만들기로 했습니다. AMP의 모든 것을 새로운 보금자리로 들여놓기 위해 설레는 마음으로 amp.dev를 발표합니다! 완전히 새롭게 꾸민 amp.dev는 ampproject.org를 대체하여 개발자와 개발자의 비즈니스 파트너가 모든 다양한 형식에 걸쳐 AMP에 관해 알아야 할 모든 것을 제공하게 됩니다. 물론, amp.dev 역시 캐시에서 사용하지 않을 때 사이트가 훨씬 더 빠르게 열리도록 하기 위해 AMP 옵티마이저를 사용해 완전히 AMP로 빌드되었습니다.

완전히 새로워진 amp.dev 홈페이지

amp.dev에서는 웹사이트, 스토리, 광고, 이메일 등이 색상별로 정렬되어 있으므로 AMP의 모든 애플리케이션에 대한 정보를 찾을 수 있을 것입니다. 문서 섹션은 전반적으로 최대한 간단하게 탐색하실 수 있도록 디자인했습니다. 각종 안내서와 가이드는 AMP 개발자 워크플로에서 단계별로 구분되어 있습니다. 따라서 프로세스의 각 단계에서 성공적인 AMP 사이트를 빌드하기 위한 리소스와 자신감을 얻을 수 있을 것입니다.

웹사이트, 스토리, 광고 및 이메일 전반의 문서
기존 ampbyexample.com 리소스뿐 아니라 ampstart.com의 템플릿이 전부 amp.dev의 다양한 섹션으로 마이그레이션되고 통합되었습니다. AMP로 만들 수 있는 다양한 가능성을 보여주는 갤러리를 찾을 수 있는 Use Cases와 같은 새로운 섹션도 있습니다. 지금은 이 섹션에 몇 개 항목밖에 없지만, 앞으로 몇 달 동안 계속 늘어날 것입니다.

amp.dev의 Use Cases 섹션
우리는 새로운 사이트로 원활하게 전환할 수 있도록 AMPproject.org를 잠시 떠날 예정입니다. 하지만 곧 AMPproject.org를 정리하기 시작하면서 리디렉션을 설정해두겠습니다. 지금은 각 사이트에 곧 변화가 생길 것이라는 사실을 알리는 배너가 있습니다. (지금 읽고 계시는) 이 블로그는 이미 blog.amp.dev로 이전된 블로그입니다. 마지막으로, AMP 프로젝트가 커뮤니티 전체의 노력의 산물인 것과 마찬가지로, 이 사이트 역시 가능한 한 최상의 사이트로 만들 수 있도록 피드백을 공유해주실 것을 부탁드립니다. 여러분의 생각과 뭔가 고쳐야 할 문제점을 확인할 수 있도록 모든 페이지의 맨 아래에 있는 배너에서 연결되는 피드백 양식을 만들어두었으므로 이 양식을 활용해 주시기 바랍니다. 전과 마찬가지로, amp.dev 역시 Github에서 AMP 프로젝트의 docs repo에서 유지 관리되므로, 모든 내용을 공개적으로 볼 수 있습니다. 그곳에서 Github 문제점을 제기하실 수도 있습니다. 수개월 동안 이번 작업에 진행한 Jung von Matt TECH 관계자 여러분께 큰 감사의 마음을 전합니다.

Flutter 1.0 출시 요약 뉴스

2019년 5월 22일 수요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있습니다> 우리가 전 세계적인 Flutter 기념 행사인 Flutter Live를 개최한 지 2주일 정도 지나 행사에 대해 몇 가지 반추한 사항을 공유해야겠다고 생각했습니다. Flutter 팀은 Flutter 1.0의 출시에 즈음하여 커뮤니티의 열광적인 반응에 압도되었습니다. Flutter를 사용하면 즐겨 사용하시는 IDE/편집기 및 개발자의 생산성을 훨씬 더 높여주는 오픈소스 런타임과 함께 작동하는 도구를 사용하여 빠르고 멋진 앱을 빌드할 수 있습니다. 이번 행사는 Flutter에 대한 우리의 계획을 공유하고 파트너들이 Flutter를 기반으로 놀라운 방식으로 빌드하고 있는 몇몇 사례를 시연하고 전 세계 곳곳의 Flutter 커뮤니티 그룹이 함께 모이는 모습을 목격한 잊지 못할 순간이었습니다. Flutter의 모멘텀 올해(2018년) 2월에 Flutter가 베타 단계로 들어간 후로 25만여 명의 개발자가 2억여 명의 사용자를 위해 다양한 앱을 빌드했습니다. 그 짧은 시간에 벌써 Flutter의 저장소는 GitHub에서 실제 가장 많이 사용되는 25개의 소프트웨어 저장소 중 하나가 되었습니다. Flutter Live에서 우리는 Flutter가 GitHub에서 실제로 사용되는 가장 인기있는 소프트웨어 저장소 순위에서 34위라는 사실을 밝혔는데, 행사 이후로 이미 21위까지 치고 올라왔습니다. 이는 Swift, Kubernetes, Angular, TypeScript 등을 앞서는 순위입니다. 우리는 개발자들이 Flutter에 보여주시는 뜨거운 애정에 계속 놀라움을 금치 못하고 더욱 겸허한 마음을 갖게 됩니다. 그리고 개발자 여러분이 Flutter를 사용하여 훌륭한 앱을 빌드하고 있음이 분명합니다. Reflectly, Topline from Abbey Road 그리고 새로 나온 History of Everything과 같은 앱을 보면 모든 픽셀과 모션이 얼마나 놀랍게 구현되어 있는지 느낄 수 있습니다. 이러한 앱과 다른 인기 Flutter 앱에 대한 Google Play와 Apple App Store의 평가를 보면 사용자들이 이러한 점에 동의한다는 사실을 알 수 있습니다. 기조연설에서 주요 주제로 다루어지는 데서 볼 수 있듯이, Flutter Live 이벤트에도 그 모멘텀이 작용했습니다.

그 모든 것이 이벤트 자체를 위해 준비되었으며, 이 10분 분량의 하이라이트 동영상에 요약되어 있습니다.

아직 보지 못하신 분은 Flutter Live 콘텐츠 전체 재생목록을 확인해보세요. Flutter 커뮤니티 Flutter 1.0에 이르기까지 Google뿐만 아니라 커뮤니티 전체의 공로가 컸습니다. Flutter 커뮤니티는 Flutter와 관련 도구의 개발에 있어 매우 소중한 역할을 했는데, 285명의 참가자가 12,000회 이상 커밋을 맡아주셨습니다. Flutter는 전 세계적인 참여를 촉진하기 위해 개방적 환경에서 개발되었지만, 개발팀조차 커뮤니티가 얼마나 강력하고 빠르게 성장할지 결코 예상치 못했습니다. 거의 알려지지 않은 사실 하나를 소개하자면, Flutter용 Visual Studio Code 플러그인 개발은 (DanTup으로도 알려진) Danny Tuppeny라는 단 한 명의 커뮤니티 개발자가 해낸 일입니다. 이처럼 놀라운 일을 해낸 Danny는 현재 VSCode로 Flutter 작업을 훌륭하게 처리하는 일을 전업으로 삼고 있습니다! Flutter가 개발자들에게 안겨주는 영감은 그 정도 선에서 멈추지 않습니다. 개발자들은 전 세계 여러 곳에서 열린 뷰잉 파티에 함께 모였습니다. 예컨대 에스토니아,

중국,

그리고 우간다 캄팔라까지 말이죠.

#MyFlutterStory에 다양한 스토리를 게시해주신 모든 개발자께 감사드립니다! 최고의 기여자를 선정하기란 어려운 일이었습니다.

모두 정말 부지런하게 활동해주신 개발자들이십니다. pub.dartlang.org에서 Flutter 패키지 목록을 보면 오늘 당장 본인의 프로젝트에도 적용할 수 있는 1,000여 개의 패키지가 나와 있는데, 모두 많은 개발자가 커뮤니티를 통해 기고해주신 패키지입니다. 커뮤니티에서 현재 이러한 리소스를 사용하여 이미 빌드 중인 작업물의 간단한 샘플을 보실 수 있습니다.

하지만 그게 전부가 아닙니다. Flutter 앱에 Firebase를 추가하기 위한 기존의 패키지 세트 외에, 실시간 이미지 및 특징 인식을 구현한 새로운 Firebase MLKit와 Square Reader에서 또는 앱 내에서 직접 결제를 받을 수 있는 Flutter용의 2가지 새로운 Square SDK도 있습니다. 도구 측면에서는, 아마 Android Studio용 Flutter 플러그인과 Visual Studio Code에 이미 익숙하시겠지만 Flutter를 위한 훌륭한 벡터 애니메이션 빌드에 도움이 되는 2Dimensions Flare 또는 Flutter 앱을 위한 Google Play 및 Apple App Store에 테스트 및 연속 배포 기능을 제공하는 Nevercode Codemagic에 대해 알고 계셨나요? Flutter 커뮤니티는 지금도 강력하지만 점점 더 강력해지고 있는 것이 분명합니다. 시작하려면 우선 Flutter 사이트인 flutter.io에서 제공하는 우수한 각종 문서, 샘플, 동영상 및 코드랩을 찾아보세요. Flutter 개발, 문제점 신고 또는 기능 요청에 대해 궁금한 사항이 있으면 Flutter 커뮤니티의 일원이 되어 적극적으로 활동해 보시기 바랍니다. Flutter의 미래 Android와 iOS를 대상으로 하는 Flutter 1.0의 출시와 함께, 개발팀은 이제 막 첫발을 뗀 단계라 할 수 있습니다. 사실, 시험해 볼 만한 새로운 기능들이 베타 버전에 이미 있습니다. Flutter 앱에 기존 모바일 플랫폼 컴포넌트를 추가하고 싶으면 새로운 Web View 및 Google 지도 패키지를 만드는 데 차례로 사용되었던 플랫폼 뷰를 통해 추가할 수 있습니다. 반대로, 기존 모바일 앱에 Flutter 코드를 넣으려면 Add to App 기능을 사용하면 되는데, 이를 통해 Flutter의 성능과 미적 요소를 계속 이용하면서도 현재 앱을 활용할 수 있습니다. 우리는 개발자 여러분의 의견을 바탕으로 Flutter에 계속 기능을 추가해나갈 것입니다. Flutter는 처음부터 단지 모바일만이 아니라 모든 화면을 위한 UI 도구 키트였습니다. 우리는 표준 기반 웹에서 실행할 Flutter 코드를 컴파일할 수 있게 해주는 “Hummingbird”라는 코드명의 프로젝트를 살짝 엿볼 수 있는 기회를 드리는 외에도, Linux, Mac 또는 Windows를 실행하는 데스크톱 기기에서 Flutter를 지원하기 위해 진행 중인 작업의 미리보기를 시연하는 방식으로 이러한 기능을 보여드리기 시작했습니다. 이들은 실험적 프로젝트로, 얼른 개발자 여러분도 사용해보실 수 있도록 마무리하고 고견을 들을 수 있기를 고대하겠습니다. 앞으로 Flutter에 대해 많은 계획을 세워두었지만, 개발자가 지금 바로 사용해 볼 수 있도록 준비되어 있습니다. 무엇을 빌드하시겠습니까?

Mobile World Congress에서 Flutter 1.2 출시했습니다

2019년 5월 22일 수요일

.post-body span { white-space: normal !important; }

<블로그 원문은 이곳에서 확인하실 수 있습니다>

Flutter 팀은 바르셀로나에서 열리는 모바일 기술 업계 최대 규모의 연례 회의인 Mobile World Congress에서 라이브로 여러분을 찾아갑니다. 1년 전에 같은 행사에서 Flutter의 최초 베타 버전을 발표한 바 있으며, 그 이후로 Flutter는 우리의 상상을 훌쩍 뛰어넘어 급속히 성장했습니다. 그래서 최초로 선보이는 Flutter의 안정적 업데이트 릴리스로 올해 연례 행사를 기념하는 것이 적절해 보입니다.

Flutter 1.2 Flutter 1.2는 Flutter를 위해 최초로 기능이 업데이트된 버전입니다. 우리는 이번 릴리스를 준비하면서 다음과 같은 몇 가지 주요 영역에 주력했습니다.

코어 프레임워크의 안정성, 성능 및 품질 개선

시각적 마감 처리와 기존 위젯의 기능을 다듬는 작업

Flutter 애플리케이션를 빌드하는 개발자를 위한 새로운 웹 기반 도구

Flutter 1.0을 출시하던 당시에는 출시를 앞두고 마지막 두어 달 동안은 테스트 및 코드 인프라 개선, 끌어오기 요청의 백로그 정리, 전체 프레임워크의 성능 및 품질 개선에 상당한 에너지를 쏟아부었습니다. 우리는 구체적인 사항에 관심이 있는 분을 위해 Flutter 위키에 이러한 요청을 정리한 종합 목록을 올려두었습니다. 이 작업에는 스와힐리어와 같은 새로운 UI 언어를 위한 더욱 폭넓은 지원도 포함되었습니다.

우리는 Material의 더욱 유연한 사용을 지원하고 계속 iOS에서 픽셀의 완벽한 충실도를 추구하기 위해 Material 및 Cupertino 위젯 세트를 둘 다 계속해서 개선하겠습니다. 후자의 작업에는 부동 커서 텍스트 편집을 위한 지원은 물론이고, 사소한 세부 사항에 대해 계속 관심을 보이는 것까지 포함됩니다. 예를 들어 애니메이션 및 그리기 순서를 충실하게 표현하기 위해 iOS에서 텍스트 편집 커서가 그리는 방식을 업데이트했습니다. Robert Penner의 작업물에 영감을 받은 폭넓은 종류의 애니메이션 감속/가속 함수 집합을 위한 지원을 추가했습니다. 그리고 데스크톱 클래스의 운영체제를 위한 더욱 심층적인 지원을 준비하면서 새로운 키보드 이벤트 및 마우스 오버를 위한 지원도 추가했습니다.

플러그인 팀은 Flutter 1.2를 준비하면서 인앱 구매뿐 아니라 비디오 플레이어, 웹뷰 및 지도를 위한 수많은 버그 수정을 지원하기 위해 진행 중인 작업으로도 무척 바빴습니다. Intuit의 한 개발자가 제공한 끌어오기 요청 덕분에, 우리는 이제 앱 크기 감소에 도움이 되고 Android 앱을 위한 동적 제공과 같은 새로운 기능을 지원하는 새로운 패키징 형식인 Android App Bundle을 위한 지원도 제공합니다.

마지막으로, Flutter 1.2는 세트 초기화를 위한 새로운 언어 지원과 함께 컴파일된 코드의 성능을 상당히 개선해주는 업데이트인 Dart 2.2 SDK를 포함합니다. 이 작업에 대한 자세한 내용은 Dart 2.2 발표 내용을 읽어보세요.

(여담이지만, 이 릴리스의 번호를 왜 1.2로 표시하는지 궁금한 분들이 계실 겁니다. 우리의 목표는 대략 월별로 '베타' 채널에 1.x 릴리스를 제공하고 대략 분기마다 프로덕션 환경에서 사용할 준비가 완료된 '안정적인' 채널에 업데이트를 릴리스하는 것입니다. 지난달의 Flutter 1.1은 베타 릴리스였고, 따라서 1.2가 최초의 안정적 릴리스입니다.)
Flutter 개발자를 위한 새로운 도구 모바일 개발자는 다양한 배경을 가진 사람들로 구성되어 있고 종종 저마다 다른 프로그래밍 도구와 편집기를 선호합니다. Flutter는 명령줄에서 앱을 빌드하기 위한 지원뿐 아니라 Android Studio 및 Visual Studio Code를 위한 최고급 지원을 포함한 다양한 도구도 자체적으로 지원하므로, 우리는 디버깅 및 런타임 검사 도구를 노출하는 방식에 유연성이 필요하다는 점을 잘 알고 있었습니다.

Flutter 1.2와 함께 Flutter 개발자의 앱 디버그 및 분석 작업에 도움이 되는 새로운 웹 기반 프로그래밍 도구 세트를 미리 선보이게 되어 기쁩니다. 이들 도구는 현재 Visual Studio Code 및 Android Studio용 확장 프로그램 및 애드인과 함께 설치할 수 있는데, 다음과 같은 여러 가지 기능을 제공합니다.

위젯 검사기: Flutter가 렌더링을 위해 사용하는 트리 계층 구조의 시각화와 탐색을 지원합니다.

타임라인 뷰: 프레임 단위로 애플리케이션을 진단함으로써 앱에서 애니메이션 '버벅거림'의 원인이 될 수 있는 렌더링 및 계산 작업을 식별하는 데 도움이 됩니다.

완전 소스 레벨 디버거: 코드를 단계별로 진행하고 중단점을 설정하고 호출 스택을 조사할 수 있게 해줍니다.

로그 기록 뷰: 애플리케이션에서 로그하는 활동은 물론이고 네트워크, 프레임워크 및 가비지 컬렉션 이벤트도 표시합니다.

우리는 Flutter 개발자와 Dart 개발자 모두를 위해 이 새로운 웹 기반 도구에 더 많이 투자할 계획이며, 웹 기반 환경을 위한 통합이 개선됨에 따라 Visual Studio Code와 같은 도구에 이러한 서비스를 직접 빌드할 계획입니다.
Flutter의 다음 행보는? 우리는 Flutter 1.0을 출시한 후로 엔지니어링 작업 외에 2019년 로드맵 작성에도 공을 들였으므로, 앞으로도 우리가 할 일이 많다는 걸 아실 수 있을 것입니다.

2019년 크게 힘을 쏟을 부분은 Flutter를 모바일 플랫폼을 넘어서까지 성장시키는 것입니다. Flutter Live에서 우리는 'Hummingbird'라는 코드명을 붙인 프로젝트를 발표했는데, 이는 Flutter를 웹으로 가져오기 위한 프로젝트로서 앞으로 몇 개월 후에 기술적 프리뷰를 공유할 계획입니다. 또한 Flutter를 데스크톱 클래스의 기기에 적용하는 작업도 계속 진행할 것이며, 이를 위해서는 위에서 설명한 대로 프레임워크 수준에서 작업하는 능력뿐 아니라, 우리가 Flutter Desktop Embedding 프로젝트를 통해 투자하고 있는, Windows 및 Mac과 같은 운영체제를 위한 애플리케이션을 패키지로 제공하고 배포하는 능력도 필요합니다.
Flutter Create: 5KB 분량의 Dart로 무엇을 할 수 있을까요? 이번 주에는 5KB 이하의 Dart 코드를 사용하여 Flutter로 흥미롭고 영감을 주며 아름다운 앱을 빌드하는 실력을 겨루는 콘테스트인 Flutter Create도 시작되므로 더욱 설렙니다. 5KB는 많은 양이 아닙니다. 일반적인 MP3 파일의 경우 5KB는 대략 1/3초 정도의 음악 데이터 분량에 불과합니다. 하지만 Flutter에서는 이처럼 적은 양의 코드로 우리 모두를 깜짝 놀라게 만들 수 있는 멋진 작품을 얼마든지 만들어낼 수 있다고 장담합니다.

이 콘테스트는 4월 7일까지 계속되므로 멋진 작품을 만들 시간이 몇 주 정도 있으니 도전해보세요. 1만 달러 상당의 가치가 있는 14-코어 프로세서, 128GB 메모리를 탑재하고 완벽한 기능을 갖춘 iMac Pro 개발자용 워크스테이션을 비롯한 엄청난 상품을 준비해놓고 개발자 여러분의 도전을 기다리겠습니다! 여러 가지 Flutter 관련 강연, 코드랩 및 활동 프로그램을 구성할 Google I/O에서 이번 콘테스트의 수상자를 발표하겠습니다.
맺음말

Flutter는 현재 Github에서 20대 소프트웨어 저장소 중 하나로, 매달 전 세계 커뮤니티의 규모가 쑥쑥 커지고 있습니다. 인도 첸나이에서 열리는 모임, 나이지리아 포트하커트에서 송고되는 기사, 덴마크 코펜하겐에서 개발되는 앱, 미국 뉴욕시의 인큐베이션 스튜디오 등등, 개발자 여러분 덕분에 Flutter는 도도한 세계적 조류를 만들어내며 계속 성장하고 있음이 분명합니다. 수억 명의 사용자를 가진 앱과 최초의 아이디어를 시장에 상품으로 선보이는 기업가가 내놓는 앱에서 Flutter를 보실 수 있습니다. 개발자 여러분이 품고 계신 다양한 아이디어를 확인하는 건 정말 흥분되는 일이며, 우리가 Flutter로 그런 멋진 아이디어를 표현하시는 데 도움이 될 수 있기를 바랍니다.

SRM 대학교 Technozzare에서 열린 Flutter 딥 다이브(deep dive) 행사 참석자

마지막으로, 우리는 최근에 Flutter 전용 YouTube 채널을 시작했습니다. 꼭 flutter.dev/youtube에서 구독 신청하시고 Boring Flutter Development Show, Widget of the Week, Flutter in Focus 등을 시청하시기 바랍니다. 인기 많은 인도 판타지 스포츠 사이트 Dream11에서 소개하는 새로운 우수사례뿐 아니라 다른 개발자 스토리도 찾아보실 수 있습니다. 그곳에서 뵙겠습니다!

TensorFlow 2.0에서 기호형 API와 명령형 API란?

AMPproject.org가 amp.dev로 이전합니다!

Flutter 1.0 출시 요약 뉴스

Mobile World Congress에서 Flutter 1.2 출시했습니다

Contents

검색

Tag

Archive

Feed