안녕하세요. 프론트엔드 개발자 송연지입니다.

뭐가 이렇게 시간이 빠른지, 2026년 상반기가 끝난 지도 벌써 한 달이 다 되어가네요.

스물일곱 살이 된 게 엊그제 같은데요. 이제 시간이 빠르다는 말을 입에 달고 사는 걸 보니 저도 착실하게 늙어가고 있나 봅니다.

예전에는 어른들이 “나이 들면 시간이 더 빨리 간다”고 말하면 그냥 바쁘게 살아서 그런 줄 알았습니다. 그런데 진짜더라고요.

1월이 시작된 지 얼마 안 된 것 같은데 정신을 차려보니 7월이었고, 상반기 회고를 쓰려고 메모장을 열었더니 8월이 코앞이었습니다.

왜 이렇게 늦게 쓰게 됐냐고요?

저도 알고 싶지 않았어요.

정확히는 7월이 저를 놓아주지 않았습니다.

원래는 상반기가 끝나자마자 멋지게 회고를 올리려고 했습니다. 1월부터 6월까지 배운 점을 차분히 정리하고, 앞으로의 계획까지 적은 다음 “하반기도 열심히 살아보겠습니다”라고 마무리할 생각이었습니다.

그런데 7월에 통합 테스트와 납품 일정이 한꺼번에 시작되면서 회고는커녕 제가 무슨 일을 했는지도 기억하기 어려워졌습니다.

상반기는 지나갔고, 7월은 저를 지나갔습니다.

그래도 더 늦으면 2026년 연말 회고에 상반기 이야기를 섞어 써야 할 것 같아서 이제라도 적어보려고 합니다.

이번 상반기를 한 문장으로 정리하면 이렇습니다.

화면을 구현하던 프론트엔드 개발자에서, 제품의 구조와 운영까지 고민하는 개발자로 강제 확장된 반년이었습니다.

제가 자발적으로 영역을 넓혔느냐고요?

일부는 맞습니다.

나머지는 일이 저를 찾아왔습니다.

저는 피하지 않았습니다.

피할 곳이 없었거든요.

그럼 2026년 상반기 회고를 시작해보겠습니다.

---

1월

별로 한 게 없다고 생각했는데, 기반 구조를 다시 만들고 있었습니다

처음 1월을 떠올렸을 때는 별다른 기억이 없었습니다.

“작년에 개발하던 거 계속 고쳤던 것 같은데?”

정말 이 정도였습니다.

업무 기록을 다시 보기 전까지는요.

기록을 살펴보니 1월에는 별일이 없었던 게 아니라, 너무 많은 일이 동시에 진행되어서 기억이 하나로 뭉쳐 있었습니다.

작년에 만들던 기능을 수정하는 동시에 제품 구조와 시스템을 다시 설계하고 있었습니다. 여기에 보안 인증 시험 일정까지 겹치면서 새로운 기능을 빠르게 분석하고 구현해야 했습니다.

새로운 기술이 들어왔지만, 기존 제품 구조는 그 기술을 자연스럽게 받아들일 준비가 되어 있지 않았습니다.

그렇다면 어떻게 해야 할까요?

구조부터 다시 봐야 합니다.

당시에는 이 답을 몰랐습니다.

그래서 처음에는 일단 기능부터 붙이려고 했습니다. 기존 코드에 새로운 기능을 연결하고, 화면에 버튼을 만들고, 엔진에서 값을 받아오면 끝날 줄 알았습니다.

끝나지 않더라고요 ㅎㅎ

왜냐고요?

저도 알고 싶지 않았어요.

버튼 하나를 추가하면 Electron 메인 프로세스와의 연결이 필요했고, 메인 프로세스에서는 다시 보안 엔진으로 요청을 전달해야 했습니다. 엔진에서 응답을 받으면 그 값을 다시 화면까지 보내야 했습니다.

화면에서는 버튼 하나였는데, 버튼 뒤에는 등장인물이 너무 많았습니다.

프론트엔드, Electron 메인 프로세스, IPC, 로컬 엔진, 서버가 각자의 방식으로 움직이고 있었습니다.

누구 하나라도 기분이 좋지 않으면 기능이 동작하지 않았습니다.

특히 매체 제어 기능을 연결하면서 엔진 통신을 본격적으로 다루기 시작했습니다.

엔진이 문제인가 싶어서 로그를 요청했습니다.

로그에는 정상이라고 적혀 있었습니다.

모두가 정상이라고 하는데 제품만 꺼지고 있었습니다.

이런 상황이 개발자를 가장 힘들게 합니다.

누군가 명확하게 실패하면 그 부분을 고치면 됩니다. 그런데 각 영역에서는 정상이라고 말하면서 전체 제품만 실패하면 어디서부터 봐야 할지 알기 어렵습니다.

결국 화면에서 엔진까지 요청이 이동하는 경로를 처음부터 하나씩 확인하기 시작했습니다.

사용자가 버튼을 눌렀는지, 렌더러 프로세스에서 이벤트가 발생했는지, IPC를 통해 메인 프로세스까지 전달됐는지 확인했습니다.

엔진에 전달하는 데이터가 올바른지, 엔진 프로세스가 실행 중인지, 요청과 응답의 ID가 일치하는지, 제한 시간 안에 응답이 돌아왔는지도 모두 확인해야 했습니다.

이때부터 제가 보는 로그의 분위기도 달라졌습니다.

예전에는 이런 로그를 봤습니다.

선택된 값: true
API 요청 성공
화면 렌더링 완료

평화롭습니다.

1월부터는 이런 로그를 보기 시작했습니다.

Pipe connection failed
Request timeout
Engine process terminated
Unknown response ID

문장에 살기가 있습니다.

화면 렌더링 완료는 저를 안심시키는데, Engine process terminated는 저에게 새로운 하루를 선물합니다.

시제품을 제품으로 바꾸려면 구조부터 달라져야 했습니다

기능을 하나씩 연결할수록 기존 구조의 한계도 보이기 시작했습니다.

당시 구조는 시제품을 빠르게 만드는 데에는 문제가 없었습니다. 기능을 구현하고 내부에서 실행해보는 수준에서는 충분히 동작했습니다.

하지만 보안 인증 시험과 실제 납품을 생각하자 이야기가 달라졌습니다.

시제품은 특정 환경에서 한 번 잘 동작하면 됩니다.

제품은 사용자가 매일 사용해도 계속 잘 동작해야 합니다.

시제품은 오류가 발생하면 옆에 있는 개발자가 설명할 수 있습니다.

제품은 오류가 발생하면 사용자가 혼자 상황을 이해해야 합니다.

시제품은 개발자가 직접 실행해줄 수 있습니다.

제품은 사용자가 직접 설치하고 실행해야 합니다.

생각해야 할 범위가 갑자기 넓어졌습니다.

