그러나 한편으로는 누군가가 나를 관찰해주고 결국 나에게 도움이 될 만한 피드백을 준다는 점에서는 어떤 피드백이던 경청할 필요가 있다는 생각이 있다.

개발을 잘한다는 건 뭘까

소프트웨어 엔지니어는 당연히 개발을 잘해야한다. 라는 전제를 깔았을 때, 당연히 개발을 잘한다는 건 어떤걸까? 한 때는 새로운 기술을 잘 사용하는 걸 개발을 잘한다고 오해했던 적도 있고, 한 때는 빠르게 개발하는 걸 개발을 잘한다고 오해했던 적도 있는 거 같다.

지금은 개발을 잘 한다는 건 결국 지금 비즈니스에서 필요한 게 무엇이고 거기에 적합한 기술을 활용하여 제품을 만들어내는 것이라고 생각한다. 다만 이 생각의 근거를 만들기위해 수많은 시행착오를 겪었고, 지금도 여전히 겪고있다고 생각한다.

하면 좋은것과 해야만하는 것은 분명히 다르니까, 팀의 리소스를 활용하여 무언가를 행하는 것이기 때문에 결국 ‘이걸 함으로써 어떤 이점이 생기는가?’ 에 대해서 분명한 이유가 없다면 하지 않는 것이 더 나을 수도 있다. 그런 면에서 잘하는 개발자는 코드를 짜는 행위를 벗어나서, 이 코드를 왜 짜는가에 대해서도 집중하는 사람이라고 생각한다. 관습적으로 행하다보면 어느 순간 행위 그 자체가 이유가 되기도 한다. 항상 그 늪에 빠지지 않게 주의하고 있지만 참 어려운 일이다.

피드백이 필요한 이유

대부분 사람들은 자기 자신에게 지나치게 관대하거나, 또는 지나치게 엄격한 면이 있다. 자기 자신을 객관적으로 보는 행위는 정말 어려운 면이 있다는 점이다. 운동을 할 때 트레이너가 붙어있으면 단순히 그가 숫자만 세줘도 운동 수행 능력이 높아진다는 이야기를 본 적이 있다. 개인의 동기 부여 및 성장은 단순히 개인에게서 발생하는 것이 아니라 하나의 집단, 또는 훈련단계에서 발생하기도 한다.

그러니 조금 무섭더라도 누군가가 나에게 피드백해주는 시간은 참 귀한 것이다. 피드백을 들을 때까지만 해도 “그거 아닌데" 라는 생각을 하다가 돌이켜서 곱씹어보면 “그 말이 맞구나” 라고 생각되니 말이다. 그래서 나는 많은 사람들에게 피드백을 들어보려고 노력한다, 쉽지 않지만 피드백을 받는건 중요하다.

매몰비용에 대해

피드백을 받지 않고 무언가를 지속해서 하다가 꽤 오랜 시간이 지나고 나서 방향이 잘못되었다는 걸 알았을 때, 과연 그 매몰 비용을 모두 감수하고 바로 개선에 돌입하는 것이 쉽게 가능할까? 오히려 아직 시간이 많이 지나지 않았을 때, 즉 매몰비용이 그렇게 높지 않을 때 빠르게 발 빼고 다른 데 시간을 투자하는 게 나을 수도 있다.

좋은 소리만 듣는 건 건강한 피드백이 아니다.

한 때는 좋은 소리만 들었던 적이 있는데, 지금 돌이켜보면 그것이 좋은 피드백이 아니라고 생각한다. 오히려 귀에 듣기 싫은 소리일 수록 내 가슴에 박히고, 그 말이 가장 건강한 피드백이었던 경험이 있다. 냉정하다고 여겨질 수도 있지만, 결국 피드백이라는 건 “내가 지금 놓친 부분” 또는 “내가 실패하고 있는 지점”, “내가 부족한 부분”에 대해서 듣는 기회이기도 한 것이다.

그러니 누군가가 귀에 단 소리를 한다면 오히려 조심해야할 때라고 생각한다. 역사상의 위인들이 간신에 의해서 망한 걸 보고도, 정작 나조차도 귀에 단 소리만 찾고있지않나 싶기도 하다.

피드백과 깨달음에 대한 도서

개인적으로는 소프트웨어 엔지니어 가이드북이라는 책이 좋았다. 깨달음에 대한 도서 중에서는 헤르만 헤세의 싯다르타가 가장 좋았다. 그 외에도 최근에 다양한 엔지니어링 스킬에 대한 책들이 늘어나고 있기 때문에, 어디서나 쉽게 접근하기 좋다고 생각한다.

보일러플레이트 작성하기

새로운 코드 작업을 시작할 때 Figma 의 디자인을 바탕으로 보일러플레이트를 생성할 때 종종 사용한다.

