2026 상반기 회고

안녕하세요, RCV 연구실 1년차이자, 막내이자, 로보틱스 팀이자, 이제 곧 입대를 하는 김기현입니다.

저도 전혀 생각하지 않고 있었는데 이번 URP 분들을 보니 저도 1년 동안 연구실 생활을 했다는 것이 좀 실감이 났습니다. 마지막으로 하고 싶은 말들을 다 적으려고 구성을 하다 보니까 내용이 좀 길어졌는데, 양해해 주시고 읽어주시면 감사하겠습니다 🌟

  1. 최신 트렌드
  2. 연구실 일상 — 우편 배달 모바일 매니퓰레이터
  3. 연구실 1년기
  4. 인간 김기현의 인생에 대해서…

1. 최신 트렌드

또 돌아왔습니다~ 김기현의 트렌드 소개 시간~

이번에도 틈틈이 본 잡지식들을 스쳐 지나가듯이 소개해 드릴 테니, 가볍게 보시고 어디서 좀 아는 척 하실 때 사용해 주시면 될 것 같습니다.
(제가 초본을 작성하고 저도 이해하기 난해하게 적어놔서 claude의 도움을 받아서 보완하고 검토했습니다)

HBM과 HBF

올해 가장 Hot했던 키워드 중 하나라고 생각이 됩니다. HBM 때문에 하이닉스와 삼성의 주가가 요동쳤다고 해도 과언이 아니라고 보입니다.
HBM(High Bandwidth Memory) 을 단순하게 설명드리자면, DRAM을 층층이 쌓아 올린 것입니다.

구조를 조금 더 뜯어보면 이렇습니다.

  • DRAM 다이 여러 장을 수직으로 쌓고
  • 각 다이를 TSV(Through-Silicon Via) 라는 관통 전극으로 위아래로 뚫어서 연결하고
  • 맨 아래에 이를 총괄해서 제어하는 베이스 다이(로직 다이) 를 둡니다

이렇게 하면 DRAM과 연산 칩 사이의 물리적 거리가 짧아지고, 좁은 공간 안에 훨씬 많은 DRAM을 넣을 수 있게 됩니다. 거리를 좁히면 당연히 전력 효율과 전송 속도에서 이점을 가지고, 배선(I/O 핀)을 훨씬 많이 배치할 수 있기 때문에 대역폭에서도 큰 이점을 가져갑니다.

여기서 하나 짚고 넘어가면 좋은 게, HBM의 본질은 클럭을 미친 듯이 올리는 게 아니라 인터페이스 폭 자체가 넓다는 것입니다. HBM3E가 스택당 1024비트, HBM4는 2048비트로 두 배가 됩니다. 넓은 길을 천천히 가는 방식이라서 비트당 에너지 효율이 좋습니다.

그리고 요즘 진짜 이슈는 “다이끼리 어떻게 붙일 것인가”입니다.

지금까지는 다이 사이에 마이크로범프를 끼우고 MR-MUF(SK하이닉스) 또는 TC-NCF(삼성·마이크론) 방식으로 붙였습니다. 여기서 한 단계 더 나간 게 하이브리드 본딩(Hybrid Bonding) 인데, 범프 없이 구리-구리(Cu-Cu)를 직접 접합하는 방식입니다. 범프가 사라지니까 피치를 10µm 이하로 줄일 수 있고, 스택 높이도 낮아지고, 무엇보다 접합부 열저항이 20~47%까지 줄어든다는 연구 결과가 있습니다.

다만 하이브리드 본딩은 비쌉니다. 그래서 JEDEC이 HBM4의 패키지 높이 제한을 720µm → 775µm로 완화해 주면서, HBM4는 마이크로범프로 한 세대를 더 버티게 되었습니다. 본격적인 하이브리드 본딩 도입은 HBM4E~HBM5 세대로 보고 있습니다. (삼성은 HBM4부터 적용하겠다고 밝힌 상태입니다)

발열은 여전히 HBM의 가장 큰 숙제입니다. 12단을 넘어가면 스택 내부 열저항이 급격하게 올라가기 때문에, 열전도가 잘 되는 몰딩재(MR-MUF) 를 채워 넣거나, 앞서 말한 하이브리드 본딩으로 아예 열이 빠져나갈 경로를 짧게 만드는 방향으로 가고 있습니다.


그러면 HBF는 또 뭐냐? 하실 텐데, 한 줄로 말하면 HBM은 DRAM을 쌓은 것, HBF는 NAND를 쌓은 것입니다.

HBF(High Bandwidth Flash) 의 포지션은 명확합니다. HBM과 SSD 사이의 새로운 계층입니다. HBM은 빠르지만 비싸고 용량이 작습니다. SSD는 싸고 용량이 크지만 GPU 입장에서는 너무 멉니다. 그 사이를 비교적 덜 비싼 NAND로 메워서, HBM에 다 못 올리는 weight를 분담하자는 겁니다.

SanDisk가 제시한 1세대 목표 스펙을 보면 이렇습니다.

여기서 핵심은 왜 추론 전용이냐입니다. NAND는 쓰기가 느리고 쓰기 수명(수천 사이클)도 짧습니다. 그런데 추론할 때 모델 가중치는 한 번 올려놓고 계속 읽기만 합니다. 즉 NAND의 약점이 드러나지 않는 워크로드입니다. 반대로 학습은 가중치를 계속 갱신해야 하니 HBF로는 안 됩니다. 그래서 처음부터 “추론용”이라고 못을 박고 나온 물건입니다.

현재 SanDisk와 SK하이닉스가 2026년 2월에 OCP(Open Compute Project) 산하에 전용 워크스트림을 만들어서 표준화를 진행하고 있고, 첫 샘플은 2026년 하반기, HBF를 탑재한 추론 디바이스 샘플은 2027년 초를 목표로 하고 있습니다.
이렇게 된 GPU가 나오게 된다면 더 무거운 weight를 올릴 수 있지 않을까 하면서 이 장을 마무리해 보겠습니다.

TPU 8세대 – 8t와 8i

젠슨 황이 TPU를 견제하는 발언을 여러 차례 했지만, Google의 TPU 시장이 커지고 있는 건 사실인 것 같습니다.
2026년 4월 22일 Google Cloud Next ’26에서 구글은 8세대 TPU인 TPU 8t와 TPU 8i를 소개했습니다.

이번 발표의 가장 큰 의미는 TPU 10년 역사상 처음으로 훈련용과 추론용 칩을 완전히 분리했다는 것입니다. 모델 크기가 기하급수적으로 커지고, 무엇보다 에이전트 워크로드가 늘어나면서 훈련과 추론이 요구하는 인프라가 완전히 갈라졌기 때문입니다.