처음에는 기존 구조에서 필요한 부분만 고치면 될 줄 알았습니다. 그런데 기능 하나를 수정하면 다른 기능이 영향을 받고, 그 부분을 고치면 다시 다른 곳에서 문제가 생겼습니다.

소프트웨어 구조가 서로 손을 잡고 있는 정도가 아니었습니다.

팔짱을 끼고 있었습니다.

하나를 움직이면 모두가 같이 움직였습니다.

결국 1월에는 눈에 보이는 기능을 만드는 것보다 제품 구조와 시스템 흐름을 다시 정리하는 데 더 많은 시간을 사용했습니다.

서버에서 관리할 데이터와 로컬에서 관리할 데이터를 나누고, 화면과 엔진 사이의 책임도 정리했습니다. 요청과 응답을 어떻게 연결할지, 통신이 실패하면 어떤 방식으로 처리할지도 고민했습니다.

이 작업은 생각보다 성취감이 적었습니다.

화면을 새로 만들면 캡처라도 남길 수 있습니다.

버튼을 추가하면 직접 눌러볼 수도 있습니다.

그런데 구조를 정리하는 일은 며칠 동안 고민해도 화면이 전날과 똑같아 보입니다.

그래서 퇴근할 때마다 생각했습니다.

“나 오늘 뭐 했지?”

분명 하루 종일 일했는데 보여줄 수 있는 것이 없었습니다.

하지만 지금 돌아보면 1월에 구조를 다시 보지 않았다면 이후 기능을 추가할 때 훨씬 더 힘들었을 것 같습니다.

당시에는 진도가 나가지 않는다고 느꼈지만, 사실은 앞으로 나아가기 전에 바닥을 다시 다지고 있었습니다.

1월에 배운 것은 화려한 프론트엔드 기술이 아니었습니다.

화면 뒤의 흐름을 이해하지 못하면 결국 화면도 제대로 만들 수 없다.

프론트엔드 개발자라고 해서 브라우저와 컴포넌트만 볼 수는 없었습니다.

사용자가 보고 있는 상태가 어디에서 만들어지고, 어떤 경로를 거쳐 화면까지 전달되는지 알아야 제대로 된 사용자 경험을 만들 수 있었습니다.

그리고 새해 첫 달부터 생각했습니다.

“올해 쉽지 않겠는데?”

예상은 정확했습니다.

---

2월

개발은 트레이드오프라는데, 포기할 수 있는 게 없었습니다

납품 일정이 다가오자 구조를 다시 보게 됐습니다

2월에도 1월에 시작한 개발을 이어갔습니다.

보안 인증 시험을 위해 추가한 기능을 다듬고, 엔진 통신을 안정화하면서 제품 구조도 조금씩 정리했습니다.

개발자의 행복 기준은 상황에 따라 낮아질 수 있습니다.

세 번 실행했을 때 한 번 성공하던 기능이 두 번 성공하면 발전입니다.

당시에는 정말 그 정도의 변화에도 안도했습니다.

그러던 중 납품 일정이 점점 가까워지기 시작했습니다.

시험을 위해 빠르게 만든 기능은 있었지만, 실제 사용자가 매일 사용하는 제품으로 보기에는 부족한 부분이 많았습니다.

내부에서는 개발자가 직접 프로그램을 실행하고, 문제가 생기면 바로 로그를 확인할 수 있습니다. 하지만 제품이 고객사에 전달된 뒤에는 개발자가 항상 옆에 있을 수 없습니다.

설치부터 사용, 오류 대응, 업데이트까지 모두 사용자가 직접 경험하게 됩니다.

이제는 기능이 단순히 ‘존재하는 것’만으로는 부족했습니다.

사용자가 기능을 발견할 수 있어야 했고, 현재 상태를 이해할 수 있어야 했으며, 문제가 생겼을 때 다음에 무엇을 해야 하는지도 알 수 있어야 했습니다.

결국 기존 일정을 일부 조정하고 제품 구조부터 다시 보기로 했습니다.

일정을 바꾸는 결정은 쉽지 않았습니다.

마감일은 이미 정해져 있었고 해야 할 일도 많았습니다. 구조를 다시 설계하는 동안에는 눈에 보이는 기능 개발이 느려질 수밖에 없었습니다.

하지만 기존 구조 위에 기능을 계속 쌓으면 당장은 빨라 보여도, 나중에는 더 큰 비용을 치르게 될 것 같았습니다.

개발은 트레이드오프라는 말을 많이 듣습니다.

속도를 선택하면 구조를 어느 정도 포기해야 하고, 안정성을 높이면 개발 시간이 길어집니다. 단순한 구조를 선택하면 확장성이 줄어들고, 확장성을 고려하면 초기 구현이 복잡해집니다.

저도 그렇게 알고 있었습니다.

그런데 실제 제품을 개발해보니 포기할 수 있는 것이 생각보다 많지 않았습니다.

빠르게 만들어야 하지만 안정적으로 동작해야 했습니다.

보안은 강해야 하지만 사용하기 쉬워야 했습니다.

기능은 많아져도 화면은 복잡해지지 않아야 했습니다.

서버 상태가 불안정해도 프로그램이 바로 무너져서는 안 됐고, 그렇다고 사용자에게 잘못된 상태를 보여줄 수도 없었습니다.

엔진의 응답을 기다려야 했지만 사용자를 무한 로딩 화면에 가둬둘 수도 없었습니다.

속도, 안정성, 보안, 사용성 중 무엇을 포기해야 할까요?

아무것도 쉽게 포기할 수 없었습니다.

고객에게는 모두 필요한 조건이었기 때문입니다.

물론 모든 조건을 완벽하게 만족하는 구조는 없습니다. 결국 우선순위를 정하고 선택해야 합니다.

다만 지금 빠르게 구현하기 위해 내린 선택이 이후 어떤 문제와 비용으로 돌아올지는 미리 생각해야 했습니다.

2월에는 코드를 작성하는 시간만큼, 이런 선택의 기준을 고민하는 데 많은 시간을 사용했습니다.

---

코드를 짜기 전에 기준부터 만들어야 했습니다

제품 구조를 다시 살펴보면서 운영 방식도 함께 정리해야 했습니다.

기능이 어떤 범위에 적용되는지, 서로 다른 설정이 겹쳤을 때 무엇을 우선할지, 사용자마다 다른 환경과 예외 상황을 어떻게 처리할지 기준이 필요했습니다.

화면을 만들려고 했는데 먼저 제품이 어떻게 동작해야 하는지를 정해야 했습니다.

버튼을 추가하려고 했는데 그 버튼이 어떤 상황에서 보여야 하는지부터 결정해야 했습니다.

상태를 표시하려고 했는데 어떤 조건을 정상으로 보고, 어떤 조건을 예외로 처리할지도 정리해야 했습니다.

