영향력 있는 개발자 되기: ‘테오의 프론트엔드’ 유용태 개발자

16분

2024.03.29.

‘테오’로 활동하며 영향력을 쌓다

Q. ‘테오’라는 이름으로 오픈채팅, 블로그, 스프린트, 컨퍼런스까지 다양한 활동을 이어가고 계신데요. 어떤 계기로 이런 활동들을 시작하게 되셨나요?

우선 ‘테오’라는 이름부터 간단히 설명하면, 2020년 카카오엔터프라이즈에 다니면서 쓰기 시작한 이름이에요. 모두 저를 부를 때 “테오”라고 하니까, 어느 순간 본명보다 더 익숙해지더라고요. 그래서 프론트엔드 정보 공유를 위해 만든 오픈채팅도 그렇고, 블로그를 만들 때도 ‘테오의 프론트엔드’로 지었죠. 이때부터 제 부캐가 된 거예요. 이러한 활동을 시작하게 된 계기는 ‘나’라는 사람을 더 잘 알리고 싶었기 때문인데요. 여기서 나를 알린다는 건 단순히 직장 생활을 하는 내가 아닌, ‘개발자로서의 나’를 의미해요.

Q. ‘개발자로서의 나’를 알리고 싶으셨던 특별한 이유가 있을까요?

사실 제가 지금처럼 ‘대기업 개발자’로 일한 건 그렇게 오래되지 않았어요. 제 실력이 크게 달라지거나, 이 회사에 오래 다닌 게 아닌데도 ‘카카오 출신 개발자’로 대우해 주시더라고요. 물론 고마운 일이고 회사에 입사한 것도 제 실력이 될 수 있겠지만, 회사 타이틀이 아닌 ‘스스로 개발 실력을 증명하고 싶다’는 생각이 들었어요. 한때는 개인 사업을 유지하기 위해 대부분의 돈을 외주로 벌어야 했는데, 이때 실제로 만드는 것보다 만들 수 있다고 증명하는 부분이 훨씬 더 어려웠거든요. 그리고 사업을 그만두고 다른 직장을 다니거나 구할 때도 실력이 있다는 걸 증명하는 게 그렇게나 어려웠는데, 이제는 카카오라는 이름이 저를 증명해 준 거죠.

그래도 지금까지 개발자로 10년 넘게 일하며 살아왔는데, 단순히 ‘카카오 출신 개발자’ 타이틀로 저를 증명하는 게 과연 맞는 건지 잘 모르겠더라고요. 물론 그게 잘못됐다는 건 아니지만, 저는 웹 프레임워크 스벨트(Svelte)를 만든 리치 해리스(Rich Harris)처럼 개발자를 위한 개발이 하고 싶었거든요. 그래서 저도 CSS 프레임워크 ‘AdorableCSS’를 만들었고, 블로그에 이에 대한 내용을 열심히 써서 올렸어요. 블로그에 홍보하면 널리 알릴 수 있을 거라 생각했죠.

Q. 생각한 대로 잘 되셨나요?

아뇨, 제 생각보다 관심을 많이 안 주시더라고요. (웃음) 오히려 운영하고 있던 오픈채팅에서 “프론트엔드가 무엇인가요?”, “프론트엔드 개발자가 되려면 어떻게 공부해야 하나요?”와 같은 질문이 많았어요. 짧은 답변만으로 충분치 못하다는 생각이 들어, 각잡고 글을 써야겠다는 생각에 관련 글을 쓰기 시작했습니다. 그런데 그 글이 점점 여기저기에 퍼졌어요. 그래서 요즘IT와도 인연이 생기게 되었고요. 글이 알려지다 보니, 더 많은 사람들이 블로그와 오픈채팅으로 모이기 시작했죠. 그 후로도 프론트엔드와 관련된 여러 글을 작성했고, 그 글들도 꽤 인기가 많았어요. 요즘IT에서도 제 글을 널리 퍼뜨려주셔서 많은 도움을 받았네요.

유용태 개발자가 운영 중인 디스코드와 카카오 오픈채팅 <출처: 요즘IT 편집>

