첫번째 고민

개발자가 기획을 하고, 디자이너가 코드를 작성하고, 이제는 비개발자도 서비스를 만들어내는 시대가 되었다.
이런 변화를 보면서 자연스럽게 한 가지 고민으로 이어졌다.

“그렇다면 개발자인 나는 어떤 역량을 더 키워야 할까?”
그리고 더 나아가,
“내가 가져가야 할 역량의 범위는 어디까지 확장되어야 하는 걸까?”

단순히 기술을 더 잘하는 것만으로 충분한 시대인지,
아니면 문제를 정의하고 제품을 만들어내는 전반적인 능력까지 가져가야 하는지,
기준이 명확하지 않은 상태에서 방향을 잡기가 쉽지 않았다.

한편으로는 또 다른 고민도 있었다.
AI와 관련된 정보들이 하루에도 수없이 쏟아지는 환경 속에서,
각자 다른 방식으로 성과를 내고 있는 사람들을 보며
“과연 나는 어떤 정보를 선택해서 따라가야 할까?”라는 질문을 계속하게 됐다.

모든 정보가 다 맞는 것처럼 보이지만, 동시에 누구에게나 정답이 될 수는 없는 상황.
결국 나에게 맞는 기준을 스스로 만들어야 한다는 생각이 들었고,
그 과정에서 들었던 몇 가지 발표들이 이 고민을 정리하는 데 큰 도움이 됐다.

첫 번째로 인상 깊었던 발표는
David McLaughlin의 세션이었다.

이 발표에서는 “좋은 소프트웨어란 무엇인가”라는 질문을 AI 시대의 관점에서 다시 짚어주고 있었다.
단순히 코드를 잘 작성하는 것을 넘어, 제품(Product), 디자인, 비즈니스, 그리고 데이터까지
여러 요소가 유기적으로 결합되어야 비로소 좋은 소프트웨어가 만들어진다는 이야기였다.

특히 인상 깊었던 부분은,
AI 시대가 되면서 개발 방식 자체가 바뀌고 있다는 점이었다.

과거에는 코드 작성 능력 자체가 핵심 경쟁력이었다면,
이제는 AI를 통해 코드 생산 비용이 크게 낮아지면서
“무엇을 만들 것인가”, “어떤 문제를 풀 것인가”, “어떤 맥락에서 동작하게 할 것인가”가
더 중요한 요소로 바뀌고 있었다.

즉, 개발자의 역할이 단순히 구현하는 사람에서
문제를 정의하고, 적절한 맥락과 데이터를 설계하는 사람으로 확장되고 있는 것이다.

또 하나 강조되었던 것은 데이터와 맥락(Context)의 중요성이었다.
아무리 뛰어난 모델을 사용하더라도 입력되는 데이터가 부정확하거나
문제 상황에 대한 맥락이 충분히 전달되지 않으면 결과 역시 한계가 있을 수밖에 없다.

결국 좋은 결과를 만들어내는 것은 모델 자체가 아니라,
그 모델을 어떻게 활용하고 어떤 환경 위에서 동작하게 하느냐에 달려 있다는 점이었다.

또 하나 인상 깊었던 발표는
업스테이지에서 오신 백수영님의 세션이었다.

“왜 조직은 작아지고 점점 더 빨라지고 있는가”라는 주제로,
AI 시대에 변화하고 있는 업무 방식에 대해 이야기해주셨다.

기존의 개발 방식은 기획, 디자인, 개발, QA처럼
각 역할이 명확히 나뉘어 있고 단계적으로 진행되는 구조였다.
하지만 이 방식은 AI 시대에 들어서면서 한계를 드러내고 있다고 지적했다.

기능을 만드는 속도는 빨라졌지만,
사람 간의 전달과 조율 과정에서 오히려 병목이 발생하고,
전체 속도는 기대만큼 빨라지지 않는다는 것이다.