개발을 시작하려고 할수록 기획 문서가 계속 늘어났습니다.

이때 과거의 제가 했던 생각을 반성했습니다.

“요구사항만 잘 정리하면 되는 거 아닌가?”

아니었습니다.

요구사항을 잘 정리하는 일이 가장 어려웠습니다.

사용자가 “조금 더 쉽게 사용할 수 있게 해주세요”라고 말하면, 개발자는 처음에는 화면이나 버튼을 하나 바꾸면 될 것 같다고 생각합니다.

하지만 실제로는 수많은 질문이 따라왔습니다.

어떤 상황에서 필요한 기능인지, 기존 방식과 무엇이 달라져야 하는지, 예외 상황에서는 어떻게 동작해야 하는지, 변경된 결과를 어디까지 유지해야 하는지 모두 결정해야 했습니다.

짧은 요구사항 하나가 새로운 기능 하나로 끝나는 것이 아니라, 새로운 흐름과 예외 상황을 함께 만들었습니다.

기획자가 하는 일은 단순히 화면을 그리는 것이 아니었습니다.

애매한 상황마다 기준을 만들고, 서로 충돌하는 요구사항 사이에서 우선순위를 정하는 일이었습니다.

코드는 잘못되면 오류라도 발생합니다.

정책과 흐름은 잘못 설계돼도 정상적으로 동작할 수 있습니다.

다만 사용자가 계속 불편할 뿐입니다.

오히려 더 무서운 문제였습니다.

2월에는 개발보다 제품의 시스템과 운영 흐름을 고민한 시간이 더 많았습니다.

회의를 하면 해야 할 일이 정리될 줄 알았습니다.

그런데 회의를 할수록 할 일이 늘어났습니다.

회의 전에는 기능 하나였는데, 회의가 끝나면 정상 상황과 실패 상황, 사용자 화면과 관리 화면, 기록과 예외 처리까지 여러 갈래로 나뉘어 있었습니다.

회의는 업무를 줄이는 자리가 아니었습니다.

그동안 보이지 않던 업무를 발견하는 자리였습니다.

이때 다시 한번 배웠습니다.

기획자를 쉽게 본 개발자의 최후는 직접 기획을 하게 되는 것입니다.

2월 말쯤에는 제품이 어떤 흐름으로 동작하고 운영되어야 하는지 조금씩 보이기 시작했습니다.

그리고 전체 흐름이 보이자 앞으로 해야 할 일도 함께 보였습니다.

모를 때가 조금 더 행복했습니다.

범위를 파악하니 무서워졌습니다.

---

3월

P2P가 대체 뭔데요?

프론트엔드도 통신 구조를 알아야 했습니다

3월부터는 P2P와 서버 통신 구조를 본격적으로 공부하기 시작했습니다.

처음 P2P라는 단어를 들었을 때는 알고 있다고 생각했습니다.

Peer to Peer.

기기나 사용자가 서로 연결되는 방식.

여기까지는 알고 있었습니다.

하지만 “우리 제품에서는 정확히 어떻게 동작하는데요?”라는 질문에는 대답할 수 없었습니다.

그래서 공부를 시작했습니다.

WebSocket과 SSE를 사용해본 경험은 있었지만, 여러 PC와 서버, 관리자 페이지, 로컬 엔진이 동시에 상태를 주고받는 구조는 생각보다 훨씬 복잡했습니다.

누가 연결을 시작해야 하는지, 연결이 끊기면 어느 쪽에서 복구해야 하는지, 사용자가 오프라인일 때 발생한 요청을 어떻게 처리할지 정해야 했습니다.

서버의 상태와 로컬의 상태가 다를 때 어느 쪽을 기준으로 화면을 보여줄지도 고민해야 했습니다.

처음에는 생각했습니다.

“P2P가 대체 뭐야?”

조금 공부한 뒤에는 생각했습니다.

“이걸 왜 프론트엔드가 알아야 하지?”

조금 더 공부한 뒤에는 알게 됐습니다.

프론트엔드도 알아야 하더라고요.

결국 사용자는 모든 결과를 화면에서 보기 때문입니다.

사용자가 보고 있는 연결 상태가 정확하려면 실제 통신 구조를 이해해야 했습니다. 연결이 끊겼을 때 어떤 기능을 제한하고 어떤 기능은 계속 사용할 수 있게 할지도 시스템의 상태를 알아야 결정할 수 있었습니다.

서버에서는 정상적으로 처리됐더라도 로컬 환경에 반영되지 않았다면 사용자 입장에서는 실패였습니다.

반대로 내부적으로는 처리가 완료됐어도 화면에 결과가 나타나지 않으면 사용자는 아무 일도 일어나지 않았다고 느낄 수 있었습니다.

이때 서버의 성공과 사용자의 성공은 다를 수 있다는 것을 많이 배웠습니다.

3월부터는 서버 개발자분과도 이야기를 자주 나눴습니다.

그러던 중 예상하지 못한 사실도 알게 됐습니다.

서버 개발자분의 지인 중 제 벨로그를 읽고 계신 분이 있다는 것이었습니다.

회사에 벨로그를 들켰습니다.

사실 숨긴 적은 없습니다.

그렇다고 보여드린 적도 없습니다.

공개된 블로그이니 누구나 볼 수 있지만, 실제로 아는 사람이 읽고 있다는 사실을 알게 되니 느낌이 완전히 달라졌습니다.

그전까지는 개발 중 겪었던 오류와 해결 과정을 비교적 편하게 적었습니다. 회사나 제품을 특정할 수 있는 내용은 제외하고, 제가 어떤 문제를 만났고 어떻게 해결했는지를 중심으로 기록했습니다.

하지만 회사 사람이 볼 수 있다고 생각하니 문장 하나하나가 신경 쓰이기 시작했습니다.

“이거 너무 힘들어 보이나?”

“회사에 대한 불만처럼 읽히지는 않을까?”

“이 내용을 보면 내부 구조를 유추할 수 있지 않을까?”

글을 쓰다가 지우기도 하고, 제목을 바꾸기도 했습니다. 작성해놓고 올리지 않은 글도 생겼습니다.

벨로그를 들킨 뒤 잠깐 주춤했습니다.

그래도 나쁜 일만 있었던 것은 아닙니다.

벨로그 이야기를 계기로 서버 개발자분과 더 편하게 대화하게 됐고, 서로 어떤 방식으로 공부하고 문제를 해결하는지도 나눌 수 있었습니다.

기술적인 협업뿐 아니라 개발자로서 어떤 고민을 하고 있는지도 자연스럽게 이야기하게 됐습니다.

---

화면 몇 개가 아니라 운영 생태계를 만들고 있었습니다

3월에는 제품의 운영 프로세스도 본격적으로 설계하기 시작했습니다.

