서류 전형 Q&A 답하기

Q1. 프로그래밍을 시작한 경위와 본격적으로 투신하고 생업으로 삼기로 결정한 이야기를 해주세요.

어릴 때부터 컴퓨터와 무엇을 만든다는 것에 흥미가 많았습니다. 예를 들어 고무줄 총 만들기, 스타크래프트 유즈맵 만들기 등이 있습니다.
그러다 보니 프로그램을 만들어보자는 생각에 방과 후 수업 및 방학 동안 선린인터넷고등학교에서 교육을 받으며 프로그래밍을 시작했고, 자연스럽게 특성화 고등학교에 진학하게 되었습니다.

프로그래밍은 공부할수록 부족하다는 것을 알려주고 더 나은 방향을 제시해주어 끊임없이 발전할 수 있게 해줍니다. 이렇게 공부한 만큼 결과가 나온다는 것이 가장 매력이고 재미있는 부분이라고 생각합니다.

저는 이러한 프로그래밍을 계속 배우고 즐기기 위해 생업으로 삼았습니다.

Q2. 좋은 개발자가 되기 위해 갖추어야 한다고 생각하는 덕목 셋을 고르고 그 이유를 말해주세요. (예를들어 책임감, 꼼꼼함, 유연성 등등)

학습, 경청, 책임감
좋은 개발자는 도태되지 않으며 다른 사람들의 의견에 귀 기울이고 자신의 코드에 책임감을 느껴야 한다고 생각합니다.

학습
개발이라는 분야는 빠르게 변화합니다. 하루 만에 라이브러리가 지원되거나 개선되고, 갑자기 지원하던 라이브러리가 갑자기 중단되기도 합니다. 이러한 상황에서 개발자는 ‘학습’을 통해 더 나은 방향으로 계속 나아가야 합니다.
물론 지속해서 학습을 안 하고 개발은 가능합니다. 하지만 자동차로 비유하자면 남들은 친환경적인 자동차를 타고 가는데 오래된 자동차로 연비(속도 및 접근성이 좋은 라이브러리의 포기)와 매연(다른 개발자의 유지보수)으로 고통이 있을 거라고 생각합니다.

공유
많은 회사가 솔루션을 개발할 때 기획자, 디자이너와 협업하고 고객관리팀과 소통합니다. 그 과정에서 솔루션에 문제가 발생하거나 변경사항이 생겼을 때, 개발자가 임의로 변경 후 공유를 하지 않는다면 다른 팀에서는 추후 확인했을 때 무슨 기능이고 어떻게 응대해야하는지 파악이 불가능합니다. 개발 업무에서도 같습니다. 프로젝트의 구조를 변경하거나 새로운 기술을 도입할 때, 혼자서만 진행을 하면 다른 팀원들은 무슨 기술이 추가되었고 어떻게 사용해야 하는지 파악할 수 없습니다. 이러한 문제가 이어지면 한 프로젝트 내에서 파일들이 각자 다른 라이브러리와 코딩스타일이 되어버리고, 유지보수 관점에서 매우 안 좋게 됩니다. 또한 기술의 공유는 회사와 회사 개발자들의 가치를 높이는 방법의 하나라고 생각합니다. ( 개발자 세미나 )

책임감
자신이 만든 프로그램과 작성한 코드에 책임감을 느껴야 한다고 생각합니다. 책임감 없이 ‘돌아가기만 하면 되지’ 라는 생각으로 개발하게 된다면, 다른 개발자가 투입되었을 때 알아보지 못하는 코드가 되며 유지보수가 힘들어집니다.
일정을 맞추기 위해 급하게 개발을 진행하더라도 책임감을 가지고 리팩토링을 이뤄야 합니다.
모든 소스코드는 리팩토링을 반복할수록 더 좋은 성능과 안정성을 가진다고 생각하며, 최종적으로는 누가 봐도 유지보수가 가능한 깨끗한 코드가 되어야 합니다.