주로 작업 초기 단계에서 유용하고, 이걸 쓰라고 만든 코드인가 싶은 결과물이 나올 때가 종종 있는데 그래도 50번 정도 돌리면 1~2번 정도는 의미있는 수준의 결과물이 나온다.

테스팅

테스팅은 의외로 활용도가 높다가도 낮다가도 하는게, 코드를 읽고 테스트코드를 짜주는 방식이다 보니까 구현체에 의존해서 테스트 코드를 작성한다. 테스트 케이스의 동작을 보장해주는 느낌보다는 코드가 의도한대로 동작하면 이런 테스트 케이스는 통과 될거임. 같은 느낌.

근데 코딩용 AI 들 말고 그냥 Gemini 나 Chat GPT에 ‘이런 테스트 케이스의 코드를 작성하고 싶은데 작성해줄래?’ 하면 주석까지 포함해서 어느정도는 잘 작성해주긴 한다. 그래서 예전에 검색에 의존하던 것들 일부를 AI에 대체할 수 있는 정도.

예시) 아이디 비밀번호 유효성 검사를 위한 정규표현식을 작성해줄 수 있을까? 보편적인 케이스여도 좋아.

뇌 외주 맡기기

가끔 코드를 작성하다보면 여러 군데에 동시다발적으로 수정해야하는 경우가 생기는 데, 이럴 때 use case를 다 찾아서 일괄적으로 수정해달라고 할 때 유용한 경우가 있다. 근데 코드베이스가 조금만 커져도 인덱싱을 제대로 못해서 AI가 인식하다가 뻗어버리는 경우가 있음.

그래서 그냥 예를 들어서 A 코드 작성하면서 ‘지금 작성 중인 코드는 이런 스펙을 위한거야. 이 코드를 위한 테스트 케이스들을 정리해줄 수 있을까?’ 라고 던져두면 테스트 케이스 몇 개 작성해주기 때문에 유용할 때가 있다.

예시) 지금 작성 중인 코드는 React로 되어있고, 유저의 ID와 비밀번호를 받아서 로그인 처리하려고 해. 이 코드를 위한 테스트 케이스를 작성해줄 수 있을까?

조금 더 복잡도 있는 코드도 디테일하게 작성하면 나름 잘 될 때가 있기 때문에 한 번 해보시길, 개인적으로는 코드 짜는데 30분 정도는 가볍게 쓰는데 프롬프트 쓰는데 30분 쓰면 왜 이리 아까운 지 모르겠다.

그리고 가끔 코딩 너무 집중해서 하면 뇌정지올 때 있는데, 그럴 때 AI한테 스펙 쭉 설명해주고 로직 설계 해달라고 하면 생각보다 잘해줌. 이제 그걸 조합해서 구현해야하는 건 당연히 엔지니어의 역할인데, 그래도 Scaffold 수준의 로직 청크가 몇 개 나오니까 맛이 좋다.

어떤 모델을 쓰는가?

프롬프트 하나 작성해두고 모델 돌아가면서 쓴다. 개인적으로는 Gemini 결제해서 사용하고 있다.

해보니 어떠한가

솔직히 뇌 외주 맡긴다는 느낌으로 가장 많이 사용한다. 이 친구가 짜준 코드는 보편적인 케이스는 잘 대응해주는데 엣지 케이스 하나 생길 때마다 스스로와 싸우다가 결국 이상한 코드 만들어내는 거 같다.

그래서 Scaffold 나 Boilerplate 정도 만들 때는 확실히 유용하고, 좀 보편적인 테스트 케이스 같은거 맡길 때도 확실히 유용한데, 코딩 결과물에 대한 최종적인 컨펌은 반드시 거쳐야하고 그걸 또 잘 조립하는 건 엔지니어의 역할인듯.

AI가 완전히 대체 가능한가에 대해서는 내가 답할 수 있는 영역은 아닌 거 같지만, 이런식의 생산성 증대는 퀄리티 저하로 이어질 가능성이 있겠다고 생각한다. 코드가 자동 생성되니까 가끔 커밋 한방에 코드 3~400줄 가까이 작성하는 경우도 있는데, 3~400줄 정도 되는 로직을 한번에 커밋하면 코드 리뷰 해주는 사람도 받는 사람도 어느 부분을 어떻게 수정해야하는 지 파악하기 어려울 가능성이 생긴다.

근데 이런 변화를 패러다임 쉬프트라고 받아들여야할 지는 잘 모르겠다. 하지만 개인적으로는 이거 까딱 잘못하면 피보겠는데..? 정도의 느낌.

프론트엔드는 진입 장벽이 낮다는 이야기를 많이 듣고, 나 스스로도 그렇게 생각했었는데 막상 생각해보면 FE가 왜 진입 장벽이 낮다고 생각하게 되는건지 명확한 이유를 모르겠다.

