Bloter 오픈AI, 아이폰 디자이너 조니 아이브 스타트업 인수 AI 기기 개발 본격화

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '세트 할인'입니다.디버깅용 데이터를 시간 순서대로 기록하는 클래스인 를 만든다고 가정해 봅시다. 이 클래스는 로 전달된 데이터를 기록하는데 이때 에 따라 필터링하고 속성을 이용해 지정된 간격으로 샘플링합니다.에 전달된 데이터는 다음 세 가지 조건이 충족될 때 기록됩니다.• 인수의 가 이상• 의 호출이 * n번째(n은 양의 정수)여기서 , , 의 세 가지 속성은 디버깅 UI에서 변경할 수 있도록 재할당이 가능하다는 필수 제약 조건이 있다고 가정합니다.이 에 개선해야 할 점이 있을까요?개별 변경은 비용이 많이 든다, , , 이 세 가지는 독립적으로 변경할 수 있기 때문에 혼란을 초래할 수 있습니다. 이런 속성은 하나의 클래스로 묶어 한 번에 업데이트하도록 하면 동작을 단순화할 수 있습니다.위 코드에서 혼동하기 쉬운 부분은 다음과 같습니다.• 를 에서 로 변경할 때 이전 및 값이 사용될 수 있다.• 나 을 변경하고 를 로 설정해야 하는데 실수로 를 먼저 변경하면 이전 및 값을 사용하게 된다.• 는 이 변경될 때에는 재설정되지만, 또는 가 변경될 때에는 재설정되지 않는다.• 속성 설정자(property setter)가 비 동기 방식으로 호출될 경우 단일 스레드 환경일지라도 경쟁 상태에 주의해야 한다.위 문제를 해결하려면 와 을 하나의 클래스인 로 묶고 는 로 표현하면 됩니다.위 코드는 다음과 같은 장점이 있습니다.• 과 가 항상 함께 업데이트되도록 보장한다.• 기록을 재개할 때 의도치 않게 이전 정책이 사용되는 버그를 방지할 수 있다.• 가 재설정되는 조건이 명확하다.• 비동기 업데이트 처리가 쉬워지고, 해당 클래스를 스레드 안전(thread-safe)하게 만들고 싶은 경우에 변경 부분을 제한할 수 있다.상태를 변경할 때 개별 속성을 직접 변경하게 만드는 것보다 변경을 제한하는 인터페이스를 만드는 게 더 좋은 경우가 있습니다. 각 속성이 서로 독립적이지 않아서 속성 중 하나의 값이 결정되면 그것이 다른 속성의 값에 영향을 미치거나(참고: Code readability: Session 4 의 슬라이드 15-32) 또는 여러 속성을 한 번에 변경해야 할 경우에 특히 유용합니다.

빠르게 쌓이는 PR, 느리게 달리는 리뷰. 결국 남는 건 LGTM(Looks Good To Me)뿐이라면?이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요. ‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지 실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!• None 01:40 코드 리뷰, 왜 필요한가요?• None 11:20 좋은 코드의 4가지 기준!Frontend Fundamentals ; 변경하기 쉬운 프론트엔드 코드를 위한 지침서 👉바로가기: https://frontend-fundamentals.com다른 모닥불 회차 보러가기 EP.10 캠프파이어 특집 상편 | 무엇이든 물어보세요 (feat. 프론트엔드 코드, 디렉토리 관리) EP.10 캠프파이어 특집 하편 | 무엇이든 물어보세요 (feat. 테스트 코드, ESLint Rule) EP.11 토스의 디자인 편집기 ‘데우스’, 이렇게 만들었어요!

