[회고] 나혼자 개발자 스타트업의 한달간의 작업 기록과 체감

우연히도 2월부터 입사를 해서 백엔드 개발자로서 근무를 하면서 면접과 입사를 할 떄부터 2월까지 있던 일에 대해서 기록을 해보고자 한다.

 

현재 다니는 회사는 차량유지관련으로 서비스를 준비하고 있는 스타트업이다.

---

현재 다니고 있는 이 회사가 면접 당시부터 많은 임팩트가 있었는데 다음과 같은 상황에 놓여있었다.

• 회사는 역삼에 있는 스타트업(??) 인데, 이미 면접볼 당시에는 많은 회사를 붙었던 상황이어서 "굳이 이 회사를 올 필요가 있을까?" 라는 생각이 많았던 상황이었다.
• 면접날인 경우에도 "면접조차도 아 귀찮은데 굳이 면접을 보러 가야하나?" 라는 생각이 많았었다.
• 면접이후 2시간만에 같이 일하자는 연락을 받았다. 이 연락을 받았을 떄는 말했던 처우를 낮추면서 제안을 했었고, 굳이 메리트가 있을까 깊게 생각을 했었다. 해당 문제들은 아래서 다뤄보고자 한다.

---

고민을 깊게 해볼 수 밖에 없었던 이유들...

장점으로만 되었던 문제들은 파란색, 단점으로만 되었던 문제는 빨간색, 두개다인 경우는 초록색이다.

 

해당 문제들은 면접을 보면서 들었던 문제들로... 입사한 이후에는 더 심각하다...ㅋㅋㅋㅋ;;;

• 개발자는 나 혼자다
  • 외부에 조언을 받을 수 있는 기술이사들이 많다고 하지만, 코드적으로 리뷰를 받을 수 있는 개발자가 없었다.
• 해보고자 하는 사항은 마음대로 해볼 수 있다.
  • 정말 좋은 말이지만 돌려 말하면 위의 '개발자는 나 혼자다'에서 연관이 충분히 되는 문제였다.
• 처우에 대한 조율
  • 이미 붙은 곳들의 경우 개발팀이 존재하며 더 좋은 대우와 복지가 있는 회사들에서 합격후 제안에 대해 응할지 말지 기다려달라 부탁을 했었던 상황이었다.
  • 복지가 채용 글도 그렇고 면접을 보러와서도 설명을 해준 부분이 전혀 없었다.
• 대표의 성격
  • 정말 재밌게 봤었던 부분이었다. 어느 회사를 면접보러 가더라도 이렇게 적극적이었던 대표가 없었다 보니까 너무 재밌어보여서 한번 같이 일해보고 싶은 생각을 들게 한건 처음이었다.

---

회사를 선택하게 된 이유

입사에 대한 제의를 받고 위의 조건들로 인하여 깊게 고민을 하면서 지인과 밥을 먹고 있는 와중에 연락을 다시 받았었다.

처우에 대해서 이전에 조율한 처우로 계약을 하자 했던걸 전부 취소하고 내가 생각중이던 처우로 계약을 하자는 말을 듣게 되었다.

 

이말을 듣게된것 자체가 한시간이 채 안걸렸던것같다. 이 말과 함께 했던 말이 기억에 남는데  "개발자님이 원하시는 처우를 낮추는건 개발자님의 퍼포먼스를 낮추는게 아닌가 다시생각해봤다 죄송하다."라는 말을 들었다.

 

이말을 듣고 대표의 성격을 같이 생각을 했을때 마음을 많이 정하게 되었었지만 나머지 부분들에 대한 걱정을 하면서도 선택을 하게 되었다.

 

 

 

일단 나의 기준에서 단점이라 생각했던 부분이 없어졌었기 때문이다.

---

입사 후 발견하게된 문제들...

 

해당 문제들을 꼬리물기하면서 들어가보면 다음과 같은 큰 문제들을 발견할 수 있었다.

문제 하나하나가 너무 크리티컬하다 생각하며, 모든 문제를 맞딱뜨린건 SM 1년차 주니어 개발자가 맞딱뜨린 문제들이었다.

 

누군가에게 조언마저도 받을 수 없는 환경이다..

 

해당 문제들은 상황에 대한 문제지 코드, 프로젝트의 구조적인 심각한 문제들은 모두 배제하였다.

 