Q. 여러 활동 중에서도 ‘테오의 스프린트’가 많이 알려지게 되었는데, 어떻게 시작하게 되셨나요?
전세계적으로 IT서비스의 가치가 높아지면서 덩달아 개발자라는 직업의 가치도 함께 높아졌어요. 예전보다 더 많은 개발자 지망생이 생겨났고, 그만큼 경쟁도 치열하다고 생각해요. 개발자에게 중요한 역량으로 코딩이 있겠지만, 지금은 협업 능력 또한 중요해서 협업 경험 자체가 하나의 스펙이 되어 버렸어요. 그런데 회사가 아닌 곳에서 협업하기란 쉽지 않고, 어떻게 사람들을 구한다고 해도 성공적으로 마무리하기 어렵죠. 아무래도 개발자 지망생이나, 아직 연차가 낮은 주니어 개발자는 협업 경험이 부족하거든요. 아직 ‘대학교 조별 과제’에서 벗어나지 못한 거죠.

그들의 고민을 어떻게 해결할 수 있을까 생각하다가, 현업에서 제가 진행하던 구글 스프린트가 떠올랐어요. 협업을 좀 더 잘할 수 있는 프로세스를 알려주고 싶었고, 이건 글로 알려줄 수 있는 게 아니라서 실제로 체험해야 했어요. 그래서 “딱 5일간만 구글 스프린트를 한번 체험해 보실 분 있나요?” 하고 구글 스프린트 이벤트를 모집하게 되었죠. 처음에는 8명으로 시작했는데, 지금은 100명도 넘는 사람들이 함께하게 되었네요.

Q. 그렇게 탄생한 ‘테오의 스프린트’가 벌써 16기까지 진행됐는데요. 스프린트에선 구체적으로 어떤 활동을 하나요?

먼저 스프린트의 개념을 간단히 소개하면, 구글 수석디자이너가 만든 협업 프로세스로 ‘5일 만에 아이디어를 검증하는 획기적인 협업 프로세스’예요. 5일간 MAP - SKECTCH - DECIDE - PROTOTYPE - TEST를 진행합니다. 원래는 기획 프로세스였지만, 저는 프로토타입 개발을 실제 프론트엔드 개발로 진행할 수 있도록 개발 기간을 하루 더 늘렸죠. 여기에 설계 과정을 추가하면서, 기존의 구글 스프린트의 구성을 개발에 맞게 변경했습니다.

테오의 스프린트는 5일간 하루에 1시간씩 온라인에서 원격으로 모여요. 첫째 날은 각자 아이디어를 공유해서 채택하고, 둘째 날부터 본격적인 스케치를 시작하죠. 셋째 날은 구현해야 할 스토리보드를 확정 짓습니다. 그다음 넷째 날 스토리보드를 기반으로 실제로 구현하는 일을 하죠. 마지막 다섯째 날은 지금까지 만들었던 것들이 효과가 있는지, 테스트를 통해 최초의 아이디어를 검증해요. 그리고 구글 스프린트엔 없는 절차지만, 4Ls(Liked, Learned, Lacked, Longed For)라는 회고를 진행하며 마무리됩니다. 좀 더 자세한 회고는 블로그에 정리해 둔 글이 있으니 참고해 보셔도 좋겠어요.

짧은 시간이지만 단순히 포트폴리오를 완성하는 게 아니라, 제대로 협업하는 방식과 프로세스를 충분히 이해하는 ‘성공적인 협업’을 경험시켜 주고 싶었어요. 중요한 것은 이렇게 하는 것이 ‘잘 된 협업이구나!’ 하는 걸 몸으로 느껴보는 것이라고 생각해요.

Q. 사실 ‘스프린트’는 기획자나 디자이너가 더 자주 쓰는 방법 같은데, 어떻게 프론트엔드 개발과 엮어서 생각하게 되셨나요?

LG CNS 신사업개발팀에서 일할 당시, 개발자이기도 했지만 말 그대로 ‘사업기획개발’을 맡게 됐는데요. 그때 기획이 다 완성되기까지 기다리기보단 작성 중인 기획서를 바탕으로, 프로토타입을 만들어 보여드렸는데 반응이 매우 좋았어요. 이후에도 일단 만들어 보고 테스트하는 방식으로 진행하다 보니, 자연스럽게 ‘애자일’에 관심을 가졌고, 그러다가 ‘구글 스프린트’를 알게 됐어요. 그래서 한번은 “우리도 구글 스프린트 방식으로 딱 5일만 해보자”라고 제안했는데, 이때 만든 결과물이 내부에서 반응이 정말 좋았고요. 무엇보다 회사 일이 아니라 즐기면서 일하는 듯한 방식에 매료된 거죠. 이후 계속해서 스프린트 방식으로 개발했던 경험이 가장 기억에 남아요.

