[회고] 2022년 개발자 회고

 

 

 

2022년은 개발자로서 생각도 많았고 고민도 많았던 한 해였다. 작년에 자만했던 내 모습을 반성했다.

# 기부금영수증

상반기에는 기부영수증 개선 작업을 진행했다. 입사한 이후 기부금 영수증 업무를 계속 맡았다. 그래서 정말 기부영수증 담당자가 되었다.

• 기부금 영수증 DB 구조 변경으로 마이그레이션
•  PDF로 기부금 영수증 다운 받을 수 있도록 만들기
• HTML로 기부금 영수증 메일 보내기
• 사업자 등록 가능
• 운영할 수 있는 어드민 화면
• 기부 여러 건 통합하여 기부금 영수증 받기
• 기부 여러 건 한꺼번에 기부금 영수증 정보 수정하기
• 주민등록번호 유효성 검사 라이브러리 만들기

초창기에는 주민등록번호 유효성 검사 기능이 없었다. 그래서 월초에는 주민등록번호 오류 건을 찾았다. 그리고 국세청에 갈 데이터 추출과 실제 데이터 비교 작업도 했다. SQL 문을 통하여 데이터를 찾고 찾았다. 그러다가 안 되면 엑셀도 이용할 수밖에 없었다. 월초가 지나고 5월이 오기 전에 사업자들을 위한 시스템을 만들어야 했다.
나는 사용자 화면보다는 다른 부서에서 응대할 수 있는 어드민 작업을 주로 했다. 사업자들에게 응대를 할 수 있도록 이메일 보내는 기능, PDF 다운 받는 기능을 넣었다. 점점 기부금 영수증 시스템이 진화하고 있었다.
5월이 지난 후에는 다른 팀에 피드백을 받아서 기획자분과 추가 개선 작업을 했다. 기부 1건씩 수정하는 것과 1건씩 메일 보내는 것이 불편하다고 했다. 그래서 통합 수정 및 발급을 받을 수 있도록 개선했다. 연말이 되기 전에 공제자 정보를 저장해서 일일이 입력하지 않아도 빠르게 등록할 수 있는 기능도 만들었다.

 

기능을 만들면서 힘들었던 점은 HTML을 해서 기부금 영수증을 만드는 것이었다. 프론트 개발자분이 전체적으로 만들어 줬지만, 추가적인 개선작업들은 내가 해야 했다. HTML과 CSS 개념이 없어서 어려움이 있었다.
또 다른 어려움은 메일 보내는 것이었다. 두레이 SMTP를 이용했는데 유료 버전에 따라 정책이 변경되면서 문제가 발생했다. 구글로 변경하는 과정에 회사 메일론 되지 않았다. 그래서 여러 방법을 찾다가 이메일 하나를 새로 만들어서 했다.

 

2022년 한 해 동안에 기획자님과 손발 맞춰 기부금 영수증 서비스를 진화시켰다. 내가 생각하지 못한 부분은 기획자님이 집어 내줬고 기획자님이 미처 생각하지 못한 부분은 내가 집어 냈다. 서로에 단점을 보완해주는 파트너였다. 기획자님 덕분에 기부금 영수증 무사히 맞출 수 있었다.
하지만 기부금 영수증을 PDF로 내려받기 전에 미리 볼 수 있는 서비스가 있다. 현재는 프론트에서 JSON 값을 받아서 만들어 주고 있다. 그런데 보안을 위해 백엔드에서 만드는 것이 좋다는 조언을 받았다. 하지만 이 작업은 아직 완수하지 못했다. 정말 느리게 진화하고 있다. 2023년에는 꼭 완성하고 싶다. 살짝 핑계를 대면 우선순위가 낮아서…. 천천히 하게 되었다.

 

 

# 기관플랫폼

기부금 영수증 작업과 함께 기관 플랫폼을 진행했다. 회사에서 하는 사업 중에 내가 제일 마음에 드는 사업이다. 이 사업이 진화하는 모습을 보니까 뿌듯했다. 나는 물건을 등록, 수정, 조회하는 부분을 맡았다.
텍스트에디터도 숙명인가? 캠페인에 이어 물품 등록에서도 하게 되었다. 원래 이미지 정보를 인코딩에서 string을 저장했는데 이 방식을 AWS에 저장하여 주소를 가져와서 저장하는 방식으로 변경했다. 그리고 파일을 저장해서 불러오는 건 쉬웠지만 이걸 수정하는 과정에서 어려웠다. 파일을 단순히 바꾸는 건 쉽지만 이 과정에서 유효성 검사를 하는 게 까다로웠다.
나는 개발을 할 때마다 느끼지만 등록보다 수정이 코드 짜기 어려웠다. 컴포넌트 만들어진 것에 값을 가져오고 바꾸는 게 생각처럼 잘되지 않았다. 특히 날짜!!! Datepicker!!!
수많은 내용을 일일이 채웠는지 맞는 정보인지 유효성 검사를 하는 건 힘들었다. 일차적으로 코드가 너무 길어진다 ㅠㅠ