Q3. 지금까지 읽었던 개발서 중 가장 중요하다고 생각하는 책 3권을 골라 선정한 이유를 말해주세요.

필요한 자료를 찾거나 학습할 때 구글 검색을 하다 보니 개발서를 많이 안 읽은 부분이 있습니다. ( 최근에는 기초 공부, 많은 사람의 생각을 알기 위해 찾아 읽고 있습니다. ) 그렇기에 가장 인상 깊었던 책과 세미나를 적어드립니다.

Clean Code
코드를 작성할 때 에러 처리, 테스트, 최소화 등 작업은 진행하였지만, ‘깨끗한 코드를 작성해야겠다’라는 생각은 가지지 않았습니다. 클린코드에서는 제 생각과 코드에 안 좋은 부분들 정확히 짚어내 주었고, 클린 코드를 작성하는 방법을 배웠습니다.

예를 들어, 저는 주석은 다른 개발자가 접근했을 때 파라미터나 어떤 함수인지 한눈에 알아볼 수 있어야 한다고 생각하였습니다. 하지만 어느 순간부터 의무적으로 작성하고 불필요하게 함수 내 특정 기능에 대한 주석도 추가하기 시작했습니다. 클린 코드에서는 이러한 부분을 나쁜 주석으로 정의해 주었고, 현재 최소한의 주석으로 의미를 전달하기 위해 노력 중입니다.

이 외에도 많은 도움을 받았던 책입니다.

네이버 TECH CONCERT: FRONT END - 오늘부터 나도 FE 성능분석가
해당 세미나에서는 프로그래밍이 아닌 초기 로딩속도에 관하여 Waterfall 차트의 폭을 어떻게 줄이는지, 사용자의 체감속도, DOM Rendering 등을 설명하였습니다.

프론트 개발을 진행하면서 ‘첫 로딩 속도를 어떻게 개선할까?’라는 생각으로 Webpack 개선, 데이터 호출 API 개선 정도만 반영했었습니다. 세미나는 새로운 부분과 어떻게 개선해야 하는지를 알려주는 부분들이 제게 프론트에 대한 시선을 넓게 보게 해주었고, 이렇게 전문적이고 모르는 부분들을 더 많이 배우고 싶다고 느끼게 되었습니다.

Q4. 기술 경향을 파악하고 업무 역량을 강화하기 위한 본인의 학습 방법을 구체적으로 설명해주세요.

프로그래밍과 사용하는 라이브러리, 배우고 싶은 라이브러리 등 그룹이나 슬랙 채널에 가입하여 기술 경향을 파악합니다. 그룹에서는 새로운 라이브러리나 업데이트, 개발자가 알아야 하는 부분들의 공유가 활발하여 학습에 많은 도움이 됩니다.

저는 항상 부족하다고 생각합니다. 최근 코딩테스트와 면접을 진행하면 더 많은 것이 느꼈습니다.
다른 회사의 기술 경향 그리고 어떤 기초가 필요한지를 이해하며 서적과 인터넷 강의를 통하여 배우고 있습니다.

React 개발 기법과 프로젝트 구성, React Hooks의 도입을 배우기 위해 강의 수강 및 youtube, 공식 문서를 찾아보았고, 다른 사람들은 프론트개발을 어떻게 하는지 알기 위해 세미나를 시청하였습니다.
최신 경향이 무엇인지 파악하기 위해 그룹 외에도 youtube에 올라오는 자료들을 확인했습니다.
궁금한 부분을 검색하거나 동료에게 물어봐도 해결 방안을 찾을 수 없다면 커뮤니티나 스택오버플로우을 찾아보고 있습니다.

최근에는 알고리즘 실력을 향상하기 위해 프로그래머스라는 사이트에서 공부 중입니다.

저는 위처럼 부족한 부분이 무엇인지에 따라 각각의 방식으로 계속 채워가고 있습니다.

