Slowly but Surely

[세상 모든 이슈] 메타 2025 Q3 실적 발표

WithSeungRyu — Fri, 31 Oct 2025 10:20:55 +0900

1. 실적 요약 & 주요 수치

2025년 9월 30일 마감 3분기의 매출은 미국 51.24 십억 달러로 전년 대비 약 26% 증가했습니다.
순이익(회계기준, GAAP)은 미국 2.71 십억 달러, 주당순이익(EPS)은 US$1.05로 대폭 하락했습니다. 이는 약 US$15.93 십억 달러의 일-회성 세금 충당금이 반영되었기 때문입니다.
세금 충당금을 제외한 비-GAAP 기준 순이익은 US$18.64 십억 달러, 조정 EPS는 US$7.25로 발표됐습니다.
광고 관련 수익이 강세를 보였습니다. 광고 게재수가 전년 대비 약 14% 증가했고, 광고 단가도 약 10% 상승했습니다.
비용 및 지출 측면에서, 연구개발 및 일반관리비 등이 크게 증가했으며, 2025년 연간 자본지출(Capex)은 US$70-72 십억 달러로 상향 조정되었습니다.

2. 시장 반응 & 애널리스트 의견 변화

주가 반응

실적 발표 직후 META 주가는 약 11% 이상 폭락했으며, 이는 미국 기업 역사상 단일 일 낙폭 상위권에 속했습니다. 마켓워치+1
특히, 이번 주가 급락에는 “막대한 AI 인프라 투자에 대한 시장의 우려”가 큰 영향을 미쳤습니다. Reuters

애널리스트 의견 변화

일부 애널리스트들은 META에 대해 투자의견을 하향 조정했습니다. 예컨대 Oppenheimer & Co.는 ‘Outperform’에서 ‘Perform’으로 낮췄고, 과도한 자본지출(Capex) 및 AI 사업의 수익화 불확실성을 주된 이유로 들었습니다. The Economic Times+1
반면, 장기 관점에서 META의 구조적 성장 가능성을 긍정하는 의견도 존재합니다. Seeking Alpha

요약

번호팩터시장/애널리스트 반응

1	매출 성장	긍정적 (광고 수익 증가)
2	순이익 급감	부정적 (세금 충당금 + 비용 증가)
3	자본지출 확대	우려 스파크
4	애널리스트 의견	일부 하향 → 장기 긍정 유지

3. 향후 전략 & 기술 흐름

기술 전략 하이라이트

META는 AI 인프라 강화, 슈퍼컴퓨터 구축, AI 모델 개발 등에 강력히 집중하고 있으며, CEO Mark Zuckerberg는 “Meta Superintelligence Labs”라는 구체적인 이름을 언급했습니다.
AI 추천 알고리즘 개선을 통해 플랫폼 내 사용자 참여 시간이 증가하고 있는 점이 특징입니다. 예컨대 Threads에서 참여시간이 전년 대비 약 10% 증가했다는 발표가 나왔습니다.
가상현실(VR) 및 증강현실(AR) 사업을 담당하는 ‘Reality Labs’ 부문은 여전히 적자를 지속하고 있지만, META는 이 영역을 미래 핵심 사업으로 보고 있습니다.

향후 흐름 전망

META는 2025년 4분기 매출을 US$56-59 십억 달러로 안내했으며, 광고 수익 증가가 주요 성장 동력으로 예상됩니다.
그러나 2026년에는 Capex가 더욱 증가할 가능성이 높으며, 이에 따른 수익화 시점에 대한 불확실성도 존재합니다.
따라서 투자자는 META를 ‘단기 실적 트리거’보다는 ‘중장기 구조적 변화의 주체’로 접근하는 것이 보다 적합하다고 볼 수 있습니다.
또한 AIㆍ광고 플랫폼ㆍAR/VR 등 사업 다각화가 진행 중이므로, 이와 연관된 생태계 기업(반도체, 데이터센터, 클라우드 등)에도 관심을 둘 만합니다.

