인프콘 2023 후기

시작하며

 오늘은 얼마 전에 다녀온 인프콘에 대한 글을 포스팅 할 것이다. 이미 다녀온 지 며칠되어 기억이 휘발되고 있는 가운데, 더 휘발되기 전에 글로 인프콘에 대한 후기글을 작성해보고자 한다.

 지난 7월에 있었던 인프콘에 참가 신청을 하였는데 무지막지한 경쟁률 때문에 안타깝게도 참가자에는 선정되지 못하였다. 1500명 가량을 뽑는데, 약 9000명이 지원하였다고 한다(무려 6대 1의 경쟁률..). 평소에 너무나 가고 싶었던 컨퍼런스였기에 매일 당근마켓을 모니터링 하며 양도권을 얻고자 노력했다.

 인프콘을 사흘 정도 남겨두고 너무나 감사하게도 어떤 분이입장권을 양도해주셔서 운이 좋게도 8월 15일에 인프콘에 다녀올 수 있게 되었다. 앞으로 있을 인프콘도 경쟁률이 높을 거 같은데, 1차로 참가자에 선정되지 못했다고 해서 포기하지말고 당근을 적극 활용해보도록 하자.

 

오프닝 세션 및 컨퍼런스 환경

 코엑스에서 주최되는 꽤나 규모가 큰 컨퍼런스였던만큼 사람들도 엄청나게 많았다. 9시부터 입장이 가능하고, 10시부터 오프닝 세션이 시작되는데, 나는 여유롭게 9시반 쯤에 입장을 하였는데도 이미 컨퍼런스장은 사람들로 가득차 있었다. 

 인프콘과 함께하는 기업들로는 요기요, 엔라이즈, 29cm, 점핏, HERREN, JETBRAINS, 카카오뱅크, 카카오페이, 몽고디비, 무신사, 메가존 등 다양한 기업들이 있었다. 각각의 기업 부스에서 이벤트를 참여하면 스탬프를 찍어주고, 여러 굿즈들을 주었다.

스탬프는 4개를 찍을 때마다 인프런 본부로 가서 사은품 뽑기 1회를 할 수 있는 기회가 주어진다.

여러 기업 부스들

 10시가 되자 이형주 대표님의 오프닝 연설이 시작되었다. 오프닝 세션에서는 인프런이 그동안 어떻게 성장해왔고, 앞으로 어떻게 성장해나갈 것인지에 대한 말씀을 하셨다(올해 인프런 회원이 무려 118만명이나 되었다고 한다). 그리고 우리의 성장이 모두의 성장이라는 모토로 개발자들과 인프랩이 함께 성장하자고 하셨다. 다음으로 이동욱 CTO님의 연설이 있었는데, 매번 유튜브로만 봤던 분을 실제로 뵈니 굉장히 낯설고 신기했다. 생각보다 덩치가 크시고 몸이 좋으셔서 놀랐다. 개발과 더불어 운동도 열심히 하시는 거 같았다.

인프콘 오프닝

개발자들의 BTS 이동욱 CTO님

 이동욱 님은 지난 1년간 인프랩에 어떤 개편이 있었고, 개편을 통해 어떤 성과를 이루었는지, 또 인프랩의 비전에 대한 이야기를 하셨다. 주요 목표로 기억나는 것은 올해 하반기에 AI를 이용하여 모든 동영상에 자막을 넣는 기능을 추가할 것이라고 하셨다. 그리고 '나이키의 경쟁사는 아디다스가 아닌 닌텐도다' 라는 말씀을 하시며 인프런의 라이벌을 노션이라고 생각하고 계시다고 했다.

 또한 노션의 모든 이력서를 렐릿으로 옮기는 것이 목표라고 하셨다. 그렇게 인프런을 개발, 커리어, 채용 등 모든 분야를 지원하는 라이프타임 커리어 플랫폼으로 만들 것이라는 비전을 설명하셨다. 나는 평소에 인프런이라는 서비스에 대하여 강의를 제공하는 서비스가 과연 어느 정도의 성장을 이룰 수 있는 지에 생각을 해봤었는데 이렇게 통합 서비스로의 성장 목표를 들으니 굉장히 신선했다. 그리고 성과 발표 및 여러 지표들을 발표하실 때,  '~~지표는 작년 대비 ~~% 상승하였고,  ~~지표는 기존 성능 대비 ~~% 개선되었다.'와 같이 항상 숫자를 기반한 지표들 위주로 발표를 하시는 점이 인상 깊었다.

