리드잇zine(ReadITZine) 8호 원고 작성 <오늘과 내일 사이 그 어딘가 : #FIXME>, 2023-04-30(Sun) 마감

https://best-bag-0db.notion.site/zine-8-4a954531d02e46f699f9c56453a48539

오늘과 내일 그 사이 어딘가 : FIXME LATER

FIXME는 "수정이 필요한 부분"을 의미합니다. 코드에서 문제점이나 버그를 나타내고, 수정이 필요한 부분을 표시하기 위해 사용됩니다.

“이게 문제가 있다는 건 알아. 하지만 당장 더 중요한 것들이 많잖아. FIXME로 문제 표시만 일단 해두고 넘어가자.”

시간에 쫓기며 달려가느라 쌓여만 가는 수많은 FIXME들. 여러분의 ‘FIXME’에 대한 이야기를 들려주세요. 마음속에 늘 품고 있는 ‘기술 부채’에 대한 이야기도 좋습니다. 부채가 있는 것이 꼭 문제라고는 할 수 없습니다. 어떤 문제가 있는지, 어떻게 조금씩 해결해 나갈 것인지 계획을 세워두는 일이 더 중요하죠. 그리고 같은 문제를 반복하지 않는 것. 그리고 변하는 상황에 대한 유연한 자세도요.

여러분의 이야기가 궁금합니다. 일에 대한 것도 좋고, 일상에 대한 이야기도 좋아요. 개발자 동료들, 독자들이 좋아할 만한 여러분의 이야기를 기다리고 있겠습니다.

오늘과 내일 사이 그 어딘가 : #FIXME

FIXME는 "수정이 필요한 부분"을 의미합니다. 코드에서 문제점이나 버그를 나타내고, 수정이 필요한 부분을 표시하기 위해 사용됩니다.

“이게 문제가 있다는 건 알아. 하지만 당장 더 중요한 것들이 많잖아. //FIXME (#FIXME) 주석으로 문제 표시만 일단 해두고 넘어가자.”

인생의 주로를 정신없이 달려가고 있기에, 앞만 보고 달려가느라 쌓여만 가는 나의 FIXME 리스트들. 여러분의 FIXME 에 대한 이야기를 들려주세요.

여러분의 이야기가 궁금합니다. 일에 대한 것도 좋고, 일상에 대한 이야기도 좋아요. 개발자 동료들, 독자들이 좋아할만한 여러분의 이야기를 기다리고 있겠습니다.

회사 업무 언젠가 내 손으로 완성하고 싶은 github actions 테스트 코드에 대해 - 쌓여가는 기술 부채 그리고 진짜 FIXME

개인 공부 양자 컴퓨팅 프로젝트 오일러

안녕하세요.

19년이라는 오랜 기간 동안 소프트웨어 엔지니어의 삶을 살고 있는 김종필입니다. 이번 주제는 FIXME에 대한 이야기인데 회사에서 겪었던 일들 그리고 개인적으로 공부하면서 미뤄진 것들에 대해 얘기해 보고 싶습니다.

FIXME 1, 패키지 관리 시스템 구축에 대해

첫 이야기는 회사 개발 업무에 관한 이야기입니다. 저는 몇 년간 unity를 사용해서 AR/VR 관련된 프로젝트와 제품 개발을 해 왔습니다. 처음에는 아무것도 없는 것 부터 프로젝트를 만들기 시작해서 계속해서 여러 프로젝트와 R&D, PoC 등을 거치면서 Util 함수로 쓸 만한 것들, 라이브러리로 써볼 것들이 조금씩 생기기 시작했습니다. 그리고 그 결과물들을 더 확장을 시켜서 unity에서 사용하는 unity package 형태로 만들었습니다.

그런데 회사에서 개발 하는 제품 관점에서 패키지는 제품 개발에 필요한 부수적인 것이라 생각할 수 있지만, 패키지도 하나의 작은 소프트웨어라고 생각할 수 있기 때문에 끊임 없이 개선하고 버그를 수정하고 버전 업그레이드를 해야 패키지를 사용하는 사용자의 만족도를 끌어 올릴 수 있습니다.

그래서 회사 제품 개발에 필요해서 만들어 둔 몇 개의 unity package들을 관리할 수 있는 방법으로 사내 서버를 두고 관리하는 방법으로 진행했습니다. npm package registry와 크게 다르지 않은 방식으로 registry를 설정하고 packages.json 파일에 관리해서 서버에서 해당 패키지를 받아와서 관리하는 방식입니다. 그런데 이 방식은 관리 측면에서는 괜찮았지만 지속적인 소프트웨어 유지보수 측면에서 빌드 파이프라인 까지는 고려되지 않은 방식이라 CI/CD가 더 추가 되어야 했고 거기서 github actions라는 걸 접하고 공부를 하게 되었습니다.