이 문제를 해결하기 위해 업스테이지에서는
한 사람이 하나의 영역을 처음부터 끝까지 책임지는 방식으로
업무 구조를 변화시키고 있다고 한다.

단순히 개발만 하는 것이 아니라,
기획과 설계, 구현까지 하나의 흐름 안에서 직접 담당하는 구조다.

이 발표들을 통해 느낀 것은,
AI 시대의 개발자는 단순히 기술을 잘 다루는 것을 넘어
전체 흐름을 이해하고 설계할 수 있는 시야를 가져야 한다는 점이었다.

자연스럽게 한 가지 질문으로 이어졌다.
“그렇다면 이런 시야를 어떻게 키울 수 있을까?”

생각해보니 단순히 글을 읽거나 강의를 듣는 것만으로는 한계가 있을 것 같았다.
결국 직접 부딪혀보지 않으면 알 수 없는 영역이라는 생각이 들었다.

마침 나는 새로운 서비스를 하나 만들어볼 계획을 가지고 있었다.
기획부터 디자인, 개발까지 모든 과정을 직접 경험하며 서비스를 출시해보는 것.

이 과정을 통해 단순히 기능을 구현하는 것을 넘어,
문제를 정의하고, 방향을 설정하고, 실제 사용자에게 전달되는 전체 흐름을 고민해볼 수 있겠다는
생각이 들었다.

또한 개발자로서 실제 고객을 대상으로 서비스를 운영해보는 경험은,
나만의 기준과 철학을 만들어가고
그동안 쌓아온 역량을 더 깊이 있게 키우고 증명할 수 있는 기회가 될 것 같다는 생각이 들었다.

결국 이런 경험들이 쌓이면서
단순히 기능을 구현하는 개발자가 아니라,
문제 해결과 서비스 전체를 고민할 수 있는 개발자로 성장해 나갈 수 있을 것이라는 기대가 생겼다.

두번째 고민

현재 나는 퀘스티란 서비스를 맡아
신규 기능 개발과 유지보수를 함께 담당하고 있으며,
인력 부족으로 프론트엔드 영역을 거의 혼자 책임지고 있다.

우리 팀은 기능을 빠르게 개발해 고객 반응을 보고,
그에 맞춰 지속적으로 수정해 나가는 방식으로 서비스를 발전시키고 있다.

하지만 이 과정에서 기획과 정책이 자주 변경되면서
문서화가 제대로 이루어지지 않았고,
관련 히스토리 또한 여러 곳에 흩어져 있는 상태가 되었다.

그 결과, 코드에는 의도를 파악하기 어려운 부분과
불필요한 로직들이 점점 쌓여가고 있었다.

문제는 이런 상태에서 장애나 이슈가 발생했을 때다.
현재 구조에서는 원인을 파악하는 데부터 많은 시간이 소요되며,
빠르게 대응하기보다는 오히려 해결이 지연될 가능성이 크다.

더욱이 나 역시 모든 코드의 맥락을 완벽히 이해하고 있는 상태가 아니기 때문에,
이 상황은 단순한 불편함이 아니라 구조적인 리스크라고 느껴졌다.

그래서 이 문제를 어떻게 해결할 수 있을지에 대해
생각하는 시간이 점점 많아졌다.

처음에는 AI를 활용해 개인적으로 정리하거나 자동화하는 방법을 떠올리기도 했다.
하지만 곧 한 가지 생각에 도달했다.

나는 단순히 개발자가 아니라,
이 팀에 속한 한 명의 동료라는 점이었다.

이 문제를 혼자 해결한 뒤
“이렇게 만들어놨으니 이렇게 사용해주세요”라고 전달하는 방식보다는,

“이런 문제가 있어서 이런 방식으로 정리해보려고 하는데 어떻게 생각하시나요?”
라는 질문을 계속 던지며
팀원들과 함께 우리에게 맞는 업무 프로세스를 만들어가는 것이 더 중요하다고 느꼈다.