4. 주식 투자자 관점에서의 생각

저는 IT와 주식 투자를 좋아하는 사람으로서 다음과 같은 관점을 갖고 있습니다.

META는 매출 성장이 여전히 견조하고 AI 기반 광고 효율이 개선되고 있다는 점에서 긍정적입니다.
반면, 이번 실적 발표에서 드러난 순이익 급감 + 대규모 자본지출 확대는 경계해야 할 요소입니다. 특히, 시장은 ‘투자 대비 수익화’ 시점을 중요하게 보고 있습니다.
따라서 투자 전략으로는 다음과 같이 접근할 수 있다고 생각합니다:
- 중장기 관점에서 META의 AI 사업이 본격화될 가능성에 베팅하되,
- 단기적으로는 자본지출 증가가 실적에 어떤 영향을 주는지를 면밀히 모니터링하고,
- 투자 비중을 조절하며 리스크 관리(예: 일부 청산, 손절선 설정) 병행.
또한, META 단독보다는 META 생태계(광고·AI칩·데이터센터 등) 포지션을 함께 보는 것이 더 전략적일 수 있습니다.

✍️ 마무리

META의 이번 3분기 실적은 표면적으로는 매출·사용자 수 증가라는 긍정적인 흐름을 보여주었으나, 수익성 악화와 투자 확대라는 그림자도 분명히 있었습니다.
IT/AI 시대의 중심에 서 있는 기업인 만큼 장기적으로는 매력적이지만, ‘투자 대비 수익 실현’이라는 확인이 이루어지기 전까지는 신중한 접근이 필요하다고 생각합니다.
지금은 META가 도약을 준비하는 시점이며, 투자자 입장에서는 “미래에 대한 베팅”을 고려하되 “지금의 비용 구조와 리스크”를 간과하지 않아야 할 때라고 봅니다.

[세상 모든 이슈] 젠슨 황·이재용·정의선 회동

WithSeungRyu — Fri, 31 Oct 2025 10:08:02 +0900

깐부치킨에서 벌어진 ‘치맥 회동’

10월 30일 저녁 7시 30분경,
서울 강남 삼성동 깐부치킨 매장에는 세 명의 글로벌 톱 리더가 등장했습니다.
젠슨 황 CEO는 이재용, 정의선 회장을 만나며 직접 선물 상자를 전달했는데,
그 안에는 일본산 위스키 ‘하쿠슈’, 그리고 AI 슈퍼컴퓨터 관련 장비가 포함된 것으로 전해졌습니다.

세 사람은 편안한 평상복 차림으로 등장해
치킨과 맥주, 소주를 곁들이며 격식 없이 대화를 나눴고,
현장에서는 젠슨 황이 직접 라이브 방송을 진행하며 즐거운 분위기를 연출하기도 했습니다.

출처: 더벨, 뉴데일리, 뉴스스페이스 등 국내 주요 경제지 보도 (2025.10.31 기준)

단순한 식사 이상의 의미

1️⃣ 반도체 + AI = 삼성 × 엔비디아

엔비디아는 세계 AI 반도체 시장을 주도하는 기업으로,
현재 삼성전자와 HBM(고대역폭 메모리), 2nm 이하 첨단 공정,
고성능 패키징 관련 협력 가능성이 꾸준히 제기되고 있습니다.

이번 만남은 AI 칩 생산 및 패키징 협업에 대한 신호로 해석되며,
삼성전자가 글로벌 AI 공급망의 ‘핵심 허리’로 자리 잡을 수 있는 계기가 될 수 있습니다.

2️⃣ 자율주행 + 로봇 = 현대차 × 엔비디아

현대자동차그룹은 최근 자율주행, 로보틱스, UAM(도심항공모빌리티) 등
AI 기반의 미래 모빌리티 사업에 집중하고 있습니다.

엔비디아의 AI 컴퓨팅 플랫폼과 현대차의 차량 기술이 결합된다면,
‘AI 중심 차량(SDV: Software Defined Vehicle)’ 시대의 본격 개막이 가능해집니다.

