연구 배경 AnomalyCLIP + Learnable Attention Head Weight Pixel-level AD 기준 정량적, 정성적인 차원에서 성능 개선을 위해 두 논문의 이론을 활용함 AnomalyCLIP : Object-agnostic Prompt Learning for Zero-shot Anomaly Detection. (ICLR 2024) Interpreting CLIP’s Image Representation via Text-Based Decomposition (ICLR 2024) 다양한 도메인에서 우수한 ZSAD(Zero-Shot Anomaly Detection) 성능을 보이는 AnomalyCLIP에 대한 연구와 ViT 내 attention head 마다 집중하는 이미지 요소가 다르다는 연구에서 얻은 아이디어를 기반으로 최종 patch representation 생성시 Industrial Anomaly Detection에 악영향을 끼치는 요소에 집중하는 head…

Abstract 본 문서는 Multi-Domain Recommendation(MDR) 문제 해결을 위해 기존 Cross-Domain Recommendation(CDR) 관련 연구들과 최신의 MDR 연구를 살펴보고 현업에 적용하기 위한 연구 방향을 제안합니다. 최근 연구된 UniSRec, UniCDR, MDRAU 세 개의 모델을 살펴보면서 MDR 연구의 큰 흐름을 이해합니다. 최근의 연구들은 사용자 행동 기준으로 도메인을 seen과 unseen을 기준으로 source domain과 target domain으로 구분하며, Sequence 기반의 user, item 데이터를 고전적인 방식의 id 기반이 아닌 text representation를 사용해서 더 많은 정보를 사용합니다. 모델링의 경우 더 긴 text를 인코딩하기 위한 개선된 transformer를 사용하고 contrastive model과 transfer model을 채택합니다. 대조학습의 성능 개선을 위한 masking m…

Evaluation Metrics 회귀(Regression) 결정계수(Coefficient of Determination or R-squared Score)를 주로 사용 1에 가까울수록 모델의 설명력이 높고, 0에 가까우면 설명력이 낮음. 음수가 나올 수 있음 MAE, MSE, RMSE, MAPE는 값이 작을수록 모델의 예측이 실제에 가깝다는 의미 분류(Classification) 모델이 예측한 값과 실제 값을 비교해, 얼마나 정확히 분류했는지 어떤 오류가 발생했는지 보여줌 혼동 행렬(Confusion Matrix) 구성 TP (True Positive): 실제 Positive를 Positive로 맞게 예측 TN (True Negative): 실제 Negative를 Negative로 맞게 예측 FP (False Positive): 실제 Negative를 Positive로 잘못 예측 (오류) FN (False Negative): 실제 Positive를 Negative로 잘못 예측 …

To OO님, 주니어, 시니어를 거쳐 언젠가는 조직의 리드 엔지니어가 될테니 리드 엔지니어의 역할과 중요하게 여겨야 할 것들에 대해 얘기해 줄게. 리드 엔지니어의 역할 리드 엔지니어의 역할은 크게 3가지로 요약할 수 있어. 기술 리드 조직의 미션 기반으로 엔지니어링 팀의 기술 목표를 세우고 효율적인 목표 달성을 위해 로드맵을 수립합니다. 조직의 기술 스택을 결정하고 적용하는 과정을 리드합니다. 프로덕트 아키텍처를 만들고 발전시켜야 합니다. 기술 코치 팀이 기술적으로 성장할 수 있는 환경을 만들고 적극적으로 코치해야 합니다. 팀의 기술적 목표를 높게 유지할 수 있도록 해야 합니다. 일하는 방식에 대해서도 팀원이 우선순위 기반으로 자신의 일정을 계획하며 관리할 수 있게 코치해야 합니다. 팀 매니징 조직의 방향성과 비전을 엔지니어들에게 이해시키고 같은 방향을 바라보게 개선합니다. 인재의 채용과 유지 팀에 맞는 최적의 엔지니어를 찾기 위해 노력합니다. 인재들을 주기적으로 면담하여 문제가 …