그래서 스프린트를 일회성 기획이 아니라, 지속적인 개발 방식으로 만들고 싶었어요. 프로토타입이 아닌 개발 중심의 방법을 고려하되, 5일간의 구글 스프린트 템포와 방식은 그대로 유지하면서 말이죠. 이렇게 하다 보니, 자연스럽게 프론트엔드 개발 중심의 스프린트가 탄생하게 됐습니다.

Q. 생각보다 더 체계적이고 재밌는 활동 같아요. 개발자 지망생이나 주니어 개발자들에겐 많은 도움이 될 것 같은데, 운영자로서 힘든 점은 없으신가요?

처음에는 걱정도 많았어요. 나는 이 방식이 재밌고 유용하다고 확신하지만, 다른 사람에게도 통용되는 프로세스일까? 경험이 없는 사람에게도 유용할까? 잘 따라오게 할 수 있을까?가 가장 걱정이었죠. 그리고 저는 경험이 많아 나름 익숙한 방법이지만, 아예 이 방식이 처음인 분들과 해야 했으니까요. 이 프로세스를 모르는 사람도 잘 이해할 수 있도록 진행해야 하는데, 그 점에서 미숙했던 부분도 있죠. 그래도 회차가 늘어나면서 점차 개선했고, 다행히 지금은 스프린트 유경험자들이 스태프로 함께해 주고 있어서 크게 힘든 점은 없어요. 이제는 새로운 사람들과 만나 추억을 다지고, 그들의 아이디어를 통해 저도 많이 배우고 있다고 생각해요.

유용태 개발자가 진행한 2023 두 번째 테오콘(TEOConf) 현장 <출처: 유용태>

Q. 이러한 활동을 통해 주니어 개발자들을 자주 만나실 텐데, 가장 많이 듣는 질문은 무엇이고 어떻게 조언해 주시나요?

가장 많이 듣는 질문은 “제가 하는 방식이 제대로 하고 있는건지 잘 모르겠어요. 다른 회사는 이렇게 일하지 않겠죠?” 같은 질문이에요. 예를 들어, “저희는 이런 식으로 일해요. 혹은 이런 기술로 이렇게 일해요. 구글이나 카카오는 이렇지 않죠?”라는 건데, 저는 회사마다 해결 방식이나 문화는 다르겠지만, 공통적으로 겪는 문제들은 비슷하고 어디서든 겪고 있다고 대답합니다. 그런데 이렇게 답변해도 다들 잘 안 믿어요. (웃음)

아마 각자 현재 회사에서 겪는 문제로 답답하겠죠. “회사에 프론트엔드 개발자가 저뿐이에요.”, “사수가 없어요”, “너무 레거시한 기술을 씁니다.”, “기술 스택을 바꾸자고 하는데 제 말을 들어 주지 않아요.”, “일정이 너무 타이트한데 조정을 안 해줍니다.” 실제로 이런 얘기들은 아무리 좋은 회사라도, 어딘가에서는 벌어지고 있는 상황이잖아요.

이럴 때 들려드리는 이야기는 ‘순서는 달라질 수 있겠지만, 결국 한 번은 다 경험해야 한다.’예요. 결국은 각자 궁극적으로 꿈꾸는 ‘좋은 개발자’의 모습이 있을 거고, 커리어는 계속 쌓아가야 하잖아요. 그래서 개발자의 커리어를 최소 20년 정도로 길게 봤을 때, 다양한 경험을 해봐야 좋은 개발자가 된다고 생각하거든요.

Q. 구체적으로 어떤 경험일까요?

예를 들어, 사수가 없이 혼자 개발해야 하는 경험, 레거시 자체를 해보는 경험, 그걸 또 개선해 보는 경험, 새로운 서비스를 개발해 보는 것, 유지보수를 해보는 것, 운영이나 버그를 잡는 것도 다 한 번씩은 필요한 경험이에요. 지금 다니는 회사의 상황 또한 채워야 할 하나의 경험이라면, 여기에서 내가 어떤 것을 채울 수 있는지 알면 돼요. 그래서 그걸 채워나가고, 다 채웠다고 생각하면 용기를 내서 이직해 보라고 조언하죠.