구현한 UI가 화면에 보이니까 디버깅이 쉬워서? 그렇게 생각하면 빌드 과정에서 에러가 나는 컴파일 언어들이 더 쉽지 않을까. HTML + CSS + JS 만 알아도 시작할 수 있으니까? 요즘 FE를 그렇게 시작하는 사람들이 얼마나 될까?

AI의 발전으로 개발 자체가 쉬워졌다는 이야기도 하지만, 막상 현실에서 겪는 개발 문제들은 AI가 해결해주지 못하는 것들이 여전히 많다. 도메인에서 생기는 문제들은 Best Practice 만으로 해결되지 않고, 때로는 안티 패턴을 사용해서 해결하기도 하고, 때로는 중개 레이어를 만들어서 해결하기도 한다.

FE는 그래서 쉬운가?

쉽다고 생각하면 쉽다.

UI를 화면에 노출시킨다는 행위 자체만 놓고 본다면, 과거에 비하여 분명히 개선된 부분이 많아져서 과거보다 훨씬 쉬워졌다고 이야기할 수도 있겠다. 그러나 반대로 이야기하자면, 사람들의 보편적인 UX에 대한 기대감이 높아진만큼 FE 영역에 대한 어려움도 증가한다.

그냥 정말 단순하게 접근해서, 데이터를 실시간으로 업데이트 해야하는 서비스를 구축해야하는데, UI 내에 그래프도 있고 테이블도 있고, 테이블은 가상 스크롤을 지원해야하며 그래프는 5가지 타입을 지원해야 한다. 또 테이블의 각 영역을 클릭했을 때 보여주는 디테일 UI가 존재하고, 디테일 UI에서는 구현해둔 그래프를 사용하되 사용자가 선택한 그래프 타입을 서비스 전체에서 연동해서 사용하고싶다. -> 어떻게 구현할 것인가?

컴퓨터에서 사용 가능한 리소스가 늘어난만큼 더 다양한 시도를 해볼 수 있게 되고, 과거보다 서빙하는 서비스의 크기 자체가 커지면서 여러 서비스의 각 이해 관계자들이 원하는 요구사항도 다양해진다.

결론적으로 말하면 점점 어려워진다.

모르면 쉬워보인다.

예전에 CrossFit을 하기 전에 CrossFit 대회를 보면 ‘저 사람들은 어떻게 저런 동작을 저렇게 잘 하지? 다들 잘하는데 쉬운 거 아닌가?’ 라는 생각을 한 적이 있다. 그러나 막상 CrossFit을 하고나니 생각보다 고려해야할 게 정말 많고, 그 사람들이 쉽게 하는 건 그만큼 잘 하기 때문이었기 때문이었다.

모르면 쉽게 느껴질 수 있다. 그래서 어느 상황이던 ‘이거 쉬워보이는데?’ 라는 생각이 들면 스스로 주의해야 한다. 그렇게 생각해서 수많은 실패를 경험했고, 그렇게 생각해서 수많은 오해를 만들었었다.

이 세상에 쉬운 일은 없다.

Front-end 엔지니어라고 하나 필요하다면 API 를 직접 연동하는 작업도 하고, Client Server 에서 필요한 Infra 작업을 하기도 하고, API 의 DTO를 직접 수정하기도 한다. 가끔은 API를 직접 구현하게 되는 일도 생긴다. (* 얼마전에 우리 회사에서는 처음으로 API 배포해봤다)

Full-stack engineer 의 허상에 대해서 많은 이야기를 하지만, 최근 몇 년 간 내 생각은 모두가 Full-stack engineer 가 되어야 하고, 거기서 얼마나 깊이있게 한 분야의 지식을 가지고 있는가로 승부를 봐야한다는 것이다. “Front-end 엔지니어니까 BE는 몰라도 된다” 같은 식의 접근이 좋은 접근이라고 생각하지 않는다.

Product engineer는 Front-end 엔지니어건 Back-end 엔지니어건 제품을 만드는 사람이라는 본질을 잃어서는 안된다.

전문성이란

전문성이라는 말에 대해서 종종 다시 생각하게 된다. 얼마 전 트위터 (현 X)를 보다보니 프론트엔드 개발자라면 수학이 필수라는 이야기를 보게 되었다. 아마 그 분의 경험에서는 프론트엔드 개발 전문성에 수학이 필수라 생각하였을 것이다.

또 어떤 사람은 웹 접근성이, 어떤 사람은 UX에 대한 이해가, 어떤 사람은 라이브러리에 대한 이해도가 높아야, 어떤 사람은 JavaScript를 잘 해야, 어떤 사람은 브라우저 API를 잘 알아야한다고 할 것이다. 나는 어떤 분야의 전문성을 논할 때, 가지면 좋은 것 (Good to have) 과 필수인 것 (Required)을 구분해야한다 생각한다.