오프닝 세션이 끝나고 10분의 휴식 후, 정규 세션이 시작되었으며 내가 들은 정규 세션 중에서 기억에 남았던 세션들 몇 개를 정리해보고자 한다.

 

 

타입스크립트는 왜 그럴까?: 집합으로 이해하는 타입스크립트 - 이정환

 타입스크립트의 복잡한 타입 간의 관계를 집합의 개념을 접목시켜, 타입스크립트에서의 타입에 대한 이해를 쉽게 설명해주셨다. 사진 찍는 것을 깜빡하는 바람에 설명해주신 내용에 대한 사진은 강의 자료로 대체하겠다.

정사각형은 직사각형이 맞지만 직사각형은 정사각형이 아니다(정사각형은 서브타입, 직사각형은 슈퍼타입)

• 타입스크립트의 타입은 사실 여러 종류의 집합들이고, 각각의 집합들은 계층이 존재한다.
• 타입스크립트의 모든 타입들은 집합으로써 서로 포함하고, 포함되는 관계를 갖는데, 이런 관계에서 다른 타입을 포함하는 타입을 슈퍼타입(부모타입)이라고 부르고, 포함되는 타입을 서브타입(자식타입)이라고 한다.
• 집합의 포함 관계를 예로 들어, 서브타입의 값을 슈퍼타입의 값으로 취급하는 것은 가능하나, 슈퍼타입의 값을 서브타입의 값으로 취급하는 것은 허용되지 않는다.

• 서브 타입의 값을 슈퍼 타입의 값으로 취급하는 것을 업 캐스팅, 슈퍼 타입의 값을 서브 타입의 값으로 취급하는 것을 다운 캐스팅이라고 한다.
• 업 캐스팅은 모든 상황에서 가능하지만 다운 캐스팅은 대부분의 상황에서 불가능하다.

• 위 집합 관계에서 unknown과 any는 타입 계층도 상에서 가장 위에 위치한다는 뜻이며, unknown(any) 타입은 모든 타입의 슈퍼 타입이다.
• 즉, unknown 타입은 모든 타입을 부분집합으로 갖는 타입스크립트 전체 집합이다.
• 그리고 반대로 never 타입(공집합) 타입 계층도의 가장 아래에 위치하며, 아무것도 포함하지 않는 집합을 뜻한다.

unknown 타입의 업 캐스팅

• unknown 계층은 타입 계층에서 제일 위에 위치함으로 모든 타입을 unknown 타입으로 업 캐스팅 시킬 수 있다.
• 위 예시에서는 number, string, boolean 등의 타입을 unknown 타입으로 업 캐스팅 시키는 예시

unknown 타입의 다운 캐스팅(대부분의 상황에서 불가능)

• unknown 타입은 모든 타입을 부분 집합으로 갖는 전체 집합이기에 (any를 제외하고는) 다운 캐스팅이 안된다.

• never 타입은 모든 타입들의 하위 집합(서브타입)이므로 모든 타입으로의 업 캐스팅이 가능하다.
• 위 예시에서는 never 타입을 number, string, boolean 등의 타입으로 업 캐스팅 시키는 예시

any 타입은 계층 관계도를 무시하는 치트키

• any 타입은 모든 계층 관계도를 무시하는 치트키 같은 타입이다.
• any 타입은 모든 타입의 슈퍼 타입이 될 수도 있고, 모든 타입의 서브 타입이 될 수도 있다.

any 타입은 모든 타입에 대하여 업 캐스팅, 다운 캐스팅이 가능하다.

• 따라서 any 타입은 모든 타입으로 다운 캐스트 할 수 있으며, 모든 타입은 any 타입으로 업 캐스트 할 수 있다.

이 외에도 Union 타입과 Intersection 타입을 집합에서의 합집합과 교집합의 개념으로 설명해주셨다. 끝으로 본인 강의의 50% 할인 쿠폰을 뿌리시면서 세션을 마무리하셨다. 타입스크립트에 처음 입문하거나 기본 개념을 탄탄히 다지고 싶은 사람에게 추천해주고 싶은 강의였다. 확실히 개념을 쉽게 설명하시긴 했지만 타입스크립트에 대해 좀 더 깊은 내용을 다뤄주셨으면 어땠을까라는 자그마한 아쉬움이 남는 세션이었다.

