Software Engineering Note

2024년 회고

devmoons — Tue, 31 Dec 2024 20:49:33 +0900

2월부터 새로운 업무를 맡게 되었다.

시대가 시대인만큼 LLM을 이용한 뭔가를 한다.

올해는 여기에 집중했다.

찰떡같이 말해도 개떡같이 알아듣는다.

찰떡같이 말하면 찰떡같이 알아듣는다.

개떡같이 말해도 찰떡같이 알아듣는다.

이런 변화 과정을 거치고 있다는 생각이 든다.

기계가 이제 자연어를 이해하기 시작한 것이다.

이것은 매우 큰 변화라고 생각한다.

나는 머지않아 개발자가 많이 줄어들 거라고 생각한다. 아예 없어지는 건 아니겠지만.

새 시대를 대비하는 것도 필요하지만,

그전에 내가 할 수 있는 것을 해보고 싶다.

마지막으로 쏟아부어 서비스로써의 결과물을 만들어낼 수 있을까.

회사에서 투자를 좀 더 하면 좋겠는데. 내년에는 상황이 나아지길 바라본다.

application 이 out of memory 로 죽을 때 개선 사례

devmoons — Mon, 19 Feb 2024 00:40:49 +0900

책을 읽던 중 사례 연구를 다루는 부분을 읽다가 생각이 나서 작성해 본다.

평화롭던 어느 날 서버 애플리케이션이 내려가기 시작했다.

동일한 어플리케이션이 수십대 서버에서 돌아가고 있었는데 하나씩 차례대로 내려갔다.

우선은 서비스 복구가 먼저이므로 한 명은 애플리케이션을 재시작하기 시작했고, 다른 팀원들은 원인 분석에 들어갔다.

원인은 너무 큰 데이터가 들어왔고, 이 데이터를 읽어 객체로 변환하는 과정에서 발생한 것이었다.

다만, 무조건 발생하는 건 아니었다.

이 애플리케이션은 요청한 size 만큼 결과를 내어주는데, 요청 size 가 작으면 버틸만했다.

원인을 알아냈으니 이제 개선을 해야 한다.

어떻게 개선을 할 수 있을까? 생각해 보자.

너무 큰 데이터를 읽으려고 하면 에러를 발생시켜 에러 응답이 나가도록 할 수도 있다.

적어도 서버가 죽어나가는 것보다는 나은 방법일 것이다.

하지만 정말 좋은 방법일까?

이 서비스로 요청을 보내는 사용처에서 감내해야 할 귀찮음을 생각해 보자.

아마도 에러 응답을 받으면, size 를 줄여 다시 요청을 보내야 할 것이다.

그래도 에러 응답을 받으면 다시 줄여서 보내야 한다. 한마디로 귀찮아진다.

적당한 개수를 결과로 내어주는 방법은 어떨까?

size=10 으로 요청을 하더라도 데이터의 크기가 너무 크면 5 정도만 내어주는 것이다.

이 방법으로 접근하면 사용처의 귀찮음도 없을 것이다.

가능한 방법인지 살펴보니, 가능해 보였다.

데이터를 kafka 에서 읽어오고 있었는데, kafka 에서 읽어올 데이터의 양을 지정할 수 있었던 것이다.

byte 단위로 읽어와서 이를 응답용 객체로 만드는 부분을 개선하면 될 것 같았다.

여기서 다시 고민되는 부분이 있었다.

size=10 으로 요청했는데 5개만 내어주는 게 맞는 것일까?

잘 모르는 사용자가 이와 같은 결과를 얻는다면 의아해할 것이다.

(일반적인 DB를 보라. 10개를 달라는데 5개만 내어놓는 제품이 있던가.)

물론, 내부용 서비스라 사용처에 설명하면 되는 문제이긴 하다.
하지만, 설명을 해야만 하는 설계는 좋은 설계가 아니라는 게 내 생각이다.
대체로 "A로 요청하면, B가 나온다" 는 관례가 있다면, 그렇게 설계하는 게 좋다.

생각 끝에 sizeHint 라는 새로운 파라미터를 생각해 냈다.

sizeHint 로 지정한 만큼 내어주려고 하되, 꼭 그렇게 되진 않는다는 의미를 담고 싶었다.

2023년 회고

devmoons — Mon, 1 Jan 2024 12:26:33 +0900

