Green Software Engineering: Kenapa Efisiensi Kode Jadi Urusan Bisnis di 2026

Pada minggu kedua Januari 2026, Ibu Sari Wulandari, pendiri platform belanja bahan pokok online Belanja Rapi yang berbasis di Bandung, duduk terpaku menatap tagihan cloud bulanan dari penyedia infrastruktur mereka: Rp 341 juta, naik 68 persen dibanding Januari 2025. Belanja Rapi bukan startup baru — sudah berjalan sejak 2019, melayani sekitar 210.000 pengguna aktif bulanan di dua belas kota, dengan omzet tahunan sekitar Rp 62 miliar. Trafik memang naik, tapi tidak sampai 68 persen. Setelah tim engineering menelusuri lebih dalam, ditemukan dua penyebab utama. Pertama, fitur rekomendasi produk berbasis AI yang diluncurkan pertengahan 2025 memanggil model machine learning eksternal hampir setiap kali halaman beranda dimuat — termasuk untuk pengguna yang sama yang membuka aplikasi lima kali dalam satu jam tanpa perubahan apa pun di keranjang belanjanya. Kedua, tim mereka pernah mem-provision server cadangan berkapasitas besar untuk menghadapi lonjakan trafik Ramadan 2025, lalu lupa menurunkan kapasitasnya kembali setelah musim itu lewat. Dua kelalaian yang terdengar sepele ini menyumbang lebih dari Rp 95 juta dari kenaikan tagihan bulanan — uang yang mengalir keluar setiap bulan tanpa memberi nilai tambah apa pun bagi pelanggan.

Kasus Belanja Rapi bukan kejadian aneh. Ia adalah gejala dari sebuah pergeseran yang mulai terasa nyata bagi bisnis di Indonesia sepanjang 2025-2026: efisiensi energi software — yang dulu dianggap urusan teknis murni yang hanya relevan bagi penyedia data center raksasa — kini menjadi persoalan biaya operasional dan kepatuhan langsung bagi hampir semua bisnis yang punya website, aplikasi, atau sistem ERP. Bagi sebagian bisnis, ini bahkan mulai menjadi syarat kontrak: klien korporat atau mitra ekspor yang mewajibkan laporan jejak karbon operasional, termasuk jejak karbon dari operasi digital mereka.

Apa sebenarnya "green software" itu, di luar jargon marketing

Green software engineering, atau yang sering disebut carbon-aware computing, pada intinya sangat sederhana: menulis dan menjalankan software sedemikian rupa sehingga ia memakai daya komputasi, listrik, dan transfer data seminimal mungkin untuk menyelesaikan pekerjaannya — tanpa mengorbankan pengalaman pengguna. Ini bukan soal membeli sertifikat offset karbon atau menempelkan lencana "kami peduli lingkungan" di footer website. Ini praktik rekayasa yang konkret dan bisa diukur, mencakup beberapa area:

• Kode yang efisien — algoritma yang menghindari komputasi berulang yang tidak perlu, query database yang memakai index dengan benar alih-alih memindai seluruh tabel setiap kali, dan pemilihan bahasa atau runtime yang sesuai dengan beban kerja, bukan sekadar yang paling populer.
• Infrastruktur yang "pas ukuran" (right-sized) — kapasitas server yang mengikuti kebutuhan riil dan bisa naik-turun otomatis, bukan dipatok tinggi "untuk jaga-jaga" dan dibiarkan menyala penuh sepanjang tahun.
• Penjadwalan carbon-aware untuk batch job — menjalankan proses berat seperti laporan bulanan, backup besar, atau training model machine learning pada jam ketika grid listrik regional sedang lebih banyak dipasok energi terbarukan, atau ketika beban keseluruhan data center sedang rendah.
• Optimasi gambar dan aset — kompresi yang tepat, format modern seperti WebP atau AVIF, dan lazy loading, sehingga satu halaman tidak diam-diam mengirim 6-8 MB data ke setiap pengunjung hanya untuk menampilkan beberapa foto produk.
• Caching yang agresif dan cerdas — tidak menghitung ulang sesuatu yang jawabannya sama untuk seribu pengguna berikutnya yang meminta hal serupa.
• Mengurangi panggilan API AI yang tidak perlu — setiap panggilan ke model bahasa besar atau model image generation membawa biaya komputasi dan energi yang jauh lebih tinggi dibanding query database biasa. Memanggilnya untuk hal yang sebenarnya bisa diselesaikan dengan logika sederhana atau lookup cache adalah pemborosan yang berlipat ganda: boros biaya, boros energi, dan sering kali juga lebih lambat bagi pengguna.