이전까지는 시제품에 가까웠습니다.

필요한 기능을 구현하고, 내부 환경에서 실행해본 뒤, 시연까지 무사히 끝나면 어느 정도 목표를 달성한 셈이었습니다.

하지만 제품을 실제로 판매하고 운영하려고 하니 전혀 다른 세계가 열렸습니다.

먼저 고객이 제품을 확인하고 구매할 수 있는 페이지가 필요했습니다.

구매 이후에는 고객사가 제품을 설정하고 사용 현황을 확인할 수 있는 관리자 페이지가 필요했습니다. 사용자가 외부에서도 필요한 정보를 확인할 수 있도록 모바일 서비스도 연결해야 했습니다.

여기에 여러 고객사와 전체 서비스 상태를 관리하는 별도의 서비스 관리자 페이지까지 필요했습니다.

처음에는 기존 제품에 화면 몇 개만 추가하면 될 줄 알았습니다.

구매 화면 하나.

관리 화면 몇 개.

모바일 화면 조금.

정말 그 정도로 생각했습니다.

하지만 운영 흐름을 하나씩 정리해보니 구매 페이지, 고객사 관리자 페이지, 모바일 서비스, 서비스 관리자 페이지가 각각 필요했습니다.

화면 몇 개를 추가하는 수준이 아니었습니다.

제품을 하나 더 만드는 것도 아니었습니다.

하나의 제품이 실제로 판매되고, 설치되고, 사용되고, 관리되기 위해 필요한 전체 생태계를 만들고 있었습니다.

더 어려운 점은 각각의 서비스가 따로 움직이면 안 된다는 것이었습니다.

구매 페이지에서 만들어진 정보는 고객사 관리자 페이지와 연결되어야 했고, 고객사가 변경한 설정은 실제 제품에도 반영되어야 했습니다.

모바일 서비스와 서비스 관리자 페이지 역시 서로 다른 데이터를 바라보면 안 됐습니다.

서비스는 여러 개였지만, 데이터와 흐름은 하나로 이어져야 했습니다.

겉으로 보면 서로 다른 화면과 서비스였지만, 사용자에게는 결국 하나의 제품이었습니다.

이쯤 되니 개발 범위가 우후죽순으로 늘어난 이유도 이해할 수 있었습니다.

기능 하나를 추가하는 것이 아니라, 제품이 실제로 굴러가기 위해 필요한 앞뒤 과정을 전부 만들고 있었기 때문입니다.

처음에는 기능만 완성하면 제품이 되는 줄 알았습니다.

하지만 실제 운영에서는 구매 이후의 과정, 처음 사용하는 사람의 흐름, 고객사가 제품을 관리하는 방식, 전체 서비스를 운영하는 방식까지 함께 설계해야 했습니다.

화면을 만드는 것보다 화면과 화면 사이의 관계를 정하는 일이 더 어려웠습니다.

그때 생각했습니다.

“설마 이걸 제가 다 개발하는 건 아니겠지?”

물론 모든 코드를 혼자 작성한 것은 아니었습니다.

다만 시간이 지날수록 예상했던 것보다 훨씬 많은 영역이 제 업무 범위 안으로 들어오고 있었습니다.

3월의 저는 아직 그 사실을 정확히 모르고 있었습니다.

모를 때가 조금 더 평화로웠습니다.

---

4월

개발실 밖으로 나가니 제품이 다르게 보였습니다

개발 환경에서 잘되는 것만으로는 부족했습니다

4월에는 납품 예정인 고객사를 직접 방문했습니다.

실제 사용 환경을 점검하고, 제품을 사용할 분들의 요구사항을 직접 들었습니다.

개발실에서는 대부분의 조건이 개발자에게 유리하게 맞춰져 있습니다.

네트워크는 비교적 안정적이고, 필요한 권한도 있으며, 문제가 발생하면 바로 개발자 도구와 로그를 열어볼 수 있습니다.

설치 과정에서 오류가 발생해도 원인을 확인할 수 있고, 설정이 잘못됐다면 바로 수정할 수도 있습니다.

하지만 고객사의 환경은 달랐습니다.

운영체제의 버전도 달랐고, 네트워크 구성과 보안 정책도 달랐습니다. 이미 설치되어 있는 프로그램과 충돌할 가능성도 확인해야 했습니다.

개발 환경에서는 설치 파일을 실행하고 몇 번 클릭하면 끝났던 과정이, 고객사에서는 설치 파일을 전달하는 방식부터 달라질 수 있었습니다.

관리자 권한이 필요한지, 내부 네트워크에서 서버와 정상적으로 통신할 수 있는지, 기존 프로그램과 충돌하지 않는지 하나씩 확인해야 했습니다.

코드가 정상이라고 제품이 정상인 것은 아니었습니다.

설치되지 않으면 사용할 수 없었고, 설치되더라도 사용자가 사용 방법을 이해하지 못하면 제품의 역할을 다할 수 없었습니다.

사용자가 이해하더라도 운영하는 사람이 관리하기 어렵다면 오래 사용하기 힘들었습니다.

개발실에서는 기능이 정상적으로 동작하는지를 주로 확인했습니다.

하지만 고객사를 직접 방문한 뒤부터는 기능을 구현할 때 다른 질문도 함께 하게 됐습니다.

“이 제품을 처음 보는 사람도 이해할 수 있는가?”

“현재 상태에서 다음에 무엇을 해야 하는지 알 수 있는가?”

“문제가 생겼을 때 사용자가 혼자 해결할 수 있는가?”

“개발자가 옆에 없어도 계속 사용할 수 있는가?”

개발자에게는 익숙한 화면과 문구도 처음 사용하는 사람에게는 전혀 다르게 보일 수 있었습니다.

우리가 중요하게 생각한 기능보다 사용자는 설치 과정이나 버튼의 위치, 안내 문구를 더 크게 불편해하기도 했습니다.

기술적으로 복잡한 기능을 구현하는 것도 중요했지만, 사용자가 제품을 처음 접하는 순간부터 불편하지 않게 만드는 것도 제품의 완성도였습니다.

이때부터 단순히 “동작하는가?”만 확인하지 않고, “실제로 사용할 수 있는가?”를 함께 생각하게 됐습니다.

개발실 안에서 제품을 볼 때와 실제 사용 환경에서 제품을 볼 때는 시선이 달랐습니다.

개발실에서는 코드와 기능이 먼저 보였고, 현장에서는 사람과 환경이 먼저 보였습니다.

---

외주 개발에서 가장 어려운 것은 같은 결과를 상상하게 만드는 일이었습니다

이 시기에는 모바일 프로젝트의 외주 개발 관리도 맡았습니다.

외주 관리는 이번이 두 번째였습니다.

두 번째라면 조금은 익숙할 줄 알았습니다.

그렇지 않았습니다.

