랄라J, 기록합니다.

이번에 DLCA Tech-Tree CON을 신청했다~!
원래는 오프라인으로 가서 들을까 했는데, 너무 감사하게도 라이브가 Youtube에서 제공되어 편하게 들었다 :)
(지금도 녹화본이 제공되니 궁금한 사람은 들어봐도 좋을 것 같아 링크를 공유합니다~!)

우선 궤도님의 강연부터 시작해 모두 유명하신 분들이라 다 듣고 싶어 라이브를 켜놓고 틈틈이 들었다.
모든 것을 메모하진 않았고, 기억에 남는 부분만 메모한 강연도 있으니 혹시 이 글을 읽으시는 분들은 참고하시길!

기술이 바꿀 미래와 과학의 역할 - 궤도

과학적 발전이 대단해도 사실 일반인인 우리들은 만들어진 것을 사용만하는 입장이다.
과학자가 아닌 이상 크게 과학적 발전에 대해 소름이 끼치는 경험을 하진 못한다.

하지만 지금 이 시간에도 과학자들은 계속해서 문제를 예측하고, 해결하기 위한 노력을 한다.
이번 강연에서 예시로 들어주신 부분에서 신기했던 예시들은 크게 3가지가 있었다. 😮

1. 우리가 코로나 바이러스로 문제를 겪은 건 몇년 전이지만 과학자들은 2004년부터 코로나 바이러스에 대해 예측하고 그를 위한 연구를 계속해왔기에 빠른 시간 안에 백신을 개발해 낼 수 있었고, 그로 인해 더 큰 문제를 막을 수 있었다.

2. 지금도 지구 온난화, 가열화를 해결하기 위해 이산화탄소를 모아 돌에 붙이는 기술을 개발했다. 하지만 현재는 그 기계를 가동하는데 에너지가 더 들어 그 부분을 해결하기 위해 노력하고 있다. 🧐

3. 해결이 되지 않는 상황을 가정해 지구 대신 옮겨가 인간이 생존할 수 있는 행성을 찾고 이동할 수 있는 수단을 개발하고 있다.

결론적으로 이슈를 해결하는건 결국 과학자들이다.

그럼 우리는 어떻게 살아야 하는가?
우리도 과학적 사고를 갖자 (원인과 결과를 명확하게 나누자)

과학적 사고가 뭘까?

정리를 하다보니 원인과 결과에 대해 나누는 게 과학적 사고인가? 싶어 추가로 정의를 찾아봤다.

위키백과에는 나오지 않고, 과학적 방법은 나와 다른 글을 보다 보니 2008년 서울대 교수님이 올려주신 글을 읽어봤다.
이 글에서는 기존지식에 대해서 의식적으로 반성하는 것, 지식의 정량화(정성적으로 기술하던 지식을 정량적으로 기술하자), 지식의 실증적 검토, 반증 가능성, 단편적인 지식들을 하나의 합리적인 체계로 설명하는 시도으로 구분해 설명하고 있다.

아마 과학적 사고를 갖자는 말이 문제를 제대로 인식하고 결과에 대해 나아가자는 말씀이 아니셨을까 추측해 본다.

앞으로 우리는 지금껏 살아온 세상과 다른 미래를 살아갈 것이다.

AI를 활용한 지금까지는 없던 직업들이 많이 나올 것이다.
예를 들면 일러스트레이터지만, 그림을 못 그려도 AI를 잘 활용하는 프롬프터 엔지니어링 일러스트레이터가
이미 사례가 있을 만큼 AI를 활용해 영화를 만드는 프롬프터 엔지니어링 감독 (두바이 국제 AI 영화제 대상, 관객상 수상한 원모어 펌킨)

개발자라는 직군도 더 중요해질 것이다. AI는 원하는 대로 만들기는 어렵기 때문이다.

다시금 과학이라는 분야에 신기함을 느꼈다. 이산화탄소를 모아 돌에 붙이는 기계를 이미 발명해냈구나 싶어 너무 신기했다. 나도 개발자로서 무언가를 해결해 내는 사람이 되고 싶다는 생각이 들었다. 과학자들의 노력으로 만들어진 것에 편의성만 느끼며 살아가는 것처럼, 누군가는 내가 만든 서비스를 통해 편리하게 느끼며 살아가도록 개발하고 싶어졌다.

