입사한 지 1년이 지났다.
힘든 점도 많았고, 좋은 추억 또한 많았다.
정말 다사다난했던 1년, 그동안의 회고를 작성해보려고 한다.
입사
‘우아한테크코스’에서 진행한 취업 박람회를 통해 지금의 회사, 마이페어를 만났다.
해외 박람회 참가 플랫폼이라는 신선한 도메인에 끌렸고, 코로나로 인한 해외 왕래에 대한 제약이 풀리면 성공할 비즈니스 같았다.
하지만 여러가지 조건 중, 한 가지 고민되는 포인트가 있었다.
사수가 없다는 것...! 그냥 백엔드 개발자가 없었다.(기존 백엔드 개발자가 한 명 있었지만, 개인 사정으로 인해 내가 입사 후 퇴사할 예정이었다.)
솔직히 정말 크리티컬한 부분이었다. 이 문제 때문에 정말 많이 고민했던 것 같다.
나는 이제 신입 개발자인데 혼자 개발팀을 이끌어가는 것이 상상이 안됐다.
그래서 6개월안에 사수(미들급 개발자)를 뽑아줄 것을 요구했다.
이에 회사 측에서는 사람일은 어떻게 될지 모르는 것이기 때문에 6개월이라는 시간은 약속하지 못하지만 전적으로 노력하겠다고 했다.
그러나 개발자를 뽑는 일은 정말 쉽지 않았다.
경력직 개발자는 지원서 조차도 잘 안 들어왔다. 여러 방면으로 노력을 했지만 점점 희망을 끈을 놓게 되었다.
그러면서 호기로운 생각을 해보았다.
그냥 내가 성장해서 CTO가 되지 뭐😼🤷♂️
시스템 개선1. 배포 개선
이번에는 입사 후 시스템 개선을 했던 이야기를 해보려고 한다.먼저 배포 시스템 개선에 관한 이야기이다.
당시 배포 시스템에는 2가지 문제가 있었다.
문제1. 한번 배포하는데 많은 시간이 소요
당시, Lucene(이하 루씬)이라는 검색 라이브러리를 활용하여 박람회 검색 기능을 제공하고 있었다.
루씬에 대해 간단히 소개하면 다음과 같다.
간단한 루씬 동작 구조 설명
1. DB에 있는 데이터를 원하는 형태로 가공하여 index파일로 저장
2. 검색시 index 파일을 탐색하여 결과 출력에 사용서버를 띄울 때 index파일이 생성되도록 되어있는데, 문제는 이 작업이 평균 15분 정도 소요된다는 것이다.
때문에 한번 배포하는데 최소 20분 정도 소요되고 있었다.
문제2. 자동화되어 있지 않는 배포
배포가 자동화되어 있지 않았다.(더 무슨 말이 필요하랴)
당시 AWS의 codeDeploy를 사용하고 있었는데 jar파일을 직접 빌드해서 만들고 aws cli명령어를 하나씩 입력하면서 진행 상황을 관찰하고 혹시라도 오류가 난다면 처음부터 다시 해야 하는 방식이었다.
(입사 초반에는 오류도 많이 발생해서 배포하는데 40분을 사용했던 적도 많았다. 이때는 진짜 그만둘까 고민도 했다.)
해결 방안
문제를 정리해보면 다음과 같다.
1. 서버를 띄울 때마다 루씬의 index 파일을 만들기 때문에 시간이 오래 걸린다.
2. 배포를 수동으로 진행한다.
서버를 띄울때마다 index파일을 만들어주는 이유는 codeDeploy를 통한 배포 과정에서 ec2인스턴스를 새로 만들기 때문이다.
그럼 만약 codeDeploy를 사용하지 않는다면?
index파일을 다시 만들 필요가 없다!
1번과 2번 문제를 한 번에 해결하는 방법으로 젠킨스를 이용한 무중단 배포로 방식을 바꾸는 게 적절해 보여 그렇게 진행했다.
그 결과 길게는 40분까지 걸리던 배포가 4분으로 줄어들었다.
시스템 개선2. 마이그레이션
(우선 입사 당시 시스템은 아래와 같았다.)
기존 시스템
- 단일 모듈
- 레이어 우선 패키지 구조
- 프론트 프레임 워크 사용 x (html, css, javascrpt, jquery, thymeleaf 등 사용)
- 동작하지 않는 테스트 코드 (대부분 실패하는 테스트들)
입사한 지 4개월쯤 된 시점이었다.
당시 코드들은 전혀 관리되지 않았던 코드였고, 심지어 2년 전에 작성하고 사용되지 않았던 코드가 남아있는 경우도 있었다.
코드 히스토리를 알고 있는 개발자가 전무하던 상황이라 더 치명적이었다.
백엔드뿐만 아니라 프론트도 비슷한 상황이었고, 새로운 기능 개발과 유지보수가 점점 어려워졌다. (코드가 많아서 IDE가 버벅거릴 정도였다.)
그러던 중 마침 개발팀에 React개발자가 들어오게 되었고, 논의를 거친 결과 시스템 전반에 걸쳐 client(react)-api서버(spring) 형태로 마이그레이션을 진행하기로 했다.
아래는 마이그레이션을 진행하면서 중요하게 생각했던 부분이다.
1. 테스트 코드 작성
기존 시스템을 통해 테스트 코드의 부재를 경험하니 테스트 코드의 중요성을 더 실감했었다.그래서 이번에는 테스트 코드를 꼼꼼히 작성하면서 마이그레이션을 진행했다.
테스트 코드 작성 전략은 아래와 같이 가져갔다.
기본 - Controller부터 DB단까지 통합테스트 (이때는 @SpringBootTest을 활용)
+ Service단 테스트를 통해 예외상황 테스트 (이때는 Mockito를 활용)
+ 필요시 domain 및 util 클래스의 단위 테스트 작성2. 불필요한 코드 걷어내기
지금까지 방치되고 있었던 삭제해도 무방한 코드를 이참에 모두 걷어내고 싶었다.그 방법으로 기존 코드를 보고 마이그레이션을 하는 방식보다는 현재 서비스의 기능을 먼저 살펴보고 해당 기능을 처음부터 다시 만드는 방식으로 진행했다.
(물론 기존 코드를 통해 예외 상황에 대한 파악은 해두었다.)
3. 멀티 모듈로 구성
기존 시스템에는 여러 기능 및 시스템들이 함께 있었다.
'박람회 검색 기능'
'이메일 발송 기능'
'예약 메일 스케줄링 기능'
'웹 훅 기능'
'어드민'
'블로그'...
위 기능들은 패키지 구분이 모호하게 섞여 있거나 메서드 재활용이 잘 이루어지지 않은 부분(비슷한 코드가 군데군데...)도 있어 유지보수 및 코드 파악에 애를 먹었었다.
이를 해결하기 위해 각 기능들을 모듈화하여 멀티 모듈과 관리하는 것이 좋아 보였고 그렇게 진행하였다.
마이그레이션에는 3개월이 소요되었다.
나름 도전적인 업무 중에 하나였고, 마이그레이션 후에는 개발속도가 더 빨라졌다.(뿌듯🙃)
풀스택 개발자
3개월간의 메인 서비스단 마이그레이션이 끝나고 잠시 텀을 둔 후에 순차적으로 어드민, 블로그 서비스 또한 마이그레이션을 진행하였다.
그 과정에서 리엑트 공부를 틈틈이 하였고, 어드민 마이그레이션부터는 프론트 개발자에게 질문해가며 프론트 작업에도 기여하기 시작했다.이후 블로그 마이그레이션을 하는 시점에는 다른사람 도움 없이 프론트와 백엔드 개발이 가능한 상태가 되었다.
개발인듯 개발 아닌 개발 같은 너
입사를 하고 개발 관련 서적보다 OKR, SEO, 스타트업, 리더쉽 등에 관한 책을 더 많이 읽은 것 같다.
언뜻 보면 개발과 맞대어 있는 것 같기도하고, 어떤 것들은 개발과 전혀 관계가 없어보이기도 한다.
하지만 아이러니하게도 위 책들이 개발하는데 도움이 되었다.
1년 동안 일해보니 개발자의 본질은 개발만 잘하는 것은 아닌 것 같다.
개발자의 본질은 문제 해결 능력이라고 생각한다.
우리는 많은 문제에 직면하며 살아간다. 문제를 인지하는 사람이 있는가하면 인지하지 못하고 당연시 넘기는 사람이 있다.
또 문제를 인지한 사람 중에서도 소수만이 문제를 해결하려고 한다.
문제를 해결하기 위해 개발을 활용하여 혁신적인 무언가를 만들기도 한다. (이것이 바로 스타트업!)
즉 개발의 시작은 문제를 인지하고 이를 해결하려는 마음에 있다.
얼핏 보면 개발과 관련 없어 보이는 책들이었지만 덕분에 더 좋은 제품을 만들고 문제를 더 잘 해결하게 되었다는 점에서 개발에 많은 도움이 되었다.
인사는 어려워
서류 검토부터 기술면접, 핏면접까지. 개발자 채용에도 참여했다.
얼마 전까지만해도 면접 지원자 신분이었던 내가 면접관이 되는 상황이 신선하고 재미있기는 했지만, 사실 스트레스를 많이 받기도 했다.(개발자 채용이 어렵다는 것을 진짜 몸소 경험...)
위에서도 언급했듯이 처음엔 경력직을 뽑으려고 노력을 했지만... 결국 포기(우리가 만족하는 미들 or 시니어가 올 확률은 0인 것 같다ㅠㅠ)
그다음엔 '잘하는 신입을 뽑자' 했지만...! 그런 신입은 우리 회사에 관심이 없다.
인턴 제도를 활용해서 일단 3개월 함께 일해보고 괜찮은 사람이 있으면 정규직으로 전환하는 방법도 시도했지만...! 이마저도 결과물은 없었다.
그 외에도 많이 고민하고 시행착오를 거쳤다.
점점 지쳐갔다.
무엇이 문제일까 고민도 해보고 채용 관련 세미나도 많이 봤다.
그러다 한번은 우리가 뽑고 싶은 개발자는 어떤 개발자인가 정리를 해봤다.
개발을 즐기고 열정을 가진 사람
문제 해결 능력이 뛰어난 사람
여러 가지 요소 중 위 두 가지가 내가 생각하는 중요한 평가 요소이다.
현재 개발 지식과 경험을 많이 보유하고 있지 않아도 위 두 가지를 만족한다면 채용하여 키우는 것이 현실적으로 맞는 방향인 것 같았다.
물론 많은 노력이 들어가겠지만 어쩔수 없는 것 같다.
그래서 최근 개발 공고의 컨셉을 전면 수정했다.
풀스택 개발자, 혹은 풀스택에 관심이 있는 개발자
(갑자기 왠 풀스택?)
풀스택 개발자를 뽑자는 생각은 '호갱 노노'라는 스타트업의 대표님이셨던 심상민 대표님과의 개발 문화 관련 세미나에서 얻은 통찰이었다.
기본적으로 풀스택에 관심이 있는 개발자는 기획이나 비즈니스 측면에도 관심이 있는 경우가 많다.
그리고 그런 개발자들이 주도적이고, 문제 해결 능력 또한 뛰어날 거라는 생각이다.
그래서 공고를 전면 수정했다.
현재 개발 능력이 뛰어나지 않아도
함께 성장할 개발에 열정이 있는, 풀스택에 관심이 있는 개발자
확실히 공고에 우리가 뽑고 싶은 개발자에 대해 명확히 적어 놓으니 지원서도 전보다 많이 들어오고 채용할때의 기준도 명확해졌다.
마치며...
지난 1년은 정말 보람찬 1년이었다.(쓸거리는 많았는데 필력이 부족한 탓에 다 적지 못했다.)
개인적인 측면에서는 혼자서 개발팀 이끌고 이렇게 저렇게 해본게 값진 경험이었다.
그 동안 머릿속으로는 알고 있었지만 내것이 아니었던 개발 지식들을 내것으로 만드는 시간도 되었다.
회사적 측면에서는 비즈니스 측면에서 더 디벨롭되었고 지금도 하루하루 더 좋은 서비스가 되어가고 있다.
동시에 앞으로 1년은 어떻게 보낼지 고민도 든다.
그런데 얼마전에 이동욱님이 블로그에 CTO 회고를 올리셨는데 거기에 기술 부채를 극복한 경험을 공유해주셨다.
그 내용들이 너무 좋았고 우리 회사에도 적용되는 것 같아 적용해볼까 생각중이다.
운좋게 앞으로 계획에 대해 좋은 조언을 받은 것 같아 기분이 좋다.
1년후 보람찬 회고록을 쓸 수 있는 올 한해가 되길 바라본다.
'생각' 카테고리의 다른 글
| 회고 / 2023 상반기 (0) | 2023.06.18 |
|---|---|
| 회고 / 2022년 (2) | 2023.01.08 |
