전체 글

문서로 시작해서 문서로 끝나는 직업 개발자가 갖춰야하는 하는 역량은 다양하다. 예를 들면 요구사항에 따라 정확하고 잘 구현해야되는 구현 능력, 비개발자와도 잘 소통할 수 있는 커뮤니케이션 능력, 제한된 일정에 스케줄링을 잘 해야하는 계획력 등이 있다. IT 인력 시장에서는 실제로 기술력이 엄청 뛰어난 슈퍼 개발자보다는 능력을 두루두룩 갖춘 개발자들을 더 많이 찾고 있으며 기획, UI/UX 설계 등 개발자들이 더 많은 부분에 관여하고 조율 함으로써 낮은 리소스로 높은 아웃풋을 내길 희망한다. 하지만 이런 모든 능력을 완벽하게 갖춘 사람이 되는 것은 매우 어려운 일은 물론이고 모든 과정의 일을 기억하고 조율하는 것은 더더욱 어려운 일이다.  그래서 개발자는 처음에는 요구사항을 만들기 위한 문서를 전달 받고 ..

글또 9기 프론트 반상회 시작 전 하나의 게시글 그리고 한명의 팔로워 어느 일상과 같이 무료한 출근하는 시간동안 나는 평소처럼 링크드인 게시물들을 눈팅하고 있었고 그러다 글또 주최자 성윤님이 장소를 대관한다는 글을 보게되었다. 처음에 게시글을 봤었을 때에는 달린 수많은 댓글들을 보고 나는 `역시 성윤님의 인적 네트워크라면 금방 장소를 구하셨겠지?`라는 생각을 하며 아무렇지 않게 다시 업무를 시작했었지만 한편으로는 우리 회사에서 열어봐도 괜찮지 않을까라는 작은 아쉬움을 가지고 있었다. 그렇게 업무를 마치고 퇴근하는 시간동안 계속 `우리 회사에서도 저런 행사 자리가 열리면 좋을 것 같은데?`, `이전에도 데이터 관련 세미나가 열었으니 허락해주지않을까?`, `프론트 반상회 자리는 아직 못구하셨겠지?`라는 생각..

시작하게 된 계기 이전에도 웹을 어느정도 개발 해왔기 때문에 jquery와 thymeleaf와 같은 도구를 활용하여 쉽게 개발을 해왔었지만 리액트나 vue와 같은 프론트 기술스택을 활용을 해야될 때에는 만들어진 프로젝트 위에 하드 코딩을 하거나 프론트 개발자를 구해 개발을 했어야 했다. 그래서 내 마음 한켠에서는 항상 불편함이 자리 잡고 있었고. 프론트 개발을 제대로 하지 못한다는 자책감을 가지게 되었다. 그리고 시시각각 변하는 프론트엔드의 시장에서의 나는 점점 프론트엔드 개발자들과의 소통이 더욱 어려워지기 시작했고 요구사항에 맞춰 소프트웨어를 함께 설계하고 개발해 나가는 과정 속에서 지속적인 커뮤니케이션의 어려움을 느끼며 큰 부담으로 다가오게 되었다. 그렇게 그런 생각이 희미해져 갈 때 쯤 회사에서 갑..

글쓰기 뉴비 시절의 나 초기에 글을 잘 쓰는 것에 대한 중요성을 잘 알지 못했던 나는 글쓰는 노하우들을 기르고 단련하기 보다는 그저 누군가 내 글을 더 많이 봐주기를 원했고 글을 통해 내가 열심히 학습하여 성장하는지 알아주기를 원했었다. 이러한 태도는 나에게는 글쓰기가 부담감으로 점점 다가왔고 더 높은 수준의 주제와 심도 있는 내용으로 글을 쓰는 것에 집착하다보니 높은 진입 장벽으로인해 한글자를 작성하는 것 조차 버거웠다. 이렇게 글을 쓰는 것을 미루다보니 글을 제출해야되는 매 순간순간이 촉박했고 그렇게 글의 완성도는 점점 떨어져 갔다. 그래도 다른 분들에게 이야기를 들으면서 좀 나아질 것 같다는 생각에 글또에서 다양한 개발자분과 분석가 분들을 만나기 시작했고 다양한 경험들과 좋은 조언들을 들을 수 있었..

마이크로 서비스 아키텍처(MSA)가 대체 뭐길래? "마이크로 서비스 아키텍처를 구축해야 되요", "서버를 분리해야한다", "프로젝트 크기가 방대하여 개발이 오래 걸려요" 등 다양한 말로 같은 뜻을 개발자들은 말한다. "마이크로 서비스 아키텍처를 구축해야되요!" 라고 하지만 PO나 기획자에게는 쌓여있는 기획들이 있을 것이고 CS를 담당하고 있는 직원들에게는 운영하는데 필요한 기능들을 기다리고 있을 것이고 데이터 분석가들에게는 분석하는데에 필요한 이벤트나 로그들이 기다리고 있을 것이다. 그래도 이유없는 주장은 없을 것이라는 생각에 일정을 물어보면 생각외로 긴 일정들을 요구하고 안정적으로 운영되고 있는 서비스의 버그나 장애가 발생할 수 있을 것이라고 이야기를 한다. 그런 이야기를 듣다보면 점점 마이크로 서비스..

백엔드 개발자가 가장 자주 하는 업무 중 하나를 꼽으라고 한다면 바로 "API 개발"이라고 이야기할 수 있을 것이다. 우리는 API들을 만들면서 API를 구현하는 비지니스 로직은 많이 공부하고 익혔었지만 API 자체에 대해서 잘 설계하는 것은 고려하지 못한 부분이 종종 있을 것이 있을 것이다. 아래와 같은 상황을 겪어 본적이 있는가? 일부 API는 단 하나의 용도로만 사용할 수 있는 방면, 어떤 API는 검색, 필터 등 유연하게 활용할 수 있다. 그리고 과거에 만들어진 어떤 API는 오랫동안 계속 사용하고 있지만 어떤 API는 최근에 만들었음에도 불구하고 약간의 변경이나 기능이 추가될 때 수정이 어려워 새로운 API를 만들거나 기존 API의 버전을 올려야 하는 상황이 발생한다. 서론이 길었지만 이글은 A..