제품을 만드는 사람에게 있어 전문성은 크게 도메인에 대한 이해도와 기술에 대한 이해도로 나뉜다고 생각한다. 예를 들어 나는 E-commerce 도메인에 대한 이해, 개 중에서도 정산 시스템에 대한 이해도가 높은 Front-End 개발자일 것이다.

여러 회사에서 다양한 도메인을 접하고 다양한 시스템을 접하다 보면 도메인에 대한 이해도는 자연스럽게 높아지지만, 기술에 대한 이해도는 직접 학습하거나 문제를 직면하지 않으면 쉽게 성장하지는 않는다. 그래서 기술에 대한 이해도를 높여 도메인에서 가진 문제를 해결할 수 있는가가 개발자의 전문성이라 생각한다.

관심사

몇 년동안 여러 신입 개발자들의 이력서를 살펴보면서 “나는 OO에 관심이 많은 개발자” 라는 이야기를 많이 보게된다. 하지만 관심이 많다고는 하지만 실제로 그 기술에 대해 깊이있게 공부하거나 나름대로의 통찰을 가지는 사람은 그렇게 보지 못했다.

사용자 경험에 대한 관심이 있다면 적어도 UX 도서 한 권 정도는 읽어봤어야 하지 않을까? 사용자 경험이 어떤 걸 의미하고 실제 개발에서 어떤 식으로 적용되어야하는 지는 전혀 공부하지 않지만 “나는 더 좋은 UX를 제공하고싶다” 라는 식의 이야기는 허상에 불과하다.

앞서 이야기했지만 기술에 대한 이해도는 직접 학습하는 방법으로 습득해야하기 때문에, 기술에 대한 관심이 없다면 지식의 습득은 자연스레 느려질 수밖에 없다. 거기에 전공자가 아니라면 더 장벽은 높게 느껴질 수밖에 없다. 하지만 그럼에도 불구하고 부딪치고 배울 수밖에 없다.

나도 지금보다 경험이 부족했을 때는 좋은 엔지니어링이란 흔히 말하는 유지보수하기 쉬운 코드를 작성하고, 확장하기 좋은 코드, 왠지 깔끔한 코드를 작성하는 일이라고 생각했는데, 틀린 말은 아니지만 이 걸 좋은 엔지니어링이라고 부르기는 힘들다고 생각한다.

오히려 좋은 엔지니어링은 비즈니스를 우선하여 고려하고, 스펙에서 부족한 부분을 채워넣고, 더 나은 사용성을 제공하는 것을 우선시할 수 있어야 한다. 그 부분이 충족되었을 때가 비로소 앞서 말한 유지보수하기 쉽고, 확장하기 좋은 코드를 고려해야하는 순간이다.

광신적 아키텍처, 과도한 우려

때로 비즈니스의 요구사항보다 아키텍처가 우선시 되는 경우가 있다. 나도 여러번 했던 실수지만, 흔히 말하는 ‘OO 기술을 사용해보고 싶다’ 라는 이름으로 시작되는 것들, 또는 흔히 말하는 MSA, SSR, SPA 등등.

모든 아키텍처, 기술에는 장단점이 있고 어떤 것을 정답이라고 말하기에는 애매하다. 정답처럼 보이는 것들은 몇가지 있다. 예를 들어 프런트엔드에서는 리액트를 쓰는 것이 당연하다는 뉘앙스, 또는 빌드 도구는 Vite 를 사용해야하고, Java를 사용한다면 Spring 을 사용하는 것이 응당 당연한 것이고 등등.

당장 비즈니스의 미래를 파악하지 못한 상황에서 ‘일어나지 않은 일에 대한 과도한 우려’는 오히려 코드를 쓸데없이 복잡하게 만드는 경향이 있다. 이 말은 ‘미래를 우려하지 마라' 라는 것이 아니라, ‘과도하게 우려하지 마라’ 라는 것이다.

당장 하루 트래픽이 1,000명밖에 안되는 서비스에 당장 100,000명을 지탱할만한 시스템을 만들 필요는 없다. 언젠가 100,000명까지 급속 성장할 수도 있겠지만 그 시기가 언제일 지는 아무도 모른다.

왜 그걸 해야하는가?

생각보다 꽤 많은 경우에서 어떤 일을 하는 이유가 하고싶어서인 경우가 많다. 때로는 직감이 시키는 일이 정답일 때도 있지만, 대부분의 경우 직감이 시키는 일은 직감이 시키는 일에서 그친다.