github actions는 소프트웨어의 작업 흐름을 정의하고 거기에 맞게 자동화된 빌드, 테스트, 배포 과정을 도와주는 도구이며, github 서비스와 통합이 되어 있기 때문에 별도의 환경 세팅이나 설치 과정 없이 github 내에서 자연스럽게 적용할 수 있는 CI/CD 도구입니다.

github actions를 적용하기 이전까지는 수동으로 패키지를 서버에 업로드하는 스크립트를 각자 로컬 PC에서 사용하는 방식으로 진행했었기 때문에, 이 작업을 자동화할 필요성을 많이 느껴서 github actions를 선택해서 진행하는 걸 고려하고 결정했습니다.

github actions를 통해 최종적으로는 다음과 같은 프로세스로 작업이 되게 만들려고 했습니다.

패키지 리포지토리에서 소스 수정이 진행되면 github actions를 통해 패키지 사내 서버 업로드 자동화(self-hosted runner 사용)
제품 개발 프로젝트의 unity package manager를 통해 방금 업데이트된 버전의 package 적용

계속해서 이 시스템을 개발하다 보니 더 잘 관리하고자 하는 욕심이 생기게 됐고 다음과 같은 부분을 더 고려해서 변경하려고 했습니다.

github의 packages를 통해 패키지 관리
github actions marketplace를 통해 패키지 소스를 관리하고 이걸 github actions에서 더 잘 사용할 수 있게 변경

이었는데 최종적으로는 github actions를 더 잘 사용하는 방향까지는 진행되지 못했습니다. 모든 회사일이 그렇지만 중요한 마감 시간이 닥치면 계획했던 일을 나중에 미루고 해야 하는 우선순위가 생기고 거기에 이 작업은 낄 틈이 없었습니다. 나중에라도 꼭 github actions를 통한 패키지 관리 시스템을 만들어 보고자 시간을 더 쓰긴 했지만 결국 나중에 해야 한다라는 FIXME라는 태그만 달린 채 현재 만들어진 패키지 관리 시스템으로만 돌리는 것으로 만족해야만 했습니다.

이 작업은 사실 계획도 잘 세웠고 스터디도 해서 진행한 거라, 시간을 더 들이면 충분히 할 수 있는 부분이기도 합니다. 그래서 언젠가는 다시 진행해서 완성해 보고 싶은 마음이 있습니다.

FIXME 2, 테스트 코드의 기술 부채

개발자 분들이라면 테스트 코드의 중요성에 대해 많이 알고 계실 것이고, 또 실무에서도 개발 프로세스의 필수적인 단계로 실천하고 계신 분들도 많을 겁니다. 저 또한 실무에서 개발할 때 작성하는 코드는 테스트 코드와 함께 로직을 검증하고 테스트 코드 실행의 자동화 까지도 함께 진행합니다.

그런데 이제 테스트 코드를 조금씩 변경을 가하는 상황이 오게 되는 순간이 있습니다. 이유는 다양한데 개발 환경이 변경되서 기존에 작성했던 테스트 코드의 일부 값들을 변경하거나 요구사항이나 정책이 변경되서 테스트 코드도 함께 변경이 일어나는 일이 벌어집니다. 우선은 일정에 문제만 없다면 테스트 코드도 함께 변경해 나가지만 급한 일정이 생기거나 정책에 대한 의사 결정이 미뤄지면서 주석처리만 해둔 테스트 코드가 하나 둘 생기기 시작하죠. 여기서 테스트 코드의 기술 부채가 시작되는 것 같습니다.

사실 테스트 코드에 주석 처리는 하는 것도 하지 말아야 할 일인데 우선은 빨리 배포해서 확인해야 하는 로직을 우선적으로 작성하다 급하면 그런 일이 종종 벌어집니다. 그래서 테스트 코드에도 항상 "나중에 정책 결정되면 수정해야 함", "개발 서버 변경되면 주석 풀어놔야 함" 같은 주석을 달아 놓게 됩니다.

<실패한 테스트 케이스는 빠른 개발 속도와 리팩터링에 대한 안정감을 얻기에 충분합니다, 출처: JetBrains>