이번 회동은 단순한 식사가 아닌,
“자동차 × AI × 반도체”라는 미래 산업 삼각동맹의 출발점이 될 것으로 보입니다.

3️⃣ 한국의 AI 산업 생태계 도약

한국은 반도체 제조 강국으로서 이미 글로벌 시장에서 중요한 역할을 하고 있지만,
이번 회동을 계기로 ‘AI 기술·생산·응용’까지 아우르는 AI 허브국가로 성장할 가능성이 커졌습니다.

삼성의 반도체, 현대차의 모빌리티, 엔비디아의 AI가 결합한다면
한국은 미국·중국 중심의 AI 패권 경쟁 속 새로운 균형축이 될 수 있습니다.

핵심 요약

구분핵심 내용

장소	서울 강남 깐부치킨
시점	2025년 10월 30일 저녁
참석자	젠슨 황(엔비디아), 이재용(삼성전자), 정의선(현대자동차)
주요 화두	반도체 협력, AI 칩, 자율주행, 미래 모빌리티
의미	한국의 AI·반도체·자동차 삼각 동맹 시그널

IT·주식 투자 관점에서 본 이번 회동

IT와 주식투자를 함께 보는 관점에서 이번 만남은 단순한 이벤트가 아닙니다.
산업 구조 재편의 시그널로서 몇 가지 포인트를 짚을 수 있습니다.

1. 삼성전자 – 반도체 패키징 수혜 기대

HBM 및 AI 반도체 생산 확대에 따른 직접적 수혜.
특히 엔비디아와의 협업이 현실화될 경우, 파운드리 수익성이 강화될 가능성.

2. 현대자동차 – AI 차량 시대의 선두주자

엔비디아와 협력 시, SDV(소프트웨어 정의 차량) 전환 속도 가속.
향후 자율주행칩·AI 모빌리티 플랫폼 분야에서 글로벌 경쟁력 확보 기대.

3. 엔비디아 – 한국 협력 네트워크 강화

삼성, 현대와의 연합을 통해 아시아 시장 공급망을 강화하고
미·중 기술 패권 갈등 속 **‘한국을 전략적 파트너’**로 삼으려는 행보로 분석.

4. 장기적으로 본다면…

이번 회동은 “한국이 단순 제조기지에서 AI 중심국으로 성장하는 변곡점”이 될 수 있습니다.
중장기적으로는 AI 반도체, 패키징, 차량용 칩 분야의 국내 상장기업들에 주목할 만합니다.

마무리 – 기술과 투자, 그리고 한국의 위치

이번 ‘치맥 회동’은 가벼운 자리처럼 보이지만,
그 속엔 한국 산업의 미래 방향성이 담겨 있습니다.

AI 시대의 핵심은 반도체와 데이터, 그리고 모빌리티(Mobility) 입니다.
삼성·현대·엔비디아가 이 세 축을 함께 논의했다는 사실만으로도
한국이 앞으로 AI 기술 허브로 도약할 발판을 마련했다는 의미가 있습니다.

개인적으로 이번 만남은 “산업의 경계가 사라지는 시대”를 상징한다고 봅니다.
기술 중심의 협력, 그리고 데이터 기반 비즈니스가 향후 한국 시장의 새로운 투자 포인트가 될 것입니다.

[세상 모든 이슈] 트럼프와 시진핑 악수

WithSeungRyu — Thu, 30 Oct 2025 15:59:02 +0900

APEC 2025 — 트럼프와 시진핑, 다시 손을 맞잡다

회담의 배경

2025년 APEC(아시아태평양경제협력체) 정상회의에서
미국의 트럼프 대통령과 중국의 시진핑 주석이 오랜만에 마주 앉았습니다.

이번 악수는 단순한 인사가 아닌,
글로벌 경제와 기술 패권 경쟁의 흐름을 바꿀 수 있는 상징적 장면으로 평가받고 있습니다.

️ 회담의 주요 논의

주요 안건내용 요약