서비스의 안정성을 높이기 위해서 OOO을 하려고 한다. 라는 말을 하려면 지금 상황이 어떠하고, OOO을 하면 미래에 어떤 식으로 서비스의 안정성이 높아지는 지를 파악하여야 한다. 비용 측면을 고려한다면 더욱 좋겠지만, 비용 측면을 당장 고려하기보다는 어떤 문제점을 어떻게 해결할 수 있는가에 대해 더욱 집중하면 좋겠다. 그렇게 하면 방향성을 어느정도 그릴 수 있게된다.

대부분의 사람들의 뇌리에 박혀있는 공통적인 방향성 또한 존재한다. 매일 30분 유산소 운동을 하면 대부분의 경우에는 지금보다 건강해질 것이다. 같은 것들이다.

• 테스트 커버리지를 높이고 테스트 케이스를 치밀하게 작성해둔다면 서비스에 새로운 기능을 추가할 때 더 안정적으로 추가할 수 있다.
• 함수명을 명확하게 지으면 추후 유지보수 과정에서 코드를 파악하는 데 도움이 된다.
• 할 일 관리 도구에서 할 일을 잘게 쪼개고, 매일 작은 업무를 처리해나가는 과정을 반복해나가면 업무 투명성이 높아지고 더 직관적인 업무 진행이 가능하다.
• 새로운 서비스를 구현하기 전에, 미리 문서를 작성하여 시스템 전체에 대해 분석하고 어떤 방향성으로 구현할 지 동료들과 리뷰하면 서비스 구현 과정에서 겪을 이슈를 사전에 파악할 수 있다.

아무리 좋은 코드를 작성해도

서비스가 망하면 크게 의미가 없다. 망한 서비스는 망한 서비스인 것이다. 함수명을 기깔나게 작성했던, 테스트 커버리지를 100%를 유지했던 상관 없다. 개발자 개인에게는 뜨거운 경험으로 남았겠지만, 서비스가 망한다는 건 말 그대로의 의미를 내포한다.

당장 모든 것이 마음에 들지 않아도, 비즈니스를 궤도에 올린 후에 하나씩 뜯어고쳐나가면 된다. 새로운 코드에 대한 테스트 커버리지를 80% 이상으로 고정한다거나, 시스템 전체의 모니터링 환경을 재구축한다거나, 불필요하게 쓰이는 자원이 없는가 등등. 우리에게는 비즈니스가 정상 궤도에 오른 후에도 더 많은 일이 남아있다.

나는 늘 비즈니스가 우선이라고 생각한다. 모든 비즈니스의 요구사항을 들어주기는 어려울 수 있어도, 비즈니스에 이로운 방향을 늘 고려하여 개발해야한다. 적어도 취미 개발자가 아니라면 말이다.

Shortly, I removed Twitter account that peoples can contact with me include secret accounts. For now, Only I have one accounts for following tech news personally. Social Network is making me connect to other folks but also far away me with other folks. So I decide to remove my twitter accounts for.

2 weeks at Japan

There has been no travel from last June 2023. So I plan to go Japan for 2 weeks, and it was great days to me. Nobody do not cares me and nobody do not wanna to contact to me.

I visited Kurashiki, Miyazu, Amanohashidate, Inenohunaya, Osaka, and many CrossFit boxes. Drink many Japanese Whiskey and good foods. Lululemon is very cheap at Japan by the way.

Learning Spring

As a Web engineer, I was using the Node based frameworks and server-less platform. But now I need to implement Spring based web application, So nowadays I learning Spring and related knowledges.

One of the major thing is Spring boot support package compatibilities and Spring having strong conventions lather than Node. So when I making code changes with Spring, It works with new packages and it is not make conflicts between each packages.

Vue

React is good library I think but Vue is also great. Sometimes Vue is too flexible that makes work but not expected (means it MUST do not working but it is working even though we were writing the wrong code). So I was need to making some convention and anti-patterns that should be avoid on Vue based code.

(나를 포함하여) 이력서를 쓰는 데 어려움을 겪는 사람들이 많다고 생각한다. 신년을 맞이하여 이력서를 업데이트하였는데, 이력서를 작성하면서 고려했던 내용들을 나열해본다.

어떤 내용을 추가할 것인가?

이력서를 작성할 때 먼저 내가 무슨 일을 했는 지를 쭉 나열해본다. 이 때 나는 포스트잇을 사용하는 편이지만 올 해는 포스트잇이 없는 상태에서 급하게 써야 해서 우선 워드를 사용했다.

• XX 프로젝트
• YY 프로젝트
• ZZ 프로젝트

프론트엔드 개발자이기 때문에 구태여 작성하지 않는다면 프론트엔드 개발이 기본이라는 것을 모두가 알겠지만, 그럼에도 내 분야가 아닌 곳에서 했던 일이 있다면 추가로 작성하는 것이 좋다. 예를 들어, 직접 참여한 프로젝트는 아니지만 간접적으로 이런 일을 했었다.

• 모바일 개발 환경 연구 및 설계, 구축
• 프론트엔드 표준 문서 작성