프로젝트가 달라지면 어려운 이유도 새로 생겼습니다.

이번에는 내부 구조를 모두 공개하기 어려운 상황에서, 외부 개발자가 필요한 기능을 정확히 구현할 수 있도록 설명해야 했습니다.

내부 정보는 보호해야 했지만, 개발에 필요한 내용은 충분히 전달해야 했습니다.

“내부 구조는 자세히 설명할 수 없지만, 기능은 정확하게 구현해주세요.”

이렇게 말해서는 당연히 원하는 결과가 나올 수 없었습니다.

그래서 외부에 전달해도 되는 정보와 그렇지 않은 정보를 나눴습니다.

내부 구조 자체를 설명하는 대신, 외부에서 필요한 인터페이스와 데이터 형식, 화면의 동작 규칙을 중심으로 문서를 작성했습니다.

정상적으로 동작하는 경우만 적어서도 부족했습니다.

응답이 늦을 때는 어떤 화면을 보여줘야 하는지, 사용 가능한 기능이 제한되는 상황에서는 어떻게 안내해야 하는지, 알림이나 데이터 수신에 실패했을 때는 어떤 상태로 처리해야 하는지도 정리했습니다.

처음에는 기능 목록과 화면 디자인만 전달하면 충분하다고 생각했습니다.

하지만 같은 문장을 읽어도 사람마다 완성된 모습을 다르게 상상할 수 있었습니다.

예를 들어 ‘로그인 기능 구현’이라는 한 문장만으로는 완료 기준을 알 수 없습니다.

화면만 만들어지면 완료인지, 실제 데이터 연결까지 포함하는지, 로그인 상태를 유지해야 하는지, 실패했을 때 안내 메시지도 보여줘야 하는지 모두 다르게 해석할 수 있었습니다.

결과물을 받은 뒤에 “제가 생각한 건 이게 아닌데요”라고 말하지 않으려면, 개발 전에 기준을 더 명확하게 정해야 했습니다.

입력값은 무엇인지, 어떤 결과가 나와야 하는지, 실패했을 때 어떻게 처리해야 하는지, 어느 상태까지 구현돼야 완료로 볼 수 있는지를 함께 전달해야 했습니다.

이 과정에서 외주 관리에서 가장 어려운 것은 개발을 대신할 사람을 찾는 일이 아니라는 것을 배웠습니다.

제가 머릿속으로 알고 있는 제품을 상대방도 같은 모습으로 상상할 수 있도록 만드는 일이 가장 어려웠습니다.

문서를 길게 작성한다고 항상 정확한 것은 아니었습니다.

설명이 많아도 해석할 수 있는 방향이 여러 개라면 결과도 여러 개가 나왔습니다.

반대로 문장이 짧더라도 조건과 결과, 완료 기준이 명확하면 서로 같은 방향을 바라볼 수 있었습니다.

좋은 문서는 많은 내용을 담은 문서가 아니라, 서로의 해석 차이를 줄여주는 문서였습니다.

4월에는 직접 코드를 작성하는 것만큼, 다른 사람이 정확한 코드를 작성할 수 있도록 설명하는 일도 중요하다는 것을 배웠습니다.

그리고 제품을 잘 만드는 것만큼, 제품을 사용하는 사람과 함께 만드는 사람이 같은 모습을 바라보게 하는 일도 중요했습니다.

---

5월

아직은 각자의 자리에서 평화로웠습니다

외주 개발을 관리하며 각자의 개발을 마무리했습니다

5월에는 외주로 진행 중이던 모바일 프로젝트를 계속 관리하면서, 제가 담당한 개발도 하나씩 마무리하고 있었습니다.

외주 개발은 직접 코드를 작성하는 것과는 또 다른 어려움이 있었습니다. 제가 머릿속으로 이해하고 있는 기능을 상대방도 같은 모습으로 이해할 수 있도록 설명해야 했고, 화면이 보이는 것만으로 완료라고 볼 수 있는지, 실제 데이터 연결과 예외 처리까지 포함해야 하는지 기준도 명확하게 전달해야 했습니다.

처음 외주 관리를 맡았을 때는 요구사항을 자세히 적으면 충분할 것이라고 생각했습니다.

하지만 ‘자세한 문서’와 ‘정확한 문서’는 달랐습니다.

설명이 길어도 해석할 수 있는 방향이 여러 개라면 결과도 여러 개가 나왔습니다. 반대로 문장이 짧더라도 입력값과 결과, 예외 상황, 완료 기준이 명확하면 서로 같은 결과를 바라볼 수 있었습니다.

5월에는 전달받은 결과물을 확인하고, 실제 동작과 예상한 흐름이 다른 부분을 정리해 다시 전달하는 일을 반복했습니다.

예전에는 문제가 보이면 바로 코드를 열어 확인했습니다. 외주 프로젝트에서는 제가 직접 코드를 고치는 대신, 어떤 조건에서 문제가 발생했고 기대한 결과와 실제 결과가 어떻게 다른지 설명해야 했습니다.

덕분에 적어도 스크린샷 한 장과 함께 “여기 이상해요”라고 보내는 사람에서는 조금 벗어난 것 같습니다.

회사 프로젝트에서는 제가 담당한 영역을 중심으로 개발을 이어갔습니다.

당시에는 역할이 어느 정도 나뉘어 있었습니다. 각자 맡은 기능을 개발하고, 마지막에 서로 연결하면 제품이 완성될 것이라고 생각했습니다.

각자의 개발 환경에서는 기능이 잘 동작했습니다.

제가 만든 부분도 동작했고, 다른 영역도 각자의 기준에서는 정상적으로 진행되고 있었습니다. 화면도 하나씩 완성되고 있었고, 일정도 생각보다 크게 밀리지 않는 것처럼 보였습니다.

그래서 5월에는 비교적 편안한 마음으로 제가 맡은 개발에 집중했습니다.

“이 정도면 일정에 맞출 수 있겠는데?”

당시에는 그렇게 생각했습니다.

물론 지금 생각하면 통합 테스트도 시작하지 않은 개발자의 순진한 자신감이었습니다.

각자의 영역에서 잘 동작하는 것과, 모든 영역을 연결했을 때 하나의 제품으로 잘 동작하는 것은 완전히 다른 문제였습니다.

하지만 5월의 저는 아직 그 사실을 온몸으로 경험하기 전이었습니다.

서로 다른 영역에서 사용하는 데이터의 기준과 상태가 완전히 같은지, 한쪽에서 변경된 값이 다른 쪽에는 언제 반영되는지, 실패했을 때 어느 영역에서 책임져야 하는지까지는 충분히 확인하지 못했습니다.

통합 전에는 모두가 자신의 환경에서 정상입니다.

통합을 시작하는 순간, 각자가 생각하는 ‘정상’이 얼마나 달랐는지 알게 됩니다.