TPU 8t (코드명 Sunfish) – 훈련용

  • 훈련에 최적화된 플랫폼. 12.6 FP4 PFLOPS, HBM3E 216GB / 6,528 GB/s
  • 3D 토러스 토폴로지 유지 → 슈퍼팟 하나에 9,600칩을 동시에 묶어서 사용 가능
  • 슈퍼팟 전체 HBM 총 용량 2PB, 121 FP4 EFLOPS (이전 세대 Ironwood 대비 약 3배)
  • SparseCore 유지 — 학습 시 임베딩 룩업처럼 불규칙한 메모리 접근 패턴을 처리해야 하기 때문
  • Virgo 네트워크 패브릭으로 스케일아웃 → 단일 데이터센터에서 13.4만 칩, 멀티 사이트로 100만 칩 이상까지 확장. ICI 스케일업 대역폭과 DCN 스케일아웃 대역폭을 모두 크게 늘려서 데이터 병목을 획기적으로 해결했습니다.

TPU 8i (코드명 Zebrafish) – 추론용

  • 10.1 FP4 PFLOPS, HBM3E 288GB / 8,601 GB/s (훈련용보다 메모리 대역폭이 오히려 더 높습니다)
  • 온칩 SRAM 384MB — 이전 세대 대비 3배. 롱컨텍스트 디코딩 중 KV 캐시를 칩 안에 통째로 올려두기 위한 설계입니다.
  • Boardfly 토폴로지 — TPU 2세대 이후 계속 써오던 3D 토러스를 버리고 도입한 신규 ICI 네트워킹 아키텍처입니다. 네트워크 지름(diameter)을 50% 이상 줄였습니다.
  • CAE (Collectives Acceleration Engine) — SparseCore를 대신하는 신규 고정 기능 블록. 자기회귀 디코딩과 chain-of-thought 처리에서 발생하는 reduce·sync 연산의 지연을 최대 5배 줄입니다.
  • ICI 대역폭 2배 (19.2 Tb/s), Ironwood 대비 성능/달러 80% 개선

이를 나눈 이유는 추론의 중요성이 기업 입장에서 커졌기 때문입니다.
대규모 모델을 연산 장치에 올려서 사용자에게 서비스로 제공하는 것이 결국 기업의 일이고, 이제 AI 가속기 사이클의 70% 이상이 추론이라고 합니다. 게다가 기술적으로도 이유가 명확한데, 훈련은 compute-bound인 반면 추론 디코딩은 memory-bandwidth-bound입니다. 병목이 완전히 다른데 칩 하나로 둘 다 하려니 어느 쪽도 최적이 아니었던 겁니다. 그래서 작업을 나누고, 각 작업에서 효율적인 칩을 구동하도록 하는 것이 목표입니다.
참고로 설계 파트너도 바뀌었습니다. 2015년부터 독점이던 브로드컴에 더해 MediaTek이 TPU 8i의 물리 구현을 맡았습니다. 하이퍼스케일러 AI ASIC에서 브로드컴 독점이 깨진 셈입니다.

Google Axion – “칩만 잘 만들어선 안 된다”

구글 얘기가 나온 김에, Axion도 짚고 가겠습니다.
Axion은 구글이 만든 Arm 기반 자체 CPU입니다. Cloud Next ’26에서는 N4A라는 새 VM 인스턴스가 나왔는데, 사실 더 중요한 건 이번 8세대 TPU의 호스트 CPU로 Axion이 처음 채택되었다는 점입니다.
구글이 직접 이렇게 말했습니다. “처음으로 두 칩 모두 우리 Axion CPU를 호스트로 사용한다. 덕분에 칩만이 아니라 시스템 전체를 최적화할 수 있다.”

이게 왜 의미가 있냐면, 9,600칩 규모의 훈련 팟에서는 호스트 CPU의 사소한 지터(jitter) 하나가 전체 collective 연산에 누적되어 goodput을 갉아먹기 때문입니다. 구글은 Axion에 NUMA 격리를 적용해서 호스트 쪽 노이즈가 훈련 동기화 구간으로 새어나가지 않도록 막았다고 합니다. x86 서버를 사다 쓰면 절대 못 하는 최적화입니다.
즉, 이제 더 이상 GPU나 연산 장치, 그리고 모델만으로는 기업이 서비스를 하는 데 제약이 많고, 호스트 CPU · 가속기 · 네트워크 · 데이터센터까지 전체 시스템을 완전히 구상해야 더 효율적이다 라는 것을 다들 알아차린 듯합니다. 이건 바로 다음에 나올 NVIDIA 이야기와 정확히 같은 결론입니다.

아마도 로봇도 결국 올 시스템(센서-연산-구동-전원)을 통합해서 설계해야 이제 경쟁력이 생길 가능성이 있어 보입니다…..

Server – NVIDIA가 이제 랙을 판다

최근 NVIDIA의 발표를 확인해 보면 NVIDIA가 서버 랙 자체를 판매한다는 내용이 담겨 있습니다. Rubin 플랫폼은 CES 2026에서 6개 칩 세트로 공개되었고, GTC 2026에서 랙 구성이 구체화되었습니다.

기존에는 CPU 같은 건 Intel을 쓰고 GPU만 NVIDIA를 사용했다면, 이제는 CPU + GPU + 네트워크 + 스토리지 + 보안까지 전부 NVIDIA가 통솔할 수 있게 된다는 것입니다.
Vera Rubin NVL72 랙의 구성 요소는 이렇습니다.

여기에 추가로 알아두면 좋은 두 가지가 더 있습니다.

  • Rubin CPX — 롱컨텍스트 추론의 prefill(사전 처리) 단계 전용 가속기입니다. prefill은 메모리 대역폭보다 연산이 병목이라 HBM이 필요 없고, 그래서 대신 GDDR7 128GB를 씁니다. 이걸 일반 Rubin GPU와 섞어 놓은 NVL144 CPX 랙은 추론 성능이 8 EFLOPS까지 올라갑니다. prefill은 CPX가, decode는 일반 Rubin이 담당하는 분리(disaggregated) 추론 구조입니다.
  • LPX 랙 (Groq 3 LPU) — NVIDIA가 Groq의 LPU 기술을 가져와서 만든 초저지연 추론 전용 랙입니다. 큰 온칩 SRAM을 활용해서 배치가 작고 지연이 중요한 추론을 처리합니다. 다만 이건 표준 NVL72 랙의 구성품이 아니라 별개의 랙 라인이라는 점을 구분해서 보시면 좋습니다.