인프런 - 한 입 크기로 잘라먹는 타입스크립트 (이정환님)

 

 

인프런 아키텍쳐 2023-2024 -이동욱

 두 번째 시간에는 이동욱 님의 인프런 아키텍쳐 2023-2024를 들으러 갔다. 인프런이라는 서비스의 아키텍쳐는 어떻게 이루어져 있을까가 궁금해서 해당 세션을 선택했다. 

 이 세션에서는 2022년에 목표로 두었던 인프런의 아키텍쳐 개선 사안에 대한  리뷰, 그리고 현재 가지고 있는 구조적 문제와 해결책 등을 주제로 진행을 하였다.

 인프런의 작년 목표는 기존에 있던 하나의 거대한 레거시 코드를 프론트엔드와 백엔드로 분리시켜 각각의 역할에 집중할 수 있도록 구조를 개선하는 것이었다. 허나 1년이 지난 지금까지도 거대한 레거시 코드는 그대로이고, 코드를 분리하지 못했다고 하셨다. 그 이유로는 조직 형태의 변화가 있었고, 기존에는 기능 조직 위주(디자이너팀, 개발팀, 백엔드팀, 프론트엔드팀이 있고, 각각의 팀장이 있는 구조)로 돌아가는 방식에서 목적조직(한 팀에 PM 1명, 디자이너 1명, 백엔드 개발 n명, 프론트엔드 개발 n명으로 구성하여 특정한 기능 개발을 목표로 하는 조직) 형태로 변경했다고 하셨다.

이렇게 조직의 구성을 바꾸니 당장의 실행력, 제품 출시 속도는 증가 했지만, 장기적은 제품 안정성 및 조직 안정감(만약에 팀에 한 명 있는 PM이나 디자이너가 퇴사하면 팀이 제대로 굴러가지 않게 됨)이 저하됐다고 하셨다. 이러한 문제를 해결하기 위해 시도했던 여러 시도들이나 그 과정에서 겪었던 시행착오 및 결과가 이 세션의 핵심 내용이었다.

인프런 서비스의 아키텍쳐

해결 시도 방법

• 기존 레포를 조직 수만큼 복제 후, 자신의 팀과 무관한 코드는 모두 삭제. 각자의 팀에서 필요한 부분만 집중해서 개발할 수 있는 환경 구축

결과

• 자신의 팀에서 사용하는 조직 코드만 남아 아키텍쳐를 개편하기 훨씬 쉬워짐

새로운 문제점 발생

• 각자 본인들의 부분을 개발하다보니 내부 API 호출이 많아져서 네트워크 리소스 및 트래픽 비용이 증가했다
  • 기존 public IP로 접근할 때 발생하는 비용을 줄이기 위해 private load balancer 도입
• 동일한 DB를 여러 곳에서 사용 -> 테이블 변경에 대한 공통 슬랙 채널을 만들어 DDL을 공유하고 호출된 SQL의 출처를 파악하기 위해 프로젝트마다 DB 계정을 분리

나는 프론트 개발을 주로 하다보니, aws나 DB 관련 얘기가 나올 때, 정확하게 이해하지는 못했다. 하지만 하나의 서비스를 운영하는 데 있어서 조직 단위에서 겪은 문제점, 아키텍쳐 단위에서 겪은 문제점들을 듣고, 이를 체계적으로 해결한 과정을 들으니 굉장히 신기한 느낌을 받았다. 나중에는 나도 저런 조직적 단위의 문제를 해결하는 시니어가 되겠다고 생각하게 되었다.

•  

 

 

안타깝게도 오늘의 TDD는 실패한 것 같군요. 내일은 가능할지도...? -한윤석

 평소 개발을 하거나 회사 업무를 할 때, TDD를 도입해보고 싶어서 이 세션을 선택했다. TDD를 도입함에 있어 가장 큰 걸림돌은 바로 TDD를 어떻게 적용하는 지 모르는 것과 TDD를 사용하는 방법의 생소함을 이유로 들 수 있다. 해당 세션에서는 '거꾸로 연구하기'라는 개념을 통해 TDD를 실무에 적용하는 방법을 알려줬다.

 우리는 보통 문제를 해결할 때, 얼렁뚱땅 문제를 해결한다. 이렇게 저렇게 해보다가 답이 나오면 끝이다. 왜 성공했는 지와 어떻게 성공했는 지는 중요하지 않다.