그리고 시니어 개발자 2달 동안 자리를 비우면서 기관 플랫폼에서 에러가 나면 전반적으로 처리했다.
처음에는 나눔 지역도 하나만 선택할 수 있었다. 그리고 타입도 중간에 추가했다. 다른 팀에서 사용할 수 있도록 계속 개선해 나갔다.
물품을 등록하고 시작 날짜 10시에 지역이나 분야에 맞는 기관에 알람톡을 보내줘야 했다. 이때 람다를 사용했다. 처음 시니어 개발자분이 하는 법을 알려줬다. 그리고 코드를 수정해 가면서 했지만, 생각보다 알람톡이 안 가서 힘들었다. 그리고 시간이 UTC로 되어 있어서 처음에는 안 와서 당황했다.
현재는 새로운 개선 사항은 나에게 없다. 이 사업이 정말 잘되길 바랄 뿐이다.

 

# 배너&팝업

기관 플랫폼에서 맡은 일이 생각보다 일찍 끝나서 배너&팝업을 맡게 되었다. 이 부분은 우선순위가 낮아서 계속 밀렸던 일이었다.
서비스하게 된 이유
1) 사용자화 면에서 하드코딩을 계속 해야 한다.
2) 급한 공고를 해야 하는 경우에 Hotfix를 할 수밖에 없다.

 

나의 목표는 "나한테 온 이상 정해진 시간 안에 빠르게 끝낸다." 였다. 그리고 기획자분이 사용하다 보니 미처 생각하지 못했던 부분이 있었다. 그래서 연말까지 하나하나 개선해 나갔다.
기획자, 프론트 개발자, 나 셋이서 개발 관련 회의를 했다. 띠배너를 하자는 의견도 반영했다. 순조롭게 끝날 것이라고 생각했던 개발이었다. 하지만 당황스러운 일이 발생했다.

 

두 팀으로 나누어져 있었다. 프론트 개발자는 우리 팀 업무도 있지만 B팀 업무도 있었다. 나는 무슨 상황인지 모르지만 프론트 개발자가 B팀에 계신 외주개발자가 개발을 멈췄으면 좋겠다는 말을 전했다. 나와 기획자는 너무 당황스러웠다. 배너&팝업 작업을 공유하지 않아서 이런 문제가 생긴 것 같다. 하지만 내 입장에서는 너무 당황스러웠다. 하지만 서로 대화를 통하여 합의점을 찾았고 B팀 업무를 우선순위하고 개발 시간이 될 때 배너&팝업 작업을 하겠다고 했다. 그리고 프론트 개발자도 계속하고 싶다는 의사를 밝혔다.

지금 생각해보면 합의점을 풀어가는 과정에서 나는 감정적이었다. 나는 화가 났고 화를 표출했다. 사람보다 그 상황에 화가 났다. 그래서 현재는 두 분과 잘 지내는 중이다. 하지만 다음에도 이런 상황이 생긴다면 지혜롭게 대처하고 싶다.

사용하다 보니까 우리가 미처 고려하지 못한 점을 발견했다. 택배사 관련 팝업을 등록할 때 캠페인마다 등록을 해야 한다는 점이다. 예를 들어서 A 택배사와 관련된 캠페인 100개이면 100개의 팝업을 등록해야 한다는 점이다. 기획자와 나는 이걸 생각하지 못했다는 것에 반성했다. 그리고 개선 작업을 시작했다. 우선순위가 낮아서 점점 미루어지다가 명절이 되기 전에 개선 작업을 마무리했다. 왜냐하면 주로 명절에 택배사 팝업을 사용하기 때문이다.

배너 작업을 하면서 나는 문득 그런 생각이 들었다. 우선순위가 낮은 건 언제까지 미뤄져야 하는 걸까? 아직 이 질문에 답은 알지 못한다.

 

# 태그

나에게 좌절을 주었고 부족함을 한없이 느꼈다.

시니어 개발자가 2달 동안 자리를 비우면서 나에게 주어진 미션이었다. 캠페인과 스토리에 태그를 넣는 작업이었다.
새로운 서비스를 만들어야 했다. 이때 개발자로서 나의 능력을 알 수 있었다. 나는 이미 만들어진 서비스에서 API 만드는 것에는 능숙했다. 하지만 API를 타기 전까지의 과정은 너무 몰랐다.