"이 Task는 예전 코드로 실행됐던 거였나?"Airflow를 운영하다 보면 한 번쯤은 이런 고민을 해보신 경험이 있으실 겁니다.지난 달 말에 출시된 Airflow 3.0 버전에서 DAG Versioning 기능이 도입되었습니다 ㅎㅎ 🎉이제 Airflow UI 상에서 DAG의 변경 이력을 추적하고, 각 task가 어떤 DAG 버전으로 실행되었는지 확인할 수 있게 되었습니다.이 글에서는 DAG Versioning이 무엇인지, 왜 중요한지, 그리고 어떻게 사용하는지를 정리해 보려고 합니다.앞으로 DAG 관리를 훨씬 체계적으로 관리할 수 있으실 거예요!Airflow 2.x까지는 DAG 실행과 UI 모두 항상 로컬의 최신 DAG 코드를 기준으로 작동했습니다.이로 인해 다음과 같은 두 가지 문제점이 발생하곤 했습니다:• None DAG 수정 시, 삭제된 태스크가 Airflow UI에서 사라짐• None DAG 실행 중 코드가 바뀌면, 일부 태스크는 이전 코드, 나머지는 수정된 코드로 실행됨이러한 문제를 해결하기 위해, Airflow 3.x 버전에서는 DAG Bundles와 DAG Versioning 이 도입되었습니다.Airflow 3.x 에서는 기존의 폴더에 파일을 두는 구조 대신, DAG 코드를 하나의 단위로 묶는 이라는 개념이 도입되었습니다.DAG Bundle에는 두가지 종류가 있습니다.DAG Bundle 구조 덕분에 Airflow는 DAG 실행 시 해당 시점의 DAG 코드 상태를 버전(v1, v2, ...)으로 고정할 수 있게 되었습니다.실습으로 알아보는 DAG Versioning이제 직접 실습을 통해 DAG Versioning을 어떻게 사용하는지 알아보겠습니다.Airflow 3.x 환경이 이미 구성되어 있다면 바로 사용해보실 수 있지만, 이 글에서는 더 간편한 방법으로 Astro CLI를 활용하겠습니다.Astro CLI 설치와 사용법은 아래의 공식 문서와 글을 통해서 알아보실 수 있습니다.Astro CLI의 버전이 이라면 Airflow 3 버전을 지원하므로 이 글의 내용을 그대로 따라 하실 수 있습니다.만약 버전이 더 낮다면, 최신 버전으로 업그레이드해 주세요.이제 실습을 위한 예제 프로젝트를 포크하고 클론해줍니다.간단한 라는 이름의 DAG를 작성해보았습니다.이 상태에서 명령어로 Airflow를 실행하면에서 Airflow 3의 새 UI를 볼 수 있어요.왼쪽 사이드바의 Dags를 통해서 현재 DAG들을 볼 수 있는데요.저희가 만든 DAG가 있는 것을 확인할 수 있습니다.DAG를 선택해서 보면, 자세한 DAG에 대한 정보를 볼 수 있습니다.DAG의 버전과 관련된 내용은 우측 상단의 Latest Dag Version을 통해서 확인할 수 있습니다.현재 버전은 v1버전으로 되어있는 것을 볼 수 있습니다.DAG버전은 Trigger를 기점으로 지정이 되므로 Trigger를 해봅시다.이렇게 DAG가 한 번 실행되면 v1으로 고정됩니다.그럼 DAG를 수정을 해봅시다. 아래의 코드 처럼 task_3을 추가했습니다.변경 후 저장하고 UI에서 다시 DAG를 Trigger하면,이제 새로운 실행은 v2로 관리됩니다.그래프 뷰에서 각 버전별로 task가 어떻게 구성되어있는지도 확인가능합니다.앞선 설명에서 LocalDagBundle은 버전관리가 안된다고 했었는데, v1, v2로 잘되는 것으로 보입니다.하지만 이는 UI상에서만 DAG가 수정되었다는 사실만 확인이 가능한 것입니다.간단하게 이 사실을 확인가능 한 것이 v1으로 실행된 DAG를 재실행하면 아래와 같이 최신 DAG코드로 실행이 된 것을 확인할 수 있습니다.LocalDagBundle와 GitDagBundle을 비교하면 아래와 같습니다.그래서 LocalDagBundle은 개발환경에서는 적합하지만, DAG의 버전 관리가 되지 않는다고 볼 수 있습니다.예를 들어 v1 실행을 다시 Run하면 v2 코드가 사용되는 등, 버전 고정이 되지 않습니다.앞서 설명한 LocalDagBundle은 버전을 만들 수는 있지만, 관리할 수는 없습니다.버전을 관리하기 위해서는 GitDagBundle을 사용해야하는데요.• None 에 를 추가해줍니다.provider의 최신버전은 아래의 링크에서 확인하실 수 있습니다.• None 에도 git을 추가해줍니다.• None GitHub에서 Personal Access Token을 발급받고, 에 host부분에는 저장소의 레포지토리 주소와 password부분에는 발급받은 토큰을 설정해줍니다.깔끔하게 정리하고 싶다면, 아래의 명령어로 컨테이너를 지우고 다시 시작해줍니다.그럼 아래와 같이 Git 저장소에서 DAG를 불러오고, DAG를 트리거하면 버전으로 실행되는 것을 확인할 수 있습니다.그럼 DAG를 수정해봅시다. 이번에는 이전에 추가했던 task_3를 삭제해보겠습니다.수정하고 trigger를 해봅니다.task_3를 삭제했는데 task_3가 실행되는 것을 확인해볼 수 있습니다.이는 DAG를 깃허브 저장소에서 가져오기 때문입니다. 반드시 Git에 커밋되어야 새로운 버전이 적용됩니다.커밋을 하고 다시 trigger해줍니다.task_3가 사라지고 버전이 v2로 고정된 것을 확인할 수 있습니다.그리드 뷰에서도 버전을 잘 확인할 수 있습니다.그리고 task_3를 다시 돌려놓고 다시 커밋을 하면 v3로 정상적으로 버전이 잘 올라가는 것을 확인할 수 있습니다.그럼 지금 task_3가 없었던 v2 DAG를 트리거 할 수 있는지 볼까요?DAG를 Clear Run을 해봅시다.정상적으로 잘 되는 것을 확인할 수 있습니다.정상적으로 잘 실행되는 것을 확인 할 수 있습니다.DAG Versioning의 진가를 느낄 수 있는 부분은 바로 각 DAG run에서 정확히 어떤 코드가 사용되었는지 확인할 수 있다는 점입니다.각 DAG run의 Detail 을 확인해보면 DAG의 버전에 어떤 Bundle에 대한 자세한 설명과 어떤 코드가 사용되었는지 확인해볼 수 있습니다.Airflow 3.x에 도입된 DAG Versioning 기능은 정말 반가운 변화입니다.이제는 “어..? 이거 코드 바뀌기 전이었나?” 같은 고민 없이,정확히 어떤 DAG 코드로 실행되었는지 추적할 수