그렇게 해서 자동화 테스트 진행 시 테스트 케이스가 실패하면 배포서버로 넘어가지 못하니까 테스트 케이스들이 어떻게든 All pass 상태를 유지하기 위해 주석을 해 두고 의미 없는 test pass로 계속 남게 됩니다. 작업해야 하는 도메인과 서비스는 더 늘어나고 복잡해지면서 테스트 코드 역시 함께 늘어나게 되고 테스트 케이스가 어느샌가 수백개가 쌓이는 시점이 오게 됩니다. 매번 자동화 빌드 단계에서 test pass가 나오는 것만 안심하고 실질적으로 특정 테스트 케이스 코드에 주석을 달아놓고 의미 없는 test pass를 언제 해 뒀는지도 잊어 버리는 것도 겪다 보니 자연스럽게 code coverage에도 관심을 가지게 되는 순기능도 경험하게 되었습니다.

이런 문제점들은 코드 리뷰 단계에서 팀원들과 공유가 되니까 나중에라도 수정을 할 수 있는 기회라도 갖게 되는데, 아직 pull request를 통해 리뷰도 진행하지 못하는 즉, 로컬에만 작성하고 주석처리한 테스트 케이스들이 더 심각한 기술 부채를 안고 가게 되는 상황을 만드는 것이라고 생각합니다. (아쉽게도 이런 일들은 실무 경헙이 부족한 주니어 개발자 분들에게 많이 일어나는 일입니다)

나중에 다시 올바로 테스트 코드가 수정되어야 하는 시간은 올 수도 있고 안올수도 있습니다. 하지만 항상 바쁘게 앞만 보며 개발을 하는 일정에서 그런 여유로운 시간은 거의 주어진 적은 없었던 것 같습니다. 오늘 지금 당장 처리해야 하는 테스트 케이스 코드들이 눈에 보인다면 주석을 걷어내고 테스트 코드에 대한 검증 코드를 바로 작성하는 것이 최선이라고 생각합니다.

FIXME 3, 양자 컴퓨터

몇 년 전 우연히 과학 채널의 유튜브를 보다가 양자 역학이라는 걸 접하게 됐고, 그 양자 역학의 원리를 활용해 컴퓨팅에 적용하는 양자 컴퓨터에 대해서 관심을 가지게 되었습니다. 그날 이후 바로 양자 컴퓨터 관련된 책을 읽게 됐고 관련된 공부를 시작했습니다.

<저를 양자 컴퓨터의 세계로 빠져들게 한 유튜브 영상, 출처: youtube Kurzgesagt – In a Nutshell 채널>

수십년간 컴퓨터를 공부하고 실무에서 개발을 해온 저에게 있어서 양자 컴퓨터의 개념은 너무나도 신선했습니다. 양자 얽힘과 중첩에 대한 개념도 마법과 같았고 무엇보다도 정보의 단위인 비트가 큐비트라는 단위로 0과 1이 관측되는 시점에 확률로 결정되는 것도 신기하다 못해 이런 신기함 마저 그냥 받아들여야 하는 영역으로 접근했었습니다.

처음 컴퓨터를 공부했을 때의 어려움이 양자 컴퓨터를 공부할 때도 그대로 다가왔습니다. 비트 단위의 논리 게이트인 AND, OR, NOT 게이트는 너무 당연한 개념인데 양자 컴퓨터 세계에는 파울리, 토폴리, 하다마드등 이름도 생소한 양자 게이트를 알아가는 과정이 필요했습니다.

몇 권의 책을 읽고 정리하던 중, 양자 프로그램밍 가능한 QASM이 있다는 걸 알게 되었고 IBM에서 양자 프로그래밍이 가능한 클라우드 서비스와 큐비트 게이트 배치를 통해 그 결과를 얻을 수 있는 것 까지 있다는 걸 알게 되었습니다. github에 실습을 위해 내용을 정리하면서 실습을 위해 보던 책의 출판사에 메일까지 보내 책 내용 일부와 연습문제를 공개로 하겠다는 내용까지 허락을 받고 공부를 했었습니다.

<3년 전 진행한 양자 컴퓨터 공부 내용을 올린 github, chapter1만 진행하고 그 이후로 진행 못하고 있다>

사실 IT 기술의 흐름상 양자 컴퓨터도 언젠가 큰 흐름이나 유행이 될 수 있는 날이 올 것이라 믿고 조금씩 공부해서 진행하면 좋겠다는 점도 양자 컴퓨터를 공부하는데 동기 부여가 되기도 했습니다. 왜냐하면 블록체인, 인공지능, 메타버스, 그리고 지금은 ChatGPT에 이르기 까지 짧으면 1년 길면 2~3년 이어지는 IT 기술의 특이점을 생각해 보면 양자 컴퓨터 분야도 그 시기가 올 것으로 기대하고 있습니다.