무역 관세 완화	미국이 중국 수입품에 대한 관세율 인하 발표
희토류 수출 협의	중국, 희토류 수출 통제를 완화하고 협력 방안 논의
AI 반도체 규제 완화 가능성	미국의 기술 통제 일부 완화 논의
펜타닐 수출 규제 강화	미국의 요구로 중국 측이 통제 강화 약속
우크라이나 및 국제 현안	지정학적 긴장 완화를 위한 협력 논의
상호 방문 약속	트럼프의 2026년 중국 방문, 시진핑의 미국 방문 검토

이번 회담에서는 “대만 문제”가 공식 의제로 다뤄지지 않았다는 점이 특히 주목받고 있습니다.

앞으로의 시나리오

시나리오 A: 관계 완화 & 시장 안정

관세 완화와 수출 규제가 실제로 이행되면
글로벌 공급망과 투자 심리가 회복될 가능성이 큼.

시나리오 B: 기술 경쟁의 고도화

반도체·AI·희토류 분야의 경쟁은 여전히 이어질 전망.
기술 동맹 및 핵심 소재 확보 경쟁이 장기적으로는 심화될 수 있음.

시나리오 C: 외교적 영향력 확장

중국은 아시아·남미 외교를 강화하고,
미국은 동맹국들과의 협력을 통해 대응할 가능성.

시나리오 D: 불확실성의 지속

정책 이행이 지연되거나 번복될 가능성 존재.
대만, 남중국해, 중동 등의 외교 리스크가 여전히 변수.

종합 정리

트럼프와 시진핑의 악수는
표면적으로는 화해의 제스처,
그러나 실제로는 전략적 계산의 한 수로 보입니다.

이 만남은 “긴장 완화”의 서막일 수도,
새로운 전략 경쟁의 리셋일 수도 있습니다.

“외형적 화해 뒤에서도, 패권 경쟁의 본질은 변하지 않는다.”

기술 & 투자 인사이트

IT·AI 기술 관점에서 본 의미

이번 APEC 회담은 AI·반도체 패권 경쟁 완화의 신호탄으로 볼 수 있습니다.

AI 반도체 공급망 안정화
- 수출 규제 완화 시, 엔비디아(NVIDIA)·AMD 등 주요 기업 실적 개선 기대.
- 중국 내 AI 스타트업 생태계도 점진적 회복 가능.
데이터 협력 및 윤리 논의 확대
- 미·중 간 데이터 표준 및 윤리 프레임워크 협의 시
  클라우드·AI 산업의 상호운용성(interoperability) 강화 가능.
보호주의 완화 → 기술 리커플링(Re-coupling)
- 분리(Decoupling)에서 협력(Cooperation)으로의 전환 가능성.

주식·투자 관점에서 본 변화

미국 시장: 반도체·AI·클라우드 관련 종목 (NVDA, MSFT, AMZN) 등 심리적 호재
중국 시장: BAT(바이두·알리바바·텐센트) 등 테크 대형주 중심 단기 반등 가능성
한국 등 아시아 시장: 공급망 안정화로 인한 반도체·디스플레이 업종 수혜 기대

다만, 정책 실현 여부와 미 대선 이후의 변수로 인해
단기 이벤트성 랠리보다는 중장기 분산투자 전략이 유효.

한줄 총평

“이번 트럼프–시진핑의 악수는
AI 시대의 새로운 ‘협력 경쟁(coopetition)’의 시작점이다.
기술은 이제 정치보다 빠르게 움직이고 있다.”

참고 링크

[JPA] native query 사용 시 enum을 변수로 하기 ( SpEL expression )

WithSeungRyu — Sun, 3 Apr 2022 13:37:59 +0900

Native Query 란?

JPQL을 사용해서 쿼리 메소드를 사용하는 것이 아닌 MySQL과 비슷한 형식으로 쿼리를 만들어 적용할 수 있다.

그러나, JPQL에서는 표준 SQL의 대부분의 기능을 지원하지만, 지원하지 못하는 문법들도 존재한다. ( ex. sub query )