1. 나한테는 현재 서비스 준비중이라는 말을 했었으나, 실제 서비스를 AWS 인스턴스로 운영중이었다.
   1. SI업체에 개발을 맡긴 이후 프로젝트가 모두 끝나있던 상황이었다.
   2. 프로젝트를 받은 이후 실운영에 대한 모니터링이 이뤄지지 않았다.
   3. 빌드를 아무도 진행해보지 않았다.
      1. Spring프로젝트를 빌드한 이후 jar파일을 그대로 운영에 실행만 하고 있었다.
   4. Git을 통한 버전관리가 불가능했다.
      1. 소스자체에 API KEY를 하드코딩해서 사용하고있었다...
   5. 사무실에서 AWS접속을 할 수 있는 방법이 없었다.
2. 개발서버가 없었다.
3. FrontEnd 프로젝트에 대해서
   1. 빌드가 불가능했다 
      1. 환경변수를 써놓고 어떤 값을 활용한지를 기록하지 않았다.
   2. React로 모든게 만들어 졌음에도 테스트가 불가능한 영역이 너무 많다.
      1. 특정 메소드에 대해서 Flutter프로젝트에만 생성 및 실행하도록 작동을 해버렸다.

---

문제를 대처하면서 느낀 감정과 진행했던 과정들

위의 인프라적인 문제들에 대해서 부터 해결하고자 노력을 하게 되었다.

문제들에 보면서 느낀 감정은 흥분이었다. 너무 재밌을것같다는 생각과 흥분이었던 것 같다.

 

실제 작업도 스트레스를 많이 받았지만 재미도 많이 느꼈었다.

 

이런 감정을 느낄 수 있던 이유는 , 어느 회사를 가도 입사를 한지 2-3주도 되지 않은 신입 개발자가 개발서버를 구축하고, 운영서버를 마음대로 접속을 해보고, Git 조직을 만들고 관리해볼 경험을 가질 수 있겠는가?? 

 

심지어 해당 글을 작성하는 현재를 기준으로 다음주 중에는 신입 개발자를 추가로 뽑을 예정인데 면접관으로 들어가는 경험까지 가져볼 기회가 생겼다.

 

 

문제를 해결해 나갔던 과정은 다음과 같았다. 약 3주간 인프라 설정을 스스로 진행하였다.

1. AWS의 운영서버에 대해서 접속 불가의 이유를 먼저 파악했다.
   1. 보안그룹의 문제로 사내 사무실 IP만 추가가 되어있지 않았다. 
      1. 추후 개발자가 추가되는 경우를 대비해 사무실의 IP에 대해서는 모두 허용을 시켜놓았다.
   2. 업무용 Mac, 운영의 프록시 서버 모두 SSH를 쉽게 접근하기 위한 별칭설정 작업을 진행을 진행하였다
2. 프로젝트의 버전 관리
   
   1. 회사에서 대표적으로 활용할 Git계정 생성 및 Git Organization을 생성
   2. 나와 기술이사로 활동중인 개발자님의 Git Invite 및 현재 관리자로 Rule을 지정하였다.
   3. FrontEnd, APP프로젝트의 경우 모두 소스코드를 확인후 문제 여부가 없는것을 판단한 이후 Repository를 생성
      1. BackEnd 의 경우 문제의 소지가 되는 부분들에 대해서 yml파일로 분류를 한 이후 프로젝트 Repository를 생성할 수 있게 되었다.
      2. Repository마다 모든 행동에 대해서 event설정을 할 수 있는 점은 처음 알게 되었다..싱기방기..