단면적으로만 봤을 때는 NVIDIA가 시장을 점령하는 것으로 보이기도 하지만, 저는 이제 단순히 인공지능 연산 장치에서 GPU만 중요한 게 아니라 CPU와 통신 시스템 같은 부가적인 장치까지 통합해서 만드는 것이 중요해졌다고 보였습니다.
이렇게 통합해서 만든다면 본인들이 만든 칩끼리 최적화를 할 수 있고, 이는 결국 성능 향상으로 가게 됩니다. 그래서 해당 시스템이 압도적인 성능 향상을 보이는 것은 단순히 GPU 성능이 향상되어서가 아니라, 시스템을 통합함으로써 얻을 수 있는 우위를 가져갔다고 볼 수 있습니다.

실제로 NVIDIA가 내세우는 수치가 “Blackwell 대비 추론 토큰 비용 10분의 1, MoE 훈련에 필요한 GPU 4분의 1″인데, 이건 GPU 단일 성능만으로는 절대 나올 수 없는 숫자입니다. 단순히 연산 분야만 개선하는 것이 아니라 통신 부분에서도 개선을 보이고 있다는 게 핵심입니다.

Power – 800V DC

최근에 봤는데 NVIDIA에서 800V DC 규격의 전력 공급을 목표로 하고 있다고 합니다. 왜 전압을 올리는가? 이유는 물리적으로 단순합니다. P = V * I 전력이 정해져 있을 때, 전압을 올리면 전류가 내려갑니다. 그런데 전송 손실은 전류의 제곱(I²R)에 비례합니다. 즉, 전압을 올리면 전류가 줄고 → 손실이 제곱으로 줄고 → 케이블도 얇아집니다. 반대로 전압이 낮으면 같은 전력을 보내기 위해 전류를 올려야 하고, 그러면 이를 버티기 위한 케이블이 두꺼워지고 열손실도 급격히 커집니다. 숫자로 보면 왜 이게 급한 문제인지 바로 보입니다.

  • 기존 랙 내부 배전은 54V DC입니다.
  • 1MW 랙을 54V로 돌리려면 → 구리 부스바만 약 200kg이 필요합니다.
  • 1GW 데이터센터라면 랙 부스바 구리만 20만 kg입니다. 지속 가능하지 않습니다.
  • H100 시절 랙당 40kW → GB200 시절 120kW → 2027년 Rubin Ultra(Kyber) 랙은 600kW~1MW를 봅니다. 3년 만에 25배입니다.

그래서 NVIDIA가 제시한 방식이 시설 입구에서 13.8kV AC를 곧바로 800V DC로 한 번에 변환하고, GPU 근처까지 800V로 보낸 다음 거기서 전압을 낮추는 것입니다. 여기서 진짜 핵심은 구리만이 아니라 AC→DC→AC→DC로 반복되던 변환 단계를 최대 4단계 제거한다는 점입니다. 효과는 종단 효율 5% 이상 개선, 유지보수 비용 70% 절감, TCO 30% 절감이라고 합니다.

그렇지만 800VDC가 단순히 좋다고 보기에는 어렵습니다.

  • 아크(arc) 문제 – 전 세계에서 기존에 사용하던 전력 시스템은 AC입니다. AC는 전류가 주기적으로 0을 지나가기 때문에 아크가 스스로 꺼집니다. 그런데 DC는 0을 지나지 않고 지속적인 형태를 보이기 때문에 아크가 스스로 꺼지지 않습니다. 사고가 났을 때나, 서버가 켜져 있는 상태에서 부품을 교체할 때 매우 위험할 수 있고, DC 전용 차단기·퓨즈·아크 억제 설계를 새로 만들어야 합니다.
  • 강압 문제 – 칩 코어는 0.7~1V 수준으로 동작합니다. 칩은 예민한 회로 시스템이라 높은 전압이 그대로 들어가면 못 씁니다. 그래서 800V를 칩 근처에서 안전하고 효율적으로 떨어뜨려야 하는데, GTC 2026에서 TI가 800V → 6V → 1V 미만, 단 2단계 변환 구조를 시연했습니다. 이런 게 다 새로 개발되어야 하는 것들입니다.
  • 표준 분열 – NVIDIA는 800V 단일, OCP 진영(구글 등)은 ±400V bipolar를 밀고 있습니다. ±400V를 쓰면 전기차 부품 공급망(650V GaN FET 등)을 그대로 재활용할 수 있다는 게 명분입니다.

그럼에도 불구하고 해당 시스템은 AI 시스템의 효율 자체를 올릴 수 있기 때문에 일정 수준 이상 개발하면 매우 가치 있는 부분이고, 이를 통해서 알 수 있는 것은 AI 팩토리가 단순히 성능을 올리는 것을 넘어서 하드웨어 상의 전력 공급망까지 재설계를 해야 하는 단계에 왔다는 것입니다.

로봇 – Figure 03과 휴머노이드

단순히 Figure 03만이 아니라 요즘 휴머노이드를 보면 모두 현장 투입을 우선적으로 하고 있는 것 같다고 생각되었습니다.

  • Figure 03 – 2026년 6월부터 BMW 스파턴버그 공장에서 실제 생산 물류 작업에 투입되었습니다. 데모가 아니라 진짜 공장 일입니다.
  • Tesla Optimus – 택배를 뒤집고 분류하는 작업을 오랜 시간 동안 반복 수행하는 모습을 계속 보이고 있습니다.
  • Boston Dynamics Atlas – 마찬가지로 현장 투입을 목표로 개발되고 있다는 느낌을 보였습니다.

그런데 Figure 03에서 진짜 주목할 부분은 성능보다 “제조”였습니다. Figure는 BotQ라는 자체 공장을 만들었는데, 2026년 1월에 하루 1대를 만들던 것을 4월에 시간당 1대로 끌어올렸습니다. 120일도 안 되어 처리량 24배입니다. 4월 말 기준 350대 이상을 출하했고요. CNC로 일주일 걸리던 부품을 사출·다이캐스팅으로 바꿔서 20초 만에 뽑는 식으로, 아예 양산을 전제로 로봇을 처음부터 다시 설계한 결과입니다.

로봇을 많이 만드는 게 중요한 이유는, 대수가 곧 데이터이기 때문입니다. 필드에 나간 로봇들이 실패 케이스를 계속 물어오고, 그게 Helix(Figure의 VLA 모델)로 다시 들어가고, OTA로 전 대수에 뿌려집니다. 실제로 최근 공개한 Helix System 0는 시뮬레이션에서 RL로 학습한 전신 제어를 실기에 파인튜닝 없이 그대로 전이해서 계단이나 울퉁불퉁한 지면을 걷게 만들었습니다. sim-to-real이 이렇게 되기 시작했다는 게 꽤 큰 신호라고 봅니다.

