취준생 대부분 포트폴리오를 잘못 만들고 있습니다 transcript

안녕하세요. 생각대입니다. 오늘은 포트폴리오 만드는 방법을 말씀드리겠습니다. 여러분은 포트폴리오라고 하면 뭐가 가장 먼저 떠오르시나요? 치준생분들이나 이직하시는 분들과 이야기해 보면 포트폴리오라는 말을 듣는 순간 대학 발표할 때 만들었던 PPT나 디자인부터 떠올리는 경우가 정말 많은 거 같습니다. 그러다 보니까 내가 만들었던 앱에 대한 설명을 놓고 프레트 화면 캡처분을 놓고 기능을 하나씩 나열하면서 뭔가 예쁘게 꾸미는 것에 굉장히 집중하는 거 같아요. 그런데 저는 이게 보편적인 포트폴리오라고 생각하지 않습니다. 물론 디자인처럼 일부 직무에서는 보여주는 방식 자체가 중요할 수 있습니다. 다만 대부분의 직무에서는 그것보다 훨씬 중요한 것이 따로 있습니다. 그래서 오늘 영상에서는 포트폴리오라는 것을 아예 다시 한번 재정의를 해 보려고 합니다. 그리고 실제로 어떤 순서로 써야 하는지까지 최대한 쉽게 말씀드려 보겠습니다. 자, 시작을 해 볼게요. 먼저 포트폴리오를 큰틀에서 한번 제정해 보겠습니다. 저는 포트폴리오는 문제 해결의 상세함을 보여주는 자료라고 생각합니다. 면접관이 포트폴리오를 봤을 때 가장 먼저 느껴야 하는 건 이런 겁니다. 아,이 지원자는 이런 문제를 발견했고 이렇게 원인을 파악했고 이런 해결 방법을 선택했고 이렇게 테스트해서 실제로 적용했구나. 이게 그냥 쭉 읽혀야 하는 거예요. 내가 어떤 기술을 썼다는 것을 자랑하는 자료가 아니라 내가 문제를 어떻게 바라보고 어떻게 판단하고 해결했는지를 면접간이 편하게 따라할 수 있도록 가독성 정리해 놓은 자료인 겁니다. 앞에 보이시죠? 이게 하나의 문제 해결에 상세함 덩어리라고 생각하시면 됩니다. 이런 덩어리가 포트폴리오 안에 한네 개 정도만 쭉 나열되어 있으면 됩니다. 생각보다 복잡하지 않아요. 하나의 덩어리 안에는 제목이 있고 그림이 있고 문제가 있고 해결 과정이 있고 마지막에 결과가 있습니다. 저는이 순서만 잘 지켜도 포트폴리오의 기본적인 가독성은 굉장히 좋아진다고 생각합니다. 먼저 맨 위에는 제목이 있습니다. 제목은 정말 간단합니다. 어떤 기능에서 어떤 문제가 있었는지를 보고 한 문장으로 적으면 됩니다. 예를 들어 개발자라면 대용량 조회 과정에서 발생한 응답 지연 개선 이런 식으로 적을 수 있는 거고 마케팅이라면 광고 전환율이 떨어지는 구간 개선 이런 식으로 적을 수 있습니다. 제목만 봐도 아이 덩어리에는이 문제를 해결했구나라는게 바로 보여야 합니다. 제목에서부터 멋있는 말을 쓰려고 하지 마세요. 그냥 어떤 문제를 해결했는지 정확하게 보여 주는게 가장 좋습니다. 그리고 그 바로 아래에 그림을 하나 넣어 주세요. 저는이 그림이 생각보다 굉장히 중요하다고 생각합니다. 면접관이이 그림만 딱 봤을 때 전체적인 상황이 한 눈에 들어와야 합니다. 개발자라면 데이터가 어떻게 흘러가는지 아키텍처를 그릴 수 있고 호출 순서를 보여 주고 싶다면 시퀀스 다이어그램을 그릴 수 있습니다. 성능 개선을 했다면 테스트 전후 결과를 막대 그래프로 보여 줄 수 있고 특정 기능의 흐름이 중요하다면 그 기능의 흐름을 그림으로 표현해도 됩니다. 중요한 건 그림의 종류가 아닙니다. 면접관이이 주제를 이해하 가장 도움이 되는 그림을 넣는 겁니다. 그런데 여기서 제가 정말 말씀드리고 싶은게 있습니다.이 그림 AI로 대충 만들지 마세요. 요즘 AI가 그림도 잘 만들어 주고 아키텍처럼 보이는 것도 굉장히 잘 만들어 줍니다. 그런데 실제로 보면 생각보다 건성으로 만든 느낌이 굉장히 많이 납니다. 특히 내가 직접 경험한 프레트인데 내가 구조도 하나 제대로 설명하지 못해서 AI가 만들어 준 그림을 그대로 넣는다면 오히려 신뢰감이 떨어질 수 있습니다. 직접 그리세요. 예쁘게 그릴 필요도 없습니다. 박스 몇 개 놓고 화사표 몇 개 연결해도 됩니다. 중요한 건 내가 실제로 이해하고 있는 구조를 면접관이 한 눈에 볼 수 있도록 만드는 겁니다. 그리고 이제 문제 부분이 나옵니다. 여기에서는이 문제를 어떻게 발견했는가를 쓰면 됩니다. 어떻게 문제를 찾았고 실제로 어떤 현상이 발생하고 있었는지를 딱 세 주 정도로 정리하시면 됩니다. 예를 들어 하나를 보다가 특정 시간대의 응답 시간이 계속 증가하는 것을 확인했다고 쓸 수 있습니다. 메모리가 계속 차는 현상을 발견했다던가 특정 커리에서만 처리 시간이 길어진다는 것을 발견했다고 쓸 수도 있습니다. 여기에서 정말 길게 쓰시는 분들이 있는데 저는 굳이 그럴 필요가 없다고 생각합니다. 문제는 세 줄이면 충분합니다. 어떻게 발견했고 어떤 문제가 있었고 왜 이걸 해결했는지이 정도만 보여 주세요. 그리고 그다음이 해결 가정입니다. 여기에서는 이제 실제로 내가 무엇을 했는지를 쓰는 거예요. 어떤 기술을 사용했는지, 어떤 커리를 수정했는지, 어떤 방식들을 비교했는지, 왜 최종적으로이 방법을 선택했는지 이런 내용을 논리적으로 적으시면 됩니다. 그런데 이것도 정말 길게 쓰지 마세요. 포트폴리오는 기술 블로그가 아닙니다. 저는 이것도 한 세 줄에서네 줄 정도면 충분하다고 생각합니다. 면접간이 보고 아 이런 이유 때문에이 방법을 선택했구나라는 흐름만 이해할 수 있으면 됩니다. 그리고 요즘은이 문제 해결 과정 쓰는 것도 예전보다 훨씬 쉬워졌습니다.