3. 사내의 사양이 빵빵한 서버 PC가 렉장비에 꼽혀있는게 아닌가..? 이걸보고 어떻게 참는가. AWS의 인스턴스는 모두 돈인데 굳이 돈을 쓰면서 구축할 필요는 없잖는가? 해당 장비를 개발서버로 만들기 시작했다.
   1. 포멧을 했다.
   2. 운영체제를 설치하고자 서버의 레이드를 설정
      1. 물리서버를 다루는게 처음이다보니 가장힘들었다. RAID0, 1이게 뭔지 몰랐는데 물리서버에 HDD가 3개가있었다. RAID1로 설정을 하면서 HDD가 홀수개인 경우 설정이 안된다는걸 처음 알게 되었다.
   3. 운영서버와 동일한 버전의 Ubuntu를 설치 
      1. 개발자들에 대해서만 자유로운 접근을 가능하도록 룰을 지정하여 방화벽(ufw)설정을 진행하였다.
   4. Docker를 활용하여 MariaDB의 설치를 진행
      1. DB의 계정 설정에 대해서 들어오는 IP대역마다 권한분류를 다르게 진행하였다. 관리자의 입장으로는 많은 고려를 해야하는것을 깊게 체감할 수 있었던 듯 하다.
      2. 실제 운영에 제작된 schema를 따라 구현하였다.
      3. 운영의 Data가 많지 않고 민감한 정보가 없는 상황이었다. 모든 데이터를 부담없이 Dump를 뜨고 개발서버에 엎었다.
   5. JDK의 설치
      1. 추후 Jenkins, pinpoint, 부하테스트 툴을 사용하면서 문제가 발생하긴 싫었다. 또한 다양한 버전을 추후 골고루 사용을 한다는 가정을 하게 되었다.
      2. 8, 11, 17버전을 선택하고 alternatives를 활용해 자유롭게 변경하는 방식을 사용하도록 채택하였다.
   6. 운영과 개발서버의 실행을 어떻게 할지를 굉장히 고민했다. 배포의 간편화를 위해 Docker를 활용하고, Kubernates를 통해 간편하게 무중단 자동배포환경을 구축해보고자 하였다.
      1. 해당 부분은 당장 운영을 희망하는 대표의 뜻에 따라 추후 하고자 하여 딜레이를 하는 것으로 최종 선택하였다.
      2. 일단 Jar를 실행하는 방식으로 하되 추후 변경하고자 마음먹었다. 
   7. Jenkins의 설치
      1. Git을 만들었으니 개발서버에 대해서는 자동배포까지 진행하고자 하였다. 
         1. Jenkins계정이 root권한이 없으니 문제가 많이 발생했었다.
      2. FrontEnd의 프로젝트 자동배포
         1. 프로젝트가 3개나 되다보니 점심나가는줄 알았다..
         2. Git Flow방식에 맞춰서 develop브랜치에 PR을 Merge하는 경우 작동되도록 진행하였다.
      3. BackEnd의 자동 배포
         1. 해당 작업을 진행할 떄부터 받은 부탁은 빠르게 오픈부터 해보자였다. 그러다 보니 최대한 단순하게 잡기로 했으며, 개발서버는 한대뿐이기에 개발서버에서 yml을 지정해서 실행하는 방법으로 변경하였다.
   8. Nginx의 설치
   9. 개발서버의 DNS설정.
      1. 현재 회사에서 활용하는 도메인이 a.com인 경우 프로젝트에 따라 shop.a.com, order.a.com, admin.a.com와 같은 방식으로 활용을 하고 있었다.
      2. 난 여기서 shop.dev.a.com, order.dev.a.com, admin.dev.a.com와 같은 방식으로 활용하고자 하였다.
      3. 사내 모든 도메인은 AWS의 DNS에서 지정을 하고 있었고 dev인 경우 개발서버로 오도록 레코드를 다시 설정하게 되었다.
   10. 문서화
       1. 누구라도 아래의 문서를 읽고 다시 개발서버를 구축 할 수 있도록 많은 정보를 남겨보고자 하였다.

---

백엔드 개발자로서 처음 제대로 프로젝트를 보게 되면서..

인프라 문제까지는 정말 괜찮았다. 사실 백엔드를 제대로 까보기 시작하면서는 '도망갈까?'라는 생각을 정말 깊게 했다 ㅋㅋ;;;

 

나는 내가 작성하는 코드마저도 냄새가 나는 코드라는 생각을 많이 했다.

하지만 내가 직접적으로 프로젝트를 제대로 보면서 느낀건 냄새가 나는 코드들의 결집체 라고

 

하지만 문제는 코드만이 아니었다, 일단 설계부터가 문제였다.

현재 작성하는 기준으로 지금도 건드릴 수 없는 상황이라 작업을 진행을 못하지만 문제파악을 먼저 할 수 있었다.

 

설계적인 문제는 다음과 같았다.

1. 로그인 세션문제.
   1. 회사의 서버 구성은 AWS의 ELB로 로드밸런싱이 되고 있었다. 근데 사용하는게 Was레벨의 Session을 사용하고 있었다.
2. Spring-Cache의 선언
   1. 정작 사용을 하질 않았으나 객체들을 만들고 있는 상황이었다.
   2. 해당 문제에 대해서는 추적후 제거하는 방향으로 진행을 했었다..
3. Mail발송 문제
   1. 기능의 오류는 아니나 Mail의 HTML컨텐츠에 대해서 Method에서 모든 내용을 작성하고 있었다..
   2. 추후에 jsp로 별도 관리하면서 내용을 가져오는 방식으로 변경해야 할 듯 하다...
4. Log
   1. 로그레벨에 대해서 아무 설정을 하지 않는 상황이다.
   2. 운영역시 Debug와 info레벨의 로그들까지 그대로 출력을 하고 있었다.
   3. 파일로 분류하는게 아닌 nohup.out으로만 로그를 배출하고있었다.... 
5. 특정기능 Seq지정 문제
   1. 다음 Seq를 뽑는게 NextVal을 활용하고 있었다. 동시성문제에대한 고려는 하지 않은 듯 하다.