그리고 과학적 사고에 대해서도 한번 다시 생각해보고 싶어졌다. 이에 관련한 책을 하나 읽어봐야겠다.
그리고 AI에 대해서도 시대가 변화하고 있는 만큼 사용하고 익숙해지는 경험을 미리미리 해놔야겠다고 생각이 들었다.

개발자의 다른 말은 문제 해결사 - 유용태(테오)

Don't be a Programmer. Be a Problem Solver!

강연은 개발에 대한 테오의 생각과 관점에 대한 이야기였다.

이번 모든 강연에서의 핵심은 결국 위 PPT 한 장이면 될 것 같다.
아래 이장원 님, 향로님의 강연도 결국 이 PPT 하나로 관통되는 느낌이랄까.

성장하면서 알게 된 개발자의 가치를 이야기하셨다.
초년차에는 좋은 개발자는 당연히 개발을 잘하는 개발자라고 생각하셨지만,
연차가 쌓이고 나서는 높은 품질의 코드를 만들어내는 것이 잘하는 것이라고 생각한다.

저연차 시절 사수보다 빠르게 코드를 작성할 수 있었기에 더 실력이 좋다고 생각했지만 코드는 대충 작성할수록 빠르게 개발할 수 있다.
하지만 잘하는 개발자는 규모가 커져도 꾸준히 예측가능한 속도로 개발가능한 구조를 함께 생각한다. (클린코드, 품질이 좋은 코드)

"언제까지 개발 가능하세요?" 질문에 대답할 수 있고, 그것에 책임을 질 수 있어야 잘하는 개발자다.

좋은 코드를 짜고 싶고, 좋은 제품을 만들어내고 싶지만 현실적으로 개발 시간은 촉박하게 주어진다.
이 모든 것을 잘 해내려다 보니 결과적으로 마주한건 번아웃과 자괴감이었다.

사업을 해보며 깨닫게 된 사실은 시장은 내 생각보다 고품질의 코드를 중요하게 생각하지 않는다는 것이다.
개발하는 우리만 해도 그렇다. 어떤 라이브러리를 사용한다고, 코드를 열어 소스 코드의 품질을 보는가? 아니라는 것을 알 수 있다.
개발의 평가는 어떻게보다 무엇을 개발하느냐에 따라 정해지더라.
동경하는 개발자가 있다면 생각해 보자. 그를 유명하게 만들어준 것은 무엇을 만들었는 지다.

코드보다 그 코드로 어떤 가치를 만들어내는지가 더 중요하다.
결국 개발은 가치를 만들어내기 위한 도구라는 것이다.
더 가치 있는 코드는 적절한 코드 품질 위에 좋은 요구사항을 구현하고 일정을 지키는 것이다.

개발의 가치는 코드 자체가 아니라 그 코드로 어떤 문제를 해결하는 데에 있다.

그럼 좋은 코드는 왜, 언제 필요할까?
코드의 품질이 중요해지는 시점은 규모가 커지고 복잡도가 생길 때부터다.
비즈니스가 성공해 규모가 커지면 다시 코드의 품질이 중요해진다.
또한 개발자로서도 낙후된 코드의 품질은 개발의욕마저 떨어뜨린다.

결국 좋은 코드는 비즈니스의 지속 가능성을 책임진다.
맛있는 김을 계속 맛있고 바삭하게 먹기 위해서는 방부제가 필요한 것처럼 말이다.

비즈니스가 성공하면 규모가 커지고 자연스레 서비스의 복잡도가 올라간다.
서비스의 규모와 복잡도가 기술적 챌린지를 만들고 이를 극복하는 경험이 개발자에게 대단한 기술적 성장을 경험하게 해 준다.

추가적으로 사실 이력서 내 사이드 프로젝트는 높은 가치를 쳐주지 않는다.
실제 서비스 된 것이 아니고, 최신 기술을 가져다 쓰는 것보다 레거시 프로젝트 경험이 훨씬 중요하다.
오래된 코드를 유지하고 서비스 규모와 복잡도가 다르기에 더 어렵기 때문이다.

