INFCON 2024 후기 ✨
Note : 이 글은 지극히 주관적인 생각을 토대로 작성된 글입니다. 혹시나 잘못된 부분이 있다면 메일 또는 코멘트를 통해 알려주시면 감사하겠습니다. 😄 제 메일은 About 탭에서 확인하실 수 있습니다. 📧
시작하며
이번에 운이 좋게 인프콘을 다녀올 수 있었다. 바로 얼마 전에 하이파이브 컨퍼런스 후기를 작성 했었는데, 인프콘에 다녀온 후기도 작성 해두면 좋을 것 같아서 한 달 만에 에디터를 켰다. 사실 올해는 크게 기대하지 않았다. 어쩌면 “올해에는 못 갈 수도 있겠구나” 라는 생각도 했다.
워낙 경쟁률이 높기도 하고, 2년 연속이 될까 싶어서 반신반의하는 마음으로 7월 초에 접수했었다. 그런데 운이 좋게도 참가자로 선정될 수 있었다. 회사의 동료 개발자분들도 접수 했었는데, 나만 참가자로 선정된 것도 참 웃픈 일이었다. 이번 연도 운을 여기에 다 사용한 건 아닐지 걱정이 들었지만 일단 잘 다녀오기로 했다.
컨퍼런스 현장 접수 및 오프닝 세션을 들으면서
컨퍼런스를 들으러 갈 때마다 시작 시각보다 조금 일찍 가서 접수를 빠르게 하고 본 세션 시작 전까지 기업 부스를 방문하면서 굿즈를 수집하면서 시간을 보냈었는데, 이번에는 아침에 늦게 일어나서 오프닝 세션 시작 30분 전 정도에 도착했다.
예상은 했지만, 사람이 되게 많았다. 그리고 기업 부스에도 이미 사람들이 줄을 많이 서고 있었는데, 특히 들어가자마자 있던 무신사 부스의 줄은 유독 더 길었다. 늦게 왔지만, 부랴부랴 줄이 적어 보이던 부스부터 가서 설문에 참여하고 굿즈들을 받았었다.
이름을 들으면 알법한 기업 부스가 많았다. 젯브레인, 무신사, 데이터독, 카우치베이스, 여기어때, 번개장터, 점핏 등이 기억이 난다. 이렇게 조금 기업 부스를 돌고 났더니, 곧바로 오프닝 세션을 들을 시간이 되었다. 부스를 둘러보다가 메인 홀로 들어가 오프닝 세션을 들었다.
오프닝 세션에서 이형주 대표님은 3년째 여전히 인프콘을 찾아주어서 고맙고, 여러분과 함께 성장하는 것이 인프랩이 바라는 미래라고 말씀을 해주셨다. 그리고 인프랩은 이제 국내 교육 시장을 넘어서 글로벌 진출에 대한 계획이 있다고 얘기해 주셨다. 글로벌 교육 컨텐츠 회사들과 현재 인프랩의 상황을 비교하면서 왜 그런 계획을 하게 되었는지 설명해 주셨다.
이동욱 CTO 님은 인프랩이 23년, 24년에 진행했던 것들에 대한 진행 상황을 간략하게 공유 해주셨다. 23년 인프콘에서 얘기해 주셨던 걸 가볍게 리뷰하고, 올해는 인프런 모바일 앱 출시, UI 개선, 자막 기능 추가 등을 위한 시간을 보냈다고 하셨다.
내년에는 글로벌 진출을 위해 기존의 강의 영상에 영어 등의 외국어를 더빙하는 기능을 AI를 이용해서 만들 계획하고 있다고 하셨고, 그 기능의 데모 시연도 함께 보여 주셨다. 더빙 데모 영상을 영한 님 강의와 리누스 토발즈의 강연 영상을 사용하셨었는데, 이 부분이 좀 재밌었다.
본 세션들을 들으면서
인프콘 참가 신청 당시에 발표 프로그램 타임 테이블을 보면서 시간표를 만들었었는데, 시간표 그대로 세션을 들었다. 이날 들었던 세션들은 모두 좋았고, 세션마다 여러 생각할 만한 부분을 제시해 주셨던 것 같다. 인프콘에서 들었던 세션들에 대해 간략하게 리뷰를 남겨볼까 한다.
- 지속 성장 가능한 설계를 만들어가는 방법 - 김재민
재민 님은 기존에 유튜브를 통해 이미 알고 있던 분이셨다. 재민 님의 유튜브 채널은 개발 과정에서 겪는 여러 문제에 대해 본인이 생각하는 해결 방법이나 팁을 많이 공유해 주셔서 평소에 즐겨 보던 채널 중 하나였다.
재민 님의 세션은 우리가 개발할 때 진행하는 “설계”에 대한 내용을 주제로 세션을 진행하셨다. 재민 님은 발표 시작부터 본 세션의 가장 핵심을 전달해 주셨다. “완벽한 설계를 하기 위한 방법은 설계하지 않는 것” 이었다. 그리고 이 얘기의 진짜 핵심은 설계보다 구현에 대해 집중하라는 얘기였다.
그리고 이 구현을 잘하기 위해서 두 가지 키워드로 “개념”과 “격벽”을 이용하라는 내용을 얘기해 주셨다. 우리가 구현해야 할 대상을 크게 나눈 항목들을 개념으로 두고, 이 각 개념 간의 참조 상태를 격벽을 이용해 분리를 통해 각 개념끼리 함부로 참조할 수 없도록 통제하는 방법이었다.
즉, 우리가 만드는 소프트웨어도 개념 간의 격벽을 세워서 통제할 수 있도록 처리 하자는 내용이 핵심이었다. 이 방법들을 대출 서비스와 커머스 서비스를 만드는 사례를 통해 설명해 주셨다. 내가 정리한 내용만 보면 뜬구름 잡는 소리처럼 보일 수 있는데, 나중에 영상으로 올라오면 한 번쯤 직접 세션에서 나온 예제와 사례를 함께 들어보면 좋은 내용이었다는 걸 알게 될 것 같다.
대부분의 개발자는 요구사항이 생기면 요구사항 분석 및 설계 후 구현하고 있는데, 이를 요구사항 분석 후 개념과 격벽을 이용해서 바로 구현을 해보자. 대신 지속 가능한 테스트를 작성하도록 하자. 그리고 구현한 내용을 기반으로 증명과 피드백을 받자. 이렇게 진행하다 보면 결국 설계가 나오게 될 것이라는 내용을 전달하고 싶으셨던 것 같다.
개인적으로 재민 님의 세션 내용은 잘 와닿았다. 실제로 업무에 적용해 봐도 괜찮겠다는 생각도 들었다. 지속적으로 변경되는 요구사항에 대해서 완벽한 설계라는 게 애당초 나올 수 없다면, 재민 님이 제시한 방법을 토대로 유연하게 대처할 수 있는 구현 방식이 더 효율적일 수 있겠다는 생각이 들었던 것 같다. - 인프런 아키텍쳐 2024 ~ 2025 - 이동욱
작년에 이어 올해도 어김없이 이동욱 님의 인프런 아키텍쳐 세션을 들었다. 인프런 아키텍처 세션은 동욱 님이 매년 인프콘에서 시리즈로 진행하고 있는 세션이다. 매년 인프런에서 어떤 문제를 발견했고, 어떻게 개선했는지 등을 공유해주는 세션이다.
첫 번째 개선 내용은 이미지 포맷 변경을 통한 트래픽 감소 및 이미지 저장 공간 최적화에 대해 공유해 주셨다. 기존에 사용하던 이미지 포맷에서 AVIF 라는 이미지 포맷으로 변경하면서 얻은 개선이었다고 했다.
여러 브라우저에서 이미 공식으로 지원하고 있어서 호환성 문제도 없었으며, 인프런에서 이미지 업로드 시 리사이징만 하지 않고 AVIF 포맷으로 변환해 주는 프로세스도 거치고 있다고 얘기해주셨다. 이미지 포맷 변경만으로도 전체 이미지 트래픽 60% 감소 및 이미지 저장 공간 최적화 등의 개선을 할 수 있었다고 하셨다.
두 번째 개선 내용은 모든 페이지에서 고정으로 노출되는 헤더의 카테고리 데이터에 대한 조회 성능을 개선한 내용을 말씀해 주셨다. 기존에 카테고리를 호출하는 트래픽을 계산해 보니까, 하루에 150GB가량 되었다. 그리고 수많은 DB 조회 요청을 통해 DB 부하도 주고 있었다. 이를 해결하기 위해 다음과 같은 방식으로 여러 차례 개선을 진행했다고 하셨다.- 처음엔 위 문제를 해결하기 위해 외부 카테고리 데이터를 원격 캐시를 통해 캐시 하도록 수정. - 그러나, 원격 캐시를 사용하는 데만 추가적인 인프라 자원 및 비용이 발생. - 추가적인 인프라 자원이 없더라도 사용할 수 있는 로컬 캐시로 변경. - 원격 캐시를 로컬 캐시로 변경 하더라도, 부하 자체는 현재 사용 중인 ECS의 EC2가 전부 부담해야 함. - 카테고리 데이터도 결국 JSON 구조의 데이터잖아? 이걸 파일로 저장해서 CDN으로 내려줄 수는 없을까?
최종적으로 JSON 데이터를 스토리지 저장소(S3 등)에 저장해둔 뒤 CDN을 통해 내려주는 방식을 채택하셨다고 한다. 이 방법을 통해 앞서 발생하던 부하를 줄일 수 있었다. 일 150GB, 월 4.5 TB 트래픽을 CDN 비용을 통해서 처리하도록 개선하셨다고 한다. API CDN 캐시 설정은 일반 CDN 캐시 설정과 다른 부분이 있어서 모두가 적용할 수 있는 방법은 아니라고 하셨다.
세 번째는 API 환경 개선에 대해 공유해 주셨다. 서비스 국제화를 위해 Express.js 에서 Next.js 로 전환하는 작업을 거치고 있는데, 이 과정에서 내/외부에서 호출할 API에 대해서 API Path를 분리하고, Go 언어로 리버스 프록시를 만들어서 적용한 내용까지 설명해 주셨다. 단계별로 왜 이런 선택을 했는지에 대한 기승전결을 세션에서 잘 보여 주셨는데, 이 부분은 영상이 올라오면 직접 보는 걸 추천 한다.
그리고 현재는 글로벌 서비스를 위해 사전 작업 기간을 거치고 있다고 하셨다. 내년부터 인프런의 일부 기능들을 다국어로 사용할 수 있게 될 것이라고 얘기해주셨다. 마지막에 글로벌 서비스를 위해 앞으로 넘어야 할 산은 많지만, 펠리컨 적 사고를 통해 일단 시도하는 게 중요하다고 하셨던 게 유독 기억에 남는다.
매번 느끼는 거지만 동욱 님의 세션은 참 전달력이 좋은 것 같다. 세션을 통해 전달하고자 하는 내용이 명확하다. 내년에 기회가 되어서 인프콘에 또 올 수 있다면 그 해 인프콘의 “인프런 아키텍처 2025~2026”을 들으러 오고 싶다. - 처음으로 기술 리더가 된 개발자를 위한 안내서 - 박서진
점심 이후 오후 첫 세션으로 박서진 님의 세션을 들으러 왔다. 어쩌면 오지 않을 수도 있고, 온다고 하더라도 먼 미래에 있을 것처럼 보이는 리더라는 역할에 대해 궁금증과 흥미가 생겼다. 좋은 리더라면 팀원과의 관계도 잘 유지할 테니까, 리더는 아니지만 다른 팀원에게도 좋은 팀원이 되고 싶은 나에게도 좋은 세션이 되겠다는 생각이 들었다.
그리고 언젠가 리더의 역할을 해야 한다면 좋은 리더이고 싶기도 했으니까, 여러모로 흥미가 있었던 세션이었다. 서진 님은 2018년에 토스의 다섯 번째 프론트앤드 개발자로 입사하셨고, 2019년에 10명의 프론트엔드 개발자의 리드를 처음 맡았다고 한다.
그때부터 INTJ(내향형 사고형)인 본인이 리더를 잘할 수 있을까? 에 대한 고민이 시작되었다고 한다. 그리고 현재 2024년에는 80명 정도 규모의 헤드를 맡고 계신다고 한다. 그리고 우여곡절을 겪다 보니, 어떻게 되긴 하더라고 말씀해 주셨는데, 이 우여곡절에 대한 히스토리를 공유해주셨다.
이 발표를 준비할 때 “먼저 2차 전직을 찍어본 사람들이 전해주는 기술 리더 공략집” 이라는 컨셉으로 준비하셨다고 한다. 기술 리더가 된다면 여러 어려움을 겪겠지만 그 어려움을 이겨내기 위해 근본적으로 확인해야 할 부분이 있다. 그건 바로 “팀원들이 나를 믿고 좋아하는가?” 이다.
리더를 신뢰하고 있는 팀원 이라면 팀 리더의 의사 결정을 바로 수용할 것이며 솔직한 이야기를 털어놓을 것이다. 그뿐만 아니라, 인정과 피드백을 진실하게 받아들일 것이다. 그리고 팀원이 리더를 신뢰하는 습관들에 대해 말씀해 주셨다.
자세한 내용은 나중에 영상이 올라오면 직접 보시는 것을 추천한다. 개인적으로 키워드별로 사례를 설명해 주셔서 이해가 잘 되었다. 나는 세션에서 들었던 몇 가지 내용을 간단하게만 적어보겠다.- 팀원이 나를 신뢰하는 7가지 습관 - 유능, 소통, 이익 공유, 유사, 안전, 관심, 예측 - 얼마나 유능한가? - 팀 리더가 개인 기여자로서 유능할 수록 신뢰를 얻기에 유능하다. - 일을 잘하니까, 주변 동료에게 신뢰받기가 수월하다. - 팀원에 대한 관심 - 관심이 있다는 '티'내기 - 팀원의 고민에 대한 의식적인 관심 - 1 on 1 이나, 커피챗에서 팀원이 고민을 1주 뒤나 다음에 마주쳤을 때 꼭 언급해서 신경쓰고 있다는 티를 내면 신뢰의 수준이 바뀐다. - 소통의 원할함 - 팀원과 깊고 원할한 소통 만으로도 나를 믿고 따른다. - 리더와 팀원의 유사성 - 리더와 팀원이 유사한 점을 공유 할수록 신뢰가 쌓인다. - 심리적 안정감 - 팀원이 현재 상황을 안전하다고 느낄수록 신뢰가 생긴다. - 칭찬 - 진실된 칭찬으로 팀원의 심리적 안정감을 높일 수 있다. - 예측 가능성 - 리더의 말과 행동이 일치하고, 팀원이 리더의 행동을 예측할 수 있다면 좋다. - 담백한 피드백 - 상호가 동의할 수 있는 사실 부터 피드백을 주면 좋다. - 팀원과 리더의 공동 목표 - 나의 목표를 팀원에게 설득하는 것이 아닌, 나와 팀원의 목표를 아우르는 공동 목표의 설정.
서진 님의 세션 내용은 전반적으로 좋았다. 그리고 많은 생각이 들었던 세션이었다. 처음 기술 리더 포지션을 맡으신 분이나 기술 리더로써 고민이 많던 분들에게는 더더욱 좋은 세션이 아니었을까 싶다.
앞으로 기술 리더, 개발 팀장 역할을 수행하고 싶으신 분들이나 이미 리더 포지션으로 역할을 수행하고 있다면 이 세션은 따로 풀영상을 챙겨보는 것을 더 추천한다. - 클린 스프링: 스프링 개발자를 위한 클린 코드 전략 - 이일민(토비)
이다음 세션이 토비님의 세션이었다. 작년 인프콘에서도 토비님의 세션을 들었었는데, 올해에도 어김없이 들으러 왔다. 토비님의 발표는 참 재밌었다. 집중력이 흐터리지지 않게끔 스토리텔링과 기승전결이 좋다는 느낌이 확 들었다.
이번 발표에서는 클린 코드에 관해서 얘기를 해주셨다. 국내의 시니어 개발자 중 일부는 클린 코드라는 주제를 그렇게 달갑게 보지 않아서 이 주제로 발표해도 될지 망설이셨다고 한다. 그래서 세션 명을 클린 스프링으로 정하셨다고 하셨지만, 사실상 클린 코드에 관해 얘기하고 싶었다고 하셨다.
클린 코드를 표현하는 다음 문장이 좋았다고 하셨다."Clean Code That Works" (작동하는 깔끔한 코드)
그리고 작동하지 않는 클린 코드에 대한 여러 얘기를 해주셨는데, 국내에 클린 코드에 대해 좋지 않았던 의견은 이 작동하지 않는 클린 코드에 대한 사례 때문으로 보였다. 클린 코드를 코드 결벽증, 원칙적이라고 이해하고 있는 사람들로 인해 클린 코드에 대한 의미가 이상하게 전파되고 있었던 건 아닐까?
이다음 내용부터 클린 코드에서 강조하는 내용과 연결되는 유지 보수성 개념과 클린 아키텍처의 코드 변경 가능성에 관해 얘기해 주셨고 유지 보수성을 얘기 해주시면서 개발 생산성에 대한 얘기까지 포함해서 설명해 주셨다.
그리고 이다음에 부채(Dept) 라는 표현을 최초로 표현하신 분이 워드 커닝엄이라고 얘기해 주셨고, 이분이 기술 부채를 상환하기 위한 방법이 리팩터링 이라고 얘기 하셨다고 한다. 자세한 내용은 영상이 올라오면 직접 보면 좋지만 내가 이해했던 내용을 잠깐만 기술하면 다음과 같았다.- 유지 보수성이 좋은 코드는 변경 가능성이 좋다 - 빠르게 변경되는 코드는 개발 생산성이 좋다. - 빠르게 변경되는 코드는 개발 생산성이 좋다. -> 유지 보수성이 좋은 코드는 변경 가능성이 좋다. - 이 과정을 리팩터링을 통해서 진행하는 것이다. - 그리고 이 과정을 끝없이 진행하는 것이 클린 코드의 선순환이라고 부를 수 있을것 같다. - 이렇게 진행되면 개발 생산성은 높이면서 유지 보수성이 좋은 코드를 작성할 수 있다. - 유지 보수성과 생산성의 규현을 잡아줄 리팩터링을 잘하려면? - 테스트가 필요하다. 테스트를 작성해야 한다. - 테스트를 빠르고 효과적으로 작성 하면서 개발하는 능력이 필요.
그리고 위 과정을 현실적으로 생각해 보면 개발은 혼자 진행하는 게 아니니까, 팀워크도 고려해야 한다고 얘기해 주셨다. 이 부분을 삼체문제에 빗대서 설명해 주셨다. 유지 보수성, 생산성, 팀워크 이 3개가 결국 코드에 영향을 준다고 말이다. 클린 코드의 많은 원칙은 팀의 동료 개발자와 관련된 것이다.
팀과 함께 결정하고 탐험하고 학습하고 성장하라고 얘기해 주셨다. 함께 코드를 작성하고 읽고, 변경할 동료 개발자에게 친절한 코드를 작성 하는게 클린 코드를 통해 얻을 수 있는 장점으로 이해되었다.
이 밖에도 클린 스프링에 관해 얘기해 주셨는데, 이와 관련해서 헥사고날 아키텍처를 좋아하신다고 하셨다. 헥사고날 아키텍처에 대한 내용도 공유 해주고 싶지만 이 내용은 너무 방대해서 강의로 만들어서 올릴 예정이라고 얘기해 주시면서 세션이 마무리되었다.
토비님의 세션은 여전히 즐겁고 재밌었다. 전혀 지루하지 않고 전달력이 좋으셨다. 주제도 굉장히 좋아서 나중에 영상이 올라오면 따로 풀영상으로 보는 것을 추천한다. - 객체 지향은 여전히 유용한가? - 조영호
다음 세션으로 조영호 님의 세션을 들으러 갔다. 이미 시간표에서 이분의 이름을 보았을 때부터 익숙하단 생각이 들었고, 그 생각이 맞았다. 객체 지향의 사실과 오해, 오브젝트라는 책의 저자이신 조영호 님이셨다. 조영호 님이 발표하시는 객체 지향에 대한 내용이라니 너무 궁금해서 들으러 갈 수밖에 없었다.
영호 님은 최근에 발표하시다가 다음과 같은 질문을 받았다고 하셨다. “객체 지향은 여전히 유용한가요?” 그리고 이 질문을 듣고 의문이 들었다고 하셨다. “왜 이런 질문을 하실까?” 그래서 그걸 그대로 물었더니 대답이 다양했다. 맡은 도메인에 따라서 팀에 따라서 객체 지향을 정말 배워야 하는 궁금증이 생겼다고 한다.
그리고 영호 님은 위 질문에 대해 다음과 같이 답변했다고 하셨다. “이런 질문을 하는 것보다 다른 질문을 하는 게 더 성장에 도움이 될 것”이라고 말이다. 왜 그런 답변을 주게 되었는지에 대해서 세션에서 설명해 주시겠다고 하시면서 세션이 시작되었다.
영호 님은 동일한 요구사항을 절차 지향으로 구현된 방식과 객체 지향 방식으로 구현에 대한 차이를 보여주셨다. 이 코드 예제들은 나중에 영상이 올라오면 직접 보시는 것을 추천한다. 이 예제들을 통해서 각 구현 방식의 장단점을 설명해 주셨다. 그리고 거기서 객체 지향은 무조건 절차 지향보다 설계가 좋은 건 아니라고 하셨다.
발표에서 보여 주셨던 코드 예제를 보면 더 이해가 잘 되겠지만, 예제를 통해서 알 수 있었던 건 타입을 추가하는 건 객체 지향의 구현 방식이 더 간단하지만, 행위가 추가 되는 건 절차 지향 방식보다 객체 지향 방식이 더 많은 소요가 들게 된다.
그래서 타입이 추가 되는 케이스가 많은 구조인지, 행위가 추가 되는 구조가 많은 구조 인지에 따라 적절한 설계 구조를 선택할 수 있다. 객체 지향 설계 구조 방식과 절차 지향 설계 구조 방식의 특징은 다음과 같다.- 절차 지향 설계의 특징 - 새로운 기능 추가가 쉽고 데이터 처리에 적합 - 포맷 변경을 위한 데이터 변환 - 데이터 중심 - 데이터 노출 - 기능 추가에 유리 - 객체 지향 설계의 특징 - 규칙에 기반한 상태 변경 - 행동 중심 - 데이터 캡슐화 - 타입 확장에 유리
객체 지향 설계는 행동 중심이며 데이터를 캡슐화하고 절차 지향 설계는 데이터를 오픈해서 Getter, Setter 의 유무에 큰 의미가 없다. 그리고 우리는 이미 개발을 진행할 때 객체 지향 설계와 절차 지향 설계를 섞어서 사용하고 있다. 레이어 별로 나눠서 개발을 진행하고 있지 않은가?
도메인 레이어는 객체 지향 구조를 사용해서 구현하고 있고, 퍼시스턴스 레이어는 단순히 데이터 베이스에서 데이터를 읽어오고 있으므로 절차 지향 구조로만 작성하면 된다. 즉, 위에서 얘기했던 더 나은 질문 이란 건 객체 지향이 여전히 유용한지보다 객체 지향이 언제 유용한지에 대해서 질문하는 게 더 적합하다는 것이었다.
특정한 때에 따라 적합한 기술과 패러다임은 다 다르다. 어떤 하나의 기술과 패러다임으로 모든 경우를 대체할 수는 없다. 코드의 목적과 변경의 방향에 따라 언제 어떤 기술을 사용할지 결정하라는 말을 끝으로 영호 님의 세션은 마무리되었다. 영호 님의 세션도 나중에 풀영상으로 보는 것을 추천한다.
영호 님의 세션을 들으면서 특정한 상황이 되었을 때 어떤 기술을 사용하는 게 적합한지 판단할 수 있는 능력을 갖추는 게 중요하다는 생각을 한번 더 하게 되었던 것 같다. -
성장하지 않아도 괜찮습니다 - 김영재
마지막 세션은 김영재 님의 세션을 들으러 왔다. 같은 시간대에 한기용님 세션도 있었지만 지난 하이파이브 컨퍼런스 에서 한기용님의 세션은 들었기에 이번에는 김영재 님의 세션을 들으러 왔다. 사실 세션 제목에 끌렸던 것 같다.
영재님은 성장이라는 단어가 어색했다고 하셨다. 이게 문법적으로 맞는지 생각이 드셨다고 한다. 우리가 성장이라는 말을 쓸 때는 다른 사람에게 “키가 많이 컸네” 와 같이 나 말고 다른 사람에게 썼던 것 같았다고 말이다.성장이란 - 시간이 한참 지난 뒤에 뒤돌아 볼 때 느끼는 것 - 그 마저도 내 입으로 차마 말할 수 없는 것
사회가 성장을 강요하는 것 같았다. 핫한 키워드를 공부 안 하면 성장이 아닌 것 같다는 압박감도 들었고 동료처럼 뭐라도 해야 한다는 불안감 또한 들었다. 뭐가 성장인지 모르겠지만 성장을 해야만 한다는 부담감이 들었고 하던 것을 꾸준히 하는 게 이상하다는 인식이 생긴 것 같았다.
하지만 아니다. 하던 걸 꾸준히 하는 게 오히려 더 의미가 있을 수 있다. 꾸준함이 곧 의미를 만들고 지금 하는 일을 더 긴 호흡으로 지치지 않고 하는 지속 가능성에 집중해야 한다. 성장은 결과일 뿐, 성장이 동사로 쓰이면 오히려 나를 잃어버릴 수 있다.
성장의 반대라고 해서 대충 일하라는 의미가 아니라고 말씀하셨다. 지금 하는 걸 더 많이 하자라는 게 핵심이었다. 엔지니어링을 통해서 현재 하고 있는 일의 재생산 비용을 제로에 가깝게 떨어뜨리는 노력을 하자. 일을 할수록 자신의 재생산 비용을 낮춰야 한다. 디자인도 기획도 개발도 모두 엔지니어링이 가능하다고 하셨다.
루틴의 자동화와 지식의 일반화를 통해서 일을 효율을 올릴 수 있는 사례들을 설명해 주셨다. 그리고 그다음으로 얘기해 주셨던 게 지금 하는 걸 더 함께하라고 하셨다. 이 부분은 프로세스 개선에 대한 내용이었다. 반복되는 질문에는 나쁜 프로세스가 숨어 있으니, 프로세스 개선을 통해서 반복되는 질문을 없애자는 내용 이었다.
이 프로세스 개선에 대한 내용도 사례를 기반으로 얘기해 주셨다. 각 내용을 말해주실 때마다 관련된 사례들을 발표에서 자세하게 다뤄 주시는데, 모두 글에 옮길 수 없었다. 이 사례들은 나중에 영상을 통해 보면 좋을 것 같다.
그리고 마지막으로 얘기해 주셨던 부분이 지금 하는 것을 더 오래 하자는 내용이었다. 거창하게 생각하지 말고 지금 하는 걸 지치지 않고 더 많이 하다 보면 나의 아이덴티티 를 발견할 수 있게 된다고 해주셨다. 그리고 어느 순간 다른 팀원들도 나를 찾을 것이고 나의 아이덴티티 또한 알게 될 거라고 하셨다.
영재님의 세션은 내용이 전반적으로 참신했다. 이 세션은 나중에 영상이 올라오면 풀영상으로 직접 보는 게 더 와닿는 게 큰 것 같아서 직접 보는 걸 추천한다. 지금 하고 있는 일을 꾸준히 하면서 얻을 수 있는 것들과 성장이란 개념에 대해 다시 한번 생각할 수 있는 계기가 되었다.
밑의 내용은 위에 작성한 내용을 정리한 내용이다.- 꾸준하게 매주, 1년에 50번 반복할 뿐 - 많이 -> 함께 -> 크게 -> 오래 - 업무의 재생산 비용을 조금이라도 낮춰보자. - 그 경험을 일반화 한다. - 그 과정에서 질문을 하나씩 도구로 만들며 없앤다. - 팀의 노하우가 된다. - 효과를 수치화, 가시화 한다. - 조금 더 큰 규모를 본다. - 이 경험을 매일, 매달마다 쌓으면 어느 순간 모두가 나를 찾는다 - 나의 아이덴티티를 다른 사람도 동일하게 인식한다.
마치며
올해도 인프콘을 다녀올 수 있어서 좋았다. 경쟁률이 높아서 못 갈 수도 있겠다고 생각도 했었지만, 다행히 당첨되어서 좋은 세션과 좋은 내용을 듣고 올 수 있어서 좋았다. 운이 다할 때까지 매년 접수해볼 예정이다.
이번에도 내용이 꽤 길어진 것 같은데, 인프콘 2024에 대한 후기는 여기까지다. 다음에 또 새로운 포스팅으로 돌아오도록 하겠다.