3L, 5L 물통을 이용하여 4L의 물 만들기

 3L와 5L짜리 물통을 이용하여 4L의 물을 구하는 문제를 예로 들어보자. 보통 사람들은 두 물통에 물을 넣었다 버려봤다 하면서 우연히 4L의 물을 만들면서 문제를 해결한다. 전혀 체계적이지 않다.

 TDD를 위한 '거꾸로 연구하기'에서는 체계적으로 문제를 해결하는 방법을 소개한다.

거꾸로 연구하기의 단계는 위 사진과 같다.

1. 요구하고 있는 것으로부터 시작해서 그것을 이미 찾은 것처럼 가정한다.

  => 4L의 물을 이미 얻은 것으로 가정하고 시작한다.

2. 원하는 결과는 어떤 전제로부터 이끌어 낼 수 있는 지 생각한다.

  => 어떤 전제가 있어야 4L의 물을 얻을 수 있는 지 생각한다.

  => 4L의 물을 얻기 위해서는 가득 찬 5L의 물통에서  1L를 버리거나 1L가 들어가 있는 5L짜리 물통에 3L의 물을 넣는 경우, 총 2가지가 있을 수 있다.

  => 첫 번째 경우에서 5L 물통에서 1L만 버리는 경우는 불가능 하기에 두 번째 경우로 생각해보자.

  => 5L 짜리에 1L의 물이 들어가기 위해서는 6L - 5L = 1L를 통해 구현이 가능하다. 이는 3L짜리의 물통에 2번 물을 가득 담아 5L 짜리 물통에 옮기고, 5L 물통의 물을 다 버린 후, 3L 물에 담겨 있는 1L의 물을 5L짜리 물통에 옮긴다.

 

위 관점을 코드에 적용시켜보면 다음과 같은 단계를 가진다.

1. 실패하는 테스트를 작성한다.(== 문제 상황을 작성한다.)

=> 주어진 초기 상황이나 사전 조건등을 정의(given)한다

2. 테스트를 통과시킨다.(== 이미 답을 찾을 것처럼 테스트 케이스를 작성한다.)

=> 정답이 되는 then(코드 실행 후, 기대되는 결과)을 설정한 후, 테스트를 통과시킨다.

3. 리펙토링한다.(어떻게 하면 위 과정을 최적화시킬 수 있을 지 고민한다.)

=> 어떤 동작이나 액션을 실행했을 때(when) 결과값을 얻을 수 있는 지, 어떻게 하면 답을 최적화하여 찾을 수 있을 지 고민한다.

읽어보면 좋을 자료들

 기존의 문제 푸는 방법과 TDD적 사고 방식은 접근 방식에서 차이가 있다는 것을 알게 되었고,  TDD를 도입하기 위해서는 발상의 전환이 필요하다는 것을 알게 되었다. 위 사진은 발표자님께서 TDD와 같이 공부하기 좋은 자료들을 정리해놓은 것이니 나중에 시간이 나면 한 번 읽어봐야겠다.

 

 

어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들 - 김영한

 제일 듣고 싶었던 세션이자 점심시간 직후인 2시에 시작하는 세션이었다. 그런데 코엑스의 인파는 생각보다 많았고, 음식점에서 메뉴가 나오는 시간은 생각 이상으로 오래 걸렸다.. 허겁지겁 밥을 먹고 1시 55분에 세션장으로 입실하려고 했는데, 정원 초과로 못들어갔다..새삼 김영한 님의 인기를 체감할 수 있었다. 나중에 인프런에 따로 영상이 올라오면 그걸로 내용을 정리하고자 한다.

교훈:인기있을 거 같은 세션은 미리미리 오픈런 하자..!!!

 

 

주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드 -배휘동

 이 세션에서는 주니어 프론트엔드 개발자들의 목표 설정, 행동 계획, 단기적 성과, 장기적 역량 등을 향상시킬 수 있는 방법 및 탁월한 개발자가 되기 위한 필수 역량을 연구 결과를 토대로 발표했다.