그 사실을 몰랐던 5월은 비교적 평화로웠습니다.

개발 공부 대신 주식 공부에 빠졌습니다

그리고 이 시기에는 개발 공부보다 주식에 조금 더 관심을 두고 있었습니다.

마침 시장 분위기도 괜찮았고, 초반에는 수익도 조금 생겼습니다. 차트를 보고 관련 뉴스를 찾아보는 일이 생각보다 재미있었습니다.

개발하다가 오류를 만나면 로그를 보고, 퇴근 후에는 주식 차트를 봤습니다.

어느 순간부터는 기술 문서보다 기업 뉴스를 더 많이 읽고 있었습니다.

수익이 생기니 자신감도 같이 생겼습니다.

“혹시 개발 외에 새로운 재능을 발견한 건 아닐까?”

잠깐은 정말 그렇게 생각했습니다.

개발자로 일한 지도 2년 정도가 지나면서 업무에 익숙해졌고, 처음처럼 퇴근 후 매일 새로운 기술을 찾아보지는 않게 됐습니다. 회사에서 하루 종일 개발하고 있으니 별도의 공부를 조금 쉬어도 괜찮다고 생각했습니다.

그 빈자리를 자연스럽게 주식 공부가 채웠습니다.

돌이켜보면 이 시기의 수익은 실력보다는 시장 분위기와 운에 가까웠던 것 같습니다.

하지만 사람은 수익이 날 때는 자신이 운이 좋다고 생각하지 않습니다.

분석을 잘했다고 생각합니다.

5월의 저는 아직 금융에 새로운 가능성이 있다고 믿고 있었습니다.

그리고 회사 프로젝트 역시 제가 맡은 영역만 잘 마무리하면 된다고 생각했습니다.

두 가지 생각 모두 6월에 조금 달라지게 됩니다.

---

6월

통합을 시작하자 평화가 끝났습니다

6월에는 통합 테스트를 준비하며 그동안 각자 개발한 영역을 하나의 흐름으로 연결하기 시작했습니다.

5월까지는 개별 기능들이 각자의 환경에서 잘 동작하고 있었습니다. 그래서 마지막에 연결만 하면 자연스럽게 하나의 제품이 될 것이라고 생각했습니다.

하지만 실제로 연결하기 시작하자 이전에는 보이지 않던 문제들이 하나씩 나타났습니다.

한쪽에서 변경한 정보가 다른 영역에는 예상한 시점에 반영되지 않거나, 같은 상태를 서로 다르게 해석하는 경우가 있었습니다.

각 기능은 분명 정상적으로 동작했습니다.

다만 함께 동작하는 방식은 충분히 정리되지 않은 상태였습니다.

개별 기능의 성공과 전체 제품의 성공은 달랐습니다.

한 영역에서 요청을 정상적으로 처리했다고 해도, 최종 결과가 다른 영역까지 이어지지 않으면 사용자에게는 실패였습니다. 반대로 내부적으로는 처리가 끝났지만 화면에 적절한 상태가 표시되지 않으면 사용자는 아무 일도 일어나지 않았다고 느낄 수 있었습니다.

통합 테스트는 이미 만든 기능이 잘 동작하는지 확인하는 과정이라고 생각했습니다.

실제로는 각자가 만든 기능이 같은 세계관 안에 존재하는지 확인하는 과정에 가까웠습니다.

그리고 생각보다 세계관이 잘 맞지 않았습니다.

처음에는 데이터 연결 몇 군데와 화면 일부를 수정하면 해결될 것이라고 생각했습니다.

그런데 문제를 하나씩 따라가다 보니 단순한 화면 문제가 아니었습니다.

화면이 복잡하게 느껴지는 이유는 디자인이 복잡해서가 아니라, 제품의 흐름과 각 영역의 관계가 화면에 충분히 정리되지 않았기 때문이었습니다.

결국 관리 영역의 화면과 구조도 다시 살펴봐야 했습니다.

원래는 서버 개발자분이 담당하고 있던 부분이었지만, 통합 과정에서 사용자 흐름과 화면 전반을 다시 정리할 필요가 생겼습니다.

그렇게 관리 페이지가 제게 돌아왔습니다.

제가 맡겼던 것은 아니었지만, 어쨌든 돌아왔습니다.

처음에는 기존 화면의 배치와 문구를 조금 수정하면 될 줄 알았습니다.

그렇지 않았습니다.

화면을 바꾸려면 사용자가 어떤 순서로 서비스를 이용해야 하는지부터 다시 확인해야 했고, 그 흐름을 정리하려면 서버와 다른 영역이 어떤 상태를 공유하는지도 알아야 했습니다.

관리 화면 하나를 수정하려고 시작했는데 다른 영역의 동작까지 다시 확인하고 있었습니다.

처음 열었던 파일과 전혀 다른 위치에서 원인을 발견하는 일도 많았습니다.

화면에서 이상한 점을 발견해 따라가 보면 데이터 흐름의 문제였고, 데이터 흐름을 확인하다 보면 처음 정한 운영 기준이 모호한 경우도 있었습니다.

프론트엔드의 문제처럼 보였지만 프론트엔드만 수정해서는 해결되지 않았습니다.

이때부터 제가 담당하는 범위도 빠르게 넓어졌습니다.

기존 개발을 진행하면서 관리 화면의 구조를 다시 정리했고, 외부에서 전달받은 결과물도 확인했습니다. 통합 테스트를 준비하고, 고객에게 전달할 문서와 매뉴얼도 함께 작성했습니다.

개발하다가 문서를 쓰고, 문서를 작성하다가 화면을 수정하고, 화면을 수정하다가 다시 로그를 확인했습니다.

오전에는 개발자였고, 오후에는 기획을 정리했으며, 저녁에는 테스트 담당자가 되어 있었습니다.

다양한 직무를 경험할 수 있었습니다.

물론 체험을 신청한 적은 없습니다.

기능을 구현하는 것과 사용자가 실제로 사용할 수 있도록 만드는 것이 다르다는 점도 다시 느꼈습니다.

개발자는 이미 제품 구조를 알고 있기 때문에 짧은 단어나 버튼만 봐도 의미를 이해합니다. 하지만 처음 접하는 사람에게는 현재 상태와 다음 행동이 명확하지 않을 수 있습니다.

그래서 단순히 화면에 상태를 보여주는 것에서 끝내지 않고, 처음 사용하는 사람도 전체 흐름을 이해할 수 있도록 화면 순서와 안내 문구를 다시 살펴봤습니다.

이 시기에는 프론트엔드 개발자가 단순히 화면을 그리는 사람이 아니라, 여러 시스템에 흩어진 정보를 사용자가 이해할 수 있는 언어로 번역하는 사람이라는 생각을 많이 했습니다.