그래서 제 생각은 이렇습니다. 앞으로 휴머노이드가 가장 먼저 투입되는 곳은 아무래도 변수가 적고, 일관된 작업을 계속 수행할 수 있는 공장이 되지 않을까? 가정용으로 휴머노이드가 나오기에는 좀 애매하지 않나? 오히려 모바일 매니퓰레이터가 현재 시점에서는 가정용에 더 적절하다고 보이는 느낌이었습니다.

다만 반대 근거도 분명히 있습니다. Figure 03은 오히려 가정용을 정면으로 노리고 설계된 로봇입니다. 딱딱한 가공 부품 대신 소프트 텍스타일로 덮었고, 끼임 방지용 다중 밀도 폼을 넣었고, 무선 충전과 음성 추론용 오디오까지 넣었습니다. 손끝 센서는 3g의 압력까지 감지합니다. 목표 가격도 2만 달러 선이고, 가정 출시 목표는 2026년 말입니다. 즉 하드웨어는 이미 가정을 향해 가고 있다고 봐야 할 것 같습니다.

결국 진짜 병목은 하드웨어가 아니라 일반화인 것 같습니다. 가정의 변수나, 크게 정해진 규칙이 없는 문제들을 해결할 수 있는 학습 방법 같은 게 안 나오면 뭔가 가정용 휴머노이드는 좀 멀지 않았나 싶습니다. 빨래 대신 해주고 설거지 대신 해주는, 일관된 동작을 하는 휴머노이드같이 다관절을 가지고 있는 로봇은 좀 멀었다고 생각합니다.

Flash-MoE – 맥북 SSD에서 397B 모델 돌리기

이건 지나가면서 쓱 하고 보게 된 내용인데, 모델을 맥북의 SSD에 올려놓고 동작시키는 방식을 제시한 내용입니다.원리를 간단히 설명드리면 이렇습니다. MoE(Mixture-of-Experts) 모델은 전체 파라미터가 아무리 커도 토큰 하나당 활성화되는 expert는 극히 일부입니다. Qwen3.5-397B-A17B의 경우 전체 397B 중 토큰당 17B만 활성되고, expert로 따지면 512개 중 4개만 켜집니다. 그러면 안 켜지는 나머지 expert는 굳이 RAM에 들고 있을 필요가 없습니다. SSD에 두고 필요할 때만 스트리밍해서 가져오면 됩니다. 이게 Flash-MoE의 아이디어이고, 뿌리를 따라가면 Apple의 2023년 논문 “LLM in a Flash”로 이어집니다.

커스텀 LRU 캐시나 프레임워크를 다 걷어내고 “OS를 믿는다” 는 철학으로 순수 C/Metal로 짠 게 핵심이라고 합니다. 구조화된 JSON 출력, tool calling, 롱컨텍스트 추론까지 다 됩니다. 다만 오해하면 안 되는 부분이 두 가지 있습니다.

  • 출력 품질은 유지되지만 속도는 확실히 느립니다. 4.4 tok/s면 사람이 읽는 속도보다 살짝 빠른 정도입니다. “성능이 안 떨어진다”는 건 답변의 질 얘기지 처리량 얘기가 아닙니다.
  • 에너지 효율은 오히려 나쁩니다. SSD의 비트당 읽기 에너지가 DRAM보다 훨씬 크기 때문에, 데이터센터 규모에서 이걸 하면 토큰당 전력이 오히려 급증한다는 연구가 있습니다. 즉 “내 랩탑에서 큰 모델을 돌려보고 싶다” 는 개인 온디바이스 용도에는 훌륭하지만, 서버 최적화 기법은 아닙니다.

그리고 이건 MoE라서 되는 것입니다. Dense 모델은 매 토큰마다 전체 weight를 읽어야 하니 SSD 대역폭이 그대로 병목이 되어서 불가능합니다. 그래서 관심 있으시거나, 온디바이스에서 모델을 돌려보고 싶은데 램이 부족하다 하시면 한번 읽어보시는 것도 좋아 보입니다.

Fable – 능력이 아니라 “안전장치”로 이름이 갈린 모델

최근에 Anthropic에서 Fable 모델이 나왔습니다. 엄밀히 말하자면 원래 모델의 이름은 Mythos이고, 여기에 안전장치를 추가해서 제시한 모델이 Fable입니다. 가중치도 아키텍처도 완전히 동일한 같은 모델이고, 차이는 오직 배포할 때 어떤 세이프가드가 켜져 있느냐입니다. 그래서 이름도 일부러 어원이 같은 걸로 지었습니다. (Fable은 라틴어 fabula, Mythos는 그리스어. 둘 다 “이야기”라는 뜻입니다.) 기존에 Mythos는 기업들이 보안 검증 등을 수행할 수 있도록 Project Glasswing이라는 이름으로 승인된 소수의 고객에게만 제공되었습니다. 그리고 6월에 안전 분류기를 붙인 Fable 5가 일반 공개되면서 Mythos급 능력이 처음으로 대중에게 열렸습니다.

Fable의 안전 분류기는 세 가지 영역을 감시합니다.

  1. 사이버보안 – Mythos급 모델은 소프트웨어 취약점을 찾고 익스플로잇하는 능력이 압도적입니다. 실제로 Glasswing 파트너들이 이 모델로 주요 OS와 브라우저 전부에서 1만 건 이상의 고위험 취약점을 찾아냈습니다.
  2. 생물, 화학 – 유전자 치료 연구에 쓰이는 능력이 그대로 위험한 바이러스 설계에도 쓰일 수 있는, 전형적인 이중용도(dual-use) 문제입니다.
  3. Distillation – 모델의 능력을 뽑아내서(증류해서) 경쟁 모델을 학습시키는 시도.

여기에 걸리면 거부(refusal)가 아니라 Claude Opus 4.8로 응답이 넘어갑니다. 사용자에게도 이 사실이 표시되고, 전체 세션의 5% 미만에서만 발동한다고 합니다.

여기에 추가로 네 번째 영역이 있었는데, 바로 Frontier LLM Development(사전학습 파이프라인, 분산 학습 인프라, ML 가속기 설계 등)입니다. 이건 블로그에는 없고 시스템 카드에만 적혀 있었고, 위 세 가지와 달리 사용자에게 보이지 않게 작동했습니다. 방식은 prompt modification(사용자 요청 앞뒤에 보이지 않는 지시 붙이기), steering vectors(특정 레이어의 활성값 건드리기), PEFT(일부 파라미터만 미세조정)로 모델의 능력을 조용히 낮추는 것이었습니다. (엔트로픽은 사용자들의 반발에 48시간만에 해당 기능을 취소했습니다)

결론적으로 제 생각은 이렇습니다.