Ada pula metrik formal yang mulai dipakai untuk mengukur ini secara serius, yaitu Software Carbon Intensity (SCI) — sebuah pendekatan untuk memperkirakan emisi karbon per unit kerja software (misalnya per transaksi atau per pengguna aktif). SCI belum jadi standar wajib di Indonesia, tapi arah globalnya jelas: efisiensi software mulai diukur, bukan sekadar diklaim.

Kenapa ini tiba-tiba menjadi urusan bisnis, bukan cuma urusan teknis

Setidaknya ada tiga kekuatan yang mendorong pergeseran ini secara bersamaan. Pertama, biaya listrik data center naik dan itu dibebankan langsung ke tagihan cloud — bukan cuma harga komputasi, tapi juga penyimpanan dan transfer data, yang semuanya pada akhirnya adalah proksi dari konsumsi energi. Penyedia cloud besar sudah mulai menaikkan harga layanan tertentu dengan alasan biaya infrastruktur dan energi yang naik, dan bisnis yang boros secara teknis akan merasakan kenaikan itu lebih dulu dan lebih dalam.

Kedua, fitur berbasis AI di dalam aplikasi bisnis — chatbot layanan pelanggan, generative image untuk katalog produk, mesin rekomendasi — menambah beban komputasi yang jauh lebih besar per interaksi dibanding fitur konvensional. Satu permintaan ke model bahasa besar bisa memakai energi puluhan hingga ratusan kali lipat dibanding satu query database sederhana. Ketika fitur AI ditambahkan tanpa perhitungan matang soal kapan dan seberapa sering ia dipanggil, biayanya menumpuk cepat — persis seperti yang dialami Belanja Rapi.

Ketiga, ekspektasi dan regulasi pelaporan keberlanjutan mulai menyentuh operasi digital, bukan hanya emisi fisik seperti pabrik atau armada kendaraan. Perusahaan besar yang tunduk pada aturan pelaporan keberlanjutan — termasuk yang terdaftar di bursa atau yang punya mitra dagang di Eropa dan Amerika — kini diminta melaporkan emisi rantai pasok mereka secara lebih luas, termasuk vendor teknologi dan penyedia layanan digital yang mereka pakai. Artinya, bisnis kecil dan menengah yang menjadi vendor atau mitra dari perusahaan besar bisa mulai ditanya: berapa jejak karbon dari sistem digital yang kalian operasikan untuk kami?

Biaya nyata dari mengabaikannya: cloud waste, risiko kepatuhan, dan reputasi

Ada tiga lapis risiko yang menumpuk kalau efisiensi software diabaikan. Lapis pertama adalah cloud waste murni — uang yang terbuang untuk kapasitas yang tidak dipakai, panggilan API yang tidak perlu, dan data yang dikirim berulang-ulang tanpa alasan. Riset industri secara konsisten menunjukkan bahwa 30-45 persen belanja cloud di banyak organisasi adalah pemborosan murni: server yang menyala tapi menganggur, storage yang menyimpan data yang sudah tidak relevan, atau proses yang berjalan jauh lebih sering dari yang dibutuhkan.

Lapis kedua adalah risiko kepatuhan dan kontrak. Semakin banyak korporasi besar mewajibkan mitra dan vendornya mengisi kuesioner keberlanjutan sebagai syarat kontrak atau tender. Bisnis yang tidak bisa menjawab pertanyaan dasar soal efisiensi digital mereka — apalagi yang sistemnya benar-benar boros — berisiko kalah tender atau kehilangan kontrak yang sudah berjalan bertahun-tahun, bukan karena produknya buruk, tapi karena laporan keberlanjutannya tidak lengkap.

Lapis ketiga, yang sering diremehkan, adalah dampak pada pengalaman pengguna dan reputasi. Website atau aplikasi yang berat — gambar tidak dikompresi, script yang menumpuk, panggilan API yang lambat — bukan cuma boros energi di sisi server, tapi juga menguras baterai perangkat pengguna dan menghabiskan kuota data mereka. Di pasar Indonesia, di mana sebagian besar pengguna mengakses internet lewat paket data terbatas dan perangkat kelas menengah, aplikasi yang berat langsung terasa sebagai pengalaman buruk: loading lambat, baterai cepat habis, dan akhirnya pengguna pindah ke kompetitor yang terasa lebih ringan dan responsif. Efisiensi teknis dan pengalaman pengguna, dalam banyak kasus, adalah dua sisi dari koin yang sama.