이때 Native Query를 사용하면 JPQL에서 지원하지 못하는 문법들을 사용할 수 있다.

Native Query 를 사용하는 방법

//-- JPQL
@Query(value="SELECT M from Member M" )

//-- Native Query
@Query(value="SELECT * from Member m", nativeQuery= true )

Native Query에서 @Param에 Enum을 넣는 방법?

JPQL을 사용하면, Java에 Enum 타입을 아래와 같이 쿼리 변수로 넣을 수 있다.

@Query(value="SELECT M FROM MEMBER M WHERE TYPE = (:type) )
fun getMemberByType(@Param type MemberType) 

enum class MemberType(
    MASTER,
    NORMAL,
)

그러나 NativeQuery에서 Enum타입을 사용해서 위와 같이 변수로 넣으면,,, 에러가 난다. ( String으로 넣어야 하도록.. )

어떻게 하면 String으로 변경해야하는 번거로움을 해소시키기 위해, 그대로 Enum을 사용할 수 있을까?

해결책을 SpEL expression 을 사용하는 것이다.

SpEL (Spring Expression Language)이란?

- 스프링 프로젝트에서 런타임에 쿼리를 지원하여 객체를 조작할 수 있는 표현식

( 참고 : https://atoz-develop.tistory.com/entry/Spring-SpEL-Spring-Expression-Language )

SpEL을 사용해서 Native Query에서 Enum 타입 사용하기

- Enum의 한 변수만 사용하기
#{#변수.name()}

@Query(value="SELECT * FROM member m WHERE m.type = #{#type.name()} )
fun getMemberByType(@Param("type") type MemberType) 

enum class MemberType(
    MASTER,
    NORMAL,
)

- Enum을 Collection(List, Set으로 사용하기
#{#변수.![name()]}

@Query(value="SELECT * FROM member m WHERE m.type in #{#types.![name()]} )
fun getMemberInTypes(@Param("types") types Set<MemberType>) 

enum class MemberType(
    MASTER,
    NORMAL,
)

[JPA] JPA native query 사용시 dto mapping

WithSeungRyu — Sun, 6 Feb 2022 14:58:23 +0900

보통 조인을 많이 사용하게 될 상황이 생기면 JPA Native query를 사용한다.

이 때, 조인되어지는 테이블들의 column 값을 사용해야하는 상황에는 Entity에 맵핑을 시켜줄 수 없는 문제가 있다.

이럴 때에는 바로 원하는 변수가 있는 DTO에 맵핑을 시켜주어야 하는데,,

어떤 방법들이 있을까?

1. Entity에서의 `@SqlResultSetMapping` 사용

@Entity
@NamedNativeQuery(
    name = "find_books',
    query =
        "SELECT " + 
        "  생략.... ",
    resultSetMapping = "book_dto"
)
@SqlResultSetMapping(
    name = "book_dto",
    classes = @ConstructorResult(
        targetClass = BookDto.class,
        columns = {
            @ColumnResult(name = "bookId", type = Long.class),
            @ColumnResult(name = "writerName", type = String.class),
            @ColumnResult(name = "launguage", type = String.class)
        }
    )
)

@Repository
public interface BookRepository extends JpaRepository<Book, Long>, {

   @Query(name = "find_books_dto", nativeQuery = true)
   List<BookDto> findAllBook(...생략);
}

2. Interface 로 선언한 Dto에 맵핑 - getter를 선언해줘야 한다.

public interface BookDto {
	getTitle();
    getWriterName();
    getLanguage();
}

@Repository
public interface BookRepository extends JpaRepository<Book, Long>, {

   @Query(value = "SELECT * FROM ... 생략", nativeQuery = true)
   List<BookDto> findAllBook(...생략);
}

만약 DTO를 그대로 클라이언트에게 주어줘도 상관이 없다면 interface ( with getter) 를 사용하여 맵핑을 시켜주어도 상관 없을 듯 하고, 만약 DTO의 변화가 필요하다면 1 번의 방식을 사용해서 맵핑을 시켜주면 될 것 같다.

혹시.. 더 좋은 방법이 있다면 알려주시면 감사하겠습니다!

[F.Y.R] Jitter? ( Retry의 전략 )

WithSeungRyu — Sun, 16 Jan 2022 15:38:55 +0900

맡고 있는 프로젝트에서 다른 서버와 통신을 하는 코드를 보던 중,

통신을 하는 서버에서 동시성 이슈로 재시도를 원하는 에러코드가 내려왔고, 이에 잠깐의 sleep을 한 후에 재시도하는 것을 볼 수 있었다.

Retry?

MSA구조에서는 서로 다른 서버와 통신을 할 일이 많다.

그렇기 때문에 서로 다른 서버와 통신할 때 실패율을 줄이는 것이 중요하며, 호출 재시도를 하며 실패율을 줄일 수 있다.

보통 Sleep을 해주는 이유는 동시에 요청이 왔을 때, 바로 재시도를 하게 된다면 동시성 이슈에 있어서 성공률은 떨어지기 때문이다.

그래서 보통은 Exponential Backoff Algorithm ( 백오프 ) 를 사용해야하는 걸로 알고 있었다.

1번째 재시도 : 1초 -> 2번째 재시도 : 2초 -> 3번째 재시도 : 4초 -> 8초.... 16초...32초

( 재시도 횟수마다 기다리는 시간이 지수 단위로 증가 )

그러나 내가 보던 코드에서는 0.1~0.4초의 범위에 랜덤한 값을 Sleep하며 재시도를 하고 있었다.

왜,,, Exponential Backoff한 Retry가 아닌 랜덤한 값을 주고 있었던 걸까?..

그 이유가 Jitter라는 것을 동료 개발자에게 들을 수 있었다.

Jitter란?

Random한 시간으로 Retry 사이의 시간을 설정해주는 방법

sleep = radom_between(0, min(xxx))

( 참고 : https://aws.amazon.com/ko/blogs/architecture/exponential-backoff-and-jitter/ )

Exponential Backoff And Jitter | Amazon Web Services

Introducing OCC Optimistic concurrency control (OCC) is a time-honored way for multiple writers to safely modify a single object without losing writes. OCC has three nice properties: it will always make progress as long as the underlying store is available

aws.amazon.com

위 글을 참고하면,

Exponential Backoff를 사용해서 재시도를 한다해도 만약 같은 시간에서의 첫 시도에 호출된 수가 많게 되면, 재시도하는 시간이 증가하더라도 대기하는 시간이 계속 같기 때문에 효과가 없을 수 있는 문제가 발생할 수 있다.

이러한 문제를 방지하기 위해서 같은 시간에 첫 호출이 발생해도 Random 한 값을 주어 해결할 수 있도록 하면, 위 글의 그래프에서 볼 수 있 듯이 높은 효율성과 낮은 Competing Clients를 얻을 수 있다.

궁금하신 것이 있으시면 언제든지 댓글 달아주세요!

[Error] org.hibernate.LazyInitializationException: could not initialize proxy

WithSeungRyu — Sun, 12 Dec 2021 16:10:28 +0900

원인 파악

코드를 열심히 작성해서 리뷰를 받고, 즐거운 마음으로 라이브 배포를 했다..

그러나 몇 분이 지나지 않고 error alert이 나오기 시작했고,,, 정말 어처구니 없는 실수를 했다는 것을 깨달았다.

에러 내용은 JPA에서 나온 오류였다..

org.hibernate.LazyInitializationException: could not initialize proxy

위와 같은 오류가 생긴 원인을 파악하기 위해서 구현한 부분을 다시 보았고,

Entity 객체를 DTO 객체로 변경하기 위해 BeanUtils copyProperties로 간편하게 하려고 했던 부분해서 문제가 있다는 것을 발견할 수 있었다.. (괜히 빠르게 하려다가..)

BeanUtils copyProperties란?

스프링에서 제공해주는 BeaUtils 클래스의 메소드인데, 같은 이름은 getter와 setter만 잘 구현되어 있다면 손쉽게 객체를 복사시킬 수 있다.

( 참고 : https://zzang9ha.tistory.com/304 )

이 메소드를 사용하며 간과한 부분이 한 객체를 다대일 관계로 구성했고 이를 LAZY 페치를 하도록 설정해두었었다. 그렇기 때문에 해당 객체는 프록시 객체로 저장이 되어 있는 상태였고, 그래서 위 메소드를 실행시 원본 객체가 아닌 프록시 객체를 복사하려고 시도했기 때문에 위와 같은 오류가 발생한 것이 었다......!

해결 방법

뭐... Lazy 를 Eager로 변경하면 좋겠지만.. 그렇게 좋은 해결책은 아닌 것 같다..

그래서 set 함수로 하나 하나 아래와 같이 넣어주는 방법이 있을 수 있다. ( 가장 원초적인 해결책 )

또한 copyProperties 중 하나의 overloading한 메소드로 프록시 객체를 가진 변수를 객체 복사에서 제외시켜줄 수 있는데,

위에 나온 것과 같이 3번째 인자로 제외하고 싶은 변수의 이름을 넣어주면 제외시켜줄 수 있다.

그래서 아래와 같이 해결해보았다.

@Entity
public class Team {
	@Id
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Member member;
}

public class Member {
	@Id
    private Long id;
}

//As-is 
public TeamDto toDto(Team team) {
	TeamDto teamDto = new TeamDto();
    BeanUtil.copyProperties(team, teamDto);
    return teamDto;  
}

//to-be
public TeamDto toDto(Team team) {
	TeamDto teamDto = new TeamDto();
    BeanUtil.copyProperties(team, teamDto, "member");
    // MemberDto 만들기
    MemberDto memberDto = new MemberDto();
    memberDto.setId(team.getMember().getid());
    teamDto.setMemberDto(memberDto)
}

이렇게 하면 Lazy로 가져온 프록시 객체 문제도 해결할 수 있어 같은 오류를 만나지 않을 수 있을 것이다

( 혹시 더 좋은 해결책이 있다면,,, 바로 알려주시면 감사하겠습니다 )

주석..주석에 대한 개인적인 고찰

WithSeungRyu — Sun, 7 Nov 2021 21:40:50 +0900

항상, 주석을 달면 다음에 읽을 사람을 위해 자세히 달아 주면, ( 아! 다음 사람이 이 주석을 보면서 코드를 더 잘 이해하실 수 있겠지?)라고 생각하며 기분 좋은 마음으로 달아주었다..

하지만 직접 실무를 다루게 되고, 다른 사람이 만들어 놓은 코드를 읽을 때면 주석이 무조건 좋은 것이 아니라는 것을 깨달을 수 있었다...

클린코드에서는 아래와 같이 좋은 주석과 나쁜 주석을 분류해놓았다.

좋은 주석

법적인 주석

의도를 설명하는 주석

의미를 명료하게 밝히는 주석

결과를 경고하는 주석

TODO 주석

중요성을 강조하는 주석

나쁜 주석

주절거리는 주석

같은 이야기를 중복하는 주석

오해할 여지가 있는 주석

의무적으로 다는 주석

있으나 마나 한 주석

무서운 잡음

함수나 변수로 표현할 수 있다면 주석 X

닫는 괄호에 다는 주석

등..

이렇게 분류를 해놓았고, 읽으면서 어느 정도 이해를 했다.

그리고 깨달은 것은 코드로 작성자의 의도를 파악할 수 있도록 '이야기를 하는 것과 같은 코드'를 최대한 짜는 것이 중요하다는 것이다...

그리고.. 코드로 절대 모든 이야기의 내용을 표현할 수 없다면 주석을 사용하는 것이 가장 베스트라는 것을.. (개인적인 의견입니당..)

[Error] Cause: java.lang.ExceptionInInitializerError

WithSeungRyu — Sat, 30 Oct 2021 20:44:44 +0900

매번 GIT으로 레포지토리를 클론하고 새 환경에서....!
Project를 실행하거나 빌드할 때, "java.lang.ExceptionInInitializerError" 에러를 자주 만나곤 한다.
구글링을 해보니 거의 80%는 JUnit, Gradle 등 버전 문제라고 한다.

Java 8로 동작하는지, Junit의 버전은 무엇인지 체크를 잘 하면 되고,
보통은 IDE에서 15로 설정된 JVM를 8/1.8 로 설정을 해주면 잘 실행된다.

Intellij IDEA
=> Preferences -> build -> Gradle -> Gradle JVM 버전 잘 설정하자....!

음성 채팅 어플리케이션 - TOVE ON

WithSeungRyu — Sun, 4 Jul 2021 22:08:58 +0900

개요

스마일게이트 스토브에서 DEV CAMP 인턴 활동을 진행하며 만든 프로젝트이다.
음성 채팅, 텍스트 채팅을 내장한 어플리케이션이며 웹과 앱으로 사용가능하도록 웹 버전, 모바일 버전으로 개발했다.

기술 스택

Front-end : VueJS(Web), Android(Mobile), WebRTC(음성 피어 연결)
Back-end : Spring boot, Spring WebSocket (STOMP Pub/Sub), Spring Security, Redis, MariaDB, CoTRUN
Infra : Aws S3, Aws RDS, Aws Elastic LoadBalance, Nginx
협업 : GIT, GitLab, Zira

역할

시그널링 서버 구축

WebRTC 전송 정보 중계 로직 구현 ( 참고 : https://withseungryu.tistory.com/category/WebRTC )
음성 채팅 방 입장 및 퇴장 로직 구현
다중 인스턴스 환경 구축 ( 참고 : https://withseungryu.tistory.com/139?category=931345 )

텍스트 채팅 서버 구축

텍스트 채팅 방 입장 및 퇴장 로직 구현
메세지 DB & FILE 로깅
RabbitMQ STOMP Broker 사용

웹 프론트 구현

음성 채팅 기능 및 UI 구현
음성 컨트롤 기능 구현
비동기 처리

전체 아키텍처

인증 채널 아키텍처

텍스트 채팅 아키텍처

음성 채팅 아키텍처

음성 통신 기능을 구현을 위한 Peer 연결로 Full Mesh 구조를 사용했는데,
Full Mesh를 사용한 이유는 해당 어플리케이션을 설계할 때 최대 인원을 8인 이하로 설정해두었고,
영상데이터가 아닌 음성데이터만을 지원하기 때문에 Full Mesh 구조를 선택했다.

성과 및 달성

음성채팅

WebRTC를 위한 사용자의 네트워크 정보 교환 ( ICE candidate ), 미디어 정보 교환, 세션 컨트롤 수행
보안을 위한 세션 연결 전 JWT를 사용해 AUTH 서버로 인증
다중 인스턴스 환경 관리를 위해 각 인스턴스에 연결된 세션 수를 Redis에 캐싱
방화벽에 의한 Symmetric NAT 환경에 대비한 릴레이 통신을 지원해주는 TURN 서버 구축

참고 : https://withseungryu.tistory.com/138?category=917456

[WebRTC] TURN 서버의 필요성

WebRTC 기술을 사용해 음성 애플리케이션을 만들어 테스트하는 중 P2P 연결이 잘 안 되는 문제가 있었다. 원인을 찾아보려고 코드를 계속 수정했지만 실행이 되지 않았다. 그러던 중 LTE를 사용하고

withseungryu.tistory.com

텍스트채팅

메시지의 효율적인 전송을 위한 STOMP 프로토콜 사용
보안을 위한 세션 연결 전 JWT를 사용해 AUTH 서버로 인증과 메시지 로깅
확장성, 결함 허용성, 간편한 모니터링을 위한 External Broker로 RabbitMQ STOMP 브로커 사용

발표 영상

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.