이걸 보면 인공지능 모델의 힘이 많이 강력해졌다고 볼 수 있고, 이를 일반 사용자에게 공개할 때의 안전장치 설계 자체가 하나의 핵심 기술이 되었다고 봅니다. 예전에는 “모델을 얼마나 잘 만드느냐”가 출시를 결정했다면, 이제는 “얼마나 잘 가둘 수 있느냐”가 출시를 결정하는 구조로 바뀐 셈입니다. 물론 뭔가 Anthropic에서 과장해서 광고를 하는 느낌도 있긴 하지만, 인공지능 모델 발전으로 인한 문제들이 충분히 우려되는 점은 사실인 것 같습니다.

World Model

올해에는 뭔가 월드 모델 자체를 기본 베이스로 깔고 가는 모델이 주가 되는 것 같다고 보였습니다. 물론 제가 로봇 부분에서만 다양한 인사이트를 찾게 되어서 그럴 수도 있지만, 모델들이 월드 모델의 가중치를 기반으로 동작하는 느낌이 강하다고 보였습니다.

VLM은 본다. VLA는 행동한다. 그런데 둘 다 “5초 뒤에 세상이 어떻게 될까”에는 답하지 못합니다. 그 빈칸을 메우는 게 월드 모델이고, 그래서 로보틱스 쪽에서는 VLA → WAM(World-Action Model) 으로 흐름이 옮겨가고 있습니다. 월드 모델 백본을 로봇 정책 안에 그대로 집어넣어서, 행동을 내뱉기 전에 머릿속에서 먼저 굴려보게 하는 방향입니다.

그런데 가장 강한 신호는 사실 하드웨어 쪽에 있었습니다. 구글이 TPU 8세대 기술 블로그에서 이렇게 썼습니다. “월드 모델은 현재의 next-token 예측 아키텍처에서 필연적으로 진화한 형태이며, TPU 8세대는 Genie 3 같은 월드 모델을 효율적으로 학습하고 서빙하기 위해 설계되었다.” 에이전트가 위험한 시행착오 대신 ‘상상’ 속에서 미래를 시뮬레이션하고 학습할 수 있게 하려면 그만한 인프라가 필요하다는 겁니다. 칩 설계 단계에서부터 월드 모델을 전제로 깔고 간다는 건, 이게 잠깐 유행이 아니라 방향이라는 뜻이라고 생각합니다

이걸 보고 느낀 것은, 이제 슬슬 World Model을 “어떻게 만들까”가 아니라 “어떻게 쓸까” 를 사람들이 고민하고 있는 것 같다는 점이었습니다.

정리

제가 이번에는 시간이 많이 없어서 주의 깊게 보지는 못했는데, 다시 정리하고 보니 이제는 칩 하나, 모델 하나로는 끝나지 않을 것 같다는 인공지능 시장의 흐름이 보였습니다.

  • HBM은 메모리 하나만 빨라져선 안 되니까 HBF라는 새로운 계층을 만들고 있고,
  • 구글은 TPU만이 아니라 호스트 CPU(Axion)와 네트워크(Virgo)까지 직접 만들고,
  • NVIDIA는 GPU만이 아니라 CPU·NIC·DPU·스위치를 묶어서 랙째로 팔고, 심지어 전력 공급망(800VDC)까지 다시 설계하고 있고,
  • Figure는 모델보다 공장(BotQ)을 먼저 지었습니다.

단순히 인공지능 분야에서 벗어나서 좀 많은 부분들에 대해서 변화가 있었던 것으로 보입니다. 앞으로도 인공지능 분야가 다양한 분야에 대해서 변화를 가져올 것으로 보이니 많은 관심을 가지고 보아야겠다고 느꼈습니다. 그리고 로봇 하는 입장에서 이 흐름이 깊게 와닿았습니다. 결국 로봇도 센서-연산-구동-전원-소프트웨어를 통째로 설계해야 뭐가 되는 물건인 걸 알게 되었습니다. 이게 왜 와닿았는지는 바로 다음 장에서 나올 텐데, 제 프로젝트에서도 Scout과 LeRobot이 따로 노는 걸 보면서 똑같은 걸 느꼈습니다.


연구실 일상 – 우편 배달 모바일 매니퓰레이터

그러면 김기현은 연구실에서 무엇을 했냐? 하면, 석준님, 우현님과 같이 하는 우편 배달 로봇을 계속 했습니다. 간단히 요약하면 이런 프로젝트입니다.

분명히 저의 퍼펙트한 계획상으로는 4월 즈음에 끝나길 기대했는데, 처음 해보는 작업이다 보니 생각보다 손이 훨씬 많이 간다는 것을 느꼈습니다. 그러면 제가 수행한 Task에 대해서 설명드리겠습니다.

1. Xlerobot 세팅

처음에는 LeRobot을 가지고 작업하는 Xlerobot을 구축했습니다. mobile까지 조작하는 코드는 이때 처음 보았기 때문에 좀 많이 헷갈리기도 했고, 해당 코드들을 이해하고 적용해서 구현하려면 LeRobot 코드에 대한 완벽한 숙지가 필요했기 때문에 이 부분들을 파악하고 구현하는 데 조금 고생했던 것 같습니다.

2. Xlerobot Teleoperation

Xlerobot 내부에 구현되어 있는 teleoperation 기능은 키보드 조작과 VR 조작 두 가지밖에 없었습니다. 그런데 둘 다 저희 Task에는 맞지 않았습니다.

  • 키보드 조작: 제가 원하는 대로 로봇팔의 자유도를 전부 다루기에는 너무 어려웠습니다.
  • VR 컨트롤: 실시간으로 오차가 누적되는 현상을 보였습니다.

그래서 저희가 하기로 한 우편물 배달 Task에는 적절하지 않다고 판단하고, LeRobot의 leader arm을 두 개 사용해서 양팔을 Teleoperation 하기로 하였습니다. 이 과정에서 여기저기 분산되어 있던 캘리브레이션 파일을 하나로 통합하고, 코드도 잘 합쳐서 양팔 컨트롤이 가능하도록 만들었습니다.

3. ArUco 마커 기반 동작 수행

해당 작업부터 정말 힘들었던 것 같습니다. mobile이 항상 동일한 위치에 정확히 멈춰주면 좋겠지만 현실적으로 불가능하기 때문에, 로봇팔 쪽에서 추가적인 보정이 필요했습니다. 보정 방법에 대한 조언을 태주님께 얻어서, ArUco 마커를 기준으로 end effector와의 관계를 풀어서 동작하게 하는 방식으로 접근하게 되었습니다.

  1. ArUco 마커를 인쇄해서 우편물 배달 상자에 부착
  2. 로봇팔에 달린 카메라의 intrinsic 파라미터 추정
  3. 카메라(cam)와 end effector(ee) 사이의 extrinsic 파라미터 추정 (hand-eye calibration)
  4. 이 값들을 PyRoki에서 IK를 풀 때 적용해서 연산할 수 있도록 구현