탁월한 개발자의 5가지 필수 역량

1. 훌륭한 코드를 짠다.

•  단순히 작동하는 걸 넘어 훌륭하게 만들 디테일에 주의를 기울인다.(에러 핸들링, 메모리, 성능, 보안, 스타일)
• 주니어에게 가장 중요한 것은 역량! 그러나 사람들이 기대하는 '훌륭함'의 기준이 아주 높지 않음에 유의
• 일정 수준을 넘어가면 다른 역량을 키우는 노력이 더 효율적이다.
• '훌륭한 코드를 짠다'에 대한 발표자님의 개인적 해석 => 코드 품질에 대한 자신만의 일관된 관점을 갖고, 고객 요구사항을 만족하는 코드를 빠른 속도와 적은 버그로 가독성 있게 작성한다.

 

2. 근거 기반 의사결정을 연습한다.

• 의사결정의 결과보다는 프로세스를 개선하는 데 집중하는 게 유리하다
  • 문제 정의 -> 현재 가진 정보에 기반해 반증 가능한 가설 수립 -> 추가로 필요한 정보 판단해서 습득 -> 의사결정 및 행동 -> 결과 관찰 -> 피드백
• 데이터에 기반하되 편견에 빠져 해석하거나, 성급하게 결론 내리지 않기
  • 새 정보를 얻었다면 불편하더라도 기존 판단을 재고해 봐야함
    • 발표자님은 매주 수요일에 운전을 하면서 전화 코칭을 하는 루틴이 있었는데, 상대방에게 '운전을 하면서 전화를 하는 것은 음주운전만큼 위험한 행동이다.'라는 말을 들었다고 한다. 전화 코치는 본인의 루틴이었기에 처음에는 좀 언짢아 하셨지만, 찾아보니 맞는 말이어서 전화 코칭을 그만두셨다고 한다.
  • 디버깅 할 때, 이건 내 문제가 아니라고 생각하면 대부분 틀림. 문제의 원인이 나와 관련 없는 라이브러리, 브라우저, 네트워크, 하드웨어 문제라고 결론을 내렸을 때, 대부분 틀린 원인 규명이라는 뜻.
  • 여유를 가지고, 열린 마음으로 다양한 외부 관점을 받아들여 큰 그림으로 보기
  • 다양한 양질의 정보가 내 주변에서 흘러가게 하는 시스템 구축하기(뉴스, 커뮤니티, 스터디 등)

 

3. 동료의 효과적 의사결정을 돕는다.

• 탁월한 개발자는 본인이 확보한 유용한 정보와 성공 및 실패 경험을 공유하여 동료를 성장시키고, 팀의 생산성을 높이고, 결과적으로 본인이 속한 조직이 더 나은 의사결정을 할 수 있도록 도움
• 주니어라면 저평가, 거절, 민폐의 두려움을 이겨내고 고맥락으로 질문 및 부탁하는 습관을 가지면 좋음
  • 신뢰가 쌓여야 취약성을 드러낼 수 있는 게 아니라, 취약성을 드러내야 신뢰를 쌓게 됨(본인이 부족한 부분을 상대방, 시니어에게 정확하게 인지시켜야 신뢰가 쌓인다는 뜻)
  • Don't Make Me Think: 어려움을 겪고 있는 flow가 A - B - C라면 C만 물어보지 마라.
• 이런 행동이 촉진되려면 취약성과 투명성에 높은 가치를 두는 문화를 구축해야 함.

 

4. 직업의 현재 가치를 극대화한다.

• 나중에 문제가 될 만한 부분이나, 요구사항이 어떻게 변할지 예측하여 장기적 관점에서 구현하기 vs 분석하느라 멈춰있지 말고, 불확실성이 두려워도 일단 뛰어들어 실행하여 피드백 받기
• 특히 스타트업에서는 후자가 더 유리하지만, 절대 극단에 치우치면 안 됨
• 적은 노력으로 큰 이득을 가져다주는 습관이 몇 가지 있음
  • 미시적: 값이 하나라도 하드코딩 대신 변수로, 값이 둘이라도 Boolean 값 대신 Mode로, 보다 확장성 있는 코드를 짠다. ex) 에디터를 만든다고 할 때, Edit 상태를 isEditing을 boolean 값으로 참, 거짓으로만 설정하지말고, 추후에 'EDIT', 'VIEW' 등의 다른 모드도 추가될 수 있기에 Mode라는 값으로 짠다.
  • 거시적: 결과를 관찰할 수 있는(피드백 받을 수 있는) 명확한 가설을 세워놓고 실행한다.

 