회사에서 희망퇴직을 진행했고,

나는 동료들과 이별하며 리딩하던 조직을 없애버렸다.

그리고, 한동안 AS를 좀 하면서 고용안정 문제를 해결하느라 바빴다.

생각보다 오래 걸리는 일이다. 2024년에는 새로운 업무를 시작할 것으로 예상이 된다.

연초까지는 조직 분위기가 괜찮았다. 뭔가 해보려는 분위기가 살아났었다.

단위 테스트라는 책을 읽고, 클라이언트용 라이브러리를 개발하는데 적용하면서, TDD에 대해 사내 세미나를 진행했다.

외부 활동을 좀 했는데.

교보문고 readITzine #7 호에 기고를 했다.

책으로만 존재하는데 어떤 분이 감사하게도 정리를 해주셨다.

https://www.redbusbagman.com/heart/

멀리간다는 마음으로

카카오엔터프라이즈 개발자, 오치문 님이 작성한 글인데 13년 차 개발자의 마음에 13년 차 UX 리서처가 공감할 수 있는 부분이 많았습니다. 일을 하면서 주니어, 중니어, 시니어 시기를 거칠 때마

www.redbusbagman.com

그동안 해왔던 업무를 정리하면서 외부 발표 자리에 섰다.

타이밍이 참 절묘하다. 마침 정리가 필요한 시점에 발표자를 모집하는 글을 봤으니말이다.

https://devmoons.tistory.com/entry/2023-%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%95%BC-%EB%86%80%EC%9E%90-%EB%B0%9C%ED%91%9C

2023 데이터야 놀자 발표