(영상이 재생되지 않는 관계로 링크에 첨부하였습니다)
https://drive.google.com/drive/folders/1OUl70HHr5Gnvg_JnFSsK2jVfv3l1a74p?usp=drive_link

결과적으로 변환 흐름은 ArUco → cam → ee 로 이어지게 됩니다. 여기에 ArUco와 ee의 상대좌표를 녹화하는 시스템을 만들어서, 우편물 상자의 위치가 이동하더라도 그 변화를 잡아서 따라가는 동작을 구현할 수 있도록 하였습니다.

4. SmolVLA 적용 실험

이 부분은 우현님이랑 제가 궁금해서 실험해 본 부분입니다. “VLA를 사용해서 동작을 학습하면 더 효율적이지 않을까?” 라는 생각에서 시작했고, 100~150개 정도의 에피소드를 녹화해서 학습을 진행해 보았습니다. 원래 녹화해서 LeRobot으로 넘기는 파이프라인을 안 만들어 놨어서 이때도 코드를 좀 수정했고, 수정을 한 뒤에 열심히 녹화를 수행한 결과 150개의 에피소드 끝에 우편물 하나를 들 수 있게 되었습니다.

그리고 우편물에서 주소가 적힌 부분을 카메라에 보여주는 동작을 수행하도록 text instruction(Pick up the mail from the 4th slot of the basket holder and present the white side to the camera라고 넣어주었습니다.)을 넣어주었더니, 텍스트가 희망하는 바를 인식하고 해당 흐름대로 따라가려는 경향을 10번 중 7번 정도 보이는 것으로 확인했습니다.

그래서 “주소를 카메라에 비춰주는 동작까지는 VLA로 해도 괜찮지 않을까?” 하고 생각했지만, 계산해 보니 애매했습니다. 슬롯이 2·4·6번으로 세 군데가 있었는데, 슬롯마다 150개씩 찍으면 대략 450개 이상의 데이터를 녹화해야 했습니다. 강건성까지 확보하려면 그 이상이 필요할 텐데, 투입 대비 효율이 너무 떨어진다고 판단했고 실험적인 시도로만 남기고 넘어가기로 하였습니다.

실험에 사용한 데이터는 아래의 데이터를 녹화해서 사용했고, 실험 결과는 아래 영상과 같습니다.

모델: https://huggingface.co/monozu-deving/Xlerobot-grap-post-index4-v1

데이터셋: https://huggingface.co/datasets/monozu-deving/Xlerobot-grap-post-index4

(영상이 재생되지 않는 관계로 링크에 첨부하였습니다)
https://drive.google.com/drive/folders/1OUl70HHr5Gnvg_JnFSsK2jVfv3l1a74p?usp=drive_link

5. Scout Mini로 베이스 교체

Xlerobot으로 녹화를 다 해놓고 나서, 실제로 실내를 자유롭게 돌아다니면서 수행하기에는 Xlerobot의 mobile 베이스가 적합하지 않다는 것을 알게 되었습니다.

하지만 저는 팔 두 개가 붙어 있는 프레임 구조는 그대로 유지하고 싶었고, 이를 Scout Mini에 그대로 옮겨 붙이는 방법으로 접근하기로 했습니다. 그래서 Scout Mini에 장착할 수 있는 프레임을 설계해서 끼울 수 있도록 하였습니다. 그런데 해당 설계의 문제는 Scout Mini가 견딜 수 있는 하중을 넘어선다는 것이었습니다. 그래서 결국 Xlerobot의 바구니 구조만 최대한 활용해서 하중을 줄이는 방향으로 되돌아왔습니다.

6. 캘리브레이션이 안 맞는 이슈

하드웨어 이슈인 로봇 본체 문제를 해결하고 보니… 추가된 Task인 엘리베이터 버튼 누르기에서 자꾸 원하는 위치를 벗어나는 모습을 보여주었습니다. 문제를 해결하려면 원인을 찾아야 하는데, “그 원인을 어떻게 수치적으로 보여주지?” 라는 고민이 생겼습니다. 그래서 고민하다가 시각화 시스템을 하나 더 만들었습니다.

그 결과 위 사진처럼 동일한 위치임에도 불구하고 캘리브레이션이 정확히 맞지 않는다는 것을 확인했습니다. 그래서 지금까지 녹화한 데이터를 버리는 것을 감수하고서라도, 엘리베이터 버튼 누르는 동작을 강건하게 수행하기 위해 캘리브레이션을 처음부터 다시 하기로 했습니다. 이번에는 좀 더 제대로 하기 위해 아래와 같이 진행했습니다.

  • intrinsic 캘리브레이션 – ChArUco 보드를 사용
  • 자동 촬영 시스템 – 마커 코너가 일정 개수 이상 검출되면 스스로 촬영하도록 구현 → 저번에 석준님과 둘이서 복잡하게 캘 하던 과정보다 혼자서도 훨씬 수월하게 진행했습니다.
  • 검증 – RMS reprojection error를 기준으로 오차 범위에서 크게 벗어난 값이 없는지 검토하면서, 이를 줄여나가며 캘리브레이션 수행

그렇게 캘리브레이션을 다시 수행한 결과, 눈으로 봐도 틀어짐 없이 캘이 맞은 것을 확인할 수 있었고, 녹화를 했을 때도 이전보다 확실히 강건하게 동작했습니다.

7. 프로젝트의 한계

프로젝트를 진행하면서 명확하게 느낀 한계가 세 가지 있었습니다.

첫째, low-cost 하드웨어의 한계입니다.
최근에 인스타에서 본 자료에서도 똑같은 이야기가 나왔습니다. 3D 프린팅으로 만든 로봇팔은 움직일 때마다 오차가 누적되거나, 나사가 제대로 고정되지 않고 계속 변수를 유발해서 결과적으로 틀어지는 현상이 나온다는 내용이었습니다. 저희 로봇도 나사가 풀리면 풀릴수록 캘리브레이션이 자꾸 틀어지고, 동작이 원활히 되지 않는 것을 확인했습니다. 그 외에도 전력 이슈, 카메라 내구도 문제 등등 다양한 문제들이 하드웨어에서 발생하는 것을 느꼈습니다.

둘째, 정보 부족입니다.
프로젝트를 진행하면서 문제가 생겨도 어떻게 찾아야 할지 막막했습니다. 관련된 논문이나 평가 방식을 찾아보려 해도 자료가 거의 없다시피 했고, 실제로는 실무 관점에서 해결되는 부분이 더 많아서 기술적으로 뭔가 공유되어 있지 않은 느낌이 들기도 했습니다.