A 서비스는 controller - service - repository 구조
B 서비스는 handler - service - internal 구조
나는 구조를 짤 때 어떻게 짜야 할 지 가장 많이 고민했다. 각 구조의 장, 단점도 잘 몰랐다. 그래서 두 서비스를 조합해서 만들었다. 하지만 왜 이렇게 했냐고 물어보면 나는 당당하게 사용한 이유를 말할 능력이 없다. 나는 한없이 부족함을 느꼈다.

 

태그는 생각보다 복잡했다. DB에는 있지만 화면상에는 삭제된 데이터가 존재한다. 그래서 등록, 수정할 때 데이터가 존재하는지 체크 해야 했다. SQL 문을 이용해서 쉽게 해야 하는 건지…. 속도를 위해서 한번 데이터를 가져와서 체크 해야 하는지…. 뭐가 좋은 방법인지 몰라서 고민을 많이 했다. 요즘은 API 속도도 생각하게 된다.

서로 다른 두 서비스를 마이크로서비스하는 과정에서 에러가 발생했다. 서비스마다 코드가 달라서 요청 값과 응답 값 규칙이 달랐다. 하지만 나는 마이크로서비스를 하는 데 큰 문제가 될 것이라고 예상하지 못했다. A 서비스는 주고받기가 잘되는데 B 서비스는 계속 에러가 났다. A 서비스에서는 토큰값을 그냥 주고받으면 됐고 B 서비스에는 Bearer를 적어서 보내야 했다. 하지만 이 과정에서 제대로 된 에러 코드가 없었다. 그래서 B 서비스를 연결하는 데 오랜 시간이 걸렸다.

이때 제일 답답했던 건 도움을 받을 사람이 없었다. 그래서 이 시기에 수많은 고민을 했던 것 같다.

태그를 검색할 수 있는 검색창을 하나 만들어 놨다. 사용자들이 무엇을 검색하는지 조사할 수 있는 서비스였다. 정말 예상 못했던 단어들이 많았다. 자신들이 궁금한 점을 검색하는 사람도 있었고 자신의 이름을 검색하는 사람, 기부가 가능한 물건인지 확인하는 사람 등등이 있었다. 이 데이터를 보면서 우리 홈페이지가 참 불친절하다는 것을 알 수 있었다. 내년에 이러한 점을 개선할 수 있었으면 좋겠다.

현재는 캠페인과 스토리에 태그를 등록할 수 있다. 하지만 다음에 리스트에서 보여지는 태그를 구별하는 서비스를 만들어야 한다. 사실 기획은 나와 있지만…. 같이 했던 기획자분과 프론트 개발자분이 퇴사해서 현재는 나 혼자 담당자가 되었다. 그리고 우선순위에서 밀리고 있다. 나에게 아픈 손가락이지만 2023년에는 꼭 완성하고 싶다.

 

#  비동기 프로그래밍 (AWS SQS)

나의 성장이 멈췄다고 느꼈다. 비동기 프로그래밍 이야기가 나왔을 때 자발적으로 하겠다고 했다.

갑자기 알람톡이 안되는 이슈가 생겼다. 큐를 통해서 보내는 것이 좋다고 외주 개발자분이 말했다. 새로운 것을 배울 수 있었던 기회였다. 알람톡을 AWS SNS로 해보자고 제안하셨다. 가이드를 해주셨다. 나는 힌트를 얻어가면서 단계적으로 만들어 나갔다. 그 과정에서 AWS SNS보다는 AWS SQS가 적합하다는 것을 깨달았다. 만드는 과정에서 궁금한 점은 매주 하는 회의 때 질문을 했다.

비동기 프로그래밍이 돌아가는 기본적인 구조를 알게 되었다. 그리고 서비스를 만드는 과정에서 TDD를 직접 할 수 있었다. 이론으로 들을 때보다 실제 해보니까 중요하다는 것이 더 와닿았다.

나는 "함수끼리는 의존하면 안 돼! "와 "코드는 중복으로 쓰면 안 돼" 이 두 가지 생각에 갇혀 있었다. 이 갇힌 생각에서 우선 빠져나오는 게 중요했다. 나는 의존하지 말라고 하는데 이렇게 코드를 짜도 되냐고 물으면 시니어 개발자는 의존성을 느슨하게 만드는 거지 아예 의존성을 없앨 수 없다고 말했다. 이렇게 코드를 짜면 중복코드가 생기는데 이렇게 해도 되냐고 물으면 필요할 때는 중복코드를 사용해도 된다고 말했다. 이 과정에서는 내가 정해 놓은 틀 안에서 나오는 게 중요했다. 하지만 이럴 때 이렇게 코드를 짜고 저럴 때 저렇게 코드를 짜고 이런 걸 잘 구별하기에는 나는 아직 어린이였다.