서버와 여러 영역의 상태를 하나의 화면으로 정리하고, 개발팀 내부에서만 이해하던 흐름을 사용자가 따라갈 수 있는 경험으로 만드는 것도 프론트엔드의 역할이었습니다.

---

금융 천재의 꿈도 6월에 끝났습니다

업무가 본격적으로 바빠진 것과 비슷한 시기에 주식 수익도 줄어들기 시작했습니다.

4월과 5월에는 수익이 조금 생기면서 제가 기업 분석에 재능이 있는 줄 알았습니다.

6월에는 아니었다는 것을 알게 됐습니다..

뭐,, 유럽여행 다녀왔다 친거죠

개발에서는 문제가 발생하면 로그를 확인할 수 있습니다.

어떤 함수에서 오류가 발생했는지, 어떤 값이 예상과 달랐는지 확인하고 수정할 수 있습니다.

주식에는 로그가 없었습니다.

가격이 내려가도 오류 메시지가 나타나지 않았고, 새로고침을 해도 원래 값으로 돌아오지 않았습니다.

이미 체결된 주문에는 Ctrl+Z도 없었습니다.

그제야 개발이 생각보다 친절한 분야라는 것을 알게 됐습니다.

적어도 코드는 제가 틀렸다는 사실을 명확하게 알려줍니다. 시장은 별다른 설명 없이 제 돈을 가져갔습니다.

그렇게 짧았던 금융 천재의 꿈은 끝났고, 저는 다시 개발에 집중하게 됐습니다.

개발에 대한 뜨거운 열정이 저를 돌아오게 한 것은 아니었습니다.

손실이었습니다.

그래도 돌아왔으니 됐습니다.

주식 공부를 완전히 그만둔 것은 아니지만, 적어도 개발 공부보다 더 열심히 하지는 않기로 했습니다.

시장이 이미 충분한 수업료를 받아갔기 때문입니다.

---

새 기술이 나왔는데 저장만 해뒀습니다

6월에는 Claude 쪽에서 fable이라는 새로운 기술도 공개됐습니다.

새로운 기술이나 도구가 등장하면 일단 사용해보고, 기존 방식과 어떤 차이가 있는지 확인하는 것을 좋아합니다. 평소 같았으면 관련 자료를 찾아보고 작은 예제라도 만들어봤을 것 같습니다.

이번에도 소개를 보자마자 흥미가 생겼습니다.

관련 내용을 찾아봤고, 나중에 사용해보려고 저장도 해뒀습니다.

그리고 저장한 것으로 끝났습니다.

새로운 기술이 나왔는데 직접 실행해보지도 못할 정도로 바빴습니다.

다른 사람들이 먼저 사용해본 결과를 보면서 저도 나중에 써봐야겠다고 생각했습니다. 하지만 통합 테스트 준비와 기존 개발, 화면 수정, 문서 작업이 계속 이어지면서 그 ‘나중’은 계속 뒤로 밀렸습니다.

배우고 싶은 것이 없어서 공부하지 않은 것은 아니었습니다.

새로운 것을 시작하기 전에 이미 벌여놓은 일을 끝낼 시간이 필요했습니다.

6월은 새로운 기술을 많이 배운 달이라기보다, 새로운 기술을 살펴볼 여유도 없이 현재의 제품을 완성하는 데 집중한 달에 가까웠습니다.

fable은 여유가 생기면 제대로 사용해보고 싶습니다.

그 여유가 언제 생길지는 아직 모르겠습니다.

---

예상하지 못한 연락도 받았습니다

정신없이 일하던 중 벨로그를 통해 예상하지 못한 연락도 받았습니다.

작성한 글을 보고 서비스 후기를 작성해달라는 제안이 왔고, 별도로 함께 프로젝트를 진행해보자는 연락도 받았습니다.

처음에는 조금 신기했습니다.

벨로그는 제가 해결한 방법을 다시 잊지 않기 위해 시작했습니다. 며칠 동안 어렵게 해결한 문제도 시간이 지나면 방법을 잊어버렸고, 몇 달 뒤 같은 문제를 만났을 때 다시 처음부터 찾아보는 일이 반복됐기 때문입니다.

미래의 저를 위해 남긴 메모에 가까웠습니다.

그런데 제가 작성한 글과 프로젝트를 보고 누군가 제 의견을 듣고 싶어 하거나 함께 무언가를 만들어보고 싶다고 연락해준다는 것이 감사했습니다.

제안받은 서비스도 충분히 사용해본 뒤 개발자의 시선에서 솔직하게 리뷰해보고 싶었습니다. 프로젝트 제안 역시 어떤 것을 만들려는지 자세히 이야기해보고 싶은 마음이 있었습니다.

하지만 당시에는 새로운 일을 시작할 수 있을 만큼 시간과 체력이 남아 있지 않았습니다.

서비스를 잠깐 사용한 뒤 형식적인 후기를 작성하고 싶지 않았고, 외부 프로젝트를 무리해서 시작했다가 회사 일과 새로운 프로젝트 양쪽 모두 제대로 마무리하지 못할 것 같았습니다.

결국 두 제안 모두 참여하지 못했습니다.

좋은 기회를 놓친 것 같아 아쉬웠지만, 제가 남긴 기록이 누군가에게 닿고 있다는 사실은 다시 벨로그를 꾸준히 작성해야겠다는 동기가 됐습니다.

회사에서 제 벨로그를 알고 있다는 사실을 알게 된 뒤 한동안 글을 쓰는 것이 조심스러웠습니다. 민감한 내용이 드러나지 않는지, 회사에 대한 불만처럼 읽히지는 않는지 계속 신경 쓰다 보니 기록 자체를 미루기도 했습니다.

하지만 기록하지 않으면 몇 달 동안 고민했던 일도 결국 “그때 뭔가 어려웠다”는 한 문장으로만 남았습니다.

처음에는 어떤 방식으로 접근했고, 왜 잘되지 않았으며, 결국 어떤 기준으로 구조를 변경했는지를 남겨야 경험도 제대로 쌓인다는 생각이 들었습니다.

앞으로는 내부 정보는 제외하면서도 제가 어떤 문제를 만났고 어떤 판단을 내렸는지는 계속 기록해보려고 합니다.

완성된 결과만 보여주는 글보다, 실패했던 접근과 수정한 이유까지 함께 보여주는 글을 쓰고 싶습니다.

---

상반기를 돌아보며

2026년 상반기에는 새로운 프론트엔드 라이브러리보다 하나의 제품이 실제 사용자에게 전달되기 위해 필요한 것들을 더 많이 배웠습니다.

화면이 잘 동작하는 것은 끝이 아니었습니다.

화면에서 보낸 요청이 서버에 저장되어야 했고, 처리 결과는 다시 에이전트와 엔진에 적용되어야 했습니다. 그 상태가 사용자 화면에도 정확히 표시되어야 했습니다.