5, 효과적으로 꾸준히 학습한다.

• 모든 역량 중 가장 중요. 효과적으로 학습하는 법을 학습하는 게 가장 큰 복리 이득을 줌
• 학습 = 나의 지식을 넓혀 삶을 변화시키기 위한 것
  • n년 전에 유효했던 지식이 지금도 유효하리라는 보장이 없음 -> 새로운 정보를 이용해 업데이트 필요
  • 정보, 해석, 예측 -> 가치있는 지식은 이 3가지를 버무릴 때 나옴
  • 그러나 정보가 많다고 무조건 좋은 건 아님
• 핵심은 "어떻게 매일 조금씩 더 효과적으로 자랄 수 있을까?"
  • 지금 당장 현실에서 내게 필요한 것을 찾고
  • 그에 관련된 이론적 근거를 딱 내가 필요한 만큼만 찾아 학습하고(그 이상 학습한다고 내 거가 되는 게 아님)
  • 배우자마자 즉시 써먹어보고 셀프 피드백. 위 과정을 반복
• 당장 내 현실에서 필요한 것은 어떻게 찾을까?
  • 일기쓰기를 통해 메타인지 높이기
  • 내가 한 주간 어디에 많은 시간을 썼는지 기록해보고, 피드백 하기

 

 위 5가지의 역량을 키우는 방법을 프론트엔드 개발자에게 적용시키면

• 프론트엔드 도메인에서 훌륭한 코드란 무엇일까? 어떻게 더 좋은 코드를 짤 수 있을까?
• 프론트엔드 도메인에서 더 나은 의사결정을 하려면 어떤 근거를 어떻게 수집해야 할까?
• 프론트엔드 도메인에서 동료의 효과적 의사결정을 돕는다는 건 어떤 의미인가?
• 프론트엔드 도메인에서 내 작업의 현재 가치를 어떻게 측정할까? 어떻게 극대화할까?
• 프론트엔드 도메인의 지식을 꾸준히, 효과적으로 학습하려면 어떻게 해야할까?

에 대해 지속적으로 심도있게 고민하는 것이 바람직하다.

해당 세션에서는 세계적으로 훌륭한 시니어 개발자들을 인터뷰하여 그들이 성공하게 된 원인을 분석한 연구 결과를 토대로 "탁월한 개발자의 5가지 필수 역량"에 대해 설명하셨다. 인상 깊었던 점은, 처음에 탁월한 개발자가 가지고 있는 필수 역량들에 대해 순위를 매겼는데, "야근하기(hard working)" 역량이 거의 꼴찌에 위치해 있었었다. "오래 일하는 것은 탁월한 개발자의 필수 역량이 아니며, 오래 일하고 있는 사람이라면, 일하고 있는 환경 자체가 비효율적인 경우가 많다." 라는 말씀이 인상 깊었다.

확실한 연구 자료에 본인의 해석을 더하여 탁월한 개발자가 되기 위한 가이드를 잘 제시해주셔서 남는 것이 많은 세션이었다.

 

마치며

인프콘에서 받은 굿즈들

위에 정리되어 있는 알찬 세션들도 듣고, 기업 부스에서 이벤트를 통해 받은 굿즈들도 챙겨서 집으로 돌아왔다. 정신적으로나 물직적으로나 풍족한 컨퍼런스가 된 거 같아서 너무나 만족했다.

처음으로 이 정도로 큰 규모의 컨퍼런스에 오게 되어서 그런지 행사장에 가는 것 자체 만으로 개발자들의 열정적인 에너지를 얻을 수 있어서 좋았다. 그리고 세상에는 열심히 살아왔고, 현재 열심히 사는 사람들이 정말 많다는 것을 느끼며 나도 더 열심히 살아야겠다는 자극을 받았다. 내년에 있을 인프콘 2024에도 꼭 참여를 하고 싶다.