이런 일들을 특별히 프로젝트성이라고 보기에는 어렵지만 기술적으로 이루어낸 일들, 그리고 중장기적으로 생산성에 도움을 주는 일이기 때문에 작성해두면 좋다.

그렇게 나열하고 나서는 P0 ~ P2 로 프로젝트별 우선순위를 추가해준다. 여기서 우선순위는 ‘이 프로젝트가 비즈니스에 미친 영향이 많다’ 인 순서가 좋다고 생각한다. 신입으로 지원한다면 프로젝트별이 아니라 Feature별로 나열할 때 우선순위를 생각해보면 좋다. 경력직이더라도 기능을 나열해두는 건 유의미하다고 생각한다.

[P0] XX 프로젝트

• [P0] OIDC 기반의 Single Sign On 구축
• [P1] GitHub Actions 를 활용한 배포 파이프라인 구축

[P0] YY 프로젝트

[P1] ZZ 프로젝트

시간이 지나서 당장 어떤 내용을 추가할 지 기억에 나지 않는 경우가 굉장히 많기 때문에, 그럴 때는 나는 PR을 다시 돌려보는 편이다.

어떤 내용을 어필할 것인가?

나는 개인적으로 “OO하는 개발자” 류의 스타트를 별로 좋아하지는 않는다. 여러 이유가 있지만 우선 고정 관념을 가진 상태로 이력서를 보게 되는 경향을 주고, 만약 OO 하는 개발자라고 썼는데 불구하고 이력서에 그런 내용이 보이지 않으면 아쉽기 때문이다.

이력서 내용을 어필할 때에는 상대방이 궁금하게 만들어야 한다. 적어도 이력서를 보고 ‘이런 일을 했다고? 한 번 상세한 내용을 들어보고 싶은데?’ 라고 만들어서 면접 (또는 과제)까지 가게 만드는 게 중요하다. 이력서에는 늘 잘한 일들을 중점적으로 쓰면 좋다. 아쉬웠던 점, 약한 점을 구태여 어필할 필요는 없다고 생각한다.

셀프 리뷰를 쓴다고 생각해보는 것도 좋다. 직장 상사나 동료가 나를 평가해야한다고 생각했을 때 셀프 리뷰 문서에 어떤 내용을 포함해야 상대방이 나를 평가할 수 있을까?

객관성을 높일 수 있는 모든 것들은 있으면 좋다.

• 수치화 가능한 건 모두 수치화한다.
• 벤치마크가 있다면 벤치마크를 반드시 활용한다.

내가 남들에 비해 뛰어나다고 생각하는 점이 있다면 어필한다.

SBI 피드백을 쑬 수 있다면 활용한다.

예를 들어,

OO 프로젝트

• OO 기능을 구현할 때, iOS Safari 및 Android Chrome 사이에 지원 범위가 명확하지 않은 이슈가 있었는데 사전에 프로토타입을 구현하여 빠르게 가능 여부를 파악했습니다. 이로 인해 추후 발생할 수 있는 이슈를 사전에 파악할 수 있었습니다. [관련 블로그 글]
• OO 기능을 구현할 때, 비즈니스 로직과 UI 로직 사이의 결합도가 높아 상태 관리가 어려운 이슈가 생겼습니다. 그 때 비즈니스 로직을 Store로 따로 분리하고 UI 로직은 컴포넌트별로 두어 비즈니스 로직 변경이 UI 로직에 직접 영향을 주지 않도록 하였습니다. 이로 인해 비즈니스 로직 변경이 용이해지고 테스트 코드를 작성하기 수월해져, 비즈니스 로직 코드 커버리지를 90%까지 끌어올릴 수 있었습니다. [관련 블로그 글]
• 특정 데이터 조회를 위한 API속도가 호출당 2 sec 정도가 걸리는 이슈가 있어, Elastic Search를 연동하여 API 속도를 호출당 0.5 sec 으로 줄인 뒤, Interface 에 페이징을 추가하여 데이터를 15개씩 호출할 때 호출당 0.1 sec 으로 최적화하였습니다.

같은 식으로 작성해볼 수 있다.

이력서도 꾸준히 개선해야한다.

프로젝트를 진행할 때에는 바쁘니 당연히 이력서를 업데이트하기 힘들지만, 그럼에도 불구하고 시간이 날 때마다 틈틈히 이력서를 개선할 필요가 있다고 생각한다. 이직 시기가 아니더라도, 시간이 지날수록 기억 속에서 휘발되기 때문이다. (이렇게 말한 나도 사실 2023년에 한 번도 업데이트하지 않았다..)

한 달에 한 번정도는 한 일을 돌아보면서 이력서를 업데이트 해보면 좋겠다.

첫번째 — 크로스핏 세미 파이널, 아시아에 스태프로 참여하면서