이 중 하나라도 실패하면 사용자는 전체 기능이 실패했다고 느낍니다.

이전에는 사용자 경험을 주로 화면 안에서 생각했습니다.

이제는 설치 파일을 받고 프로그램을 실행하는 순간부터, 연결이 끊겼을 때 복구되는 과정과 관리자가 승인하는 순서까지 모두 사용자 경험이라고 생각합니다.

상반기에는 이런 복잡한 시스템을 이해할 수 있는 형태로 번역하는 일을 많이 했습니다.

엔진의 상태를 문구로 바꾸고, 서버의 권한 구조를 화면으로 옮겼습니다. 운영 정책을 관리자 페이지의 순서로 만들고, 내부 아이디어를 외주 개발자가 이해할 수 있는 문서로 정리했습니다.

처음에는 개발과 조금 떨어진 일이라고 생각했지만, 결국 제품을 완성하기 위해 모두 필요한 과정이었습니다.

---

조금 솔직한 상반기 평가

상반기 내내 성실하게 공부한 것은 아닙니다.

개발 공부가 느슨해진 시기도 있었고, 주식으로 잠깐 돈을 벌고 새로운 재능을 발견한 줄 착각하기도 했습니다.

회사에 벨로그를 들킨 뒤 글쓰기가 조심스러워졌고, 좋은 제안을 받았지만 여유가 없어 놓친 기회도 있었습니다.

그래도 완전히 멈추지는 않았습니다.

익숙하지 않은 엔진 통신을 공부했고, 제품 구조를 다시 설계했습니다. 고객사의 환경을 확인하고 외부 개발자와 협업하기 위한 문서를 만들었습니다.

관리자 페이지와 에이전트, 서버, 엔진을 하나의 흐름으로 연결하며 문제를 바라보는 범위도 넓어졌습니다.

예전에는 화면에 문제가 생기면 컴포넌트와 상태부터 확인했습니다.

이제는 서버 데이터, 엔진 연결, 사용자 권한, 운영 순서까지 함께 확인합니다.

알아야 할 것이 늘어난 만큼 오히려 더 조심스러워졌습니다.

예전에는 모르는 것이 적어서 자신감이 있었고, 지금은 고려해야 할 것이 많다는 사실을 알아서 신중해졌습니다.

이것도 성장이라고 생각합니다.

이 시기에는 몇몇 회사에 지원서를 넣으며 현재 제 상태도 함께 점검했습니다.

저는 도태되고 있다는 감각을 가장 싫어합니다.

한 환경에서 오래 일하면 제가 실제로 성장한 것인지, 단순히 현재 업무에 익숙해진 것인지 구분하기 어려울 때가 있습니다.

지원서를 작성하면서 그동안 했던 일을 다시 정리했습니다. 어떤 기술을 사용했는지 나열하는 것보다, 왜 구조를 변경했고 어떤 문제를 해결했으며 그 과정에서 제가 담당한 범위가 어디까지였는지를 설명해야 했습니다.

아직 지원한 곳이 아주 많지는 않았지만 서류 합격률은 약 60~70% 정도였습니다.

이 수치가 제 실력을 완전히 증명한다고 생각하지는 않습니다. 회사마다 필요한 경험이 다르고, 채용 시기와 지원자 구성에 따라서도 결과가 달라지기 때문입니다.

그래도 지금까지 쌓아온 경험이 외부에서도 완전히 의미 없는 것은 아니라는 작은 확인은 됐습니다.

아직은 잘 살아가고 있는 것 같았습니다.

그래서 하반기에는

상반기가 끝났다고 일이 잠잠해지지는 않았습니다.

7월에는 해커톤 준비와 회사 일정이 겹쳤고, 여기에 주말 출근과 야근까지 이어졌습니다. 상반기 회고를 쓰려고 몇 번이나 메모장을 열었지만, 글을 쓰기 전에 당장 처리해야 할 일이 계속 생겼습니다.

퇴근 후에는 해커톤 지원서를 다듬고, 프로젝트 아이디어와 역할을 정리했습니다. 회사에서는 통합 테스트와 납품 준비가 본격적으로 시작됐고, 평일에 끝내지 못한 일은 자연스럽게 주말까지 따라왔습니다.

7월은 개발도, 해커톤 준비도, 체력 관리도 모두 놓치고 싶지 않아 욕심을 냈던 달이었습니다. 결과적으로 무엇 하나 가볍게 지나가지는 않았습니다.

상반기는 제품의 구조와 운영을 배우는 시간이었다면, 7월은 그동안 준비한 것들을 실제 일정 안에서 버텨내는 시간이었던 것 같습니다.

자세한 이야기는 하반기 회고에서 풀어보려고 합니다. 아직 8월이 되지는 않았지만, 그때는 조금 더 긍정적인 이야기를 적을 수 있으면 좋겠습니다.

“7월에는 정말 힘들었지만, 그래도 결국 잘 마무리했다.”

다음 회고에서는 이렇게 쓸 수 있기를 기다려봅니다.

2026년 상반기는 프론트엔드 개발자로서 제가 바라보는 범위가 가장 많이 넓어진 시간이었습니다. 화면을 만드는 것에서 시작해 화면 뒤의 서버와 엔진을 이해하게 됐고, 제품이 설치되고 운영되는 과정까지 고민하게 됐습니다.

제품을 완성한다는 것은 기능을 모두 만드는 것이 아니라, 각 기능이 사용자에게 하나의 경험으로 이어지게 만드는 일이다.

그리고 개발자는 코드를 작성하는 사람이기도 하지만, 복잡한 문제 사이에서 기준을 만들고 끝까지 연결하는 사람이기도 합니다.

지금도 일정과 오류, 예상하지 못한 요구사항 사이에서 버티고 있는 개발자분들이 많을 것 같습니다. 개발하다 보면 분명 어제까지 잘되던 기능이 갑자기 안 되고, 거의 끝났다고 생각한 순간 새로운 요구사항이 들어오기도 합니다.

왜 그런 일이 계속 생기는지는 저도 알고 싶지 않습니다.

그래도 결국 하나씩 원인을 찾고, 다시 연결하고, 어떻게든 다음 단계로 넘어가게 되는 것이 개발자의 일인 것 같습니다.

조금 지쳤더라도 우리가 못하고 있어서 힘든 것만은 아닐 겁니다. 책임지는 범위가 넓어지고, 해결해야 하는 문제가 어려워졌기 때문에 힘든 순간도 분명 있을 테니까요.

이상으로 많이 늦은 2026년 상반기 회고를 마치겠습니다.

8월에는 조금 더 여유롭고 긍정적인 회고를 쓸 수 있기를 바라며,

오늘도 각자의 자리에서 버티고 있는 지친 개발자분들, 모두 파이팅입니다.