Bloter 구글, AI 구독 서비스 도입 최신 기능 사용할 수 있는 VIP패스

안녕하세요. 저희 AMD(Applied ML Dev) 팀에서는 생성형 AI를 포함한 다양한 AI/ML 모델을 개발하고 서비스에 적용하고 있습니다.앞서 발행한 AI로 생성한 이미지는 어떻게 평가할까요? (기본편)에서는 생성형 AI 모델의 성능을 평가하는 다양한 방법론을 살펴봤는데요. 이번에는 생성형 AI을 활용한 몇 가지 애플리케이션을 소개하면서, 이와 같은 애플리케이션의 성능을 향상시키기 위해 생성형 AI 평가 방법을 어떻게 활용하고 있는지 공유하고자 합니다.사진 속에서 주인공을 제외한 배경 인물을 AI로 제거하는 방법여행지에서 멋진 풍경을 배경으로 사진을 찍었는데 예상치 못한 인물들이 같이 찍혀 있어서 사진을 여러 번 다시 찍어야 했던 경험이 있으신가요? 이런 불편함을 해소하는 데 생성형 이미지 AI 기술을 활용할 수 있습니다.다음은 생성형 이미지 AI 기술을 활용해 배경 인물을 제거한 결과입니다.* 이미지를 우클릭해서 새로운 탭이나 창에서 열면 이미지를 원본 크기로 확인하실 수 있습니다.배경 인물 제거(background person removal, 이하 BPR)는 다음과 같은 과정으로 진행됩니다.위 과정은 크게 세 단계로 나눌 수 있습니다.• 인스턴스 분할(instance segmentation)• 입력 이미지 내 각 픽셀이 어떤 객체에 속하는지 식별하는 과정으로, 인스턴스 분할 모델을 활용해 사람이나 건물, 나무 등 다양한 객체를 구분하고 개별적으로 인식합니다.• 주요 객체 탐지(saliency object detection)• 이미지에서 가장 눈에 띄는 주요 객체를 식별하는 과정으로, 주요 객체 탐지 모델을 이용해 시선이 집중되는 영역을 픽셀 단위로 추출함으로써 메인 피사체와 배경 인물을 구분할 수 있습니다.• 인페인팅(inpainting) 수행• 주요 영역에 속하지 않는 배경 인물들이 포함된 영역을 인페인팅 기술을 사용해 자연스럽게 제거하고 복원하는 과정입니다.• 여기서 '인페인팅'이란 이미지의 특정 부분을 삭제한 후 주변 환경과 조화를 이루도록 재구성하는 기술입니다.여기서 마지막 단계인 인페인팅 수행 단계는 배경 인물 제거 결과에 가장 큰 영향을 주는 단계이기 때문에 성능이 좋은 인페인팅 모델을 사용해야 합니다. 최근에는 생성형 이미지 모델을 이용한 인페인팅 기술이 많이 발표되고 있는데요. 인페이팅 기술에 대해서 조금 더 깊이 살펴보겠습니다.인페인팅 기술은 이미지의 특정 영역을 제거하고 그 빈자리를 자연스럽게 채워 넣는 기술입니다. 예를 들어 사진 속 인물이나 물체를 삭제한 후 그 공간을 주변 환경과 조화롭게 재구성해 채워 넣는 작업에 활용할 수 있습니다.인페인팅 모델은 생성형 AI의 한 종류로, 이미지의 결손 부분을 채우는 데 특화된 모델이라고 할 수 있습니다. 접근 방식에 따라서 크게 두 가지 주요 모델 로 나눌 수 있는데요. 디퓨전(diffusion) 계열 모델과 GAN(generative adversarial network) 계열 모델로 나뉩니다.이 두 가지 접근 방식은 각각 고유한 메커니즘과 장점을 가지고 있으며, 이미지 복원 작업에서 서로 다른 방식으로 활용됩니다. 하나씩 간략히 살펴보겠습니다.• 디퓨전 계열 모델• 이미지를 점진적으로 변화시켜 손상된 영역을 복원하는 방법입니다.• 보통 이미지의 노이즈를 제거하거나 점진적으로 이미지를 개선하는 방식으로 작동합니다. 예를 들어 랜덤 노이즈인 초기 상태에서 노이즈를 점차 줄여가며 원본 이미지의 형태를 찾아가는 과정으로 진행됩니다.• 복잡한 이미지의 세부 사항을 자연스럽게 복원하는 데 특히 유리합니다.• 다만, 좋은 결과가 나올 때도 있지만 가끔 이상한 물체가 생성되기도 합니다.• 이미지 생성을 위해 반복적으로 노이즈 제거 과정을 거치기 때문에 일반적으로 GAN 계열 모델에 비해 이미지 생성 속도가 느립니다.• 디퓨전 계열 모델에 대한 보다 자세한 설명은 먼저 발행된 AI로 생성한 이미지는 어떻게 평가할까요? (블랙박스 최적화 적용편)을 참고하시기 바랍니다.• GAN 계열 모델• GAN 모델은 생성자(generator)와 판별자(discriminator)라는 두 개의 신경망이 경쟁하면서 학습하는 구조입니다.• 생성자는 결손된 이미지를 복원하려 시도하고, 판별자는 생성된 이미지가 실제 이미지와 얼마나 유사한지를 평가합니다. 이 과정을 반복하면서 점점 더 정교하고 사실적인 이미지를 생성합니다.저희는 BPR 애플리케이션에 다 음과 같은 다양한 인페인팅 모델을 적용해 봤는데요. 원본 이미지의 해상도가 낮거나 인페인팅해야 하는 영역이 작은 경우에는 대부분의 모델에서 좋은 결과가 나왔지만, 원본 이미지의 해상도가 높고 인페인팅해야 하는 영역이 큰 경우에는 모델에 따라 큰 차이가 발생했습니다.먼저 다음은 어떤 인페인팅 모델을 사용하든 좋은 결과가 나온 경우입니다.* 이미지를 우클릭해서 새로운 탭이나 창에서 열면 이미지를 원본 크기로 확인하실 수 있습니다.다음은 사용한 인페인팅 모델에 따라 결과에 큰 차이가 발생한 경우입니다.* 이미지를 우클릭해서 새로운 탭이나 창에서 열면 이미지를 원본 크기로 확인하실 수 있습니다.위 테스트 결과로 알 수 있듯 사용할 모델을 선정할 때 논문에서 제시하는 성능 지표만 보고 판단하는 것은 어렵습니다. 각 모델이 실제 응용 사례에서 어떤 성능을 보여줄지 명확히 파악하기 어렵기 때문입니다.일반적으로 논문에서는 정해진 해상도(예: 256x256)에서 평가를 진행합니다. 이는 실제 사용 환경과는 다를 수 있습니다. 또한 논문마다 평가에 사용한 인페인팅 영역이 다르며, 대부분 실제로 우리가 직면하는 현장과는 다른 상황에서 평가가 진행됩니다. 게다가 인페인팅은 이미지 생성 모델의 일종이므로 어떤 정답이란 것이 존재하지 않습니다. 다양한 형태로 생성된 이미지 모두가 정답이 될 수 있으며, 이는 평가를 더욱 복잡하게 만듭니다.따라서 모델의 실제 성능을 평가할 때는 다양한 요소를 고려해야 합니다. 논문에 제시된 지표들이 어느 정도 대략적인 성능의 경향을 보여줄 수는 있지만, BPR 작업에서 발현될 정확한 인페인팅 성능을 대변하지는 못합니다. 예를 들어 어떤 테스트에서는 좋은 결과를 보여준 모델이 다른