Solusi tempelan vs rekayasa ulang sungguhan: mengenali greenwashing digital

Banyak bisnis, ketika mulai sadar isu ini, tergoda mengambil jalan pintas: membeli sertifikat carbon offset, memindahkan hosting ke penyedia yang mengklaim "100 persen energi terbarukan" tanpa mengubah satu baris kode pun, atau sekadar menambahkan pernyataan komitmen keberlanjutan di halaman "Tentang Kami". Langkah-langkah ini tidak salah, tapi kalau berdiri sendiri tanpa perubahan teknis nyata, itu adalah greenwashing digital — klaim hijau yang tidak dibarengi efisiensi yang sesungguhnya. Sistem yang boros tetap boros; hanya listriknya sekarang berlabel hijau.

Rekayasa ulang sungguhan bekerja dengan cara yang berbeda. Ia dimulai dari audit menyeluruh: profiling kode untuk menemukan proses yang paling banyak memakan CPU dan memori, analisis pola trafik untuk melihat kapan dan bagaimana infrastruktur benar-benar dipakai, audit aset (gambar, video, script pihak ketiga) yang membebani setiap halaman, dan pemetaan setiap panggilan API AI untuk melihat mana yang benar-benar perlu real-time dan mana yang bisa di-cache atau dijadwalkan ulang. Dari situ baru disusun rencana perbaikan: refactor kode yang boros, right-sizing infrastruktur dengan auto-scaling yang benar, penerapan caching bertingkat, optimasi aset otomatis dalam pipeline deployment, dan redesign arsitektur AI supaya panggilan mahal hanya terjadi ketika benar-benar dibutuhkan. Hasilnya bukan sekadar klaim, tapi angka yang bisa dibandingkan sebelum dan sesudah: tagihan cloud turun, waktu muat halaman turun, dan skor efisiensi seperti SCI bisa dihitung dan dilacak dari waktu ke waktu.

Kisaran biaya dan waktu pengerjaan di Indonesia

Investasi untuk efisiensi software sangat bergantung pada skala dan kondisi sistem yang ada, tapi berikut kisaran realistis yang biasa dijumpai di pasar Indonesia untuk 2026:

• Audit efisiensi dan carbon assessment — untuk website atau aplikasi skala kecil-menengah, biasanya berkisar Rp 15 juta sampai Rp 45 juta, dikerjakan dalam 2-3 minggu. Hasilnya berupa laporan temuan, prioritas perbaikan, dan estimasi penghematan.
• Optimasi menengah (refactor bagian kritis, right-sizing infrastruktur, caching, kompresi aset) — kisaran Rp 150 juta sampai Rp 450 juta, dengan waktu pengerjaan 2-4 bulan, tergantung kompleksitas sistem yang ada.
• Rekayasa ulang arsitektur penuh untuk sistem berskala besar dengan banyak fitur AI dan trafik tinggi — kisaran Rp 500 juta sampai Rp 1,5 miliar, dengan waktu pengerjaan 4-8 bulan, mencakup migrasi infrastruktur, redesign layanan AI, dan pemasangan dashboard monitoring energi/biaya yang berkelanjutan.

Sebagai perbandingan, penghematan cloud yang dihasilkan dari optimasi menengah biasanya mencapai 25-40 persen dari tagihan bulanan sebelumnya — yang untuk bisnis dengan tagihan ratusan juta rupiah per bulan berarti balik modal dalam hitungan bulan, bukan tahun.

Studi kasus: Belanja Rapi setelah program efisiensi

Kembali ke Belanja Rapi. Setelah audit menyeluruh pada Februari 2026, tim engineering menemukan bahwa fitur rekomendasi AI mereka bisa dipangkas panggilannya sampai 70 persen tanpa mengurangi kualitas rekomendasi, cukup dengan menyimpan hasil rekomendasi dalam cache selama 15 menit dan hanya memanggil ulang model ketika keranjang belanja pengguna benar-benar berubah. Server cadangan Ramadan yang terlupakan langsung diturunkan kapasitasnya dan digantikan aturan auto-scaling berbasis trafik riil. Gambar produk yang sebelumnya diunggah dalam resolusi mentah dari toko mitra kini dikompresi otomatis lewat pipeline sebelum tayang ke pengguna.