Q5. 지난 개발 프로젝트들의 아쉬운 점이 있었다면 무엇이고, 개선 방안은 무엇일까요?

처음부터 투입되지 못한 프로젝트들이 아쉽습니다.
개발자들이 흔하게 말하는 것 중 하나가 환경설정이 가장 어렵다는 것입니다. 프로젝트를 구성할 때 환경설정을 직접하고 배우지 않는다면, 다음에 같은 환경으로 개발을 진행하고 싶을 때 프로젝트를 시작하기 힘든 부분이 있습니다.

저는 이러한 부분을 개선하기 위해 새로 배운 부분들은 토이 프로젝트로 직접 환경을 구성하고 개발을 진행해보고 있습니다.

미숙한 부분들로 인한 반복작업
코드를 개발하다 보면 나중에 ‘이전에 개발한 부분도 이런 방식으로 개발했으면 더 깔끔하겠다’라는 생각을 자주 하게 됩니다.

크게 어려운 코드는 아니었지만, 처음에 구조만 잘 설계했다면 작업하지 않아도 될 부분도 있었습니다. 이러한 반복적인 작업들이 모이게 되면 업무시간에서 큰 비율을 차지하게 됩니다.

저는 이러한 부분들은 Q4에서 답변드렸던 것처럼 많은 개발자의 노하우를 공부하고 저의 지식과 개성을 합쳐 재사용성이 뛰어난 깨끗한 코드를 작성할 수 있도록 노력하고 있습니다.

Q6. ‘좋아하는 시나 소설, 노래 중심으로’ 자신을 자유롭게 소개해 주세요. (지원동기/이직사유, 장/단점 등)

소설 - 희생부활자 ( 주의 : 약간의 예를 설명 드리면서 스포일러가 될 수 있습니다. ) 책 선정 이유는 내용보다 제대로 읽은 첫번째 소설이며, 제가 읽는 방식을 중점으로 말씀드리려고 합니다.

저는 소설을 좋아합니다. 소설을 읽다보면 어느 순간부터 내용을 머릿속으로 그려내기 시작하는데, 배경, 등장인물, 생김새나 표정, 행동들까지 마치 실제로 본 장면처럼 상상하며 소설을 읽습니다. 이 작품에서 간단하게 예로 부활한 어머니와 아들을 분리하여 가두는 장면에서는 영화로 보던 경찰서 취조실을 그리고 두 사람을 전시적 작가시점으로 바라보며 읽었습니다. 위처럼 상상하며 주인공과 주변인물에 몰입한다는 부분이 소설을 좋아하게 만들었습니다.

이렇게 소설을 읽는 방식은 집중과 더불어 다른 분야에서도 활용되고 있습니다.

손으로 조립하거나 무언가를 만들 때는 다음 조립을 진행했을 때 어떤 결과가 나올까? 상상하며 제작합니다. 코딩을 할 때는 이러한 로직이 실행되면 어떻게 돌아갈까? 개선사항 알고리즘이 어떻게될까? 여러가지를 상상합니다.

저는 위처럼 상상하는 것을 장점으로 생각하지만, 단점으로 보일 때도 있었습니다. ‘차라리 생각하지말고 시도했다면 더 빠른 결과가 나왔을 텐데’라는 생각이 대표적입니다.

하지만 바로 진행한다는 것은 설계를 하지않고 개발을 한다는 것과 같다고 생각한건 여러번의 시행착오 후에 깨달았습니다.

저는 단점을 보완하기 위해 최근에는 전자노트를 사용하고 있습니다.

머릿속에서 나온 로직을 프로그래밍 하지 않고, 여러가지 테스트 케이스를 전자노트에 작성하고 로직을 하나씩 적용해봅니다. 이 방법은 생각보다 많은 오류를 잡아주고 로직을 더 명확하게 만들어줍니다. 이후 테스트 케이스와 로직을 코드로 구현하니 기존에 하는 방식보다 더 빠르게 알고리즘을 작성할 수 있었습니다.