1~6월보다 최근 프로젝트를 진행한 한 달 동안 더 많이 성장하고 있다고 느낀다.
최근에 내가 개발자로 성장하려고 어떤 노력을 하고 있는지 적어보고자 한다.
내가 생각하는 개발자는 단순히 컴퓨터 언어를 사용해서 코딩을 하는 사람은 아니다.
개발자는 어떠한 문제
를 정의하고, 적절한 기술을 사용해서 해결하는 사람이라고 생각한다.
즉, 실력이 좋은 개발자로 성장하려면 문제를 해결하는 능력을 길러야 한다.
여기서의 문제
는 비즈니스 문제 같은 중요한 것들 뿐만 아니라 다양하고 사소한 것들도 포함된다고 생각한다.
예를 들어, A
라는 코드 안에서 사용되는 함수를 B
에서도 사용 가능하게 분리할 때 어떻게 하면 재사용성 높게 할 지도 하나의 문제로 볼 수 있다.
협업 과정에서 다른 사람들도 쉽게 이해할 수 있게 추상화하고 선언적으로 코드를 짜고, 이해 가능한 메서드/변수 명을 고민하는 것도 하나의 문제로 볼 수 있다.
문제 해결력은 단순히 알고리즘 문제를 많이 푼다고 해서 자연스럽게 길러지는 것은 아니다.
문제 해결에는 CS 지식, 프로그래밍 언어에 대한 깊은 이해, 효율적인 구조와 설계에 대한 감각, 코드를 읽고 고치는 능력, 그리고 협업 과정에서의 커뮤니케이션 능력까지도 영향을 미친다.
즉, 개발자로서 문제를 해결하는 능력은 단순한 구현 능력 그 이상이다.
예를 들어, 어떤 기능을 구현할 때도 단순히 동작하게 만드는 것에서 그치지 않고, 어떤 방식이 더 유지보수에 유리할지, 팀원들이 이해하기 쉬운 구조는 무엇인지, 성능과 확장성을 고려한 설계인지를 고민하는 과정에서 문제 해결력이 길러진다.
또한, AI의 성능이 향상되면서 어떤 기능이 동작하게 만드는 건 너무 쉬운 세상이 되어버렸다. 그래서 난 오히려 하나의 기능을 고도화 할 수 있는 능력이 훨씬 중요해지고 있다고 느낀다.
따라서 이번 프로젝트는 하나의 기능을 디테일하게 만드는 것에 집중했다.
우선 본인이 사용하는 기술에 대해서 자세히 알아야한다.
기술을 사용하는 사람이 아니라 활용하는 사람이 되어야하고, 철저한 학습이 선행되어야 한다고 생각한다.
이번 프로젝트에서 로그인 기능을 구현한 과정을 예시로 들어보겠다
우선 여러 인증 방식에 대한 지식을 학습하고 기술 블로그를 작성했다.
참고 - 당신이 로그인을 구현할 때 반드시 알아야하는 것들
이후 토큰 방식 인증을 사용하는 OIDC 소셜 로그인을 구현하는 것으로 결정을 내렸다.
OAuth를 통해 받은 Access Token은 Opaque 토큰이자 베어러 토큰이므로 이를 인증에 활용하면 안된다는 것을 학습했다.
따라서 우리 서버에서 ID Token 검증 이후 자체적으로 Access Token, Refresh Token을 발행하는 방식을 채택하였다.
Access Token는 어디에 저장해야 할 지 고민을 했다.
항목 | Cookie | LocalStorage | SessionStorage |
---|---|---|---|
서버 전송 여부 | 매 요청 시 자동 전송 (Cookie 헤더) | 직접 전송 필요 | 직접 전송 필요 |
보안 옵션 | Secure , HttpOnly , SameSite 설정 가능 | 없음 | 없음 |
브라우저 접근 | JavaScript로 접근 가능 (단, HttpOnly 면 불가) | JavaScript로 접근 가능 | JavaScript로 접근 가능 |
클라이언트에 토큰을 저장할 수 있는 방법인 Cookie, LocalStorage, SessionStorage 중 보안 옵션을 걸 수 있어 그나마 안전한 쿠키를 사용하기로 결정했다.
쿠키에 걸 수 있는 다양한 보안 옵션을 공부하면서, 해당 옵션을 적용했을 때 구현 과정에 끼칠 영향을 고려했다.
예를 들어, httpOnly 옵션은 크로스 사이트 스크립팅(XSS) 공격을 막을 수 있는 옵션이다.
쿠키는 document.cookie
를 통해 접근이 가능한데 httpOnly 옵션을 쓰면 이를 막고, HTTP 요청에만 담기게 된다.
보안적으로 좋지만 프론트엔드 개발자도 쿠키에 대한 접근이 불가능하게 되어, Authorization 헤더에 토큰을 담을 수 없게 된다.
따라서 백엔드에서는 Authorization 헤더가 아닌 쿠키에 접근해 토큰을 검증해야 하고, 프론트엔드에서는 별도로 Authorization 헤더에 담을 필요가 없다는 걸 알았다.
httpOnly 옵션으로 인해 프론트엔드에서는 Access Token에 직접 접근할 수 없기 때문에,
/api/me
엔드포인트에 요청을 보내 사용자의 인증 상태를 확인하고, 그 결과를 상태로 저장하여 UI에 반영하기로 결정했다.
이처럼 구현 과정에 앞서 인증 방식, 토큰 저장 방식의 보안성, 쿠키의 동작 방식과 보안 옵션의 의미를 충분히 학습하고 정리했기 때문에, 실제 구현 단계에서는 설계 변경없이 빠르게 개발을 진행할 수 있었다.
디테일한 개발을 위해선 기초가 튼튼해야 한다고 느꼈고, 우리 팀에서 하는 추가적인 활동도 소개하겠다.
우리 프로젝트에는 딥다이브라고 불리는 시간이 있다.
매일 아침 데일리 스크럼이 끝나면 하루에 2시간정도 언어나 프레임워크에 대한 지식을 학습한다.
예를 들어, 클로저를 학습한다고 가정하면 개념에 이어서 추가적으로 연관된 지식을 학습하는 방식으로 진행한다.
이 때, AI와 공식문서를 최대한 활용하고자 하는데
mdn이나 리액트 공식 문서를 활용해 나만의 답변을 먼저 작성하고, AI에 질문을 해서 내 답변이 적절한지와 추가적으로 학습할 내용을 물어보는 방식으로 학습하고 있다.
3주 동안 프론트 파트는 160개, 백엔드 파트는 130개가 넘는 질문/답변을 작성했다.
아래는 실제 우리 팀에서 사용하는 프롬포트이니 시도해보려는 사람은 참고하면 좋을 것 같다.
나는 자바/ 스프링 백엔드, 자바스크립트 프론트엔드로 입사하려는 신입 개발자야
너가 웹 개발 20년차 전문 CTO 및 면접관 입장에서
지원자가 대답하면 좋을 것 같은 답변을 작성하는 걸 도와줘야 돼
나는 두괄식패턴인 OREO 방식으로 2~3줄에서 3~5줄 사이로 답변을 작성하고 싶어
그리고 한번에 모든 걸 말하지 않고
묻는 질문에 대한 핵심 내용만 답변한 다음 추가질문을 유도할 거야
따라서 내가 질문을 하면 최대 3~4줄 정도로 답변하고
예상되는 추가 질문을 작성해줘
우리 팀은 주 1회 기술 블로그 작성을 강제하고 있다.
기술 블로그의 필요성은 아는데 막상 작성하는 시간도 오래 걸리는 작업이라 시작하기가 힘들다.
그래서 우리 팀은 주 1회를 작성하지 않으면 작성을 완료할 때까지 개발에 참여하지 못하게 하여 무조건 작성할 수 밖에 없는 환경을 조성하였고 실제로 잘 지켜지고 있다.
또한 MM에 매주 작성된 기술 블로그를 올리고 있는데, 누군가 내 글을 볼 수 있다는 압박이 있으면 글의 논리나 맥락을 신경쓰게 되고 퀄리티를 신경쓸 수 밖에 없어진다.
이번 프로젝트가 만족스럽게 진행되고 있고, 진행 방식이 좋은 것 같아 공유하고자 글을 작성해봤다.