셋째, 작업 배분과 시간 스케줄링입니다.
제가 많이 바빴던 것도 있어서 스케줄링이 명확하게 되지 않았습니다. 작업 중에 변수가 생기면서 매번 새로운 게 튀어나오는데, 그걸 실시간으로 대응하면서 스케줄링까지 하기에는 제가 너무 빈틈이 많았다고 느껴졌습니다. 그리고 제가 모빌리티 시스템 자체를 잘 모르다 보니, 시간이 조금 더 있었다면 이런 것도 공부해서 같이 했으면 조금 더 빨리 끝나지 않았을까 하는 생각이 들었습니다.

+ 데이터셋을 촬영하기에 별로 좋지 않은 환경이었습니다.
엘레베이터 앞에서, 그리고 엘레베이터 안에서 로봇 동작을 촬영하는데 여름에 에어컨 없는 곳에서 촬영을 하다 보니 너무 더웠습니다. 그리고 엘레베이터 근처에 전기를 공급받을 수 있는 곳도 없고, 무엇보다 엘레베이터에 부착된 아르코마커를 누군가 자꾸 제거를 하는데, 이러면 치수를 측정했어도 다시 녹화를 해야 합니다. 그래서 일관된 환경을 로봇에게 제공하기에 너무 어려웠다는 결론을 내렸습니다.

8. 앞으로 모바일 매니퓰레이터를 하실 분들께

프로젝트를 하면서 몸으로 느낀 부분들이 있어서, 나중에 모바일 매니퓰레이터를 하실 분들을 위해 세 가지만 남겨두려고 합니다.

첫 번째, 전선 관리를 잘하시면 좋겠습니다.

현재 Scout Mini 위에 올라간 LeRobot을 보시면 배선이 굉장히 복잡하다는 걸 아실 겁니다. 저 배선을 그대로 고정해 두고 쓴다면 문제가 없겠지만, 저와 우현님이 사용하면서 세팅이 계속 바뀌다 보니 전선이 꼬이기도 하고 중간에 빠지는 경우도 많았습니다. 세팅 변경을 전제로 배선을 설계하시면 좋겠습니다.

두 번째, 완전한 무선 시스템 구축입니다.

이번에는 LeRobot leader arm을 사용했는데, 굉장히 불편한 점이 많았습니다. leader arm에 들어가는 전원선, 그 전원선에 전원을 공급하는 배터리, leader arm의 정보를 전달하는 USB 케이블까지… 유선 시스템으로 구축해서 지속적으로 사용하기에는 굉장히 힘든 구성이었습니다.

그리고 가장 큰 문제는 엘리베이터였습니다. 엘리베이터 앞과 내부에는 와이파이가 잘 잡히지 않기 때문에, 엘리베이터 버튼을 누르는 동작을 녹화하려면 키보드·마우스·모니터를 추가로 챙겨가야 했습니다. 저는 몇 개 되지도 않는 데이터를 녹화하면서 굉장한 불편함을 느꼈고, 나중에 더 많은 데이터를 여기저기서 찍을 때는 훨씬 편한 시스템이 필요할 것 같다고 느꼈습니다.

세 번째, 시스템 통합입니다.

Scout과 LeRobot은 전원도 다른 시스템이고 코드상으로도 다른 시스템입니다. 분업을 하는 과정에서는 오히려 좋았지만, 몇 가지 기능을 한 번에 수행하거나 코드를 통합할 때는 환경을 여기저기 오가면서 작업해야 하기 때문에 “굳이 이렇게까지?” 싶은 비효율이 생길 수 있겠다는 생각을 했습니다. 결과적으로 하나로 패키징해서 최적화하는 데에는 한계가 있어 보였다, 라고 생각하시면 될 것 같습니다.

앞에서 트렌드 얘기할 때 “이제 칩 하나로는 안 되고 시스템 전체를 통합해야 한다”고 적었는데, 사실 이게 제일 크게 와닿았던 게 바로 이 지점이었습니다. 그 외에도 다양한 문제들이 존재했지만, 위 세 가지가 데이터를 모으거나 실험을 하면서 가장 직관적으로 저에게 다가온 문제들이었습니다. 앞으로 모바일 매니퓰레이터를 하시는 분들은 이런 부분들을 미리 잘 개선하고 시작하시면 좋을 것 같습니다….

9. Conclusion

결과적으로 이 프로젝트를 하면서 좀 많은 것들을 배웠습니다. 이렇게 같이 프로젝트를 해볼 수 있는 기회가 처음이었고, 처음 해보는 것이다 보니 부족한 부분도 많았습니다. 그럼에도 어찌저찌 진행을 해냈고, 제가 할 수 있는 부분에서는 나름 의미 있는 결과를 얻었다고 생각합니다. 특히 “안 되는 이유를 수치로 만들어야 고칠 수 있다” 는 것을 캘리브레이션 이슈를 겪으면서 제일 크게 배운 것 같습니다. 눈으로 봐서 “뭔가 이상한데?” 로 끝났으면 아마 지금까지도 헤매고 있었을 겁니다.


연구실 1년기

우선 연구실에서 생활을 거의 1년 보냈다는 사실이 좀 실감이 나지는 않지만, 어떻게 저떻게 지내다 보니 벌써 1년이라는 시간이 왔습니다.

아무것도 모르는 상태로 입학해서 한 학기 학교를 보내고 바로 연구실로 들어온 제가, 지금 생각해도 무슨 생각이었는지 모르겠지만, 지나고 나니 후회되는 선택은 아니었다고 생각이 됩니다.

첫 학기를 보낼 때는 부족한 것도 많고, 할 수 있는 것도 많지 않았습니다. 그래도 공부도 하고 옆에서 많은 정보를 듣다 보니 많이 배울 수 있었고, 저한테 부족한 부분이 무엇인지도 알 수 있었습니다. 그래서 부족한 부분을 채우기 위해서 한 학기 동안 좀 다양한 일을 했던 것 같고, 작년 연말 회고록에 적은 것처럼 여러 작업을 했던 것 같습니다.

올해는 좀 하고 싶은 게 많아졌습니다. 그래서 동아리도 하고, 부스 운영도 하고, 연구실 활동도 하고 진짜 많은 것들을 한 것 같습니다.

물론 이 모든 걸 하면서 연구실 활동까지 본격적으로 하기에는 저에게 주어진 시간이 턱없이 부족했습니다. 더군다나 일주일에 3번을 아침 9시 수업을 듣다 보니, 일을 다 하고 늦게 퇴근할 수 있는 날은 금요일밖에 없었던 것 같습니다.

이 중에 뭔가 하나를 좀 내려놓아야겠다는 생각을 하긴 했지만, 제 성격상 절대 내려놓을 수가 없었습니다. 저는 제가 무언가를 달성하지 못하면 뭔가 오기가 생겨서 그걸 끝내는 성격이라서, 이 많은 것들을 담당하면서도 “진짜 끝까지 해보자” 라는 마인드로 했던 것 같습니다.