그럼 마음으로 약 1년간 진행한 공부는 다른 바쁜 회사일과 중요한 일에 비해 관심에서 멀어지면서 중단이 되었고, 마음속 한 켠에는 언젠가 다시 진행해야지라는 마음만 가지고 있습니다. 지금 이 글을 쓰는 시점에도 다시 시작해야 겠다는 생각을 하고 있으니까요. 어쩌면 이것도 저의 게으름으로 인해 만들어진 부채라는 생각이 많이 듭니다. 올해는 반드시 달성 가능한 계획을 세우고 공부를 진행하려고 하고 있습니다.

FIXME 4, 프로젝트 오일러

프로젝트 오일러는 유명한 수학자의 이름을 딴 웹사이트 이름으로, 컴퓨터를 사용해서 수학 문제를 풀고 문제를 풀면 풀었던 사람들의 다양한 프로그램 언어와 해결 방법을 공유할 수 있는 사이트입니다.

<프로젝트 오일러 문제 페이지, 취업을 위한 한국식 알고리즘 코딩 문제와 달리 수학 문제 자체를 컴퓨터 프로그래밍으로 풀어야 하는 재미(?)가 있다, 출처: projecteuler.net>

외국에서 생활하는 한 한국인 개발자 분의 블로그를 통해 프로젝트 오일러를 알게 되었고 그 분이 100문제를 풀어 나가면서 정리한 글이 있었습니다. 게다가 저는 한번도 해보지 않았던 프로그래밍 언어인 clojure로 풀어 나가는 걸 보고 저도 한번 해보면 좋겠다라는 생각을 하게 된 것 같습니다.

저 역시도 프로그래밍 언어를 뭘 쓸지를 정할지 고민을 조금 했었습니다. 제가 주로 쓰는 언어는 C#인데 C#으로 문제를 푸는 건 그렇게 도움이 될 것 같지 않았습니다. 처음 몇 문제를 풀 때는 몰랐는데, 프로젝트 오일러 문제는 프로그래밍 언어 숙련도도 중요하지만 수학적인 문제 이해가 더 중요하기 때문입니다. 그래서 인기 순위가 높은 프로그래밍 언어를 번갈아 가며 문제를 푸는 방식으로 정했고 그렇게 한 동안 문제를 푸는 재미를 들였습니다.

또 문제를 풀어서 올려 놓았던 걸 다시 생각해 보니 더 좋은 방법이 있어서 다시 푼 문제도 몇 문제가 되다 보니 문제 자체를 이해하는 게 더 중요하다는 걸 알게 되었습니다. 1번 문제를 소개해 드리면 1번 문제는 다음과 같습니다.

1000보다 작은 자연수 중에서 3 또는 5의 배수를 모두 더하면?

대부분의 개발자 분들은 문제를 보자마자 1000번을 실행하는 for문 코드 그리고 3과 5를 사용한 모듈러 연산을 쉽게 떠올리셨을 겁니다. 하지만 아마 프로그래밍을 배우지 않은 고등학생에게 문제를 풀어 보라고 하면 코딩은 하지 못하겠지만 등차수열의 합과 차를 통해 문제를 풀었을 겁니다. 이 지점에서 수학적 이해가 중요한데 문제를 어떻게 풀던 결과는 나오겠지만 조금 더 수학적인 이해를 바탕으로 프로그래밍 코드를 작성할 수 있으면 프로젝트 오일러 문제를 푸는데 있어서 더 효율적이고 도움이 됩니다. 그리고 계속해서 다음 문제를 풀다 보면 전에 풀었던 수학적 지식을 자연스럽게 터득하게 되기도 합니다.

아쉽게도 저는 현재 프로젝트 오일러 문제를 27번 까지만 풀었고 중단된지 3년이 넘었습니다. 양자 컴퓨터 공부 보다는 무게가 조금은 덜 하지만 그래도 꾸준히 1년에 몇 문제라도 풀면 어떨까? 하는 생각만 가득하고 아직 다음 문제인 28번 문제를 풀지 못하고 있습니다.

<다양한 프로그래밍 언어로 문제를 풀고 정리한 github README 페이지 , 출처 https://github.com/jongfeel/ProjectEuler>

프로젝트 오일러도 중단된 이유도 앞만 보고 바쁘게 살다 보니 우선순위라는 것에 밀리게 되고 그러다 보니 시간이 흘러 잊혀지게 된 것 같습니다. 아직 구체적인 계획을 세우지는 않았지만 언젠가 계획을 세우고 한 문제씩 차례대로 풀어 나가면서 수학과 프로그래밍의 재미를 함께 느낄 수 있는 시간을 가져보면 좋겠다는 생각입니다.

jongfeel / Activity