큰 기업도 막상 들어가 보면 비슷한 개발을 하고 있을 것이다. 다른 점이 있다면, 고려할 규모가 다르다는 점이다.

개발자의 역할은 코드의 품질을 유지하면서도 비즈니스의 가치를 높이는 균형의 수호자가 되어야 한다.

필요에 의해서 필요한 기술을 필요한 만큼만 사용하는 것이 정말 중요한 실력이다.
기술을 위한 기술이 아닌 문제 해결을 위한 기술이어야 한다.

하지만 당연히 좋은 도구를 많이 가지고 있으면 좋다.
좋은 도구를 적재적소에 쓰는 노하우를 가지고 있는 게 중요하기 때문이다.

요구사항, 시간, 코드의 품질, 번아웃과 자괴감, 코드와 비즈니스 가치의 균형 감각, 기술과 가치의 수호자 역할 모두 개발이더라.

개발자는 비즈니스의 가치를 어떻게 올릴 수 있을까?
개발자는 저점을 높여주는 거지 고점을 높이는 것은 어렵다.
또한 개발자의 목표와 비즈니스의 목표가 달라 가치의 충돌이 생긴다.

협업하는 사람과 함께 성과를 성과를 내야 하고, 그들을 돕는 게 나를 돕는 일이다.
개발은 코드로만 하는 게 아니다.
코드를 만들어내는 가치를 더 높일 수 있도록 하는 모든 범위가 개발이라고 할 수 있다.

프로그래머를 넘어 문제 해결사가 되자.
진짜 중요한 것은 그 문제를 어떻게 해결하고 어떤 가치를 창출할 것인지를 결정하는 우리의 마음가짐과 접근 방식이다.

대표적인 예시로 공항의 불만 처리 방식을 이야기해 주셨다.
요약하자면 기술적 문제를 해결한 것이 아닌 사람의 심리를 이용한 해결을 이뤄냈다.
즉, 개발로만 모든 문제를 해결할 필요는 없다.

문제해결을 잘하기 위해서는 본질을 찾고, 모순을 해소하고, 함께 해결해나가야 한다.

함께 잘 협력하는 사람이 되기 위해서는
1. 잘 들어주는 사람이 되어 상대방에게 심리적 안정감을 주어야 한다.
2. 시키는 일이 아니라 함께 해결해야 하는 문제라고 생각하자.
3. 문제해결을 위해 공감보다는 연민하자.
4. 설득을 하는 것이 아니라 비교로 생각의 주파수를 맞춰야 한다.

회사다 보니 논리로만 되지 않는 순간도 있다.
그리고 가치는 내가 고생하거나 어려운 만큼 올라가는 것이 아니라는 것을 인지하자.

이론 < 구현능력 < 좋은 품질의 코드 < 딜리버리(완성도, 마감) < 비즈니스 가치 = 협업 = 유지를 위해서는 좋은 코드 품질 유지 필요
결국 절대적인 것은 없고, 상대적인 것이다.
상황에 맞는 가치들의 균형감각이 중요하다.

코드를 작성하는 것만이 개발이 아니다.
개발만 하고 싶은데 개발만 하게 내버려두질 않네요 -> 그게 다 개발이다.
마인드를 바꾸면 주도적으로 할 수 있을 것이다.

마무리 - 모든 개발을 주도적으로 선택하고 해결하는 멋진 문제해결사가 되길 바란다.

인사이트를 얻게 하는 강연이었다.
사실 나에게 이 컨퍼런스를 들어야겠다 결심했던 건 테오님의 강연이 컸다.

전에는 FE에서 좋은 개발자라고 생각하면 변화에 발맞춰 빠르게 트렌드를 쫓아가고, 다양한 기술을 섭렵한 사람이라고 생각했는데,
이 강연을 듣고 요즘의 생각은 기본기가 탄탄하고 응용할 수 있는 개발자, 깊이 생각해 본 경험이 있는 개발자라고 생각하고 있다.
신규 프로젝트에 최신 기술을 마구 넣어 사용해 본 경험보다는 레거시 코드를 유지보수 해 본 경험이 더 중요하다는 말씀에 한번 더 생각해 보게 되었다. 나도 기술을 위한 기술을 사용하고 있던 건 아닐지...!