AI가 있기 때문이에요. 내가 실제로 했던 일을 AI에게 설명하고 이걸 문제와 해결 과정으로 정리해 줘라고 하면 생각보다 굉장히 잘 정리해 줍니다. 그래서 글을 쓰는 거 자체는 이제 예전만큼 어렵지 않습니다. 다만 절대로 AI가 만들어 준 내용을 그대로 복사해서 붙이지는 마세요. 내가 하지 않은 판단이 들어갈 수도 있고 실제로는 사용하지 않은 기술이 들어갈 수도 있고 너무 그럴듯한 말만 가득해질 수 있습니다. AI는 내가 했던 일을 읽기 좋게 정리해 주는 용도로 사용하시고 내용 자체는 반드시 내가 했던 경험을 기준으로 작성하셔야 합니다. 그리고 마지막으로 결과가 있습니다. 결과에서는이 문제를 해결하고 나서 실제로 무엇이 달라졌는지를 보여 주시면 됩니다. 성능이 좋아졌다면 응답 시간이 얼마나 개선됐는지 쓸 수도 있고 메모리 누수를 해결했다면 더 이상 해당 현상이 발생하지 않는다고 쓸 수도 있습니다. 개발 직무가 아니더라도 마찬가지입니다. 유관부서에 업무 시간이 줄었다던가 운영 과정에서 반복 작업이 감소했다던가 생산성이 좋아졌다는 내용을 쓸 수도 있습니다. 결과는 가능하면 그래서 뭐가 좋아졌는데 대답할 수 있도록 써 주세요. 그리고 여기서 굉장히 중요한게 하나 나옵니다. 만약 성능 개선을 했고 부하 테스트까지 진행했다면 테스트 조건을 꼭 같이 써 주세요. 그냥 TPS가 두 배 증가했습니다. 이렇게만 쓰면 생각보다 신뢰성이 떨어집니다. 어떤 환경에서 테스트했고 서버 스펙은 어느 정도였고 어느 정도의 요청을 넣었고 그 결과 어떻게 바뀌었는지를 같이 보여 주는 겁니다. 예를 들어 2코어 2GB 환경에서 몇 TPS로 몇 분간 부활를 줬고 응답 시간이 얼마에서 얼마로 개선됐는지 이런 조건들이 같이 들어가면 결과 자체의 신뢰도가 굉장히 높아집니다. 저는 포트폴리오에서 숫자를 쓰는 것만큼 그 숫자가 나온 조건을 같이 보여 주는 것도 정말 중요하다고 생각합니다. 자, 이렇게 해서 하나의 덩어리를 만들었습니다. 제목이 있고 그림이 있고 문제가 있고 문제 해결 과정이 있고 마지막에 결과가 있습니다. 이렇게 한네 개 정도 만들어서 쭉 나열하시면 됩니다. 그런데 여기서 정말 중요한게 있습니다. 두 번째 덩어리를 만들 때도 똑같은 순서로 사용해야 합니다. 제목, 그림, 문제, 해결, 결과 세 번째도 똑같이 가세요.네 번째도 똑같이 가시면 됩니다. 왜냐하면 이게 결국 가독성이기 때문입니다. 첫 번째에서는 제목, 다음에 그림이 있었는데 두 번째에서는 갑자기 그림이 없어지고 문제가 먼저 나오고 세 번째에서는 결과가 위에 있고 아키텍처가 마지막에 있고 이렇게 되면 보는 사람 입장에서는 계속 읽는 방법이 달라져야 합니다. 굉장히 사소해 보이지만 이게 쌓이면서 포트폴리오가 굉장히 읽기 어려워집니다. 반대로 모든 덩어리의 구조가 똑같으면 면접가는 두 번째부터는 어디서 어떤 내용이 있는지 바로 알 수 있습니다. 저는 이게 포트폴리오에서 정말 중요한 가독성이라고 생각합니다. 그리고 만약 어떤 경험을 넣으려고 하는데 여기에는 넣을 그림이 없는데라고 생각이 든다면 저는 한번 고민해 보셨으면 좋겠습니다. 정말이 경험이 포트폴리오에 들어갈 정도로 구체적인 문제 해결 경험이 맞는지 보는 거예요. 물론 모든 경험에 무조건 아키텍처가 있어야 한다는 이야기는 아닙니다. 다만 어떤 흐름도 보여 주기 어렵고 테스트 결과도 보여 주기 어렵고 전후 비교도 보여주기 어렵다면 그 경험은 이력서에는 들어갈 수 있어도 포트폴리오에서 상세하게 풀기에는 조금 약한 경험일 수 있습니다. 포트폴리오는 결국 상세하게 보여줄 가치가 있는 경험을 골라서 넣는 자료이기 때문입니다. 자, 오늘 말씀드린 내용을 정리해 볼게요. 포트폴리오를 PPT처럼 생각하지 마세요. 앱, 화면, 캡처 몇 장 넣고 기능 설명을 나열하는 자료도 아닙니다. 포트폴리오는 내가 문제를 어떻게 발견했고 어떻게 해결했고 그 결과 무엇이 달라졌는지를 상세하게 보여주는 자료입니다. 하나의 문제 해결 경험마다 제목, 그림, 문제, 해결, 결과이 순서로 하나의 덩어리를 만들고 그 덩어리를 한네 개 정도 일간된 형태로 쭉 보여 주세요. 그것만 제대로 해도 포트폴리오의 방향성 자체가 굉장히 많이 달라질 겁니다. 특히 포트폴리오를 만들면서 디자인 때문에 너무 많은 시간을 쓰지 않았으면 좋겠습니다. 자, 이렇게 포트폴리오에 대해서 한번 말씀드려 봤습니다. 다음에는 조금 다른 이야기를 해 보려고 합니다. 회사라는 것은 대체 무엇일까? 개똥이 아닐까라는 주제로 한번 이야기해 보겠습니다. 회사라는 걸 조금은 가볍게 바라봐도 되는 이유와 왜 회사가 내 인생의 전부가 될 필요가 없는지 제 생각을 한번 풀어 보려고 합니다. 구독해 주시고 다음 영상도 기다려 주세요.