회고록을 쓰기에 앞서
우선 나 자신에게 미안한다는 말부터 하고 싶다. 지금까지 블로그에 글을 쓰는 것이 매우 뜸했다. 내가 개인적으로 공부하는 것은 노션에 정리하고, 바쁘다는 핑계로 글을 쓰는 것을 미뤄왔으니깐...
그럼에도 불구하고 블로그를 다시 쓰게 된 큰 계기는 내가 가진 경험 혹은 지식을 글로 표현하는 것이 매우 중요하게 느껴졌기 때문이다. 특히 처음으로 이력서를 쓸 때, 나의 경험을 타인이 보기 쉽게 글로 적는다는 것이 생각보다 어려웠다.
그리고 블로그는 보여 주기를 위한 최고의 활동이란 것도 깨닫게 되었다. 내가 개인적으로 공부하기 위해서 사용한 노션은 나만 본다는 의식이 있어서 남들에게 지식 공유가 될 수 없는 글들이 태반이었다.
1. 현장실습 (2022-12 ~ 2023-2)
처음으로 기업에서 프로그래밍을 하게 되었다. 나는 회사 내에서 연구소라는 곳에서 웹 EDI를 개발하게 되었다. 우선 EDI란 비즈니스에서 거래에 사용되는 일종의 표준 포맷이다. 웹 EDI는 EDI를 웹상에서 사용할 수 있는 서비스이다.
문제는 EDI를 실제로 까보게 되면 되게 복잡하다. 수백개(혹은 그 이상)의 세그먼트를 조합해서 문서 타입에 따라 다르게 해석할 수 있어야 한다. 도메인 자체를 이해하기 매우 어려웠다. 사실 아직까지도 완전히 이해하지 못했을 수도 있다. 아직도 보기만 해도 울렁거리는 것 같다.
나는 웹 EDI 프로젝트에서 사용자가 엑셀 문서를 업로드 -> EDI로 변환 -> 검증 -> 전송하는 프론트&백엔드를 담당하게 되었다.
해당 회사가 좋은 회사라고 말할 수는 없지만 배울 수 있는 것들이 많았던 경험이었다.
1.1 Tool에 집착하지 말자
해당 회사를 지원한 이유는 여러 회사 중에서 스프링을 쓴다고 하였기에 지원하게 되었다. 하지만 막상 들어가보니 우리가 잘 알고 있는 스프링을 쓰지 않고 jax-rs, Karaf, OSGI, jooq 등 나에게 생소한 기술들을 쓰게 되었다.
모든 회사가 다 그렇다고 할 수는 없겠지만 우리 회사는 프로젝트의 요구사항을 도출하고 요구사항을 달성하기 위한 최적의 프레임워크를 찾는다. 그 다음 Feasibility study를 한다고 하셨다.
어떤 프레임워크를 잘 쓰는 것도 필요하지만 궁극적으로 최고의 산출물을 위해서 도구를 잘 선택하고 사용하는 능력이 더 중요하다는 것을 깨달았다. 특히 상황이 계속 변화하는 IT업계에서 살아남기 위해서는 필수적이라고 생각한다.
1.2 중요한 것 먼저
우선순위가 제일 높은 것을 먼저 개발해야한다
개발 기간 동안 한 번 불려간 적이 있었다. 가장 중요한 부분인 엑셀문서에서 EDI 포맷을 변환하는 과정을 먼저 개발하지 않아서였다. 내가 변환 과정을 먼저 프로그래밍 하지 않은 이유는 맡은 업무가 업로드 -> 변환 -> 검증 -> 전송이기 때문에 순차적으로 처리하는 것이 좋다고 생각했다.
실제로 개발하면서 중요한 부분의 진행사항에 따라서 프로젝트의 요구사항, 일정 등이 변경될 수 있음을 느꼈다. 예를들어 내가 변환된 EDI를 다른 B 서버에 전송하는 작업이 마지막에 있었는데, 만약에 EDI 변환 과정을 추후에 개발하게 되면 전송받는 B서버 개발 TASK와 일정 마찰이 있었을 것이다.
1.3 Test
소장님께서는 테스트의 중요성을 누차 말씀하셨다. 나는 이후 캡스톤(졸작)에서 그 의미를 알게 되었다.
1.4 충분한 WHY 던지기
워낙 어려웠던 도메인이었기에 프로젝트 초반에 잘못 이해한 것들이 많았다. 내가 완전히 알았다는 착각을 하게 되며 내가 만든 것들이 요구사항과는 다른 방향으로 가게 되었다. 질문하는 것을 두려워하지 말고 충분히 질문을 던지는 것이 오히려 프로젝트 성과에 도움이 될 수 있다는 것을 배웠다.
2. 미국 여행 (2023-02)
처음에 미국 여행에 뜻이 있어서 간 것은 아니였다. 단지 LA행 비행기표가 매우 싸게 나왔기에 여행 계획을 짜게 되었다. 그리하여 3주 약간 안되는 시간안에 부랴부랴 계획부터 여권 발급, 예약까지 다 하게 되었다. 그래서 그런지 설렘보다는 걱정이 앞섰던 여행이었다.
하지만 결과적으로는 매우 만족한 여행이 되었다. 나는 여행을 가면서 해당 나라의 문화를 느끼는 것을 매우 좋아하는데 미국, 특히 LA는 최적의 장소였다. 많은 사람들과 나눈 여러 대화와 일화들(미국 갱 Crips OG를 만난 썰 등등..)이 아직도 기억에 남는다. 하지만 영어가 짧아서 원할하게 소통한 것은 아니였다...
대표적으로 느낀 것은 일반적으로 자신감이 있어 보인다는 것이었다. 긍정적이라고 해야하나. 물론 LA라서 혹은 내가 만난 사람들만 그런 것일 수도 있는데, 자신감이 부족한 나는 깊은 감명을 받았다.
나를 과대평가하지 않고 겸손하려고 하는 행동들이 돌이켜보니 자신감을 깎아내리는 행동들이 아닌었던가 싶다. 앞으로는 조금 더 나에 대한 확신을 가지고 살아야겠다는 생각이 들었다. (물론 오만은 금물이다)
물론 일주일 약간 넘는 여행 경험은 성급한 일반화일 수도 있다. 하지만 한국과는 다른 문화적 차이가 일반 여행자의 눈인 나에게도 느껴졌다.
3. GDSC Solution Challenage(2023-02 ~ 2023-05)
Solution Challenage는 구글에서 GDSC 대상으로 주최하는 글로벌 콘테스트이다. 실질적인 스프링 프로젝트를 처음하게 된 경험이었다. 나를 포함해서 4명이 감정 분석 일기 앱을 만들게 되었다. 그리고 Solution Challenage를 통해 아래와 같은 것들을 경험할 수 있었다.
3.1 API 명세서 도출의 중요성
내가 전반적인 백엔드를 구성했기 때문에 API 명세서를 빠르게 도출했어야 했다. 하지만 그렇지 못하면서 전반적인 개발에 차질이 생겼다. 빠르게 개발 해야한다는 생각 때문에 API 개발 후, API 명세서를 프론트 파트에게 전달했다.
오히려 이 방식보다는 백엔드에서 우선 API 명세서를 전달하고 프론트에서 API 명세서 기반으로 Mocking하는 것이 더욱 빠르고 효율적이라는 것을 늦게 깨달았다.
3.2 AI 파트와 협업
일기 내용을 감정 분석하기 위해서 AI 파트와 협업하였다. 나는 AI에 대해, AI 파트는 백엔드 부분에 대해 전혀 모르는 상황에서 프로젝트를 시작하였다. 그런 상태에서 우리는 감정 분석 프로세스를 다음과 같이 짰다.
- 유저가 일기 작성(업로드)
- 자바의 ProcessBuilder를 통해 파이썬 프로세스(감정분석 AI) 실행
- 파이썬 프로세스는 감정분석 완료 후 결과 json 파일 생성
- 유저가 메인 화면 조회할 때 마다 -> 감정 분석 결과 json조회
하지만 다음과 같은 문제점이 발생하였다.
- 감정분석 성능: GCP의 기본 컴퓨팅 파워로 AI 감정분석 시간이 많이 소요
- 감정분석 시간이 많이 소요되기 때문에 배포 환경에서 검증하기 힘듦
나중에는 기본적인 서버와 AI 서버를 분리하고 AI 서버는 Django, Fast API와 같은 프레임워크로 서버를 구축하는 것이 어땠을까 생각이 들었다. 그리고 확실히 Feasibility Study를 선행적으로 하고 메인 기능의 프로토타입을 먼저 만들어야겠다는 생각도 같이 들었다.
3.3 마지막으로
이번 프로젝트를 통해 GCP를 사용해 서버를 처음 배포해본 것이 가장 큰 경험이었다. http를 통해서 실제로 동작되어 매우 기뻤다. 동시에 코드가 업데이트 될 때마다 수동으로 배포하는 상황이 매우 번거롭게 느껴졌다. 이는 추후 캡스톤(졸작)에서 배포 자동화를 적용하는 계기가 되었다.
원래는 이번 회고록에서 졸작을 포함해서 쓰려고 했는데 길어져서 졸작 회고는 따로 분리하게 되었다.