2023년 10월. 데이터야 놀자라는 개발자 행사에서 발표자로 섰다. 그동안 진행했던 업무를 마무리하는 시점에 행사 안내를 본 것은 운명일까. 데이터 유통 플랫폼 구축하기 (부제: 저장소를 통합

devmoons.tistory.com

자료를 만들고 녹화를 하는데 고생을 좀 했는데, 이렇게 남겨놓으니 역시 뿌듯하다.

2024년에는 어떤 일을 하게 될지, 다시 개발자로 빠져들 수 있을지, 궁금해진다.

2023 데이터야 놀자 발표

devmoons — Sun, 17 Dec 2023 12:02:57 +0900

2023년 10월.

데이터야 놀자라는 개발자 행사에서 발표자로 섰다.

그동안 진행했던 업무를 마무리하는 시점에 행사 안내를 본 것은 운명일까.

데이터 유통 플랫폼 구축하기 (부제: 저장소를 통합하라)

한 판 정리하고 나니 뿌듯하다.

강의를 하는 느낌이 들었는데 전체적으로 재미있었다.

다만, 가끔 화면이 튕기는 오류가 있어 발표가 순조롭지 못했다.

음성도 녹음이 안되서 나중에 따로 녹화를 해야 했다.

이후에는 좀 더 개선되길 바라본다.

어쨌든, 좋았던 경험.

https://www.youtube.com/watch?v=GR7a0nHF-sg

단위 테스트 (Unit Testing)

devmoons — Sun, 19 Feb 2023 20:56:15 +0900

단위 테스트

소프트웨어 개발에 있어 단위 테스트는 이제 선택이 아니라 필수가 됐다. 단위 테스트에 대한 오해를 바로잡고, 올바른 단위 테스트에 대한 원칙, 테스트를 작성하는 스타일과 효과적인 테스트를 위한 소프트웨어 아키텍처를 이해할 수 있다. 또한 단위 테스트를 통합 테스트와 구분하고, 둘의 차이와 각각 활용법과 적절한 작성법, 안티 패턴 등을 알 수 있다.

저자: 블라디미르 코리코프

출판: 에이콘출판

출판일: 2021.10.20

좋은 책이다.

내용도 좋고 번역도 괜찮다.

테스트에 대한 이야기뿐만 아니라,

육각형 아키텍처, 함수형 아키텍처, 패턴과 관련된 내용도 기술되어 있고,

이러한 아키텍처와 테스트의 관계에 대해서도 잘 설명되어 있다.

도메인과 컨트롤러로 나누고,

도메인에는 복잡한 비즈니스로직과 알고리즘을,

컨트롤러에는 협력자와의 통신만을 넣어야 함을 강조하는데 이것이 책을 관통하는 핵심 아닐까 싶다.

그러므로, 유닛테스트는 도메인 영역에만, 통합테스트는 컨트롤러 영역에만 적용해야 한다.

복잡한 코드를 도메인과 컨트롤러 영역으로 분산되도록 리팩토링 하는 예제도 나와서 이해가 쉽다.

테스트를 정말 잘 만들고 있는지, 어떻게 만들어야 하는지 고민하는 개발자라면, 꼭 보라고 권하고 싶다.

좋은 개발자가 되는 방법

devmoons — Sat, 18 Feb 2023 13:43:00 +0900

1. 장인 정신

주어진 일을 직업이나 직장생활에서 해야 하는 의무로 생각하느냐,

정말 잘 끝내야 하는 작품으로 생각하느냐의 차이는 엄청 큰 것이다.

(개발자의 업무는 대부분 코드를 생산하는 것이라, 이것을 작품이라 표현했다.)

코드를 보면 이 사람이 어떤 마인드로, 어느 정도의 정성으로 일을 했는지가 보인다.

생계를 위한 코드는 동작하는데 만족한다. 고민의 흔적이 많이 보이지 않는다.

여기저기 중복이 존재하고, 확장성은 찾아보기 힘들다.

내가 같이 일 하고 싶은 동료들은 모두 장인 정신이 어느 수준 이상은 있었다.

내 기준으로는 그런 동료들이 좋은 개발자이다.

그들에게는 배울 점이 있고, 같이 성장하는 기분이 든다.

그들은 일단 눈높이가 높아서 같은 일을 해도 일의 퀄리티가 다르다.

더 좋은 코드, 더 좋은 아키텍처를 항상 고민하고 또 가능하게 만든다.

그들에게 일의 퀄리티는 뭔가 양보할 수 없는 영역처럼 느껴지기도 한다.

장인 정신을 갖자는 것은

일을 잘 마무리하는 것에 관심을 갖자는 것이고,

업무 결과를 예술 작품으로 생각해 보자는 것이다.

이는 곧 본인의 성장과 연결된다.

2. 업무와 관련된(or 관심 분야) 공부

같은 내용의 책도 내가 필요할 때 보면 더 잘 들어오는 법이다.

새로운 업무를 맡았다면 기회로 생각하고 그와 관련된 책이나 강좌들을 알아보자.

현재 고민하고 있는 내용과 그 해결책이 제시되는 경우도 있으니, 이를 활용하면 더 훌륭하게 일을 끝낼 수 있다.

비슷한 일을 하더라도 새로운 방법으로 일을 진행하거나, 새로운 기술을 도입해서 지식의 영역을 확장시킬 수 있다.

업무를 지식 확장의 기회로 만들라는 뜻이다.

여러분이 할 일은 공부에 필요한 시간을 할애하는 것뿐이다.

업무 외에도 관심 있는 분야를 공부하는 것도 좋다.

내 말 뜻은, 어떤 지식을 잘 받아들일 수 있는 조건이 되었을 때를 전략적으로 이용해서, 밀도 있는 학습을 하라는 의미이다.

3. 공유

새롭게 배웠거나, 문제를 해결했거나, 개선을 했거나.. 이 과정에서 깨달음을 얻었다면 공유를 해보자.

그런데, 이것이 공유를 할 만한 내용인지 고민되는 경우가 있을 것이다.

시니어라면 대충 각이 나오는지 알 것이고, 주니어라면 조직장이나 시니어에게 조언을 얻어보자.

지식 공유에 관심이 있는 조직장이라면 업무 상황을 보고 공유를 제안할 수도 있다.

공유 자리를 준비하면서, 또 질문을 받으면서 얻은 지식을 더 공고히 다질 수 있는 기회가 된다.

그럼 좋은 개발자가 되면 뭐가 좋을까.

당연히 부와 명예를 얻을 확률이 높아진다. 그런데, 이를 본질로 생각하고 추구하면 안 된다.

본질은 스스로의 성장이다. 훌륭한 장인이 되는 것이다.

그래야 회사에도, 사회에도, 동료에게도 도움이 된다.

잘 포장된 입 개발자들로 인한 해악을 그동안 많이 봐왔을 테니 무슨 말인지 이해하리라 믿는다.

2022년 회고

devmoons — Sat, 31 Dec 2022 21:01:24 +0900

벌써 2022년도 다 갔구나.

올해 초부터 같이 일한 멤버들이 빠지는 한 해였다.

각자가 다른 이유로 자신의 길을 갔다.

착잡한 기분도 들었지만, 또 그게 서로를 위한 길이기에 이해가 되었다.

하지만, 역시 사람이 빠지는 건 마냥 괜찮을 수는 없었던 일이었다.

그래도 생각보다 빨리 원 상태로 돌아온 것 같다.

다시 손 발을 오래 맞춰왔던 멤버들만 남았다.

몇 년 동안 같은 시스템을 운영하고 있는데,

계속해서 할 일이 있는 건 참 신기하고도 재미있는 부분이다.

어떤 일은 부탁을 받기도 하고, 어떤 일은 스스로 만든다.

몇 번 문의를 받다 보면 자동화할 수 없는지를 계속 고민하게 된다.

그러다 보면 다시 할 일이 되는 것이다. 성취하면 또 뿌듯함을 얻게 되고. 성장도 한다.

좋은 루틴이라 생각한다.

올 해는 몇 권의 책을 읽었다.

처음부터 끝가지 본 책도 있지만, 궁금한 부분만 읽은 책도 있다.

확실히 호기심이 있을 때 읽어야 머리에 잘 들어온다.

업무를 하면서 계속 의문을 갖게 만드는 게 좋은 전략이란 생각이 여전히 유효한 것 같다.

초여름에는 leetcode에 들어가 문제를 꽤 풀었다.

하다 보니 랭크 올리는 재미가 있고, 또 푸는 맛이 있어 약간 중독되었던 것 같다.

확인해보니 5-7월에 많이 풀었네.

그렇다고 코딩테스트를 잘 친다는 이야기는 아니다.

코딩 테스트는 어떠해야 하는가 라는 글도 남겼다.

IDC 화재로 4-5일은 개고생 한 것 같다.

정말 이러다 회사가 망하는 건가.. 싶은 생각도 들었다.

하지만 사람의 힘이란 무서운 것이다. 결국 크루들의 의지로 하나하나 다 복구해냈다.

앞으로는 이런 일이 발생하지않기를. 제발.

몇 개 회사와 커피챗도 했다.

주로 스타트업이었고. 요즘은 커피챗이 좀 유행인 것 같다.

서로를 알아보는데 도움이 되고, 이야기를 하다 보면 현재 몸담고 있는 회사의 장단점도 보인다.

하고 나면 대체로 지금 하고 있는 일이 꽤 재미있고, 카카오가 참 좋은 회사라는 생각이 들었다.

아직 이직이 급하진 않은 것 같다.

내년에는 왠지 좀 더 열심히 일과 공부를 할 것 같은 예감이 든다.

코딩 테스트는 어떠해야 하는가

devmoons — Sun, 4 Sep 2022 11:12:35 +0900

코딩 테스트에 대한 생각을 적어보려 한다.

코딩 테스트의 유형은 크게 두 가지로 나뉜다.

온라인 코딩 테스트, 그리고 직접 만나서 티키타카를 하며 진행하는 코딩 인터뷰

온라인 코딩 테스트는 주로 테스트 환경을 제공하는 업체를 통해 진행되고 지원자에게 링크가 전송되어 언제까지 풀라고 요구한다.

코딩 테스트를 생각하기 전에 먼저 어떤 개발자를 뽑고 싶은지 생각할 필요가 있다.

- 최소한의 코딩 능력만 갖춰도 괜찮은 개발자를 원하는가?

- 알고리즘에 탁월하거나 머리가 좋은, 순발력이 뛰어난 개발자를 원하는가?

- 기본적인 코딩능력과 문제 해결 능력이 있고 잠재력이 있는 개발자를 원하는가?

알고리즘에 탁월하거나 문제 해결 능력이 엄청 뛰어난 개발자를 뽑고 싶다면,

미친 수준의 하드코어 알고리즘 문제를 내고 온라인 코딩 테스트로 필터링하면 될 것이다.

나라면 기본적인 코딩 능력과 문제 해결 능력이 있고 잠재력이 있는 개발자를 선발 기준으로 삼겠다.

어떻게?

온라인 코딩 테스트와 코딩 인터뷰를 둘 다 진행한다.

온라인 코딩 테스트에서는 기본기를 평가하고, 코딩 인터뷰에서 잠재력을 확인한다.

온라인 코딩 테스트 문제의 구성은 3-4 문제로 하고,

1번 문제는 자신감을 심어줄 수 있는 비교적 쉬운 난이도의 문제를 선택한다.

긴장감을 풀어주고 자신감을 주어 제대로 실력을 발휘하도록 하기 위해서다.

난이도는 쉬운 문제에서 어려운 문제 순서로 배치하고 시간은 충분히 부여한다.

온라인 코딩 테스트는 기본기를 평가하므로, 온라인 코딩 테스트는 반드시 전부 풀 수 있어야 한다.

코딩 인터뷰는 어려운 문제를 선택해도 상관없다.

단, 일방적으로 풀라고 하는 것이 아니라 조금씩 힌트를 주면서 문제 해결을 유도하고, 함께 푼다는 분위기를 조성해야 한다.

이런 측면을 고려하면 처음에는 쉬운 해결책이 생각나지만, 그 방법으로는 실행시간이 너무 오래 걸리는 등의 문제로 더 나은 해법이 필요한 문제가 좋다. 해법이 여러 개일 수 있는 문제가 좋다는 의미도 된다.

코딩 인터뷰에서 중요하게 봐야 할 것은,

더 나은 해법이 왜 더 나은지를 제대로 이해하는지, 시간/공간 복잡도를 잘 따져보는지, 해법을 제대로 구현하는지 등이다.

다음은 leetcode 문제를 풀면서 코딩 인터뷰 문제로 쓸만하다 생각되는 것들을 정리한 것이다.

two pointers

https://leetcode.com/problems/find-the-duplicate-number

bfs

https://leetcode.com/problems/network-delay-time

Sliding Window

https://leetcode.com/problems/permutation-in-string/

https://leetcode.com/problems/longest-substring-without-repeating-characters/

DP or Expand Around Center

https://leetcode.com/problems/longest-palindromic-substring/

Trie or BinSearch

https://leetcode.com/problems/search-suggestions-system/

hash or union-find

https://leetcode.com/problems/longest-consecutive-sequence/

greedy, priority queue, parametric search

https://leetcode.com/problems/furthest-building-you-can-reach/

greedy

https://leetcode.com/problems/container-with-most-water/

merge sort, segment tree, etc

https://leetcode.com/problems/count-of-smaller-numbers-after-self/

segment tree

https://leetcode.com/problems/range-sum-query-mutable/

코딩 인터뷰어들도 다양하게 풀어보고 인터뷰에 활용하면 좋을 것이다.

어느 날 문득

devmoons — Sun, 8 May 2022 00:25:29 +0900

오늘 갑자기 과거 경력을 정리해보고 싶었는데

정리하다 보니 시기별로 추구했던 가치가 구별되어 신기했다.

크게 나누어보면

- "성장"에 목말랐다.

- "인정"에 목말랐다.

- "몸값"에 목말랐다.

신기한 이유는 당시에는 그것이 목표라고 생각하지 않았기 때문이다.

이제야 돌아보니 그때는 그랬더라. 이런 느낌?

그냥 본능적으로 그렇게 살았던 것 같다.

시기별로 성과가 있었다는 점도 신기하다.

역시 인생은 생각하는대로 흘러가는 것인가. 아니 생각보다는 본능이 이끄는 대로?

그리고 이제는 다시 배움과 성장에 목마르다.

그런데 과거보다 훨씬 더 재미있을 것 같다.

이제는 아무것도 모르면서 좌충우돌하지 않기 때문이다.

과거에 했던 일의 의미를 다시 되새기게 되고 한편으론 정리되는 느낌도 든다.

책을 읽어도 와닿는 부분이 많다.

이제 정말 고수가 될 준비가 된 것 같다. : )

효율적 개발로 이끄는 파이썬 실천 기술

devmoons — Thu, 7 Apr 2022 22:45:14 +0900

효율적 개발로 이끄는 파이썬 실천 기술

좋은 책이다.

초심자 뿐만 아니라 나처럼 파이썬을 어깨너머 배운 사람에게도 도움이 된다.

설명이 친절한 게 최장점이다.

실행 코드에 오타가 좀 있지만 극복 가능한 수준이다.