스프링 캠프, 쉼표
의도치 않게 참석한 스프링 캠프 2025. 누군가 내게 소프트웨어 엔지니어로 깨어 있으라고 말하는 것 같았다. 한 동안 일단 동작하게 만들기 전략을 앞세워 달려 온 것 같다. 오늘 여러 발표를 들으며 내가 소프트웨어 엔지니어링 기법들에 대해 한 동안 거의 생각해 오지 않았고, 단지 기능이 동작하도록 구현하는데 몰두해 왔음을 깨달았다. 소프트웨어의 복잡성을 다루는 일이라던지, 의존성의 방향이 한 방향이 되게 하는 등의 테크닉들을 생각할 겨를도 없이 눈 앞의 환경에서 최선의 것을 신속히 구현해 온 것 같다. 스스로에게 괜한 변명거리를 찾게된다. 아마도 이런 것들을 의도적으로 생각하진 않았지만 그래도 늘 더 나은 코드, 더 나은 구조의 시스템을 만들려 노력했을 것이다. 내가 그런 것들을 하고 있다고 느낄 겨를도 없이 바빴을 뿐이다. 잠시 쉼표가 필요했던 것 같다.
밖도 돌아볼 때
이번에 나는 스프링 캠프가 열리는 줄도 모르고 있었고, 요즘은 트위터에도 거의 들어가지 않는터라 이런 소식은 거의 접하지 못하고 있었다. 최근에 너무 기쁜 소식이 있어 SNS에 남기고 싶은 마음에 트위터에 접속했는데 누군가 스프링 캠프 티켓 구매에 실패했다는 글을 보게 되었다. 그러고 아무 생각 없이 인프런에 들어가 결제를 눌러 봤는데 결재가 된거다. 때마침 누가 취소한 표가 난 건지 어떻게 내가 구매한 건지 모르겠다. 아무튼 급하게 기능을 동작시키고 우리의 실험을 이어가는데 매진하던 나에게 성능도 고려하고, 유지보수도 생각하고, 새로운 기술도 살피며. 조금 더 크고 장기적인 시스템을 생각하라고 여기 나를 보냈다는 생각이 들었다. 작년에 모든 컨퍼런스 참석에 다 떨어져 대외 행사에 한 번도 참석하지 못했다. 회사 일에 집중할 때인가 보다 하고 계속 회사 일에만 몰두 했는데 다시 밖도 돌아볼 때가 되었나 보다.
요즘 나는 Linux, C++, Python
길게 후기 글을 쓸 말이 딱히 생각나지 않는다. 요즘 Java, Spring을 사용하고 있지 않고, 어떤 프레임워크 없이 단순히 Linux 위에서 C++ 로 개발을 하고 있다. Pyhton으로 미션 계획 시스템들을 개발하고 있는 건 조금 특별하다. 아무튼 오늘 특별히 기술적인 감상을 남길 것은 없는 것 같지만 몇 가지 인상 적인 것들을 남겨 본다.
질문하고 답변 받는 것을 넘어
Agent AI 라는 개념을 접하게 되었다. 지금도 늘 ChatGPT나 회사에서 구매해준 Gemini, Copilot 과 코딩을 하지만 나는 확실히 Agent AI 라는 개념을 잘 활용하고 있지 못한 것 같았다. 나는 단순히 질문을 하고 답변을 받아 이용하는 입장이라면 Agent AI는 스스로 목표를 세우고 실행하고 피드백을 받아 잘못된 것을 교정하는데 까지 한 걸음 더 나아간 개념 같았다. 요청한 코드에 대해 테스트 코드까지 작성되어 자기가 만든 코드를 검증하는 부분이 인상깊었다. 오늘 소개 받은 AWS Q Developer 꼭 사용해 봐야겠다. (어쩌면 Cursor를 먼저 사용해 봐야할지도 모르겠다) 최근에 리눅스에서 다양한 명령어를 GPT에게 물어보고 활용하다가 CLI에서 자연어를 받아 Linux 명령어 세트를 입력하고 실행해 주는 Agent 같은게 있으면 좋겠다고 생각했는데 발표자께서 앞으로 GUI 기반의 IDE보다 CLI가 부각될 것이라는 말에 공감할 수 있었다.
바쁠 때도 생각하기
소프트웨어의 복잡성을 다루어내고 의존성을 단순하게 하는 일들을 바쁜 일정 가운데서도 잊으면 안되겠다.
다른 사람 발료를 보고
이번에 몇몇 사람들의 발표자료들을 보면서 PPT가 너무 보고서 같이 작성되어 있다는 것이 눈에 띄었다. 글씨가 거의 보이지 않았고 한 페이지를 띄우고 책을 읽듯 설명을 많이 해주었다. 물론 그래도 유용한 설명이 있었지만 임팩트 있게 다가오지는 못했다. 그리고 몇몇 다이어그램이나 그림들이 페이지를 지나갔는데 어떤 자료는 간결하게 모아 나중에 사진을 찍을 수 있게 한 장 딱 띄워주면 좋겠다는 생각이 들었다. 다음에 발표할 일이 있으면 그렇게 해야겠다고 생각했다. 그리고 또 다른 발표에서는 관련 기술의 좋은 점을 많이 설명해 주었는데, 트레이드오프가 되는 반대편의 이야기는 해주지 않아 발표를 듣는 내내 무척 아쉬웠다. 다음에 지식을 공유할 일이 있다면 꼭 좋은 점과 트레이드오프가 되는 단점도 공유하고 적절한 상황까지 말해주어야겠다고 생각했다. 그리고 나도 무언가 가치있는 것들을 공유하는 일을 다시 하고 싶다는 생각이 들었다. 내 삶에 뭔가 공유할게 없나 돌아보게 되었다.
네트워크 프로그래밍
중간에 들어가서 어느 회사의 누가 발표하신 건지 설명을 못들었는데 나중에 얼핏 듣기로 스터디 모임을 하시는 분들 같기도 했다. 중간 중간 설명 중에 아쉬운 부분들이 보였다. 예를 들면 비동기 소켓에서 읽기 API 호출을 했을 때 반환 값이 0보다 크면 다시 읽기를 하지 않아도 된다는 설명이 거슬렸다. 소켓에서 읽기 API 호출은 실제로 읽은 바이트 수를 반환하는데 내가 읽기를 요청한 바이트 수와 다를 수 있기 때문이다. 사실 아무것도 읽을 것이 없어서 에러 코드를 반환하는 것과 다르지 않은 상황일지도 모른다. 아무것도 읽을 것이 없는 것과 내가 원하는 것을 다 읽지 못한 상황 모두 다시 읽기를 해야 하는 건 마찬가지이기 때문이다. 따라서 내가 요청한 길이 만큼 읽었는지 체크를 하며 재시도를 반복해야 하는데 이런 내용이 빠져 있어서 약간 아쉬웠다. 여기까지가 즉흥적인 내 생각이었는데 혹시나 해서 Java 소켓 API들을 잠시 찾아보고 머리를 숙이게 되었다. 저수준 Java의 소켓 읽기 API는 내가 생각하는 것과 달랐다. 예를 들면 그냥 in.read()와 같이 몇 바이트를 읽을지 입력을 받는 파라미터 자체가 없었다. C, C++ 그리고 Netty 같은 프레임워크에서 네트워크 프로그래밍을 하던 내 경험에 비추어 다른 사람을 판단하던 나의 교만한 마음이었다. 상대방의 문맥을 먼저 이해하는 것은 중요하구나 다시 한 번 배운다.
Virtual Thread
Virtual Thread에 대한 개념을 조금 이해할 수 있어서 좋았다. Virtual Thread는 JVM이 플랫폼 쓰레드를 통해 Application 레벨에서 관리하는 가상의 쓰레드임을 이해하게 되었다. 플랫폼 쓰레드가 OS에 의해 컨텍스트 스위칭 될 때는 비싼 비용이 드는 반면 Virtual Thread는 Application 레벨에서 더 적은 비용으로 쓰레드 간 스위칭을 관리함으로 성능 이점을 달성한다고 했다. 세세한 내용은 더 공부해 봐야 할 것 같다.
기술 토크 세션
이동욱님과 조영호님 안영회님의 기술 토크 세션은 정말 좋았다. 1시간에 소프트웨어 개발에 대한 양서 여러 권을 액기스만 뽑아서 읽은 것 같은 느낌이 들었다. 소프트웨어 개발에 대해(특별히 현실의 팀에서 개발하는 일에 대해) 치열하게 고민하고 적용해온 온 사람들이란 느낌이 들었다. 열심히 메모한 좋았던 조언들을 그냥 나열한다.
- 내 코드를 다른 사람이 보거나, 내 코드를 다른 사람이 고칠 때 설계가 중요해 진다. 나 혼자만 뭔가 할 때는 좋은 설계라는게 잘 와 닿지 않는다.
- 코드리뷰 시 맞고 틀리고를 리뷰하는 것 보다는 팀이라는 생태계가 서로 이해하고 합의되도록 하는 것이 중요하다.
- 앞으로 어떤 상황이 될지 알 수 없는데, 내 기준에 맞는 것을 미리다 만들어 놓는건 결코 좋지 않다.
- 동료들이 스스로의 생각으로 만든 결과물을 빠른 제품 릴리즈를 통해 필드로 부터 피드백을 받도록 기회를 준다.
- 객체를 설계할 때 연극의 시나리오를 쓰듯이 시스템의 동적인 흐름을 생각해 본다. 그리고 요소들을 나누고 어떤 인터랙션이 일어나는지 생각한다. 나는 정적인 코드 구조부터 생각하지 않는다.
- 아무리 강의를 많이 들어도 모듈 간의 경계와 책임을 나누는게 실제로는 잘 안되는데, 이건 경험이 쌓여 가야 하는 일 같다.
- 뭔가를 분리할지 말지 고민되는데 둘의 변화의 속도와 방향이 분명이 다르면 분리하는게 좋다. 그러나 잘 모르겠으면 처음부터 무조건 나누진 않는다. 한 DB를 여러 조직에서 함께 공유해서 쓴다면 나누는게 합리적이다.
- 어떤 패러다임(절차 지향, 객체 지향, 함수형) 안에서도 공통적으로 코드를 나누는 일이 있고, 또한 나눌 뿐 아니라 함께 돌아가게 해야한다.
- 나는 미래에 있을 창발적 설계의 기회를 막지 않으려 한다.
- 현재 상황에 맞게 가장 단순한 설계를 하는게 좋다.
- 복잡도의 레벨이 바뀌었는데 고민 없이 과거의 방식을 고집하는 건 나쁘다.
- 켄트벡의 TDD & 익스트림 프로그래밍 책을 추천한다.
- 내가 처한 환경 안에서 할 수 있는 최선이 좋은 설계이다.
빅뱅 방식으로 최선의 개발하기
마지막으로 ‘빅뱅 방식으로 최선의 개발하기‘ 세션을 들었다. 오늘 들은 첫 세션에서 정보가 트리 구조로 되어 있어서 너무 싫다는 한 발표자 분의 이야기를 들으며 웃었는데 이 분은 트리 구조를 코딩이 아닌 분석과 설계 작업 프로세스에서 너무 잘 쓰고 계셔서 놀랐다. 일하는 방식을 배우는 일은 코딩 기술을 배우는 것 만큼 가치있다는 생각이 들었다. 내 개인적인 일들을 다룰 때나 회사의 프로젝트를 이끌 때 잘 사용해 봐야겠다고 생각했다. 사실은 나도 이렇게 하고 있는 듯한데, 누군가 이런걸 이론화해서 체계적으로 설명해 주니 더 가치있고 설득력있게 다가왔다. 이외에도 화면과 API와 DB테이블을 연관지어 설계하고 API껍데기를 만들고 더미 응답을 하도록 미리 구현하는 방식은 내가 일해오던 방식과 많이 닮아있다고 생각했고, 요즘 웹개발을 안해서 잊고 있던 개념들을 상기시킬 수 있었다.
크라이치즈버거
끝으로 오늘 크라이치즈버거에서 점심 협찬을 한 것 같았다. 사장님께서 편지를 손수 써서 주셨는데 사장님의 마음이 전해졌다. 사장님 말대로 대량 주문은 대게 그렇듯 햄버거가 식어 있어서 다음에 매장에 가서 따뜻한 햄버거를 먹어보고 싶다는 생각이 들었다. 사장님 하시는 일이 잘되시길.
정말 오랜만에 대외 활동이었다. 감사하고 좋은 시간이었다.