어떤 일이던 참석자로 참여할 때와 스태프로 참여할 때의 시선이 달라지는데 세미 파이널은 꽤 재미있는 경험이었다. 우선 부산에서 진행되어서 고향에 돌아온 기분이 들었고, 아시아의 전역의 세미 파이널이기 때문에 여러 국적의 참석자가 있었다.

우선 영어로 커뮤니케이션이 가능하다는 점은 꽤 플러스였던 거 같다. 통역 담당자가 존재했지만, 통역 담당자가 모든 통역을 담당하지 않았기 때문에 해외 참석자와 직접 이야기하는 경우에는 담당자가 직접 이야기를 나눠야 하는 때가 있었다.

나에게는 취미지만 누군가는 크로스핏의 선수로서 참여하는 모습을 보면서 대단함을 느끼기도 하고, 나는 나이가 있어서 라는 생각을 했던 때도 있었는데 나와 비슷한 나이대의 사람들이 참여하거나 더 나이가 있는 참석자를 보면서 포기하지 않아야겠다는 생각을 하기도 했다.

또한 함께 참여한 사람들의 열정을 보면서도 많은 생각을 했다. 누군가가 나에게 신선한 자극을 주는 건 꽤 좋은 시간이라고 생각한다. 나도 내 본업에서 그런 사람이 될 수 있을까? 라는 생각을 많이 하였다.

두번째 — 올 해의 해외 여행 정산

올 해는 후쿠오카를 한 번 다녀오고, 시애틀을 한 번 다녀왔다. 기존에는 더 많은 국가를 돌아다녔었는데 올 해 들어서는 유독 많이 돌아다니지 않았다. 여러 이유가 있었지만 시간도 애매하게 부족했고, 무엇보다 여행을 가야겠다는 절대적인 마음이 들지는 않았던 거 같다.

다만 시애틀에 출장을 다녀온 건 좋은 일이었다고 생각한다. 처음으로 시애틀을 방문하면서 (+ 차를 렌트하지 않으면서) 도시의 모습을 보았고, 이민에 대해 고민하던 여러가지 생각들이 깔끔하게 정리되었다. 확실한 건 여행을 다니고 경험을 쌓을 수록 더 많은 것들을 알게 된다는 것이다. 2024년에는 더 많은 곳을 가보려고 한다. 또 한편으로 2024년부터는 토플을 준비해보려고 한다.

더 많은 것들을 체험해볼 수 있는 2024년이 되었으면 좋겠다.

세번째 — Hard work

2023년에는 참 어려운 일이 많았다. 그럼에도 불구하고 2023년을 잘 마무리해서 다행이라고 생각하고, 2024년에는 더 많은 일을 해낼 수 있으면 좋겠다.

종종 어떤 엔지니어들은 “어떤 문제를 해결하기 위해서는 어떤 기술을 사용해야만 해” 또는 “이 기술을 사용하면 우리가 가진 문제가 해결될거야” 같은 추상적인 결론에 도달하기도 하는데 실질적으로 그렇지 않을 확률이 더 높다. 오히려 문제가 무엇인 지를 명확하게 하고 적절한 수준의 기술을 사용하는 것이 더 도움이 될 때가 많기도 하다. 이미 잘 굴러가고 있는 바퀴를 재발명해야할 때는, 기존 바퀴보다 더 잘 굴러갈 수 있다는 확신을 줄 수 있어야 한다 (모두와 합의가 필요하다).

간혹 아키텍처에 대한 의사 결정을 내려야할 때, 마음 한 켠에 늘 ‘이 방법이 가장 나은 방법인가’ 라는 생각을 한다. 하지만 기술 아키텍처란 결국 그런 것이다, 지금은 정답이었던 게 미래엔 아닐 수도 있다. 지금 정답이라고 생각했던 게, 막상 시작하고 나니 아닐 수도 있다.

언젠가 훌륭한 엔지니어링이라는 말에 대해 과하게 집착했던 때가 있다. 이렇게하면 더 낫겠지, 이런 기술을 쓰면 더 낫겠지. 라고 생각하며 스스로를 몰아넣었다. 하지만 이제 훌륭한 엔지니어링에 대한 생각은 좀 다르다. 결국 우리는 비즈니스를 만들어나가는 사람들이고, 비즈니스가 더 나은 방향으로 갈 수 있게 도움을 주는 사람들이다.

비즈니스가 잘 돌아가도록 만들고, 엔지니어들도 만족하게 만드는 것. 그것이 훌륭한 엔지니어링이라고 스스로 생각한다.

Installation

First, You need to install the Cassandra database server on your local computer. In the mac os, You can install it with homebrew. Open the terminal, and install the cassandra database with brew.

$ brew install cassandra

If you don’t have brew, you need to install brew first.