2021년 유닛테스트를 짝 프로그래밍으로 한 적이 있는데 실무에 적용을 시키지 못했고 바쁘다는 핑계로 잊고 있었다. 사람은 역시 안 하면 까먹는다. 이번에는 유닛테스트를 배울 수 있는 시간이었다. 하지만 하다 보니까 계속 의존성이 생겼다. 유닛테스트는 의존성을 배제하고 테스트해야 한다고 생각하지만, 막상 코드를 짜는 건 쉽지 않았다. 시니어 개발자는 인터페이스와 mock을 이용하라고 조언 해주셨다.
이 프로젝트는 아직 끝나지 않았다. 현재 에러 코드 관련해서 배우고 있다. 2023년에는 실무에 적용할 예정이다.

# GRPC 스터디

스터디의 목표 : 전체적으로 서비스를 구현해보자
나의 소감: 환경 설정을 하기 위해 설치하는 과정에서 좌절, 개념을 이해하느냐고 바쁨, GRPC와 친해지기 위한 노력

시니어 개발자와 함께 GRPC 스터디를 했다. 비동기 프로그래밍보다 더 낯설었다. 설치하는 과정에서 에러가 많이 났다. 1차적으로 path 문제가 많았다. 원도우와 맥은 달라서 한명 괜찮으면 한명이 안되는 경우도 많았다. 에러를 찾는 과정에서 시간을 많이 사용했다. A와 B 서비스가  GRPC를 통해서 통신할 수 있는 방법,  API 호출을 해서 API 게이트 웨이를 통하여 GRPC 접근하여 통신하는 방법, 양방향 streaming 방법을 배웠다. 

개념적인 이해를 도와주셨고 코드를 설명해주셨다. 우리는 각자 개발해서 테스트했다. 정말 자세히 설명을 해주셨는데 내가 참 말귀를 못 알아들었다.
배우면서 기록은 했지만 바로 글로 남기지 않아서 2023년에는 복습하는 시간을 가져야겠다. 이번에는 전체적으로 서비스를 구현해봤다는 것에 의의를 갖자!!

 

 

 

# GitHub 잔디의 집착

나는 참 이상한 것에 집착한다. 이 잔디 심는 것에 집착했던 것 같다. 그래서 결과물은 딱히 없는 것 같다. 이걸 신경 쓰느냐고 블로그에 글도 잘 올리지 않았던 것 같다. 그래서 이 이상한 집착과 블로그의 글 올리는 것! 둘 다 충족시킬 수 있도록…. 깃 블로그를 시작했다. 깃 블로그 만드는데 CSS를 직접 해 볼 수 있었다.
내년에는 잔디에 그만 집착하자! 그리고 깃허브 내용도 정리를 잘해보자!

 

# 내 자신

2021년에 일을 정말 많이 했다고 생각했다. 근데 글을 쓰다 보니 2022년에도 나는 많은 일을 했다는 것을 깨달았다.
2021년 나는 내가 급성장했다고 생각한다. 같은 연차에 비해 일을 잘한다고 생각했다. 주변에서도 잘한다는 칭찬을 많이 해주셨다. 그래서 나도 모르는 사이 자만하고 있었다. 2022년 올해는 성장이 멈췄다는 생각을 많이 했다. 같은 연차에 비해 한없이 부족하다는 것을 깨달았다.

부족함을 느껴서 배움을 통해서 채워 넣으려고 했다. 그래서 뭔가 계속 배우려고 했다. 강의도 듣고 컨퍼런스도 듣고 PT 실무도 들었다. 그래도 뭔가 부족하다는 생각을 지울 수 없었다. 그런데 문득 생각이 들었다. 배우기만 했지 내 것으로 만들지 않았다는 생각이 들었다. 그래서 2023년에는 지금까지 배운 것들을 내 것으로 만드는 시간을 가지려고 한다.

올해는 "개발자로서"라는 생각을 많이 했다. 나를 성장시킬 수 있는 환경이 중요하다. 기술적인 성장도 중요하지만 다양한 상황을 경험하는 것도 중요하다. 많은 상황을 경험하고 그걸 헤쳐 나가는 과정에서 내가 많이 깨닫는다. 이때 개발자로서 성장하는 느낌이다.

이렇게 글을 쓰니까 새로운 것을 많이 배웠네…. 2023년에는 배운 것들을 내 것으로 만드는 시간을 가져야겠다. 남들처럼 부지런하지 않지만 그래도 포기하지 말고 해보자!! 파이팅!

 

 

끝!

(길다 길어)