6. 실행 단계에 대해서 application.yml와 application-prod로만의 분리
   1. 개발을 진행하면서 설정파일에 대해서 application.yml에서 그대로 사용을 했던 것으로 보인다.. 근데 여기에 운영key를 넣고 테스트를 왜했는지 의문을 많이 가지고있다..

 

위의 내용만 보면서도 한숨을 많이 쉬었던 것 같다.

나는...테스트케이스 만들고...기능개발하면서 일하면 될줄알았는데... 정말 ....한숨밖에 안나왔던 상황같다.

---

작업을 진행한 과정은? 

• 일단 Intellij에서 Style Format부터 지정했다.
  • Google Style Guide를 따르기로 지정을 하고 열어본 파일들에 대해서 Format에 맞춰서 수정되도록 했었다.
• 문자열에 대해서는 Enum을 활용하였다.
  • Enum으로는 지정을 못하는 값에 대해서는 Value변수를 추가해서 읽어오는 방식을 활용하고자 하였다.
  • Rule에 대해서는 Enum안에 Method를 제작하고 활용해 검증하는 방식을 활용하는 쪽으로 방향을 변경하였다.
• Aligo라는 API를 활용하는 기술이 있었다.
  • 해당 기능을 활용 할 때 HashMap으로 Parameter를 제작하여 전달하는 기능이 있었는데 공통의 정보가 들어가고있었다.
    • static메소드로 제작한 이후 모두 해당 메소드를 호출하는 방식으로 변경하였다.
    • 변경하고 보니 해당 문제로만 코드가 120줄이나 감소하였다..정말 기겁하는줄 알았다.
• Import에 대해서 읽어보는 페이지들은 * 를 없앴다.
  • 최적화.
• 기존에 // 형식으로 간단한 기능정리만 한 기능들에 대해서 JavaDoc을 활용하여 메소드의 상세 기능을 기록하였다.
• 조건문이 3중 4중으로 되버리는 기능들이 존재했다.
  • 소스를 읽어보고 미리  Return이 가능한 조건들에 대해서 줄이면서 3중 4중으로 된 소스코드를 한단계 두단계 줄이면서 그나마 읽을 수 있었다.
  • 아마..추후 시간이 많이생기면 좀 더 작업을 해야하지 않을까 싶다

---

앞으로 진행할 과정은?

• 모든 파일에 대해서 작업의 진행을 하지는 못했다. 위의 작업에 대해서 조금더 보완하지 않을 듯 싶다.
• 기능 들에 대한 Unit TestCase를 작성하고자 한다.
  • 커버리지에 대해서 100%가 되지 않는 경우 Build가 불가하도록까지 작업할 예정이다.
• 조건문안에 조건문이 나오는케이스는 모두 삭제하는걸 목표하고자 한다.
• DB스키마 구조를 보기 쉽게 문서화 하고자 한다.
• 모든 요청을 Postman으로 정리하고자 한다.
• 개발서버를 기준으로 부하테스트 및 모니터링까지 목표하려 한다.

---

추가 개발에 대해서는?

많이 놀란건 해당 사항이다. 위의 내용만 봐도 사실 혼자할 분량이 아니다. 라고 말할 수 있다. 

Figma를 보니 수십페이지가 있는 걸 보고 울고싶었다. 

 

설계가 없는 상태로 UI / UX를 그리고 있었던 것이다. 현재 UI / UX를 보면서 급하다고 하는 기능들에 대해서 먼저 개발에 들어갔다.

 

앞으로의 기능들에 대해서는 프로젝트를 기존의 프로젝트에 붙이는게 아니라 분류를 하고자 한다.

 

Session이 문제가 되서 token의 유효성 검사를 먼저 하는 방향으로 진행을 하면 어떻게든 되겠지라 생각은 한다. 

 

위의 앞으로의 진행할 과정에 대한 목표들을 하고자 하기 때문에 분리하면서 개발해야 하지 않을 듯싶다...

---

혼자 일해보면서 느끼는 점들...

이게 맞나?를 매번 외치고있다. 하지만 정말 신입임에도 불구하고 많은 업무를 진행해 볼 수 있었 던 듯 하다.

 

시니어 개발자가 되지 못하면 못할 줄 알았던 부분들을 많이 겪어보고 있고, 진행을 하면서 어떻게든 버티면서 위의 목표를 성공적으로 이루면  어느 누구한테도 밀리지 않는 이력이 되겠다는 생각을 깊게 해볼 수 있다고 매일매일 느끼고 있는 것같다.

 

자신이 정말 버틸 수 있는 사람들한테는 이런 환경을 추천해주고싶다.

하지만 멘탈적으로 약한 사람들한테, 불안함을 이겨내기 힘든 사람들한테는 권장하고 싶은 상황은 아닌 듯 하다..