한 마디 더 보태면 ‘회사 생활과 이직은 배타적인 게 아니다.’라는 얘기도 해줍니다. 이직할 마음이 있다고 해서, 회사 생활을 열심히 안 해야 할 이유는 없다고요. 반대로 회사 생활이 너무 즐겁다고 해서 이직을 생각하는 게 배신이나 잘못된 것이 전혀 아니라는 것이죠. 현재 환경에서 최선을 찾아 보고, 그걸 해내는 것이 가장 중요하다고 말해줍니다.

‘시니어 개발자’가 된다는 것

Q. 10년 넘게 개발자로 일하셨어요. 시니어 개발자에게 ‘커리어’란 뭐라고 생각하시나요?

개발자에게 커리어는 ‘내가 지금까지 얼만큼 걸어왔구나’라는 것을 보여주는 일종의 흔적 같은 거라고 생각해요. 제가 10년 넘게 개발자를 하고 있지만, ‘내가 이렇게 가야지’라고 생각해서 지금의 커리어를 갖게 된 건 아니거든요. 처음에는 이런저런 멋진 꿈과 커리어를 그렸었는데, 그렇게 뭘 정하고 가려고 하니 오히려 괴로운 순간들이 많았어요.

세상이 원래 내 뜻대로 다 되는 건 아니잖아요. 이걸 깨닫고 나니 ‘뭐든 그냥 열심히 해야지’라고 생각하며 살아왔는데요. 지금까지 와보니 ‘내가 이렇게 흘러왔네’가 어느 순간 보이더라고요. 그래서 커리어는 내가 최선을 다해 걸어온 나의 길에 대한 흔적이고, 그 흔적이 무엇이든 정답은 없을 것 같아요.

Q. 카카오엔터프라이즈에선 파트장으로 팀을 리딩하셨는데, ‘원활한 협업’을 위해 어떤 점을 신경쓰셨나요?

저는 좋은 팀이 되려면 팀원들이 ‘내가 팀원으로서 어떤 얘길 해도 안전하다.’라는 믿음을 가지고 있어야 한다고 생각해요. 그래야 스스로 무언가를 하는 데 있어서 주저함 없이 함께 할 수 있어요. 이를 ‘심리적 안전감’이라고 하는데, 저 역시 누군가 어떤 의견을 내더라도 “이 사람이 내 얘기를 들어주겠구나.”라는 기본적인 믿음을 가질 수 있게 분위기를 조성하고자 했어요.

Q. 그렇다면 리더로서 ‘함께 일하고 싶은 팀원’은 어떤 사람인가요?

꼭 리더의 관점이 아니더라도 같이 일하고 싶은 팀원은 ‘밝고 무해하며 기꺼이 하려고 하는’ 사람인 것 같아요. 팀으로 함께 일하다 보면, 우리 일인것은 확실한데 내 일인지, 다른 사람의 일인지 애매한 경우가 많아요. 그런데 그걸 내 일처럼 함께하려고 하는 사람들이 있어요. 뭔가 하나라도 누군가를 도와주려고 하는 사람과 일하고 싶죠.성과가 바로 나타나지 않는 일이라도, 우리 팀의 일이라면 기꺼이 할 수 있는 사람이라면 결국 어떤 성과든 보여주게 되는 것 같아요. 저도 그런 사람이 되려고 여전히 노력하고 있고요.

Q. 주니어, 미드레벨, 시니어 개발자의 가장 큰 차이점은 무엇일까요? 스스로 ‘시니어’라고 느낄 수 있으려면 어떤 역량이 필요할까요?
우선 업무를 진행함에 있어 누군가의 도움이 꼭 필요하다면 주니어, 목표가 주어졌을 때 혼자서도 할 수 있다면 미드레벨이라고 생각합니다. 이때 누군가의 ‘도움’이 단순히 코딩을 할 수 있고 못하고의 범주는 아니에요.

주니어라도 코드에서는 막힘없이 개발을 잘하는 분들이 많아요. 하지만 업무에서 이 일이 언제까지 가능한지, 그다음에는 무슨 일을 해야 하는지, 누구에게 전달하고, 어떻게 공유해야 하는지 같은 부분을 모두 포함합니다. 그래서 보통 스스로 개발이 가능하고 일정 판단과 조율이 가능하며, 원활하게 소통할 수 있으면 미드레벨이 되었다고 생각해요.