To OO님, 풀스택을 해야하는가에 대한 고민 잘 읽었어. 엔지니어 성장과 프로덕트 두 가지 관점에서 풀스택을 지향하는 것은 당연하다고 생각해. 엔지니어는 기술을 사용하여 문제를 해결한다고 정의했지? 엔지니어가 성장한다는 것은 점점 더 효율적(더 빠르고 정학하게)으로 문제를 해결할 수 있게 되는 것을 의미해. 특히, 프로덕트 관점에서 문제 해결을 하려면 여러 해결 방법들에 대해 가장 빠른지 또는 효율적인지를 판단하기 위해 여러 기술을 알아야 필요가 있어. 이러한 이유들로 결국 영향력 있는 엔지니어가 되려면 풀스택을 해야 하는데 그 이유를 자세히 설명해 줄게. 효율적인 문제 해결을 위해 예를 들어, 앱의 로딩시간이 길어 사용자가 이탈한다는 문제를 해결하기 위해 담당 엔지니어들이 해결 방법과 필요한 일정을 제안했어. 백엔드 : API 성능 개선 / 3일 iOS : 로딩 상태 애니메이션 인디케이터를 추가 / 1일 AOS : 로컬 캐시를 이용해서 api 호출을 줄임 / 2일 과연 어떤 해…

To OO님, 번아웃이 온 것 같아서 걱정이 크다는 메일을 보니 예전의 내가 떠오르며 남일 같지 않더라. 나는 대략 3년 정도에 한 번씩 번아웃이 왔었거든. 어떻게 해결했냐고? 백엔드에서 iOS로 직군을 바꿔보기도 했고 이직을 통해 새로운 곳에서 환경과 업무에 변화를 주기도 했었어. 번아웃이 여러 이유가 있겠지만 가장 큰 이유는 현재 상황에 대한 불만이 개선되지 않는 상태에서 계속 업무를 해야하는 상황일 때 온다고 생각해. 경험상 엔지니어들은 아래 상황들이 지속될 때 번아웃이 오더라고. 기술의 변화를 줄 수 없는 레거시 환경에서의 업무 코드 리팩토링과 성능 개선을 못하고 계속 새로운 기능만 구현해서 기술부채에 대한 부담 업무의 중요도와 내가 생각하는 중요도가 일치하지 않는 상황 일정에 대해 주도권이 없어 엔지니어 의견과는 상관없이 결정되고 그 일정을 반드시 지켜야하는 상황 문제의 해결 방법이나 사용하고 싶은 기술 스택이 조직의 방향과 맞지 않은 상태 자, 그럼 번아웃이 오면 어떻게…

To OO님, 드디어 원하는 곳에서 엔지니어로 커리어를 시작했구나! 새로운 곳에서 시작을 축하해! 게다가 벌써 업무에 투입되서 첫 배포까지 했다니 대단하다. 이번 메일에서 일정으로 인해 고민하고 부담을 갖기 시작한 것을 보니 엔지니어로서 본격적으로 커리어를 시작했구나란 생각이 들어. 사실 경험 많은 시니어도 일정을 지키는 것은 어렵긴 마찬가지거든. 왜 항상 예측보다 시간이 오래 걸리는 이유? ‘애자일 조직혁명’의 저자 ‘스리람 나자얀’은 소프트웨어 개발이 항상 예측보다 시간이 오래 걸릴 수 밖에 없는 이유에 대해 소프트웨어 개발은 생산 공정이 아닌 디자인 공정이기 때문이라고 얘기했어. 소프트웨어 개발이 왜 항상 예측보다 시간이 오래 걸리는 이유? 진행하고 나서야 그 필요성을 깨닫게 되는 것들이 있음 아무리 예측을 잘하더라도 파악할 수 없는 무지(Unknown unknowns)를 비켜나갈 수 없다. 예상조차 하지 않은 일을 대비할 방도란 없기 때문이다. 그러므로 소스코드는 제품이 아…