그렇다면 결국 남는 질문은 하나였다.
“그래서 어떻게 해야 할까?”

요즘은 다양한 회사에서 각자의 방식으로
효율적인 개발 방법론이나 프로세스를 공유하고 있다.

하지만 단순히 “이게 좋다”는 이유만으로 가져오는 것이 아니라,
그 방식이 우리 팀의 상황과 구조에서도 실제로 잘 동작할 수 있는지에 대해
한 번 더 고민해볼 필요가 있다고 생각했다.

이런 고민을 가지고 발표를 들으러 갔고,
그 자리에서 이경록 CEO의 세션을 들을 수 있었다.

요즘 가장 많이 언급되는 주제 중 하나인 하네스 엔지니어링(Harness Engineering)에 대한 내용이었는데,
이 개념을 단순한 트렌드가 아니라 실제 개발 방식의 변화로 설명해주셨던 점이 인상 깊었다.

발표 내용을 간단히 정리해보면,
기존에는 우리가 AI를 사용할 때 프롬프트를 잘 작성하는 것에 집중했다면,
그 이후에는 RAG나 메모리, 툴을 활용하는 컨텍스트 엔지니어링으로 발전해왔다.

하지만 이 방식의 한계는 분명했다.
아무리 컨텍스트를 잘 구성하더라도 구조 자체가 정적이기 때문에
결과가 지속적으로 개선되기 어렵고, 결국 사람의 개입에 의존할 수밖에 없다는 점이었다.

그래서 등장한 개념이 하네스 엔지니어링이다.

핵심은 단순히 입력을 잘 넣는 것이 아니라,
결과를 기반으로 시스템 자체를 계속 수정하고 발전시키는 구조를 만드는 것이다.

예를 들어 기존에는 결과가 잘못 나오면
프롬프트를 다시 수정하는 방식이었다면,

하네스에서는 어떤 결과가 잘못되었는지 판단하고
그 원인을 룰이나 검증 로직에서 찾아내고
그 로직 자체를 수정해서 다음에는 같은 문제가 발생하지 않도록 만드는 구조를 만든다

즉, 결과를 고치는 것이 아니라
결과를 만들어내는 시스템을 개선하는 방식이라고 볼 수 있었다.

이 구조는 특히 여러 단계로 이루어진 작업이나
장기적으로 반복되는 작업에서 점점 더 큰 효과를 낼 수 있다고 설명해주셨다.

그리고 더 인상 깊었던 부분은,
이 하네스 엔지니어링을 실제 팀의 업무 프로세스에 적용해
어떻게 개선을 시도하고 있는지에 대한 이야기였다.

다만 여기서 강조했던 한 가지가 있다.

“정답은 없다”는 것.

회사마다 상황이 다르고, 팀마다 구조가 다르기 때문에
어떤 방식이 항상 옳다고 말할 수는 없으며,
지금도 계속 다양한 실험을 통해 더 나은 방향을 찾아가고 있는 단계라는 점이었다.

이 이야기를 들으면서 자연스럽게 이런 생각이 들었다.
“그렇다면 우리 팀에는 어떤 방식의 하네스가 맞을까?”

하지만 솔직히 말하면,
이 글을 쓰고 있는 지금도 그 답을 명확하게 내리지는 못한 상태다.

그럼에도 불구하고 한 가지는 확실해졌다.

이런 불확실한 상황일수록
혼자 고민하고 끝내는 것이 아니라 팀원들과 계속 공유하고,
여러 가지 시도를 통해 우리에게 맞는 방식을 찾아가는 과정 자체가 중요하다는 점이다.

완벽한 방법을 찾는 것보다,
작은 실험을 반복하면서 점점 더 나은 방향으로 개선해 나가는 것.

그 방향성을 다시 한 번 확신하게 된, 의미 있는 시간이었다.