$ /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After downloading the Cassandra, you can turn on the Cassandra database, You can do it with brew.

$ brew services start cassandra

Also you can stop it.

$ brew services stop cassandra

After the database server starts, you can open the cqlsh for a query to the local Cassandra server. You just type the cqlsh on your terminal.

$ cqlsh

Now installation is done. You can also use docker to install and start the Cassandra database, but I don’t use docker for now.

Make the keyspace and table

Cassandra Keyspace is a data container inside of a Cassandra database system. A keyspace is an outermost object in a Cassandra cluster that controls how data replicates on nodes. You can make multiple keyspaces on your Cassandra database system. I just make one simple keyspace to local. Be careful you MUST do it with single quotes not double quotes.

cqlsh> CREATE KEYSPACE awesome_db WITH REPLICATION = { ‘class’ : ‘SimpleStrategy’, ‘replication_factor’: 1 };

This query makes a keyspace named awesome_db, so now we can make tables to the awesome_db and connect to awesome_db keyspace. After creating the keyspace, let’s make the table an awesome_db keyspace.

cqlsh> CREATE TABLE awesome_db.users (id int PRIMARY KEY, name text, email text);

I make the users table to awesome_db keyspace and make it with three fields named id, name, and email. In the table, it’s required that at least one field is set as a primary key. In this sample, id is the primary key. You can check data types from this article: CQL data types | CQL for Cassandra 3.x

You can check the table using CQL. don’t forget the semicolon. Now the table is made successfully.

cqlsh> SELECT * FROM awesome_db.users;

id | email | name
 - - + - - - -+ - - - 
(0 rows)

CQL CRUD

Now you need to know how to query with CQL. This query will using at your client server.

CREATE

You can use INSERT INTO to add data to the table.

cqlsh> INSERT INTO {KEYSPACE.TABLE_NAME} (fields) VALUES (values);
cqlsh> INSERT INTO awesome_db.users (id, email, name) VALUES (0, 'sample@email.com', 'Sample name');

READ

You can use SELECT FROM to read data from the table.

cqlsh> SELECT {FIELDS} FROM {KEYSPACE.TABLE_NAME};
cqlsh> SELECT * FROM awesome_db.users;

UPDATE

You can use UPDATE SET and WHERE to update the column. Be careful use this as this might make all columns change.

cqlsh> UPDATE {KEYSPACE.TABLE_NAME} SET {FIELD = UPDATED VALUE} WHERE {FIELD = WHERE};
cqlsh> UPDATE awesome_db.users SET name = 'updated sample' WHERE id = 0;

DELETE

You can delete columns with DELETE and also be careful this also makes delete all columns.

cqlsh> DELETE FROM {KEYSPACE.TABLE_NAME} WHERE {FIELD = WHERE};
cqlsh> DELETE FROM awesome_db.users WHERE id = 0;

You can refer to entire scripts from documents: CQL commands | CQL for Cassandra 3.x. Find what you need and make it yourself.

Make API server with Express (node) and Cassandra.

Now You can make the express server but it is okay with other server frameworks even plain nodeJS. You can use spring boot (java or Kotlin), Fastify (node), django (Python), and so on. So let’s make some server with your favourite architecture. This time, I will use the express.

You need to install the nodejs, and then automatically install the npm.

$ mkdir express-server
$ cd express-server
$ npm init -y

After that you need to install the express for making an API server.

$ npm install express

Also we’re downloading the nodemon package for node development, It will automatically restart the server when server code is changed.

$ npm install nodemon — save-dev

And you need to make a node package as a module to handle the import statement. Add "type":"module" to your package.json. You also edit scripts for starting your server.

"type": "module",
"scripts": {
  "start": "node src/app.js",
  "dev": "nodemon src/app.js"
},

Make the src folder, and make the app.js file to the src folder.

import express from 'express';

const app = express();

app.get("/", (req, res) => {
  res.send("hello world");
});

app.listen(3000, () => {
  console.log("server will be start at 3000 port")
});

Now, Let’s make some connections with Cassandra. We’ll install the Cassandra driver to connect between express and cassandra.

$ npm install cassandra-driver

You need to adding this to your app.js file

import cassandra from "cassandra-driver";

const client = new cassandra.Client({
 contactPoints: ['127.0.0.1'],
 localDataCenter: 'datacenter1',
 keyspace: "awesome_db"
});

app.get("/api/users", async (req, res) => {
 // CQL
 const query = 'SELECT * FROM users';
 // QUERYING
 const response = await client.execute(query);
 // Response to client
 res.send(response.rows);
})

After running your server, You can see the response from /api/users routes.

$ npm run dev
$ curl localhost:3000/api/users

This is all. Now you can add the query, execute, and more validations.

Sample code: https://github.com/techhtml/express-cassandra