Dalam tiga bulan setelah perubahan diterapkan penuh, tagihan cloud bulanan Belanja Rapi turun dari Rp 341 juta menjadi Rp 198 juta — penghematan 42 persen. Waktu muat halaman beranda turun dari rata-rata 4,1 detik menjadi 1,8 detik, dan tim mencatat kenaikan konversi checkout sebesar 11 persen pada periode yang sama, sebuah efek samping yang sering muncul karena kode yang efisien hampir selalu berarti aplikasi yang lebih cepat. Sebagai bonus, Belanja Rapi kini punya laporan efisiensi digital yang siap dipakai ketika salah satu mitra ritel besar mereka mulai meminta data jejak karbon vendor pada kuartal berikutnya.

Metrik yang wajib dipantau setelah implementasi

Efisiensi bukan proyek sekali jalan — ia perlu dipantau berkelanjutan lewat metrik yang jelas:

• Biaya cloud per transaksi — bukan cuma total tagihan, tapi biaya dibagi jumlah transaksi atau pengguna aktif, supaya pertumbuhan bisnis yang sehat tidak disalahartikan sebagai pemborosan.
• Page weight (berat halaman) — total ukuran data yang dikirim per kunjungan, idealnya di bawah 1-2 MB untuk halaman utama pada koneksi mobile.
• Skor Software Carbon Intensity (SCI) atau proksi energi setara, untuk melacak tren efisiensi dari waktu ke waktu, bukan cuma angka sesaat.
• Rasio cache hit — seberapa sering permintaan dijawab dari cache alih-alih dihitung ulang dari nol.
• Jumlah panggilan API AI per sesi pengguna — metrik yang sering diabaikan padahal langsung berkorelasi dengan biaya dan energi.
• Waktu respons dan Core Web Vitals — karena efisiensi dan kecepatan hampir selalu berjalan beriringan.

Tantangan implementasi dan cara mengatasinya

Rekayasa ulang untuk efisiensi bukan tanpa hambatan. Tantangan paling umum adalah kode lawas (legacy) yang ditulis tanpa dokumentasi memadai, sehingga tim butuh waktu ekstra untuk memahami sebelum berani mengubahnya — solusinya adalah audit bertahap dengan prioritas pada bagian sistem yang paling boros terlebih dulu, bukan mencoba merombak semuanya sekaligus. Tantangan kedua adalah kesenjangan keahlian: tidak semua tim internal terbiasa berpikir dalam kerangka efisiensi energi dan biaya, sehingga kolaborasi dengan mitra teknis yang sudah berpengalaman menangani migrasi serupa sangat membantu mempercepat kurva belajar. Tantangan ketiga adalah mengukur dampak karbon secara akurat, karena data emisi listrik regional di Indonesia belum sepenuhnya transparan real-time — di sinilah metrik proksi seperti biaya komputasi dan SCI berperan sebagai pendekatan praktis sambil menunggu data yang lebih presisi tersedia. Tantangan terakhir adalah menyeimbangkan efisiensi dengan pengalaman pengguna — jangan sampai penghematan agresif justru mengorbankan fitur yang pengguna sukai; solusinya adalah selalu menguji setiap perubahan dengan data pengguna riil, bukan asumsi di atas kertas.

Kasus Belanja Rapi menunjukkan sesuatu yang sederhana: sistem digital yang boros bukan cuma masalah lingkungan yang abstrak, tapi kebocoran biaya yang nyata dan risiko bisnis yang mulai bisa diukur dalam kontrak dan tender. Semakin lama dibiarkan, semakin besar tagihan yang menumpuk dan semakin sulit sistem yang sudah telanjur rumit untuk dirapikan. Kalau bisnis Anda belum pernah mengaudit efisiensi digitalnya, sekaranglah waktu yang tepat untuk mulai — sebelum tagihan cloud berikutnya datang, atau sebelum mitra dagang Anda yang bertanya lebih dulu. Tim AFSS siap membantu mengaudit sistem Anda dan merancang arsitektur yang lebih hemat sekaligus lebih cepat. Cek kisaran harga kami atau langsung ajukan proyek Anda.