마이그레이션 과정 회고
한달어스 프로덕트의 코드 마이그레이션 과정과 이를 통해 한달어스 팀이 느낀 점을 회고합니다.
Writer : 권민재(Developer of Handal.us | 010-9831-4034 | kkmj4034@handal.us)
기존 한달어스의 모든 코드를 내재화하는 미션이 주어지다.
6월 말 한달어스에 입사하고 약 1달 반 정도가 지난 무렵인 8월 초, 외부 개발자분에 의해 짜여진 한달어스 프로그램의 기존 소스코드를 내재화해야 하는 미션이 주어졌습니다.
여기서 내재화란 기존 코드의 유지보수 및 개선 작업을 자유롭게 할 수 있는 것, 즉 기존의 코드를 내가 짠 코드처럼 다룰 수 있게 되는 것을 의미합니다.
사실 처음엔 막막했습니다. 개발을 처음 시작한게 올해 2월 부터인데, 마이그레이션 시작 당시 개발 5개월차, 리액트를 조금 다뤄봤고 서버 개발에 대해서는 거의 모르는 수준이었습니다.
20년차 개발자 분이 (파트타임이었긴 하지만) 2년 여에 걸쳐 쌓아 두신 코드들을 이제 막 개발자로서 커리어를 시작한 제가 혼자서 그대로 옮겨 받아야 한다는 미션 자체가 결코 쉽게 느껴지진 않았습니다.
하지만 주어진 태스크가 내 능력에 비해 클수록 그 일을 해냈을때의 성장의 폭도 클 것임을 알기에, 어떻게든 일을 완수한다는 생각으로 처음부터 차근차근 시작했습니다.
사용할 기술 스택 선정
개발을 시작하기 전 크게 다음과 같은 두 가지 선택 사항이 있었습니다.
- php를 학습하여 php로 짜여진 기존 코드 그대로를 직접 옮겨받아 유지보수하는 방식
- 새로운 기술 스택을 적용하여 기존 코드는 참고만 하되 새로 코드를 짜는 방식
물론 php도 좋은 프로그래밍 언어이지만 최근엔 node.js나 java, python 등에 비해 비교적 주류 언어에서 멀어졌기 때문에,
- 구글링했을 때 다양한 참고자료를 찾을 수 있는가
- 학습했을때 미래 활용가치가 높은가
의 기준으로 따졌을때 학습 비용 대비 효율이 떨어진다고 생각했습니다.
따라서 결론적으로 두번째 방향을 선택했고, 웹 생태계에서 다양한 분야로 가장 대중적으로 쓰이고 있는 자바스크립트 기반의 기술 스택을 사용하기로 결정했습니다.
사용한 기술 스택은 다음과 같습니다.
Front-End : React.js (+ Recoil)
Back-End : Express.js (+ Sequelize)
DBMS : MySql
실제 개발에 돌입하다
기술 스택을 선택하고 막상 실제로 개발을 시작하려 하니, 어디서부터 어떻게 시작해야 할지 감이 잡히지 않았습니다.
우선 전달받은 데이터 베이스부터 테이블 하나씩 뜯어보며 구조를 파악했습니다.
DB구조가 그리 복잡하지 않아서, 상대적으로 구조를 파악하기 쉬웠습니다.
이후 기능별로 필요한 API를 개발하고(Express), 클라이언트 단을 개발하여(React) 이를 적용하는 식으로 개발을 쭉 진행했습니다.
말은 쉽게 적었지만, 개발 과정에서 기능별로 각각 수많은 마이크로한 문제들에 마주했고, 해결하는 과정에서 많은 것을 배우고 성장했습니다. 각각의 개발 과정과 에러 해결 과정에 대한 글은 차후 주제별로 따로 기술하고, 본 글에서는 코드 마이그레이션 과정에서 전반적으로 느낀 점들을 몇 가지 공유하고 글을 마무리하고자 합니다.
마이그레이션 과정에서 느낀 것들
‘구글링을 잘하는 것’도 능력이다
흔히들 농담 삼아, 개발자의 가장 중요한 덕목은 복붙, 구글링이라고 합니다.
물론 이는 구글링에만 의존하게 되는 개발자들을 꼬집는 자조적인 어조의 농담이지만, 방대한 구글의 아카이브를 잘 활용하는 것은 개발자에게 정말 중요하다고 생각합니다.
이번 마이그레이션 과정을 사수 없이 혼자서 진행하면서, 많은 의문점들을 구글링을 통해 해결했습니다.
혼자서 고민하고 서칭하는 과정에서 ‘웬만한건 내 머리와 구글과 함께 해결할 수 있구나’라는걸 깨닫고 에러에 비교적 침착하게 대응할 수 있게 되었고, 지금 발생하는 이 문제를 어떻게 ‘키워드화’해서 검색할 수 있을지에 대한 감을 키울 수 있었습니다.
또한 다음과 같은 방식으로 구글링하며 빠르게 성장할 수 있었습니다.
- 발생한 문제와 연관된 키워드들을 함께 검색하며 공부한다.
const [count, setCount] = useState(0);
const onClick = () => {
setCount(count+1);
setCount(count+1);
};
...
return (
<div>
<h3>{count}</h3>
<button onClick={onClick}>+</button>
</div>
)
...예컨대 위와 같은 상황에서 useState가 내 생각과 다르게 작동하여 이에 대해 검색하다가 useState의 비동기적 작동 방식에 대한 글을 보게 되었다고 합시다.
글을 읽으며 useState의 작동 방식을 이해하다 보니, useState(정확히는 setState)가 모든 명령 코드들을 받은 후에 가장 최신의 결과를 리렌더링하는 방식으로 비동기적 작동을 한다는 것을 알게 되었습니다.
이 때만약 ‘렌더링’이라는 것에 대해 정확히 몰랐다면, 그냥 그런가 보다 하고 지나가는 것이 아니라 또 다시 렌더링이라는 키워드로 구글링을 하여, 브라우저의 렌더링 과정에 대해서 정확히 이해하는 과정을 꼭 거쳐야 합니다.
지금 모르는 개념은 언젠가 또다시 마주치게 되기 때문에, 그러한 학습 부채를 쌓아두지 않고 제때 공부하여 해소하는 것이 중요합니다.
2. 구체적이지만 피상적인 ‘방법론’만을 제시하는 글이 아닌, 해결책과 함께 가급적 그 원리까지 이해하고 넘어간다.
위의 예시에서 혹자는
‘아, useState를 동기적으로 처리하려면 setState에 어떠한 값을 바로 넘겨 주는 것이 아니라 함수를 통해 전달하는 방식으로 처리하면 되는구나. 또는 useEffect의 의존성 배열을 이용하면 되겠구나. 이유는 잘 모르겠지만 잘 되니까 일단 그냥 넘어가자’
라는 생각으로 단순 해결법만을 가지고 넘어갈 수 있습니다.
하지만 위에서 언급했듯, 특히 주니어 단계에 가까울수록 학습 부채를 제때 해결해야 성장할 수 있다고 생각합니다.
useState의 작동 방식을 모르겠다면 이에 대해 뜯어 보고, 함수형으로 처리하면 왜 정상 작동하는지를 이해하고 넘어가야 합니다.
모르면 물어봐라
위에서 언급했듯, 구글링을 통해 스스로 문제를 해결할 수 있는 능력은 중요합니다.
하지만, 그럼에도 불구하고 구글링만으로 해결되지 않는 문제들이 존재하기 마련입니다.
최소 1~2일 정도 스스로 해결하려 충분히 고민한 문제라면, 문제가 어느정도 구체화되었을 것이며 질문을 통해 얻고자 하는 점이 보다 명확해진 상태일 것입니다. 그러한 상태에서 질문을 해야 질문을 받는 분도 질문에 답변해줄 가치를 느끼고, 효과적으로 명확한 답변을 주시기 쉽습니다.
충분히 혼자서 고민해보고, 질문과 답변을 주고 받을 준비가 된 상태에서 질문을 하는게 주니어 개발자의 기본 자세이자 효과적인 문제 해결 방법이라고 생각합니다.
유저는 예상대로 움직이지 않을 수 있다.
이번 개발 과정을 통해 다시금 느낀건, ‘개발자가 당연시하는 동작이 유저에게는 결코 그렇지 않을 수 있다’라는 것입니다.
예컨대 다음 화면에서 유저가 로그인을 한 후 화면을 켜둔 채 24시간동안 방치했다가, 다시 화면으로 돌아와 링크를 입력하고 ‘카카오톡으로 인증 완료하기’ 버튼을 눌렀다고 합시다.
(보안을 위해 로그인 세션을 24시간 미만으로 설정한 상황. 로그인 세션 확인은 페이지 라우팅 시에만 하도록 설정되어 있다고 가정.)
유저의 로그인 정보가 없으므로 인증 버튼은 작동하지 않을 것입니다.
이때 초보 개발자의 시선으로, ‘인증 버튼이 작동하지 않으면, 사용자는 당연히 새로고침을 해보겠지’라고 생각하면 안됩니다.
프로그램을 직접 만든 개발자의 시선에서 당연하다고 여겨지는 것이, 해당 화면을 처음 보는 실제 사용자의 입장에선 결코 당연하지 않을 수 있습니다.
위의 경우에선 당연히, 페이지 라우팅 시 뿐만 아니라 버튼 클릭을 통한 API 호출 등의 이벤트에도 로그인 세션의 만료 여부를 체크하고, 만료되었다면 안내 메시지와 함께 유저를 다시 로그인 창으로 redirect하는 방향으로 코드를 짜야 합니다.
마무리
한달어스의 코드 마이그레이션 과정에서 느낀점을 짧게나마 거시적인 관점에서 정리해보았습니다.
작업 과정에서 마주친 구체적인 문제 상황들과 해결 과정은 차후 순차적으로 각각의 포스팅을 통해 다룰 예정입니다.
누군가는 필자와 같이 소규모 조직에서 개발 과정 전반을 책임 지며 고군분투하는 과정에서 본 글을 접하였을 수 있습니다. 또 누군가는 한달어스의 개발 여정이 궁금해서, 혹은 또다른 다양한 경로를 통해 본 글을 읽게되었을 수도 있습니다.
어떤 이유에서건 본 글을 읽은 모든 이들에게 감사를 표하고, 각자의 상황에 알맞은 도움이 되었길 바랍니다.