그래서 제가 평소에 좀 열받으면 혼잣말을 하는데(저희 방이랑 최근에 지냈던 모빌리티 방 분들 죄송합니다;;), 이 혼잣말로 저는 뭔가 좀 동기를 얻는 것 같습니다. 그래서 금요일 밤이면 새벽까지 하던 걸 끝내고 가기도 하고, 주말에도 가끔 나와서 하던 걸 마무리하기도 합니다.

그렇게 해서 어찌저찌 Xlerobot 프로젝트도 하고, 연구실에 필요한 일 있으면 열심히? 했던 것 같습니다.

연구실에 있으면서 좋았던 점은, 여러 명의 시선에서 바라본 기술적인 부분을 배울 수 있다는 점이었습니다. 이런 기회는 일반적으로 경험할 수 없기 때문에 매우 좋은 기회라고 생각했고, 유익했습니다. 그 외에도 개인 자리가 있고, 듀얼 모니터가 있고, GPU를 쓸 수 있고, 얼음 정수기가 있고, 로봇도 마음껏 쓸 수 있고, 3D 프린터가 있고 등등 다양한 것들이 너무 좋았습니다.

아쉬웠던 것은 제가 아무래도 1년밖에 없었다 보니 논문을 쓰지 못한 게 아쉬웠습니다. 제가 아는 게 그렇게 많지도 않고, 구체적으로 하고 싶은 연구 목표도 없다 보니, 이런 점에서 논문을 쓰지 못해서 이런 경험을 하지 못했다는 점이 좀 아쉽기도 했습니다.

인간 김기현의 인생에 대해서…

이제 마지막으로 기술 얘기 말고 사람 얘기를 좀 해보겠습니다.

올해의 목표는?

제가 2025년을 마치는 아듀 세미나를 하면서 소박한 다짐을 이렇게 적었습니다. 결론적으로 말씀드리자면 한 70% 정도는 제가 목표한 바를 이루었다고 생각합니다.

  • 하고 싶었던 것들 — 축제 부스 운영, 축제 구경, MT, 개총, 종총… 진짜 하고 싶었던 건 다 했다고 생각이 됩니다.
  • 공부 열심히 하기 — 많은 것들을 벌여놓고 하다 보니, 나름 선방했다고 생각합니다.
  • 운동 시작하기 — 좀 반성해야겠씁니다….(이번에 페스티벌을 가면서 체력을 키울 필요가 있다고 생각했습니다…)
  • 자주 놀러 다니기 — 잘 놀러다녔다! 즐겁다!
  • 사진 많이 찍기 — 이번 학기 동안 갤러리에 생긴 사진을 세어 보니 대충 1000장 정도가 더 생겼더라고요. 이건 확실히 지킨 것 같습니다.

이번 학기의 나는 무엇을 하였는가?!!?

저에게 있어서 이번 학기는 진짜 정신없는 한 학기였습니다.
우선 저는 아직 2학년이기 때문에 19학점을 들었습니다. 시간표도 영 좋지 않은 상태였고요.

이 시간표를 소화하면서 동아리를 2개 했습니다.

  • SMARCLE (과 동아리) — 집행부원 + 스터디 1개 참여 + 스터디 1개 운영(감독까지)
  • ALOM (중앙 동아리) — 스터디 2개(Blender 메인 총괄 멘토 + 기계학습 멘토)

여기에 축제 기간에 중앙 동아리 부스 운영까지 하면서 수업 과제도 하고, 연구실 일도 하고… 위에서 적은 우편 배달 로봇까지 붙잡고 있었으니, 다시 생각해도 진짜 정신없는 한 학기였다는 생각이 듭니다.

그리고 제 성격이 가만히 있는 건 못 참아서…시간표랑 일정 사이사이에 일정을 계속 추가해서 열심히 생활했습니다…
그래도 후회되는 선택을 했다고 생각한 적은 한번도 없습니다!

김기현의 자랑 섹션

🎧 플레이리스트

제가 최근에 생긴 취미 중에 하나인 플리 만들기입니다. 혹시 관심 있으신 분은 제가 느좋 노래 계속 업데이트 하고 있으니 한번 감상해 주시면 좋을 것 같습니다.

👉 김기현의 Spotify 플레이리스트

📸 일본 여행

그리고 이번에 일본을 갔다 왔는데요(장소 & 맛집 추천해 주신 근택님 감사합니다), 여행 가실 때 색다른 사진 찍고 싶으시면 일회용 필름 카메라 챙겨가 보시는 걸 추천합니다. 제가 평소에 사진 찍는 걸 좋아하는데, 필름 카메라 챙겨가서 “밝은 곳에서” 사진 찍으면 이쁜 색감으로 사진이 나와서 이번에 인화까지 했는데 매우 만족했습니다.

🖼️ 김기현 갤러리

이번 학기동안 제가 찍은 사진들을 공유하면서 마무리 할려고 합니다

https://even-edge-0ec.notion.site/3a919013341680de887afb59666f3668?source=copy_link

⚠️열심히 노력해서 만들었어요. 꼭 봐줘요.⚠️


마치며

뭔가 전하고 싶은 말은 많은데 갑자기 이렇게 적으려고 하니까 흠………….. 좀 막막하긴 하네요….(나머지 말은 군대 갔다 와서 하지 않을까요…?)

일단은 모든 연구실 분들, 마지막까지 잘 챙겨주셔서 너무 감사합니다…. 최고…

그리고 1년 동안 잘 가르쳐주시고 잘 챙겨주신 로보틱스 팀 분들 너무 감사하고, 같이 프로젝트 진행해 주신 석준님, 우현님 너무 감사합니다. 그리고 같이 URP 동기였던 정우 형, 재윤 형, 예은 누나, 찬미 누나, 그리고 인하 형 항상 잘 놀아줘서 감사합니다… 그리고 마지막으로 잘 지도해 주신 교수님 정말 감사드립니다….

실은 제가 모두에게 해드리고 싶은 말이랑 감사한 일이 너무 많은 것 같아서 편지로 좀 적었습니다. 아래 링크 들어가 보시면 되고, 아마 이걸 올리고 나서나 며칠 뒤에 모두에게 슬랙으로 비밀코드를 보내드릴 것 같습니다. 한 번 확인해 보시고, 답장 하시려면 슬랙이나 인스타로 답장 남겨주세요 👍

👉 https://monozu-deving.github.io/thanks_for_rcv/

지금까지 김기현이었고, 항상 감사했습니다ㅏㅏㅏ

Author: 김기현

Leave a Reply