타 스트레스 없이 개발만 하는 환경을 중요하게 생각하는 개발자 가보면 자신을 되돌아볼 수 있는 좋은 강연이었다.
요즘의 개발자는 소프트 스킬이 중요하다고 하는데 그 이유가 이 강연을 통해 다 드러나는 것 같다.

스타트업 개발에서 개발자들이 아쉬워하는 부분은 최신 기술을 적용하지 못하고, 레거시 코드가 많다는 게 큰데 여기서 멈춰 생각해봐야 하는 포인트인 것 같다. 필요에 의해 최신 기술 적용이 필요한 것인지, 뒤쳐지고 있다는 불안감으로 인해 최신 기술을 사용하려고 하는지 말이다. 레거시 코드 개선을 통해 얻는 성장도 크다는 말에 막 성장하는, 그래서 함께 성장할 수 있는 회사에 합류하고 싶어졌다.

연차마다 처한 환경마다 느끼는 바가 다를 것 같기 때문에 프론트엔드 개발자 생활을 하면서 이 강연을 두고두고 다시 봐도 좋을 것 같다.

Possibility, it's a Mystery - 이장원

앞서 테오님의 강연은 다시 곰곰이 생각해 볼 무거운 주제였다면, 뒤에 이어지는 순서는 본인의 삶에 관한 내용이어서 조금은 가볍게 들었다!

강연의 제목은 Possibility, it's a Mystery인데 가능성, 그것은 알 수 없는 것의 의미로 2005년 슈퍼 판타스틱 앨범에 수록된 곳이라고 한다.
진로 고민을 담았던 곡이라고 해서 의미 있었다.

페퍼톤스의 이장원씨의 강연이었다. 본인을 어떻게 아는지 모른다며 안다는 사람에게 90도 인사하시며 감사하다는 반응이 너무 재밌으셨다.
본인이 특이한 점, 배울 수 있는 점에 대해 고민하다. 그냥 본인의 성장과정을 얘기해 보겠다고 하셨다.

이력이 아주 화려하시다. 과고 -> 카이스트 학사, 석사, 박사까지 엘리트 코스를 밟으셨다. 페퍼톤스 활동을 하시면서도 경영 금융 쪽 관심이 생기셔서 리만 브라더스에 지원했는데 하필 시기가 서브프라임 모기지 사태가 터졌던 시기라고 하셨다. 그래서 순탄했던 시절만 있다가 고민을 겪게 되셨다고 한다.

본인의 삶을 돌아보니 겁쟁이 개복치라고 표현하셨다. 엘리트 코스의 정석을 걷고 계시다가 본인이 제어할 수 없는 사회의 흐름에 무너지는 시기를 겪으셨다고 그래서 MBTI도 제어할 수 있던 시절에는 P 셨다가, 위기를 겪고 J로 변하셨다고 한다.

직접 PPT로 만드셨다며 설명하는 과정이 너무 재밌었다.

맹귀우목, 눈먼 거북이가 나무를 만나다.
거북이는 멈춰 있지 않고, 계속해서 도전했기 때문에 기회가 왔을 때 그것을 거머쥘 수 있었다.

결론으론 멈춰 있지 말자, 쓰러진다고 두려워하지 말자, 페퍼톤스를 듣자 😂

나는 이장원님을 AI 남편으로 너무 재밌게 봤었어서 등장과 함께 너무 재밌는 강연이었다.
앞선 강연을 집중해 들으셨는지 김과 방부제 이야기 등을 언급하시는 부분도 좋았다.

엘리트 코스만을 밟던 그에게 닥친 시련과 그로 인해 얻은 결론을 듣기까지
위트 넘치시게 강연을 이어나가셔서 시간 가는 줄 모르고 봤던 것 같다.

멈춰있지 말자, 쓰러진다고 두려워하지 말자, 페퍼톤스를 듣자 🎶