여기서 한발 더 나아가 시니어의 경우, 프로젝트 단위에서 스스로 해낼 수 있으면 됩니다. 그러기 위해서는 주니어와 미드레벨 개발자에게 업무를 할당하고, 그에 맞는 도움도 주어야 하죠. 또한 남들보다 더 넓은 시각으로 바라보고 결정을 내리거나 설득해야 해요. 기술 스택에 관한 결정이나 프로젝트 구조가 될 수도 있고, 다른 사람들과 소통하거나 공유가 필요한 때도 있죠.

이러한 일들을 해내려면 기술뿐만 아니라 도메인 지식도 충분해야 하고, 회사의 사정도 잘 알고 있어야 합니다. 프로젝트를 성공시키기 위해서는 업무를 스스로 만들어 낼 줄도 알아야 하니까요. 내가 하고 있는 개발이 어떠한 업무인지를 이해하고, 개발과 일을 컨트롤 할 수 있는 게 ‘미드레벨’로 가는 역량이라면, ‘시니어’는 이러한 일들이 모여서 어떤 가치가 되고, 어떻게 소통하고 흘러가는지를 이해해야 합니다.

더 큰 가치를 만들기 위해 어떤 일을 만들어야 하는지, 누구에게 어떻게 분배할지, 어떻게 소통하며 다시 의견을 모아야 하는지 등을 아는 역량이죠. 개발이 ‘가치를 만들기 위한 도구’라면 도구를 더 잘 다룰 수 있게 숙련하는 것도 중요하지만, 그 도구로 만든 결과물의 가치를 높이는 역량 또한 매우 중요합니다. 결국 개발자의 역량은 요구사항에 대한 결과물과 기간으로 평가받기 마련이니까요.

개발자의 동력과 성장에 관해

Q. 현재 본업 외에도 멈추지 않고 무언가를 계속해 나가고 계신데, 그 원동력은 무엇인가요?

처음엔 나 자신을 알리고, 스스로를 증명하는 게 중요한 동력이었던 것 같아요. 그리고 그 방법으로써 남을 돕는 방식을 선택했어요. 당시 읽었던 ‘기버’라는 책에 큰 영감을 받았는데요. 그 과정에서 내 경험으로 누군가에게 도움을 줄 수 있게 된 거죠. 그 이후로는 자연스럽게 누군가를 돕는 활동이 꾸준히 이어졌어요. 그리고 함께하는 과정에서 많은 사람들과 이어지게 됐고, 이제는 그 사람들로 하여금 무언가를 하게 되네요. 지금은 특별히 어떤 원동력이라고 말하기보단, 함께 하는 사람들이 생기니까 의도하지 않아도 계속 나아가는 느낌입니다.

Q. 개발자로서 현재 위치에 오기까지 어떤 점이 큰 영향을 주었나요?

개발자가 되고 나서는 함께하는 사람들에게 영향을 많이 받았어요. 여러 회사에 다녀 보니 ‘좋은 개발자’는 그저 코딩만 잘하는 사람은 아니더라고요. 저도 개발자라면 ‘개발 실력’을 증명하는 게 가장 중요하다고 생각했는데, 실력만이 다가 아니라는 것을 알게 됐죠. 결국 누구나 복합적인 능력으로 평가받기 마련인데, 다양한 사람을 만나 보고 시야를 넓히는 게 관건인 것 같아요. 사람들을 많이 만날수록 새로운 자극을 얻고, 동기부여가 되니까요. 같이 일하는 팀원들에게서도 자극받을 때가 많았는데, “저렇게 열심히 사는구나”라는 생각이 들어서 스스로 반성하기도 합니다.

그 다음은 ‘책’인데 특히 철학과 인문학의 영향을 많이 받았죠. 좋은 사람, 실력 있는 사람이 되기 위해 어떻게 성장해야 할지, 어떻게 일해야 할지, 어떻게 살아가야 할지, 어떻게 사람들을 대해야 할지에 대한 답을 책을 통해 깨닫고, 현실에 적용해 가며 성장했다고 생각해요.