커리어 각 지점의 고민과 선택들 - 향로

발표자 이동욱(향로)님은 개발바닥, 인프런 CTO, 기억보단 기록을 블로그로 이미 유명하신 분이다.
간단히 인프런의 앞으로의 목표와 강연 내용 주의 사항으로 시작하셨다.
인프런의 현재 목표는 AI 더빙을 해서 국내 좋은 강의들이 세계로 뻗어나가는 것을 목표로 하고 있고,
강연의 내용은 본인의 이야기지 정답은 아니니 하나의 자료로서 참고만 하기를 당부하고 시작되었다.

전공이 아닌 SW로 진로를 변경해 4학년 여름방학 때 국비 학원으로 시작했다. 그때 재학생은 국비 지원을 못 받아 내 돈으로 낸다면 가장 잘 가르치는 곳으로 가자고 생각해 서울로 올라왔다.

왜 복수전공, 전공변경, 재입학이 아닌 부트캠프를 갔는가?
남들과 같은 길을 가면 늦은 사람이 되지만, 다른 길을 선택하면 다른 선택을 한 사람이 된다.
Reset 하는 것을 습관화 되게 만들고 싶지 않았다.

부족한 공부 환경, 열악한 생활 수준, 비전 없어 보이는 미래였고,
그 당시 개발자라는 직군은 주당 100시간을 일하는 3D 대표 직업군 -> 과로사 등이 뉴스에 많이 나오는 시점이었다.
그렇기에 오히려 그 일을 좋아하는지 객관적으로 비교하는 시간을 가졌다.

3학기 120개 지원하고, 최종 합격은 1 군데 했다. (지금 시장도 비슷한 것 같다.)

위 조건에 맞는 회사에 지원하기 시작했고, 붙은 회사는 중견 SI 기업이었다.
연봉이 2천대라 더 준비해서 더 좋은 회사로 갈지 고민했지만, 돈을 벌어야 하는 상황이라 경력이라도 쌓이는 일을 하자고 생각해 전진했다.
하지만, 신입 온보딩이 없었고 개발보다 수주가 중요해 PT 능력을 강조했다.

그래도 좋았다. 동기들 대상으로 본인이 스터디를 주도했고, 강조한 덕에 많이 PT 경험할 수 있었고, 객관적인 시선을 갖게 되었다.
그렇지만 코드리뷰, 뛰어난 동료, 실시간 서비스 운영 및 장애경험을 원해서 두 번째 직장으로 이직했다.

두번째 회사에선 최신기술을 배우고 좋았는데, 입사 7개월 차에 본인을 제외한 모든 팀원들이 이탈을 했고, 장애 대응을 혼자서 해야 했다.
퇴사 위기가 왔지만, 그래도 2년을 채우자고 다짐했다.

사수가 없고 계속된 신입 개발자의 합류로 내가 원하던 개발환경을 만들어 볼 수 있었던 시간이었다.
하지만 업계 1위를 지향하는 조직에 대한 갈망하기 시작해 배달의 민족으로 이직했다.

당시 배달의 민족의 상황은 지금과 달리 좋은 환경이 아니었다.
그럼에도 간 이유는 그동안 Follow 하던 많은 시니어 엔지니어들이 합류하던 곳이기 때문이었다.

배달의 민족이 성장하는 과정을 함께 하면서도 많은 학습을 하게 되었고, 그로 인해 수많은 기회를 얻게 되었다.
물론 사이에 또 퇴사 위기가 있었지만 많은 것을 얻게 되었다.

배달의 민족이 성장하면서 복지도 좋고, 성공에 따른 보수도 좋았지만 또다시 퇴사 위기가 왔다.
앞으로 여기가 가장 이야깃거리가 많은가에 대한 고민이었고, 본인에게 가장 중요한 문제였다.
경험하지 못한 시리즈 seed, A, C, D의 개발에 대한 호기심이 생겼다.
성공하면 좋은 것이고, 실패해도 에피소드가 되니까 인프런에 이직을 해 도전하게 되었다.
가장 이야깃거리를 많이 만들 수 있는 곳이라고 생각했기 때문이다.