Q. 블로그에 꾸준히 글을 쓰고 계신데, 테오 님만의 ‘글쓰기 노하우’도 있을까요?
이게 노하우일지 잘 모르겠지만, 저는 글쓰기 전에 우선 녹음기를 켜요. 그리고 내가 적고 싶은 내용을 말로 설명해 보죠. 좋은 글은 말하듯이 쓰는 것이라고 하는데, 잘 작성된 글은 마치 음성 재생되듯 읽히죠. 백지에 글을 쓰려고 하면 막막함이 있는데, 일단 말해보는 건 좀 더 편하게 시작할 수 있는 것 같아요.

이렇게 녹음된 내용을 음성 변환 도구를 사용해서 글로 바꿔요. 그러면 글을 쓰지 않아도 재료가 생기죠. 이렇게 재료를 모은 후, 그룹화해서 적절한 제목을 달아줍니다. 마치 개발자가 코드를 모아 함수로 추상화하는 과정처럼요. 이렇게 만들어진 블록의 순서를 적절히 재배치하고, 더 큰 구조를 만들어가는 과정을 반복합니다. 이렇게 글의 구조를 설계하는 거죠.

한 가지 중요한 점은 읽는 사람을 고려하면서 써야 해요. 코딩할 때도 마찬가지인데, 내가 아는 내용이라 의도치 않게 맥락을 생략하는 경우가 많거든요. 그런데 읽는 사람의 대부분은 그 맥락을 모를 수 있어요. 그래서 찬찬히 읽어보며, 한 번도 설명하지 않은 내용이 갑자기 나오지 않았나 확인하죠. 마치 코딩할 때 선언하지 않았던 변수를 사용하는 걸 체크하는 것과 같아요. 내가 아는 내용이니 무심코 건너뛰지 않도록, 이 글만으로도 설명이 가능한 글을 쓰려고 노력하고 있어요.

Q. 성공한 개발자란 어떤 개발자라고 생각하시나요?

성공을 본인이 어떻게 정의하느냐에 따라 다를 것 같아요. 처음 사업을 시작했을 때는 소위 대박 나서 ‘돈을 많이 번 개발자’가 성공한 개발자라고 생각했어요. 그래서 성공하지 못했다는 생각에 심리적으로 많이 힘들었죠. 그다음에는 인지도를 쌓아서 ‘유명한 개발자’가 되어야 성공한 것이라 생각했어요. 그런데 나름 열심히 인지도를 쌓아가는 과정에서 현타가 오더라고요. 인지도를 성공이라고 생각하니 다른 사람들과 자주 비교하게 됐거든요. 그래도 이런 과정들을 거쳐, 이제는 ‘남을 도울 수 있는 개발자’가 되는 것이 성공이라고 생각합니다. 이렇게 생각하면 지금은 꽤 성공한 개발자가 아닐까 싶네요.

Q. 앞으로 어떤 직업인으로 성장하고 싶으신가요? 성장을 위해 하고 있는 노력이 있다면요?

고민은 하고 있는데 지금과 같은 일을 계속해 나가고 싶어요. 개발 경력이 10년 차가 넘으면서 시니어가 됐지만, 성장은 멈출 수 없다고 생각해요. 물론 열심히 한다고 해서 무조건 잘 된다는 보장은 없지만요. 그래도 안 하면 0%고, 뭐라도 하면 뽑기권 10장 정도는 받을 수 있는 거예요. 그 뽑기가 당첨될 확률을 계속 높이고 싶죠. 지금 할 수 있는 것들을 해 나가면서요. 예를 들어, 제가 사수 없이 일해왔기 때문에 ‘사수가 없어서 고민이에요’라고 말하는 사람들을 보면 도와주고 싶어져요. 개발자라고 해서 너무 개발만 하지 않도록 이끌어주고 싶고, 앞으로도 ‘테오’라는 이름으로 이런 일들을 해나갈 수 있을 것 같아요.

Q. 꿈이 있다면?

지금보다 조금 더 나은 사람이 되고 싶어요. 회사에서는 함께 일하고 싶은 사람이 되고 싶고, 가족에겐 좋은 아빠이자 남편으로요. 그리고 내가 만든 라이브러리를 많은 사람들이 써줬으면 좋겠고요. (웃음) 저는 테오로 활동하며 사람을 만나는 기회가 늘었고, 할 수 있는 일도 많아졌어요. 삶의 스펙트럼이 넓어진 만큼 더 많은 사람을 도우며 살고 싶습니다.

김소희 에디터 [email protected]

로그인하고 자유롭게 의견을 남겨주세요.